ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
heat has joined #dri-devel
co1umbarius has joined #dri-devel
<karolherbst> I can finally wire up proper nir_validate support in rusticl, but that also requires me to bump to meson 1.2.. oh well.. need it for some of the external crate support anyway.
<karolherbst> dcbaker: how much of that already works btw?
columbarius has quit [Ping timeout: 480 seconds]
<dcbaker> karolherbst: all that landed for 1.2 was the core classes and functions unfortunately :/
<karolherbst> ahh... so I guess proper crate.io support might come in 1.3?
<karolherbst> I kinda want to see something like this: https://github.com/mesonbuild/meson/pull/11856#issuecomment-1586106520 :D
jfalempe has quit [Remote host closed the connection]
jfalempe has joined #dri-devel
alanc has quit [Remote host closed the connection]
jfalempe_ has joined #dri-devel
jfalempe has quit [Read error: Connection reset by peer]
jfalempe_ has quit [Remote host closed the connection]
jfalempe_ has joined #dri-devel
yyds has joined #dri-devel
airlied has quit [Ping timeout: 480 seconds]
airlied has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
konstantin_ has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit []
konstantin has joined #dri-devel
konstantin has quit [Ping timeout: 480 seconds]
benjaminl has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
lina has quit [Remote host closed the connection]
lina has joined #dri-devel
gallo72 has joined #dri-devel
aravind has joined #dri-devel
bgs has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
bgs has quit [Remote host closed the connection]
aravind has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.6]
aravind has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
Duke` has joined #dri-devel
dviola has quit [Quit: WeeChat 4.0.2]
idr has quit [Quit: Leaving]
mvlad has joined #dri-devel
junaid has joined #dri-devel
junaid has quit [Remote host closed the connection]
JohnnyonFlame has quit [Read error: Connection reset by peer]
sima has joined #dri-devel
Haaninjo has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
fxkamd has quit []
Company has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
<daniels> jenatali: we don’t even manage them though, alatiera isn’t us …
fab has quit [Quit: fab]
mvchtz has quit [Quit: WeeChat 3.5]
jkrzyszt_ has joined #dri-devel
mvchtz has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
fab has joined #dri-devel
nashpa has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
fab has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
pcercuei has joined #dri-devel
sarahwalker has joined #dri-devel
swalker_ has joined #dri-devel
rasterman has joined #dri-devel
swalker_ is now known as Guest7017
konstantin has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
sarahwalker has quit [Ping timeout: 480 seconds]
MrCooper has joined #dri-devel
lynxeye has joined #dri-devel
<sravn> javierm: Did you consider to pull out the logo stuff from fbmem and place it all in video/logo/*
<javierm> sravn: that's an option to. The functions though are named fb_* so probably that should be changed too
<javierm> sravn: I actually don't have a strong opinion on this, just wondered and asked Geert since he was touching that
<sravn> javierm: Yep, it should be clear this is logo stuff and not core fb stuff
<javierm> sravn: agreed. I just noticed that inconsistency so thought that either everything should be in fbdev/core or in video/logo
aravind has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
dos1 has quit [Ping timeout: 480 seconds]
dos1 has joined #dri-devel
aravind has joined #dri-devel
fab has quit [Quit: fab]
pochu has joined #dri-devel
fab has joined #dri-devel
itoral has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]> eric_engestrom: hey! I'm still looking at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24305#note_2013552 and trying find better approach.. while it would be best to merge it asap, do you have any insight on how to solve this?
dliviu has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
donaldrobson has joined #dri-devel
itoral has joined #dri-devel
maxv has joined #dri-devel
crabbedhaloablut has joined #dri-devel
<maxv> Hi. If I export gbm_bo, is it safe to immediately call gbm_bo_destroy, or should I keep it around while the buffer is used by another process?
<emersion> you can destroy the bo immediately
<MrCooper> maxv: export to dma-buf fd, or to KMS handle?
<maxv> emerson: great, thanks
<maxv> MrCooper: dma-buf
<MrCooper> then yes, the dma-buf fd keeps the underlying kernel BO alive (a KMS handle wouldn't though)
yyds has quit [Remote host closed the connection]
donaldrobson has quit [Remote host closed the connection]
<emersion> MrCooper: a KMS FB would i believe?
<MrCooper> yeah, I think so
<emersion> did you mean "GEM handle" instead of "KMS handle"?
<emersion> and i believe a GEM handle would retain a ref as well
<emersion> (modulo the GEM_CLOSE weirdness)
<MrCooper> indeed I did, used the Mesa radeonsi terminology
<MrCooper> gbm_bo_get_handle may (or may not) return the same GEM handle used by GBM itself, in which case destroying the gbm_bo may destroy the kernel BO and invalidate the GEM handle
<MrCooper> so a GEM handle cannot be relied on for keeping the BO alive
<eric_engestrom> DavidHeidelberg[m]: I was off yesterday, I hadn't seen your comment yet; IMO stable branches should get `sed /'compare_to: main'/d` since they don't get any benefit from not using the previous push's state, and there is a downside to specifying anything, since I see 3 possibilities: 1) you leave `main` and you get a completely wrong pipeline, 2) you set `XX.Y-branchpoint` and you get a pipeline with everything that has
<eric_engestrom> ever changed in the stable branch, or 3) you set it to `staging/XX.Y` and you get the same pipeline as if you hadn't specified anything while working on a release, and when making a release you get a completely wrong pipeline
<eric_engestrom> DavidHeidelberg[m]: as for where to document this `sed`, https://docs.mesa3d.org/releasing#making-a-branchpoint would be the place
<eric_engestrom> IMO it would be good to have this doc update in the same commit
<maxv> One more question: do I understand correctly that in order to resize an EGLSurface created from gbm_surface, I need to release current EGL context, destroy EGLSurface and gbm_surface, and create new GBM/EGL surfaces with the new size? And why isn't there a resizing mechanism for gbm_surface?
<zamundaaa[m]> Of what use would a resizing mechanism be? The surface doesn't matter, KMS only works with buffers
<maxv> but GBM+EGL is not limited to KMS, as noted in https://mesa-dev.freedesktop.narkive.com/buxk7VLG/gbm-surface
<maxv> In particular I'm implementing a wayland client and currently I create an EGLImage from gbm_bo and set it as a gl renderbuffer storage. I know that EGLSurface can be created for native wl_surface, but I'm experimenting with other wayland libraries.
kts has joined #dri-devel
<DavidHeidelberg[m]> eric_engestrom: can it look like I wrote it? This part doc isn't my strong side :P
<eric_engestrom> haha, I was just looking at your new push
<eric_engestrom> I can't parse the first half of your message though?
<eric_engestrom> (the "can it look like I wrote it?")
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<DavidHeidelberg[m]> eric_engestrom: updated, Marge assigned, thanks!
xantoz has quit [Remote host closed the connection]
sravn has quit [Read error: Connection reset by peer]
cmichael has joined #dri-devel
godvino has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
godvino has quit [Quit: WeeChat 3.6]
itoral has quit [Remote host closed the connection]
smiles_1111 has joined #dri-devel
smilessh has joined #dri-devel
smiles_1111 has quit [Read error: Connection reset by peer]
fab has quit [Quit: fab]
godvino has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
<zmike> DavidHeidelberg[m]: have you had any time to make progress on splitting the CI CTS updates for GL versions?
<DavidHeidelberg[m]> zmike: I'm working on doing viable package for it, so I guess it counts as yes? :D (not progressed much yet)
<zmike> 🤝
frieder has joined #dri-devel
Company has joined #dri-devel
Duke` has quit [Ping timeout: 480 seconds]
xantoz has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
<dj-death> someone knows of a pass that would eliminate a pattern like a temporary variable stored with a value from a ubo and then read back in the next block ?
<dj-death> when the variable could be completely removed and just the load_ubo replacing the temporary variable read
<pendingchaos> nir_opt_copy_prop_vars + nir_opt_sink
fab has joined #dri-devel
<dj-death> pendingchaos: thanks a lot
frieder has joined #dri-devel
godvino has quit [Ping timeout: 480 seconds]
<dj-death> pendingchaos: doesn't seem to work on temporaries
<dj-death> nir_variable_mode ignore = nir_var_read_only_modes & ~nir_var_vec_indexable_modes;
godvino has joined #dri-devel
<dj-death> or maybe reading this wrong :/
sravn has joined #dri-devel
<pendingchaos> temporaries shouldn't be in nir_var_read_only_modes
godvino has quit [Ping timeout: 480 seconds]
godvino has joined #dri-devel
<dj-death> pendingchaos: maybe my case is too complex then
<dj-death> pendingchaos: it's a vec2[24] loaded with a bunch of vec2 sequentially from a UBO (like memcpy exactly) and then there is an indirect indexing in the temporary array
<dj-death> pendingchaos: do you happen to know if this pass can deal with that?
lemonzest has quit [Quit: WeeChat 3.6]
<pendingchaos> I don't think it can
<pendingchaos> maybe if the copy was done with a copy_deref intrinsic?
<pendingchaos> would probably also remove the need for nir_opt_sink
Leopold has joined #dri-devel
lemonzest has joined #dri-devel
cmichael has quit [Quit: Leaving]
cmichael has joined #dri-devel
yyds has joined #dri-devel
<dj-death> pendingchaos: ah damn, this is not a contiguous UBO array unfortunately
<maxv> Do you think implementing gbm_surface_resize is desirable? I think it should be pretty easy and I probably can do it, but I'm not sure if something like this would be accepted.
kzd has joined #dri-devel
<emersion> is it cumbersome to destroy and recreate?
<emersion> because that's exactly what happens when a surface is "resized" AFAIK
<alyssa> gfxstrand: !24326 is teaching me about the limits of gitlab
<gfxstrand> alyssa: Well, yes. Someone's got to stress-test the system. :joy:
godvino1 has joined #dri-devel
<maxv> emersion: It kinda is. When resize happens some buffers are locked and wait for a release event. gbm_surface_destroy docs say that all buffers need to be released and EGLSurface destroyed before calling it. This leads to a state when multiple (maybe even more than two) surfaces must exist at the same time, which is awkward.
godvino has quit [Ping timeout: 480 seconds]
<maxv> The context switch also seems unnecessary
<alyssa> gfxstrand: do they? my 1-line NIR patches usually stress the system just fine ;~P
<dj-death> pendingchaos: would you happen to know what would vectorize scratch load/stores? :)
Duke`` has joined #dri-devel
<alyssa> dj-death: i/o vectorizer can't do it?
<alyssa> er
<alyssa> load/store vectorizer
<alyssa> nir_opt_load_store_vectorize.c
<pendingchaos> the load/store vectorizer could probably be made to do that, if they aren't derefs
<pendingchaos> before deref lowering, nir_opt_combine_stores/nir_opt_cse is part of a solution
<alyssa> i guess that doesn't do scratch
<alyssa> that thing scares me ngl
<pendingchaos> I think that was because AMD hardware doesn't benefit from vectorizing scratch access
<pendingchaos> but I don't think that's actually true, so I'm not sure why it doesn't do scratch
* alyssa needs to setup load/store vectorizing on agx, we'd benefit
<alyssa> (and I'm working on a lowering pass that emits piles of scalar stores in a row that are just begging to be vectorized. not trivial to emit them as vector, loop unrolling happens in the middle)
<dj-death> also _nir_shader_variable_has_mode asserts on temp
<dj-death> but anyway I probably want to find some other trick
<dj-death> maybe promote those UBO loads to shared memory
<dj-death> ah but no, it's not going work for FS :/
<dj-death> pendingchaos: will you send a fix for the lower_shader_calls ?
<dj-death> pendingchaos: I can Rb
<pendingchaos> the "resume_shaders[i]" thing?
<pendingchaos> I don't have any way to test that it does anything, at the moment
<pendingchaos> If I'm reading stuff right, RADV doesn't use this load/store vectorizer yet
<pendingchaos> if I get it working, I guess I can make a fix
<dj-death> okay I can test it
<dj-death> we use it
godvino1 has quit []
heat has joined #dri-devel
idr has joined #dri-devel
frieder has quit [Remote host closed the connection]
benjaminl has joined #dri-devel
dliviu has quit [Ping timeout: 480 seconds]
<zmike> what's the difference between nir_intrinsic_io_xfb and nir_intrinsic_io_xfb2
<zmike> oh
<zmike> 😬
<dj-death> it's twice as good
<zmike> twice as incoherent :/
<dj-death> that's so true for intel
<zmike> as you know I test everything on intel first
Danct12 has quit [Quit: A-lined: User has been AVIVA lined]
Danct12 has joined #dri-devel
junaid has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<mareko> zmike: xfb describes xy and xfb2 describes zw channels
<mareko> it's also twice as good
aravind has quit [Ping timeout: 480 seconds]
<dj-death> pendingchaos: yeah enabling vectorization of scratch load/store seems to massively improve things
smilessh has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
jkrzyszt_ has quit [Ping timeout: 480 seconds]
Mangix_ has joined #dri-devel
Guest7017 has quit [Remote host closed the connection]
Mangix has quit [Ping timeout: 480 seconds]
Mangix_ has quit []
Mangix has joined #dri-devel
cmichael has quit [Quit: Leaving]
JohnnyonFlame has joined #dri-devel
alanc has joined #dri-devel
dliviu has joined #dri-devel
AndrewR has quit [Remote host closed the connection]
rmckeever has joined #dri-devel
linkmauve has left #dri-devel [Error from remote client]
Haaninjo has joined #dri-devel
linkmauve has joined #dri-devel
dliviu has quit [Ping timeout: 480 seconds]
<dj-death> people know of a NIR pass that groups the scratch loads/stores
<dj-death> in particular if the stores are in the block just before the loads which are in an if block
<dj-death> sounds like GCM would do that, but that doesn't seem to deal with variables
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
<dj-death> ah... store_scratch is not marked a reorderable
<dj-death> nor store_deref apparently
rasterman has quit [Quit: Gettin' stinky!]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
<alyssa> dj-death: can't move stores across loads
<alyssa> CAN_REORDER is a pretty blunt flag
maxv has quit [Remote host closed the connection]
<anholt> daniels: do you have some time to actually do dri image format #define collapsing?
<dj-death> alyssa: I meant just move then before the loads
<dj-death> alyssa: in the same if block
<dj-death> alyssa: avoiding a bunch of writes if it's not going to be used
<cwabbott> dj-death: you can't sink stores into an if except if you know that the store won't be used after the if
<cwabbott> I don't think we have anything ATM that can do that type of analysis
<cwabbott> it would probably have to use derefs in order to know what could potentially be a use
mvlad has quit [Remote host closed the connection]
tursulin has quit [Ping timeout: 480 seconds]
tango_ has joined #dri-devel
<dj-death> cwabbott: yeah, the shader I'm looking at has that one temporary variable written entirely just before an if block that will read from it
<daniels> anholt: I think it's going to become ~necessary, so yeah
<anholt> daniels: looks like the #defines aren't abi any more, which is great.
<anholt> I think we can #define them to PIPE_FORMATs then just start deleting no-op code.
<daniels> anholt: you mean __DRI_IMAGE_FORMAT?
<anholt> yeah
junaid has joined #dri-devel
junaid has quit []
<daniels> anholt: ok, neat - I guess pull that up to src/util/, then into a table which adds canonical conversions to at least DRM_FORMAT as well as sizes/shifts, then start pulling all the hand-rolled conversions?
<anholt> daniels: I was thinking that basically once you #define to PIPE_FORMAT/MESA_FORMAT in the header, one could start just collapsing the lookup tables translating between them. and then, you can probably delete the shifts/offsets from those tables since you should be able to get them from the format descriptions.
<anholt> not sure we need to build a new thing first
<daniels> anholt: ah yeah, so it is
<alyssa> hero
<zmike> don't get left behind
<zmike> review now before your driver is broken!
fab has quit [Quit: fab]
dliviu has joined #dri-devel
* alyssa pretends to be a lima developer
<alyssa> zmike: I think that MR will let us compile VS prologs at CSO create time
<alyssa> so that's nifty
<zmike> 💪
Duke`` has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
<airlied> zmike: you know the wierd things, what is EXT_depth_clamp_zero_one and why does mesa expose it only for anv and badly at that? :-)
<zmike> well
<zmike> it's for clamping depth to zero and one
<zmike> so it can't go negative or unrestri,cted
<zmike> but I can only answer that part of the question
<alyssa> for Z32F?
<airlied> so hasvk seems to expose it properly, anv half exposes it, neither of them deal with VkDeviceCreateInfo accepting the feature extension
<airlied> though maybe that is magic now
<Sachiel> that is magic now
<airlied> ah I loves the magic
JohnnyonFlame has joined #dri-devel
<alyssa> can't have bugs if magic
<alyssa> or something
<airlied> ah so the driver just doesn't seem to care if the ext is set or not
* alyssa vaguely apologizes
<airlied> which maybe is fine
<Sachiel> yeah... we do that a lot
<Sachiel> I don't see hasvk setting the feature bit though
<Sachiel> not sure if that's intended
<airlied> hasvk sets it directly in features->
<Sachiel> ah, yeah, hasvk doesn't use magic
<airlied> as opposed to magic
<alyssa> why is hasvk in tree
<alyssa> anarsoul: could I get an ack on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24341 ? thanks :)
<alyssa> it's enunes' code, just split off from the draft MR
<anarsoul> hmm, I thought that enunes is working on it
<anarsoul> sure, let me take a look
<alyssa> the draft MR has ppir working and gpir not working
<alyssa> I split off just the ppir commit so that can land now, while gpir gets sorted
<airlied> alyssa: where else would it be? probably has more users than panfrost :-P
<alyssa> airlied: good point, let's kick out panfrost too ;~P
<airlied> like why is anything in tree? let's just kick it all out to other trees
<alyssa> ambitious!
<alyssa> =D
<anarsoul> alyssa: It's quite a change, I'll take a look later tonight, I made a note for myself
<alyssa> anarsoul: thanks!
frankbinns has quit [Remote host closed the connection]
<alyssa> (enunes wrote it and says deqp is happy, and I reviewed it with my NIR hat on and I'm happy, I just don't want to randomly merge it without an ack since I pulled it off a draft MR)
<anarsoul> why not to ask for enunes' ack then? :)
<alyssa> I would also accept that ;~P
enunes[m] has joined #dri-devel
<enunes[m]> alyssa: anarsoul: I'll get back to that in the next days, unfortunately didnt have much time to followup on it since the weekend
<alyssa> enunes[m]: thanks :) can I land the ppir commit now though?
jkrzyszt_ has joined #dri-devel
<alyssa> (would let me busy myself deleting abs/neg/sat)
<anarsoul> enunes[m]: btw, are there any functional changes? or differences in shader-db?
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
<enunes[m]> as far as I could tell no changes in deqp or piglit for that patch, CI should confirm that, but shaderdb takes a hit
<enunes[m]> minor things can be improved on that patch like the remaining is_ssa and removing reg_base, but I don't necessarily object going with it now if it helps unblock work...
<enunes[m]> if anarsoul is ok with it merge it :)
<anarsoul> can I see shader-db diff first?
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
<enunes[m]> I don't have it at hand now
ngcortes has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit []
bnieuwenhuizen_ has quit []
bnieuwenhuizen has joined #dri-devel
<Kayden> zmike: thanks for the heads up, testing a tidied iris patch now
<zmike> I've been pinging for two weeks and I'll probably need to ping for another two before it has a chance of landing
<zmike> the struggle of refactoring 🤕
<Kayden> yeah :(
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Armada has joined #dri-devel
smilessh has joined #dri-devel
pcercuei has quit [Quit: dodo]
jkrzyszt_ has quit [Ping timeout: 480 seconds]