On 29.04.2009 16:12, martin krastev wrote:
> Thank you, Roland, that explains it all. When i said the code was
> running that much faster on almost the same configuration - that other
> config is AGPx4, with a native OSX driver edge for the rv280 (it's a
> mac). And yes, the vertex arrays are large. So in one case we have
> larger vertex arrays perpetually traversing a (66MHz) PCI bus, in the
> other - proper VBOs over an AGPx4 bus - that could easilly account for
> an order of magnitude, and then some, for this task. And this given
> that fillrate alone is better on the PCI ATI (later model, faster
> clocks, wider memory bus, etc).
> 
> let's say i decided to hack a rudimentarty allocate-only/no-deallocate
> memory manager for STATIC_DRAW VBOs into the edge, not for
> upstreaming, just for my purposes here, where would you advise me to
> start looking at? Also, should i be able to do with just the present
> sources, no futher NDA'd specs required?

I think you wouldn't need any NDA's specs. If you want to make the index
buffer also reusable, you need to use the INDX_BUFFER packet which isn't
used in the r200 driver. However, r300 works just the same there (and
does use it).
I dunno where to start, though. The r300 driver once upon a time
actually used (now defunct and ifdefed out) USER_BUFFERS code to
implement vbo without real memory management. Maybe that's a start, r200
and r300 don't really differ there. Otherwise, it would probably be
easier to use the radeon-rewrite branch along with the appropriate drm
bits and just implement it for real...


Roland

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to