ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
tarceri has joined #dri-devel
a-865 has quit [Quit: ChatZilla 0.17b1 [SeaMonkey 2.53.17/20230610105000]]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
penguin42 has quit [Remote host closed the connection]
Daaanct12 has quit [Remote host closed the connection]
yuq825 has joined #dri-devel
Danct12 has joined #dri-devel
vignesh has joined #dri-devel
Danct12 is now known as Guest6487
Danct12 has joined #dri-devel
Danct12 has quit [Quit: WeeChat 4.0.2]
a-865 has joined #dri-devel
aravind has joined #dri-devel
eukara has quit []
crabbedhaloablut has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
Company has quit [Remote host closed the connection]
co1umbarius has quit [Remote host closed the connection]
co1umbarius has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
kzd has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
Danct12 has joined #dri-devel
<Lynne>
airlied: I just rebooted, and nouveau works now
<Lynne>
guess it didn't like hot modprobes
<Lynne>
it's using ampere's gsp binary from 535, so the binary version must match with the headers
sebastiencs has joined #dri-devel
smiles_1111 has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
<Lynne>
got a triangle to render! struggled a bit to find any vulkan 1.0 clients at all
fab has joined #dri-devel
<Lynne>
vkquake runs too!
Duke`` has joined #dri-devel
<dj-death>
Looks like a530 runners are running into unexpected passes
ondracka has joined #dri-devel
<HdkR>
4
ondracka has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
ondracka has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
rasterman has joined #dri-devel
fab has quit [Quit: fab]
alanc has quit [Remote host closed the connection]
sima has joined #dri-devel
alanc has joined #dri-devel
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
zzyiwei has joined #dri-devel
fab has joined #dri-devel
zzyiwei has left #dri-devel [#dri-devel]
smiles_1111 has joined #dri-devel
zzyiwei has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
zzyiwei has left #dri-devel [#dri-devel]
tursulin has joined #dri-devel
rgallaispou has joined #dri-devel
mvlad has joined #dri-devel
pcercuei has joined #dri-devel
fab has quit [Read error: No route to host]
digetx has quit [Ping timeout: 480 seconds]
sgruszka has joined #dri-devel
lynxeye has joined #dri-devel
djbw has quit [Remote host closed the connection]
frieder has joined #dri-devel
donaldrobson has joined #dri-devel
paulie_ has joined #dri-devel
ondracka has quit [Read error: Connection reset by peer]
apinheiro has joined #dri-devel
<kode54>
I still wonder what the heck is up with the Xe driver and compute causing gpu crashes and resets
<kode54>
Is there any debug logging for the crash dump interface to pull the exact job queue that caused the crash? I saw something about that
cmichael has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
omioceodeotm^ has quit [Remote host closed the connection]
<DavidHeidelberg[m]>
dj-death: that's nice, link please. It's flake or geniue unexp pass?
<DavidHeidelberg[m]>
dj-death: also sorry about mess with these, I added like four batches of flakes, but some are still showing up, it's not the driver with most stable results
<dj-death>
I put the link in the MR
<dj-death>
seems to be flakes mostly
<DavidHeidelberg[m]>
I see the MR, thanks!
<dj-death>
np
<DavidHeidelberg[m]>
dj-death: at some point (next flakes batch) I think I'll wild card those which are just adding testcases in one group each time
<DavidHeidelberg[m]>
*wildcard
vyivel has quit [Remote host closed the connection]
<alyssa>
jenatali: TBF nir_builder for big shaders will still suck
<alyssa>
I really want a common way to write internal shaders as GLSL or OpenCL C
<zmike>
jenatali: I was optimistic at the beginning and tried to start with xfb
<jenatali>
alyssa: Embrace C++, have nir SSA defa as classes with proper operators
<jenatali>
That's what WARP does and it's honestly okay to write internal shaders
<alyssa>
jenatali: TBH I still would rather have real GLSL or CL C
<alyssa>
There are a bunch of different approaches to this already used in tree
<alyssa>
I would like to pick one of them and promote it to common code
<alyssa>
- qoShaderModuleCreateInfoGLSL (GLSL, single source, aco tests, from Crucible, depends on glslang)
<alyssa>
- float64.glsl and friends (GLSL, separate source, uses Mesa's GLSL compiler)
<konstantin_>
GLSL is the one that doesn't require any driver changes
<alyssa>
- anv's bvh builder (OpenCL C, separate source, uses the OpenCL compiling pipeline at build time, runs their backend compiler at build time, scary)
<konstantin_>
D:
<jenatali>
Yeah that's fine for writing full shaders that don't need parameterization
<jenatali>
Being able to sprinkle builder conditional logic is quite nice
<alyssa>
- radv's bvh building (GLSL, separate source, glslang at build-time?)
<alyssa>
jenatali: Ideally spec constants (or, ugh, the preprocessor) could be used for that
<jenatali>
That still... kinda sucks
<alyssa>
I mean.. maybe?
<alyssa>
IDK
<alyssa>
nir_builder excels at writing lowering passes, munging shaders, inserting little bits of code
<konstantin_>
RADV BVH building currently uses the preprocessor, I want to change it to spec constants in the future
<alyssa>
It's considerably less good at building entire shaders out of thin air
<alyssa>
which is... fine, honestly?
<alyssa>
I don't want a better nir_builder as much as I want to just write GLSL or CL C when I know I have a large (100s of lines) kernel that doesn't do anything an app wouldn't do
<alyssa>
the operator overloading sugar C++ provides would be nice for writing lowering passes I admit
<jenatali>
Yeah I was thinking of lowering
<konstantin_>
How would that work with a typeless IR?
<jenatali>
Or mini tini meta shaders that should be parameterized
<alyssa>
yeah. there are distinct use cases here
<jenatali>
konstantin_: Add type info just for determining what operators do
<alyssa>
The cases I have in mind are things like BVH building kernels
<alyssa>
where you fundamentally work on a different level of abstraction
<alyssa>
you don't care about the hw instructions or the SSA form or the phi nodes
<jenatali>
E.g. ssa_uint vs ssa_int vs ssa_float where you can cast freely between them
<alyssa>
or, ugh, the loops
<jenatali>
alyssa: Yeah makes sense
<alyssa>
NV_device_generated_commands is an excellent candidate for this
<alyssa>
although that's also kinda lowery
<alyssa>
ideally you could, like.. build a NIR "library" and then you have an easy lowering pass that just inlines the functions you care about
<alyssa>
I think the float64 lowering works like this already
<jenatali>
Yeah
<jenatali>
That's effectively what libclc is too
<alyssa>
right
<alyssa>
So the operative questions are:
<alyssa>
- OpenCL C or GLSL?
<alyssa>
- If GLSL, Mesa's compiler or GLSLang?
<alyssa>
- Single-source or separate files?
Company has joined #dri-devel
<jenatali>
Seems the answers can depend on the use case
<alyssa>
- Parametrizable? If so, how? Preprocessor or spec constants or something else?
<alyssa>
jenatali: Yeah, for sure. Which is why there are 4 different approaches in-tree already
<jenatali>
If I had infinite time I would honestly be interested in trying the c++ approach
<alyssa>
I don't hate it. But it doesn't solve the same problems
<jenatali>
Agreed
<alyssa>
Actually -- how about I list the use cases that I have in mind for this specifically
<alyssa>
- BVH building (duh)
<alyssa>
- NV_dgc
<alyssa>
- software tessellator (someday..?)
<alyssa>
- Maybe vk_meta
<alyssa>
One of the concrete problems I see is that... it would suboptimal to build-time depend on glslang for core parts of Mesa
Kayden has quit [Quit: office]
<alyssa>
however Mesa's own glsl compiler may not be a suitable replacement for Vulkan use cases
<alyssa>
I assume it doesn't recognize Vulkan-flavour GLSL because why would it? stuff like push constants
<alyssa>
I'm not too sure how much of a problem this is in practice
<alyssa>
Is a build-time (not runtime) dependency on glslang a real problem? Probably not? I mean, RADV already has that for raytracing so hopefully distros are used to it by now
<alyssa>
I don't think there are any portability issues there
<alyssa>
I don't think anyone loves glslang but also I don't think anyone loves the mesa glsl compiler ither
<jenatali>
Fwiw on Windows it would be a pain to depend on that
<jenatali>
So for common code I'd prefer to avoid it if possible
<alyssa>
Alrght
<alyssa>
That rules out vk_meta use
<alyssa>
There's a middle-ground option of having some common solution for driver use
<alyssa>
So as long as you don't build any drivers that use it you don't need the dep
<konstantin_>
Or we repurpose the GLSL compiler and store serialized NIR in the driver binary
<alyssa>
which should alleviate those concerns
<alyssa>
konstantin_: the problem with using Mesa's GLSL compiler is that Vulkan GLSL is a bit different and IDK how bad the impedance mismatch is going to be
<alyssa>
no push constants, no descriptor sets, etc..
<konstantin_>
Yeah, missing BDA support
<alyssa>
if you declare an SSBO in GLSL fed recognized by Mesa's GLSL compiler, it's going to give you load_ssbo intrinsics which is .. not what your Vulkan driver wants
<alyssa>
though maybe it's fine? maybe?
<mattst88>
anholt: are the groups of tests that deqp-runner makes deterministic?
fxkamd has quit []
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
<alyssa>
konstantin_: jenatali: I think maybe not supporting Vulkan GLSL might be ok
<alyssa>
In particular, it might be reasonable to write GL-style GLSL for the meta shaders
<jenatali>
Seems okay to me
rasterman has joined #dri-devel
<alyssa>
and then have an optional lowering pass to turn the reuslting GL NIR into Vulkan NIR
<alyssa>
with some simple mapping
<anholt>
mattst88: yes, for same input caselists / fraction / deqp-runner version, etc.
<alyssa>
(uniforms become push constants, each gl resource type gets a corresponding descriptor set with bindings matching the gl-side index, etc)
<alyssa>
doesn't help with BDA, though
cmichael has quit [Quit: Leaving]
<konstantin_>
Well at least for BVH building, we need BDA. So there is definitely some frontend work that needs to be done
<alyssa>
yeah, BDA is the big elephant in the room here
* alyssa
whinneys
<mattst88>
anholt: awesome, thanks
<alyssa>
If not for jenatali's windows comment I'd be tempting to promote RADV's BVH building infrastructure to common and call it a day
<konstantin_>
We don't have to support spec compliant Vulkan GLSL. There is potential to hack C-style pointer syntax into GLSL instead of the mess we have with build_helpers.h
<jenatali>
alyssa: I'm just one voice, I can be overridden
<anholt>
making glsl_compiler input some of vulkan sounds pretty reasonable to me, if we have existing syntax to follow.
<jenatali>
But also our driver would never use a common BVH builder
<jenatali>
Since that's the D3D driver's responsibility
<alyssa>
jenatali: Fair enough. But not being able to use this for common code might be annoying. IDK. Might be ok
<konstantin_>
dozen is not the only driver that can be build on Windows, right?
<pixelcluster>
radv can be built on windows too
<pixelcluster>
(although it's not very useful at the moment)
<alyssa>
anholt: it'd be reasonable if the glsl compiler weren't terrifying (-:
<konstantin_>
I smell an interesting/cursed project for the next month
<pixelcluster>
the 3rd one?
<konstantin_>
3rd?
<pixelcluster>
I mean I don't have a copy of your todo list
<pixelcluster>
maybe it's the second
<pixelcluster>
there's one I know of for sure :P
<alyssa>
konstantin_: my next interesting/cursed project is FEX-related, alas :p
<konstantin_>
BH, you're kind of right
<konstantin_>
*TBH
<jenatali>
For what it's worth, my concerns aren't really about myself, but about other contributors. I really like to be able to point our customers at the source and let them self-help. The setup instructions for GL are a bit of a pain (download flex/bison/pkgconfig/mako/meson). Instructions for CL are god-awful (build LLVM/Clang/LLVMSPIRVLib/libclc)
<jenatali>
Vulkan is pretty easy right now, just meson/mako. I'd be mildly frustrated if that had to get more complicated :)
<anholt>
alyssa: it's bad, but it's also so much smaller than it used to be.
<alyssa>
valid
<alyssa>
i don't think i've written any parsers since middle school
<alyssa>
("Weird flex?")
<anholt>
we use standard flex. ;)
<psykose>
what about lexers
<alyssa>
anholt: =D
<alyssa>
I walked right into that one damn
tango_ has quit [Ping timeout: 480 seconds]
<zf>
<Lynne> got a triangle to render! struggled a bit to find any vulkan 1.0 clients at all < fwiw, Wine has very lax vulkan requirements, if you're looking for test cases :-)
<zf>
and we certainly have a lot of test cases :D
<zf>
vkd3d as well, as a splinter project, and that might be a little friendlier to development
smaeul has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
Kayden has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
eukara has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
eukara has quit []
eukara has joined #dri-devel
junaid has quit [Remote host closed the connection]
JohnnyonFlame has joined #dri-devel
djbw has joined #dri-devel
idr has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
ngcortes has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
ondracka has joined #dri-devel
digetx has quit [Ping timeout: 480 seconds]
<austriancoder>
does anybody know if there is a deqp that tests the maximum number of varyings (GL_MAX_VARYING_FLOATS)? Something like piglits' glsl-max-varyings?
alyssa has quit [Quit: alyssa]
<everfree>
trying to update an out of tree module to 6.4. It's trying to call mutex_lock_interruptible on a dma_buf->lock, but its erroring because dma_buf doesn't have a "lock" member. Did something get moved around here in the kernel
<everfree>
im not 100% sure it ever compiled against a mainline kernel fwiw, i just found this thing, so if dma_buf.lock was like a vendor kernel extension w/e i can deal i guess
<everfree>
but the rest of it doesnt seem too vendor-kernely
digetx has joined #dri-devel
<everfree>
huh, friend found a kernel commit 28743e25fa1c867675bd8ff976eb92d4251f13a1 that suggests i can just... delete the lock/unlock, that its not used.
ondracka has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has quit [Ping timeout: 480 seconds]
<Company>
what's faster in GLSL: x < min (min (a, b), min (c, d)) or any (lessThan (vec4 (x, x, x, x), vec4 (a, b, c, d))
<Company>
and how interesting is it for performance to care about such things these days?
<anholt>
Company: if it helps you guess, all hardware these days breaks vectors down into scalars. so that probably compiles down similarly.
smiles_1111 has quit [Ping timeout: 480 seconds]
<Company>
so no need to pack stuff into vectors anymore
<pendingchaos>
the former is 3 min and 1 comparison, the latter is 4 comparisons and 3 boolean ops
<pendingchaos>
on AMD hardware, that's 4 standard cost VALU vs 4 standard cost VALU and 3 SALU
<pendingchaos>
otoh, the latter might have better ILP, because the 4 VALU are independent
agd5f has quit [Read error: Connection reset by peer]
agd5f has joined #dri-devel
ondracka has quit [Remote host closed the connection]
ondracka has joined #dri-devel
tango_ has joined #dri-devel
parellan has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
leo60228- has joined #dri-devel
leo60228 has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
ondracka has quit [Remote host closed the connection]
ondracka has joined #dri-devel
ondracka has quit [Remote host closed the connection]
ondracka has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit []
mvlad has quit [Remote host closed the connection]
ondracka has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
smaeul has quit [Ping timeout: 480 seconds]
smaeul has joined #dri-devel
<austriancoder>
finding the test source from a deqp name is challenging
tango_ has quit [Ping timeout: 480 seconds]
<pixelcluster>
had to find the deqp name from a test source once, that wasn't too fun either :3
tango_ has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
smaeul has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
crabbedhaloablut has quit []
Duke`` has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
alyssa has joined #dri-devel
uranus has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
digetx has quit [Ping timeout: 480 seconds]
digetx has joined #dri-devel
digetx has quit []
digetx has joined #dri-devel
<Lynne>
tried to find some extension I could help with on nvk, but everything's either handled already, handled by the vulkan framework, or would step on someone else's toes
Kayden has quit [Quit: home]
<karolherbst>
there is some performance work which is needed
<Lynne>
compiler-wise?
<karolherbst>
yeah
idr has quit [Quit: Leaving]
<karolherbst>
atm we use global memory for ubos, but we really should use ubos... but that's a bit... non trivial to deal with with the current compiler. Though one part could be to remove the descriptor indirection and promote some of those to direct ubo accesses
<karolherbst>
we have 8/16/18 slots available depending on the stage and generation
<Lynne>
speaking of buffers, what does a memory heap with zero flags mean?
dakr has quit [Remote host closed the connection]
dakr has joined #dri-devel
benjaminl has joined #dri-devel
uranus has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]