Re: mesa: Changes to 'master'

> -----Original Message-----
> From: Keith Whitwell [mailto:keith <at> tungstengraphics.com]
> Sent: 2007年8月31日 18:27
> To: Nan hai Zou
> Cc: MESA-Devel
> Subject: Re: mesa: Changes to 'master'
> 
> Nan hai Zou wrote:
> >  src/mesa/drivers/dri/i965/brw_clip_line.c  |    7 +
> >  src/mesa/drivers/dri/i965/brw_clip_state.c |    2
> >  src/mesa/drivers/dri/i965/brw_clip_tri.c   |  105
> ++++++++++++++++++++++++++++-
> >  src/mesa/drivers/dri/i965/brw_clip_util.c  |   12 ---
> >  4 files changed, 112 insertions(+), 14 deletions(-)
> >
> > commit diffs at http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=summary
> >
> > New commits:
> > commit b47c9f8c915ae4ca8c7fa5ee3b6b64f17c38b569
> > Author: Zou Nan hai <nanhai.zou <at> intel.com>
> > Date:   Fri Aug 31 13:42:20 2007 +0800
> >
> >       optimize 965 clip
> >       1. increase clip thread number to 2
> >       2. do cliptest for -rhw
> 
> Nan hai Zou,
> 
> Isn't it the case that the hardware bug that requires the -rhw
> workaround is fixed in later versions of the hardware?  It would be good
> to turn the workaround off in those cases - both in the clipper and the
> vertex shader.
> 
> Likewise, the various workarounds for send destination dependency
> checking (eg. in brw_vs_emit.c emit_math1(), etc.) can be turned off in
> later revisions and steppings of the hardware.  This is probably quite
> important as I believe the workaround defeats built in latency-hiding
> characteristics of the hardware.
> 
> It's also worth noting that the hardware support for guard band clipping
> isn't turned on in the current i965 driver.  Making use of this could
> give a good boost to clipping performance...
> 
> Otherwise, looking good.  It's nice to see the driver continuing to evolve.
> 
> Keith

Hi Keith, 
	Yes it is for the -rhw workaround. It just do a fast clip test before the relatively slower full clip when
-rhw workaround is needed.
	I am testing the 965 driver performance with some 3D engines,
I see clipper take a lot of  GPU time with Doom III demo and becoming a bottleneck.
	I guess it is because the heavily used stencil shadow algorithm in Doom3 III engine, because it is very
likely shadow volumes get clipped than normal scenes.
    For other game engines, I don't see clipper becoming a bottleneck maybe because they are not using stencil
shadow. Although the stencil shadow does not look work quite correct on DOOM 3 demo, I think it is still
worth to optimize the clipper..., later I will fix the 3D effect issue.
	Actually this change for -rhw does not optimize the clip performance in DOOM III too much. I have only got
around 20% speed-up with cliptest on -rhw. Another change clip thread number to 2 in this patch gives
another more than 50% speed up.
    I have tried guard band method, not seeing any performance gain with Doom III...
I  will continue checking the 3D pipeline to try to speed up the driver performance.

Thanks
Zou Nan hai

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev