3 Sep 2007 03:44
Re: mesa: Changes to 'master'
Zou, Nanhai <nanhai.zou <at> intel.com>
2007-09-03 01:44:10 GMT
2007-09-03 01:44:10 GMT
> -----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