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]
vyivel has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
paulie_ has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
junaid has quit []
junaid has joined #dri-devel
ondracka has joined #dri-devel
kts has joined #dri-devel
kugel is now known as Guest6522
kugel has joined #dri-devel
Guest6522 has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
smaeul has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
frieder has joined #dri-devel
kts has joined #dri-devel
fab has joined #dri-devel
apinheiro has quit [Quit: Leaving]
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #dri-devel
itoral has quit [Quit: Leaving]
Danct12 has quit [Quit: WeeChat 4.0.2]
alpalcone has joined #dri-devel
lplc has quit [Ping timeout: 480 seconds]
<zmike> mareko: do you have a branch with your linker wip somewhere? I want to see where it fits into the shader lifetime
OftenTimeConsuming has quit [Remote host closed the connection]
heat has joined #dri-devel
OftenTimeConsuming has joined #dri-devel
<mripard> daniels: \o/
<mripard> congrats
<daniels> mripard: thanks!
<mripard> (and congrats to everyone involved as well, obviously :))
<javierm> daniels: wow, huge news! Congrats to you and all folks involved :)
<MrCooper> what's this about?
<MrCooper> thanks
<daniels> javierm: thanks, but yeah, better directed at the ones doing the work :)
<MrCooper> nice indeed
rasterman has quit [Quit: Gettin' stinky!]
kts has quit [Quit: Konversation terminated!]
sgruszka has quit [Ping timeout: 480 seconds]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
Haaninjo has joined #dri-devel
Company has quit [Read error: Connection reset by peer]
kzd has joined #dri-devel
fxkamd has joined #dri-devel
<mareko> zmike: after varying linking and before uniform linking in the NIR linker of GLSL
<zmike> mareko: does running this yield store_output or is it expected that drivers are calling lower_io
<mareko> zmike: the linker calls nir_lower_io to lower store_deref to store_output, st/mesa and drivers only get store_output
<zmike> ahhh ok
<zmike> thanks
<mareko> zmike: the varying optimizer requires lowered IO, so the linker has to lower it
<zmike> right, I was expecting something like this but I wanted confirmation
yuq825 has quit []
<zmike> how is bindless texture io handled? e.g., passing nir_var_image in input/output
<mareko> bindless textures use 64-bit handles
<zmike> kinda?
<mareko> exactly
<zmike> on receiving them they're image types
<zmike> even if really they're 64bit ints
digetx has joined #dri-devel
kts has joined #dri-devel
<mareko> zmike: they are 64-bit numbers in NIR, and radeonsi uses the numbers to load descriptors
junaid has joined #dri-devel
<mareko> we literaly replace the 64-bit handle src with a vec4 or vec8 handle src containing the AMD image/sample/buffer descriptor
<mareko> *sampler
<zmike> I was talking about the variables, but I suppose they don't matter for explicit io
<mareko> bindless don't have variables
digetx has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<mareko> also GLSL has this tricky feaature that it can typecast a bindless handle to a variable and vice versa
<mareko> we don't implement the typecasting in radeonsi
<mareko> or maybe it can only do the typecast from a variable to a bindless handle, not vice versa
digetx has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
donaldrobson has quit [Remote host closed the connection]
<zmike> yeah there's piglit tests for that
<zmike> which is what I was referencing
<zmike> my memory is fuzzy but I expect I'll re-remember most of it in a day or two since I'm attempting an explicit io conversation
<zmike> conversion
ondracka has quit [Ping timeout: 480 seconds]
<mareko> radeonsi still uses derefs for textures and images
aravind has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
<alyssa> hey NIR people, get excited :3
<jenatali> alyssa: I'm excited
<jenatali> zmike: :O good luck
<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
OftenTimeConsuming has joined #dri-devel
<zmike> if you are a gallium driver owner and haven't signed off on the great vertex stride move of '23 (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24117) pls click and review
ondracka has joined #dri-devel
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]
Jeremy_Rand_Talos__ has joined #dri-devel
pcercuei has quit [Quit: dodo]