Zou, Nanhai wrote: >> -----Original Message----- >> From: Keith Whitwell [mailto:[EMAIL PROTECTED] >> 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 <[EMAIL PROTECTED]> >>> 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.
Nan hai Zou, Interesting. It seems like the -rhw path is important for Doom 3, in which case it would be worthwhile to turn off all workarounds on hardware where they aren't required. I think that around the C stepping of crestline and possibly the latest stepping of broadwater the bug is fixed?? Keith ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
