On Wed, 2008-01-16 at 17:35 +0000, Keith Whitwell wrote: > Pretty much every buffer is potentially a render target, for instance > all texture buffers when generating mipmaps, etc. > > In the example above, different parts of individual buffers may be > rendered to with different pitches, etc, ie when targetting different > mipmaps. Intel hardware uses the same pitch for all mipmaps, but this > is not universal. > > Furthermore things like GL's pixel buffers may be used with different > pitches etc according to the user's whim. > > In general one of the nicest things about the current memory manager is > that it does *not* impose this type of thing on regular buffer > management. I've worked with systems that do and it can be very > burdensome. > > It's not like this presents a security issue to the system at large, so > the question then is why make it a kernel function? You just end up > running into the limitations you've encoded into the kernel in > generation n when you're trying to do the work for generation n+1. > > One motiviation for this sort of thing might be making allocation of > fenced memory regions easier (fenced in the sense used in Intel HW, > referring to tiled memory). I think that might be better handled > specially without encumbering the system as a whole with a fixed > interpretation of buffer layout. > > Is there a specific issue that this proposal is trying to address? > > Keith
Well main motivation was for mode setting and command checking, for radeon a proper command checking will need to do a lot of, (width|pitch)*height*bpp + alignment against bo size checking. I do see render buffer object as a way of greatly simplify this. But i won't fight for it, i am well aware that current bo are really nice because it doesn't enforce a policy. I guess my main concern is more about how to ask to mode setting to program card to use this kind or this kind of layout for scan out buffer. Cheers, Jerome Glisse ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
