ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
vliaskov_ has quit [Remote host closed the connection]
gio has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
gio has quit [Ping timeout: 480 seconds]
gio has joined #dri-devel
heat has quit [Remote host closed the connection]
yyds has joined #dri-devel
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
atipls has quit []
Danct12 has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
yuq825 has joined #dri-devel
aravind has joined #dri-devel
mbrost__ has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
gio has quit [Ping timeout: 480 seconds]
mbrost__ has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
gio has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
macromorgan_ has joined #dri-devel
bmodem has joined #dri-devel
macromorgan has quit [Ping timeout: 480 seconds]
Dark-Show has joined #dri-devel
Dark-Show_Pi4 has quit [Read error: Connection reset by peer]
Peuc has quit [Remote host closed the connection]
Peuc has joined #dri-devel
<kode54> oops
<kode54> people once again using %lu for uint64_t
<kode54> (and thank you, again, compiler gods, for requiring the world to use things like PRIu64 to be architecture compatible)
<HdkR> Time to use c++20 formatting tools. Just use {} for everything :D
<kode54> probably not too many people testing their code with a build setup that produces a full multilib build
<kode54> though CI would definitely catch that
<DavidHeidelberg> anyone from AMD would be willing to look why raven2 is hanging a lot on our CI with 6.5 (6.4 we use now is just fine)? https://gitlab.freedesktop.org/mesa/mesa/-/issues/9865
Duke`` has joined #dri-devel
<mareko> agd5f: ^^
atipls has joined #dri-devel
atipls has quit []
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
Dark-Show has quit [Quit: Leaving]
tzimmermann has joined #dri-devel
tzimmermann has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
kem has quit [Ping timeout: 480 seconds]
sgruszka has joined #dri-devel
pekkari has joined #dri-devel
kem has joined #dri-devel
Peuc has quit [Remote host closed the connection]
Peuc has joined #dri-devel
habernir has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
kem has joined #dri-devel
mvlad has joined #dri-devel
crabbedhaloablut has joined #dri-devel
<javierm> tzimmermann: I was on holidays yesterday, I'll take a look to the patch-set today
An0num0us has joined #dri-devel
rasterman has joined #dri-devel
<soreau> daniels: When I force push my branch to update i.e. https://gitlab.freedesktop.org/mesa/kmscube/-/merge_requests/47 it sends a ci-fail message to my inbox because I lack permissions to run it. Is there anything that can be done so it runs the ci successfully when I force push?
<soreau> robclark: eric_engestrom: who should I ping about this MR to have it reviewed? ^^
pekkari has quit [Quit: Konversation terminated!]
<tzimmermann> javierm, thank you
rgallaispou has joined #dri-devel
habernir has quit [Quit: Leaving]
Dark-Show_Pi4 has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sgruszka has quit [Ping timeout: 480 seconds]
sghuge has joined #dri-devel
Dark-Show_Pi4 has quit [Quit: Leaving]
tursulin has joined #dri-devel
Company has joined #dri-devel
pochu has joined #dri-devel
lemonzest has quit [Quit: WeeChat 4.0.4]
Kayden has quit [Quit: Leaving]
vyivel has quit [Read error: Connection reset by peer]
vyivel has joined #dri-devel
Kayden has joined #dri-devel
mripard has joined #dri-devel
lemonzest has joined #dri-devel
Dark-Show_Pi4 has joined #dri-devel
pekkari has joined #dri-devel
pcercuei has joined #dri-devel
vliaskov has joined #dri-devel
lynxeye has joined #dri-devel
bbrezillon has joined #dri-devel
bbrezillon has quit []
bbrezillon_ has joined #dri-devel
lynxeye has quit [Ping timeout: 480 seconds]
kos_tom has joined #dri-devel
pekkari has quit [Quit: Konversation terminated!]
junaid has joined #dri-devel
lynxeye has joined #dri-devel
ascent12 has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
ascent12 has joined #dri-devel
junaid has quit [Remote host closed the connection]
co1umbarius has quit [Ping timeout: 480 seconds]
sarahwalker has joined #dri-devel
co1umbarius has joined #dri-devel
junaid has joined #dri-devel
junaid has quit [Remote host closed the connection]
oneforall2 has quit [Remote host closed the connection]
<soreau> zmike: got xwayland working with zink and no modifiers using a hacky 3 liner patch (see the issue)
oneforall2 has joined #dri-devel
<kode54> soreau: you are cool
Company has quit [Remote host closed the connection]
<soreau> kode54: well, not yet.. that was only in nested wayland backend
cmichael has joined #dri-devel
<kode54> Oh
<kode54> Well, get it to where you can dogfood it
<kode54> Iā€™m maining your track-wlroots branch at least
DodoGTA has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
vyivel has quit [Ping timeout: 480 seconds]
vyivel has joined #dri-devel
Dark-Show_Pi4 has quit [Quit: Leaving]
heat has joined #dri-devel
Haaninjo has joined #dri-devel
novaisc has joined #dri-devel
tonyk has joined #dri-devel
pekkari has joined #dri-devel
<MrCooper> can commit_tail get called from atomic context?
DodoGTA has joined #dri-devel
<MrCooper> err, make that drm_atomic_helper_commit with nonblock=false
DavidHeidelberg has quit [Remote host closed the connection]
okias has joined #dri-devel
okias has quit [Remote host closed the connection]
DavidHeidelberg has joined #dri-devel
DavidHeidelberg has quit [Remote host closed the connection]
DavidHeidelberg[m]_ has joined #dri-devel
DavidHeidelberg[m]_ has quit [Remote host closed the connection]
DavidHeidelberg has joined #dri-devel
pekkari has quit [Quit: Konversation terminated!]
heat has quit [Ping timeout: 480 seconds]
mairacanal has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
antoniospg has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
<karolherbst> alyssa, gfxstrand: any comments/complains on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25330/diffs?commit_id=b5e51b631cc1097385768f7fabafb1002820fe0d ? Kinda want to land it so vec4 backends can start using it for vec8/16 lowering
<karolherbst> unless you have better ideas or other suggestions
heat has joined #dri-devel
vyivel has quit [Remote host closed the connection]
<tzimmermann> arnd, hi. what happened to https://lore.kernel.org/dri-devel/20230719123944.3438363-2-arnd@kernel.org/ did you merge this patchset?
sgruszka has joined #dri-devel
angerctl is now known as Namarrgon
larunbe has joined #dri-devel
<alyssa> karolherbst: no comments or complaints
alarumbe has quit [Ping timeout: 480 seconds]
<karolherbst> ehh wait
<karolherbst> I linked the wrong commit
<arnd> tzimmermann: I actually wanted to get back to this today, and something else came up. I had been travelling most of the time in the last six weeks, so I did not get to it earlier
itoral has quit [Quit: Leaving]
Danct12 has joined #dri-devel
yyds has quit [Remote host closed the connection]
atipls has joined #dri-devel
An0num0us has quit [Ping timeout: 480 seconds]
<karolherbst> zmike: question.. if I call launch_grid, then memory_barrier(PIPE_BARRIER_ALL) then resource_map a buffer used in launch_grid, should I expect the content behind the map pointer to be synced?
An0num0us has joined #dri-devel
<karolherbst> maybe some zink_batch_reference_resource_rw are missing for the global buffers..
<karolherbst> ehh
<karolherbst> buffer_map I mean
<zmike> karolherbst: no
<zmike> you'd need to map the buffer persistently
Dark-Show_Pi4 has joined #dri-devel
<karolherbst> mhhh.... kinda annoying, because it's not necessarily a buffer not being created with PIPE_RESOURCE_FLAG_MAP_PERSISTENT
<karolherbst> s/not/
<karolherbst> also, I just wnat to copy the buffers content to host memory
<zmike> then you could also manually sync it
<karolherbst> yeah, that would be fine
<zmike> I think that's a transfer_map_flush thing but I'll have to get down to my office and check
<zmike> alternatively resource_copy_region ?
<karolherbst> that only works between two resources.. but I guess I could create a temporary one
<karolherbst> but that kinda sounds a bit wasteful to do
<karolherbst> right.. there is transfer_flush_region
<karolherbst> yeah, let me look into that
<karolherbst> ehh.. looks like that's only for writes into the mapped area
An0num0us has quit [Ping timeout: 480 seconds]
<tzimmermann> arnd, ah ok. what a coincidence
<zmike> karolherbst: I'm not sure there's a gallium api for this
<karolherbst> yeah.. me neither
<zmike> I'd suggest using a persistent+coherent staging resource
<karolherbst> mhhh
<zmike> zink does slab allocation anyway so it's basically free if you tack it on to the end of your cmdbuf right before a flush
<karolherbst> I think I'd rather change the gallium API, because zink is the only driver where it doesn't work
<zmike> what are you doing for other drivers that makes it work?
<karolherbst> nothing
<zmike> šŸ¤”
<karolherbst> other drivers seem to synchronize things, or rather.. do things in a way, that I can use buffer_map in my use case
<karolherbst> I didn't check though
<zmike> maybe describe your case a bit better
<karolherbst> I just want to map a buffer after launch_grid and see the writes to it from that compute shader
<zmike> that should work?
<karolherbst> I think that's unknown, all I can say is that I don't have that issue with other drivers
<zmike> give me a branch and a test case
<karolherbst> my rusticl/zink branch + test_conformance/basic/test_basic if
<karolherbst> have to set "CL_DEVICE_TYPE=CL_DEVICE_TYPE_GPU RUSTICL_ENABLE=zink"
<karolherbst> zmike: mhhh...
<karolherbst> there might be a different fix for me
<karolherbst> atm I flush/finish the context after doing the map + copy.. maybe I should flush first, then copy the buffer..
<karolherbst> that seems to fix it for zink at least
rasterman has quit [Quit: Gettin' stinky!]
<karolherbst> there is a "blocking_read/blocking_write" argument to some of the CL operations and I should probably finish the context before doing those operations...
<karolherbst> let me toy around with that first
<zmike> map should automatically be doing the sync as long as you aren't trying to map it asynchronously
<karolherbst> yeah... that's what I assumed
<karolherbst> but `zink_buffer_map` doesn't seem to sync anything before `zink_copy_buffer`
<zmike> hmmm
<zmike> what is this buffer used for?
<zmike> ssbo?
<karolherbst> yeah, CL global memory
<zmike> you need a memory barrier between launch_grid and copy
<karolherbst> I tried to add calls to zink_batch_reference_resource_rw for each buffer inside ctx->di.global_bindings but that didn't seem to help
<karolherbst> yeah..
<karolherbst> I have one :)
<karolherbst> though currently I'm using PIPE_BARRIER_GLOBAL_BUFFER
<karolherbst> but BARRIER_ALL also didn't help
<karolherbst> but maybe zink has to add some barrier handling for global_bindings
<zmike> I'll look in a few, gotta actually afk a bit now
<karolherbst> yeah, no worries, I'll dig into it a bit
bmodem has quit [Ping timeout: 480 seconds]
<mareko> karolherbst: any reason for the si_clear_render_target change here? https://gitlab.freedesktop.org/-/snippets/7690
<karolherbst> I didn't try without it
<karolherbst> but it's probably fine without it, let me do a run without it
<karolherbst> zmike: doing "zink_screen(ctx->base.screen)->buffer_barrier(ctx, src, VK_ACCESS_FLAG_BITS_MAX_ENUM, 0);" instead of VK_ACCESS_TRANSFER_READ_BIT seems to fix it...
<zmike> literally what are you doing
<karolherbst> launch_grid, memory_barrier + buffer_map
<karolherbst> maybe something bda specific needs to be done here or something...
<zmike> still struggling to build cts again
Dark-Show_Pi4 has quit [Remote host closed the connection]
<karolherbst> yeah.. it's a pain, probably fails due to outdated CL headers
<karolherbst> just use an older commit
<karolherbst> on fc38 588a935e9d90c92839f3d256d82c35d3f081075a should work
<karolherbst> uhm..
<karolherbst> 0702f2ecee4b250818a7fe289508ef9c54c1b48e
<zmike> seems like it can't find the loader libs even though I'm passing them
<karolherbst> uhh
<karolherbst> cmake -G "Ninja" ../ -DCL_LIBCLCXX_DIR=/usr/lib64/ -DCL_INCLUDE_DIR=/usr/include -DCL_LIB_DIR=/usr/lib64/ -DCMAKE_RUNTIME_OUTPUT_DIRECTORY=. -DOPENCL_LIBRARIES=OpenCL -DCMAKE_BUILD_TYPE=Debug
<karolherbst> or something
<zmike> yea I did that
<karolherbst> mhhh...
Peste_Bubonica has joined #dri-devel
<karolherbst> pastebin the output?
<zmike> I got it working
<zmike> now to figure out why rusticl exploded
<karolherbst> ehh wait... messing with buffer_barrier didn't change a thing, I just messed up my environment
<karolherbst> zmike: ohh.. not sure how well things work on radv...
<karolherbst> mareko: yeah, seems fine without that si_clear_render_target change
<zmike> Requesting GPU device based on environment variable for platform index 0 and device index 0
<zmike> ERROR: clGetPlatformIDs failed! ((unknown) from /home/zmike/src/OpenCL-CTS/test_common/harness/testHarness.cpp:403)
<zmike> OCL_ICD_FILENAMES=/usr/local/etc/OpenCL/vendors/rusticl.icd CL_DEVICE_TYPE=CL_DEVICE_TYPE_GPU RUSTICL_ENABLE=zink test_conformance/basic/test_basic
<karolherbst> huh...
ungeskriptet7 has joined #dri-devel
yyds has joined #dri-devel
ungeskriptet has quit [Ping timeout: 480 seconds]
<karolherbst> zmike: try OCL_ICD_VENDORS and point to the so file
<zmike> no change
<karolherbst> looks like the ICD doesn't load rusticl
<tnt> I never had any luck with OCL_ICD_VENDORS. Usualy I need to get OCL_ICD_VENDORS to "" (empty) and then set OCL_ICD_FILENAMES to the .so
<karolherbst> it kinda depends on what ICD you have
<karolherbst> but yeah..
<zmike> the icd just has the library so path
<karolherbst> what ICD are you using anyway? ocl-icd or that khronos one?
<zmike> it's the rusticl icd
<karolherbst> I meant the loader
<zmike> ocl-icd
<karolherbst> mhh.. then OCL_ICD_VENDORS with an absolute path to the drivers so file should work
<karolherbst> or just use meson devenv
bmodem has joined #dri-devel
<zmike> no change
<karolherbst> are you even building it?
<zmike> yes
<karolherbst> maybe check with LD_DEBUG=libs then
pekkari has joined #dri-devel
<zmike> oh it's using the khr loader
<zmike> but ld debug seems to find everything
<zmike> never gets to the point of loading rusticl though
<karolherbst> I think the khronos one expect OCL_ICD_FILENAMES to point to the so file...
<zmike> ok that worked
<zmike> šŸ¤•
<karolherbst> I should fix that mess in the devenv setup...
<zmike> so what am I looking at here
<karolherbst> after a call to zink_launch_grid you should see a call to zink_buffer_map
antoniospg has quit []
<karolherbst> and the memory the returned pointer points to doesn't contain the writes from that launch_grid
<zmike> oh gallium trace doesn't work with rusticl
<karolherbst> ehh.. I thought I fixed it
<zmike> is it the first sequence of launch_grid -> buffer_map that fails?
<karolherbst> yes
<karolherbst> there shouldn't be a second one anyway
<zmike> I'm testing on radv and it seems like it passes
<karolherbst> mhhhh
<karolherbst> let me check on radv...
<zmike> it fails on like the 20th one
<karolherbst> mhh.. looks like it's indeed more reliable on my desktop.. uhh
<karolherbst> it fails like always on my laptop
<karolherbst> maybe it's a bug in anv... but I was seeing fails on my desktop with more GPU load...
<karolherbst> ehh wait..
<karolherbst> I should have used my local build and not intels' stack..
<karolherbst> yeah...
<karolherbst> it works more reliable with radv and always fails with anv
<karolherbst> zmike: if I keep the AMD gpu busy with other things, it fails more often
<zmike> which test case in this thing is failing, specifically
<karolherbst> "if"
<karolherbst> it's a dead simple test if almost nothing else going on
<karolherbst> *with
<zmike> hm I'm seeing a bunch of other fails before that one
<zmike> but sure
<karolherbst> yeah.. it's a general problem
yuq825 has left #dri-devel [#dri-devel]
macromorgan_ has quit [Read error: Connection reset by peer]
cef has quit [Ping timeout: 480 seconds]
An0num0us has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
pekkari has quit [Quit: Konversation terminated!]
<zmike> karolherbst: remind me again what you're doing with the global_binding buffers
<karolherbst> pass their raw addresses into the shader via cb0, and the shader might do arbitrary things with it
yyds has quit [Quit: Lost terminal]
robmur01 has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
<karolherbst> well.. arbitrary meaning load/stores on global memory
<zmike> so it's read-only access?
<zmike> or read-write
<karolherbst> read-write
<zmike> ok
yyds has quit []
yyds has joined #dri-devel
pekkari has joined #dri-devel
<zmike> karolherbst: I think it was not described clearly to me originally
<zmike> along with all the other tests
robmur01 has joined #dri-devel
Duke`` has joined #dri-devel
<karolherbst> okay, cool
<karolherbst> I'll run the cts and check if it fixes the problem generally
<karolherbst> or is the stuff done in zink_update_descriptor_refs enough?
<zmike> yeah don't do that
<karolherbst> okay
<mareko> tarceri: do you know if disk_cache has a mechanism that detects file corruption and rejects corrupted shaders?
<pekkari> Hi guys, how is the best way to wait a crtc commit to be finished in the kernel side? I tried to use drm_crtc_commit_wait, but I got no big luck
<karolherbst> zmike: you want to submit an MR or should I just add a commit in our name to the rusticl/zink one?
macromorgan has joined #dri-devel
<soreau> daniels: thanks
<soreau> robclark: Thanks for the review, I've been trying to clean it up. Can you say if recreating the fb on each frame is ok or should I be able to do it once upfront and just rebind on each frame?
<zmike> karolherbst: just amend it into the other global binding one
<karolherbst> ohhh.. yeah.. I thought it already landed...
<mareko> dschuermann: would you be OK with adding a hash check into cached RADV shaders to detect file system corruption? or is this something disk_cache should do instead?
<karolherbst> done
<pendingchaos> it looks like disk_cache_os.c's parse_and_validate_cache_item() does a CRC32 check
mauld has quit []
mauld has joined #dri-devel
<karolherbst> zmike: anyway, this was the last blocker, so if that's fine now I kinda want to merge it
<zmike> you tell me if it's fine, I'm not running cts
<karolherbst> yeah.. I'll run it here also with radv and see if anything else is super broken or if it's fine now..
<karolherbst> but it looks better now
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
<zmike> I'll await your feedback
<karolherbst> "Pass 2418 Fails 35 Crashes 1"
<karolherbst> CL_ADDRESS_CLAMP being like 15 of those...
<karolherbst> but yeah.. nothing serious enough to block on merging in
<karolherbst> let's see what radv and lvp say
<karolherbst> this will take a while, but I think once everything is reviewed it can land
<robclark> soreau: recreating each frame is probably not the end of the world on most hw.. but kmsro stuff that needs contiguous scanout buffer might appreciate you not doing that
heat_ has quit [Read error: Connection reset by peer]
heat_ has joined #dri-devel
<eric_engestrom> soreau: next time you rebase your kmscube MR, the pipeline will run properly :)
<soreau> robclark: I did try simply rebinding the fb, db and textures, but this 'didnt work'. What more do I need to do, set min/mag filters?
<soreau> eric_engestrom: thank you!
<robclark> oh, I guess you are talking about the fbo you render the gears to, not the one that is scanned out? I think that shouldn't be a problem to recreate
<robclark> re: gl.. `MESA_DEBUG=1`?
<robclark> or =incomplete_fbo
<karolherbst> zmike: list of commits still missing reviews: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24839#note_2101851
<zmike> I'm going through them now
<karolherbst> thanks!
cmichael has quit [Quit: Leaving]
<soreau> robclark: yes, the gears fb
<soreau> I still would at least not to glGen/glDelete on each frame but I don't know how much overhead that would save
<robclark> I'd probably not worry too much
<soreau> ok, thanks
<soreau> robclark: renamed the shaders and reformatted to whitespace
<pekkari> is it the right place to ask questions about drm_atomic? or is there any other channel for that?
<MrCooper> pekkari: this is it
<soreau> daniels: the link is wrong on the wiki 'signup page'
bbrezillon has joined #dri-devel
<pekkari> oh, alright, thanks MrCooper, I asked it a few lines up about how would be the right way to make drm_atomic wait on a crtc commit to be finished
<soreau> can anyone confirm going to https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home and clicking on 'signup page' brings them to an unrelated issue report?
<soreau> eric_engestrom: I pushed but it failed instantly again
guru_ has joined #dri-devel
<soreau> oh you did say to rebase
<soreau> derp
<soreau> eric_engestrom: yes it worked, thanks
aravind has quit [Ping timeout: 480 seconds]
<eric_engestrom> soreau: hehe
<eric_engestrom> you're welcome :)
oneforall2 has quit [Ping timeout: 480 seconds]
<soreau> :)
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
cef has joined #dri-devel
kzd has joined #dri-devel
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
yyds has quit [Remote host closed the connection]
kts has joined #dri-devel
<soreau> pekkari: you might have a look at kmscube https://gitlab.freedesktop.org/mesa/kmscube/-/blob/master/drm-atomic.c and look around for fences
sarahwalker has quit [Remote host closed the connection]
* pekkari looking, thanks!
<pekkari> though I'm looking into the kernel space, not sure if the user space use case will actually help my day
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
pekkari has quit [Quit: Konversation terminated!]
gouchi has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<zmike> karolherbst: anything else I need to do at this point
<karolherbst> nope
<zmike> k
glennk has joined #dri-devel
<karolherbst> I'll probably run into more bugs once I test more with nvidia's vulkan driver and stuff
tzimmermann has quit [Quit: Leaving]
tales-aparecida has joined #dri-devel
rasterman has joined #dri-devel
bbrezillon_ has quit []
macromorgan has quit [Read error: Connection reset by peer]
praneeth_ has joined #dri-devel
macromorgan has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
An0num0us has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
<karolherbst> uhh.. my new way of loading zink doesn't work on lvp... shouldn't be hard to fix though
ngcortes_ has joined #dri-devel
<karolherbst> mhhh.. works with LIBGL_ALWAYS_SOFTWARE=1
<karolherbst> whatever
<zmike> shipit
<karolherbst> it's just a mess for the script I use to run the CTS on all the drivers and hardware and everything
<karolherbst> but I can make that work
<soreau> zmike: do you have any idea or comment on why drm backend hard locks the machine with my zink patch?
<soreau> my eyes aren't as good as yours
<karolherbst> I have to add special handling for nvidia anwyay
<zmike> soreau: at a glance I'd say because you're trying to do complicated stuff like run xserver with glamor disabled and modifiers hacked out and hitting codepaths that aren't intended to be hit
<soreau> zmike: no, it's glamor enabled
<soreau> I got that working with wayland backend at least
<zmike> but your device doesn't support modifiers
ngcortes has quit [Ping timeout: 480 seconds]
<soreau> well, it works with wayland backend, that's what I know
<soreau> but it's clear it's hitting paths that aren't intended for this case, I was just wondering if you had a hunch as to where or what
<zmike> I do not
<soreau> ok, thanks šŸ‘
<zmike> good luck
<soreau> btw, when hard locks happen, what's a good way to debug? serial?
<zmike> maybe?
bmodem has quit [Ping timeout: 480 seconds]
ngcortes_ has quit [Ping timeout: 480 seconds]
<soreau> or some watchdog situation
rosasco has joined #dri-devel
<karolherbst> zink intel: Pass 2417 Fails 35 Crashes 2 AMD: Pass 2285 Fails 30 Crashes 139 lvp: Pass 2286 Fails 30 Crashes 138
<zmike> at least the fails are consistent?
<karolherbst> all crashes are image related...
<karolherbst> well.. except the 2 intel also has
<karolherbst> it's probably something silly
<karolherbst> asserts inside vk_object_base_assert_valid
<karolherbst> looks like some invalid handle getting passed around
<karolherbst> mhhh, it's inside zink_descriptors_update_masked_buffer, which isn't reached with anv
<karolherbst> yeah.. so it's a ZINK_DESCRIPTOR_MODE_LAZY vs ZINK_DESCRIPTOR_MODE_DB thing
<zmike> which one is asserting
ngcortes_ has joined #dri-devel
<karolherbst> the call into GetDescriptorEXT
<zmike> šŸ¤”
<karolherbst> line 1174
<zmike> ZINK_DEBUG=vvl
<karolherbst> what does this do, because it doesn't print anything to stdout
<karolherbst> ohh..
<karolherbst> probably I have to properly set up validation layers again.. uhhh
<karolherbst> okay, got it
<zmike> your vvl is too old
<zmike> update
ngcortes_ has quit []
ngcortes has joined #dri-devel
Company has joined #dri-devel
<karolherbst> I hope version 261 will be new enough
<zmike> that's kinda old
<zmike> I think even ci has newer than 261
<karolherbst> newest is like 264, no?
<zmike> yea
<karolherbst> 265 actually
<karolherbst> let's hope it's enough because atm it's the easiest thing to install/build, otehrwise I will have to build into a local prefix and that's going to be more pain
<karolherbst> but I have currently 238....
sukrutb has joined #dri-devel
halfline has joined #dri-devel
atipls has quit []
<halfline> did anyone on dri-devel mailing list get this mail I sent a couple of hours ago? https://paste.centos.org/view/d5ff0b7c I'm not seeing it in the archives. wondering if it got caught in a spam trap or something
atipls has joined #dri-devel
<javierm> halfline: I don't see in my inbox, nor in patchwork https://patchwork.kernel.org/project/dri-devel/list/?submitter=Ray+Strode&archive=both
<javierm> halfline: so it seems that didn't make it
atipls_ has joined #dri-devel
<airlied> probably just held for moderator, MrCooper usually processes those when he gets the chance
<halfline> weird, i'm pretty sure i've been subscribed to that list for decades, wonder why it went to moderation
<karolherbst> uhhh
atipls has quit []
<karolherbst> spirv-tools update broke existing binaries :')
<karolherbst> anyway.. I think it's simply passing either a NULL sampler or the memory is simply not initialized
exp80 has quit [Ping timeout: 480 seconds]
atipls_ has quit []
atipls has joined #dri-devel
rosasco has quit [Quit: Leaving]
atipls has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
atipls has joined #dri-devel
<karolherbst> zmike: yeah... no idea what's going on there. This db_template stuff is quite confusing. The test running into this is `test_basic image_r8`
<zmike> checking
<halfline> javierm: looks like it's in patchwork now. thanks for the link
<zmike> oh
<zmike> how did this work at all
<karolherbst> ehhh
<karolherbst> anv be like: case VK_DESCRIPTOR_TYPE_SAMPLER: /* There is no real limit on samplers */ break;
<karolherbst> ehh
<karolherbst> maybe different API
<karolherbst> but anv takes a different path anyway
<karolherbst> anyway.. "ZINK_DESCRIPTORS=lazy" works with lvp as well
<zmike> fixed
<zmike> pick HEAD off zmike/test
<karolherbst> uhhh
<karolherbst> looks better
<karolherbst> now it's Pass 2374 Fails 40 Crashes 40
<karolherbst> will look into the other things tomorrow
ngcortes has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
<karolherbst> radv: Pass 2400 Fails 44 Crashes 10
fab has quit [Quit: fab]
tursulin has quit [Ping timeout: 480 seconds]
heat_ has quit [Remote host closed the connection]
heat has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
halfline has quit [Quit: Page closed]
ngcortes has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
gouchi has quit [Remote host closed the connection]
antoniospg has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
<robclark> this is a fun read.. https://www.hertzbleed.com/gpu.zip/GPU-zip.pdf .. time for MESA_uncompressed_texture gl/vk extension?
imre is now known as Guest1396
imre has joined #dri-devel
Guest1396 has quit [Ping timeout: 480 seconds]
Peste_Bubonica has quit [Remote host closed the connection]
heat_ has quit [Read error: No route to host]
heat has joined #dri-devel
<dj-death> robclark: ahah :)
heat has quit [Remote host closed the connection]
<airlied> robclark: isn't that just use linear :-)
<robclark> well, that is the big hammer approach.. but maybe you'd like to still do tiled
<robclark> anyways, that gallium driver part of it shouldn't be so hard (and could fallback to LINEAR based on pipe cap or something like that)
ngcortes has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit []
rasterman has quit [Quit: Gettin' stinky!]
shashanks_ has joined #dri-devel
<soreau> zmike: I got Xwayland working with RX580 on wayland and drm backends running zink+radv using this patch http://ix.io/4Hwh
<soreau> shall I make an MR or is it no good?
shashanks__ has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
<zmike> definitely not
<zmike> first part is maybe something, idk what you're doing in the second
<soreau> and it needs to set this https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/zink/zink_resource.c?ref_type=heads#L756 to VK_IMAGE_TILING_LINEAR or VK_IMAGE_TILING_OPTIMAL depending on the conditional in the patch
<soreau> or else glxgears stride is wrong, or otherwise the image is corrupted
<soreau> would it not work in the case where there are modifiers supported?
<soreau> because IIUC, I think tiling would get set to VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT in that case because EXT_image_drm_format_modifier && modifiers_count
<soreau> zmike: if you would prefer, I could make an MR where we can discuss it further on gl
<zmike> I'm at the pub so probably that'd be more productive
pcercuei has quit [Quit: dodo]
<soreau> super good