ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
robclark: Hey. Did nine-tests worked for you ?
yuq825 has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
<robclark>
DavidHeidelberg[m]: haven't had time to try to get setup to run nine tests.. and pretty low on free disk space so that probably won't happen until I have time to move things over to a device with more disk space..
<DavidHeidelberg[m]>
robclark: ok, I guess I'll follow the idea of non bloxking nine tests :)
<robclark>
if you can bisect which commit causes issues, that might make the problem more obvious.. ofc if it comes down to a commit that exposes new pipe cap, that could trigger entirely different code-paths or even test or gallium frontend bugs.. it already happens that exposing new gl features expose unrelated problems (either in test or gallium backend or elsewhere) so sometimes the answer is to just add it to xfails.. ofc w/ new CI
<robclark>
tests if you don't spend a lot of time stress testing to track down flakes it is good to start w/ non-blocking informational because people get grumpy with flakes, and very occasional flakes happen a lot when you are pushing as many CI jobs as mesa does ;-)
* robclark
also notices that it looks like we need to update restricted-traces checksums
<DavidHeidelberg[m]>
Yeah. I'll try bisect and modify none-tests MR justnto be non blocking. It's just shame I have to for this short tests separate lava job, bit with nonblocking option there isn't any other option
<DavidHeidelberg[m]>
I have access (well not from the phone right now, but I have :D )
deathmist1 is now known as deathmist
<DavidHeidelberg[m]>
*bit with nonblocking
<DavidHeidelberg[m]>
*but with nonblocking (i ha(t/v)e android keyboard)
<deathmist>
hello, I figured out what seemed to break at least FD540 X11/XWayland entirely and would like to know if I can help more with testing a fix etc. I've submitted https://gitlab.freedesktop.org/mesa/mesa/-/issues/7555 ("freedreno: X11/XWayland on Adreno 540 freezes updating screen entirely") for this
<DavidHeidelberg[m]>
hmm, OP5T, older brother of my beloved OnePlus 6(T) :) (just fixed my Mobian yesterday on it, never flash same boot into slot A and B.. updater gets confused :'( )
<deathmist>
we really need A5XX on CI with wide coverage of tests running; there's no way I would've known this is a recent regression if I didn't happen to run 22.1.7 and saw it was fine compared to 22.2.2, and would've probably just shrugged it off as "yet another broken thing with mesa fd5xx"
<DavidHeidelberg[m]>
A5xx got switched off due to kernel issues, I think woth new 6.0 it could be possible re-enabled (btw. MR is still open)
slattann has joined #dri-devel
<DavidHeidelberg[m]>
*issues after kernel update (I think the update was to ~ some -next where a5xx was unhappy)
<deathmist>
I'll try to get my hands on another OnePlus 5 unit to perhaps dedicate for running tests on A540, also DavidHeidelberg: which MR?
<DavidHeidelberg[m]>
deathmist: search for 6.0 kernel
<DavidHeidelberg[m]>
deathmist: for CI we would need 2+, bit most likely at least 3-4 of them to be able donpre-merge checks
<DavidHeidelberg[m]>
Gtg sleep, 3:20am 😪 gn
Jeremy_Rand_Talos has quit [Remote host closed the connection]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos has joined #dri-devel
yogesh_mohan has joined #dri-devel
slattann has quit [Quit: Leaving.]
JohnnyonFlame has joined #dri-devel
mhenning has quit [Quit: mhenning]
Duke`` has joined #dri-devel
nchery has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
neonking has joined #dri-devel
bgs has joined #dri-devel
fab has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
danvet has joined #dri-devel
neonking has quit []
bgs has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
cef has quit [Quit: Zoom!]
cef has joined #dri-devel
Surkow|laptop has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
vliaskov has joined #dri-devel
jkrzyszt has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Surkow|laptop has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
jlawryno has joined #dri-devel
jlawryno has quit []
jlawryno has joined #dri-devel
milkylainen has quit [Quit: ktnx]
Akari has quit [Ping timeout: 480 seconds]
caef^ has quit [Ping timeout: 480 seconds]
caef^ has joined #dri-devel
tzimmermann has joined #dri-devel
mszyprow has joined #dri-devel
rasterman has joined #dri-devel
frieder has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
<MrCooper>
dv_: with tiling, stride is generally defined as "<number of bytes between consecutive lines of tiles> / <tile height>"
fab has joined #dri-devel
<danvet>
+1
<danvet>
luckily no one managed to create a tile format odd enough where this doesn't work out
<pq>
LaserEyess, HDR_OUTPUT_METADAT is purely infoframe data sent to the sink (monitor), so who knows how they will behave. You might spy some intended behavior from HDMI or DisplayLink specs.
<pq>
LaserEyess, setting the KMS property to 0 will just stop sending any metadata of that kind, rather than telling the monitor switch. How a monitor should react to that, I don't know.
<MrCooper>
mstoeckl: if waypipe could instead map only the rectangles it actually writes to with GBM_BO_TRANSFER_WRITE, that might perform better
pjakobsson has quit []
jani has quit []
chipxxx has joined #dri-devel
pjakobsson has joined #dri-devel
jani has joined #dri-devel
apinheiro has joined #dri-devel
chip_x has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
lynxeye has joined #dri-devel
sarahwalker has joined #dri-devel
tursulin has joined #dri-devel
jlawryno has quit []
jlawryno has joined #dri-devel
kts has joined #dri-devel
jlawryno_ has joined #dri-devel
jlawryno_ has left #dri-devel [#dri-devel]
jlawryno has left #dri-devel [#dri-devel]
jlawryno has joined #dri-devel
<jlawryno>
hi guys
<jlawryno>
anyone interested in reviewing a new drm driver for Intel VPU?
<jlawryno>
This a Movidius AI accel integrated into Intel CPU
<jlawryno>
The KMD driver has almost no AI related code. It mostly looks like a GPGPU driver.
<pq>
I wish the kernel DRM KMS docs would have linkable anchor at KMS property names, so one could have a URL pointing straight at the prop doc.
<pq>
that combined with (linked from) the drmdb page about the prop would be awesome
fab has quit [Quit: fab]
mvlad has joined #dri-devel
<tzimmermann>
javierm, do you want to review my fbdev refactoring soonish? i'd like to send out a new version, but maybe i should wait?
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #dri-devel
<emersion>
pq, drmdb tries to print the kernel docs
<emersion>
but yeah it's a bit hit-or-miss, because the kernel docs are a mess
<pq>
right
pjakobsson has quit [Remote host closed the connection]
pjakobsson has joined #dri-devel
lemonzest has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
jkrzyszt has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
MrCooper_ has joined #dri-devel
MrCooper has quit [Ping timeout: 480 seconds]
MrCooper__ has joined #dri-devel
pendingchaos_ is now known as pendingchaos
libv_ has joined #dri-devel
MrCooper_ has quit [Ping timeout: 480 seconds]
libv has quit [Ping timeout: 480 seconds]
yogesh_m1 has joined #dri-devel
yogesh_mohan has quit [Ping timeout: 480 seconds]
Akari has joined #dri-devel
Lucretia has quit []
<javierm>
tzimmermann: you mean "[PATCH 0/5] drm: Add new plane helpers to begin/end FB access" ?
<javierm>
tzimmermann: I thought you had a conversation with danvet the other day and would re-spin based on his feedback?
<javierm>
tzimmermann: ah, no. You meant "[PATCH 00/21] drm/fb-helper: Untangle fbdev emulation and helpers" ?
Lucretia has joined #dri-devel
<tzimmermann>
javierm, yes, the latter. some of the commit messages are wrong, so i don't want to wait for too long before sending an update
<javierm>
tzimmermann: feel free to res-spin then and I can review the next revision if you want
<tzimmermann>
ok, thanks a lot
<javierm>
tzimmermann: you are welcome
libv_ has quit [Quit: Reconnecting]
libv has joined #dri-devel
[Ristovski] has left #dri-devel [#dri-devel]
Ristovski has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
david has joined #dri-devel
Company has joined #dri-devel
gawin has joined #dri-devel
fab has joined #dri-devel
david has quit [Remote host closed the connection]
david has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
<LaserEyess>
pq: then how is one supposed to "reset" a monitor? is just sending an "SDR" blob good enough?
<LaserEyess>
that's what I'm doing right now but apparently that shouldn't be necessary
<pq>
LaserEyess, do whatever is necessary. I don't know what the standards say about those, and even then what monitors/TV actually do is another thing.
<LaserEyess>
that seems weird but ok, if that's what you do
<pq>
me? in weston? I don't, actually. I don't even remove the HDR metadata.
<pq>
in KMS, whoever takes over next gets to clean up all the mess
<LaserEyess>
no, not you
<LaserEyess>
I highligheed vsyrjala
<pq>
LaserEyess, you said "that seems weird but ok, if that's what you do". I replied to that.
<LaserEyess>
general you, i.e. "If that is what the developer is supposed to do"
<LaserEyess>
english can be annoying sometimes
<pq>
LaserEyess, wait, did you *only* destroy the metadata blob, or did you explicitly program 0 to HDR_OUTPUT_METADATA?
<LaserEyess>
I tried all combinations
<pq>
ok
<LaserEyess>
right now I create a new blob that is SDR, and set it
<LaserEyess>
I don't set the blob_id back to 0 right now, but I did at one time
<pq>
Creating a new blob with SDR should be correct, and it's also explicitly telling the monitor that we are SDR now. So it should be good.
<pq>
setting HDR_OUTPUT_METADATA to 0 will just stop sending anything, I guess.
<LaserEyess>
it does work, but I guess I'm confused that the blob still "exists" (checking with drm_info, you can see a non-0 blob_id)
<pq>
and only destroying the blob might not actually do anything
<LaserEyess>
actually, this is another question I had, since libdrm is not well documented
<LaserEyess>
say I create an HDR blob, I send it and it's fine, then playback is over, so I create an SDR blob and send it
<LaserEyess>
and then it resets to SDR
<LaserEyess>
all fine, but afterwards I only destroy the SDR blob
<LaserEyess>
should I have destroyed all of the blobs?
<pq>
Well, yeah, it's a blob of metadata that gets repeatedly sent to the monitor. If the blob is set to 0, there is nothing to send.
<LaserEyess>
hmm, so I might want to send SDR and then 0 as well
<pq>
LaserEyess, yes, you should destroy all blobs, but I think they also get cleaned up when you close the DRM device.
<LaserEyess>
to say "stop sending this"
<pq>
yup, that would make sense to me
<LaserEyess>
ok, then that's a bug, because there's a chance you play an HDR video, then switch to an SDR video, so we wouldn't clean up the HDR blob there
<LaserEyess>
this is making more sense, but I have to ask, are there any plans to document libdrm by anyone?
<pq>
hmm... actually I'm not sure how the blob lifetime works
<LaserEyess>
"patches welcome", I'm sure :)
<LaserEyess>
well, suppose the worst case and userspace has to manage the blob's memory
<LaserEyess>
it couldn't hurt to destroy the blob after you're done with it, right?
<pq>
LaserEyess, you might be looking for the kernel docs. libdrm is only an API shim, it's not even supposed to document properties.
<LaserEyess>
the DRM API is one thing, but questions like these such as "who is responsible for lifetime management of blobs created with drmModePropertyCreateBlob()" is surely something that needs to be in libdrm...
<vsyrjala>
blobs are reference counted. as long as someone is using it it'll keep on living
<LaserEyess>
ok
<vsyrjala>
and yes, you should destroy every blob you create. otherwise you leak that reference and it'll never go away
<emersion>
LaserEyess: libdrm is just one user of the DRM uAPI. one could write Go or Rust wrappers which directly use the IOCTLs, for instance
<emersion>
but yeah, maybe the kernel docs should get duplicated in libdrm…
<emersion>
another thing is that kernel docs are published, but libdrm API docs are not
<pq>
vsyrjala, not even on closing the device?
<emersion>
pq, i think this retains the blob, because the next master needs to be able to read back e.g. MODE_ID
<LaserEyess>
emersion: not that I am the most savvy of developers, most of this is new to me, but I have found it confusing trying to jump back and forth between the kernel docs and libdrm functions, as they don't necessarily map 1:1
<emersion>
indeed
<pq>
emersion, only if the blob was actually assigned to a prop, in which case the prop has a ref on it?
<LaserEyess>
descriptions of properties, etc. sure, but actual functions and drm objects, idk
<emersion>
pq, yes
<emersion>
i think closing the FD is an implicit drmModeDestroyBlob
<pq>
right, that's what I was after. Thanks.
<emersion>
LaserEyess: i've been sending multiple doc patches, but always to the kernel, never to libdrm
<emersion>
the kernel has people to review patches, libdrm not so much
<LaserEyess>
yeah that's fair
<emersion>
libdrm has some man pages, but separate from doc comments…
<LaserEyess>
yes it does, and btw those man pages are very out of date/missing a lot
<emersion>
indeed
<LaserEyess>
they references pages that just do not exist
<emersion>
these were pretty much TODO
apinheiro has quit [Ping timeout: 480 seconds]
montjoie has left #dri-devel [#dri-devel]
<LaserEyess>
anyway, I think my specific question about the blobs has been answered, so thank you
fahien has joined #dri-devel
<emersion>
feel free to send a kernel patch to document stuff
<LaserEyess>
what about a libdrm patch?
<vsyrjala>
yeah close() should free the user blobs, but relying on that would be lame. you could have leaked tons of non-swappable kernel memory by then
<emersion>
LaserEyess: i'd review that as well
<LaserEyess>
I'm not going to rely on that, because with mpv you could play multiple videos, some of which are HDR, some of which are SDR
<LaserEyess>
so if we did HDR, HDR, SDR, HDR, SDR, we'd leak at least 3 blobs
<LaserEyess>
playlists can loop as well, so it would not be right to just wait until mpv exists
<LaserEyess>
exits*
<vsyrjala>
if you never reuse the same blob you could just nuke it as soon as the atomic ioctl has returned
<LaserEyess>
right now we create a blob on every frame, though, I think they're identical blobs
<pq>
blobs are not de-duplicated AFAIK...
<LaserEyess>
I'm really fuzzy on the actual semantics of when a new blob is needed or not, in theory there's dynamic HDR but idk
<pq>
are you leaking them all, one per frame?
<LaserEyess>
based on this conversation, yes
<pq>
that could become a real problem :-)
<LaserEyess>
luckily I labeled my PR as WIP
<pq>
I think the kernel HDR_OUTPUT_METADATA structs so far are explicitly static metadata.
<pq>
if you had dynamic metadata support, I believe you'd create another blob and maybe attach it to another prop
<LaserEyess>
well, I'm not quite sure what that is supposed to mean either
<LaserEyess>
because I found the CTA-861.G spec, and it *only* says there's static metadata
<pq>
at least the metadata_type field inside the blob would be different.
<LaserEyess>
but I know that isn't true, there are android devices that do dovi/HDR10+
<LaserEyess>
my biggest problem continues to be I know very little about the technical details of all of these things...
<pq>
downstream kernels and drivers, right?
<vsyrjala>
no one really thought about dynamic metadata yet i think. that stuff can also be bigger, and there are new hw mechanism to transmit it for both hdmi and dp. none of which is implemented in at least i915
<LaserEyess>
hm
<LaserEyess>
that surprises me a bit, perhaps it's all just tonemapped
<pq>
or maybe they accept HDR10+, but throw away the dynamic metadata?
<LaserEyess>
for android specifically, I would have expected google to try and upstream *some* of that stuff
<LaserEyess>
a lot of new smart TVs are explicitly "android TV" and not just a-smart-TV-that-happens-to-run-android-underneath TVs
<LaserEyess>
pq: well you can tonemap HDR->HDR, so perhaps what they do is that, tonemapping the dynamic stuff to static
<LaserEyess>
I really have no idea though
<pq>
that doesn't make sense, because that *is* what the dynamic metadata is for: tone mapping
<pq>
or, *better* tone mapping than what you get with static metadata
<pq>
a TV probably doesn't drive an internal panel like an external monitor, a TV /is/ a monitor - it does not need to tell KMS to send metadata to a monitor.
lygstate has joined #dri-devel
<LaserEyess>
I guess not
<pq>
Something implements all the image enhancement that TVs do, and it's not implemented in CPU or GPU but dedicated hardware because of power requirements, I believe.
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
fxkamd has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
fahien has joined #dri-devel
david_ has joined #dri-devel
david has quit [Ping timeout: 480 seconds]
Akari has quit [Ping timeout: 480 seconds]
frieder has quit [Ping timeout: 480 seconds]
jlawryno has quit [Remote host closed the connection]
jlawryno has joined #dri-devel
frieder has joined #dri-devel
fab has quit [Quit: fab]
kts has joined #dri-devel
jlawryno has quit [Ping timeout: 480 seconds]
yuq825 has quit []
<tzimmermann>
danvet, coming back to https://patchwork.freedesktop.org/series/109768/ , can we merge the callbacks without begin_cpu_access() ? even in the case of only having vmap in there, it seems the right thing to vunmap buffers at the end of the current commit.
zehortigoza has quit [Remote host closed the connection]
<tzimmermann>
i'd effectivly merge patches 1 and 2
frieder has quit [Ping timeout: 480 seconds]
MrCooper__ is now known as MrCooper
jewins has joined #dri-devel
frieder has joined #dri-devel
fxkamd has quit []
Jeremy_Rand_Talos has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
FireBurn has joined #dri-devel
fab has joined #dri-devel
nchery has quit [Read error: No route to host]
nchery has joined #dri-devel
Duke`` has joined #dri-devel
caef^ has quit [Remote host closed the connection]
kem has quit [Ping timeout: 480 seconds]
<danvet>
tzimmermann, but do you need a new callback for that?
ybogdano has joined #dri-devel
<danvet>
instead of vmap just around the access, wherever that is
<danvet>
oh vmap
zehortigoza has joined #dri-devel
* danvet
is slow
<danvet>
tzimmermann, maybe without the symmetry, give it a more descriptive name?
<danvet>
finish_fb_commit or something?
* danvet
not creative today
gawin has quit [Ping timeout: 480 seconds]
kem has joined #dri-devel
<tzimmermann>
danvet, splitting possible pinning and vmap in prepare_fb is one of the points of merging this. otherwise i'd rather keep it as is. having these callbacks no hard requirement; just much nicer
<danvet>
tzimmermann, well I figured you really need the finish_fb_access one otherwise the vmap stays around too long
<danvet>
which I thought was the original motivation
<danvet>
but then I got a bit derailed into the entire cache flushing story
<danvet>
also I think with good docs that explain that pin/unpin belongs in prepare/finish and vmap/vunmap into begin/end_access I think the names are good
<tzimmermann>
danvet, begin_fb was the original motivation. vmap was the extra.
<danvet>
begin_fb?
<tzimmermann>
the call to drm_begin_cpu_access()
<danvet>
you mean dma_buf_begin_cpu_acccess
<danvet>
yeah so that one is not good as discussed
<tzimmermann>
danvet, i have to leave. I'll post something and then we'll see
<danvet>
but the vmap one makes some sense to me
<danvet>
it was what I assumed, before coffee kicked in :-)
<danvet>
so pushing that is imo fine, I don't see any issue with that
<danvet>
checked a bit of vmap code too just now
frieder has quit [Remote host closed the connection]
macromorgan has quit [Quit: Leaving]
bgs has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
kem has joined #dri-devel
sarahwalker has quit [Remote host closed the connection]
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
fahien has quit [Quit: fahien]
jkrzyszt has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
kts has quit [Quit: Leaving]
gouchi has joined #dri-devel
jlawryno has joined #dri-devel
iive has joined #dri-devel
<jlawryno>
anyone interested in reviewing a new drm driver for Intel VPU?
<jlawryno>
This a Movidius AI accel integrated into Intel CPU
<jlawryno>
The KMD driver has almost no AI related code. It mostly looks like a GPGPU driver.
heat has joined #dri-devel
apinheiro has joined #dri-devel
jlawryno has quit [Ping timeout: 480 seconds]
flibitijibibo has joined #dri-devel
Akari has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
apinheiro has quit [Ping timeout: 480 seconds]
david_ has quit [Remote host closed the connection]
david has joined #dri-devel
jlawryno has joined #dri-devel
Haaninjo has joined #dri-devel
<graphitemaster>
How well tested are 3D textures?
LexSfX has quit []
macromorgan has joined #dri-devel
<airlied>
jlawryno: I think you should talk to the GNA Intel team and maybe the Qualcomm QAIC driver about cross reviews
jlawryno has quit [Ping timeout: 480 seconds]
david has quit [Remote host closed the connection]
david has joined #dri-devel
Kayden has quit [Quit: lunch, office]
ngcortes has joined #dri-devel
jljusten has quit [Quit: WeeChat 3.6]
jljusten has joined #dri-devel
MajorBiscuit has joined #dri-devel
Jeremy_Rand_Talos_ has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
<linkmauve>
When I mask out all color and depth writes, do drivers optimise fragment shaders to only output to the stencil buffer, and ignore now-unused calculations (like the actual fragment colour)?
<anholt>
nope, not going to recompile for that.
<linkmauve>
Ok, thanks. :)
<linkmauve>
I’ll use a simpler fragment shader then, if this ever becomes an issue.
david_ has joined #dri-devel
david has quit [Remote host closed the connection]
idr has joined #dri-devel
djbw has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
krushia has quit [Ping timeout: 480 seconds]
yang_ has left #dri-devel [#dri-devel]
yang3 has joined #dri-devel
genpaku has quit [Remote host closed the connection]
fab has quit [Quit: fab]
genpaku has joined #dri-devel
david_ has quit [Remote host closed the connection]
david has joined #dri-devel
krushia has joined #dri-devel
ngcortes has joined #dri-devel
<FireBurn>
@karolherbst: Do the other two scenes work for you on Luxmark? Or Luxmark 4?
<karolherbst>
nope
<karolherbst>
they don't
<karolherbst>
that's the reaoson we need proper function calling support in the backends
rasterman has quit [Quit: Gettin' stinky!]
<karolherbst>
so what happens is, that we create nir shaders with literally millions of ssa values
<karolherbst>
sometimes your system manages and doesn't run out of memory, but then RA never finishes
<FireBurn>
Oh blimey, yeah, it's currently 64% memory of a 64GB machine :O
bgs has quit [Remote host closed the connection]
<FireBurn>
What's RA again?
<karolherbst>
register allocation
<FireBurn>
Ta
<karolherbst>
Anyway.. radeonsi handles all of that on the llvm level, so we might be able to just have function calls inside nir and translate that to proper LLVM
<karolherbst>
would need somebody sufficiently knowledable about all of that to try out. I already did some nir fixes for passes, but... probably needs a lot more work
<FireBurn>
What happens when it's combined with zink and radv/aco ?
<karolherbst>
the same
<FireBurn>
How do you enable rusticl over zink?
<Sachiel>
MESA_LOADER_DRIVER_OVERRIDE=zink ?
MajorBiscuit has quit [Read error: No route to host]
<karolherbst>
robclark: rusticl/zink
<karolherbst>
ehhh
<karolherbst>
FireBurn: ^^
<FireBurn>
Ah more patches required
<karolherbst>
sorry for the wrong ping
david has quit [Remote host closed the connection]
<agd5f>
karolherbst, amdgpu backend in llvm has function call support for ROCm. Not sure how hard it would be to utilize that
david has joined #dri-devel
<karolherbst>
it shouldn't we just need to write the nir_to_llvm code for it
<karolherbst>
and fix nir passes expecting inlined shaders
<karolherbst>
radeonsi would be my first choice to prototype it because of LLVM
<airlied>
i should revive.my llvmpipe hacks
<karolherbst>
ohh.. good idea
<karolherbst>
airlied: I have some patches to fix all the inlining details, so I could give you that once I cleaned it up and rebased it
<airlied>
it at least parsed the spirv hints
Duke`` has quit [Ping timeout: 480 seconds]
<karolherbst>
yeah... though my first attempt would be super simple: inline everything except calls into libclc
<karolherbst>
that alone might fix 99% of the problems
mareko has quit [Read error: Connection reset by peer]
mareko has joined #dri-devel
mszyprow has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
FireBurn has quit [Quit: Konversation terminated!]
srslypascal is now known as Guest3874
srslypascal has joined #dri-devel
Guest3874 has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
<robclark>
jasuarez: btw this seems to be a v3d flake: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/30345648 ... I'd seen a couple other v3d flakes over the weekend (but would have to dig thru old jobs to check if it was same test or different flakes each time)
david has quit [Remote host closed the connection]
david has joined #dri-devel
david has quit [Remote host closed the connection]
david has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
david_ has joined #dri-devel
david has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
jewins1 has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
<zmike>
karolherbst: just merge your branch already
<zmike>
you've only got like 3 days for the zink stuff
<zmike>
for me to fix up the zink stuff*
heat has quit [Remote host closed the connection]
The_Company has joined #dri-devel
heat has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
iive has quit [Quit: They came for me...]
Haaninjo has quit [Quit: Ex-Chat]
ybogdano has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
<karolherbst>
okay.. :D
<karolherbst>
I still have to look into using the split texture/sampler types, but I suspect this might be way easier for zink to support instead of the thing we have now
<karolherbst>
zmike: probably just needs code like if pure_sampler sampler = find_texture_var(slot) or something
<zmike>
I think the existing code is fine
<karolherbst>
okay. Will try it out then
<zmike>
not sure why you want to go chasing sampler variables
<zmike>
but it's still very broken and I need to fix it
<zmike>
mainly wrt max sampler count
<karolherbst>
sure, but the main thing I want to change is, that rusticl provides texture vars with the dim instead of images. So I'd convert those image vars to texture ones if they are used by txl
<karolherbst>
pr txs
<zmike>
ah yes
<zmike>
that would be nicer
<karolherbst>
yeah
<karolherbst>
I prototype that tomorrow
<zmike>
somewhat amazed my info gathering passes fool as many tests as they do
<karolherbst>
because the test usually only use one image and one sampler
<zmike>
but also won't be sad to delete them
<zmike>
yeah that's classic CTS coverage
<karolherbst>
except the mri tests, which you came up with super hacky hacks for
<zmike>
gotta get those pass results up faster than jekstrand
<karolherbst>
yeah... should be fine
<karolherbst>
with that image stuff sorted out it's like 7 fails left
<karolherbst>
but one isn't fixable
<zmike>
?
<karolherbst>
we need to use one variable for shared and scratch mem
<zmike>
🤔
<karolherbst>
yep
<karolherbst>
or we just yolo it...
<zmike>
how/why?
<karolherbst>
because pointer casts
<karolherbst>
had some fp16 tests trip over it or something
<zmike>
fp16
<karolherbst>
some other fails are annoying precision things I still have to sort out as well
<zmike>
😬
<karolherbst>
in combination of vec3, which are a pain as well
<zmike>
at least not dvec3
<zmike>
the ultimate cancer
<karolherbst>
I am sure we won't get it to 100% at the end of the week, but having images fixed would be huge
<zmike>
then hurry up and click merge already
<karolherbst>
will do it tomorrow, because I wanna go to bed soon
<zmike>
smh sleeping
<zmike>
not even 10pm yet
<karolherbst>
at least you don't consume sampler derefs like radeonsi