[Mesa-dev] [Nouveau] [PATCH 4/4] nvfx: random cleanups of the state validation code

[Lucas Stach]

Am Dienstag, den 17.01.2012, 18:22 +0100 schrieb Patrice Mandin:
> Le Tue, 10 Jan 2012 12:41:04 +0100
> Lucas Stach <dev at lynxeye.de> a écrit:
> 
> > Signed-off-by: Lucas Stach <dev at lynxeye.de>
> > ---
> >  src/gallium/drivers/nvfx/nvfx_state_emit.c |   49 ++++++++++++---------------
> >  1 files changed, 22 insertions(+), 27 deletions(-)
> > 
> > diff --git a/src/gallium/drivers/nvfx/nvfx_state_emit.c b/src/gallium/drivers/nvfx/nvfx_state_emit.c
> > index e2cfb76..a959015 100644
> [snip]
> > @@ -302,11 +303,7 @@ nvfx_state_validate_common(struct nvfx_context *nvfx)
> >  	if(dirty & NVFX_NEW_SR)
> >  		nvfx_state_sr_validate(nvfx);
> >  
> > -/* All these dependencies are wrong, but otherwise
> > -   etracer, neverball, foobillard, glest totally misrender
> > -   TODO: find the right fix
> > -*/
> > -	if(dirty & (NVFX_NEW_VIEWPORT | NVFX_NEW_RAST | NVFX_NEW_ZSA))
> > +	if(dirty & NVFX_NEW_VIEWPORT)
> >  	{
> >  		nvfx_state_viewport_validate(nvfx);
> >  	}
> [snip]
> 
> After a small revert/compile/try, reverting just that part makes
> rendering working again in ut2004demo.

Thanks for taking the time to hunt this down. So the comment was not
specific enough and so I was led into the illusion that this junk is
safe to remove after testing all the apps listed there.

So it seems this workaround is needed for nv3x. I will send a follow up
patch to correct this.
> 
> I noticed another small regressing with it, the splashscreen bitmap is
> also not displayed anymore, so I'll investigate a bit further. Maybe no
> need to revert the whole series.
> 

Woah, nv3x really has some weird problems. My nv49 shows the
splashscreen just fine. Fortunately I get a nv35 myself in the near
future, so I can test this on my own.