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: [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: [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: [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: [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: [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: [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: [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: [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: [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: [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
