<alyssa>
on one hand this seems excessive to sneek into 20.3
<alyssa>
otoh this is... essentially entirely obscure bug fixes that /do/ need to be backported...
<alyssa>
4 distinct bugs fixed here relating to AFBC.
gouchi has quit [Remote host closed the connection]
<alyssa>
21.3, sorry
<kisak>
sneaking anything into 20.3 at this point is excessive :P
<alyssa>
kisak: pandemic isn't over yet! :-p
<alyssa>
it will still be 2020 until the mask mandates get lifted :-p
<alyssa>
we are all in 2020 on this blessed day
<kisak>
when mesa 20.14 is released I guess I'm buying the alcohol
<alyssa>
lol
<kisak>
joke aside, any bugfixes that make your life a little easier should definitely land in stable releases, especially 21.3 since it's still in pre-release testing
<alyssa>
yeah, this MR was supposed to go in before the 21.3 branchpoint but then uni deadlines happened
<alyssa>
(Fix a bunch of bugs affecting systems on 21.2, and then "just" delete some code to make the newer systems significantly faster)
<alyssa>
Read: major optimization got disabled in 21.2 but only on the architecture we do CTS runs on ;-)
<alyssa>
tomeu: also added Piglit to our CI so now I'm forced to not break piglits, and the "turn the opt on" MR found a bunch of piglit regressions (even once CTS was clean) that presumably affect the older hw shipping in prod now...
<alyssa>
tomeu: how could you ;-p
rasterman has joined #dri-devel
<HdkR>
Does anyone have a CPU profiling tool that can collapse duplicated symbol names? I find that perf top just..doesn't
Ahuj has quit [Ping timeout: 480 seconds]
pushqrdx has quit [Remote host closed the connection]
<mareko>
imirkin: yes
<alyssa>
....Yikes.
<alyssa>
Gallium allocates a resource as PIPE_R16G16B16_FLOAT
<alyssa>
It then creates a surface with that resource interpreted as PIPE_R16G16B16X16_UNORM and renders to it.
<alyssa>
=> MMU fault.
<alyssa>
(in piglit ./bin/arb_texture_view-rendering-formats)
<alyssa>
PIGLIT: {"subtest": {"render to GL_RGB16F as GL_RGB16" : "fail"}}
<alyssa>
on a driver that has RGB16F renderable but RGB16 not
<alyssa>
which is admittedly a stupid thing for a driver to advertise, heh
<alyssa>
oh but mesa/st actually asks for RGBX_UNORM16 for GL_RGB16. uh.
<alyssa>
(Admittedly also a
<alyssa>
stupid test/spec)
crabbedhaloablut has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
loki_val has quit [Ping timeout: 480 seconds]
sarnex has quit [Quit: Quit]
<alyssa>
freedreno solves this by not allowing rendering or sampling for any 48-bit formats.
<alyssa>
("solves", but if it passes the tests..")
sarnex has joined #dri-devel
<imirkin>
alyssa: you should assume that RGB formats don't work
<imirkin>
no hardware supports them, so the software isn't ready for it either
<alyssa>
imirkin: Got it.
<alyssa>
our hw 'can' support them but I am totally good with "just don't advertise support" as a solution
<imirkin>
yeah, same with adreno hw
<imirkin>
which can texture but not render
<imirkin>
but at that point, you run into problems of "i allocated a texture, and expected GL_RGB16 to be renderable, whaaaa"
<mareko>
npot bpp screws up tiling
<alyssa>
imirkin: yep yep
<imirkin>
yeah, there are practical reasons why it's not a good idea either :)
<alyssa>
mareko: the mali hw can chew through it. I shudder to imagine the perf implications
<imirkin>
RGB32 is supported for PIPE_BUFFER only
<imirkin>
and i suspect someone at some point has made RGB8 semi-work
<mareko>
a pixel of npot bpp can also straddle 2 cache lines, which I can imagine would be pretty annoying from the hw design perspective
<alyssa>
at any rate this is unrelated to my AFBC issues :|