-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Keith Whitwell wrote: > 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?
In a limited sense, yes. > 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. I wonder if we could avoid one of the copies in the CVA case by implicitly using some APPLE_client_memory type functionality. Do some sort of a lazy copy. Hmm... > 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. Right. Which is why the driver would have to flip the switch to enable that code path. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFS6OjX1gOwKyEAw8RApt7AJsFwPJMs8NyMLG2n5MEMymgw5vYtwCaAxoF yHG2ExDHP4lHRdv4hpNmz7A= =IPdn -----END PGP SIGNATURE----- ------------------------------------------------------------------------- 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
