Jakob Bornecrantz wrote: >> There should be master (possibly one for each card) which be the only >> one being able to do this call: >> DRM_IOCTL_MODE_SETCRTC - set CRTC parameters >> (which i assume is set the mode, associat crtc-output and set framebuffer) >> >> Other call can be made by any others client: >> - DRM_IOCTL_MODE_ADDFB - add a new FB object >> - DRM_IOCTL_MODE_RMFB - remove an FB object >> - DRM_IOCTL_MODE_GETFB - get info about an FB object >> ... >> > I don't feel it is necessary for the clients to be able to create a > framebuffer, why, because from the kernel standpoint where the said > object will live, it will only be a small container containing the > buffer object(s), a list of crtc that is using the buffer object(s) as > a scanout buffer and the information about its size and format. Read > below for more. > > The reasons why i wanted to expose frame buffer to client is because there is constraint to a frame buffer and this depend on the card, and if you want to take advantage of card you likely will want to follow this constraint when rendering. For instance if you got a card capable of supporting tiles you will want to render to a tiled buffer, i don't think this is easy to expose this to the client when creating a BO as BO are generic and can be used for vertex, or others data.
In fact i do see a framebuffer as a special instance of BO which follow constraint of the card for rendering, we maybe can even force all rendering to happen into framebuffer (or others name if that's what matter). This way you know that you follow card constraints (tiles, stride size, alignement, component separation, ....) If we force all rendering to happen into framebuffer then each client can either have its own or a part of another framebuffer (X client got a part of another if no compositing). So to resume having framebuffer might let us put specificity of memory layout, needed for efficient GPU rendering, into the kernel. We can let each driver accept additional parameter on ADDFB to tweak this (force tile off/on, RGB16, RGB32, ...). And also provide additional function for framebuffer addressing (like get pixel, get area, set pixel, set area) i believe fb driver expose such function and i believe this make writting console driver easier. Also, this way one can wrote a dumb app for any card which is graphical and don't have any dependency. It also make coding GL driver easier as you basicly use framebuffer (with associated Z/stencil buffer) from the kernel side and then you only matter on creating command stream not on how you should arrange things in memory. But maybe you still need anyway to put this knowledge into the driver (texture tiling, cube map specific memory organization, ...). Oh and as each client can carry its frame buffer(s) and it can believe being displayed while maybe somethings else is scanned out. Client are not aware of sharing the card the believe they own it and don't need to ask for a slice of a common frame buffer. That just might be given the chance of being scanout like they just might be never displayed (i am sure some one want to play quake without even seeing the screen ;)). I believe this make card "virtualization" total as the master will be in control and have the possibility to choose between each card available frame buffer, this can also help for instance when transitioning from fullscreen game to windowed without changing anythings. Hope some of arguments make sense :) and that i explained properly why i think putting all framebuffer layout specificity knowledge into kernel sounds better to me. Cheers, Jerome Glisse ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
