ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
kzd has quit [Quit: kzd]
<RAOF>
daniels: Yeah, the weird shadow gbm_bo is a problem with my proposal. I'm not clear about the bandwidth concern, though? If you're on embedded, you've got a gbm_bo you want to scanout of, but it's not in scanoutable memory what's the *better* approach than a blit?
kzd has joined #dri-devel
<RAOF>
Anyway, mainly my concern is that every time I look at this code I go "Urgh, I've got a dmabuf in a format the GPU claims to be able to scanout of, but we're setting up a bunch of EGL state, texturing from it, and hoping that the drivers are smart enough to just use the dma engine the GPU surely has".
<RAOF>
So if gbm_bo_copy (possibly plus an "allocate a gbm_bo that'll be scanoutable in whatever format you'd most like to copy into" function) is an acceptable API then that also scratches my itch.
alyssa has joined #dri-devel
<alyssa>
oh, hum, KHR-GLES31.core.compute_shader.simple-compute-shared_context is a new test
<alyssa>
so maybe a test bug?
<alyssa>
or maybe a weird mesa/st bug?
<alyssa>
(failing before it even gets to the driver)
<alyssa>
(fails under softpipe too)
<zmike>
I filed a ticket about that failing on zink recently
<alyssa>
spicy
<alyssa>
I expect it's failing on all mesa drivers
<alyssa>
updated your ticket
krushia has joined #dri-devel
co1umbarius has joined #dri-devel
<Sachiel>
seems to pass on iris
columbarius has quit [Ping timeout: 480 seconds]
<jenatali>
Guess I need to try it
<alyssa>
Sachiel: even spicier.
<alyssa>
debug build?
<alyssa>
zmike: x86?
<Sachiel>
release, it seems. Let's try a debug
mdroper has quit [Remote host closed the connection]
<alyssa>
the test looks ok.
<alyssa>
I am very confused
<Sachiel>
passes on debug too
<alyssa>
I see the shader object added into mesa's hash table but not removed, and yet it can't be found later
<alyssa>
memory corruption maybe?
<alyssa>
valgrind doesn't complain
<alyssa>
ooh
<alyssa>
wait
<alyssa>
there are multiple contexts flying around arent there
<alyssa>
right, yes
<alyssa>
it's trying to glDeleteProgram from a different gl_context than the shaders were created on
<alyssa>
I am unsure if that's legal
<jenatali>
Why not, if they're shared?
<jenatali>
Isn't there a pipe cap for shareable shaders?
<alyssa>
jenatali: "why not" well the entirety of mesa/st seems to believe it's not legal
<alyssa>
and if that is false oh boy
<jenatali>
Yeah seems like mesa/st needs to replicate them if it's false but maybe it's just not putting them in the share group now?
* jenatali
is guessing
<alyssa>
yeah.. the two contexts have different ctx->Shared
<alyssa>
I think that's the actual problem here
<jenatali>
O.o
<jenatali>
How could that ever pass? How does iris pass?
<alyssa>
Unclear
<alyssa>
jenatali: tracing up the call stack into WSI stuff
<alyssa>
I'm using a surfaceless deqp
<alyssa>
Sachiel: what window system is your deqp?
<jenatali>
Ooh
<Sachiel>
whatever it is when you don't specify one. I usually just look at vulkan
<Sachiel>
since it does pop up a window, I assume it's not surfaceless
<alyssa>
glx maybe
<alyssa>
jenatali: driCreateContextAttribs called with shared = NULL
pallavim has quit [Read error: Connection reset by peer]
bmodem has joined #dri-devel
bmodem has quit []
sima has joined #dri-devel
bmodem has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
sgruszka has joined #dri-devel
Duke`` has joined #dri-devel
nchery has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
bgs has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
kzd has quit [Ping timeout: 480 seconds]
bgs has quit [Remote host closed the connection]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
junaid has joined #dri-devel
pochu has joined #dri-devel
q66 has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
<benjamin1>
so I just had a wild time debugging a behavior in nvk where the number of pushes needed for a command buffer was very different between a debug and release build (674 vs 1025). turns out the root cause d9f8225398d12c3ca25e6a5d6455711781bdec9b, which sets P_IMMD to use immediate form _only when the compiler can prove that the value fits in 13 bits at compile time_.
<benjamin1>
I am awed and horrified that it's even possible to do this :)
q66 has joined #dri-devel
<pq>
emersion, don't single-plane YUV formats always have full-resolution chroma, so no chroma reconstruction is needed?
pcercuei has joined #dri-devel
<daniels>
pq: no, e.g. YUYV is 2x horizontally subsampled
<jannau>
pq: no, the most common single plane YUV format is YUY2 (and variants) which is 4:2:2 subsampled
<pq>
aha
<pq>
so what are the chroma siting rules for that? Are there more than one flavor, like there are for 4:2:0?
mvlad has joined #dri-devel
<pq>
I've missed the 4:2:2, because it's never mentioned in the video standards I've been reading about broadcast and HDR.
<pq>
handling 4:2:2 chroma siting is currently missing in the Wayland color-representation extension, too
anshuma1 has joined #dri-devel
biju has joined #dri-devel
biju has quit []
rasterman has joined #dri-devel
lynxeye has joined #dri-devel
Danct12 is now known as Guest2487
Danct12 has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest2488
Danct12 has quit []
Danct12 has joined #dri-devel
bmodem1 has joined #dri-devel
swalker__ has joined #dri-devel
<gfxstrand>
dcbaker: \o/
<jannau>
pq: it is co-located with the first luma sample in h264 and h265. av1 in practice as well unless it is externally signalled
<gfxstrand>
dcbaker: If a fork of my nak/main branch magically appeared which uses said fancy new integration, I wouldn't mind. ;-)
bmodem has quit [Ping timeout: 480 seconds]
Guest2488 has quit [Ping timeout: 480 seconds]
cmichael has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
Danct12 is now known as Guest2489
Danct12 has joined #dri-devel
Guest2489 has quit [Ping timeout: 480 seconds]
sgruszka has quit [Ping timeout: 480 seconds]
Danct12 has quit [Quit: WeeChat 3.8]
i509vcb has quit [Quit: Connection closed for inactivity]
<pq>
jannau, and no other convention is used anywhere to warrant making the siting configurable?
<eric_engestrom>
not at all; I've only been following from the sidelines, but they reported that this commit fixes the issue on main, and applying it on 23.1 also fixes the issue
<dolphin>
airlied, sima: drm-intel-fixes PR sent, just 4 fixes and two were to selftests to appease static checkers
<eric_engestrom>
oh you're right dj-death, I has missed the last comment 🤦
<eric_engestrom>
nevermind then, nothing to do on mesa
* eric_engestrom
read this last night, and asked you this morning without re-reading the issue
<jannau>
pq: I don't know how it's handled on display side but being specified as fixed in h264/h265 while it could have been easily signalled using the same syntax as 4:2:0 suggests that it is somewhat safe to assume that the chroma location is fixed for 4:2:2
<pq>
jannau, very good.
<karolherbst>
dcbaker: nice.. I hope my other fix will make it as well :')
<pq>
and if it turns out contrary, the Wayland extension is easy to extend
<karolherbst>
ohh.. CI was fixed, nice
<karolherbst>
so my fix can land :)
<jannau>
of course there will be media with incorrectly downsampled chroma but I'm not sure if that justifies making it configurable. especially if it is unclear how display output should deal with it
<pq>
if it's incorrectly downsampled, then how would anyone know how it was really sampled, so can't do anything anyway
<rpigott>
eric_engestrom: my bad, with the latest vulkan-validation-layers I was able to apply them without a crash.
<jannau>
pq: wrong chroma location should introduce color artefacts on all vertical edges with color and brightness changes. you try to correct that but damage is already done
gawin has joined #dri-devel
<gawin>
today is stable release?
<karolherbst>
9bff18d13473a9fdf81d5158248472a9d8ecf2bd (very likely) introduced a use-after-heap regression in 6.3 for nouveau. You might want to check that out as well in other drivers.
fab has quit [Quit: fab]
<jannau>
sigh, I hate the abstraction mismatch between apple's firmware display interface and drm/kms. it's all integrated in basically a single entity on apple's side but I still need to mux between "crtc" and encoders/outputs
<jannau>
apple's model seems to be broken as well, I think it's not possible to get any information from connected displays if all "crtc" are used
kts has joined #dri-devel
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
<alyssa>
ok, definitely up against 2 bugs in the CTS here
<alyssa>
or a bug in CTS and a bug in Mesa, maybe
<alyssa>
I fixed the CTS bug but the test is still failing
FireBurn has quit [Read error: Connection reset by peer]
kts has quit [Quit: Konversation terminated!]
<alyssa>
can I submit those patches without needing to learn gerrit challenge
<daniels>
RAOF: hidden blits are problematic because I try to use planes greedily. if gbm_bo_import() silently allocs+copies, using planes is not a win compared to the GPU, so I'd rather just composite in almost all cases. even for the cases where it is a win, I'd really rather have that explicitly surfaced than the driver being 'helpful' but destructive
<daniels>
I'd take gbm_bo_copy() tho
cmichael has quit [Quit: Leaving]
bmodem has joined #dri-devel
<MrCooper>
how could a shadow BO be kept up to date, anyway
<lynxeye>
daniels: If you don't want blow up GBM to deal with fences etc, better have the copy in EGL/Vulkan if you need it at all. I think James Jones had some proposal along those lines at XDC a few years back.
<emersion>
^
<daniels>
yeah, makes sense
<daniels>
MrCooper: ... quite
bmodem1 has quit [Ping timeout: 480 seconds]
<mripard>
jannau: it looks similar (in that sense) to the I2C/SPI panels that have basically all bundled in one. Did you have a look in the simple kms helpers?
<jannau>
mripard: it's not a simple driver. it has to support crtcs and outputs (both up ~10 (much more outputs if dp-altmode/thunderbolt tunneled dp counts separately))
<mripard>
I'm not sure I get it, how can you support CRTCs if it's not exposed by the firmware?
<MrCooper>
zmike: looks like os.path.exists never succeeds in the add_shader_test for loop? No idea why though
<zmike>
it pretty puzzling
<jannau>
mripard: not a real CRTC but the FW interface provides most of the functionality a drm_crtc needs (and more)
swalker_ has joined #dri-devel
swalker_ is now known as Guest2505
swalker__ has quit [Remote host closed the connection]
<mripard>
ok :)
<mripard>
I don't know if you've looked at it already, but the RPi has a (out-of-tree) KMS driver running on their firmware too that they've been using in production for a while
<emersion>
i mean that's a perfectly readable diagram right here
<emersion>
don't tell me you don't yet have a kernel doc renderer embedded in your brain
<daniels>
too much brain surface area taken up by a fucking YAML parser
<jannau>
that's more or less the same level we already have. hardcoded drm_{crtc,encoder,output} display pipelines. crtc and output provide their functionality via the same fw interface
jewins has joined #dri-devel
swalker__ has joined #dri-devel
<jannau>
that stops being simple when crtc <-> output muxing has to be supported. The HW has usually more outputs than CRTCs
pochu has quit [Quit: leaving]
Danct12 has quit [Quit: WeeChat 3.8]
<mripard>
jannau: yeah... tell me about it :)
<mripard>
I spent way too much time figuring it out for the RPi :)
Haaninjo has joined #dri-devel
Guest2505 has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
junaid has quit [Remote host closed the connection]
jkrzyszt has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
<tleydxdy>
is there a vulkan format that puts alpha in byte 0? so ABGR in byte order
<mattst88>
tl;dr: my gpg key isn't in the release-maintainers-keys.asc key, and someone is concerned about that in regards to a release of glu I did a year or so ago
<mattst88>
I'm not really planning to make a bunch of releases or anything, so I wonder if dcbaker or eric_engestrom would like to tag and release a new glu?
<mattst88>
it's currently got a few fixes in master that would be nice to ship to distros, like a fix for clang-16 support
<mattst88>
and that would mean the latest release is signed by someone in the keyring
<mattst88>
IIRC I just used the standard xorg/util/modular/release.sh script for glu previously
<eric_engestrom>
mattst88: I can do that, but probably not this week
<mattst88>
thanks, that's totally fine
<eric_engestrom>
oh wait I just looked at the issue, is this just about signing the tarball?
<mattst88>
the filed issue is, yes; but I think it would be nice to tag a new release anyway which would kill two birds with one stone
<eric_engestrom>
that's all I have time to do today, I have to go now
<mattst88>
thanks
<eric_engestrom>
o/
vliaskov has joined #dri-devel
kts has joined #dri-devel
lygstate has joined #dri-devel
lygstate has quit []
lygstate has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
Leopold___ has joined #dri-devel
FireBurn has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
Piraty has quit [Remote host closed the connection]
Piraty has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Quit: Leaving]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
dviola has left #dri-devel [WeeChat 3.8]
alanc has joined #dri-devel
dviola has joined #dri-devel
vliaskov_ has joined #dri-devel
swalker__ has quit [Remote host closed the connection]
vliaskov has quit [Ping timeout: 480 seconds]
<dcbaker>
I don't actually know if my key is in the public maintainers asc
vliaskov_ has quit [Ping timeout: 480 seconds]
smilessh has quit [Read error: Connection reset by peer]
JohnnyonFlame has joined #dri-devel
caef^ has joined #dri-devel
gawin has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<dcbaker>
karolherbst: merged
<karolherbst>
\o/
oneforall2 has joined #dri-devel
<mattst88>
dcbaker: it is. see 677c1bd0559a4d96599348cae92750057f422942
<dcbaker>
TIL
<dcbaker>
lol
<dcbaker>
I can probably make a glu release. Maybe this will motivate me to add autoconf support to my attempt to rewrite release.sh in python...
<mattst88>
I'd suggest just doing the typical autotools make dist release that release.sh does
<mattst88>
doesn't hurt meson to have the pre-generated autotools files
<dcbaker>
Yeah. Right now the autotools path is a "raise NotImplementedError()" I've mostly been focused on mesa and trying to make the release process there smoother.
<dcbaker>
like having release.py do all of the "generate docs, update docs, bump VERSION, make release, update docs again, etc"
idr has quit [Ping timeout: 480 seconds]
<gfxstrand>
mareko, Kayden: How ephemeral is pipe_surface? Is it intended to be created/destroyed by the state-tracker at-will or is it okay to hang on to pointers to them?
<gfxstrand>
robclark: ^^
<robclark>
they are dynamically created in a bunch of cases
<robclark>
I mean, they are refcnt'd so you can hold on to one.. but the next frame/blit/whatever you might just end up with a new instance of an identical surface
FireBurn has quit [Quit: Konversation terminated!]
pac85 has quit [Quit: Konversation terminated!]
anshuma1 has quit [Ping timeout: 480 seconds]
gawin has quit [Quit: Konversation terminated!]
lynxeye has quit [Quit: Leaving.]
jewins has quit [Ping timeout: 480 seconds]
djbw_ has quit [Read error: Connection reset by peer]
lygstate has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
djbw_ has joined #dri-devel
<mareko>
gfxstrand: they are only render target views, refcounted, and created at will
<mareko>
drivers should hang onto them only if they are bound, frontends and utils can hang onto them however long they want
jewins has joined #dri-devel
idr has joined #dri-devel
smiles_1111 has joined #dri-devel
ngcortes has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
Leopold___ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
junaid has joined #dri-devel
junaid has quit [Quit: leaving]
sima has quit [Ping timeout: 480 seconds]
co1umbarius has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
heat has quit [Remote host closed the connection]
smiles_1111 has quit [Read error: No route to host]
heat has joined #dri-devel
smiles_1111 has joined #dri-devel
mvlad has quit [Remote host closed the connection]
mbrost has quit []
fab has quit [Quit: fab]
ADS_Sr has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
<zmike>
this is an ominous question
<airlied>
the egg came first
<HdkR>
Whoa, controversial
<karolherbst>
oh no... shared atomics are busted in iris if the source isn't an SSA
<karolherbst>
value
<karolherbst>
ehh, the offset
<karolherbst>
probably the atomic rework causing that
<karolherbst>
or maybe something else :) who knows, let's await my bisect
i509vcb has joined #dri-devel
<dj-death>
karolherbst: odd
<karolherbst>
068bf1378d71e6498a4763666be3bb28a0a2e5a6 intel/fs: enable SSBO accesses through the bindless heap
<karolherbst>
div r6 = intrinsic shared_atomic (r5, ssa_127) (base=0, atomic_op=iadd)
<dj-death>
yeah looks like 2 changes interacted in a bad way
<karolherbst>
yep
<karolherbst>
(I really should wirte up CL testing for iris)
<karolherbst>
*wire
<dj-death>
easy enough to fix
<karolherbst>
though it's kinda funny I only hit this with the CL CTS if I run it in spir-v mode instead of source
<karolherbst>
oh well...
<dj-death>
I can see that
<karolherbst>
yeah.. just it makes no sense, because the source also gets translated to spir-v almost through the same path.. probably something funky I didn't account for in my aot compiler
<dj-death>
there a bunch of NIR passes that would not deal with register well
<karolherbst>
yeah.. makes sense
<karolherbst>
I totally get it for images
<karolherbst>
luckily, CL isn't as crazy as GL and indirect textures don't exist at all :)
<dj-death>
DG2 is really interesting
<dj-death>
you can address surface from 3 different heaps
<karolherbst>
dj-death: yeah, seems to fix it btw
<karolherbst>
oh wow
<dj-death>
for buffers
<dj-death>
the sampler still just 2
<dj-death>
it's nice, but also a bit wtf
<karolherbst>
doing a full run and see if anything else stands out, but I think this was the only iris regression so far :)
<dj-death>
you can tell different HW teams working at different paces
<karolherbst>
I don't see why there isn't just "surface memory" but whatever :P
<dj-death>
I mean the surface descriptions can belong to 3 different heaps
<dj-death>
I don't know how it is for other HW
<karolherbst>
yeah.. it's just weird to have different heaps at all
<karolherbst>
well... on nvidia here is just one heap: the VM
<dj-death>
looks like AMD has a way to build the HW description in the shader
<dj-death>
which is nice
<dj-death>
or maybe it's just shaders
<karolherbst>
there is a table for direct surface accesses you can set up, but that's just handle to pointers into the normal global memory heap
<Sachiel>
someone at intel really misses segmented memory
<karolherbst>
nvidia also got rid of the shader heap, but that was just a bound pointer into the global memory and shaders got 32 bit address offsets...
<karolherbst>
but I'm sure Intel folks know what they are doing there :) It just feels weird to me to make those things overly complicated