ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
hch12907 has quit [Ping timeout: 480 seconds]
pendingchaos has quit [Read error: No route to host]
pendingchaos has joined #dri-devel
hch12907 has joined #dri-devel
tarceri has quit [Remote host closed the connection]
hch12907_ has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
tursulin has quit [Read error: Connection reset by peer]
lemonzest has quit [Ping timeout: 480 seconds]
Lucretia-backup has joined #dri-devel
Lucretia has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
<jekstrand> FLHerne: I intended no such implications.
<FLHerne> Yeah, but if you were under an Intel NDA you'd say that
<FLHerne> or indeed if you were being blackmailed by the mole people to deny it
<imirkin> jekstrand: so what happened to the IGC effort then?
<imirkin> did they say "oh yeah, nevermind, we were wrong"? seems unlikely :)
mszyprow_ has quit [Ping timeout: 480 seconds]
<jekstrand> The IGC stuff has quieted down last I knew.
<jekstrand> But I really can't comment on what will happen. I'm not there anymore.
pcercuei has quit [Quit: dodo]
<jekstrand> I am, however, now in a position to NAK stupid patches should someone decide to send them. :)
<imirkin> hehe
<jenatali> jekstrand: I didn't realize the 64-as-32 lowering was *part* of nir_lower_io. Looks like I'll still have to fix up variables myself to be able to generate valid DXIL signatures
<imirkin> anholt: library ABIs on android are definitely for chumps...
iive has quit []
elongbug has quit [Read error: Connection reset by peer]
ybogdano has quit [Ping timeout: 480 seconds]
<jekstrand> jenatali: Ugh... Why does everyone keep needing varibles? :-(
<jenatali> Yeah, I like having the lowered io intrinsics instead of derefs, but DXIL requires signatures, which... well, look a lot like NIR variables
<jenatali> jekstrand: Unless you can think of a good way to deduce signatures from nir shader info or intrinsics :P but I think that'd be hard
rasterman has quit [Quit: Gettin' stinky!]
<jekstrand> jenatali: Yeah...
co1umbarius has joined #dri-devel
<jekstrand> jenatali: Writing a pass that does it on variables instead of on-the-fly would totally be possible, I guess.
danvet has quit [Ping timeout: 480 seconds]
columbarius has quit [Ping timeout: 480 seconds]
<jenatali> jekstrand: Yeah, doesn't even need to be instead, can just be after
<jenatali> As long as it computes the same registers and stuff
<jenatali> Eh maybe for my case it does need to be instead
<jekstrand> Do you actually want variables and derefs or do you just want what slots are filled and, in the PS, interpolation modes?
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
sdutt has quit [Ping timeout: 480 seconds]
boistordu has quit [Remote host closed the connection]
boistordu has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
orbea has quit [Read error: Connection reset by peer]
reductum has quit [Quit: WeeChat 2.8]
macromorgan has quit [Quit: Leaving]
orbea has joined #dri-devel
<jenatali> I need slots, which components, interpolations, I think types? And names don't hurt
<jenatali> And streams, and... yeah basically all the stuff in variable data. I don't need derefs to them, as long as the intrinsics in the shader line up, but I do kinda need the separations that the variables provide
<imirkin> jenatali: out of curiousity ... why not just make everything single-component?
<imirkin> or does that have downsides?
<jenatali> Uh... good question
<imirkin> gpu's of yore cared about vec4's
<imirkin> but at least all DX10+ nvidia chips couldn't care less
<anholt> jenatali: are you sure lowered intrinsics don't have all you need in the i/o semantics?
<jenatali> Oh, lowered io will do loads/stores of vec4s. That'll break unless the corresponding signature also declares the vec4s
<jenatali> anholt: I need, at the shader level, a list of which "registers" are used and what they are
<jenatali> I might be able to gather that out of I/O semantics but that's basically just reconstructing variables
<imirkin> jenatali: you can break up any load/stores
<jenatali> Hm, I suppose
<jenatali> I wonder if that'd be simpler
<jenatali> So far I've been trying to produce "canonical" IL but since it is just IL I don't know how much that really matters...
<imirkin> hope i'm not leading you down a path to a dead end :)
* jenatali shrugs
<imirkin> hrmph ... is there a way to get meson to build tests in native arch?
<imirkin> i guess that's a pain for the build system. but also for me :)
sdutt has joined #dri-devel
Company has quit [Quit: Leaving]
<jenatali> imirkin: thinking about it more, I think that would break xfb at least
<imirkin> how so?
<imirkin> enhanced layouts-like functionality should be able to fix it all up
<imirkin> essentially do the equivalent of layout(slot=X, component=Y) float asdf;
<jenatali> Hm, I might be able to make that work
macromorgan has joined #dri-devel
macromorgan has quit []
macromorgan has joined #dri-devel
macromorgan is now known as Guest967
macromorgan has joined #dri-devel
Guest967 has quit []
<imirkin> dcbaker: i'm getting "ERROR: Can not run test applications in this cross environment." when setting an exe_wrapper. looking at the meson code that triggers this, it seems to only happen when exe_wrapper is None. but it only triggers via meson.build if exe_wrapper is set, so ... weird. (it's the have_mtls_dialect detection)
mattrope has quit [Read error: Connection reset by peer]
<imirkin> dcbaker: when i add some bits to skip that logic, it does seem to work ok and i can do 'ninja test' just fine
<imirkin> dcbaker: is cc.run not the right thing to do?
<imirkin> (fwiw this is with meson 0.59.4)
anholt has quit [Remote host closed the connection]
anholt has joined #dri-devel
reductum has joined #dri-devel
Duke`` has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
mszyprow_ has joined #dri-devel
Company has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
tango_ is now known as Guest989
tango_ has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
Guest989 has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
heat has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Daanct12 has quit [Quit: Quitting]
gouchi has joined #dri-devel
sravn has joined #dri-devel
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
lemonzest has joined #dri-devel
pcercuei has joined #dri-devel
bnieuwenhuizen has joined #dri-devel
danvet has joined #dri-devel
gouchi has quit [Remote host closed the connection]
mlankhorst has quit [Ping timeout: 480 seconds]
i-garrison has quit []
mszyprow_ has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
mszyprow_ has quit [Ping timeout: 480 seconds]
bgs has quit [Ping timeout: 480 seconds]
bgs has joined #dri-devel
Duke`` has joined #dri-devel
mlankhorst has joined #dri-devel
mszyprow_ has joined #dri-devel
jkqxz has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
mszyprow_ has joined #dri-devel
Haaninjo has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
mszyprow_ has quit [Ping timeout: 480 seconds]
<graphitemaster> Why does the GL spec not list GL_OUT_OF_MEMORY as an error for glTextureStorage
<graphitemaster> It does for glBufferStorage
ppascher has quit [Remote host closed the connection]
join_subline has quit [Remote host closed the connection]
<imirkin> graphitemaster: every command can return those
<imirkin> graphitemaster: i suspect glDelete* can return them
nchery has joined #dri-devel
nchery has quit []
jn has joined #dri-devel
gouchi has joined #dri-devel
luckyxxl has joined #dri-devel
Danct12 has joined #dri-devel
ppascher has joined #dri-devel
join_subline has joined #dri-devel
karolherbst has quit [Remote host closed the connection]
fxkamd has quit []
karolherbst has joined #dri-devel
mlankhorst has joined #dri-devel
<cheako> My random FPS glitch takes all the fun out of playing. I played a little after getting a good role on FPS, but then I switched game modes and had to role again... The game crashed during this and I quit for now.
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
sdutt has joined #dri-devel
alyssa has joined #dri-devel
<alyssa> jekstrand: Mali has an instruction which does bitselect() directly (MUX.i32.bit).. thoughts on adding a nir_bitselect and replacing the builtin builder with lower_alu?
<alyssa> ("Trying to nerdsnipe jekstrand into OpenCL Mali are we?")
<alyssa> Also has native indirect branches and function call stuff and .... great platform to bring up clover ;-)
<imirkin> indirect branches are all well and good ... but how to RA
<alyssa> don't worry about it
<imirkin> YOLO
bluebugs has quit [Remote host closed the connection]
anholt has quit [Ping timeout: 480 seconds]
bluebugs has joined #dri-devel
Peste_Bubonica has joined #dri-devel
Peste_Bubonica has quit []
<karolherbst> imirkin, alyssa: yeah.. I guess we need some kind of "function ABI thing" for those cases... we already hit this issue with lightmark where kernels are soooooo huge that we just can't handle them like that
<karolherbst> although backend compilers might be more suited for this kind of stuff
<ccr> ... in Ian Fleming's "You only register allocate twice"
anholt has joined #dri-devel
<cphealy> When running Mesa, what decides which DRI driver should be used? Specifically, in /usr/lib/dri I have panfrost_dri.so and swrast_dri.so. For some reason swrast_dri.so is being used by the GLES application instead of panfrost_dri.so and I'm not sure why.
<kisak> probably the wrong line of thought, but maybe LIBGL_ALWAYS_SOFTWARE=true is set?
rasterman has joined #dri-devel
<cphealy> kisak: nope, that's not it.
<ccr> perhaps you just need to force it? I've no idea how Arm world works (I assume this is Arm because panfrost?) and there's unlikely to be PCI based detection .. perhaps alyssa can tell us how it is done? :)
mclasen has joined #dri-devel
<cphealy> I'm not aware that there is a way to force it.
<ccr> MESA_LOADER_DRIVER_OVERRIDE=panfrost ? *shrug*
<ccr> sorry, just rambling without any real knowledge.
<soreau> if panfrost_dri.so is the wrong arch, or created with `touch panfrost_dri.so`, it might not work
jekstrand is now known as Guest1044
<jekstrand> alyssa: I think Intel has a bitselect as well. I'd be fine with adding a NIR op.
<imirkin> cphealy: there's a loader, and it looks around to see what it has
<imirkin> cphealy: mostly, it looks at sysfs. you can run 'strace -f -e file' to see what files it's looking at
<imirkin> cphealy: you can also run with LIBGL_DEBUG=verbose which will print some more stuff abou tits decisions
lyudess has joined #dri-devel
Lyude has quit [Ping timeout: 480 seconds]
<pendingchaos> jekstrand: alyssa: nir_op_bitfield_select?
<pendingchaos> (I think that op already exists)
sagar__ has quit [Remote host closed the connection]
sagar__ has joined #dri-devel
lyudess has quit []
<alyssa> pendingchaos: seems plausible
<alyssa> this is the (a & c) | (b & ~c) op
Lyude has joined #dri-devel
<jekstrand> Looks like we just need to add lowering and wire up the SPIR-V differently.
<alyssa> ah nice
<alyssa> cphealy: Is your GPU supproted by the panfrost build?
<alyssa> if the GPU ID isn't recognized we silently bail
<alyssa> build the latest upstream/main
<alyssa> and if you need to add an ID, it's a 1 line change only
<cphealy> I actually just figured it out. It was a sandboxing config issue that prevented the GPU from being accessible... :-(
<alyssa> in src/panfrost/lib/pan_props.c
<alyssa> ah booo
<cphealy> yea
<cphealy> On the upside, PF is now working seemingly fne.
<cphealy> fine
<mattst88> jekstrand: I love your "In Defense of NIR" article! thank you for writing that
<mattst88> jekstrand: it would be nice if your articles had a date somewhere on them
<alyssa> mattst88: you didn't hear? timeless articles are all the rage among the kids :-p
<mattst88> heh
<imirkin> "best thing of 2020" last updated 2022.
maxzor has joined #dri-devel
mareko has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
* alyssa thought it was still 2019
<imirkin> alyssa: because nothing has dates on it anymore?
<Sachiel> the only part of the date that matters anymore is the day: workday, notworkday
mclasen has quit [Ping timeout: 480 seconds]
<HdkR> I wonder when my next notworkday is going to happen. It's still 2019 and every day is a workday
<Sachiel> you have to carve those out for yourself
<imirkin> get a knife.
<imirkin> tell your boss you want to carve something out ... preferably vacation days :)
<HdkR> Self inflicted pain is frowned upon :P
<imirkin> like i said, the _preference_ is vacation days
<imirkin> but all options are to be considered
<maxzor> Excuse me for interfering in your chill discussion :) What do you think of ROCm? Is there current open development for interop between Mesa graphics (OpenGL and Vulkan) and AMD ROCm compute? How does opencl implentations compare between the two? That's a lot of general questions.
mclasen has joined #dri-devel
<imirkin> maxzor: mesa's opencl impl is, for end-users, non-existent
<imirkin> afaik there are various exts for opencl interop which work at least with radeonsi? not sure.
<imirkin> mostly you just use EGL to import the resources
<maxzor> Isn't EGL just to retrieve an opengl context? Is there intra-GPU interop? I have a hard-time finding a definition of interop, much worse a standard
<imirkin> maxzor: depending on the direction that you want things to flow in
<imirkin> e.g. clCreateFromGLRenderbuffer
<maxzor> If there is a vulkan texture on a shader engine, can a hip/opencl compute kernel being on the same shader engine interact with the texture without going through host memory?
<imirkin> sure
<imirkin> maxzor: clCreateFromGLTexture
jn has left #dri-devel [#dri-devel]
eukara has quit [Read error: Connection reset by peer]
eukara has joined #dri-devel
mlankhorst has joined #dri-devel
<graphitemaster> Is there really no bitCount for GL_ARB_gpu_shader_int64
<HdkR> Just two two 32-bit bitcounts :)
<HdkR> do two
<graphitemaster> pm = unpackUint2x32(ballotARB(digit == 4) & gl_SubGroupLtMaskARB); bitCount(pm.x) + bitCount(pm.y);
<graphitemaster> Yall really want me to do that huh
<jekstrand> Sure.
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #dri-devel
<jekstrand> That's what we do if we got a 64-bit bit count.
<jekstrand> Well, depends on hardware, I guess.
<jekstrand> But also, it's an easy enough optimization to turn it into one if you've got the hardware.
<jekstrand> But also, not having it is stupid
<graphitemaster> There's holes everywhere.
<HdkR> Matches the hardware implementations perfectly then :)
<graphitemaster> Like Swiss cheese
gouchi has quit [Remote host closed the connection]
<imirkin> is there hw with 64-bit bitcount?
<HdkR> I can only hope some random Intel GPU supports it
Duke`` has quit [Ping timeout: 480 seconds]
<graphitemaster> Intel always seems to have the strangest things
<graphitemaster> Like they have conservative rendering when AMD does not
<graphitemaster> They have a massive push constant area unlike any of the big vendors.
<graphitemaster> To the point I actually think on Intel I'll never need a UBO
<graphitemaster> They actually do geometry shaders efficiently and I cannot for the life of me figure out why.
danvet has quit [Ping timeout: 480 seconds]
<graphitemaster> But Intel graphics are really mid tier stuff yet they have all this stuff that I'd classify as high end hardware stuff that the highend hardware does not have.
gawin has joined #dri-devel
gawin has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
mclasen has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
mszyprow_ has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
luckyxxl has quit [Quit: bye]
gawin has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
<alyssa> I figure some random Mali has it ;-p
<alyssa> I think midgard would've had it but with an erratum making it useless
<alyssa> (IIRC something screwy with sign extensions)
gawin has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
jewins has joined #dri-devel
<karolherbst> graphitemaster: well.. intel isn't really known for their simplicity in hardware, are they? :P