ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://oftc.irclog.whitequark.org/panfrost - <macc24> i have been here before it was popular
rasterman has quit [Quit: Gettin' stinky!]
vstehle has quit [Ping timeout: 480 seconds]
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #panfrost
davidlt has joined #panfrost
vstehle has joined #panfrost
davidlt has quit [Ping timeout: 480 seconds]
erlehmann has quit [Ping timeout: 480 seconds]
davidlt has joined #panfrost
erlehmann has joined #panfrost
davidlt has quit [Ping timeout: 480 seconds]
<alyssa>
Ohhh the psiz issue is why the DDK translates "gl_PointSize = <psiz>" to "if (is_drawing_points) { gl_PointSize = <psiz> }"
<alyssa>
whether a shader key is better/worse than a sysval is unclear
<alyssa>
there's a cheap way to key it
<alyssa>
If psiz written, nothing to key.
<alyssa>
Ifer
<alyssa>
er
<alyssa>
If psiz is not written, nothing to key.
<alyssa>
If psiz is written, duplicate the final shader and delete the psiz write.
<alyssa>
(Optionally do it before RA and DCE)
* alyssa
back to Valhall choo choo
<alyssa>
Ooh there's an optimization for IDVS on bifrost -- wait focus Alyssa
<alyssa>
Did a rough impl of the "stupidly cheap key" strategy
<alyssa>
seems to work and should be a bit cheaper than what the DDK does
<alyssa>
~87% pass rate, you know what? i'll take it
<icecream95>
Is the dEQP pass rate related to ASTC?..
<alyssa>
1232 crashes from ASTC, so yes :-p
<icecream95>
..So this is for Valhall?
<icecream95>
What would be the point in ever using wide ldr?
<alyssa>
Yes, but I imagine the equivalences hold for Bifrost too
<alyssa>
Dunno
<alyssa>
unless er wait
<alyssa>
narrow vs wide is a valhall thing isn't it
<icecream95>
I think there is different behaviour for error blocks?
* alyssa
has too many Malis
<icecream95>
On Midgard and Bifrost, I think that LDR is always narrow but HDR is always wide
<icecream95>
(But without the decode mode extension, I don't think that we would be allowed to use the LDR format even if there are no HDR blocks in the texture)
<alyssa>
*nod*
<icecream95>
So therefore there is no point in me writing a compute kernel to check for HDR blocks. :)
<alyssa>
heh
<alyssa>
Mesa probably needs the astc_decode_mode ext wired through but I'm not volunteering
<alyssa>
jekstrand: You've been volunteered
anarsoul|2 has quit [Read error: Connection reset by peer]
<icecream95>
..If there was support for mapping memory as not write-combine, then a bunch of the compute kernels I've been writing wouldn't be so necessary
anarsoul has joined #panfrost
nlhowell has quit [Ping timeout: 480 seconds]
<icecream95>
alyssa: Are you ever going to do anything about 'panfrost: Process scissor state earlier', or do you want me to create an MR?
<alyssa>
Please create an MR
<alyssa>
been very distracted
<icecream95>
With my or your version of the patch?
<alyssa>
The simplest of the set of working patches
nlhowell has joined #panfrost
<icecream95>
Can I assign it straight to Marge?
<icecream95>
(This is your patch)
<alyssa>
Ummm
<alyssa>
I should probably do a piglit run of it .. I remember seeing flakes from my patch
<alyssa>
but might've be unrelated
* icecream95
drops the "/assign @marge-bot" from the merge request description, and creates the MR
<alyssa>
creating the MR is a great way to get me to get it landed, you know how I loathe open MRs :-p
<alyssa>
For each block size, there are 3 different formats
<alyssa>
LDR / non-sRGB (internally fp16)
<alyssa>
LDR / sRGB (internally unorm)
<alyssa>
HDR / non-sRGB (internally fp16)
<icecream95>
I can only see two, COMPRESSED_RGBA_ASTC_*_KHR and COMPRESSED_SRGB8_ALPHA8_ASTC_*_KHR
<alyssa>
---right
* alyssa
grumbles
<alyssa>
I guess COMPRESSED_RGBA_ASTC_*_KHR is HDR if the _hdr ext is exposed but LDR if the _hdr ext is not exposed?
<alyssa>
which is what Piglit tests for
<alyssa>
you're right that doesn't require adding new enums, so much as a PIPE_CAP_ASTC_IS_HDR
<icecream95>
I think there is an Arm blog post that makes it more clear, but yes I think the !SRGB format changes meaning depending on the extensions exposed
<alyssa>
*nod*
<alyssa>
In that case I agree we don't need enums, just a CAP that controls what the non-sRGB pipe formats mean
<alyssa>
assuming this is true for VK too
<alyssa>
(which shares PIPE_FORMATs)
<icecream95>
Oh, it seems that Vulkan does have separate HDR formats?
<icecream95>
"Should we introduce new format enums for HDR?" "Yes."
<icecream95>
But using the HDR format for LDR textures is still allowed under Vulkan
rasterman has quit [Quit: Gettin' stinky!]
<alyssa>
Yeah I was just reading that, you beat me by a minute
<alyssa>
". if this extension is supported then sampling from a VK_FORMAT_ASTC_4x4_UNORM_BLOCK image format may return HDR results"
<alyssa>
may but not must
<alyssa>
so the CAP approach is legal in VK too but maybe not optimal
<alyssa>
I'd lean towards new enums because they correctly model the defined behaviour of ASTC, rather than a quirk of GL that mesa/st can deal with itself
<alyssa>
although that requires surgery on st_formats.c
<alyssa>
I don't know
nlhowell is now known as Guest2056
nlhowell has joined #panfrost
<alyssa>
There's no good way to handle
nlhowell is now known as Guest2057
nlhowell has joined #panfrost
<alyssa>
Passed: 1330/1330 (100.0%)
<alyssa>
it likes my ASTC implentation :-D
Guest2056 has quit [Ping timeout: 480 seconds]
Guest2057 has quit [Ping timeout: 480 seconds]
nlhowell is now known as Guest2059
nlhowell has joined #panfrost
Guest2059 has quit [Ping timeout: 480 seconds]
nlhowell has quit [Ping timeout: 480 seconds]
nlhowell has joined #panfrost
<cphealy>
Regarding the above astc discussion, is this all in the context of Vulkan only or will this work result in increased ASTC capabilities with the GLES APIs? Here's what I'm seeing for extensions supported today with the Mali DDK and Mesa 22.0 on the Mali G52:
<icecream95>
Wait.. so <Valhall *does* support rgb9e5 decode modes?
<cphealy>
I'm looking at G52 (Bifrost)
<HdkR>
Nobody supports the _hdr extension in mesa. That would probably take more wiring up. HDR is already not great under Linux
<icecream95>
cphealy: Currently we decode ASTC textures as HDR even though the extension isn't exposed
<cphealy>
For sure HDR (in general) has a lot of work to still be done...
<cphealy>
At least in the context of Linux, Mesa, and DRM/KMS drivers/API.
<cphealy>
idecream95: when you say we currently decode ASTC textures as HDR even though the extension isn't exposed, can you elaborate on this? Do you mean that even if I have a LDR ASTC asset, you treat it as an HDR compatible texture format?
<cphealy>
If so, are there negative RAM implications to this when doing LDR ASTC?
<icecream95>
cphealy: A single ASTC texture can have both HDR and LDR blocks within it. Decoding LDR textures as HDR increases the space used in the texture cache, but not in system RAM
<icecream95>
The blob would likely also decode LDR textures as HDR in OpenGL ES
<icecream95>
(An "LDR ASTC texture" is only an ASTC texture which has no HDR blocks)
<cphealy>
makes sense, tnx.
<HdkR>
What sort of evil being would allow LDR and HDR in the same format.
<icecream95>
HdkR: Someone who wants a normal LDR texture with just a couple of SUPER BRIGHT pixels in it?
<cphealy>
HdkR: that's a good question. I struggle to see a use case where this would be useful. It would be like having a movie that has some macroblocks in LDR and some macroblocks in HDR.
<HdkR>
Just make the whole thing HDR then :P
<icecream95>
HdkR: But then you have less precision for blocks which don't need it
<cphealy>
Perhaps there's a RAM storage savings for the case where you have a large image that is all black but with some image data that benefits from HDR in 10% of the full image?
<icecream95>
HDR and LDR blocks are the same size, 128 bits
<cphealy>
fireworks at night in a 1080p image? ;-)
<HdkR>
Ah, precision changes, interesting
<HdkR>
Still evil. Use a larger encoding space at that point :D
<icecream95>
It only costs a ~single bit in the format to encode whether it is HDR or LDR
<icecream95>
HdkR: I don't think precision changes, it's just that each endpoint takes up more space, so you might not be able to fit everything in 128 bits
<icecream95>
How it actually works is quite complicated, go read the ASTC spec yourself