Jerome Glisse wrote: > 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.
Modesetting and scanout buffers are a different kettle of fish - it may be reasonable to have more policy there than we currently do, and I don't think that the negatives I'm worried about apply so much to this area. It's quite reasonable to expect that *somebody* in the display stack may have more information than the 3d client driver about the necessary format, layout, etc of a scanout buffer, and that information would be necessary in order to get eg. page flipping to work correctly. It *may* be that the memory manager/kernel module has a role to play in this -- I don't really know one way or another. I guess the argument is stronger when you're talking about cases where the drm module does modesetting itself. It should be possible to put together a proposal in this area that doesn't negatively affect the 3d driver's ability to use buffers as rendertargets in new & innovative ways. I'm not sure what it would look like exactly, but I'd be happy to evaluate it in the above terms. Keith ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
