Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Keith Whitwell wrote:
>> OK, the first round of work on the VBO branch seems to have gone quite
>> smoothly. It'd be great if a couple of the key r200/r300 people could
>> check the branch out and verify whether I've broken those drivers or not.
>>
>> It'd be particularly interesting to see if someone (Aapo?) can take a
>> look at the disabled vtxfmt_a code and see if it is easy to port that
>> over to the new archiecture. I've got a feeling it should be fairly
>> straight-forward, as it's simple to fallback to the tnl/ module for any
>> unexpected or non-handled situations.
>
> How hard would it be to add some quick-and-dirty acceleration for CVAs
> in this branch? I ask for a couple reasons. First, it's on my Mesa
> wish-list. ;) Second, I think that the lack of acceleration for CVAs is
> a big part of the reason that fglrx beats the pants off r300 in Quake3
> based games.
>
> According to the Phoronix review (below), gets nearly *DOUBLE* the
> framerate in Enemy Territory at 640x480 on an X300. Ouch. :( The gap
> closes as resolution increases. It stands to reason that we're not fill
> rate limited but geometry limited.
>
> It seems like we ought to be able to do something generic that could be
> enabled by any driver that provides real VBOs. Thoughts?
That's the catch. I don't know how many drivers do provide real VBO's -
does the r300 actually manage this?
Until the i965 gets ported to the TTM memory manager, it is still using
a fake-plus implementation of VBO's - it has backing store in regular
memory which gets copied to AGP on usage, just like textures in the old
DRI scheme. It may stay there for several usages, but can be knocked
out at any time by another context.
You run into a similar situation if you try to make the VBO module turn
*all* incoming data into VBO's, like I thought would be clever when I
started writing it:
The upload path using VBO's would look like:
- Identify locked array situation.
- Copy locked arrays to VBO.
- Inside the driver: Copy VBO to AGP.
So you get a double copy. Compare to just leaving them alone:
- Pass regular arrays to driver
- Inside the driver: Copy arrays to AGP.
Only one upload.
With CVA, maybe the arrays will get used again in a subsequent drawing
command, in which case you don't lose, or maybe 2 subsequent commands,
in which case you win.
If the driver actually does real VBOs and it allows us access to real
AGP memory, we can do:
- Identify locked array situation
- Copy locked arrays to VBO in AGP space.
Which is what you want.
Keith
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
