<tomeu>
couldn't find any other gallium driver inverting when sampling
<bbrezillon>
tomeu: it's just mandatory for partial updates, so yes, it will be useful ;)
<bbrezillon>
all I need to do on top is restrict the area(s) where the "reload-fb-content" shader is applied
<bbrezillon>
tomeu: and thanks again for sorting this out
<daniels>
tomeu: not off the top of my head, but if you look at the spec for FBOs, you can see that they're treated as having an inverted co-ord space - that they use texture co-ord space, whereas winsys buffers do not
<daniels>
probably asking on #dri-devel would be easier, since I'm disappearing very shortly
<daniels>
and indeed, thanks very much to you both :)
mearon has quit [Quit: WeeChat 1.7.1]
mearon has joined #panfrost
pH5 has quit [Quit: bye]
stikonas has joined #panfrost
pH5 has joined #panfrost
marcodiego has quit [Read error: Connection reset by peer]
<robclark>
tomeu, daniels: btw, mesa/st should be handling all the FBO flip for you, and I don't even think the driver reliably knows which buffers are FBO or not.. nothing is really inverted, mesa just fixes up things like fragcoord to make it look that way to the app.. see nir_lower_wpos_ytransform.. or there is some equiv thing for drivers using tgsi
<robclark>
if you need to know about FBO vs non-FBO in gallium driver, it sounds like you are doing something rather wrong..
rhyskidd has quit [Ping timeout: 272 seconds]
rhyskidd has joined #panfrost
<alyssa>
robclark: That's probably a deeper issue, yes...
<alyssa>
What is the right way to know whether to invert a buffer (for scanout and/or for sample), then?
<robclark>
the gallium driver should *never* invert
<alyssa>
The blob definitely has a negative stride for scanout and a positive one for FBOs..
<robclark>
it is all FBO's
<robclark>
just treat everything (incl scanout) like FBO
<alyssa>
If I don't invert at all, scanout is upside down.
<robclark>
that means you have something else wrong then, maybe there is an upside-down bit
<robclark>
it isn't actually exposed anywhere to the gallium driver whether you are rendering to an FBO or not.. these are state-tracker level concepts, not pipe driver level concepts
<alyssa>
What about the sign of the viewport's Y?
<robclark>
mesa/st flips that around for you
<robclark>
from gallium PoV there is no difference between fbo and window system buffer
<alyssa>
If I have a negative Y in pipe_viewport_state...?
<anarsoul>
robclark: well, we need to know about FBO vs non-FBO in lima. Mali4x0 can render and simple into tiled buffers, but display driver can't untile them. Rendering into and sampling from tiled buffers is faster, so using linear buffers everywhere isn't an option
<alyssa>
anarsoul: That's a question of the SCANOUT/DISPLAY_TARGET flags in the resource
<alyssa>
Which I think is orthogonal to what we're talking about
<anarsoul>
can't you use the same flags for selecting sign of stride?
<robclark>
so looks like st_update_viewport() fixes up vp->translate[1] for Y_0_TOP
<alyssa>
That's what I'm doing now, but as Rob pointed out that's probably wrong
<anarsoul>
alyssa: and I'm trying to understand why :)
<robclark>
you can look around mesa/st for Y_0_TOP and Y_0_BOTTOM for all the things it massages so from gl standpoint things look inverted while in memory they are actually not
<alyssa>
Ohh!!!!!
<alyssa>
I get it now!
<alyssa>
I feel like such a dork nowz!
<alyssa>
D'oh d'oh d'oh d'oh
<alyssa>
Thank you!
<robclark>
it is kinda funny that mali literally implements upside down rendering.. I guess the hw designers took the gl spec too seriously :-P
<alyssa>
robclark: :D
<alyssa>
robclark: It's not literally upside down, it's just that the stride is signed
<alyssa>
The driver is doing it literally upside down, though
<robclark>
I guess I can't speak for nv blob.. adreno blob defn does more or less the same thing mesa does..
<alyssa>
robclark: Okay, but now my scissor min/max is wrong..?
<robclark>
well, signed stride is weird..
<robclark>
I suppose mesa/st flips those too
<robclark>
it's been a while since I looked..
<robclark>
I'd probably be blissfully ignorant of mesa/st's Y_0_TOP/BOTTOM stuff it does to hide the FBO vs winsys if I didn't have to write the lower_wpos_ytransform pass to get nir instead of tgsi ;-)
<alyssa>
Hehe
NeuroScr has joined #panfrost
<alyssa>
robclark: ....Now backface culling is backwards D:
<robclark>
thats why it is backface?
<alyssa>
robclark: I.e. CW/CCW are flipped now. Which I guess means I have some other bug somewhere else too
<alyssa>
(Symptom is -btexture drawing the backfaces and none of the front faces)
<alyssa>
alyssa: Implement fabs/fneg; the fmov removal broke master and you have nobody to blame since you Reviewed-by that :P
<robclark>
yeah, I guess you somehow had some combination of bugs that cancelled each other out?
<alyssa>
It happens a lot :D
<alyssa>
This fixes an Xwayland bug, so that's good
<robclark>
nice
BenG83 has joined #panfrost
yann has quit [Ping timeout: 258 seconds]
<alyssa>
robclark: Out of curiousity, what happens if you use a negative stride for the fb on adreno?
<alyssa>
I wonder
<alyssa>
("A worrisome question")
<robclark>
iommu faults, I expect, since it would be an unsigned #
<HdkR>
The biggest of framebuffers
<alyssa>
robclark: No chance the hw would do a wrapping 2s complement shtick?
<robclark>
the *hugest* framebuffers
<robclark>
I don't expect so
<alyssa>
I've known a lot of framebuffers in my life, and these are the hugest.
<HdkR>
robclark: Is your topend FB limit 16k?
<robclark>
sounds plausible.. need to double check..
<HdkR>
I think that's the largest outside of NV atm
<robclark>
yeah, 16k would match what I have in tex state
<alyssa>
robclark: So, Gallium does flip front_ccw if it's flipping the transform
<robclark>
and qcom is pretty good about being consistent (ie. not rendering to things it can't sample from, and supporting same compressed formats everywhere)
<robclark>
alyssa: I expect so, I'd have to go back and look at the code, but there is no place were I differentiate between fbo and winsys
<HdkR>
Sadly Mali is still at 8k
<robclark>
it is all fbo's all the time for gallium drivers
<alyssa>
Tasty
<alyssa>
ClipOrigin
<alyssa>
uh
<robclark>
there might be some sneaky way to figure out what he y-flip is but I don't think there is.. I briefly thought I'd need it for lowering fb reads for advanced-blend..
<robclark>
and then I realized the fb coords were already matching the coord I need to sample
<alyssa>
Tada
<HdkR>
robclark: Does gallium not have a way to expose the D3D clip origin compatibility thing to the backend?
<HdkR>
Some hardware has hardware flipping support so you don't pay additional costs depending on what you're targeting
<robclark>
HdkR: if it was supported, I'd expect it is self contained in mesa/st
<HdkR>
Even if it is just a couple of fmul :P
<HdkR>
Yea, that's what I would think as well
<robclark>
I doubt a couple fmul is the thing to optimize, most real shaders are many 100's of instructions or more these days
<HdkR>
Yea. Probably why Nouveau hasn't taken the time to optimize it away
<HdkR>
Especially on OP hardware
<robclark>
I guess that means nv also has flip support in hw..
<HdkR>
Yea, this is known
<robclark>
silly thing to waste transistors on ;-)
<HdkR>
When you have 815mm^2 to waste I'm sure it seems tiny
<robclark>
to be fair, I think adreno has bits for d3d vs gl pixel-center and other differences like that.. although I guess that might be more annoying to workaround in sw..
<HdkR>
Right
<HdkR>
It could also be a by-product of being able to program sampling positions
<HdkR>
So you get it for free
<HdkR>
(This is how ArtX could get D3D versus GL pixel centers)
<HdkR>
But then Nintendo hecked it up and gave everyone 7/12 pixel centers!
* HdkR
flips table
<robclark>
heh
<alyssa>
robclark: Here's a fun one.. gl_FragCoord on Mali is exposed per GL conventions in hw. But apparently they want a unified compiler between D3D and GL, since the blob always emits an affine transform alongside it (with a 2x2 matrix in the uniform)
<robclark>
are you sure that isn't just handling fbo vs winsys (ie Y_0_TOP vs Y_0_BOTTOM)? Do you get different uniforms plugged in for fbo vs winsys?
<alyssa>
Oh, that's possible as well
<alyssa>
I'm mostly just surprised they're not keying
<alyssa>
Maybe it makes sense not to, tho
herbmilleriw has quit [Quit: Konversation terminated!]