Re: [R300] on lockups

2005-06-05 Thread Vladimir Dergachev
On Sat, 4 Jun 2005, Nicolai Haehnle wrote: The mirroring works as follows: each time scratch register is written the radeon controller uses PCI to write their value to a specific location in system memory. Are you sure it uses PCI? I'm assuming that the destination address for scratch

Re: [R300] on lockups

2005-06-05 Thread Vladimir Dergachev
Which way can memory controller be misprogrammed ? The part that concerns us are positions of Video RAM, AGP and System Ram in Radeon address space. (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION). The memory controller *always* assumes that system RAM (accessible via

Re: [R300] on lockups

2005-06-05 Thread Philipp Klaus Krause
Vladimir Dergachev schrieb: My understanding is that AGP only does transfers system RAM - video RAM and all transfers in the opposite direction have to use plain PCI transfers at least as far as the bus is concerned. AGP can do both. Every AGP compliant device has to support the System RAM

[Bug 2365] ATI IGP9100 with dri enabled in blender corrupts screen

2005-06-05 Thread bugzilla-daemon
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=2365 --- Additional Comments From [EMAIL PROTECTED] 2005-06-05 07:27 --- any

Re: [R300] on lockups

2005-06-05 Thread Vladimir Dergachev
On Sun, 5 Jun 2005, Jerome Glisse wrote: Note that old driver was able to test whether mirroring works, so it would correspond to behaviour of RV350 cards. It could be that R300 cards are more touchy in this regard. Might be worth trying to fallback to non-mirrored setup and see if that

[r200] 'texwrap' sigfaults during pressing 'b'

2005-06-05 Thread Dieter Nützel
progs/tests ./texwrap Texture Border Size = 1 Speicherschutzverletzung (core dumped) progs/tests l core -rw---1 nuetzel users 6156288 2005-06-05 17:59 core Loaded symbols for /usr/lib/libtxc_dxtn.so Reading symbols from /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2...done. Loaded

[r200] quake3-smp hangs in futex (current Mesa DRI not SMP ready?)

2005-06-05 Thread Dieter Nützel
games/quake3 ltrace ./quake3-smp.x86 . . . memcpy(0x08938ad6, GL_SUN_slice_accum, 18) = 0x08938ad6 memcpy(0x0892d1b8, GL_ARB_depth_texture GL_ARB_draw..., 3026) = 0x0892d1b8 free(0x08937f18) = void pthread_mutex_unlock(0x44b9dce4, 129, 0xbfffe2d4, 0xbfffe2d8,

Re: [R300] on lockups

2005-06-05 Thread Nicolai Haehnle
On Sunday 05 June 2005 15:55, Vladimir Dergachev wrote: On Sat, 4 Jun 2005, Nicolai Haehnle wrote: The mirroring works as follows: each time scratch register is written the radeon controller uses PCI to write their value to a specific location in system memory. Are you sure it

Re: [R300] on lockups

2005-06-05 Thread Vladimir Dergachev
This register is programmed to a value that falls within the AGP area (as defined by RADEON_MC_AGP_LOCATION) if I understand the code correctly. My understanding is that AGP only does transfers system RAM - video RAM and all transfers in the opposite direction have to use plain PCI transfers

Re: [R300] on lockups

2005-06-05 Thread Nicolai Haehnle
On Sunday 05 June 2005 20:07, Vladimir Dergachev wrote: My understanding is that dev-agp-base is the address where the AGP GART mirrors the pieces of system RAM comprising AGP space. Yes, that's my understanding, too. But what is the Radeon's business knowing that address? Why does it

Re: [R300] on lockups

2005-06-05 Thread Vladimir Dergachev
Yes, however it is convenient to do so. The point is that AGP base address will not normally overlap the location of system RAM. This is, of course, only reasonable for 32 bit systems.. I understand that part, but it's not what I meant. What I mean is this: You said, RADEON_MC_AGP_LOCATION is

[Bug 2241] implement GL_ARB_texture_cube_map in radeon driver

2005-06-05 Thread bugzilla-daemon
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=2241 [EMAIL PROTECTED] changed: What|Removed |Added

Re: [r200] 'texwrap' sigfaults during pressing 'b'

2005-06-05 Thread Roland Scheidegger
Dieter Ntzel wrote: progs/tests ./texwrap Texture Border Size = 1 Speicherschutzverletzung (core dumped) This is still #2516 (rasterization fallbacks cause segfaults), though the backtrace output has slightly changed due to changes to the t_vertex code. Roland

Re: [R300] on lockups

2005-06-05 Thread Benjamin Herrenschmidt
On Sun, 2005-06-05 at 09:58 -0400, Vladimir Dergachev wrote: Which way can memory controller be misprogrammed ? The part that concerns us are positions of Video RAM, AGP and System Ram in Radeon address space. (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION).

Re: [R300] on lockups

2005-06-05 Thread Benjamin Herrenschmidt
My understanding is that AGP only does transfers system RAM - video RAM and all transfers in the opposite direction have to use plain PCI transfers at least as far as the bus is concerned. You mean system RAM - graphics card, right? Does this mean that the graphics card cannot always

Re: [R300] on lockups

2005-06-05 Thread Benjamin Herrenschmidt
Yes, however it is convenient to do so. The point is that AGP base address will not normally overlap the location of system RAM. This is, of course, only reasonable for 32 bit systems.. It will overlap it on all PowerMac's (where it will be 0) Ben.

Re: [R300] on lockups

2005-06-05 Thread Benjamin Herrenschmidt
On Sun, 2005-06-05 at 14:45 -0400, Vladimir Dergachev wrote: Yes, however it is convenient to do so. The point is that AGP base address will not normally overlap the location of system RAM. This is, of course, only reasonable for 32 bit systems.. I understand that part, but it's not

[Bug 4714] New: OpenGL applications and some X-windows functions cause machine to be unresponsive.

2005-06-05 Thread bugme-daemon
http://bugzilla.kernel.org/show_bug.cgi?id=4714 Summary: OpenGL applications and some X-windows functions cause machine to be unresponsive. Kernel Version: 2.6.11 -- 2.6.12-rc5 Status: NEW Severity: normal Owner: [EMAIL