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
<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
<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]
<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.
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?
<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
<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>
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