ngcortes has quit [Remote host closed the connection]
<zmike>
I have wished for this many times
digetx has joined #dri-devel
egbert has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
Daanct12 has joined #dri-devel
camus has joined #dri-devel
camus has quit []
camus has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
egbert has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
adarshgm has joined #dri-devel
adarshgm has quit [Read error: Connection reset by peer]
saurabhg has joined #dri-devel
saurabhg has quit []
ella-0_ has joined #dri-devel
bmodem has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
bmodem has quit []
aravind has joined #dri-devel
mbrost has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
ppascher has joined #dri-devel
Company has quit [Quit: Leaving]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
aravind has quit [Remote host closed the connection]
LexSfX has quit []
aravind has joined #dri-devel
<hikiko>
dcbaker, thank you I've found the 32bit pkg config of debian and set it in my cross file and it worked after that I just realized that you've never seen my reply because I had been disconnected right afterwards!
<hikiko>
(so indeed debian has a 32bit pkgconfig :D)
danvet has joined #dri-devel
LexSfX has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
<dcbaker>
hikiko: awesome, glad you got that working :)
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
toolchains has joined #dri-devel
idr has quit [Quit: Leaving]
sdutt_ has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
Daanct12 has quit [Read error: Connection reset by peer]
toolchains has joined #dri-devel
itoral has joined #dri-devel
kts has joined #dri-devel
Daaanct12 has quit [Read error: Connection reset by peer]
Daaanct12 has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
probablymoony has quit []
moony has joined #dri-devel
lemonzest has joined #dri-devel
moony has quit []
Daaanct12 has quit [Remote host closed the connection]
moony has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
toolchains has joined #dri-devel
tzimmermann has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
zf has quit [Quit: Segmentation fault (core dumped)]
zf has joined #dri-devel
mbrost has joined #dri-devel
toolchains has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
jkrzyszt has joined #dri-devel
kts has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
pochu has joined #dri-devel
icecream95 has joined #dri-devel
tursulin has joined #dri-devel
Haaninjo has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
MajorBiscuit has joined #dri-devel
lynxeye has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
jewins has quit [Read error: Connection reset by peer]
lemonzest has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
pcercuei has joined #dri-devel
vliaskov has joined #dri-devel
whald has joined #dri-devel
Daanct12 has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
<whald>
hi! i'm trying to use two GLES contexts w/ two threads in the hope to do occasional updates to some texture without dropping a frame. i'm not happy. thing is that the glTexSubImage call takes about 18ms, happening on thread 2 and everything is good. T2 then does glFenceSync/glClientWaitSync, which bocks another 3.8 ms and *then* makes the texture visible to T1. there, the very first glDrawArrays call that actually uses that
<whald>
texture takes another 18 ms, completely defeating the purpose. is that expected?
<whald>
well, that's not the full picture. the glTexSubImage2D takes pretty consistent 18.5ms (handling 4k ARGB32 data on a not so beefy CPU, kind of expected). that glDrawArrays call OTOH fluctuates quite a lot, in the range of 4-18ms. it seems i'm missing something.
fahien has joined #dri-devel
<pq>
whald, a shot in the dark: would a glFinish() in T2 before handing the texture to T1 make any difference?
<whald>
pq, currently my code does a glFlush and then the glFenceSync dance. previously i had glFinish instead (which as I understand it should be equivalent) and indeed the outcome is the same.
tzimmermann has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
<pq>
ok
<pq>
glTexSubImage2D is probably two steps: first memcpy into some GL internal buffer, then DMA into VRAM. glTexSubImage2D returns after the memcpy is done, but does not wait for DMA. I guess you know that, because you are trying to wait for it already.
heat has joined #dri-devel
<pq>
I suppose the problem is, that DMA does not count as "rendering", so these methods to wait for it don't work. Maybe?
<pq>
whald, did you consider using PBO too?
<pq>
*DMA copy
<pq>
ISTR that PixelBufferObject could avoid the memcpy and maybe it also allows you to wait for the DMA copy to finish before trying to use the texture, so that draw does not need wait for DMA copy.
<whald>
pq, i considered but did not want to invest the time until i have at least some hope that it will help. probably interesting, too: the "bad behaviour" happens on Intel only, on some AMD APU I see exactly what I was hoping for, not a single frame dropped and all the heavy lifting happens on T2
<pq>
I can't promise PBO will make a difference, but I'd try it :-)
<pq>
Did you try on a discrete gfx card, too? APU is an iGPU, right?
<whald>
pq, I will try to use PBOs next, but I still feel that there's something fishy with intel because I have slow operations on *both* threads. if the DMA would be deferred until forced by glDrawArrays that would be unfortunate but understandable. but as it stands, both threads do horribly slow things. that's beyond my understanding.
<pq>
isn't that excatly what the wait for DMA copy to finish would explain?
<whald>
pq, APU is an igpu, indeed.
<whald>
pq, if the waiting happens on T1, what is it that takes consistent 18.5ms on T2?
<pq>
the memcpy, I'd guess
<MrCooper>
a CPU profile might shed some light on that
<whald>
MrCooper, very true, I'll play around with that and give PBOs a try and report back here in case anyone cares. ;-)
<pq>
from a CPU profile you'd also see if Mesa is doing pixel format conversions instead of a simple memcpy, too
<pq>
if PBO can avoid the memcpy step completely, that could be a win alone
<pq>
although, for some reason we don't use PBO in Weston, and I don't quite recall why we didn't bother so far
<whald>
pq, kind of, because I don't really care how long the stuff on T2 takes. but maybe it also happens with whatever is going on on T1
<pq>
whald, the memcpy takes a big bite out of the memory bandwidth, which may slow down other threads.
<pq>
...which is actually another theory of why T1 is randomly slow
JohnnyonFlame has quit [Ping timeout: 480 seconds]
MrCooper has quit [Quit: Leaving]
MrCooper has joined #dri-devel
icecream95 has quit [Ping timeout: 480 seconds]
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
toolchains has quit [Ping timeout: 480 seconds]
sdutt_ has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
aravind has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
Company has joined #dri-devel
fahien has joined #dri-devel
kts has joined #dri-devel
<whald>
pq, MrCooper so I implemented my texture update thingie using "glMapBufferOES" (i'm on GLES...) and indeed, this has "moved" the expensive first texture use in T1 to happen on T2 as well. T2 now takes consistent 28ms to do it's business, but T1 is smooth and no frames are left behind. thanks for the input!
<pq>
oh, never thought of that, but cool :-)
rasterman has joined #dri-devel
<whald>
pq, damn, i was too fast. i was only looking at my "alert" timers, which yell if something takes longer than 1ms. and those are gone. *but* now my fence synchronizing drawing with DRM page flip is *still* "late" and i'm indeed missing page flips. (╯°□°）╯︵ ┻━┻
<whald>
so whatever takes so long was moved from my main thread to wherever and nothing was won
<pq>
I didn't think PBO was about MapBuffer...
<pq>
whald, is it still fluctuating a lot how late the flip is?
luc4 has joined #dri-devel
<whald>
pq, yes, by about 7ms
MajorBiscuit has quit [Quit: WeeChat 3.5]
MajorBiscuit has joined #dri-devel
<MrCooper>
how do you measure that? Page flips by default complete only during vertical blank periods, so the completion should vary by the duration of a display refresh cycle
kts has quit [Ping timeout: 480 seconds]
<MrCooper>
oh, I guess you measure the fence itself, not the flip completion
kts has joined #dri-devel
TheSwordOfMyBone has joined #dri-devel
vup has joined #dri-devel
vup has quit []
vup has joined #dri-devel
<whald>
MrCooper, yes, i'm doing the SYNC_IOC_FILE_INFO to get the "render done" time from the fence FD
pochu_ has joined #dri-devel
pochu has quit [Ping timeout: 480 seconds]
rasterman has quit [Ping timeout: 480 seconds]
Terman has joined #dri-devel
jewins has joined #dri-devel
iive has joined #dri-devel
lemonzest has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
kts has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
camus has quit []
pochu_ has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
<KunalAgarwal[m]>
what could be the solution for glEGLImageTargetTexture2DOES not getting identified. I tried #define GL_GLEXT_PROTOTYPES before including gl.h
fxkamd has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
jekstrand: I kind of hate nir_alu_src->swizzle
<alyssa>
statically allocating 16 bytes of swizzle per source despite vec16 being lowered pretty quickly and only with OpenCL
<alyssa>
it would be nice to say swizzle[num_src_components:] is undefined and then allocate only the amount needed
<ajax>
KunalAgarwal[m]: it's not exported statically, you need to look it up eith eglGetProcAddress.
<alyssa>
but then the nir_alu_src[] array in nir_alu_instr[] doesn't work
<alyssa>
i should probably amend that first statemnet: I kind of hate C
kts has joined #dri-devel
<KunalAgarwal[m]>
auto glEGLImageTargetTexture2DOES = (PFNGLEGLIMAGETARGETTEXTURE2DOESPROC)eglGetProcAddress("glEGLImageTargetTexture2DOES");
<KunalAgarwal[m]>
is this right? its still not getting identified
<ajax>
what do you mean by "identified" here
<KunalAgarwal[m]>
PFNGLEGLIMAGETARGETTEXTURE2DOESPROC is undefined, my IDE shows..
<KunalAgarwal[m]>
and getting "‘glEGLImageTargetTexture2DOES’ was not declared in this scope " on compiling
<pq>
KunalAgarwal[m], did you forget to include gl2ext.h?
JohnnyonFlame has joined #dri-devel
Duke`` has joined #dri-devel
<KunalAgarwal[m]>
Its in gl.h too right?
nchery has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
sdutt has quit []
sdutt has joined #dri-devel
<daniels>
ajax: did you know that nwnk.net's MX is currently not routeable?
kts has joined #dri-devel
<ajax>
daniels: ugh. registrar deciding to not understand billing.
rgallaispou1 has quit [Read error: Connection reset by peer]
vliaskov has quit [Remote host closed the connection]
alatiera has quit [Quit: Ping timeout (120 seconds)]
alatiera has joined #dri-devel
<alyssa>
cwabbott: dschuermann and I were talking about parallel copies with more sources/dests than registers, which ir3 handles by sequentializes while spilling
<alyssa>
did you ever hit a shader (real-world or synthetic) testing that code path?
jkrzyszt has quit [Ping timeout: 480 seconds]
<cwabbott>
alyssa: tbh, I'm not entirely sure if I did
<alyssa>
okay
<cwabbott>
possibly, with IR3_SHADER_DEBUG=spillall
<cwabbott>
but... the way the ir3 spill pass is written, it doesn't really matter
<alyssa>
(ACO has this as a TODO and so far nobody noticed)
<cwabbott>
it doesn't *actually* sequentialize
<dschuermann>
the TODO is only about circles larger than the register file
<dschuermann>
which tbh seems almost impossible to write in a shader
<alyssa>
yeah..
<cwabbott>
it "goes through the motions" to sequentialize but stops short unless there's actually a spill
<cwabbott>
so yeah, it does solve that TODO
<cwabbott>
in general I would copy ir3's spilling pass over aco's (I may be biased though :) )
<dschuermann>
cwabbott: did you implement partial spilling of parallelcopies? (i.e. spilling a def first?)
MajorBiscuit has quit [Ping timeout: 480 seconds]
<alyssa>
yeah, the ir3 impl looks right, I'm just trying to see how one would test that
<cwabbott>
dschuermann: yeah, I did
<alyssa>
and it bothers me that none of the papers talk about this case
<alyssa>
(even as a footnote)
<dschuermann>
I should probably have a look at that as well ;)
<cwabbott>
"details to be left to the reader" lol
<alyssa>
"proof is trivial"
<alyssa>
"for details see [404]"
<dschuermann>
"as done in [123]" which solves something entirely different :P
<cwabbott>
dschuermann: the idea is to do the classic parallel copy resolving algorithm, but instead of emitting moves, it updates the list of live defs
<cwabbott>
and emit spill code if the pressure is exceeded
<cwabbott>
as-if we had emitted actual copies
<cwabbott>
if there was no spill code, then it actually doesn't do anything
<dschuermann>
ah, so along the path, it has to reload the operand and can then decide to spill one of the already handled defs?
<cwabbott>
right
<dschuermann>
how does that resolve the circles? in theory, you have to load all operands at once
<cwabbott>
it loads one at a time, and might spill other things in the process of loading them
<dschuermann>
very academic, but that's not enough
<cwabbott>
once we emit a reload, we have a "fresh" value we can assign to the same phi-web-class as the phi operand (so it shares a spill slot)
<cwabbott>
and if values share a spill slot, then we're already done because we can just spill it
<dschuermann>
😵💫
<dschuermann>
okay, that brings the question about the maximum number of spill slots needed with greedy coloring
<dschuermann>
because I assumed it to be 2n, but this case makes me wonder
luc4 has quit []
<cwabbott>
iirc you might have to create an extra spill slot in the case where you create a temporary to break a cycle and it's spilled
<ajax>
import the counters when you create the swapchain, handle target msc appropriately for whichever presentation mode, use the USTs from successive presents to estimate the frame time so you can get FIFO_RELAXED right...
<ajax>
thanks for double checking me, this code is subtle
<MrCooper>
how are you planning to set target MSC correctly for FIFO(_RELAXED) without waiting for the previous presentation to complete?
<MrCooper>
(kind of a rhetoric question I'm afraid :)
Daanct12 is now known as Danct12
mbrost has quit [Remote host closed the connection]
<ajax>
MrCooper: fire a NotifyMSC(0) right before presentation to see where it currently is?
alyssa has left #dri-devel [#dri-devel]
<ajax>
s/where/when/ i gues
mbrost has joined #dri-devel
<MrCooper>
that doesn't tell us when a pending presentation will complete
<MrCooper>
it would require a working crystal ball or time machine ;)
<ajax>
no, but it tells us what msc the server thinks is next, which is all you can hope for here i think
<ajax>
if you then get a CompleteNotify later where you discover you missed some frames, you can catch up then
<MrCooper>
FIFO semantics include "every image is actually presented", guaranteeing that requires waiting for the previous presentation to complete before sending another one
ybogdano is now known as Guest5636
ybogdano has joined #dri-devel
<ajax>
then i don't understand the difficulty. for fifo the target msc is always one greater than either the last one you sent or the last one you heard a completion about from the server, whichever is greater
<MrCooper>
the last one you sent may not complete at its target MSC but only a later one
Akari has quit [Quit: segmentation fault (core dumped)]
<MrCooper>
if you send another presentation for (previous target MSC + 1), it may end up replacing the previous one in that case, violating FIFO semantics
<ajax>
and when it does, i will run the event queue and discover when it did complete, and any subsequent submits will be scheduled for then plus one plus however many other images have presents pending
<ajax>
or: i keep the list of queued presents inside the wsi thread and drip them out one at a time in response to MSC notifies from the server
<ajax>
at the point where you have two images presented you can go ahead and ask for another wakeup for the incoming frame edge...
Akari has joined #dri-devel
Guest5636 has quit [Ping timeout: 480 seconds]
<MrCooper>
"and when it does", the damage is already done :)
<jekstrand>
AlexisHernndezGuzmn[m]: Yeah.... If we were in C++, I might make a little class that does nibbles and makes it look like an array or something.
<jekstrand>
alyssa, rather
<jekstrand>
Who's not online
<MrCooper>
ajax: MSC notifies just cannot tell us when a pending presentation will complete, only the completion event provides certainty for that
<MrCooper>
anyway, dinner time, back tomorrow
ybogdano has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
krushia_ has joined #dri-devel
krushia has quit [Read error: Connection reset by peer]
srslypascal is now known as Guest5640
srslypascal has joined #dri-devel
Guest5640 has quit [Ping timeout: 480 seconds]
fahien has quit [Quit: fahien]
fahien has joined #dri-devel
fahien has quit []
bwidawsk has joined #dri-devel
ngcortes has joined #dri-devel
Haaninjo has joined #dri-devel
aswarup_ has joined #dri-devel
aswarup_ has quit [Remote host closed the connection]
<jenatali>
zmike: Probably, but I don't think we have the border color swizzle cap hooked up at all right now
<zmike>
they're independent quirks
kts has quit [Ping timeout: 480 seconds]
<ajax>
MrCooper: i'm... not totally convinced that fifo requries that every image be displayed
<ajax>
it requires (in what might technically be non-normative discussion) that one image be removed from the queue on every frame interval
<ajax>
but that's not quite the same thing. if the target msc passes without the image being displayed it seems like from vulkan's perspective it's already been removed from the queue so skipping past it is fine
<ajax>
if it's me, and i queue three frames, and i discover that the first one posted only after the third one was supposed to, probably i _want_ to not wait for the remaining two image to post since their due date is already in the past...
danvet has quit [Ping timeout: 480 seconds]
macromorgan has quit [Read error: Connection reset by peer]
gouchi has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
nchery has quit [Ping timeout: 480 seconds]
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
macromorgan has joined #dri-devel
nchery has joined #dri-devel
ppascher has joined #dri-devel
krushia_ has quit []
Duke`` has quit [Ping timeout: 480 seconds]
frankbinns has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]
idr has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
pcercuei has quit [Quit: dodo]
alyssa has joined #dri-devel
<alyssa>
not going to lie, aco::span makes me a bit jealous of C++ ^_^