<bbrezillon>
daniels: I'm currently testing partial-update+enlightenment, and buffer_age() returns me 1 most of the time, and sometimes 4 or 5 ?!
fysa has quit [Ping timeout: 246 seconds]
<bbrezillon>
note that it's using the DRI3 implementation (loader_dri3_query_buffer_age())
<bbrezillon>
any idea what could be causing that?
<bbrezillon>
looking at the back buffer address, I seem to have 2 buffers
<bbrezillon>
so I'd expect an age of 2 (except at the beginning)
stikonas has joined #panfrost
stikonas has quit [Ping timeout: 252 seconds]
maccraft123 has joined #panfrost
fysa has joined #panfrost
fysa has quit [Ping timeout: 265 seconds]
<daniels>
bbrezillon: 4 or 5 can happen when the app doesn't keep constant frame rate so bounces between double and triple buffering ... but yeah if you only ever have 2 allocated then that's obviously wrong
maccraft123 has quit [Quit: WeeChat 2.6]
karolherbst has quit [Ping timeout: 265 seconds]
maccraft123 has joined #panfrost
rhyskidd has joined #panfrost
maccraft123 has quit [Quit: WeeChat 2.6]
sphalerite has quit [Ping timeout: 264 seconds]
karolherbst has joined #panfrost
sphalerite has joined #panfrost
karolherbst has quit [Quit: duh 🐧]
karolherbst has joined #panfrost
fysa has joined #panfrost
maccraft123 has joined #panfrost
fysa has quit [Ping timeout: 268 seconds]
<dhewg>
tomeu: with sw decoding some videos won't play back on t720
<dhewg>
im not seeing any relevant debug output so far
<dhewg>
any idea what that is about? missing support for some color spaces maybe?
<dhewg>
on one file `mpv --opengl-rectangle-textures` errors out with "no matching function for call to `texture2D(sampler2DRect, vec2)'; candidates are: vec4 texture2D(sampler2D, vec2)..."
<bbrezillon>
daniels: looks like we receive XCB_PRESENT_EVENT_IDLE_NOTIFY before querying the new back buffer, and the implementation decides to reuse the same buffer, hence the age=1 here
<bbrezillon>
(I mean, the buffer is considered idle, and the implementation can reuse it immediately)
maccraft123 has quit [Ping timeout: 268 seconds]
<bbrezillon>
the problem is, the 2nd buffer, which not used most of the time keeps getting older and older
maccraft has joined #panfrost
megi has joined #panfrost
maccraft has quit [Quit: WeeChat 2.6]
<daniels>
right, that makes sense - it's optimised for the steady state
<bbrezillon>
so you reckon it should stay like that
<bbrezillon>
raster: I'm debugging partial-update+enlightenment, and I noticed that keeping the damage extend + forcing the damage box to 0.0->0.0 solves the problem
<bbrezillon>
raster: are you sure you update the whole region covered by the damage rects?
<raster>
bbrezillon: really sure. it's the same logic for sw
<raster>
and our update buffers are malloced so if we didnt render parts of those it'd be junk
<raster>
or they are recycles shm buffers from a shm pool
<raster>
(in sw)
<raster>
both sw and gl share the same logic for update region tracking etc.
<raster>
and what do you mean by forxing the dmg box?
<raster>
i'm sure you printf'd the rects coming in at the gl interface point?
<bbrezillon>
^ that might be a problem, but I only see one flush per swap right now
<raster>
bbrezillon: that'd be correct
<bbrezillon>
clearly, the KHR_partial_update() spec states that the damage region stays active until the next swap
<raster>
the output buffer flush in gl just fliushes all the rendering done so far to screen
<raster>
ie - swap
<bbrezillon>
which means that any explicit flush that happen between 2 swap will not reset the damage region
<raster>
yup
<raster>
though what are u testing? x or wayland?
<bbrezillon>
yes, but if you add draws after the flush, the implem doesn't know it has to reload the region that was previously drawn
<bbrezillon>
X
<raster>
aaah i was testing wl (gl_drm)
<bbrezillon>
didn't manage to start gl_drm
<raster>
just running e in a tty will run in wl mode
<raster>
nothing special to enable
<raster>
:)
<raster>
well if e and efl are built with wl and drm support...
<bbrezillon>
I did use the same PKGBUILD options
<bbrezillon>
anyway, should work with X too, right?
<raster>
those all enable that so u're ok
<bbrezillon>
and seem to have pretty much the same black tiles you had the other day
<bbrezillon>
so it's probably not related to X vs WL_DRM
<raster>
glsym_evas_gl_symbols() will be called before rendering after we get buffer age and use that plus update regions to calculate render regions. it should be called just once per fream at the start for rendering so thats where the input comes from
<bbrezillon>
I added traces to eng_output_redraws_next_update_get() to understand how the damage rects were built
<bbrezillon>
I always end up with a single rect
<raster>
aaah that'll be during iterating over the rects rendering each
<bbrezillon>
yes, that's the part I was looking at right now
<raster>
so that'll be after setting them up with the setdamageregion()
<bbrezillon>
yes
<raster>
you will end up with multiple rects if you have the right situations
<raster>
theres a bunch of fuzzy logic that tries to merge rects near eachother, round them up to 16x16 tile regions, and try limit the number of them as well
<bbrezillon>
would need to track the area cover by each draw happening between the set_damage_region() and swap()
<raster>
so it'll eventually expand them as bounding regions betwen multipel smaller input render regions just to do some tradeoff of # of render passes vs benefit to rendering less per pass :)
<bbrezillon>
as long as everything is re-rendered inside the damage extent and no explicit flush come in before the swap we should be good
<raster>
if we flushed before we had rendered all the regions we'd miss out entire update regions
<bbrezillon>
raster: hm, so I reverted the damage.box = 0 and added an explicit damage-reset after each flush
<bbrezillon>
and it work :-(
<bbrezillon>
works*
<tomeu>
alyssa: the cube now looks textured in glmark
<raster>
bbrezillon: the damage region should automatically be reset after every swap ... right?
<raster>
by mesa...
<bbrezillon>
raster: swap yes, not flush
<raster>
what - which flush
<raster>
this is the evas_outbuf_flush()?
<raster>
or another?
<bbrezillon>
that probably means we have a glFlush() (or something calling a flush internally)
<bbrezillon>
I don't know yet
<raster>
because the outptuf flush is the swap thing :)
<raster>
(also possibly passing damage regcts with tht swap and setting swap interval etc.)
<bbrezillon>
you mean glsym_evas_gl_common_context_flush() ?
<raster>
oh no
<raster>
that is different
<raster>
that flush pushes out pending triangle arrays we accumulted in the core common renderer
<raster>
so basically a gldraqwarrays()
<bbrezillon>
that's the one called from eng_outbuf_push_updated_region()
<raster>
it may issu emultiple drawarrays
<bbrezillon>
ok, so no flush
<bbrezillon>
I mean, no glFlush()
<raster>
the common rendere doesnt actually "draw" when u ask. it accumulates trinalge sin up to 128 separate triangle buffers
<bbrezillon>
(so many things using the term flush :))
<raster>
each tri buffer is for a specific texture id, shader program, blend mode etc.
<raster>
so this allows us to issue fewer drawarrays by merging lots of draws that share the same context info
<raster>
the common flush forces alll the pending tri buffers to be pushed out and cleared
<raster>
and yeah
<raster>
so manhy flushes
maccraft123 has quit [Quit: WeeChat 2.6]
<raster>
we actually dont call glFlush()
maccraft123 has joined #panfrost
<raster>
well there is code to call it but ONLY if the app is using out explicit exposing of the opengl-es api
<raster>
e will not be doing that when rendering
<raster>
it's highly rare to use this
<raster>
(as it means doing immediate mode rendering)
<dhewg>
tomeu: nice, that was fast
<dhewg>
and i think we have a winner, i see videos playing back using egl that don't with mesa master
raster has quit [Quit: Gettin' stinky!]
<tomeu>
yeah, it's starting to look pretty good
<dhewg>
indeed, nice work
<dhewg>
i'll play around some more and try to break it
Thra11_ has quit [Ping timeout: 265 seconds]
<dhewg>
nope, everything that didn't play before now plays fine. with either mpv or kodi
<tomeu>
alyssa: I'm quite surprised to find that, when running locally the 222 tests that fail on CI, only 80 of them fail
<tomeu>
same mesa commit
Thra11_ has joined #panfrost
pH5 has quit [Quit: bye]
raster has joined #panfrost
raster has quit [Client Quit]
gcl has quit [Ping timeout: 240 seconds]
gcl has joined #panfrost
maccraft123 has quit [Quit: WeeChat 2.6]
fysa has joined #panfrost
<robmur01>
tomeu: apparently the distinction between "older midgard" and "t720" is still a bit blurred - t620 becomes super-broken with that branch :(
maccraft123 has joined #panfrost
yann has quit [Ping timeout: 240 seconds]
megi has joined #panfrost
pH5 has joined #panfrost
karolherbst has quit [Ping timeout: 268 seconds]
jolan has quit [Quit: leaving]
pH5 has quit [Read error: Connection reset by peer]
jolan has joined #panfrost
fysa has quit [Ping timeout: 265 seconds]
pH5 has joined #panfrost
<alyssa>
robmur01: Good to know, thank you for testing
<alyssa>
tomeu: "the cube now looks textured in glmark" Ey!
<robmur01>
the cube does indeed now appear textured on my t720 too; it just no longer appears at all on my t620 :P
<alyssa>
:P
<alyssa>
I can finegrain
yann has joined #panfrost
robmur01 has quit [Ping timeout: 268 seconds]
robmur01 has joined #panfrost
karolherbst has joined #panfrost
fysa has joined #panfrost
fysa has quit [Read error: Connection reset by peer]
maccraft123 has quit [Quit: WeeChat 2.6]
maccraft123 has joined #panfrost
maccraft123 has quit [Quit: WeeChat 2.6]
robmur01 has quit [Remote host closed the connection]
robmur01 has joined #panfrost
guillaume_g has quit [Quit: Konversation terminated!]
stikonas has joined #panfrost
maccraft123 has joined #panfrost
BenG83 has joined #panfrost
NeuroScr has joined #panfrost
maccraft123 has quit [Quit: WeeChat 2.6]
maccraft123 has joined #panfrost
maccraft123 has quit [Client Quit]
* alyssa
time to clean up giant set of branches
<alyssa>
now that LCRA is merged
<anarsoul>
yay
<anarsoul>
:)
maccraft123 has joined #panfrost
<alyssa>
Yay indeed :)
<alyssa>
unfortunatley I can't just delete everything ... lot of my forgotten branches I have here do contain good code that I forgot about due to task switching
<alyssa>
so I'm going through and cherry-picking
<Lyude>
i feel that
<Lyude>
i have so many branches for various features and stuff that are mostly done, but I haven't been able to finish up because i've been way too preoccupied with other stuf
<Lyude>
(not on panfrost, just in general with the projects I work on)
<HdkR>
The last couple percent towards finishing a branch of work is always the most work :P
<Lyude>
for sure
<alyssa>
Sigh
<alyssa>
With that, time to rebase my SSBO/OpenCL series now that LCRA landed and see where we're at
<alyssa>
..of course, most of mesa is now recompiling...
Elpaulo has joined #panfrost
<alyssa>
Ugh this series is going to conflict pretty bad with the fp16 series. Meh.
<alyssa>
This is the bigger/more important one, it wins, I'll try to add on fp16 to it later but honestly let's get this to the finish line first.
maccraft123 has quit [Ping timeout: 240 seconds]
maccraft123 has joined #panfrost
maccraft123 has quit [Ping timeout: 246 seconds]
maccraft123 has joined #panfrost
davidlt has quit [Ping timeout: 246 seconds]
maccraft123 has quit [Quit: WeeChat 2.6]
davidlt has joined #panfrost
davidlt has quit [Ping timeout: 240 seconds]
BenG83 has quit [Ping timeout: 265 seconds]
pH5 has quit [Ping timeout: 265 seconds]
karolherbst has quit [Remote host closed the connection]