<daniels>
chewitt_: thanks! could you please send that as an MR?
<chewitt_>
daniels, with or without the T628 enable in the whitelist?
chewitt_ is now known as chewitt
<daniels>
I assume the 628 is still broken?
<chewitt>
I didn't get far with it
<daniels>
in that case separate sounds good - one to just get the Bifrost IDs in line with the rest, and then another can add 628 to the whitelist when it's safe to be whitelisted :)
<chewitt>
k
cwabbott has joined #panfrost
<chewitt>
MR 4870 submitted
stikonas has joined #panfrost
yann has quit [Read error: Connection reset by peer]
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #panfrost
NeuroScr has quit [Quit: NeuroScr]
icecream95 has quit [Ping timeout: 246 seconds]
bnieuwenhuizen has quit [Ping timeout: 272 seconds]
raster has quit [Ping timeout: 272 seconds]
yann has joined #panfrost
raster has joined #panfrost
Elpaulo has quit [Quit: Elpaulo]
Elpaulo has joined #panfrost
bnieuwenhuizen has joined #panfrost
raster has quit [Remote host closed the connection]
<tomeu>
sorry, I lost track of who I have mentioned it to :)
<tomeu>
not completely sure alyssa will agree, but I think we would prefer to whitelist GPUs only once they are at rough parity with existing ones and are under CI
<tomeu>
otherwise we'll be supporting people who want to try it out instead of writing code
<chewitt>
no problem
<chewitt>
I'll close the MR
<alyssa>
icecream95: ..or sw decompress. but who knows
<alyssa>
tomeu: "not completely sure alyssa will agree, but I think we would prefer to whitelist GPUs only once they are at rough parity with existing ones and are under CI"
<alyssa>
^ This is exactly my policy.
<alyssa>
mesa ships to end-users automatically via distributions. If we ship a bad driver, we will cause real problems for real people, and we probably won't even know about it. Hence the whitelist.
<robmur01>
however AFAIK whether SoC vendors enable support for the various proprietary formats at integration time depends on whether they can be bothered to sort out licenses ;)
<robmur01>
according to the RK3288 datasheet, "W" variants "Support DirectX", which presumably implies the old regular (and "c") ones don't
<robmur01>
(much like there's apparently also a "D" variant with whatever Dolby licensing applies to the audio IP)
<alyssa>
robmur01: Cute, ok :)
<alyssa>
I don't suppose any windows mali actually happened..
<alyssa>
tomeu: FBO stuff looks remarkably similar to midgard mfbd
<alyssa>
big diff is block = TILED is always true
<alyssa>
and .unk3 = 0xc,
<alyssa>
for an FBO
<alyssa>
.unk3 = 0x4,
<alyssa>
for no
<alyssa>
so I assume unk3 is the real layout specifier, probably shifted some bits
<alyssa>
It's not clear to me whether that's AFBC or tiled.
<alyssa>
Easy way to find out :3
<alyssa>
`idea2` is current branch of bifrost hacks for me
<alyssa>
tomeu: shadow crash is since rt_count=0, working on it
<alyssa>
icecream95: Oh, that's an incredible find, nice!!
<alyssa>
I suspected something like that given the GL_QUADS support (etc) but nice to see a primary source
<HdkR>
Oh neat
<alyssa>
I should check if Bifrost supports quads..
<alyssa>
The obvious tests for it require x11 which I don't have piped through yet
<cwabbott>
I wonder if they support all the super-fun legacy stuff like point-coord replacement then
<alyssa>
cwabbott: I wouldn't be surprised tbh.
<alyssa>
Given how literally they seem to interpret the spec in hw :)
raster has quit [Quit: Gettin' stinky!]
<alyssa>
cwabbott: As it is, gl_PointCoord is done as a magic `elements` value on midgard, with normal ld_vary instructions
<alyssa>
same with gl_FragCoord (c.f. bifrost sysval)
<alyssa>
so ignoring Y-flips, you don't need to key the shader.
<cwabbott>
yeah, but with legacy stuff you can replace literally any varying with gl_PointCoord
<cwabbott>
for compatibility with legacy fixed-function stuff
<alyssa>
exactly
<cwabbott>
oh, yeah
<alyssa>
it's a magic gl_PointCoord address so the replacement is just scribbling over the address
<cwabbott>
right
<cwabbott>
iirc it wasn't like that on bifrost
<alyssa>
not sure if there's a gl_PointCoordFlipped address too... right now I ignore the orientation and since the stars in neverball are symmetric nobody's noticed :p