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 ------------------------------------------------------------------------------ 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
