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
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2702
--- Additional Comments From [EMAIL PROTECTED] 2005-03-13 00:45 ---
(In
[EMAIL PROTECTED] schrieb:
the drm version of the patch. Straightforward, I did not apply it to cvs
since
it needs a version bump, and I don't think this feature alone is worth
that.
Idx buffer support could be one of such features.
Unfortunately no one seems to be interested in writing
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
Dave Jones wrote:
We got a bug report in our bugzilla from a user that saw
SiS DRM crashing when he restarted X.
The crash seems to be two things.
First, a page allocation failure.
Mar 11 17:52:29 localhost kernel: X: page allocation failure. order:4, mode:0xd0
Mar 11 17:52:29 localhost kernel:
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
On Sunday 13 March 2005 03:10, Adam K Kirchhoff wrote:
Was it always shared with the USB controller? Can you try changing that?
Some more info for both of you...
I remarked, in an earlier e-mail, that glxgears wouldn't cause the
lockups. That's not true. For whatever reason, it doesn't
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
Nicolai Haehnle wrote:
On Sunday 13 March 2005 03:10, Adam K Kirchhoff wrote:
Was it always shared with the USB controller? Can you try changing that?
Some more info for both of you...
I remarked, in an earlier e-mail, that glxgears wouldn't cause the
lockups. That's not true. For
On Sun, 2005-03-13 at 07:43 -0500, Adam K Kirchhoff wrote:
Nicolai Haehnle wrote:
On Sunday 13 March 2005 03:10, Adam K Kirchhoff wrote:
Was it always shared with the USB controller? Can you try changing that?
Some more info for both of you...
I remarked, in an earlier
On Sat, 2005-03-12 at 21:10 -0500, Adam K Kirchhoff wrote:
[snip]
[drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held,
held 0 owner ec8fce80 f7669180
[drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held,
held -2147483648 owner ec8fce80 f7669180
irq 16:
Jan Gukelberger wrote:
On Sat, 2005-03-12 at 21:10 -0500, Adam K Kirchhoff wrote:
[snip]
[drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held,
held 0 owner ec8fce80 f7669180
[drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held,
held -2147483648 owner
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
Vladimir Dergachev wrote:
don't recall ever seeing message from the kernel about nobody caring
about irq 16, or about radeon_cp_reset... With my 9800, I was getting
radeon_cp_dispatch_swap errors.
I do know, however, that my 9200 was working just last week or the week
before. Hmmm... I think my
Hi there.
I have a problem seemingly related to DRM in the current Linus 2.6-bk
tree (2.6.11-bk9 as of this writing). The problem started with
2.6.11-bk3.
Basically the machine is locking up when X (xorg 6.8.1 from FC3) starts
and needs a hard reset to recover. Disabling DRI in X and/or DRM in
I was getting:
Badness in remove_proc_entry at fs/proc/generic.c:693
[c01951ba] remove_proc_entry+0x10a/0x150
[dfb81925] drm_core_exit+0x15/0x48 [drm]
[c01305f4] sys_delete_module+0x144/0x180
[c01564d3] do_munmap+0x143/0x180
[c0156554] sys_munmap+0x44/0x70
[c010311f] syscall_call+0x7/0xb
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
On Gwe, 2005-03-11 at 19:42, Dave Jones wrote:
We got a bug report in our bugzilla from a user that saw
SiS DRM crashing when he restarted X.
This object could be vmalloc()'d
---
SF email is sponsored by - The IT Product Guide
Read honest
Hi,
I played with stencil and this patch is output.
I tested it only on stenciltst from
http://www.sgi.com/products/software/opengl/examples/glut/examples/
This app doesn't use Z_TEST. It show correct output. Somene with more
mesa and r300 knowledge should correct it (there are still problems).
[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
Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
don't recall ever seeing message from the kernel about nobody caring
about irq 16, or about radeon_cp_reset... With my 9800, I was getting
radeon_cp_dispatch_swap errors.
I do know, however, that my 9200 was working just last week or the
week
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
Jerome Glisse wrote:
Maybe the lockup you experiment is linked with the lockup
Adam gets. Adam have you upgraded you kernel recently ?
Maybe a 2.6.10 or even previous one could fix this. Thus
telling that the lockup may be due to some usb change or
some others things in the kernel.
Just trying to
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
Hi all,
I just uploaded a new DRIconf version (0.2.3), which features better
support for floating-point ranges like the brilinear option proposed by
Roland Scheidegger. There are also a few bug fixes and usability
improvements as well as updates and additions to the README file.
This version is
Alright... So drm from both February 14th and January 1st are locking up as
well... Which is odd since I never had any of these problem till this
weekend. I'll start rolling back changes to the Mesa dri driver... Perhaps
this isn't directly related to the drm.
Oh, I've also flashed my
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 Mon, 2005-03-14 at 01:32 +0100, Jerome Glisse wrote:
Maybe the lockup you experiment is linked with the lockup
Adam gets. Adam have you upgraded you kernel recently ?
Maybe a 2.6.10 or even previous one could fix this. Thus
To clarify:
2.6.11-bk2 OK
2.6.11-bk3 Lockup
Cheers,
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
Andrew Clayton writes:
2.6.11-bk2 OK
2.6.11-bk3 Lockup
Have you tried the most recent kernel? There were some changes to the
AGP code that caused it to oops for me. Linus took my patch to fix
that this last weekend.
Paul.
---
SF email is
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
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2702
--- Additional Comments From [EMAIL PROTECTED] 2005-03-13 21:17 ---
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 (using the accel engine) before
setting the new mode, so that we come out clean of the mode setting
(without ugly artifact),
55 matches
Mail list logo
