RFC: render buffer
Hi all, There have been discussion on irc and elsewhere about the need or not of an object describing a render buffer (could be scan-out buffer or or other specialized card render buffer: color buffer, zbuffer, ...). This would mostly act as a wrapper around BO. Here is what i can imagine as an interface for this: - RenderCreate(properties) - RenderMapLinear - RenderMap - RenderUnmap - Renderunreference Properties would be a set of common properties like: - width - height - bit per pixel - pitch - scan out buffer And also driver private properties like: - compressed in this weird specific format - ... At creation you give a set of properties and you can't change them afterward (well i think it's good enough rules). For what this could be use full ? Well first it would be very useful for mode setting as we can then just have a place where constraint on scan out buffer memory layout are properly checked. Right now we just blindly trust user space to provide a big enough buffer. This could also be use full for creating render buffer making cmd checking a lot easier (as we would have access to width, height, pitch or whatever information is needed to make sure that we have a proper target for our rendering command. Also we could offer common interface for scan out buffer where the driver should allocate a proper buffer using only default properties like (width, height, bit per pixel) and it would be up to driver to fill in other properties with good safe default value (alignment, pitch, compressed, ...) I believe having render buffer object concept in kernel make sense for the above mentioned reasons and because in graphics world render buffer are a key concept and every things in end have to deal with it. So to sum-up: - easy checking of proper render buffer in kernel - easy checking of proper scan out buffer in kernel - make user space easier and safer (others things than a dri driver will allocate proper buffer without having to duplicate code). Few more words on map i think it could be use full to provide two different map method one linear specifically means that you want a linear mapping of the buffer (according to width, height, pitch and bpp) the others just ask for mapping and driver could pass some informations on the layout of the mapped memory (tiled, compressed, ...). For implementation is see two possible way: - wrap render buffer around BO - make render buffer a specialized BO by adding a flag into BO and ptr to render buffer structure Second solution likely the easier one. Anyway what are people thought on all that ? 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/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: render buffer
Jerome Glisse wrote: Hi all, There have been discussion on irc and elsewhere about the need or not of an object describing a render buffer (could be scan-out buffer or or other specialized card render buffer: color buffer, zbuffer, ...). This would mostly act as a wrapper around BO. Here is what i can imagine as an interface for this: - RenderCreate(properties) - RenderMapLinear - RenderMap - RenderUnmap - Renderunreference Properties would be a set of common properties like: - width - height - bit per pixel - pitch - scan out buffer And also driver private properties like: - compressed in this weird specific format - ... At creation you give a set of properties and you can't change them afterward (well i think it's good enough rules). For what this could be use full ? Well first it would be very useful for mode setting as we can then just have a place where constraint on scan out buffer memory layout are properly checked. Right now we just blindly trust user space to provide a big enough buffer. This could also be use full for creating render buffer making cmd checking a lot easier (as we would have access to width, height, pitch or whatever information is needed to make sure that we have a proper target for our rendering command. Also we could offer common interface for scan out buffer where the driver should allocate a proper buffer using only default properties like (width, height, bit per pixel) and it would be up to driver to fill in other properties with good safe default value (alignment, pitch, compressed, ...) I believe having render buffer object concept in kernel make sense for the above mentioned reasons and because in graphics world render buffer are a key concept and every things in end have to deal with it. So to sum-up: - easy checking of proper render buffer in kernel - easy checking of proper scan out buffer in kernel - make user space easier and safer (others things than a dri driver will allocate proper buffer without having to duplicate code). Few more words on map i think it could be use full to provide two different map method one linear specifically means that you want a linear mapping of the buffer (according to width, height, pitch and bpp) the others just ask for mapping and driver could pass some informations on the layout of the mapped memory (tiled, compressed, ...). For implementation is see two possible way: - wrap render buffer around BO - make render buffer a specialized BO by adding a flag into BO and ptr to render buffer structure Second solution likely the easier one. Anyway what are people thought on all that ? 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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: render buffer
On Wed, 2008-01-16 at 17:35 +, 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/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: render buffer
Jerome Glisse wrote: On Wed, 2008-01-16 at 17:35 +, 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/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: render buffer
On Wed, 16 Jan 2008 19:49:34 + Keith Whitwell [EMAIL PROTECTED] wrote: Jerome Glisse wrote: On Wed, 2008-01-16 at 17:35 +, 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 Well we did have some more discussion on irc about this and i think that having this informations for framebuffer is the only place where this is truely needed. We already have special interface for framebuffer so i guess we could work our way from there without impacting bo. For things other than framebuffer i think the main outcome of the discussion we had is that this kind of informations should be exchanged in user space btw program who cares. For instance in an X server this kind of informations would be exchanged throught dri2, so we might just have to limit bo sharing to a group of client behind a same master (i am thinking of Dave'smulti-master work here which might bring us the foundation for this). So xserver is a drm master and each xserver client is a drm child or dependant of this master and bo can only be shared through the master. And finaly checking bo size even if we need to do some computation like (width*height*bpp) won't kill the performance and will let the user use its buffer in whatever way it sees fit as long as it doesn't go beyond the size. Cheers, Jerome Glisse [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
