ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<alyssa>
gfxstrand: Unity used to embed ancient Mesa, IDK if they still do
<alyssa>
glsl-optimizer lol
penguin42 has quit [Remote host closed the connection]
elongbug has quit [Read error: Connection reset by peer]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
benjaminl has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
pa has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
yyds has joined #dri-devel
yuq825 has joined #dri-devel
* alyssa
still can't choose between mesa glsl, glslang, and clang
<Sachiel>
don't choose, write a new one
<alyssa>
big brain
<alyssa>
based on in-tree prior art, it looks like glslang is the most popular option, but not by much
<alyssa>
with util/glsl2spirv.py from the anv side, hmm
<alyssa>
although you get vulkan-flavour spirv out, which might be annoying to use in a gl driver
<alyssa>
(tractable, but annoying)
<alyssa>
probably i should just pick one and go with it since there's no perfect option but ugh
<zmike>
write a cmdline util that pipes compiler/glsl through ntv you coward
<alyssa>
that doesn't solve any of the problems
<zmike>
oh now we gotta be solving problems?!
<alyssa>
i've just discovered builtin_int64.h
<alyssa>
make it stop make it stop make it stop
<zmike>
DavidHeidelberg[m]: did libx11 ever get upgraded in ci? looking at https://gitlab.freedesktop.org/mesa/mesa/-/jobs/47403946 I see there's two glx tests hitting the timeout, which means they're almost certainly deadlocking
Company has quit [Remote host closed the connection]
Kayden has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
thellstrom has joined #dri-devel
sima has joined #dri-devel
Zopolis4 has joined #dri-devel
pjakobsson has joined #dri-devel
frieder has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
f11f12 has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
junaid has joined #dri-devel
apinheiro has joined #dri-devel
bgs has joined #dri-devel
MrCooper has joined #dri-devel
sarahwalker has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest8938
Ahuj has joined #dri-devel
sarahwalker has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<MrCooper>
a530_gl 1/6 seems very flaky, multiple flaky tests in there
Zopolis4 has quit [Quit: Connection closed for inactivity]
donaldrobson has joined #dri-devel
mvlad has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
donaldrobson has quit [Ping timeout: 480 seconds]
donaldrobson has joined #dri-devel
cmichael has joined #dri-devel
vliaskov has joined #dri-devel
<DavidHeidelberg[m]>
MrCooper: it was almost "flake free", but then anholt fixed some fails, and different stuff started flaking (probably matters which combination of tests are run together), I'm adding another bunch of tests into flakes and we'll see :(
<MrCooper>
thanks
<DavidHeidelberg[m]>
zmike: into skips everywhere :( (like every driver has Fail/Crash and Flake)
<DavidHeidelberg[m]>
zmike: rarely, we had some patches libx11 (older), and with Debian 12 there should be the fixed version as default, let me check the logs
<DavidHeidelberg[m]>
*git logs
djbw has quit [Read error: Connection reset by peer]
apinheiro has quit [Quit: Leaving]
<DavidHeidelberg[m]>
zmike: Debian 12 has 1.8.4-2+deb12u1, seems without patches, looked into changelog of 1.8.5 (buildsystem and locales) and .6 (CVE) there shouldn't be any changes on top
<DavidHeidelberg[m]>
aaah, nope. The patch Drop --disable-thread-safety-constructor again. is applied again
<DavidHeidelberg[m]>
tjaalton: Why Mr. Anderson, why? Why you fighting the patch? Why do you persist? :D
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
hansg has joined #dri-devel
kzd has joined #dri-devel
sravn has quit []
danilo has quit []
dakr has joined #dri-devel
f11f12 has quit [Quit: Leaving]
kts has joined #dri-devel
sravn has joined #dri-devel
Company has joined #dri-devel
greenjustin_ has joined #dri-devel
hansg has quit [Remote host closed the connection]
junaid has quit [Remote host closed the connection]
greenjustin has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
gouchi has joined #dri-devel
benjaminl has quit [Remote host closed the connection]
benjaminl has joined #dri-devel
cmichael has quit [Quit: Leaving]
hansg has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
greenjustin_ is now known as greenjustin
benjaminl has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
junaid has joined #dri-devel
<anholt>
MrCooper: there's a test that crashes in that job, which takes out random other tests. I've got an MR up that moves it to skips.
<MrCooper>
cool
<anholt>
(I also have a branch that works on hopefully fixing the crash in that test, but it runs into other fail).
JohnnyonFlame has joined #dri-devel
<anholt>
I'm kinda grumpy that a530 got enabled when it was so unstable. I had disabled it for exactly this reason.
bmodem has joined #dri-devel
<linyaa>
VK_gpl for venus, anyone want to volunteer to review it? mesa!22419
junaid has quit [Quit: leaving]
<linyaa>
(the #1 and #2 venus devs are on lengthy vacation. i'm trying to merge it before august ends).
vyivel has quit [Ping timeout: 480 seconds]
pac85 has joined #dri-devel
<alyssa>
zmike: after extensive thought
<alyssa>
i too hate gl point size
<zmike>
😬
<alyssa>
why is gles different from gl here this is dumb
<alyssa>
how is this supposed to work in gallium drivers
<pac85>
So in mesa vkSetDebugUtilsObjectNameEXT relies on all objects passed to it to derive from vk_object_base, but VkSurface in wsi does not and the spec says nothing against passing that to vkSetDebugUtilsObjectNameEXT right? This causes crashes in some games and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24698 fixes the crashes
Ahuj has quit [Ping timeout: 480 seconds]
<alyssa>
zmike: "CTS explicitly has “wide points” tests which verify illegal point sizes that are exported by the tessellation and geometry shader stages. Isn’t that cool?"
<alyssa>
clown.jpg
<zmike>
any issues that existed there are long since fixed
<alyssa>
oh i see how this is supposed to work now
<alyssa>
I still hate it
<gfxstrand>
anholt: What drivers are still using NTT?
<zmike>
llvmpipe
<zmike>
nine
<anholt>
gfxstrand: r300 (for the moment), i915, virgl
<anholt>
nine is TTN.
<alyssa>
zmike: softpipe, yes. I didn't think llvmpipe?
<zmike>
ah right, nvm, I got them mixed up
<anholt>
yeah, softpipe.
<gfxstrand>
Pretty sure HW atomic counters are subtly busted and I'm trying to decide how much I care.
<anholt>
HW atomic counters are I think r600 only, and it's not on ntt any more.
<anholt>
(thanks, @gerddie!)
<anholt>
oh, I suppose virgl might be HW atomic counters.
<gfxstrand>
Yeah, virgl still plumbs them through. :rolls_eyes:
<alyssa>
can we tell virgl to stop
<gfxstrand>
Gotta make sure virgl on r600 is fast!
<alyssa>
:p
<gfxstrand>
I do have pseudo-minions who can fix that. :)
<anholt>
I would be +1 to virgl just doing ssbos.
<anholt>
that HW atomic counter code in NTT was such a fuss.
<alyssa>
zmike: i also hate triangles_with_adjacency hbu
<zmike>
yup
<alyssa>
*triangle_strips_with_adjacency
<alyssa>
(I mean all adjacency but especially tri strips)
<zmike>
amen
<zmike>
things should not be next to other things.
<alyssa>
absolutely
<alyssa>
wanted geometry shaders anyway for a laugh? we had a tool for that: points
<zmike>
or just turn off your computer and go outside
<alyssa>
gfxstrand: could you take a look at !24616? thanks :)
Kayden has joined #dri-devel
vsyrjala has joined #dri-devel
donaldrobson has quit [Ping timeout: 480 seconds]
benjaminl has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
* alyssa
wonders what's up with KHR-GLES31.core.geometry_shader.rendering.rendering.triangles_with_adjacency_input_line_strip_output_triangle_strip_adjacency_drawcall
<alyssa>
it's in the xfail list for radeonsi/gfx9 and angle+radv/stoney
<alyssa>
it doesn't /seem/ to be doing anything obviously spicy..
<zmike>
wfm
<alyssa>
I wonder what Zink is doing different than ANGLE
<zmike>
not failing ig
<alyssa>
I do notice that the GLES spec and the VK spec seemingly disagree on the definition of tri strips with adjacency
<alyssa>
er, no, maybe the GLES spec is just written in the most confusing way possible
<alyssa>
i think it's that
<anholt>
alyssa: zink CI isn't running that test on radv, fwiw.
<alyssa>
spicy
<zmike>
gotta run manual to get the good stuff
<anholt>
which toml do you see running that?
djbw has quit [Read error: Connection reset by peer]
<zmike>
Test case 'KHR-GLES31.core.geometry_shader.rendering.rendering.triangles_with_adjacency_input_line_strip_output_triangle_strip_adjacency_drawcall'..
<zmike>
Pass (Pass)
junaid has quit [Read error: No route to host]
junaid_ has joined #dri-devel
<alyssa>
Hmm I don't see Zink doing anything special for adjacency..
<alyssa>
so presumably this isn't a gl vs vk compat issue (I implemented from the VK spec)
<alyssa>
provoking vertex mode, oh that could be spicy..
<alyssa>
Yeah, I bet that's it.
<alyssa>
I'm doing special provoking vtx handling for tri strips, but not tri strips w/ adjacency. Yeah, that's gotta be wrong
<alyssa>
Thanks :)
<Sachiel>
glad to be useful
<alyssa>
gles spec you're useless
<alyssa>
vk you're up
<HdkR>
GLES sitting in the bus being all, "I'm underspecified :>"
<alyssa>
I don't think it's that, the GLES spec is just written as confusingly as possible (-:
djbw has joined #dri-devel
<alyssa>
hm that didn't fix the test but presumably fixed something..
<Sachiel>
if angle is failing with everything, then maybe angle is wrong
<alyssa>
this isn't angle, I just find it interesting that angle is failing the same tests I am
<Sachiel>
oh
mvlad is now known as Guest8991
mvlad has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
Guest8991 has quit [Ping timeout: 480 seconds]
benjaminl has joined #dri-devel
Kwiboo has quit [Quit: .]
jrpan has joined #dri-devel
<jrpan>
IDENTIFY
<alyssa>
ALYSSA
<DavidHeidelberg[m]>
jrpan: wrong window :D
<DavidHeidelberg[m]>
:D
<jrpan>
oops. Sry
<zmike>
peak #dri-devel energy
<jrpan>
Hi all, I’m using an old version of mesa3d, and I’m trying to read the index buffer within Intel Vulkan driver. I succeeded getting the address with formula `addr.bo->map + addr.offset` (addr is anv_address struct) in a simple vulkan sample. But when trying out a real game from Godot engine, the buffer is empty.
<jrpan>
). Is the method of calculating the address correct? Or is there any Vulkan feature that allows the buffer to be set after being bound? I’m a GPU researcher but unfamiliar with computer graphics. Any help would be appreciated!
Kwiboo has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
Kwiboo has quit [Quit: .]
<anholt>
jrpan: index buffer contents are probably being uploaded into that space by some other command. So you'd need to look at the contents after the GPU has finished.
heat has joined #dri-devel
<ccr>
"come out with your hands up .. slowly .. keep your editor and compiler visible .."
Kwiboo has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
vyivel has joined #dri-devel
<jrpan>
Thank you! I'm checking the buffer within `void genX(CmdDrawIndexed)` actually. I assume at this point the index buffer should be set. Is my assumption correct?
Kwiboo has quit []
<anholt>
jrpan: no. the command buffer is executed by the GPU asynchronously from the CPU recording into it. that execution may involve filling out the contents of that buffer.
Kwiboo has joined #dri-devel
<jrpan>
anholt: Thank you very much!
frankbinns has quit [Remote host closed the connection]
junaid_ has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
jrpan has quit [Quit: Page closed]
<alyssa>
Sachiel: Ok, so the definitions of tri strips with adjacency between the GLES and VK specs are subtly different after all
<alyssa>
specifically for the odd cases, the vertex order is different in gl
gouchi has quit [Remote host closed the connection]
<alyssa>
I assume this is provoking vertex related, but the VK spec is not being especially helpful
<alyssa>
if I use the gl ordering, the gles tests are passing
<alyssa>
I have no idea how this works on Zink
frankbinns has joined #dri-devel
<Sachiel>
yeah, it is provoking vertex defined. GL defaults to last and VK defaults to first, iirc. Zink always sets that, I don't know if because it's aware of the difference or if it's been working correctly by chance
<Sachiel>
knowing zmike, I'll go with "working by chance"
<ccr>
:O
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
mvlad has quit [Remote host closed the connection]
<alyssa>
at any rate, rotating the inputs appropriately to match the gl definition makes the test pass so... sure, whatever
<HdkR>
There's some extension for changing behaviour of provoking vertex isn't there? I would assume Zink relies on that
<Sachiel>
yup
<alyssa>
Sachiel: now i'm looking at the published intel docs to see if I can make sense of your commit
<alyssa>
must be so boring
crabbedhaloablut has quit []
<Kayden>
alyssa: yeah, I was really surprised to see that VK switched the convention to be reversed from GL (but presumably match DX)
<Sachiel>
oh, 01.org is dead and my prm links no longer work
<alyssa>
"Workaround: reorder mode must be set to REORDER_LEADING and reordering must be done in the Geometry shader"
<alyssa>
fun.
<Sachiel>
on the internal docs thing, there's a "Object Vertex Ordering" that tells you the order for all that stuff on the geometry shaders. I don't know if those titles are preserved when the PRMs are generated
junaid has quit [Ping timeout: 480 seconds]
bgs has quit [Remote host closed the connection]
<alyssa>
\/
heat has quit [Read error: No route to host]
heat_ has joined #dri-devel
greenjustin_ has joined #dri-devel
greenjustin has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
<alyssa>
the end-primitive piglit is so cursed.
<HdkR>
Cursed unit tests so you don't need to run the cursed games that they came from? :D
<alyssa>
HdkR: it has geometry shader invocations that emit stray vertices
<HdkR>
That's pretty cursed
<alyssa>
they don't form a primitive and just need to be ignored
<alyssa>
the problem I hit is that my implementation calculates the number of /actual/ vertices and allocates exactly what's needed
<alyssa>
but I didn't predicate the EmitVertex() stores on that bounds check... meaning the writes for those stray vertices race with the first vertices of the next geometry shader
<alyssa>
and since the geometry shaders are running in parallel, that means a test flake
<i509vcb>
VkPhysicalDeviceExternalImageFormatInfo states the following:
<i509vcb>
> To determine the image capabilities compatible with an external memory handle type, add a VkPhysicalDeviceExternalImageFormatInfo structure to the pNext chain of the VkPhysicalDeviceImageFormatInfo2 structure and a VkExternalImageFormatProperties structure to the pNext chain of the VkImageFormatProperties2 structure.
<i509vcb>
VkExternalImageFormatProperties doesn't seem to be required? Is this a spec oversight or is there a reasonable reason why you'd want to ignore VkExternalImageFormatProperties (you can't blindly assume the handle type can be exported/imported, you need to check VkExternalImageFormatProperties)
<HdkR>
Spicy polygons
<i509vcb>
(asking before I file a bug report with the Vulkan spec)
heat_ has quit [Remote host closed the connection]
frankbinns has quit [Remote host closed the connection]