Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Thu, 17 Mar 2005, Ville [iso-8859-1] Syrjl wrote:
On Thu, Mar 17, 2005 at 12:12:58PM +1100, Benjamin Herrenschmidt wrote:
I understand you can't have userspace program the accelerator while
someone else is doing the same thing. Oh and I now understand that the
same really applies to direct framebuffer access due to the swapper.
And you can't have someone program the accelerator while somebody does
direct access neither. It's basically all exclusive.
I haven't seen that happen on any hardware I own. Matrox specs explicitly
mention that there is no need to synchronize accelerator and direct
framebuffer access.
Really? I was always given Matrox as an example of a card that would lock up if
you access the frame buffer while the accelerator is busy...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Thu, Mar 17, 2005 at 10:08:15AM +0100, Geert Uytterhoeven wrote: On Thu, 17 Mar 2005, Ville [iso-8859-1] Syrj??wrote: On Thu, Mar 17, 2005 at 12:12:58PM +1100, Benjamin Herrenschmidt wrote: I understand you can't have userspace program the accelerator while someone else is doing the same thing. Oh and I now understand that the same really applies to direct framebuffer access due to the swapper. And you can't have someone program the accelerator while somebody does direct access neither. It's basically all exclusive. I haven't seen that happen on any hardware I own. Matrox specs explicitly mention that there is no need to synchronize accelerator and direct framebuffer access. Really? Really. I was always given Matrox as an example of a card that would lock up if you access the frame buffer while the accelerator is busy... Apparently they didn't know what they were talking about. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, Mar 16, 2005 at 05:31:16PM +1100, Benjamin Herrenschmidt wrote: On Wed, 2005-03-16 at 00:21 -0500, Michel Dänzer wrote: Actually people do use it on big-endian systems but since neither the mach64, ati128 or radeon drivers play with the swapper settings I can only assume that they haven't been tested very extensively. You are wrong here, all of those 3 drivers do play with the swapper setting, [...] I think he was referring to the DirectFB drivers. Exactly. I prorably should have mentioned that explicitly. Well, do they revert it after atyfb/aty128fb/radeonfb set it then ? it's definitely set on mode switch. The point is that there can be offscreen surfaces with different depth than the fbdev surface. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wednesday 16 March 2005 09:09, Ville Syrjl wrote: On Wed, Mar 16, 2005 at 05:31:16PM +1100, Benjamin Herrenschmidt wrote: Well, do they revert it after atyfb/aty128fb/radeonfb set it then ? it's definitely set on mode switch. The point is that there can be offscreen surfaces with different depth than the fbdev surface. _Will_ be. Otherwise GL and Render performance drops through the floor. - ajax pgphgrpcnCfJg.pgp Description: PGP signature
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, Mar 16, 2005 at 12:51:27PM +1100, Benjamin Herrenschmidt wrote: On Wed, 2005-03-16 at 03:47 +0200, Ville Syrjälä wrote: There's also the case with Matrox Millennium I/II cards. They must place the visible frame buffer so that no line crosses the boundary of memory banks. matroxfb deals with that by moving the buffer and changing smem_start and smem_len appropriately. But that is really bad for DirectFB's offscreen memory management. After a mode switch the memory manager would need to know what kind of initial byte offset was used. Of couse it would be possible to determine that from smem_start by knowing how the aperture must be aligned. Actually we already do that sort of thing to allow hw accelerated rendering when used on matroxfb controlled G450/G450/G550 CRTC2. But in that case the offset won't change on mode switch. So it alls end up to - mode switch has to bust memory layout, and any assumptions that DirectFB tries to do are incorrect. I don't think so. Due to fbdev API limitations DirectFB just can't accurately determine how much memory will be used by the fbdev buffer. It can make an educated guess though. Just as long as you don't change the fact that the fbdev buffer will be located at the beginning of the memory that is. and because it seems that directFB has only been tested on little endian machines (damn them !) and thus doesn't understand the problem with swapper on framebuffer access). Actually people do use it on big-endian systems but since neither the mach64, ati128 or radeon drivers play with the swapper settings I can only assume that they haven't been tested very extensively. You are wrong here, all of those 3 drivers do play with the swapper setting, they all 3 set the swapper based on the bit depth of the screen, so writing an image to offscreen memory with a different bit depth will be broken. See usage of SURFACE_CNTL in radeonfb for example. This was about the DirectFB drivers. One thing just popped to my head though. If in the future we are going to allow graphics cards to render to system memory, using the swapper will no longer work. I don't see any other solution that having the CPU perform the byte swapping. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, Mar 16, 2005 at 02:09:18PM +1100, Benjamin Herrenschmidt wrote: It's ugly, but that's not the point. The point is that all deployed versions of X (and even current X.org CVS head still, in fact) make this assumption. Oh, that's fine and that's not a problem. I will only repaint the framebuffer on bit depth or line lenght changes. I'm trying to talk about the _future_ here. That is support for dual head at the fbdev level and other niceties. I don't see the current system slowly evolving into some superb future system with an in kernel memory manager. The current APIs just have too many limitations. I think the memory manager must be the foundation of everything and after it's in place the fbdev API should be able to use it. The only change to simple fbdev apps would be that they can't get access to any offscreen memory as they do now. Something like DirectFB would need to change to accomodate the new system but I don't see that as a problem. I think the best short term option for radeonfb is to simply follow matroxfb's example and cut the memory into two parts. The cutoff point should probably be configurable via a module option. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 2005-03-16 at 22:08 +0200, Ville Syrjl wrote: I don't see the current system slowly evolving into some superb future system with an in kernel memory manager. The current APIs just have too many limitations. I think the memory manager must be the foundation of everything and after it's in place the fbdev API should be able to use it. The only change to simple fbdev apps would be that they can't get access to any offscreen memory as they do now. Something like DirectFB would need to change to accomodate the new system but I don't see that as a problem. I agree on this. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, Mar 16, 2005 at 10:49:11AM +1100, Benjamin Herrenschmidt wrote: In the meantime, can you tell me more about your arbitration scheme ? There is a lock associated with the graphics card. The lock is always taken before programming the hardware. Other things wanting access to the hardware wait until the lock is released. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 16 Mar 2005 22:08:08 +0200, Ville Syrjälä [EMAIL PROTECTED] wrote: On Wed, Mar 16, 2005 at 02:09:18PM +1100, Benjamin Herrenschmidt wrote: It's ugly, but that's not the point. The point is that all deployed versions of X (and even current X.org CVS head still, in fact) make this assumption. Oh, that's fine and that's not a problem. I will only repaint the framebuffer on bit depth or line lenght changes. I'm trying to talk about the _future_ here. That is support for dual head at the fbdev level and other niceties. I don't see the current system slowly evolving into some superb future system with an in kernel memory manager. The current APIs just have too many limitations. I think the memory manager must be the foundation of everything and after it's in place the fbdev API should be able to use it. The only change to simple fbdev apps would be that they can't get access to any offscreen memory as they do now. Something like DirectFB would need to change to accomodate the new system but I don't see that as a problem. I think the best short term option for radeonfb is to simply follow matroxfb's example and cut the memory into two parts. The cutoff point should probably be configurable via a module option. if we are going to go through the trouble to do it at all why not do it the right way? We could also work on updating the fbdev drivers to the new version out of tree until they have stabilized and then we can work on merging them into the kernel. that should give GUI/driver developers time to adapt their respecitve projects. Alex -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjl wrote: One thing just popped to my head though. If in the future we are going to allow graphics cards to render to system memory, using the swapper will no longer work. I don't see any other solution that having the CPU perform the byte swapping. Sane hardware should have a way to deal with this as well. Either way, this is hardware specific, so it will probably have to be handled by the hardware driver(s) somehow. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, Mar 16, 2005 at 04:00:26PM -0500, Michel Dänzer wrote: On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjälä wrote: One thing just popped to my head though. If in the future we are going to allow graphics cards to render to system memory, using the swapper will no longer work. I don't see any other solution that having the CPU perform the byte swapping. Sane hardware should have a way to deal with this as well. In that case I'm not familiar with any sane hardware. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote: On Wed, 16 Mar 2005 22:08:08 +0200, Ville Syrjälä [EMAIL PROTECTED] wrote: On Wed, Mar 16, 2005 at 02:09:18PM +1100, Benjamin Herrenschmidt wrote: It's ugly, but that's not the point. The point is that all deployed versions of X (and even current X.org CVS head still, in fact) make this assumption. Oh, that's fine and that's not a problem. I will only repaint the framebuffer on bit depth or line lenght changes. I'm trying to talk about the _future_ here. That is support for dual head at the fbdev level and other niceties. I don't see the current system slowly evolving into some superb future system with an in kernel memory manager. The current APIs just have too many limitations. I think the memory manager must be the foundation of everything and after it's in place the fbdev API should be able to use it. The only change to simple fbdev apps would be that they can't get access to any offscreen memory as they do now. Something like DirectFB would need to change to accomodate the new system but I don't see that as a problem. I think the best short term option for radeonfb is to simply follow matroxfb's example and cut the memory into two parts. The cutoff point should probably be configurable via a module option. if we are going to go through the trouble to do it at all why not do it the right way? I haven't seen anyone coming forward with a design/code for the memory manager. In the meantime I'm assuming that people might want to make some use of their dualhead cards... -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 16 Mar 2005 23:08:12 +0200, Ville Syrjälä [EMAIL PROTECTED] wrote: On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote: On Wed, 16 Mar 2005 22:08:08 +0200, Ville Syrjälä [EMAIL PROTECTED] wrote: On Wed, Mar 16, 2005 at 02:09:18PM +1100, Benjamin Herrenschmidt wrote: It's ugly, but that's not the point. The point is that all deployed versions of X (and even current X.org CVS head still, in fact) make this assumption. Oh, that's fine and that's not a problem. I will only repaint the framebuffer on bit depth or line lenght changes. I'm trying to talk about the _future_ here. That is support for dual head at the fbdev level and other niceties. I don't see the current system slowly evolving into some superb future system with an in kernel memory manager. The current APIs just have too many limitations. I think the memory manager must be the foundation of everything and after it's in place the fbdev API should be able to use it. The only change to simple fbdev apps would be that they can't get access to any offscreen memory as they do now. Something like DirectFB would need to change to accomodate the new system but I don't see that as a problem. I think the best short term option for radeonfb is to simply follow matroxfb's example and cut the memory into two parts. The cutoff point should probably be configurable via a module option. if we are going to go through the trouble to do it at all why not do it the right way? I haven't seen anyone coming forward with a design/code for the memory manager. In the meantime I'm assuming that people might want to make some use of their dualhead cards... Good point. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 2005-03-16 at 11:48 -0500, Adam Jackson wrote: On Wednesday 16 March 2005 09:09, Ville Syrjälä wrote: On Wed, Mar 16, 2005 at 05:31:16PM +1100, Benjamin Herrenschmidt wrote: Well, do they revert it after atyfb/aty128fb/radeonfb set it then ? it's definitely set on mode switch. The point is that there can be offscreen surfaces with different depth than the fbdev surface. _Will_ be. Otherwise GL and Render performance drops through the floor. Yes, but again, GL/DRI knows how to play with the swapper, that is not my point. Looks like people here prefer arguing for the sake of it rather than trying to make progress... I think I'll just decide something randomly in radeonfb and let folks cope with it. Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjälä wrote: This was about the DirectFB drivers. One thing just popped to my head though. If in the future we are going to allow graphics cards to render to system memory, using the swapper will no longer work. I don't see any other solution that having the CPU perform the byte swapping. There is a _lot_ of existing code that will stop working, MOL is an example, it requires proper native format for the framebuffer. X too in it's current incarnation (fb format is defined at compile time I think). So the swapper is _needed_ for framebuffer access. The best we can do is save/change/restore it around accesses like we do already when copying YUV frames to video memory. Now regarding the setup of the apertures, I suppose that I'll do something complicated that nobody will use right, that is use 2 separate apertures contiguous with each framebuffer at the beginning of each aperture when CONFIG_APER_SIZE is 1/2 of vram size, and 2 separate apertures contiguous with each framebuffer together in the first one in the other cases. Only difference: first case will allow macs to have separate swappers for each aperture. All other cases will have both swappers set the same way. Hopefully, all Mac cards have CONFIG_APER_SIZE set to half the vram. Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 2005-03-16 at 15:42 -0500, Michel Dänzer wrote: On Wed, 2005-03-16 at 22:08 +0200, Ville Syrjälä wrote: I don't see the current system slowly evolving into some superb future system with an in kernel memory manager. The current APIs just have too many limitations. I think the memory manager must be the foundation of everything and after it's in place the fbdev API should be able to use it. The only change to simple fbdev apps would be that they can't get access to any offscreen memory as they do now. Something like DirectFB would need to change to accomodate the new system but I don't see that as a problem. I agree on this. Ok, ok, I'll do crap since that's what everybody wants. Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 2005-03-16 at 22:55 +0200, Ville Syrjälä wrote: On Wed, Mar 16, 2005 at 10:49:11AM +1100, Benjamin Herrenschmidt wrote: In the meantime, can you tell me more about your arbitration scheme ? There is a lock associated with the graphics card. The lock is always taken before programming the hardware. Other things wanting access to the hardware wait until the lock is released. Ok, so it would be easy to have directFB use an external arbiter without breaking existing clients ? It will need at least to use the vga arbiter that I'm about to finish, that should allow at least to have X on one card and directFB on another without conflict. Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 2005-03-16 at 16:00 -0500, Michel Dänzer wrote: On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjälä wrote: One thing just popped to my head though. If in the future we are going to allow graphics cards to render to system memory, using the swapper will no longer work. I don't see any other solution that having the CPU perform the byte swapping. Sane hardware should have a way to deal with this as well. Either way, this is hardware specific, so it will probably have to be handled by the hardware driver(s) somehow. Of course, and radeonfb is what if not a hardware driver ? Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 2005-03-16 at 23:08 +0200, Ville Syrjälä wrote: On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote: I haven't seen anyone coming forward with a design/code for the memory manager. In the meantime I'm assuming that people might want to make some use of their dualhead cards... Are you aware that with the current fbdev API, there will simply be no working use of dual head ? As soon as somebody will try to do 2 different things on the 2 heads, it will either lockup due to lack of engine arbitration, or have wrong endianness, or whatever ... Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Thu, 17 Mar 2005 10:26:57 +1100, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Wed, 2005-03-16 at 15:42 -0500, Michel Dänzer wrote: On Wed, 2005-03-16 at 22:08 +0200, Ville Syrjälä wrote: I don't see the current system slowly evolving into some superb future system with an in kernel memory manager. The current APIs just have too many limitations. I think the memory manager must be the foundation of everything and after it's in place the fbdev API should be able to use it. The only change to simple fbdev apps would be that they can't get access to any offscreen memory as they do now. Something like DirectFB would need to change to accomodate the new system but I don't see that as a problem. I agree on this. Ok, ok, I'll do crap since that's what everybody wants. Why don't we modify the new radoenfb driver to have a real arbitration/management layer. Directfb can continue to use the old driver. The rule is that you can't mix old and new style fbdev drivers in a system. Over time DirectFb and X can be fixed to use the new model. There is going to have to be a transition path while we debug the arbitration/management layer and figure out the right API for it. Supporting multiple disparate users of the graphics hardware is a quite complex feature that no other operating system implements. Ben. ___ xorg mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/xorg -- Jon Smirl [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Thu, 2005-03-17 at 10:28 +1100, Benjamin Herrenschmidt wrote: On Wed, 2005-03-16 at 16:00 -0500, Michel Dnzer wrote: On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjl wrote: One thing just popped to my head though. If in the future we are going to allow graphics cards to render to system memory, using the swapper will no longer work. I don't see any other solution that having the CPU perform the byte swapping. Sane hardware should have a way to deal with this as well. Either way, this is hardware specific, so it will probably have to be handled by the hardware driver(s) somehow. Of course, and radeonfb is what if not a hardware driver ? Who said it was anything else? Is radeonfb gonna handle the offscreen surfaces though? My point was that the hardware driver(s) should be involved in the decision on what format/byte order/... should be used for a surface, instead of just hardcoding fixed formats and having the CPU do possibly unnecessary byte swapping. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
Why don't we modify the new radoenfb driver to have a real arbitration/management layer. Directfb can continue to use the old driver. The rule is that you can't mix old and new style fbdev drivers in a system. Over time DirectFb and X can be fixed to use the new model. There is going to have to be a transition path while we debug the arbitration/management layer and figure out the right API for it. Supporting multiple disparate users of the graphics hardware is a quite complex feature that no other operating system implements. I prefer letting the heat cool down for now. I'll implement the actual mode setting etc... with a very basic memory management, and we'll move from there once I have the code. Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Thu, Mar 17, 2005 at 10:27:56AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2005-03-16 at 22:55 +0200, Ville Syrjälä wrote: On Wed, Mar 16, 2005 at 10:49:11AM +1100, Benjamin Herrenschmidt wrote: In the meantime, can you tell me more about your arbitration scheme ? There is a lock associated with the graphics card. The lock is always taken before programming the hardware. Other things wanting access to the hardware wait until the lock is released. Ok, so it would be easy to have directFB use an external arbiter without breaking existing clients ? It will need at least to use the vga arbiter that I'm about to finish, that should allow at least to have X on one card and directFB on another without conflict. Is the vga arbiter required for something else besides access to some legacy ports? DirectFB only uses legacy ports to wait for vsync if a better method is not available. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Thu, 2005-03-17 at 02:14 +0200, Ville Syrjälä wrote: On Thu, Mar 17, 2005 at 10:27:56AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2005-03-16 at 22:55 +0200, Ville Syrjälä wrote: On Wed, Mar 16, 2005 at 10:49:11AM +1100, Benjamin Herrenschmidt wrote: In the meantime, can you tell me more about your arbitration scheme ? There is a lock associated with the graphics card. The lock is always taken before programming the hardware. Other things wanting access to the hardware wait until the lock is released. Ok, so it would be easy to have directFB use an external arbiter without breaking existing clients ? It will need at least to use the vga arbiter that I'm about to finish, that should allow at least to have X on one card and directFB on another without conflict. Is the vga arbiter required for something else besides access to some legacy ports? DirectFB only uses legacy ports to wait for vsync if a better method is not available. Yes. I need to extend the Arbiter API a bit in fact to deal with clients that don't know if the card is doing legacy decoding like you. The problem is that unless the card you are using is not doing any legacy decoding (has been set not to decode legacy VGA IO ports and legacy VGA memory), trying to use another card in the system that does decode them requires switching off IO and MEM access on you. Even if you aren't actually using those legacy stuff, the simple fact that the card is decoding them mean it needs to be disabled. (In fact, it could be avoided in some cases where the card is under a different P2P bridge by just disabling VGA forwarding, but that's the aribter salad, as a client, you don't have to know that). So the arbiter provides calls to lock some resources and deals with eventually ping-pong'ing IOs. It's currently providing APIs to lock legacy IO and legacy MEM and to inform the arbiter that the card isn't decoding some or all of the legacy stuff (to put it out of the arbiter hands basically). It needs an addition to the API I posted for cases where you don't know if the card is doing legacy decoding, to indicate you want to access the normal memory/IO resources of the card, and implictely lock the legacy ones if they are beeing decoded. I'm working on it, I hope to have something to start playin with soon, there are some issues to deal with the kernel vga console though that i'm trying to iron out. Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Thu, Mar 17, 2005 at 10:30:01AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2005-03-16 at 23:08 +0200, Ville Syrjälä wrote: On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote: I haven't seen anyone coming forward with a design/code for the memory manager. In the meantime I'm assuming that people might want to make some use of their dualhead cards... Are you aware that with the current fbdev API, there will simply be no working use of dual head ? As soon as somebody will try to do 2 different things on the 2 heads, it will either lockup due to lack of engine arbitration, or have wrong endianness, or whatever ... I understand you can't have userspace program the accelerator while someone else is doing the same thing. Oh and I now understand that the same really applies to direct framebuffer access due to the swapper. I hadn't really thought about that issue before since I don't own a big-endian system. I really must try to get one... So basically to fix both issues we need some locks everyone must acquire before accessing the hardware. With the current mmap() registers and go interface the accelerator lock wouldn't actually guarantee anything but it would allow well behaving applications to share the accelerator. Good behaviour is already expected from the applications anyway due to the direct access to hardware registers. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
I understand you can't have userspace program the accelerator while someone else is doing the same thing. Oh and I now understand that the same really applies to direct framebuffer access due to the swapper. And you can't have someone program the accelerator while somebody does direct access neither. It's basically all exclusive. I hadn't really thought about that issue before since I don't own a big-endian system. I really must try to get one... The only thing that would work without arbitration is direct famebuffer access on both, with both using a different swapper, that is a different aperture. That is either doing the the way I described earlier (having both apertures overlap the beginning of memory) or doing the mapping the right way (that is both apertures mapping half of memory so that together they map all of it). The problem is that I think a bunch of BIOSes for x86 didn't care since they don't use the swapper and didn't set the aperture size properly. So basically to fix both issues we need some locks everyone must acquire before accessing the hardware. Plus the VGA arbitration of course ... But yes. That's more or less what DRM provides. With the current mmap() registers and go interface the accelerator lock wouldn't actually guarantee anything but it would allow well behaving applications to share the accelerator. Good behaviour is already expected from the applications anyway due to the direct access to hardware registers. It's more than the accelerator. A framebuffer access concurrent with accelerator operations can lockup too. Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Thu, Mar 17, 2005 at 12:12:58PM +1100, Benjamin Herrenschmidt wrote: I understand you can't have userspace program the accelerator while someone else is doing the same thing. Oh and I now understand that the same really applies to direct framebuffer access due to the swapper. And you can't have someone program the accelerator while somebody does direct access neither. It's basically all exclusive. I haven't seen that happen on any hardware I own. Matrox specs explicitly mention that there is no need to synchronize accelerator and direct framebuffer access. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Thu, 2005-03-17 at 03:25 +0200, Ville Syrjälä wrote: On Thu, Mar 17, 2005 at 12:12:58PM +1100, Benjamin Herrenschmidt wrote: I understand you can't have userspace program the accelerator while someone else is doing the same thing. Oh and I now understand that the same really applies to direct framebuffer access due to the swapper. And you can't have someone program the accelerator while somebody does direct access neither. It's basically all exclusive. I haven't seen that happen on any hardware I own. Matrox specs explicitly mention that there is no need to synchronize accelerator and direct framebuffer access. You are lucky then :) Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrjl wrote:
I think that making the assumption that all memory is preserved when the
memory layout (virtual resolution and depth) doesn't change is perfectly
valid too. That would allow X to do it's Ctrl-Alt-+ and - things without
repainting the whole screen.
Indeed. The `geometry' part of the screen isn't changed, only the `timings'
part (cfr. the split of fb_var_screeninfo parameters I did in fbutils (which
BTW wasn't ever finished).
If radeonfb will allocate the buffer for the second head from the top of
the memory users would basically have to guess it's location. matroxfb
simply cuts the memory in two pieces and allocates the buffers from the
start of each piece. I don't really like that approach. Adding a simple
byte_offset field to fb_var_screeninfo would solve the problem quite
nicely but I don't know if such API changes are acceptable at this stage.
You wouldn't have to guess its location, look at fix.smem_start.
I once did a similar thing for an embedded prototype: take a fixed amount of
memory for both frame buffers (this was a UMA system), fb0 starts from the top,
fb1 starts from the bottom. You can enlarge each frame buffer, until you read
the memory of the other. Each fix.smem_{start,len} corresponds exactly to the
memory allocated to each frame buffer.
Of course, if you also want off-screen memory (i.e. memory beyond
xres_virtual*yres_virtual*bpp/8), things get more complicated, since currently
there's no way for the application to ask for a minimum amount of off-screen
memory. Perhaps a new field in fb_var_screeninfo (and zero means `I don't
care', for backwards compatibility).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
Ville Syrjälä wrote: I think that making the assumption that all memory is preserved when the memory layout (virtual resolution and depth) doesn't change is perfectly valid too. That would allow X to do it's Ctrl-Alt-+ and - things without repainting the whole screen. I'm not sure I agree here, as it's not always true. For instance, the radeon has some restrictions whether it can use tiling or not with a certain mode (interlace/double scan) thus you need to redraw everything anyway (which is exactly why I implemented a driver workaround to repaint everything when that happens - in fact the workaround also gets rid of the offscreen contents, which is not necessary, but was much easier to implement, since I couldn't find an easy way to invalidate the framebuffer). What's the big deal with repainting everything? It's not like you would do 100 mode changes per second so it would be performance-critical... Roland --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Tue, Mar 15, 2005 at 12:30:56PM +0100, Roland Scheidegger wrote: Ville Syrjälä wrote: I think that making the assumption that all memory is preserved when the memory layout (virtual resolution and depth) doesn't change is perfectly valid too. That would allow X to do it's Ctrl-Alt-+ and - things without repainting the whole screen. I'm not sure I agree here, as it's not always true. For instance, the radeon has some restrictions whether it can use tiling or not with a certain mode (interlace/double scan) thus you need to redraw everything anyway I didn't know about that. My first thought would be to disallow such modes but knowing that X lacks a proper fullscreen API that might not be a realistic option. (which is exactly why I implemented a driver workaround to repaint everything when that happens - in fact the workaround also gets rid of the offscreen contents, which is not necessary, but was much easier to implement, since I couldn't find an easy way to invalidate the framebuffer). What's the big deal with repainting everything? It's not like you would do 100 mode changes per second so it would be performance-critical... I don't really have a big deal with invalidating the visible part of the memory. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Tue, Mar 15, 2005 at 09:51:40AM +0100, Geert Uytterhoeven wrote:
On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrj??wrote:
If radeonfb will allocate the buffer for the second head from the top of
the memory users would basically have to guess it's location. matroxfb
simply cuts the memory in two pieces and allocates the buffers from the
start of each piece. I don't really like that approach. Adding a simple
byte_offset field to fb_var_screeninfo would solve the problem quite
nicely but I don't know if such API changes are acceptable at this stage.
You wouldn't have to guess its location, look at fix.smem_start.
But how would someone mmap() the whole memory then? matroxfb already plays
tricks on fix.smem_start on Millennium I/II cards and it really confuses
DirectFB's memory allocator.
I once did a similar thing for an embedded prototype: take a fixed amount of
memory for both frame buffers (this was a UMA system), fb0 starts from the
top,
fb1 starts from the bottom. You can enlarge each frame buffer, until you read
the memory of the other. Each fix.smem_{start,len} corresponds exactly to the
memory allocated to each frame buffer.
Of course, if you also want off-screen memory (i.e. memory beyond
xres_virtual*yres_virtual*bpp/8), things get more complicated, since currently
there's no way for the application to ask for a minimum amount of off-screen
memory. Perhaps a new field in fb_var_screeninfo (and zero means `I don't
care', for backwards compatibility).
Offscreen memory is pretty much essential for DirectFB.
--
Ville Syrjälä
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Tue, Mar 15, 2005 at 05:59:42PM +1100, Benjamin Herrenschmidt wrote: On Tue, 2005-03-15 at 08:01 +0200, Ville Syrjälä wrote: If radeonfb will allocate the buffer for the second head from the top of the memory users would basically have to guess it's location. matroxfb simply cuts the memory in two pieces and allocates the buffers from the start of each piece. I don't really like that approach. Adding a simple byte_offset field to fb_var_screeninfo would solve the problem quite nicely but I don't know if such API changes are acceptable at this stage. And we don't know if all HW would support it anyway. Such hardware would be free to ignore any user supplied byte_offset and place the buffer anywhere it wants. Even a read-only byte_offset field would help. But using the second head would require all apps to be updated to be aware of byte_offset :( Maybe some kind of API version thing could help here ie. User sets flag X somewhere indicating byte_offset should be used instead of changing smem_start. We are thinking with the new model in mind, and so far, a mode setting is under control of the framebuffer. Content of video memory (framebuffer, textures, overlay, whatever) simply cannot be considered as preserved accross mode switches. We can't also block all evolutions just because we have to support a broken model. I'm not suggesting that, but I do think that tying together mode switching and memory allocation would be a big mistake. Indeed. The main issue hwoever, is access arbitration. I'd appreciate your DirectFB point of view on these things. DirectFB has it's own asbitration mechanism. It doesn't support using multiple framebuffer devices at the same time. For that to work DirectFB would just have to know if some of the framebuffer devices are actually different outputs of the same card so that it could associate both with the same lock and accelerator state. With the current system I don't see much chance of using accelerated fbcon on one head and accelerated DirectFB (or something else) on the other. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Tue, 15 Mar 2005 16:00:05 +0200, Ville Syrjälä [EMAIL PROTECTED] wrote: DirectFB has it's own asbitration mechanism. It doesn't support using multiple framebuffer devices at the same time. For that to work DirectFB would just have to know if some of the framebuffer devices are actually different outputs of the same card so that it could associate both with the same lock and accelerator state. With the current system I don't see much chance of using accelerated fbcon on one head and accelerated DirectFB (or something else) on the other. It looks to be like there needs to be new rules for framebuffer access. X needs to change, why can't DirectFB change too? This is why we have so much conflict in graphics. Everyone thinks they completely own the hardware and can do whatever they want with it. It's obvious to me, if we add universal aribtration everyone has to change and follow the new rules. Aonther approach would be to just say you have to choose to run one of X, DirectFB, FBUI, XGL and you can't switch between them. Other than developers I don't know if anyone really runs more than one of these at a time. Here's another one: http://home.comcast.net/~plinius/fbui.html -- Jon Smirl [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Tue, 2005-03-15 at 12:30 +0100, Roland Scheidegger wrote: Ville Syrjl wrote: I think that making the assumption that all memory is preserved when the memory layout (virtual resolution and depth) doesn't change is perfectly valid too. That would allow X to do it's Ctrl-Alt-+ and - things without repainting the whole screen. I'm not sure I agree here, as it's not always true. For instance, the radeon has some restrictions whether it can use tiling or not with a certain mode (interlace/double scan) thus you need to redraw everything anyway (which is exactly why I implemented a driver workaround to repaint everything when that happens - in fact the workaround also gets rid of the offscreen contents, which is not necessary, but was much easier to implement, since I couldn't find an easy way to invalidate the framebuffer). What's the big deal with repainting everything? It's not like you would do 100 mode changes per second so it would be performance-critical... It's ugly, but that's not the point. The point is that all deployed versions of X (and even current X.org CVS head still, in fact) make this assumption. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Tue, 2005-03-15 at 09:29 -0500, Jon Smirl wrote: Aonther approach would be to just say you have to choose to run one of X, DirectFB, FBUI, XGL and you can't switch between them. Other than developers I don't know if anyone really runs more than one of these at a time. FWIW, yes we do. We're developing a system for neuro-scientific experiments where we enjoy having a fast and lightweight graphics stack with access to VSYNC interrupt (DirectFBGL) for reliable frame timing of visual stimuli. OTOH the experimenter gets a QT control GUI running on a second graphics card with regular X. As this is not very common and quite a hassle to setup (e.g. X stomping on other card's IRQ and the like) I'm eagerly following all efforts to build a common standard graphics base with improved multi-head and GL support. That said, I realise that this is not a very widespread use-case. But nonetheless there are such applications. Thanks, Jan --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
Jon Smirl wrote: Can we put in our own fault handler for the mmap, trap the directfb accesses and do the proper locking? Some SGI hardware used to work like that. When they asked Linus for some kernel hooks to support that type of thing, well...I'm just glad *I* wasn't in the line of fire. ;) I seriously doubt that it would be looked upon any kinder now. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
DirectFB assumes all memory outside var.yres_virtual * fix.line_length is preserved. A totally valid assumption in my opinion. Except that you can't know in advance how much fix.line_length will be. The fix isn't really fixed. Different cards will have different requirements depending on the bit depth for example. On radeonfb, the line_length will vary due to alignment constraints related to the engine, or due to tiling, etc etc... So you basically don't know in advance what will be preserved... (And you can't, unless you start having all sort of card specific knowledge). Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, Mar 16, 2005 at 09:44:19AM +1100, Benjamin Herrenschmidt wrote: DirectFB assumes all memory outside var.yres_virtual * fix.line_length is preserved. A totally valid assumption in my opinion. Except that you can't know in advance how much fix.line_length will be. The fix isn't really fixed. Different cards will have different requirements depending on the bit depth for example. On radeonfb, the line_length will vary due to alignment constraints related to the engine, or due to tiling, etc etc... So you basically don't know in advance what will be preserved... (And you can't, unless you start having all sort of card specific knowledge). True. Currently DirectFB doesn't handle this correctly. But that could be easily fixed if only line_length wasn't totally misplaced. It really belongs to fb_var_screeninfo. We could first test the mode with FB_ACTIVATE_TEST and actually see how much memory it needs and could evict enough offscreen surfaces to make room before actually setting the mode. Currently it would need some guesswork. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
I once did a similar thing for an embedded prototype: take a fixed amount of
memory for both frame buffers (this was a UMA system), fb0 starts from the
top,
fb1 starts from the bottom. You can enlarge each frame buffer, until you
read
the memory of the other. Each fix.smem_{start,len} corresponds exactly to
the
memory allocated to each frame buffer.
Of course, if you also want off-screen memory (i.e. memory beyond
xres_virtual*yres_virtual*bpp/8), things get more complicated, since
currently
there's no way for the application to ask for a minimum amount of off-screen
memory. Perhaps a new field in fb_var_screeninfo (and zero means `I don't
care', for backwards compatibility).
Offscreen memory is pretty much essential for DirectFB.
I still tend to think that offscreen memory is busted on mode
switches...
Now, I agree that cutting the vram in half, and reserving both halves
to the offscreen needs to each head may help avoiding mode switch on
one head busting things used by whoever works on the second head, but
I'm not sure that fits the DRM needs very well..
Ben.
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Tue, 2005-03-15 at 16:00 +0200, Ville Syrjälä wrote: DirectFB has it's own asbitration mechanism. It doesn't support using multiple framebuffer devices at the same time. For that to work DirectFB would just have to know if some of the framebuffer devices are actually different outputs of the same card so that it could associate both with the same lock and accelerator state. With the current system I don't see much chance of using accelerated fbcon on one head and accelerated DirectFB (or something else) on the other. Oh, I think that won't happen unless directFB maps it's arbitration mecanism on top of the DRM lock and fbcon does that too. BTW. Can you quickly explain me the DirectFB arbitration mecanism ? We'll need to map it on top of the VGA arbiter _at_least_ ... Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Tuesday 15 March 2005 21:36, Ville Syrjälä wrote: On Tue, Mar 15, 2005 at 09:51:40AM +0100, Geert Uytterhoeven wrote: On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrj??wrote: If radeonfb will allocate the buffer for the second head from the top of the memory users would basically have to guess it's location. matroxfb simply cuts the memory in two pieces and allocates the buffers from the start of each piece. I don't really like that approach. Adding a simple byte_offset field to fb_var_screeninfo would solve the problem quite nicely but I don't know if such API changes are acceptable at this stage. You wouldn't have to guess its location, look at fix.smem_start. But how would someone mmap() the whole memory then? matroxfb already plays This is multi-head, right? That implies one fb per head. So, can't you do separate mmaps? fb0-fix.smem_start|len and fb1-fix.smem_start|len. Tony --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 2005-03-16 at 01:05 +0200, Ville Syrjälä wrote: True. Currently DirectFB doesn't handle this correctly. But that could be easily fixed if only line_length wasn't totally misplaced. It really belongs to fb_var_screeninfo. We could first test the mode with FB_ACTIVATE_TEST and actually see how much memory it needs and could evict enough offscreen surfaces to make room before actually setting the mode. Currently it would need some guesswork. Agreed. line_lenght was misplaced... I suppose there may be interest in making a v2 of the var structure and using a flag to indicate wether we are passing a v1 or a v2 one... In the meantime, can you tell me more about your arbitration scheme ? Arbitration is what I'm trying to solve. There are two main issues: multiple card arbitration (that is, the VGA cruft to deal with) and arbitration between access on X heads of the same card (which would be nice, but not mandatory, DirectFB may take over all heads of the card, doing that wuld require proper use of the DRM lock engine context switch, more of a long term goal). Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 2005-03-16 at 07:37 +0800, Antonino A. Daplas wrote: On Tuesday 15 March 2005 21:36, Ville Syrjälä wrote: On Tue, Mar 15, 2005 at 09:51:40AM +0100, Geert Uytterhoeven wrote: On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrj??wrote: If radeonfb will allocate the buffer for the second head from the top of the memory users would basically have to guess it's location. matroxfb simply cuts the memory in two pieces and allocates the buffers from the start of each piece. I don't really like that approach. Adding a simple byte_offset field to fb_var_screeninfo would solve the problem quite nicely but I don't know if such API changes are acceptable at this stage. You wouldn't have to guess its location, look at fix.smem_start. But how would someone mmap() the whole memory then? matroxfb already plays This is multi-head, right? That implies one fb per head. So, can't you do separate mmaps? fb0-fix.smem_start|len and fb1-fix.smem_start|len. Sure, re-read the thread :) Also, he's worried about management of offscreen memory. (which is an issue too because of possible problems with the setup of the apertures - start of the discussion, and because it seems that directFB has only been tested on little endian machines (damn them !) and thus doesn't understand the problem with swapper on framebuffer access). Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, Mar 16, 2005 at 10:50:52AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2005-03-16 at 07:37 +0800, Antonino A. Daplas wrote: On Tuesday 15 March 2005 21:36, Ville Syrjälä wrote: On Tue, Mar 15, 2005 at 09:51:40AM +0100, Geert Uytterhoeven wrote: On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrj??wrote: If radeonfb will allocate the buffer for the second head from the top of the memory users would basically have to guess it's location. matroxfb simply cuts the memory in two pieces and allocates the buffers from the start of each piece. I don't really like that approach. Adding a simple byte_offset field to fb_var_screeninfo would solve the problem quite nicely but I don't know if such API changes are acceptable at this stage. You wouldn't have to guess its location, look at fix.smem_start. But how would someone mmap() the whole memory then? matroxfb already plays This is multi-head, right? That implies one fb per head. So, can't you do separate mmaps? fb0-fix.smem_start|len and fb1-fix.smem_start|len. Sure, re-read the thread :) Also, he's worried about management of offscreen memory. (which is an issue too because of possible problems with the setup of the apertures - start of the discussion, There's also the case with Matrox Millennium I/II cards. They must place the visible frame buffer so that no line crosses the boundary of memory banks. matroxfb deals with that by moving the buffer and changing smem_start and smem_len appropriately. But that is really bad for DirectFB's offscreen memory management. After a mode switch the memory manager would need to know what kind of initial byte offset was used. Of couse it would be possible to determine that from smem_start by knowing how the aperture must be aligned. Actually we already do that sort of thing to allow hw accelerated rendering when used on matroxfb controlled G450/G450/G550 CRTC2. But in that case the offset won't change on mode switch. and because it seems that directFB has only been tested on little endian machines (damn them !) and thus doesn't understand the problem with swapper on framebuffer access). Actually people do use it on big-endian systems but since neither the mach64, ati128 or radeon drivers play with the swapper settings I can only assume that they haven't been tested very extensively. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 2005-03-16 at 03:47 +0200, Ville Syrjälä wrote: There's also the case with Matrox Millennium I/II cards. They must place the visible frame buffer so that no line crosses the boundary of memory banks. matroxfb deals with that by moving the buffer and changing smem_start and smem_len appropriately. But that is really bad for DirectFB's offscreen memory management. After a mode switch the memory manager would need to know what kind of initial byte offset was used. Of couse it would be possible to determine that from smem_start by knowing how the aperture must be aligned. Actually we already do that sort of thing to allow hw accelerated rendering when used on matroxfb controlled G450/G450/G550 CRTC2. But in that case the offset won't change on mode switch. So it alls end up to - mode switch has to bust memory layout, and any assumptions that DirectFB tries to do are incorrect. The only sane thing that could be done is along the lines you suggested, that is move most of fix into var so that the card can tell in advance what the layout looks like. But again, this is all going nowhere in the long run. One of the plans we have is to have the mode setting be independant of the client. While a client might lock it, we want a model where the user triggers a mode setting via some mode setting desktop geometry management library that interfaces to fbdev, and clients be notified. For that to work, it also requires proper arbitration though, so we may end up again limit that functionality to clients using the DRM for artbitration and lock everything when some guy like DirectFB enters the picture. and because it seems that directFB has only been tested on little endian machines (damn them !) and thus doesn't understand the problem with swapper on framebuffer access). Actually people do use it on big-endian systems but since neither the mach64, ati128 or radeon drivers play with the swapper settings I can only assume that they haven't been tested very extensively. You are wrong here, all of those 3 drivers do play with the swapper setting, they all 3 set the swapper based on the bit depth of the screen, so writing an image to offscreen memory with a different bit depth will be broken. See usage of SURFACE_CNTL in radeonfb for example. Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
It's ugly, but that's not the point. The point is that all deployed versions of X (and even current X.org CVS head still, in fact) make this assumption. Oh, that's fine and that's not a problem. I will only repaint the framebuffer on bit depth or line lenght changes. I'm trying to talk about the _future_ here. That is support for dual head at the fbdev level and other niceties. We simply cannot guarantee preserving the video memory accross mode switches. We have enumerated enough examples of that, and Ville himself came up with a nice one about Matrox. What we _can_ do is let people know what was expelled from video memory eventually. But even the let's ask fdbev what will change before the actual mode switch isn't really a good idea in the long run since it sort-of defeats the purpose of having a common memory manager. Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 2005-03-16 at 10:33 +1100, Benjamin Herrenschmidt wrote: Now, I agree that cutting the vram in half, and reserving both halves to the offscreen needs to each head may help avoiding mode switch on one head busting things used by whoever works on the second head, but I'm not sure that fits the DRM needs very well.. It probably doesn't, but it seems to me like that's all that can be done with the current fbdev API. On Wed, 2005-03-16 at 12:51 +1100, Benjamin Herrenschmidt wrote: On Wed, 2005-03-16 at 03:47 +0200, Ville Syrjl wrote: There's also the case with Matrox Millennium I/II cards. They must place the visible frame buffer so that no line crosses the boundary of memory banks. [...] That still doesn't require any changes on mode switches as long as the pitch stays the same, does it? So it alls end up to - mode switch has to bust memory layout, [...] Why? All that a mode switch changes is how the current screen surface is scanned out. It shouldn't have any implicit effect on memory allocation or even contents. [...] For that to work, it also requires proper arbitration though, so we may end up again limit that functionality to clients using the DRM for artbitration and lock everything when some guy like DirectFB enters the picture. I was thinking about something like that as well, may be the only way to preserve the current fbdev API and offer something more sophisticated. and because it seems that directFB has only been tested on little endian machines (damn them !) and thus doesn't understand the problem with swapper on framebuffer access). Actually people do use it on big-endian systems but since neither the mach64, ati128 or radeon drivers play with the swapper settings I can only assume that they haven't been tested very extensively. You are wrong here, all of those 3 drivers do play with the swapper setting, [...] I think he was referring to the DirectFB drivers. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 2005-03-16 at 00:21 -0500, Michel Dänzer wrote: Actually people do use it on big-endian systems but since neither the mach64, ati128 or radeon drivers play with the swapper settings I can only assume that they haven't been tested very extensively. You are wrong here, all of those 3 drivers do play with the swapper setting, [...] I think he was referring to the DirectFB drivers. Well, do they revert it after atyfb/aty128fb/radeonfb set it then ? it's definitely set on mode switch. Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Tue, 2005-03-15 at 09:37 +1100, Benjamin Herrenschmidt wrote: Be that as it may, it remains a fact that such a change would break existing installations... I think that mode setting and memory allocation should be separated. X will always reserve enough video RAM for the largest resolution it uses for the screen contents. But X has no control on where fbdev will allocate memory. My understanding is that so far, the fbdev API has pretty much implied that any mode scans out the beginning of the memory accessed via the framebuffer device, unless the panning ioctl is used. IIRC at least DirectFB makes basically the same assumptions as X there. We are thinking with the new model in mind, and so far, a mode setting is under control of the framebuffer. Content of video memory (framebuffer, textures, overlay, whatever) simply cannot be considered as preserved accross mode switches. We can't also block all evolutions just because we have to support a broken model. I'm not suggesting that, but I do think that tying together mode switching and memory allocation would be a big mistake. The EGL API for this is currently being discussed on the dri-egl list (http://lists.freedesktop.org/mailman/listinfo/dri-egl), you may want to join in there. We'll need to find a way to deal with that. An idea would be for me to do the clearing only when I come from a different bit depth or from text mode. That is, what i want to avoid, is those artifacts caused by incorrect bit depth content. A strict mode change isn't an issue in this case. That would solve my immediate problem. Sounds good. _BUT_ in the long run, X will have to be smarter. Current UseFBDev or X fbdev can't support dual head properly on top of fbdev anyway, Agreed for UseFBDev, but what's the problem with fbdev? But until all clients are DRI clients, we have a problem. Keep in mind that basically the only driver-independent API exposed by the DRI is OpenGL, so I'm afraid it's unlikely that all fbdev applications will take that route. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Mon, 14 Mar 2005 23:59:37 -0500, Michel Dänzer [EMAIL PROTECTED] wrote: On Tue, 2005-03-15 at 09:37 +1100, Benjamin Herrenschmidt wrote: Be that as it may, it remains a fact that such a change would break existing installations... I think that mode setting and memory allocation should be separated. X will always reserve enough video RAM for the largest resolution it uses for the screen contents. But X has no control on where fbdev will allocate memory. My understanding is that so far, the fbdev API has pretty much implied that any mode scans out the beginning of the memory accessed via the framebuffer device, unless the panning ioctl is used. IIRC at least DirectFB makes basically the same assumptions as X there. We are working on adding secondary head support on radeonfb. Where does the second buffer go when fbdev is running standalone? We are thinking with the new model in mind, and so far, a mode setting is under control of the framebuffer. Content of video memory (framebuffer, textures, overlay, whatever) simply cannot be considered as preserved accross mode switches. We can't also block all evolutions just because we have to support a broken model. I'm not suggesting that, but I do think that tying together mode switching and memory allocation would be a big mistake. If fbdev is running standalone and two heads are active, there has to be some very primitive buffer management going on. This may be as simple as fb0 starts at 0, and fb1 is at the end of CONFIG_APER_SIZE. When DRM loads it can install hooks to a more sophisticated memory manager. The EGL API for this is currently being discussed on the dri-egl list (http://lists.freedesktop.org/mailman/listinfo/dri-egl), you may want to join in there. help me out with the relevant attribute/value pairs for modes We'll need to find a way to deal with that. An idea would be for me to do the clearing only when I come from a different bit depth or from text mode. That is, what i want to avoid, is those artifacts caused by incorrect bit depth content. A strict mode change isn't an issue in this case. That would solve my immediate problem. Sounds good. _BUT_ in the long run, X will have to be smarter. Current UseFBDev or X fbdev can't support dual head properly on top of fbdev anyway, Agreed for UseFBDev, but what's the problem with fbdev? But until all clients are DRI clients, we have a problem. Keep in mind that basically the only driver-independent API exposed by the DRI is OpenGL, so I'm afraid it's unlikely that all fbdev applications will take that route. There is a 300K OpenGL-ES to framebuffer implementation on sourceforge that someone might get working in this model. There is also a big difference between sharing the system with XGL and an app writen to use fbdev versus supporting an embedded system where only the fbdev app is running. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ xorg mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/xorg -- Jon Smirl [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Tue, 15 Mar 2005 09:37:53 +1100, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Be that as it may, it remains a fact that such a change would break existing installations... I think that mode setting and memory allocation should be separated. X will always reserve enough video RAM for the largest resolution it uses for the screen contents. But X has no control on where fbdev will allocate memory. We are thinking with the new model in mind, and so far, a mode setting is under control of the framebuffer. Content of video memory (framebuffer, textures, overlay, whatever) simply cannot be considered as preserved accross mode switches. I can agree that all video memory for that head can be booted. But just because one head changes mode we shouldn't boot the objects for the other head. You wouldn't want the two user case of one user changing modes making the other user's display blink. We can't also block all evolutions just because we have to support a broken model. We'll need to find a way to deal with that. An idea would be for me to do the clearing only when I come from a different bit depth or from text mode. That is, what i want to avoid, is those artifacts caused by incorrect bit depth content. A strict mode change isn't an issue in this case. That would solve my immediate problem. _BUT_ in the long run, X will have to be smarter. Current UseFBDev or X fbdev can't support dual head properly on top of fbdev anyway, so that means I have some flexibility. The second head will probably move on mode switches since I intend to allocate it at the top of the accessible aperture as described by Jon. I agree that X has to be fixed to work cooperatively in this environment. The alternative is to just leave X alone and make all of this work for XGL. The user would then choose which environment they want to run. I'm leaning toward just leaving X alone and spending the resources on making XGL work. After all XGL is a complete X replacement. If you want to run existing X load an old fbdev driver. We can keep both fbdev drivers in the kernel until it is clear if XGL is going mainstream. One thing that does need to get fixed is mesa support for non-accelerated fbdev drivers but mesa can add all of the appropriate locking. All of that just keep uncovering more and more issues with our current fbdev model though. From discussions we had so far, it uncovers the problem of arbitration. That is, can we simply afford having a process mmap /dev/fb and blast things to it without any arbitration like we do today ? If the answer is yes, then we are in deep trouble for lots of reason: - VGA Arbitration might require us to flip/flop MEM/IO enable bits - Swapper control as explained earlier unless I can reserve a swapper for each head, that is manage to have one aperture per head - Engine discipline. What if the client on head 0 (like current X) uses the engine ? Even if the one on head 1 doesn't, simple framebuffer accesses can be enough to lock up the card. - etc I think that Jon's dream of having totally independant heads that can run 2 separate applications is a long way away and we have sort-of to tie /dev/fb's together, though I don't know how to acheive that in practice, unless we switch to a new API that can enforce it. The current fbdev API cannot. This is definitely something to works towards. There is a lot of application for this in schools, libraries, internet cafe, etc. There are several companies selling variations on this. I don't expect an immediate solution but I want to make sure the redesign allows it to be built. DRI can do such things afaik (manage several contexts etc...), at least provides the infrastructure for it. But until all clients are DRI clients, we have a problem. That means that any direct fb client has to take over the entire card. All heads. There is simply no choice, and that doesn't even help with the VGA arbitration issue which still require explicit lock/unlock around accesses. I'm open to suggestions... Can we put in our own fault handler for the mmap, trap the directfb accesses and do the proper locking? Ben. ___ xorg mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/xorg -- Jon Smirl [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Mon, Mar 14, 2005 at 11:59:37PM -0500, Michel Dänzer wrote: On Tue, 2005-03-15 at 09:37 +1100, Benjamin Herrenschmidt wrote: Be that as it may, it remains a fact that such a change would break existing installations... I think that mode setting and memory allocation should be separated. X will always reserve enough video RAM for the largest resolution it uses for the screen contents. But X has no control on where fbdev will allocate memory. My understanding is that so far, the fbdev API has pretty much implied that any mode scans out the beginning of the memory accessed via the framebuffer device, unless the panning ioctl is used. IIRC at least DirectFB makes basically the same assumptions as X there. DirectFB assumes all memory outside var.yres_virtual * fix.line_length is preserved. A totally valid assumption in my opinion. It allocates all offscreen memory starting from the top of the memory so overlaps with fbdev are as rare as possible. Currently it doesn't handle multi head except for Matrox G400/G450/G550 TV-out but that is handled without fbdev so no API limitations get in the way. I think that making the assumption that all memory is preserved when the memory layout (virtual resolution and depth) doesn't change is perfectly valid too. That would allow X to do it's Ctrl-Alt-+ and - things without repainting the whole screen. If radeonfb will allocate the buffer for the second head from the top of the memory users would basically have to guess it's location. matroxfb simply cuts the memory in two pieces and allocates the buffers from the start of each piece. I don't really like that approach. Adding a simple byte_offset field to fb_var_screeninfo would solve the problem quite nicely but I don't know if such API changes are acceptable at this stage. We are thinking with the new model in mind, and so far, a mode setting is under control of the framebuffer. Content of video memory (framebuffer, textures, overlay, whatever) simply cannot be considered as preserved accross mode switches. We can't also block all evolutions just because we have to support a broken model. I'm not suggesting that, but I do think that tying together mode switching and memory allocation would be a big mistake. Indeed. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Mon, 2005-03-14 at 23:59 -0500, Michel Dänzer wrote: On Tue, 2005-03-15 at 09:37 +1100, Benjamin Herrenschmidt wrote: Be that as it may, it remains a fact that such a change would break existing installations... I think that mode setting and memory allocation should be separated. X will always reserve enough video RAM for the largest resolution it uses for the screen contents. But X has no control on where fbdev will allocate memory. My understanding is that so far, the fbdev API has pretty much implied that any mode scans out the beginning of the memory accessed via the framebuffer device, unless the panning ioctl is used. IIRC at least DirectFB makes basically the same assumptions as X there. But that will not be true with dual head unless I put the second framebuffer into some fixed location in memory, thus making life more difficult for the allocator. I'm not suggesting that, but I do think that tying together mode switching and memory allocation would be a big mistake. The EGL API for this is currently being discussed on the dri-egl list (http://lists.freedesktop.org/mailman/listinfo/dri-egl), you may want to join in there. I'll try, I'm near by bandwidth limit already though. We'll need to find a way to deal with that. An idea would be for me to do the clearing only when I come from a different bit depth or from text mode. That is, what i want to avoid, is those artifacts caused by incorrect bit depth content. A strict mode change isn't an issue in this case. That would solve my immediate problem. Sounds good. _BUT_ in the long run, X will have to be smarter. Current UseFBDev or X fbdev can't support dual head properly on top of fbdev anyway, Agreed for UseFBDev, but what's the problem with fbdev? Read the rest of the email. But until all clients are DRI clients, we have a problem. Keep in mind that basically the only driver-independent API exposed by the DRI is OpenGL, so I'm afraid it's unlikely that all fbdev applications will take that route. I meant DRM. That is some arbitration locking. There is simply _NO_ way we can have something that works with both independant multiple heads and direct banging of the framebuffer without arbitration. There is no magic here. It _can_ be made to work in _some_ cases using the separate swappers, but that won't help if one of the heads try to do accel Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Tue, 2005-03-15 at 00:30 -0500, Jon Smirl wrote: I agree that X has to be fixed to work cooperatively in this environment. The alternative is to just leave X alone and make all of this work for XGL. The user would then choose which environment they want to run. I'm leaning toward just leaving X alone and spending the resources on making XGL work. After all XGL is a complete X replacement. If you want to run existing X load an old fbdev driver. We can keep both fbdev drivers in the kernel until it is clear if XGL is going mainstream. One thing that does need to get fixed is mesa support for non-accelerated fbdev drivers but mesa can add all of the appropriate locking. No, that isn't realistic. I want a smooth transition, and XGL won't be the only player in the field anyway. I think that Jon's dream of having totally independant heads that can run 2 separate applications is a long way away and we have sort-of to tie /dev/fb's together, though I don't know how to acheive that in practice, unless we switch to a new API that can enforce it. The current fbdev API cannot. This is definitely something to works towards. There is a lot of application for this in schools, libraries, internet cafe, etc. There are several companies selling variations on this. I don't expect an immediate solution but I want to make sure the redesign allows it to be built. Yes. But I think that we should basically consider that anybody openng /dev/fb also locks out write access to the other heads. That is, the other head can be opened, but nothing done (mmap etc... on it) unless both opener's have done the right ioctl telling us they know how to do arbitration or that kind of thing. No ? The fbdev API needs a mirror of the vga arbitration API. The later is for use only by applications directly tapping vga legacy stuff. But something using fbdev also need a lock/unlock API to enclose any hardware access, at the very least. And when you think about it, what you end up needing is ... the DRM lock. So there might be some need to have fbdev be capable of taking the DRM lock now. Unless that's done, I'll have to impose severe restrictions on accesses to radeonfb's second head. Can we put in our own fault handler for the mmap, trap the directfb accesses and do the proper locking? Gack. First that's lazy locking and something I'd like to avoid, but if directfb API doesn't provide any other option ... then, it also requires regulary un-mapping them back from the process using directfb or the stuff will remain locked forever, and unmapping things behind a process back isn't cool (some interesting locking issues). Overall rather complicated and inefficient performance wise. And part of that infrastructure already exist, somewhat, in the DRM ... If a directFB client uses a /dev/fb, I think it should own both heads. We simply can't do anything else. And we might even still need arbitration because of the VGA stuff in case the card we are using has legacy decoding enabled _anyway_. So Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Tue, 2005-03-15 at 08:01 +0200, Ville Syrjälä wrote: If radeonfb will allocate the buffer for the second head from the top of the memory users would basically have to guess it's location. matroxfb simply cuts the memory in two pieces and allocates the buffers from the start of each piece. I don't really like that approach. Adding a simple byte_offset field to fb_var_screeninfo would solve the problem quite nicely but I don't know if such API changes are acceptable at this stage. And we don't know if all HW would support it anyway. We are thinking with the new model in mind, and so far, a mode setting is under control of the framebuffer. Content of video memory (framebuffer, textures, overlay, whatever) simply cannot be considered as preserved accross mode switches. We can't also block all evolutions just because we have to support a broken model. I'm not suggesting that, but I do think that tying together mode switching and memory allocation would be a big mistake. Indeed. The main issue hwoever, is access arbitration. I'd appreciate your DirectFB point of view on these things. Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
