<stikonas>
HdkR: I think it was more of a case, haven't done yet
<alyssa>
TheCycoONE: I didn't realise Xwayland/egl worked in weston, neat
<stikonas>
in some u-boot fork by rockchip developer I now saw rk3399-sdram-lpddr4* file
<HdkR>
Oh, maybe I misread the conversation about two blobs remaining :P
<stikonas>
well, I still use the blob
<stikonas>
but hopefully soon somebody will add a proper rockpro64 support to u-boot...
<stikonas>
at least I got panfrost running :)
<stikonas>
even with kwin_wayland
<TheCycoONE>
it doesn't have any backend specific code, so I launched with SDL_RENDER_DRIVER=opengles2 - a bit better; everything was skewed, like the number of pixels in a line wasn't right
<alyssa>
TheCycoONE: stride is probably wrong somewhere
<alyssa>
Are the colours right?
<TheCycoONE>
yes
<alyssa>
Alright
<alyssa>
(That eliminates a whole class of bugs related to bad format bits)
<alyssa>
This is still from wayland?
<alyssa>
*Weston
<TheCycoONE>
yeah, SDL_VIDEO_DRIVER=wayland, launched from weston
<alyssa>
Hrmph.
<stikonas>
I tried to start wesnoth from weston :D, had to reboot
<alyssa>
Do glmark2-es2-wayland / es2gears_wayland / etc have the same issue?
<stikonas>
I didn't try SDL_RENDER_DRIVER=opengles2 though...
<alyssa>
stikonas: Bwa? I didn't realise you were playing with any SDL apps?
<stikonas>
only for a few seconds...
<TheCycoONE>
es2gears_wayland is fine
<stikonas>
until it crashed
<TheCycoONE>
I don't have glmark
<stikonas>
well, I might play a bit more later
<stikonas>
it's bed time
<alyssa>
Nini
<alyssa>
TheCycoONE: Hrmph
<alyssa>
I wonder what SDL could be doing
stikonas has quit [Remote host closed the connection]
<TheCycoONE>
there's ways to get a trace of gl calls right?
<alyssa>
TheCycoONE: Shot in the dark, but what's your window size?
<alyssa>
Specifically the width
<HdkR>
apitrace and renderdoc works well if you want to capture GL at the API level
<alyssa>
I need to try that :p
<TheCycoONE>
1055
<HdkR>
apitrace will capture things from the start of the application launch while renderdoc lets you capture per frame data
<TheCycoONE>
I can fiddle with the width; what's a value that should be good?
<TheCycoONE>
yep, 640x480 fixes it
<TheCycoONE>
at least through the spash screen and intro movie - then the colours get screwed up for the game menu
<HdkR>
Nice
<alyssa>
TheCycoONE: lol, okay, yeah
<alyssa>
Widths need to be tile-aligned (16x16)
<alyssa>
I should probably assert guard that
<alyssa>
HdkR: apitrace won't work on my panfrost machine, bailing with "error: unavailable fucntion glXGetProcAddressARB"
<alyssa>
Any ideas?
<HdkR>
Are you tracing an EGL application?
<HdkR>
`apitrace trace -a egl es2gears`
<alyssa>
Ah
<HdkR>
Then `qapitrace es2gears.trace`
<alyssa>
qapitrace?
<HdkR>
Trace file appears in the cwdir when the application closes
<HdkR>
qapitrace is the QT application for inspecting the trace file after the fact
<alyssa>
Oo
<HdkR>
Or you can just `apitrace repla es2gears.trace` to replay it
<HdkR>
replay*
<alyssa>
Super helpful!
<alyssa>
Probably will help solve some bugz
<alyssa>
:P
<HdkR>
And it is an API level capture, so you don't have to worry about visual problems
<HdkR>
Fix the bugs and hope for the trace to play correctly :P
<alyssa>
...Oh, lovely, I regressed [redacted] sometime today. Ok.
<TheCycoONE>
thanks HdkR
<HdkR>
Oh. What did I do?
<HdkR>
alyssa: Does xmoto and teeworlds work with the new GL work though? :D
<alyssa>
HdkR: Who and what?
<HdkR>
Those are two of the three games I care about
<alyssa>
What's the third? :P
<HdkR>
I'd ask about rrootage, but lawl, that is like a hard x86 only title
<alyssa>
Titles I care about: SuperTuxKart, ....that's it really
<alyssa>
Even then it's like
<alyssa>
Eh
<alyssa>
<--- does not like video games
<HdkR>
and until we get to ES 3 or GL 3 I can't ask about Dolphin
<alyssa>
:P
<alyssa>
HdkR: Um
<alyssa>
For an app I just tried, _ertyhing_ ended up on frame 0
<alyssa>
So it thinks there are 2 million draw calls on one frame
<alyssa>
Uh oh
<alyssa>
This makes debug prohibitively difficult :p
<HdkR>
Oh
<HdkR>
There is a way to change the new frame marker
<HdkR>
misremember. Nvidia nsight tools have a way to set the end frame marker
<HdkR>
Looks like renderdoc doesn't have a way to set the end frame marker either :|
<TheCycoONE>
I maintain CorsixTH, so I care about it - that's probably it :)
<HdkR>
Nice
<alyssa>
TheCycoONE: ^_^
<HdkR>
I maintain a collection of insanities
<alyssa>
I maintain Panfrost
<alyssa>
:P
<TheCycoONE>
and I'm very thankful!
<alyssa>
:)
<TheCycoONE>
night \o
<alyssa>
o
<alyssa>
Eliminating more transient uploads for (hopefully) lower overhead
<alyssa>
Index buffers are directly mapped now
<alyssa>
Going from 36k to 30k bytes uploaded transient in glxgears
<alyssa>
...which is pretty pathetic but it probably adds up for bigger apps :P
<alyssa>
Kodi is nice :)
<alyssa>
...and nicer with Panfrost
<alyssa>
:P
_whitelogger has joined #panfrost
<sphalerite>
o/ I've been busy with other things for a while, what's the current state of affairs with panfrost, particularly kernel-wise?
pH5 has joined #panfrost
<tomeu>
alyssa: I agree with your assessment in principle, but once I start thinking of how to move forward, I do'nt see a good reason to come up with an ABI that is any different to that of lima
<tomeu>
because the kernel doesn't know about bytecode or cmd stream, then I don't see much left that could make that big of a difference
<tomeu>
unless the ARM people took a deliberate effort to make things different for the sake of it :)
<tomeu>
if the ABI is shared between lima and panfrost, then the winsys is basically the same and the compiler and cmd generation code has to be abstracted anyway same as it is in other drivers such as freedreno
<tomeu>
there will be of course differences to tackle in the common code, but I don't have right now a good reason to think that they would be substantially bigger than differences between versions of midgard and bitfrost
<tomeu>
in any case, I think it's too early to come up with a clear answer, so the immediate question is what to try first: separate drivers and merge them later if needed, or start with same drivers and copy out later if needed
<tomeu>
even if we decided right now that we want to have separate code bases for everything, I think the best way of starting things up would be to copy lima's kernel and mesa drivers and gradually changing them to match midgard
raster has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
<mifritscher>
one question: how big is the kernel driver? and is the needed functionality clear?
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
adjtm_ has joined #panfrost
adjtm has quit [Ping timeout: 250 seconds]
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Remote host closed the connection]
rhyskidd has joined #panfrost
rhyskidd has quit [Remote host closed the connection]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
_whitelogger has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
afaerber has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
<raster>
hmm what src goes into making rockchip_dri.so?
<raster>
rockchip_drm_winsys.c ?
<tomeu>
raster: would expect so
<tomeu>
and the GPU stuff is in panfrost_dri.so
<raster>
i'
<raster>
i'm gettring a totally empty extensions array from it
<raster>
gee. there is no code in that... well not much
<raster>
__driDriverExtensions[] that is is just a NULL entry in it so its empty
<raster>
how on earth is it even getting __driDriverExtensions
<raster>
the megadrive4r gets linked into drockchip_dri?
<raster>
hmm lineks with panfrostwinsys
<raster>
and that provides just 2 funcs////
<raster>
not extensions
<raster>
basically the problem for init for panfrost for me is it's looking for DRI_Core and DRI_DRI2 extensions and cant find either
<raster>
failed to bind extensions
<tomeu>
raster: I think these days it should be calling __driDriverGetExtensions_panfrost()
<tomeu>
well, or __driDriverGetExtensions_rockchip()