ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
haaninjo has quit [Quit: Ex-Chat]
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #dri-devel
amarsh04 has quit []
amarsh04 has joined #dri-devel
davispuh has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]
The_Company has joined #dri-devel
Namarrgon has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
alane has quit []
alane has joined #dri-devel
The_Company has quit []
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Jeremy_Rand_Talos has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
dapslt^ has left #dri-devel [#dri-devel]
kzd has quit [Ping timeout: 480 seconds]
peterson[m] has quit [autokilled: Spambot. Mail support@oftc.net if you think this is in error. (2025-02-24 03:58:21)]
heat has quit [Ping timeout: 480 seconds]
ziplocksoda has joined #dri-devel
glennk has joined #dri-devel
ziplocksoda has quit [Read error: Connection reset by peer]
dolphin has joined #dri-devel
fab has joined #dri-devel
itoral has joined #dri-devel
Duke`` has joined #dri-devel
gnarchie has quit [Remote host closed the connection]
cascardo has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
cascardo_ has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
kode54 has quit [Read error: Connection reset by peer]
kode54 has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
coldfeet has joined #dri-devel
sima has joined #dri-devel
yrlf has quit [Ping timeout: 480 seconds]
karolherbst has quit [Ping timeout: 480 seconds]
yrlf has joined #dri-devel
<Ristovski>
I can "bypass" glvnd (I have mesa built without it) while using nvidia proprietary by something silly like LD_PRELOAD, is there a similarly-naughty incantation that would work for EGL on Wayland as well?
mehdi-djait3397165695212282475 has joined #dri-devel
mahkoh has joined #dri-devel
<mahkoh>
On AMD and Intel cards, does it make sense to increase VRAM usage to remove dependencies between render passes, i.e. render passes writing to the same buffer, so that they can be rendered to in parallel? Or do those cards always process render passes in series anyway?
<mahkoh>
I'm using a single vulkan graphics queue.
<sima>
if the vk driver doesn't have multiple queues, then neither does the hw
<sima>
and I think for render that holds for everything (unless it's some multi-chip monster)
<mahkoh>
My thinking was: if two render passes are only able to use 50% of the GPU capacity each, could the GPU run them in parallel. I guess AMD and Intel can't do this?
tzimmermann has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
<mahkoh>
More concretely: I'm starting to use intermediate 16-bit blend buffers in my compositor. The question is: If I have two 1080p monitors, is it sufficient to use a single blend buffer or should I allocate 1 blend buffer per monitor to potentially decrease latency.
<mahkoh>
I assume the rendering operations will always use 100% of the GPU anyway. But there might be situations I haven't considered.
NiGaR has quit [Ping timeout: 480 seconds]
NiGaR has joined #dri-devel
sally has quit [Quit: sally]
mvlad has joined #dri-devel
<MrCooper>
dj-death: sounds like either GitLab accidentally associated a non-MR pipeline with the MR, or there's something wrong in the CI configuration
<MrCooper>
Ristovski: why wouldn't that work for EGL on Wayland?
<Ristovski>
MrCooper: Not sure, `eglinfo -B` tries to load nouveau which obviously fails at `eglInitialize` since I am using the proprietary ones
<MrCooper>
eglinfo prints information about all EGL platforms, nvidia probably doesn't support all of them
<Ristovski>
I am aware, yet there is only mesa/llvmpipe in the output, which is peculiar
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
jsa2 has joined #dri-devel
sally has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
<MrCooper>
maybe try running it in strace to see where it's picking up stuff from
frontin has joined #dri-devel
frieder has joined #dri-devel
fab has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
frieder has joined #dri-devel
phasta has joined #dri-devel
jkrzyszt_ has joined #dri-devel
rasterman has joined #dri-devel
Sid127- has joined #dri-devel
caitcatd- has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
ckoenig has joined #dri-devel
Sid127 has quit [Ping timeout: 480 seconds]
caitcatdev has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
sally has quit [Quit: sally]
mehdi-djait3397165695212282475 has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
<Company>
make the client/server thing an xdg portal so it works for flatpaks!
frieder has quit [Read error: Connection reset by peer]
gnarchie has joined #dri-devel
<MrCooper>
there's no client/server thing
<Company>
yet!
<Company>
I just wanted to point out the problem that sharing the cache is happening less these days
sarnex has quit [Read error: Connection reset by peer]
<MrCooper>
not sure what you mean by that
sarnex has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
bolson has joined #dri-devel
hansg has quit [Quit: Leaving]
<pac85>
mahkoh the vulkan spec says that commands always begin execution in the order they are issued, but can end out of order. This means that if you have two passes one after the other in a cb the first draw of the second pass must begin execution after the last draw of the first. Assuming there are no barriers that prevent it you can have some overlap between the two passes (so some draws from the previous pass might still be doing work when
<pac85>
the second pass starts) but in practice this is limited to a handful of draws for desktop GPUs. AMD technically does have more than one GFX queue but I don't think that's exposed. If it where you would have to split your passes into two separate submissions to take advantage of it. So to answer your question, removing dependencies between passes can have some benefit but how much depends on the workload. There is some mobile hw out there
<pac85>
with separate queues for vertex and fragment in which removing dependencies between passes allows for quite a bit of parallelism (those GPUs can't overlap vertex and fragment work unless they are from different passes, unlike most desktop HW and some mobile GPUs which can do it at a draw granulairty).
frieder has joined #dri-devel
mahkoh has joined #dri-devel
frieder has quit [Remote host closed the connection]
<mahkoh>
"first draw of the second pass must begin execution after the last draw of the first" - if the two render passes share no resources, then I suppose this would be indistinguishable from draws running in any order, which the GPU exploit to make use of available parallelism
<mahkoh>
but for now I'm going with a single buffer shared by all monitors
mahkoh has quit [Quit: WeeChat 4.5.2]
<alyssa>
glehmann: supporting everything in divergence is on my todo list
<alyssa>
or rather, describing divergence properties in nir_intrinsics.py
<alyssa>
(at what point we can build-time assert that everything is described)
<alyssa>
just haven't figured out exactly how that should look
phasta has quit [Ping timeout: 480 seconds]
guludo has quit [Quit: WeeChat 4.5.2]
guludo has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
<pac85>
mahkoh well yeah execution beginning in order doesn't have many semantics implications for most commands but it does match how most implementations on desktop work. (tiling GPUs somewhat do reorder but not the way you suggest).
dsimic is now known as Guest9904
dsimic has joined #dri-devel
Guest9904 has quit [Ping timeout: 480 seconds]
<digetx>
MrCooper: roughly remember, will try getting to it sooner
jsa2 has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
<alyssa>
[I can relatively easily write the coccinelle to port most of the tree to that, but i can't decide if it's, sensible]
<dcbaker>
Okay, after being sick for 3 weeks and then having inclement weather... I am finally almost caught up on everything. I'm planning to cut the last 24.3.x release on Wednesday, and I'll be sending out an email to the list with all of the patches that do not apply to get dev feedback on what they want to get backported before the release happens
<alyssa>
dcbaker: sorry to hear about the illness :(
<dcbaker>
Thanks. It's kinda my fault for not going to the doctor sooner. Listen kids, don't be a stubborn old man like me. lol
<alyssa>
:(
mattst88 has quit [Quit: Lost terminal]
tzimmermann has quit [Quit: Leaving]
davispuh has joined #dri-devel
<glehmann>
alyssa: I think your nir_progress idea is quite neat
<alyssa>
glehmann: thanks :)
<alyssa>
my main reservation is that it won't be practical to convert 100% of the tree (just because coccinelle isn't perfect and so on)
<alyssa>
and IDK if we end up in a very confusing spot if we have half-way coverage
<alyssa>
although maybe it'd be ok? and we'll see how close cocci can get
<alyssa>
there are only ~382 nir_metadata_presere calls in tree so if cocci can get most of them, that's a good spot
mattst88 has joined #dri-devel
<glehmann>
I think we should fully replace the old helper if we decide to adopt the new one, even if it will lead to weird code like if (progress) nir_progress(true, ) else nir_progress(true, ) in a few places until someone decides to clean it up
<gfxstrand>
alyssa: I don't hate it. :)
<alyssa>
glehmann: yeah that's fair
<alyssa>
gfxstrand: alright. I will see what I can cook up then :}
shashanks has joined #dri-devel
nchery has joined #dri-devel
vliaskov has joined #dri-devel
jsa2 has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
unerlige has quit [Ping timeout: 480 seconds]
heat is now known as Guest9911
Guest9911 has quit [Remote host closed the connection]
<uriah>
i'm not 100% sure that virtio-wl is required for amdgpu but perhaps the others
gnarchie has quit []
<robclark>
virtio-wl is for wayland proxy to host compositor, so not needed if you are using a guest compositor
<uriah>
ok
<robclark>
I think the others should not be mandatory... in any case, they are all guest kernel patches
<uriah>
i see
<uriah>
good to know
bolson has quit []
mvlad has quit [Remote host closed the connection]
bolson has joined #dri-devel
jeeeun841351908155 has quit []
jeeeun841351908155 has joined #dri-devel
<robclark>
ugg... why does piglit still use cmake.. and what does `Could NOT find PythonNumpy (missing: PythonNumpy_STATUS)` mean (I do ofc have python3-numpy installed)
<dcbaker>
robclark: I have some patches around somewhere...
<airlied>
usually means it's picked up a different python
<dcbaker>
not complete
<robclark>
hmm, does look like I have py 3.12 and 3.13 (but nothing more ancient)
<robclark>
hmm, cmake picked 3.12.9
<robclark>
ok, removing 3.12.9 did the trick.. ugg