ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<zmike> texture whats
<karolherbst> texture vars
<karolherbst> that image -> texture stuff I was talking about above
<zmike> I need ints for everything texture related
<zmike> and derefs for images
<karolherbst> okay
<karolherbst> guess I'll need to figure that out, but should be trivial
<zmike> just find the right code to copy:p
<karolherbst> yeah. MS has a lowering pass to convert image vars to texture ones :)
<karolherbst> but I need to do it before I do IO lowering
<zmike> I believe in you
heat has quit [Ping timeout: 480 seconds]
<jenatali> karolherbst: I'm pretty close on writing up interop - still all untested though
<karolherbst> cool
<zmike> jenatali: I believe in you too
<karolherbst> are there actual real world test cases for that or just the CTS?
<karolherbst> I mean.. besides davinci resolve which needs other exts on top
<jenatali> I told you, DaVinci Resolve
<jenatali> Oh I have no idea :)
<karolherbst> me neither :)
The_Company has quit []
<jenatali> Hopefully tomorrow I'll have written enough to actually start testing it
<karolherbst> .. there is a bug on intels CL thing about users needing it, but of course they don't say which application :(
<jenatali> That's the worst
<karolherbst> "my app" yes, thanks for your input
<illwieckz> “So many video applications require the OpenCL and OpenGL interop” 👀️
<jenatali> But it's the most important app!
<karolherbst> "Any news on that ? This extension is really a must have for many applications."
<karolherbst> "cl_khr_gl_msaa_sharing" fun...
<karolherbst> ohhh.. I might have an idea
<karolherbst> though it's mostly lwjgl
<karolherbst> opencv.. interesting
yuq825 has joined #dri-devel
<illwieckz> that search engine isn't really convenient
<karolherbst> it's not, but better than nothing
<illwieckz> it would be cool to just have a collapsed list of repositories using the keyword
<illwieckz> then you uncollapse to get the files and forks
<karolherbst> maybe.. but most of them reference it because they bundle lwjgl...
<karolherbst> yeah...
<illwieckz> I thought searching for commits would be more helpful but they are all about libraries https://github.com/search?l=OpenCL&q=cl_khr_gl_sharing&type=commits
<illwieckz> this UI should deduplicate commits with same id
<karolherbst> I am sure we could use the API and do something filtering...
<karolherbst> lol
<illwieckz> it's more a search engine for forks than other things
co1umbarius has joined #dri-devel
<illwieckz> I then thought about looking for wiki, thinking wiki are hand-written… but wiki are cloned with repos XD
<illwieckz> so, same noise
<illwieckz> opencv everywhere
columbarius has quit [Ping timeout: 480 seconds]
ngcortes_ has joined #dri-devel
Surkow|laptop has quit [Ping timeout: 480 seconds]
bbrezillon has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
ngcortes_ has quit []
ngcortes has joined #dri-devel
bbrezillon has joined #dri-devel
Surkow|laptop has joined #dri-devel
Kayden has quit [Quit: home]
pendingchaos has quit [Ping timeout: 480 seconds]
egbert has quit [Ping timeout: 480 seconds]
jewins1 has quit [Ping timeout: 480 seconds]
sarnex_ has joined #dri-devel
slattann has joined #dri-devel
david_ has quit [Remote host closed the connection]
david has joined #dri-devel
sarnex has quit [Ping timeout: 480 seconds]
sarnex_ has quit []
sarnex has joined #dri-devel
vliaskov_ has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
pendingchaos has joined #dri-devel
egbert has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
david has quit []
<airlied> yay a mesa build with no opaque ptr api warnings
kem has joined #dri-devel
<zmike> \o/
ppascher has joined #dri-devel
jewins has joined #dri-devel
Sachiel has quit [Quit: WeeChat 3.5]
aravind has joined #dri-devel
Sachiel has joined #dri-devel
* airlied finds the first nir pass busted with functions, lower bool to 32 :)
<airlied> dang blows up in llvm backend now
kem has quit [Ping timeout: 480 seconds]
idr has quit [Quit: Leaving]
kem has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
lemonzest has joined #dri-devel
Duke`` has joined #dri-devel
Kayden has joined #dri-devel
l554 has joined #dri-devel
l554 has left #dri-devel [#dri-devel]
Duke`` has quit []
bgs has joined #dri-devel
itoral has joined #dri-devel
kisak has quit [Ping timeout: 480 seconds]
itoral_ has joined #dri-devel
Duke`` has joined #dri-devel
itoral has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
ngcortes has quit [Quit: Leaving]
bgs has quit [Remote host closed the connection]
<airlied> karolherbst: how do samplers as function parameters work?
<airlied> barriers are the other nightmare
kts has joined #dri-devel
<dj-death> anybody gave a thought about how to use the implicit sync stuff that jekstrand did in vulkan?
<dj-death> the import/export of sync_fds on the dma-bufs
jewins has quit [Ping timeout: 480 seconds]
<HdkR> "DisplayPort or USB-C monitor is not supported on the ThunderboltTM 4 Type-C Ports" Frickin backstabbed by JHL8540
danvet has joined #dri-devel
<airlied> karolherbst: my llvmpipe-cl-funcs branch is updated, the basics work, luxmark doesn't
OftenTimeConsuming is now known as Guest3901
OftenTimeConsuming has joined #dri-devel
Guest3901 has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
bmodem has quit []
bmodem has joined #dri-devel
bmodem has quit []
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
bmodem has joined #dri-devel
frieder has joined #dri-devel
lynxeye has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
tzimmermann has joined #dri-devel
kisak has joined #dri-devel
fab has joined #dri-devel
<tomeu> airlied: danvet: so, do you have any remaining concerns about the drm-ci series? https://patchwork.freedesktop.org/patch/502641/
<danvet> I think good to go and forward in a pull request to linus next merge window
<danvet> I guess it's a bit too late this time around :-)
<danvet> airlied, should we give linus a heads up? or just make sure he has that topic pull early?
<airlied> tomeu: did you address daniels concerns in the last posting?
* airlied is kinda wondering why we are putting all of it in-tree
<airlied> particularly around the lab is up, lab is offline type scenarios we hit with mesa the whole time
* airlied can't really justify a git changelog full of lab up/down commits
<tomeu> airlied: daniels' concerns? you mean danvet's?
<tomeu> airlied: so, most of the scripts remain in https://gitlab.freedesktop.org/gfx-ci/drm-ci/
<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
<tomeu> and regarding lab up/down, that is in a separate repo just because of what you said: https://gitlab.freedesktop.org/gfx-ci/lab-status
<airlied> oh cool, I just read daniels post and way awaiting clarification
<danvet> airlied, daniels' point is kinda exactly why I think we should have it in-tree
<danvet> because we have these bazillions of trees, if it's out-of-tree completely every tree will cook up their own stuff
<danvet> but if at least the corner stone is in-tree, we force them a lot more to converge
<danvet> but yeah there is the downside that it takes a tad longer for stuff to got around, in some cases at least
<danvet> but that's kinda what the external repo is for, when needed
<tomeu> hrm, it must have fallen prey of my boss spam filter
<tomeu> I think daniels missed the part when I say that the files included in v8 are those _specific_ to kernel testing
<airlied> ah well if we have things split appropriately so the day-to-day stuff is external and I only see results etc
<tomeu> all the stuff we take from mesa remains out of tree
<airlied> then I'm happy to give it a spin
<danvet> airlied, we probably don't have it perfectly split, but that's kinda what needs to be figured out as we go :-)
<danvet> that entire "what should be in/out of tree" question is probably one we need to highlight with linus
<danvet> and warn him that we might need to move a bunch of files in/out depending how badly we got it wrong
<tomeu> TBH, Mesa doesn't have _everything_ in-tree, because it depends on debian, external git repos, pipi, etc
<danvet> tomeu, also maybe update the commit log, since atm it's not making it super clear that there is this split
<airlied> yeah I've warned him we were experimenting before, so happy to play around and see how much trouble we can get in
<tomeu> it just draws the line in a different place because some other trade offs are made
<tomeu> danvet: point taken
<airlied> yeah I just want to minimise the amount of patches for day-to-day operation in the tree
<danvet> "move all the files" sounds at least like it's truly everything
<danvet> also for daniels concern of "make sure people get it asap"
<danvet> that's what drm-tip (instantenous, if people don't screw it up) and linux-next (1d delay) are for
<danvet> so maybe we should make sure that ci stuff after the initial pull goes in through drm-misc to make sure everyone gets it asap?
<danvet> airlied, ^^ so like topic branch in drm.git for the initial pile and then drm-misc or so
rasterman has joined #dri-devel
<danvet> also the topic branch in linux-next for a while to make sure
fab has quit [Quit: fab]
<danvet> in mesa it's also not instantenous, or at least not automatic
<danvet> because if you based your personal repo branch off the wrong thing also have to rebase first
<danvet> wrong as in broken
jlawryno has joined #dri-devel
<airlied> danvet: yeah a topic to land, I wonder if it would be a good thing as an ongoing topic
<airlied> but not sure it would make much sense
<danvet> airlied, I guess we could offer the ongoing topic to linus
<danvet> if he's too concerned about the history
fab has joined #dri-devel
<danvet> but as long as we keep the lab flapping out, I think it should be fine
<danvet> airlied, the trouble with ongoing topic is that the result files really need to be updated together with fixes
<danvet> so for those the ongoing topic really doesn't work that well
<danvet> I typed up some reply to daniels
rgallaispou has quit [Remote host closed the connection]
<daniels> heh yeah, I agree with your reply at least
<daniels> so I guess let’s go for it and find out
nchery has joined #dri-devel
apinheiro has joined #dri-devel
krushia has quit [Quit: Konversation terminated!]
krushia has joined #dri-devel
mvlad has joined #dri-devel
sarahwalker has joined #dri-devel
sarahwalker has quit [Read error: Connection reset by peer]
jkrzyszt has quit [Remote host closed the connection]
tursulin has joined #dri-devel
chipxxx has quit [Read error: Connection reset by peer]
ahajda has joined #dri-devel
chipxxx has joined #dri-devel
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #dri-devel
JohnnyonFlame has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
srslypascal has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
jkrzyszt has joined #dri-devel
macromorgan has quit [Ping timeout: 480 seconds]
slattann has quit []
sarahwalker has joined #dri-devel
fab has quit [Quit: fab]
Akari has quit [Ping timeout: 480 seconds]
jlawryno has quit [Remote host closed the connection]
jlawryno has joined #dri-devel
srslypascal has joined #dri-devel
Nirvin[m] has joined #dri-devel
kts has joined #dri-devel
MrCooper_ has joined #dri-devel
MrCooper has quit [Ping timeout: 480 seconds]
<karolherbst> airlied: they don't
<karolherbst> or at least probably don't
<karolherbst> I'll probably still inline a lot in the first step and just keep function calls into libclc
<karolherbst> could think about having "library CSOs" or something in the future and then we do object linking, but not sure yet
bmodem1 has joined #dri-devel
jlawryno has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
devilhorns has joined #dri-devel
MrCooper_ has quit [Ping timeout: 480 seconds]
chipxxx has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
<airlied> karolherbst: spirv gives hints from clang which i assume we are expected to use
<karolherbst> yeah.. at some point
<airlied> my branch does all that fine already
Lucretia has quit []
<karolherbst> but we'd have to figure out how to properly deal with derefs and all that kind of fun stuff
Lucretia has joined #dri-devel
<airlied> just cant handle sampler derefs and barriers
<airlied> though i think inlining toplevel fns might make most tests pass
<airlied> i might consjder if you see a barrier, inline it all
<karolherbst> thing is, when I played around with some of it and postponed inlining to the very last moment, performance was tanking a lot :/
<karolherbst> but that might be only because the way we do function calls in nir
<airlied> why inline at last moment?
<karolherbst> it was just as a test
<airlied> ah
<karolherbst> wanted to fix nir passes
<airlied> the only pass i found that blew up was bool to int32, so you must have gotten a few
<karolherbst> a few of the fixes should be upstreamed already, but I didn't check the entire CTS with that
<airlied> i might know how to get debuginfo into the jit code, but its a big task
<karolherbst> yeah...
<airlied> but will make tracing the fn stack easier
<airlied> have to manually write llvm debuginfo metadata
<karolherbst> I have to see how much time I actually have for all the fun stuff today :/
fab has joined #dri-devel
jlawryno has joined #dri-devel
bmodem1 has quit []
bmodem has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
macromorgan has joined #dri-devel
srslypascal is now known as Guest3914
srslypascal has joined #dri-devel
Guest3914 has quit [Ping timeout: 480 seconds]
itoral_ has quit [Remote host closed the connection]
JohnnyonFlame has joined #dri-devel
Company has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
jlawryno has quit [Ping timeout: 480 seconds]
bmodem1 has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
bmodem has joined #dri-devel
bmodem1 has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
Akari has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
<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
Guest3926 has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
mszyprow has joined #dri-devel
<kisak> sergi-bot? This doesn't seem human-generated https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19299
Namarrgon has quit [Quit: WeeChat 3.7]
Namarrgon has joined #dri-devel
<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> yeah
<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?
<karolherbst> it's actually not as horrible as I thought it would be
<alyssa> It is seemingly always more lines to use, though it is a little more structured and simpler code
<karolherbst> ehh.. 1d buffer regressed.. should be easy to fix though
mszyprow has quit [Ping timeout: 480 seconds]
<javierm> mripard: there's a new cmdline option now in my arm troubleshoosting toolbox: "deferred_probe_timeout="
<javierm> I wasn't aware that probe deferral was time bounded nowadays
ybogdano has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
ngcortes has joined #dri-devel
guru_ has quit [Remote host closed the connection]
fahien has quit []
tzimmermann has quit [Quit: Leaving]
ybogdano has joined #dri-devel
oneforall2 has joined #dri-devel
Akari has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<karolherbst> I'd really like to merge this MR, but don't feel comfortable doing it without reviews from AMD folks: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18581
Haaninjo has joined #dri-devel
<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> uhh... I just found an evil bug in glsl_types: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/compiler/glsl_types.cpp#L1053
<karolherbst> :(
<karolherbst> needs to be vtextureBuffer_type
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #dri-devel
JohnnyonFlame has joined #dri-devel
ybogdano has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
<jenatali> karolherbst: oops, my bad (I think)
<karolherbst> now I have to get radeonsi working :)
<karolherbst> but seems like the change isn't terrible, so we might be able to merge it easily
Duke`` has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
bgs has quit [Remote host closed the connection]
jkrzyszt has quit [Ping timeout: 480 seconds]
<karolherbst> okay.. radeonsi is fixed as well. Only have to check llvmpipe and then I'll rebase all the zink stuff
fab has quit [Quit: fab]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
ybogdano is now known as Guest3953
ybogdano has joined #dri-devel
Guest3953 has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
<agd5f> airlied, yeah, that's the plan.
mmind00 has quit [Remote host closed the connection]
mmind00 has joined #dri-devel
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<karolherbst> ehh "SPIR-V id 262165 is out-of-bounds" rude
rasterman has quit [Quit: Gettin' stinky!]
danvet has quit [Ping timeout: 480 seconds]
columbarius has quit [Read error: Connection reset by peer]
CME_ has joined #dri-devel
CME has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
<karolherbst> zmike: I think you want to get that in asap unless you are fine with broken spec constants :) https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19310
alyssa has left #dri-devel [#dri-devel]
<karolherbst> not sure if that's caused by some other random changes on my rusticl/zink branch though
<karolherbst> zmike: anyway.. pushed all my texture rework stuff to rusticl/zink
<karolherbst> a few new crashes but that's to be expected I guess
<zmike> hm I think this is only triggered in rusticl
<karolherbst> well variable local sizes would trigger it on the GL side
<karolherbst> I think?
<zmike> there's piglit tests for that which get run by ci
<karolherbst> odd
<karolherbst> the corruption is though that the type is created after the spec constants was started to get built
<karolherbst> so you get a weirdo spir-v
<zmike> yes I see
<karolherbst> maybe gl lucks out
<zmike> it only occurs if the type was first instantiated here
<zmike> in gl that probably isn't the case somehow
<karolherbst> yeah
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
warpme___ has quit []
mszyprow has quit [Ping timeout: 480 seconds]
gbelgurr has quit [Remote host closed the connection]
gbelgurr has joined #dri-devel
anarsoul has quit [Quit: ZNC 1.8.2 - https://znc.in]
anarsoul has joined #dri-devel
jljusten_ has joined #dri-devel
jljusten has quit [Ping timeout: 480 seconds]
jljusten_ has quit []
jljusten has joined #dri-devel
ybogdano has quit [Ping timeout: 481 seconds]
<karolherbst> wow... radv actually validates all spir-vs and I am a little surprised: Pass 1395 Fails 6 Crashes 1048 Timeouts 0
<kisak> This is a CL test suite -> rusticl -> zink -> radv?
<karolherbst> yeah
<kisak> only a little layer cringe
<karolherbst> anv just accepts any spir-v, so the pass rate is way better: Pass 2404 Fails 7 Crashes 31 Timeouts 0
<idr> tarceri: Only OpenGL uses nir_lower_const_arrays_to_uniforms. Is that because Vulkan doesn't have OpenGL-style uniforms, or is there more to it?
pcercuei has quit [Quit: dodo]
<zmike> vulkan does not have uniforms, no
<karolherbst> okay.. tomorrow I'll fix those crashes on anv and see how much we can clean up all the stuff
<zmike> karolherbst: odd you're seeing more validation in radv since both drivers use the same code for it?
<karolherbst> radv asserts on valid spir-vs
<airlied> asserts in the backend somewhere?
<karolherbst> ../src/amd/compiler/aco_interface.cpp:82: void validate(aco::Program*): Assertion `is_valid' failed.
Haaninjo has quit [Quit: Ex-Chat]
<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.
bbrezillon has joined #dri-devel
lanodan_ has joined #dri-devel