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
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
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
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
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.
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
20 matches
Mail list logo
