ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<hays_> alyssa: its pretty much a constant on many of these arm boards. and many of them end up stranded with no fully working software unfortnately
<hays_> i got mine on a recommendation and did not realize it was so new. that said i got it working for the gift i was making, and now i have an extra to play with and can volunteer as a tester for you all
<alyssa> :)
<alyssa> not quite ready for testing but we'll make an announcement when we have something acceptably for upstream for people to play with
<hays_> sure. and i should have some experience with it by then--using a bit of code that i think for reasons i don't know and better not to get into won't be directly merged
<alyssa> see my mastodon for how i feel about that code but yes
ybogdano has joined #dri-devel
<hays_> yeah i don't know what happened but partly why im here because i want to put my efforts in the right place
<alyssa> :)
ngcortes has joined #dri-devel
<hays_> huh. OT but apparently my mastodon server is 'shutting down imminently'
vliaskov has quit [Remote host closed the connection]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
<Lynne> if rk3588 is anything like rk3399, I definitely shouldn't have one
<Lynne> these hands of mine have killed at least 3 rk3399 chips because the emmc contains the bootloader, and if you wipe that, no amount of tools can bring it back
<alyssa> rk3399 >> rk3588 but i am biased :p
<Lynne> disk destroyer? brick maker.
<Lynne> I even resorted to removing the emmc chip of a board and its recovery bootloader still wouldn't recover
agd5f has quit [Read error: Connection reset by peer]
<Lynne> rockchip only ever expected for users to only run android, or at most a heavily vendored linux distro off of a chinese website with random images on google drive
<alyssa> yeah...
<Lynne> debian have pure nightly images, where they have a generic arm64 partition data that gets appended to vendor-specific bootloader+partition table images
<alyssa> there's a lot of people that would consider rk3588 morally superior to t8103 and i am unsure how much reality there is to that
ybogdano has quit [Ping timeout: 480 seconds]
<Lynne> unfortunately, all the rk3399 chips I had were on random barebone unvendored boards that someone threw in the bin (unsurprisingly)
illwieckz_ has joined #dri-devel
illwieckz has quit [Read error: Connection reset by peer]
Haaninjo has quit [Quit: Ex-Chat]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
<Lynne> airlied: btw tested your fix, works fine on amd, breaks on nvidia
<Lynne> it seems to me either radv or nvidia is in the wrong
<Lynne> I'd go with the latter, but I'm biased :P
YuGiOhJCJ has joined #dri-devel
<kisak> https://cgit.freedesktop.org/mesa/mesa/tree/meson.build#n961 because meson 0.61.2 in Ubuntu Jammy and 0.61.1 in Debian Bullseye just isn't good enough
srslypascal has joined #dri-devel
<kisak> to be fair, there are some rust-related fixes between meson 0.61.1 and 0.61.4
<psykose> practically every single commit between .1 and .4 is bugfixes
<psykose> they should just update it
<psykose> it also defeats half the point of having a half-stable branch (0.61 in this case) where there's an intention of trying not to change any major behaviour on it and yet people don't upgrade to the releases anyway
heat has joined #dri-devel
heat_ has quit [Read error: No route to host]
<mareko> alyssa: unbinding is not necessary in theory
ngcortes has quit [Read error: Connection reset by peer]
<mareko> alyssa: an unbound sampler state leads to an undefined behavior, which is like a different sampler state was bound
<alyssa> mareko: right, that's fair
<alyssa> is that true even for robust contexts?
<alyssa> I know some APIs have null textures and such
<mareko> NULL texture are defined to return 0,0,0,1 or all 0s on our hw
<mareko> so they are much better defined
<alyssa> seems very reasonable
<mareko> I don't think gallium defines it though
<alyssa> I think ours is the same
<mareko> the GL frontend creates a dummy 1x1 texture for unbound textures, GL requires 0,0,0,1 to be returned I think
jkrzyszt has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
heat has quit [Remote host closed the connection]
<Kayden> anyone familiar offhand with a crash in u_vbuf_draw_vbo (cso_draw_vbo_default) on u_vbuf.c:1468, const uint32_t used_vb_mask = mgr->ve->used_vb_mask; where mgr->ve is a NULL pointer?
heat has joined #dri-devel
<Kayden> seems to only be happening with GALLIUM_THREAD=0
<Kayden> (was trying to disable u_threaded_context to debug....something else)
<airlied> Lynne: my problem is I can't justify why my code would be right :-)
<Lynne> airlied: hmm, with more refs, even your code fails
<airlied> Lynne: not shocked!
rmckeever has quit [Quit: Leaving]
<Lynne> let me get some clean samples
<mareko> Kayden: I see that
<mareko> robclark: any idea why cffdump fails? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/33378497
<Lynne> the most barebones HEVC file I could make
<Lynne> no advanced features at all, no b-frames
Company has quit [Quit: Leaving]
<Kayden> mareko: wow, thanks! that fixes the crash for me
<robclark> mareko: idk... some recent change about util_cpu_caps spam vs stdout/stderr would be my guess from looking at the diff
bmodem has joined #dri-devel
<robclark> and apparently the change didn't trigger enough CI jobs to catch it?
bskica has quit [Ping timeout: 480 seconds]
<mareko> robclark: nothing changed util_cpu_caps printing, only util_cpu_detect is now called for those tests, but it doesn't print anything if GALLIUM_DUMP_CPU isn't set
<mareko> the question is why it's printing anything
<robclark> maybe the test changed, idk?
<mareko> it didn't change either
<mareko> the change is that util_cpu_detect is now called for util_bitcount on x86
mbrost has quit []
<mareko> or inside util_bitcount rather
<mareko> why does build/gitlab-ci.yml contain GALLIUM_DUMP_CPU: true?
<robclark> idk?
<mareko> same here
<robclark> it doesn't really look like a cffdump issue.. maybe a gitlab-ci issue?
<mareko> yes
<mareko> at least I know what to revert now
<robclark> tag CI label on revert so someone who actually understands the yml rules looks at it?
aravind has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
heat has quit [Ping timeout: 480 seconds]
bskica has joined #dri-devel
<mareko> done
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
AndrewR has quit [Quit: Leaving]
srslypascal is now known as Guest1957
srslypascal has joined #dri-devel
kts has joined #dri-devel
Guest1957 has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
orbea has quit [Quit: You defeated orbea! 2383232 XP gained!]
orbea has joined #dri-devel
tarceri has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
itoral has joined #dri-devel
fab has joined #dri-devel
tzimmermann has joined #dri-devel
nchery has joined #dri-devel
bgs has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
jewins has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
ahajda_ has joined #dri-devel
Danct12 has quit [Quit: Quitting]
fab has quit [Quit: fab]
bgs has quit [Remote host closed the connection]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
danvet has joined #dri-devel
<airlied> Lynne: didn't get much further today, too many other tasks got in the way
<airlied> that video is useful, seeing crap after 5-6 frames, the first time a DPB slot 0 isn't used as a reference
<airlied> will try and focus a bit more tomorrow
genpaku has quit [Remote host closed the connection]
genpaku has joined #dri-devel
mvlad has joined #dri-devel
frieder has joined #dri-devel
sgruszka has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
samuelig_ is now known as samuelig
rasterman has joined #dri-devel
bskica has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
MajorBiscuit has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
tursulin has joined #dri-devel
fab has joined #dri-devel
Danct12 has joined #dri-devel
Danct12 has quit []
lynxeye has joined #dri-devel
q4a has quit [Read error: Connection reset by peer]
jkrzyszt has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
swalker_ has joined #dri-devel
swalker_ is now known as Guest1969
swalker__ has joined #dri-devel
Thaodan has quit [Quit: ZNC - https://znc.in]
Thaodan has joined #dri-devel
dcz_ has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
Guest1969 has quit [Ping timeout: 480 seconds]
pendingchaos_ has joined #dri-devel
ramacassis[m] has quit []
pendingchaos has quit [Ping timeout: 480 seconds]
pendingchaos has joined #dri-devel
pendingchaos_ has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
mvlad has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
RSpliet has quit [Ping timeout: 480 seconds]
RSpliet has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
melissawen_ has left #dri-devel [#dri-devel]
melissawen has joined #dri-devel
ahajda_ has quit [Remote host closed the connection]
pendingchaos has quit [Ping timeout: 480 seconds]
pendingchaos has joined #dri-devel
MajorBiscuit has joined #dri-devel
devilhorns has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
yuq825 has quit []
jkrzyszt has joined #dri-devel
bmodem has quit []
srslypascal has quit [Quit: Leaving]
ahajda has joined #dri-devel
<daniels> mareko, robclark: c6979d97e46907ff341665200b853cbca1d5524c
itoral has quit [Remote host closed the connection]
paulk-ter has quit [Ping timeout: 480 seconds]
jagan_ has quit [Remote host closed the connection]
bmodem has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
macromorgan has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
macromorgan has joined #dri-devel
agd5f has joined #dri-devel
Akari has joined #dri-devel
<jani> drm-tip rebuild fails because of f728a5ea27c9 ("dma-buf: fix dma_buf_export init order v2") in drm-misc-fixes
heat has joined #dri-devel
<jani> is Christian König here? ^
<jani> hmm, the conflict resolution was done using git version 2.25.1, maybe the reason
<robclark> daniels, mareko, ahh yeah, that would do it
kts has joined #dri-devel
Company has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
djbw has joined #dri-devel
agd5f_ has joined #dri-devel
agd5f_ has quit [Remote host closed the connection]
agd5f_ has joined #dri-devel
agd5f_ has quit [Remote host closed the connection]
sgruszka has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
ybogdano has joined #dri-devel
paulk-ter has joined #dri-devel
fxkamd has quit []
devilhorns has quit []
fab has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
kts has quit [Quit: Leaving]
swalker__ has quit [Remote host closed the connection]
jkrzyszt_ has joined #dri-devel
jkrzyszt_ has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<jani> anyway, I'm not doing the conflict resolution on dma-buf, and drm-tip remains stale with conflicts
<jani> danvet: airlied: mripard: mlankhorst: tzimmermann: ^
frieder has quit [Remote host closed the connection]
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
sarahwalker has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest1999
sarahwalker has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
paulk has joined #dri-devel
paulk-ter has quit [Read error: Connection reset by peer]
<mareko> daniels: yeah that's what I'm going to revert
djbw has joined #dri-devel
Daanct12 is now known as Danct12
Leopold_ has quit [Remote host closed the connection]
<danvet> jani, taking care of that
Leopold_ has joined #dri-devel
<dj-death> is Marge blocked by something?
<jenatali> dj-death: Doesn't look like it. Seems she's working on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16835
<daniels> yeah, which is in turn blocked on anholt's jetson farm being dead-ish
<daniels> (rsync seems like it's stuck)
lynxeye has quit [Quit: Leaving.]
<dj-death> how do we unblock it?
<dj-death> just unassign/reassign that MR to put at the bottom of the pile?
srslypascal has joined #dri-devel
<bnieuwenhuizen> marge a MR to disable those jobs until ahnholts farm is back up?
<mareko> the good thing about Vulkan is that it doesn't have lots of layers of complexity
<bnieuwenhuizen> we;ve been adding them
<mareko> where?
<bnieuwenhuizen> I think we have like 10 ways right now to get a constant into a shader
<bnieuwenhuizen> also generating cmdbuffers on the GPU is fun
<bnieuwenhuizen> so we're generating lots of complexity in the API
<mareko> I wonder if AMDVLK also generates command buffers like RADV, or whether they use special packets
<bnieuwenhuizen> AMDVLK doesn't support the extension, but it is clear that for D3D12 they also generate command buffers
<jenatali> Yep
gouchi has joined #dri-devel
<mareko> bnieuwenhuizen: do you just generate command buffers for ExecuteIndirect? or something else too?
<bnieuwenhuizen> yes, pretty much that
<bnieuwenhuizen> basically have to be able to bind VBOs and descriptor sets + index buffers
<mareko> do you think having packets to do that would be faster? I guess it would depend on the latency of indirect loads
<bnieuwenhuizen> I dunno actually, I haven't benchmarked
<bnieuwenhuizen> I'm already happy it doesn't hang too often
<mareko> something like an uber packet
<mareko> but then you could be limited by CP performance
<bnieuwenhuizen> I think the biggest problem is probably that we have a wait between generating the cmdbuffer and executing it
<bnieuwenhuizen> otherwise I'm also not so sure how I'd write an uber packet, like how we represent descriptor sets etc. is kinda driver specific
<bnieuwenhuizen> oh also: I think vkd3d-proton does its own compute shader to translate from d3d12->vulkan format
<bnieuwenhuizen> so having a packet would probably be nice, but not sure yet how to get there and I haven't benchmarked
<jenatali> FWIW Xbox (same hardware) uses custom packets for ExecuteIndirect
<mareko> bnieuwenhuizen: INDEX_ATTRIBUTES_INDIRECT to bind an index buffer from a memory descriptor: https://github.com/GPUOpen-Drivers/pal/blob/dev/src/core/hw/gfxip/gfx9/gfx9CmdUtil.cpp#L2510
<bnieuwenhuizen> huh interesting
<bnieuwenhuizen> didn't see that before
alyssa has joined #dri-devel
<alyssa> Is there a perf issue from using border color swizzle quirks?
<alyssa> I don't see one which makes me wonder why we don't..
<mareko> alyssa: maybe small overhead
<mareko> EXECUTE_INDIRECT might be PAL-specific, the other one seems generic
<mareko> I think older firmware didn't have those packets
<alyssa> mareko: bah, worth it
Guest1999 has quit [Ping timeout: 480 seconds]
<alyssa> I guess the related question is whether any apps depend on customBorderColorWithoutFormat
<mareko> GL_QUADS in Vulkan when? :)
<alyssa> Zink depends on it, bahh
<alyssa> "Whatever you're thinking of doing Alyssa, don't"
<alyssa> Zink depends on it. Bah ODOAOAOA
Akari has quit [Quit: segmentation fault (core dumped)]
<anholt_> daniels: oh? taking a look.
<mareko> odd GL vertex formats in Vulkan when? :)
tursulin has quit [Ping timeout: 480 seconds]
<alyssa> mareko: I was reading your vertex input in LLVM code recently,
<alyssa> I thoroughly enjoyed implementing GL_FIXED in NIR myself, in a masochistic way
<alyssa> (src/asahi/lib/agx_nir_lower_vbo.c)
<mareko> yeah we plan to move all our LLVM IR code to NIR
bmodem has quit [Ping timeout: 480 seconds]
<mareko> s/plan/wish/
<alyssa> nod
<alyssa> looked into sharing VBO code, didn't turn out to be practical because there's too much HW specific in both our impls to use all the ISA-specific format stuff
<alyssa> oh well
<anholt_> daniels: man, no clue what was going on there. 4 jobs stuck in rsync, continuously making heaps of tempfiles in lib/dri
MajorBiscuit has quit [Ping timeout: 480 seconds]
ahajda_ has joined #dri-devel
ahajda has quit [Ping timeout: 480 seconds]
ahajda__ has joined #dri-devel
<anholt_> oh no
<anholt_> so, something's putting tempfiles (named st*) in our artifacts
<anholt_> combine that with baremetal forgetting to clean the dir it's expanding artifacts into
rgallaispou has quit [Read error: Connection reset by peer]
<anholt_> and as the container gets reused we are rsyncing more and more stuff.
ahajda_ has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
agd5f has quit [Read error: Connection reset by peer]
agd5f has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
heat_ has joined #dri-devel
iive has joined #dri-devel
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
junaid has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
heat has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
ngcortes has joined #dri-devel
<macromorgan> so I'm trying to create a new drm helper function that depends on both drm_of.h and drm_mipi_dsi.h. Where would be a good place for this helper?
Haaninjo has joined #dri-devel
warpme_____ has quit []
<mareko> anholt_: what is "exit status 3" from osmesa-render in https://gitlab.freedesktop.org/mesa/mesa/-/jobs/33394462 ?
<anholt_> I don't know, but the job log says to go look at the testlog.txt, and that says "00e1:fixme:module:K32EnumProcessModulesEx (0xffffffffffffffff, (nil), 0, 0x329cdc, 2) semi-stub" around the osmesa test?
<anholt_> nope, that appears to be common noise
<mareko> anholt_: I don't see a straightforward way to debug this on linux, can we drop mingw32 support?
<linkmauve> Wow, on a Cortex-A53, panfrost_load_tiled_image() takes 1.3s while uploading a 2048×2048 RGBA8 image. Is that in the ballpark of the expectation on this kind of hardware?
tzimmermann has quit [Quit: Leaving]
<linkmauve> Decoding from PNG takes only a fraction of that time.
<linkmauve> Or is it because it writes to uncached memory or something?
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
<jenatali> mareko: That mingw test is running on Linux through Wine
<anholt_> mareko: you seem to be changing code that would be run on windows, and exit status 3 sounds related to crashes on windows, and osmesa is used a lot on windows, so that seems like a bad idea to me.
<jenatali> The MSVC build does seem to work though
<anholt_> that's good news, at least
<mareko> the question is about mingw32, not windows
<anholt_> anyway, https://docs.mesa3d.org/ci/index.html?highlight=docker#building-locally-using-ci-docker-images has some tips for being able to iterate on a build without having to install all the packages that ci wuold
<linkmauve> Oh! The slow path isn’t even in the store part, it’s in the load part!
<jenatali> It's MinGW cross-compiling for Windows, and then running the resulting executable through Wine
<linkmauve> When generating mipmaps.
<mareko> anholt_: ok, different question - can be disable mingw32 testing in CI?
<linkmauve> I guess once the texture has been uploaded, Lima didn’t keep a shadow copy so glGenerateMipmap() must load it back from its tiled format.
<linkmauve> A better solution would be for me to generate the mipmaps and upload them manually I guess.
<jenatali> mareko: I assume you're hitting an unreachable() in that test
<mareko> yes but I don't see how
<jenatali> Yonggang/lygstate should be able to help debug
<jenatali> FWIW I don't care about the MinGW build but I know he does at least
<alyssa> that's the problem with MinGW
<alyssa> what we need is MaxGW
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
<alyssa> supporting ALL the C++25 features
Jeremy_Rand_Talos_ has joined #dri-devel
<alyssa> linkmauve: Yeah, that function is used to load back
<alyssa> twiddled -> linear
<alyssa> the problem is that it's reading from write-combine memory
<alyssa> and it's reading horribly out of order, too
<alyssa> it could be optimized but it hasn't been a hotspot for us because we're generating mipmaps on the GPU
<alyssa> and yes we don't keep linear shadow copies
warpme_____ has joined #dri-devel
mvlad has quit [Remote host closed the connection]
lemonzest has quit [Quit: WeeChat 3.6]
<linkmauve> alyssa, a better solution for my usecase would be to generate the mipmaps manually and upload them without reading back.
<alyssa> where is the readback happening?
<alyssa> in your app or in mesa?
<alyssa> if it's your app, yeah dont do that
<alyssa> if it's in mesa, possibly lima needs fixin
<linkmauve> In Mesa of course, glGenerateMipmap() doesn’t really have much configuration. ^^
<HdkR> glGenerateMipmap, the pain
<mareko> hopefully a new round of #ifdef changes will fix that
<alyssa> lol
<alyssa> linkmauve: right.. then ideally we'd fix mesa
<alyssa> maybe u_generate_mipmap would be better for lima
<alyssa> it works OK for panfrost but the overhead is pretty high due to the piles of user<-->kernel roundtrips involved
<mareko> util_gen_mipmap is highly recommended
<mareko> util_blitter_generate_mipmap is better
<alyssa> how many mipmap gen functions do we have :p
<alyssa> and why have i written 2 more and not merged either one
<HdkR> The NIH is strong
<mareko> the blitter one has less CPU overhead because only a few states need to be changed between blits
<zf> I have a question about, uh, embedded vulkan, that people here might be able to answer?
<mareko> util_gen_mipmap just uses blit
<alyssa> mareko: right ok. both are going to have high overhead for us because every blit turns into a separate ioctl regardless
<alyssa> because of the render pass change
<alyssa> tilers are fun
<mareko> a compute-based solution would be very interesting, especially trying to generate 2 levels in the same workgroup
<mareko> or 4 levels at once
<alyssa> intel had that
<alyssa> it won't help for mali because imageWrite() is incompatible with compression
<zf> the question is... vulkan has an explicit feature bit for user clip distances, and in practice a lot of embedded devices don't support it. this is confusing, because user clip planes are a mandatory part of GL 1.0. is there some other way to do user clip planes with vulkan, or is there any explanation for this discrepancy?
<alyssa> and the win from compression for sampling mipmaps is going to far exceed the slower mipmap gen
<alyssa> zf: those embedded devices don't support gl either
<alyssa> gles yes gl no
<zf> ahhh
<alyssa> gles dont have clip planes
<zf> forgot about gles, thanks :D
<mareko> zf: clipping can be emulated with discard in FS
<mareko> a new round of #ifdefs didn't do anything, still getting exit status 3
<linkmauve> alyssa, doing it on the GPU should still be possible for non-compressed formats right?
<jenatali> It's a shame that job doesn't upload artifacts
<jenatali> I'd be happy to download the test exe and see whether it's a build problem or a wine problem
dv_ has quit [Quit: WeeChat 3.0]
dv_ has joined #dri-devel
<mareko> I'll try if !defined(__MINGW32__) first
<DemiMarie> alyssa: any particular reason for not trusting the GPU firmware to validate its inputs properly? danvet: could i915 virtualize the GuC queues to prevent direct guest/firmware interactions?
<mattst88> I don't know the context of the question, but given the variety of GuC bugs that have happened since it was originally created (for Broadwell!), I certainly don't trust the GuC :)
dcz_ has quit [Ping timeout: 480 seconds]
agd5f has quit [Remote host closed the connection]
jkrzyszt has quit [Remote host closed the connection]
<danvet> DemiMarie, I'm not sure that would work with the current design
<danvet> the guc knows which vf a queue belongs to
<danvet> so you'd practically write new fw I guess
<danvet> which you can't, because it's signed
<DemiMarie> danvet: only until somebody finds an exploit allowing code execution on the GuC 🙂
<alyssa> linkmauve: panfrost applies framebuffer commpression (AFBC) to textures when possible
<DemiMarie> mattst88: the context is that the current design for i915 SR-IOV allows guests to directly interact with the GuC firmware. Given the usual quality of such code, I consider this a security risk.
<DemiMarie> danvet: there is no rule saying the host cannot have access to VFs
<DemiMarie> they are just memory and/or PCI BARs, after all
agd5f has joined #dri-devel
<DemiMarie> I would not be surprised if a significant part of the SR-IOV work at Intel was hardening the firmware against malicious guests, but I still would prefer the host to proxy such interactions
alyssa has quit [Quit: leaving]
<DemiMarie> if they are just some memory and a doorbell register, one option would be to have the doorbell be write-protected, so that writes to the doorbell trap
<DemiMarie> the host then copies the queue contents to a staging buffer, validates them there, and finally submits them to the GuC
<linkmauve> alyssa, ah, I’m not on panfrost so can’t use that compression format.
<DemiMarie> mattst88: have any of those bugs caused the GuC to crash or corrupt its own memory?
MajorBiscuit has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
<linkmauve> alyssa: ah, I’m not on panfrost so can’t use that compression format.
<alyssa> linkmauve: yeah, I know
<alyssa> was explaining the reason we don't want to use a compute shader to generate mipmaps
<alyssa> doesn't apply to lima obviously :-p
<alyssa> (which doesn't have compute at all :P)
rmckeever has joined #dri-devel
<alyssa> but for lima, util_blitter_generate_mipmap is worth a try
<alyssa> or util_generate_mipmap
alyssa has quit [Quit: leaving]
fab has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
fab has joined #dri-devel
<anarsoul> linkmauve: patches are welcome :)
<anarsoul> I really wonder why it doesn't use blitter though
fab has quit [Read error: No route to host]
Guest2024 has joined #dri-devel
fab_ has joined #dri-devel
fab_ is now known as Guest2025
<anarsoul> linkmauve: do you happen to have a small reproducer?
<linkmauve> https://git.linkmauve.fr/inochi2d.git is a not-that-small reproducer.
<linkmauve> I can create a smaller one if you prefer.
<linkmauve> I use it with https://linkmauve.fr/files/Aka.inp which is a sample file for the format I implemented.
<anarsoul> linkmauve: basically I'm looking at st_generate_mipmap(), it should try blitter first
<anarsoul> which should be faster than 1.3s :)
MajorBiscuit has quit [Ping timeout: 480 seconds]
<mareko> do you get the software fallback or what?
<mareko> if a format isn't renderable, blitter won't help
Guest2025 has quit [Ping timeout: 480 seconds]
<linkmauve> `git clone` that, `cargo build --release --example=render`, then you can profile `target/release/examples/render Aka.inp`.
<linkmauve> It does much more than just uploading textures, but you should be able to reproduce at least.
<anarsoul> ugh, I don't know how to debug mesa calls from rust code
<linkmauve> I use gdb, same as from any other language.
<linkmauve> It’s a bit further in the call stack, but still extremely visible.
<linkmauve> anarsoul, I’m still on main from the 15th of November, I assume nothing changed wrt mipmap generation since then though.
<linkmauve> (Rebuilding Mesa atm.)
<anarsoul> Updating crates.io index :) I wonder how long it'll take on 4xA53@1.2GHz
tarceri has joined #dri-devel
<anarsoul> linkmauve: yeah, there were no changes to lima for quite a while
<linkmauve> Want my binary?
<linkmauve> With debug symbols and all.
heat_ has quit [Remote host closed the connection]
<anarsoul> nah, it's already at 73%
heat_ has joined #dri-devel
<linkmauve> After updating crates.io you’ll have to build the thing and all of its dependencies. :p
<anarsoul> linkmauve: yeah, I know. I hope it's not a lot
<psykose> 12 minutes is my guess
<linkmauve> Takes 28.45s to build on four cores of Neoverse N2.
<anarsoul> psykose: I like your estimate
<anarsoul> but it's almost done
<linkmauve> So yeah, multiply that by big cores only → little cores only, and you get approximately 12 minutes. :D
<anarsoul> have you seen an SBC with Mali4x0 GPU and big cores? :)
<linkmauve> I build on a big core CPU, and then run on a 4xx GPU. ^^
<linkmauve> Doesn’t need to be the same computer.
<anarsoul> linkmauve: how do I force GLFW to use X11?
<linkmauve> Hmm, probably export WAYLAND_DISPLAY=nope or something like that.
<linkmauve> I haven’t compiled mine with X11 support.
gouchi has quit [Remote host closed the connection]
<anarsoul> linkmauve: so it never reaches st_generate_mipmap()
<anarsoul> how do you know that it spent 1.3s generating mipmaps?
<linkmauve> anarsoul, it is in st_generate_mipmap() that it loads the tiled image back, detiling it on the way.
<linkmauve> It’s a total of about 15s for the twelve 2048×2048 textures I generate mipmap for, on my phone.
<anarsoul> it hits blitter path for me
<anarsoul> linkmauve: can you set a breakpoint on lima_do_blit and check where it bails out?
<anarsoul> lima doesn't support swizzled formats in lima_do_blit(), but I get PIPE_FORMAT_R8G8B8X8_UNORM, so it should be perfectly fine
<anarsoul> I presume you don't have LIMA_DEBUG=noblit set?
<linkmauve> I don’t.
<linkmauve> And it doesn’t enter that function.
<anarsoul> huh?
<linkmauve> This is my flamegraph, if this is of any help.
danvet has quit [Ping timeout: 480 seconds]
<anarsoul> oh
<anarsoul> looks like it copies data in st_finalize_texture()
<anarsoul> which is about to be overwritten?
alyssa has joined #dri-devel
<anarsoul> I'm not really familiar with st_generate_mipmap(), but it looks like st_finalize_texture() call from st_generate_mipmap() really messes things up
<alyssa> eric_engestrom: left some links covering what you talk about but yeah could use some summarizing and aggregation because it's daunting rn
<alyssa> linkmauve: sorry are you rewriting inochi2d in rust? :p
<anarsoul> linkmauve: feel free to file an issue at gitlab, but it looks like a generic mesa st issue
<anarsoul> copying data around while it will be overwritten pretty soon doesn't look right to me
<linkmauve> alyssa, I might have done a few bits of that yes. o:)
<linkmauve> For now only the rendering is correct, I was working on params before falling ill, and only today I’m starting to feel a bit better.
<linkmauve> anarsoul, ack, thanks for the debug!
<alyssa> linkmauve: brain
<mareko> Marge is chilling again, so I clicked the Merge button with passing CI in one MR
<mareko> or maybe not, but it looked like it was chilling
<anholt_> sure looks like marge has been busy to me
q66 has quit [Quit: No Ping reply in 180 seconds.]
<jenatali> Yep, it was working on !20042, which now will need to restart
<mareko> I had a passing MR and Marge not merging, but then realized I restarted the failing pipeline, so it wasn't Marge who started the CI, and I forgot about that
q66 has joined #dri-devel
<alyssa> Marge has been busy lately ... I hope she gets some rest soon. I don't want her to burn out.
<anarsoul> mareko: airlied: looks like you looked into st_generate_mipmap() recently. Any ideas why it calls st_finalize_texture() and why st_finalize_texture() does copy_image_data_to_texture() for all the levels which is kind of pointless when we're about to generate mipmaps?
<anarsoul> it looks like it does it even for the drivers that support hw mipmap generation
<bnieuwenhuizen> agd5f: please don't forget to upstream 7000 series firmware :)
<alyssa> nyerr I want to go deleting
heat_ has quit [Read error: No route to host]
heat has joined #dri-devel
<airlied> anarsoul: it should possible have a fast path in finalize that bypasses that for mipmap
<mareko> anarsoul: if "recently" means in the last 14 years, then yes
<airlied> my last contributions were just refactors, non-functional ones
<mareko> improvements welcome
<airlied> but make sure you actually hit that path
<airlied> it shouldn't be happening on the common case I don' think
heat has quit [Remote host closed the connection]
<anarsoul> airlied: it does hit it, see https://linkmauve.fr/files/lima-flamegraph.svg
heat has joined #dri-devel
warpme_____ has quit []