On Mon, 2009-05-25 at 11:02 -0400, Owen Taylor wrote: [...] > > Anyway i think the plan for newttm is to use such page allocator so > > we can avoid changing cache status of page on every allocation, also > > we would like to avoid zeroing page more than necessary for this we > > need that the userspace keep the buffer around. > > Hmm, isn't the problem with that approach knowing when the kernel is > done with buffers so they are ready for reuse? You'd need some way to > query the kernel to find out what command buffers have completed.
We do have such interface bo busy ioctl, it stills need work thought. > > So in the end the call to drm_ttm_set_cahing (or equivalent in newttm) > > should happen only once at buffer creation. > > > > Btw the limit on radeon for vertex buffer is quite high: > > max number of vertices * max stride = 65536 * (128 * 4) = 32M but i > > think it's unlikely to have a stride 128 dwords, common case would > > around 32 dwords i think. > > Not quite sure what you are referring to - the DMA buffer seems to be > sized assuming a stride of 4 dwords - It's just 16 * 65536. > > [ Even 32 dwords seems very high to me - for example the most > complicated format supported by glInterleavedArrays - GL_T4F_C4F_N3F_V4F > - is just 15 dwords. ] > > - Owen I did take this number from specifications, anyway i don't think anythings use that much geometry in one run and we should really be more clever about vertex buffer, note that we can avoid calling dmarelease on cmdbuf flush but problem is that right i believe we don't accept to map a bo if it's in use by gpu while clearly here what we want to do is having a gpu read from one part of the bo while the cpu is writting to another. I will think a bit about that, but i think the question here is do we want to allow that ? ie to assume that userspace will ask kernel to do proper caching operation when needed, i think it boils down to ask the userspace to be in charge of cache coherency decision and to tell to the kernel what to do. Cheers, Jerome ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
