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, 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
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, 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
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
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
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
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
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:
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 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
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
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
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
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
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 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
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
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
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
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
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
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
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
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-+
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
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
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
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 -
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.
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. ;)
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
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
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 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
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 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
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
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
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
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
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
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
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
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
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.
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
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
57 matches
Mail list logo
