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
On Sun, Mar 13, 2005 at 11:04:59PM +1100, Benjamin Herrenschmidt wrote:
I must be missing something something obvious because I don't quite
understand what major drawbacks there are with the non-overlapping mode.
As I see it you get at least the same amount of CPU accessible memory as
On Mon, 2005-03-14 at 18:12 +1100, Benjamin Herrenschmidt wrote:
On Sun, 2005-03-13 at 23:28 -0500, Michel Dnzer wrote:
On Sun, 2005-03-13 at 17:43 +1100, Benjamin Herrenschmidt wrote:
And finally, I want to blank the screen (using the accel engine) before
setting the new mode, so
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
In an ideal world ... However, since we are planning to move the memory
manager to the kernel, that would mean a kernel access (syscall, ioctl,
whatever...) twice per access to AGP memory. Not realistic.
Could the user space driver batch many
On Mon, Mar 14, 2005 at 05:30:04PM +0100, Soeren Sandmann wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
In an ideal world ... However, since we are planning to move the memory
manager to the kernel, that would mean a kernel access (syscall, ioctl,
whatever...) twice per access
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ville Syrjälä wrote:
Makes me wish I had a PPC box alongside the x86 one.
You might like to try http://pearpc.sourceforge.net/.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Ok so the problem is byte swapping. Looking at atyfb for example it uses
the big-endian aperture on big-endian systems and selects the byte
swapping method according to the bit depth. If that really means that all
host access to the aperture gets byte swapped then I don't see how the
On Mon, 2005-03-14 at 11:20 -0500, Michel Dänzer wrote:
On Mon, 2005-03-14 at 18:12 +1100, Benjamin Herrenschmidt wrote:
On Sun, 2005-03-13 at 23:28 -0500, Michel Dänzer wrote:
On Sun, 2005-03-13 at 17:43 +1100, Benjamin Herrenschmidt wrote:
And finally, I want to blank the screen
On Mon, 2005-03-14 at 17:30 +0100, Soeren Sandmann wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
In an ideal world ... However, since we are planning to move the memory
manager to the kernel, that would mean a kernel access (syscall, ioctl,
whatever...) twice per access to AGP
On Tue, 2005-03-15 at 08:52 +1100, Benjamin Herrenschmidt wrote:
On Mon, 2005-03-14 at 11:20 -0500, Michel Dnzer wrote:
On Mon, 2005-03-14 at 18:12 +1100, Benjamin Herrenschmidt wrote:
On Sun, 2005-03-13 at 23:28 -0500, Michel Dnzer wrote:
On Sun, 2005-03-13 at 17:43 +1100, Benjamin
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
On Sun, Mar 13, 2005 at 12:35:43PM +1100, Benjamin Herrenschmidt wrote:
Hi !
I'm currently rewriting radeonfb to implement support for dual head, and
ultimately, to make it more friendly to be hooked on DRM for mesa-solo
style setups.
I have some issues however related to the way memory
On Sun, 2005-03-13 at 10:22 +0200, Ville Syrjälä wrote:
- We only really need to bother about CPU access for the framebuffer
itself (and possibly the cursor). That is normal non-accelerated fbdev
operations an mmap'ing of the framebuffer in user space. This is not
really a problem if
On Sun, Mar 13, 2005 at 08:20:45PM +1100, Benjamin Herrenschmidt wrote:
On Sun, 2005-03-13 at 10:22 +0200, Ville Syrjälä wrote:
- We only really need to bother about CPU access for the framebuffer
itself (and possibly the cursor). That is normal non-accelerated fbdev
operations an
AGP as it's currently used is pretty much pointless for software fallbacks
since reading from AGP memory is nearly as slow as reading from video
memory.
Hrm.. I wouldn't expect _that_ slow. It's uncacheable, right, but still
on a faster bus. Especially if we use it the way we do on ppc
On Sun, Mar 13, 2005 at 11:19:35AM -0500, Jon Smirl wrote:
On Sun, 13 Mar 2005 23:04:59 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
AGP as it's currently used is pretty much pointless for software fallbacks
since reading from AGP memory is nearly as slow as reading from video
On Sun, 13 Mar 2005 19:47:14 +0200, Ville Syrjälä [EMAIL PROTECTED] wrote:
I don't understand why we have GART memory anyway. It's just main memory
and I don't see any point going through the GART to access it with the
CPU. Only the graphics card needs to use the GART.
I see no need to for the
On Sun, 13 Mar 2005 23:04:59 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
AGP as it's currently used is pretty much pointless for software fallbacks
since reading from AGP memory is nearly as slow as reading from video
memory.
Hrm.. I wouldn't expect _that_ slow. It's
On Sun, 2005-03-13 at 11:19 -0500, Jon Smirl wrote:
On Sun, 13 Mar 2005 23:04:59 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
AGP as it's currently used is pretty much pointless for software fallbacks
since reading from AGP memory is nearly as slow as reading from video
If you are doing fallback calculations in a 6MB buffer that is 1,500
pages. Accessing all of this effectively flushes the data cache. Once
you are done with it you probably don't want those pages in the cache
anyway.
I don't understand why we have GART memory anyway. It's just main
The best model would be to chuck the AGP/PCI Express interface on the
board and have a hyperchannel instead. Hyperchannel provides full
cache consistency without all of these flushing problems. The GPU
really is another specialized CPU, give it a CPU class memory
interface.
You mean
On Mon, 14 Mar 2005 08:49:13 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
If you are doing fallback calculations in a 6MB buffer that is 1,500
pages. Accessing all of this effectively flushes the data cache. Once
you are done with it you probably don't want those pages in the cache
[slightly off topic]
Am Sonntag, den 13.03.2005, 12:56 -0500 schrieb Jon Smirl:
On Sun, 13 Mar 2005 19:47:14 +0200, Ville Syrjälä [EMAIL PROTECTED] wrote:
I don't understand why we have GART memory anyway. It's just main memory
and I don't see any point going through the GART to access it
On Sun, 2005-03-13 at 17:10 -0500, Jon Smirl wrote:
On Mon, 14 Mar 2005 08:49:13 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
If you are doing fallback calculations in a 6MB buffer that is 1,500
pages. Accessing all of this effectively flushes the data cache. Once
you are done
On Mon, 14 Mar 2005 08:52:46 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
The best model would be to chuck the AGP/PCI Express interface on the
board and have a hyperchannel instead. Hyperchannel provides full
cache consistency without all of these flushing problems. The GPU
On Sun, 2005-03-13 at 17:17 -0500, Jon Smirl wrote:
On Mon, 14 Mar 2005 08:52:46 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
The best model would be to chuck the AGP/PCI Express interface on the
board and have a hyperchannel instead. Hyperchannel provides full
cache
On Sun, 2005-03-13 at 23:21 +0100, Felix Kühling wrote:
[slightly off topic]
Am Sonntag, den 13.03.2005, 12:56 -0500 schrieb Jon Smirl:
On Sun, 13 Mar 2005 19:47:14 +0200, Ville Syrjälä [EMAIL PROTECTED] wrote:
I don't understand why we have GART memory anyway. It's just main memory
On Mon, 14 Mar 2005 09:20:01 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
On Sun, 2005-03-13 at 17:10 -0500, Jon Smirl wrote:
On Mon, 14 Mar 2005 08:49:13 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
If you are doing fallback calculations in a 6MB buffer that is 1,500
I'm not being clear
Leave AGP memory as normal RAM
driver does it thing to the memory
driver executes flush of data cache on CPU
after flush tell GPU to access the data
The performance hit of executing the flush is probably negligible
since you probably didn't care about anything
On Sun, Mar 13, 2005 at 06:00:01PM -0500, Jon Smirl wrote:
On Mon, 14 Mar 2005 09:20:01 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
Though the flushes may be fast if there is no actual hit in the cache, I
agree. Again, that should be benched.
In fact, i would _love_ to be
That shouldn't matter the page brought in would be for a speculative
read and never accessed. It should just fall out of the cache and not
be written back. There is only one cachable mapping. In this model
writes are always followed by a flush before telling the GPU to access
the memory
On Mon, Mar 14, 2005 at 10:48:19AM +1100, Benjamin Herrenschmidt wrote:
That shouldn't matter the page brought in would be for a speculative
read and never accessed. It should just fall out of the cache and not
be written back. There is only one cachable mapping. In this model
writes
I don't think normal drivers do them at all. I did experiment with
DirectFB at one point and had it place all offscreen surfaces to AGP
memory. It worked really well on my hardware (G400 + VIA KT133
northbridge). I also tried it with PCI transfers and that too worked but
was naturally
On Mon, 14 Mar 2005 10:48:19 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
That shouldn't matter the page brought in would be for a speculative
read and never accessed. It should just fall out of the cache and not
be written back. There is only one cachable mapping. In this
On Sun, Mar 13, 2005 at 07:25:15PM -0500, Jon Smirl wrote:
On Mon, 14 Mar 2005 10:48:19 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
That shouldn't matter the page brought in would be for a speculative
read and never accessed. It should just fall out of the cache and not
Jon Smirl writes:
It works, but it's illegal. That means that the CPU might well speculate
a load from one of these pages in kernel-land just because it happens to
be next to a page where you are iterating an array, and may then bring a
bit in the cache from that page.
That shouldn't
On Sun, 2005-03-13 at 19:25 -0500, Jon Smirl wrote:
On Mon, 14 Mar 2005 10:48:19 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
That shouldn't matter the page brought in would be for a speculative
read and never accessed. It should just fall out of the cache and not
be
On Mon, Mar 14, 2005 at 11:41:23AM +1100, Paul Mackerras wrote:
Jon Smirl writes:
It works, but it's illegal. That means that the CPU might well speculate
a load from one of these pages in kernel-land just because it happens to
be next to a page where you are iterating an array, and
On Mon, 2005-03-14 at 02:39 +0200, Ville Syrjälä wrote:
On Sun, Mar 13, 2005 at 07:25:15PM -0500, Jon Smirl wrote:
On Mon, 14 Mar 2005 10:48:19 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
That shouldn't matter the page brought in would be for a speculative
read and
On Mon, 14 Mar 2005 12:05:59 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
It should be the responsibility of the memory manager. If anything wants
to access the memory it would call lock() and when it's done with the
memory it calls unlock(). That's exactly how DirectFB's memory
On Sun, 2005-03-13 at 20:47 -0500, Jon Smirl wrote:
On Mon, 14 Mar 2005 12:05:59 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
It should be the responsibility of the memory manager. If anything wants
to access the memory it would call lock() and when it's done with the
[EMAIL PROTECTED] removed from CC since I can't post to it.
Jon Smirl writes:
It shouldn't hurt to have a parallel non-cached mapping being used in
conjuction with this protocol. By definition the non-cached mapping
never gets into an inconsistent state.
According to the PowerPC Architecture
On Sun, 2005-03-13 at 17:43 +1100, Benjamin Herrenschmidt wrote:
And finally, I want to blank the screen (using the accel engine) before
setting the new mode, so that we come out clean of the mode setting
(without ugly artifact), and I will probably clean both fb's (simpler).
That would
On Mon, 14 Mar 2005 15:07:26 +1100, Paul Mackerras [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] removed from CC since I can't post to it.
Jon Smirl writes:
It shouldn't hurt to have a parallel non-cached mapping being used in
conjuction with this protocol. By definition the non-cached
On Sun, 2005-03-13 at 23:40 -0500, Jon Smirl wrote:
On Mon, 14 Mar 2005 15:07:26 +1100, Paul Mackerras [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] removed from CC since I can't post to it.
Jon Smirl writes:
It shouldn't hurt to have a parallel non-cached mapping being used in
1 - 100 of 106 matches
Mail list logo
