<tomeu>
which is basically what is in mesa's .gitlab-ci
<danvet>
yeah I thought this time around it's just a tad more so it's a bit more in everyone's face and hopefully force collaboration more on one way to do things
<airlied>
tomeu: nope daniels reply
<danvet>
but with the flap stuff still out of tree
<karolherbst>
how are texture variables usually kept, as nir_var_uniform or nir_var_image?
<karolherbst>
nir_validate complains if those are images, fair enough then
JohnnyonFlame has quit [Ping timeout: 480 seconds]
alarumbe has joined #dri-devel
<zmike>
uniform
kts has quit [Quit: Leaving]
<karolherbst>
mhh.. iris regresses in a few tests :/
<karolherbst>
but it still seems to work
<karolherbst>
at least luxmark still runs, so... (shipit.png)
fahien has joined #dri-devel
<Compy_>
Kind of a general question here: So I've got gstreamer leveraging hardware decoding (Allwinner H3 chip and a MALI400 based GPU). It's using KMSDRM (kmssink) and rendering fairly fluidly. However now I'm wondering if I can have overlay graphics (I usually use SDL2 to draw things) on top of the video. I've managed to keep most everything "headless" here and on a very small system. Curious: should I involve a compositor in
<Compy_>
the wayland ecosystem or potentially try to leverage DRM layering/different planes for the SDL2 stuff on top?
jewins has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<daniels>
Compy_: kmssink doesn't play well with overlays; even if it did, you'd have to essentially write your own scheduling compositor to merge the GStreamer and GPU content
<daniels>
so yeah, just use a Wayland compositor - that's exactly what they're designed to do, with low latency
<daniels>
+ overhead
<Compy_>
Perfect! That explains exactly why I wasn't finding much of anything on people that had pulled off overlays with a kmssink. Thanks for the feedback daniels. Wayland it is. I'll start with Weston and work from there.
fab has quit [Quit: fab]
fxkamd has joined #dri-devel
heat has joined #dri-devel
bmodem1 has joined #dri-devel
<daniels>
np, good luck!
gawin has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
yuq825 has left #dri-devel [#dri-devel]
kts has joined #dri-devel
srslypascal is now known as Guest3924
srslypascal has joined #dri-devel
Guest3924 has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
srslypascal is now known as Guest3926
srslypascal has joined #dri-devel
<karolherbst>
ahh well.. radeonsi totally doesn't like my new thing here :D
<kisak>
sergi: ^ if that's yours, please clean up / close your dangling merge request.
guru_ has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
<jekstrand>
dj-death: Context?
bgs has joined #dri-devel
Duke`` has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
kem has joined #dri-devel
apinheiro has joined #dri-devel
srslypascal is now known as Guest3929
srslypascal has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
Guest3929 has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
<karolherbst>
jekstrand: if I change the var_mode of a variable, is there a simple way to propagate that change through derefs using that?
<karolherbst>
I assume I have to rewrite everything though...
<jekstrand>
nir_fixup_deref_modes
<karolherbst>
problem is: if I convert readonly images to textures, I also have to move it to uniform
<karolherbst>
ohh
<karolherbst>
so it just fixes everything.. nice
<karolherbst>
except casts... mhh.. though that _might_ be fine here
<jekstrand>
Yeah, can't fix casts
<jekstrand>
Doesn't the read-only to texture pass already do this?
<karolherbst>
it doesn't
<jekstrand>
Oh. Right, I see that now. The variables version only smacks the type, it doesn't fix the mode.
<karolherbst>
ehh and now I hit the same issue I have with samplers as well in lower_explicit_io :(
<jekstrand>
Hrm... lower_explicit_io on nir_var_uniform is a bit sketchy
<karolherbst>
heh... deref_var aren't fixed but I also change the vars type :/
<jekstrand>
For that pass, I'd change the mode and type at the same time rather than using fixup_modes
<karolherbst>
yeah...
<karolherbst>
guess I'll need to do a bigger rewrite here
<jekstrand>
Yeah
gawin has joined #dri-devel
<jekstrand>
And maybe the pass should run vars-first when we're running on variables
<karolherbst>
I already have some fixups in that direction, just have to make that work with the var rewrite
<jekstrand>
Ugh... why does this pass use lower_instructions?!?
<jekstrand>
I'm starting to regret I made that helper
<karolherbst>
which one?
<karolherbst>
nir_lower_cl_images?
<jekstrand>
nir_shader_lower_instructions
<jekstrand>
People think it's the thing to use. 90% of the time, it's not.
<karolherbst>
no, I meant which pass uses it
<jekstrand>
readonly_images_to_tex
<karolherbst>
ahh
<jekstrand>
And I reviewed the change...
* jekstrand
reaches back through time and smacks younger jekstrand
<karolherbst>
:D
<karolherbst>
I can do the fix up there as I already have some of the code to translate those to textures..., but the problem is, we can't do it there, because we'll get a few txl/txf already anyway. Though we could check for those there...
<karolherbst>
heh wait...
djbw has joined #dri-devel
<karolherbst>
I might want to set per_variable to true, but that still wouldn't fix up everything
<karolherbst>
mhh
<jenatali>
Just FYI if you change the var modes I'll probably need to make a corresponding change, but I think that's fine, I'm pretty sure I change them already just in a different pass
<karolherbst>
yeah.... I think we should fix it all up inside nir_lower_readonly_images_to_tex
<karolherbst>
spirv_to_nir might give us tex ops with texture_derefs to images, but... we could just accept that and leat nir_lower_readonly_images_to_tex fix it
<karolherbst>
let me try that, heh
<karolherbst>
or let me set per_variable to true first and see what's actually not working then
<jekstrand>
karolherbst: We'll maybe need to add void sampler types to make this work
<karolherbst>
why?
<karolherbst>
iris is fine either way
<karolherbst>
and samplers will just stay pure samplers
<jekstrand>
The comment is a lie
<jekstrand>
pure samplers are pure samplers
<karolherbst>
yep.. works on iris as it seems
<karolherbst>
eheh wait
<karolherbst>
it didn't actually fix it
<jekstrand>
karolherbst: The problem is that we have no vsamplerND types. Just samplerND (float), isamplerND, and usamplerND.
<karolherbst>
we don't need them
<karolherbst>
we only need vtextureND
<jekstrand>
right
<karolherbst>
and we got those already
<karolherbst>
I have that all working on iris already, just need to make it more generic and also working for radeonsi
<karolherbst>
or maybe we should fix it on the spirv_to_nir level already...
<karolherbst>
txf/txs with images as texture_derefs does sound wrong
<jenatali>
You're doing this work at a good time, I'll actually have cycles to adapt our CL stack to it :)
<karolherbst>
yeah.. just not sure what's the solution we want to go for here :) I think using texture types is a strong yes here. That makes perfectly sense. Just do we want to fix it up with passes or make spirv_to_nir to actually do the right thing from the start?
<karolherbst>
it all feels a little inconsistent
<karolherbst>
mhh.. but then we have those image_deref_format/order ones pointing towards texture vars :(
<karolherbst>
(could add txs for that though)
<karolherbst>
uhm.. txq
<jekstrand>
karolherbst: I think having a lowering pass is fine
iive has joined #dri-devel
<jekstrand>
karolherbst: IDK how I feel about the format/order intrinsics. I think they're fine.
<jekstrand>
It's a bit odd to reference a texture from a non-texture thing but intrisics exist to make it easy to and random bits.
<karolherbst>
next question is.. should readonly lowering deal with all of that or should I fix it up inside lower_cl_images?
srslypascal is now known as Guest3931
<karolherbst>
kind of prefer the latter tbh
srslypascal has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
<karolherbst>
but maybe it's fine to do that in lower_readonly... will play around with that once I am done with meetings and dinner
sarahwalker has quit [Remote host closed the connection]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
<karolherbst>
yeah... would just need to have to add support for tex ops there and we'd be good to go
<karolherbst>
okay, cool
Guest3931 has quit [Ping timeout: 480 seconds]
<dj-death>
jekstrand: using vm_bind in iris
<jekstrand>
dj-death: Right.
fahien has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
frieder has quit [Remote host closed the connection]
<jekstrand>
dj-death: Effectively, we need to insert fences at every transition point but I thought Kayden and pzanoni had already mostly figured that out with their explicit sync work.
<jekstrand>
I don't see what that really has to do with vm_bind, though.
* zmike
smells sparse binding in the air
srslypascal is now known as Guest3934
srslypascal has joined #dri-devel
srslypascal is now known as Guest3935
srslypascal has joined #dri-devel
<jekstrand>
zmike: You'd like to think so
Guest3934 has quit [Ping timeout: 480 seconds]
<zmike>
I know it's just an illusion
Daanct12 is now known as Danct12
Guest3935 has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
vgpu-arthur has joined #dri-devel
gawin has quit [Quit: Konversation terminated!]
<pzanoni>
jekstrand: the context is that in the previous plan for vm_bind we could still rely on the Kernel's implict sync (i.e., submittting exec objects to execbuffer2) even with vm_bind. Although we implemented some synchronization for Iris, it did not cover 100% of the use cases, only the cases for non-shared buffers. But with the current proposed vm_bind API, Kernel implicit sync is completely gone since there's no way to pass exec objects to the Kernel,
<pzanoni>
and I was told your 2 new ioctls would cover the cases we need, but I am failing to understand how I should use them for the cases that they clearly should cover (when we have dmabuff stuff) and how we should cover the other cases where we're still relying on implicit sync and are not even using dmabuf
<jekstrand>
Right
<pzanoni>
jekstrand: the interface we have currently is that the Kernel wants drm_syncobjs passed to it, and it's still not clear to me how to do the whole conversion between dma-buf fds, dma-fence fds, drm-syncobj handles and fds, etc. I'm right now reading some IGTs
kts has quit [Quit: Leaving]
<karolherbst>
jekstrand: the builder isn't set up in your readonly rework
<dj-death>
jekstrand: there is an execbuf3 coming with vm_bind, and it's going to prevent the implicit sync
<jekstrand>
karolherbst: bah
<jekstrand>
karolherbst: Fixed
bmodem1 has quit [Ping timeout: 480 seconds]
devilhorns has quit []
jlawryno has joined #dri-devel
<karolherbst>
cool, doesn't crash anymore
idr has joined #dri-devel
srslypascal is now known as Guest3939
srslypascal has joined #dri-devel
Guest3939 has quit [Ping timeout: 480 seconds]
jlawryno has quit [Remote host closed the connection]
jlawryno has joined #dri-devel
<karolherbst>
uhh.. now I have to make iris look at the texture thing mhhh
<karolherbst>
though why did the sampler vanish
<jenatali>
Ugh... to get CL interop to work with wgl, I need to get at the extension functions from the GL driver, so I need to use wglGetProcAddress, but that doesn't work unless a context is current, which the CL interop spec doesn't guarantee
<karolherbst>
ahh yeah....
<jenatali>
Which I guess means I have to create a temp context, bind it, get the extension functions, and then restore the app's context if one was bound. So stupid
<karolherbst>
pure joy
<jenatali>
Now the question, do I pull in OpenGL-Registry to get the function prototypes, or do I just redeclare what I need...
<jekstrand>
CL<->GL interop is a mess
jlawryno has quit [Ping timeout: 480 seconds]
<jenatali>
Yes
<karolherbst>
mhh.. why does txs need a sampler?
<jenatali>
It goes the wrong way, exporting GL objects into CL
<jenatali>
EXT_external_objects is so much better, if only they added CL import for that
Akari has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
alyssa has joined #dri-devel
<alyssa>
karolherbst: txs does not require a sampler
<alyssa>
see the comment for sampler_index in nir.h
<alyssa>
there may be driver bugs, though
<karolherbst>
it was my bug :)
<alyssa>
sure
<alyssa>
jekstrand: When /is/ lower_instructions the right thing?
<dv_>
<MrCooper> dv_: with tiling, stride is generally defined as "<number of bytes between consecutive lines of tiles> / <tile height>"
<dv_>
so, for example, with 4x4 NV12 tiling, this would be 4*4*12/8 bytes per tile, in a 1080p display, there would be 1920/4 = 480 tiles in the horizontal direction, amounting to 4*4*12/8 * 480 bytes until the next line of tiles is reached
<dv_>
and this would mean (4*4*12/8 * 480) / 4 (the tile height) = 2880 as stride?
<airlied>
agd5f: why do you need non-compute command submit to move to using amdgfx api? wouldn't it be fine to just allow userspace compute submission for compute contexts?
<agd5f>
airlied, seemed like a good transition point.
<agd5f>
plus we had some new packets added to the firmware to deal with implicit sync
<airlied>
agd5f: is the plan to use userspace command submit for graphics?
<airlied>
would be nice to have documented solutions around things like how to make forward progress when two apps have 51% of VRAM allocated
mvlad has quit [Remote host closed the connection]
<karolherbst>
it's fine, we should fix all those validation issues anyway
<karolherbst>
there is a lot of code to upstream anyway
<airlied>
ah aco compiler asserts
<airlied>
not totally surprising
apinheiro has quit [Quit: Leaving]
<airlied>
it has never had a lot of compute paths thrown at it
<karolherbst>
and I think I'll prepare another MR to zink witha bunch of stuff we can probably just upstream already.. there is a bunch of stuff which look fairly straightforward
iive has quit [Quit: They came for me...]
karolherbst is now known as karolherbst_
karolherbst_ is now known as karolherbst
lanodan_ has quit [Ping timeout: 480 seconds]
<anholt>
idr: we use nir_opt_large_constants instead.
bbrezillon has quit [Ping timeout: 480 seconds]
<idr>
anholt: Yeah... Kayden reminded me about that, and about !16539.