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
