FYI, the solution for r300 in both classic and Gallium drivers is to modify the shaders. It sucks, and I've spoken out against modifying them since it results in more code created and cached, but it's necessary because the WPOS is not available to the fragment shader. So we have to re-route it through a texcoord.
If there really isn't any other way, you could modify your shader compiler to copy WPOS to a temp and properly set it up for usage. On the other hand, part of the reason this is acceptable in r300 is that we do SSA and DCE during shader compile, so a double inversion doesn't hurt us as much. :3 ~ C. On Wed, Jan 20, 2010 at 8:59 AM, Christoph Bumiller <e0425...@student.tuwien.ac.at> wrote: > On 01/20/10 16:21, Brian Paul wrote: >> Luca Barbieri wrote: >>> Investigating a vertical flipping problem in Doom 3, I discovered that >>> fragment shader wpos handling is incorrect in the nv40 driver. >>> >>> The issue is that nv40 provides a "position" register with OpenGL >>> semantics, so if TGSI_SEMANTIC_POSITION is directly wired to it (as >>> the nv40 driver incorrectly does currently), then the inversion >>> generated by the state tracker is counterproductive and causes >>> misrendering. >>> This can be confirmed with trivial/fp-tri position.txt >>> >>> I'm not sure how to fix it though. >>> Clearly, the driver could try to invert it again itself, but it's >>> stupid to invert it twice, especially considering that the viewport >>> would be needed as input two times. >>> Detecting the inversion robustly (to remove it) in the driver is also >>> impossible because the driver cannot know that the constant in SUB >>> temp, const, wpos will be set as the window height. This is always >>> true for TGSI programs produced by Mesa, but not in general. >>> >>> It seems that a Gallium interface change is necessary for optimal >>> results (i.e. a fragment program that directly uses the hardware >>> register). >>> >>> I see the following options: >>> 1. Add a TGSI_SEMANTIC_POSITION_YINVERTED register and have mesa st >>> use it. This requires to change all drivers. >>> 2. Add a TGSI_SEMANTIC_FB_HEIGHT register and use it to invert the >>> position. This requires to change all drivers. >>> 3. Add an "fb height" flag to const declarations or similar TGSI token >>> and have mesa st set it on its window height const. This does NOT >>> require to change all drivers, but there will be an unused constant >>> slot and it's somewhat ugly. >>> 4. Assume that if a code sequence like the one used by mesa st to >>> invert wpos is present, the constant is the fb height and remove the >>> sequence. Assert on any other use of the position semantics. This >>> works right now and requires no changes in Mesa, Gallium, or other >>> drivers, but it's clearly not a good design. >> >> I wonder if there's a hardware flag somewhere that can control this. >> For Direct3D, the origin would be in the upper-left corner. Either >> NVIDIA has a bit to set that convention or they modify their DX >> shaders to follow OpenGL's convention. Any idea? >> >> -Brian >> > On nv50, blob always performs a MAD operation on gl_FragCoord, with > constants height, +/-1, so there is no hardware switch present for > handling GL_ARB_fragment_coord_conventions, ... > other than the one that turns the whole rendering operation upside down > - having that one set to Y_0_TOP is the reason nv50's FragCoord is as > the st expects. > > Since nv40 pipe doesn't invert anything itself, it seems it also renders > Y_0_TOP (coordinates after vport transform) but FragCoord is the other > way ? That's odd, makes me think there should be a switch, but then ... > maybe they just built it the OpenGL way back then. > (do you have GL_ARB_fragment_coord_conventions ?) > > Well, if there is none, another solution might be adding something like > pipe_screen::get_hw_convention(PIPE_CONVENTION_FRAG_COORD_ORIGIN). > Hm, that would be nicer if it had more than 1 use case though. > > Christoph >> >> ------------------------------------------------------------------------------ >> Throughout its 18-year history, RSA Conference consistently attracts the >> world's best and brightest in the field, creating opportunities for >> Conference >> attendees to learn about information security's most important issues through >> interactions with peers, luminaries and emerging and established companies. >> http://p.sf.net/sfu/rsaconf-dev2dev >> _______________________________________________ >> Mesa3d-dev mailing list >> Mesa3d-dev@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson <mostawesomed...@gmail.com> ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
