Keith Whitwell <[EMAIL PROTECTED]> wrote:
> The percentage improvement you quote is largely due to the
> introduction of the CVA extension, and its use in quake3. I am
> told that Mesa's performance with Q3 on 3dfx hardware is comparable
> to what you can expect from 3dfx's drivers on windows. That aside,
> there is certainly still room for improvment on our code.
Well we just benchmarked this stuff last week using the absolute
latest CVS sources and this is not what we found. Here's the timedemo
results from Quake2 (timedemo 1, demomap demo1.dm2) at 640x480 (3Dfx
Mesa would not go above this resolution - the Banchee ICD and
MSWrapper go to 1280x1024):
[Test machine: AMD K6 3DNow! 366Mhz, 98MB RAM, Quake2 v3.20 (supports
vertex arrays & compiled vertex arrays).]
3Dfx Banshee ICD (Q3 compatible driver): 32.8fps
Microsoft QuakeGL wrapper: 27.8fps
3Dfx Mesa (latest CVS source): 18.9fps
As you can see, the Mesa 3dfx driver is running at nearly half the
speed of the Banshee ICD, and this pretty much comparable to the same
results that we get via GLDirect on the same hardware.
> But, regarding your comments on the pipeline, if you look at the
> newest CVS code, you'll notice the pipeline is now a data
> structure, and is built and modified at runtime.
Great! So you are saying that in the newest CVS code it will be
possible to re-structure the output of the Mesa geometry pipeline to
exactly match the hardware vertex formats? If so, that is exactly the
type of thing we need (so now we need to re-code the 3dfx driver to
utilise this; or has this already been done?).
> These allow drivers to provide code performing exactly the type of
> operations you describe, and in the case of the 'Optimize'
> routines, to break out of the 'expected' data rules, including
> typing and placement of the data. Thus it is possible to code up
> maximally efficient fast-paths for any particular rendering
> scenario that takes your fancy, and apply them at runtime.
Sounds great! I will need to look into the latest changes that you
are doing more extensively. Sounds like there will be a good match
with the new drivers we are working on.
> Anyway, before you engage in more hand-waving, let me point out
> the existence of a tool for measuring where time is spent in a
> running program - the profiler. Here is profiling output for
> quake3 running the current 'experimental-1' code:
>
> % cumulative self
> time seconds seconds name
> 12.03 4.96 4.96 fx_tri_view_clip_RGBA_TMU0
> 9.84 9.02 4.06 fx_tri_view_clip_RGBA_TMU0_TMU1
> 7.30 12.03 3.01 fxsetupXYZWRGBAT0
> 6.38 14.66 2.63 gl_x86_cliptest_points4
> 6.01 17.14 2.48 gl_3dnow_transform_points3_general_raw
> 5.53 19.42 2.28 fxsetupXYZWRGBAT0T1
> 3.23 20.75 1.33
> render_vb_triangles_fx_smooth_indirect_view_clipped
> 3.10 22.03 1.28 gl_BindTexture
> 2.64 23.12 1.09 gl_prepare_arrays_cva
> 2.42 24.12 1.00 fxsetupXYWRGBAT0
> 1.84 24.88 0.76 gl_update_state
> 1.70 25.58 0.70 cliptest_points3_raw
> 1.45 26.18 0.60 fxsetupRGBAT0
>
> Waving my own hands, I would say fxsetup routines are about 70% real
> work, 30% copying. The setup routines consume a disproportionate amount
> of time because they are still 'C' coded, and will probably remain that
> way because Glide3 will be here RSN. The excellent x86 and 3dnow vector
> processing routines have essentially no fat on the bone.
>
> It is clear that we do spend quite a bit of time in fx setup. We
> also spend quite a bit of time in the clipping code. These two are
> intimately related - the interaction between clipping (in clip
> space) and setup (clip and window -> device space) is the biggest
> 'knot' left in the pipeline, and is what I am currently addressing.
Great. So it would appear then that some time is being spent copying
and re-formatting the data structures internally in the 3dfx driver
currently. If the 3dfx driver was updated to use the new vertex re-
formatting stuff you mentioned in the geometry pipeline, this should
speed that stage up by 30% right?
Regards,
+---------------------------------------------------------------+
| SciTech Software - Building Truly Plug'n'Play Software! |
+---------------------------------------------------------------+
| Kendall Bennett | Email: [EMAIL PROTECTED] |
| Director of Engineering | Phone: (530) 894 8400 |
| SciTech Software, Inc. | Fax : (530) 894 9069 |
| 505 Wall Street | ftp : ftp.scitechsoft.com |
| Chico, CA 95928, USA | www : http://www.scitechsoft.com |
+---------------------------------------------------------------+
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
