Re: [Dri-devel] Radeon scratch register writeback patch
On Mon, 2002-07-15 at 05:21, Jens Owen wrote: Michel Dänzer wrote: On Sun, 2002-07-14 at 15:36, Keith Whitwell wrote: Michel Dänzer wrote: On Fri, 2002-07-12 at 14:56, Keith Whitwell wrote: Looks good, but I think I've got an even better patch: http://www.penguinppc.org/~daenzer/DRI/radeon-nommio.diff I've moved the initialization and put the scratch registers right behind the ring read pointer, this should work with PCI GART and all kinds of AGP GART. I'll commit this now. This looks ok. The one thing I'd say is that we've added functionality to the kernel module, so we should bump the minor version number (ie 1.4.0) -- this means that you can test rmesa-drm.minor (or whatever) instead of firing off the ioctl checking for EINVAL. Bumping the minor strikes me as overkill for this. It's not a new ioctl or something. What about the attached patch? It's a change to the interface -- an extension. It doesn't matter that it's not a new ioctl, this is exactly what bumping the minor number is supposed to do. Bumping the minor number is free - it doesn't cost anything or break anything. One thing that we haven't really made clear is when a 'release' is. However, given that 1.3 is in the 2.5 kernel sources, I'd say wherever the line is, we've crossed it. So - bump the minor don't worry too much. You're the boss. :) Changed and committed. Michel, Please don't think of Keith as being heavy handed. I don't, I was just joking. His suggestion is exactly what we need to do in order to preserve compatability. I understand that. Thanks for working with us on this issue. Thanks for guiding me. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Thursday 11 Jul 2002 9:25 pm, Michel Dänzer scribed numinously: PS: Sorry if you wasted time on this. I worked on it on Monday but haven't gotten around to finish it until now, and I thought you didn't have time to work on it this week. I was mucking around moving things over to the new os-independent stuff anyway, so no more than 10 minutes wasted :-) I'm back to probing at the lockup now that I have my hacking space back. I'll post the WAIT_UNTIL_3D_IDLE version in a minute so there's a fix while I try to understand the true problem more. Heh. My boss is in the country tomorrow. Maybe I can convince him to let me spend time on this at work dreams... -- Tim Smith ([EMAIL PROTECTED]) SMALL ADS: WANTED for treason, arson and insurrection. Reasonable rates. Apply within. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Mon, Jul 15, 2002 at 09:25:18PM +0100, Tim Smith wrote: I'm back to probing at the lockup now that I have my hacking space back. I'll post the WAIT_UNTIL_3D_IDLE version in a minute so there's a fix while I try to understand the true problem more. Heh. My boss is in the Which lockup is this? Which files in CVS should I watch for your commit? I've been scratching at the switch-to-vt-and-back freeze for a few days, but am a bit out of my depth with this source. Thanks for any information, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Monday 15 Jul 2002 9:33 pm, Charl P. Botha scribed numinously: On Mon, Jul 15, 2002 at 09:25:18PM +0100, Tim Smith wrote: I'm back to probing at the lockup now that I have my hacking space back. I'll post the WAIT_UNTIL_3D_IDLE version in a minute so there's a fix while I try to understand the true problem more. Heh. My boss is in the Which lockup is this? Which files in CVS should I watch for your commit? I've been scratching at the switch-to-vt-and-back freeze for a few days, but am a bit out of my depth with this source. I'm almost certain they're unrelated - this is to say, I've not been able to provoke the switch-to-vt-and-back freeze on my system. The file is radeon_state.c; the lockup occurs when waving a 2D window over a very active 3D window, causing the redraw of the 3D window to occur in several smaller clipping rectangles rather than one big one. You need a quick(ish, by todays standards) system (e.g. Athlon 1200) and a heavy 3D app (e.g. the NeverWinter Nights toolset) to make it happen, though I did manage to make glxgears do it once. I'm pretty new at the source myself, so I post (small) patches here rather than apply them directly, so that wiser heads can hopefully stop me before I break anything... -- Tim Smith ([EMAIL PROTECTED]) Daleks are now an endangered species, and it is actually illegal not to let one exterminate you if it wants to. -- Dave's Web of Lies --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
Michel Dänzer wrote: On Fri, 2002-07-12 at 14:56, Keith Whitwell wrote: Looks good, but I think I've got an even better patch: http://www.penguinppc.org/~daenzer/DRI/radeon-nommio.diff I've moved the initialization and put the scratch registers right behind the ring read pointer, this should work with PCI GART and all kinds of AGP GART. I'll commit this now. This looks ok. The one thing I'd say is that we've added functionality to the kernel module, so we should bump the minor version number (ie 1.4.0) -- this means that you can test rmesa-drm.minor (or whatever) instead of firing off the ioctl checking for EINVAL. Bumping the minor strikes me as overkill for this. It's not a new ioctl or something. What about the attached patch? It's a change to the interface -- an extension. It doesn't matter that it's not a new ioctl, this is exactly what bumping the minor number is supposed to do. Bumping the minor number is free - it doesn't cost anything or break anything. One thing that we haven't really made clear is when a 'release' is. However, given that 1.3 is in the 2.5 kernel sources, I'd say wherever the line is, we've crossed it. So - bump the minor don't worry too much. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Sun, 2002-07-14 at 15:36, Keith Whitwell wrote: Michel Dänzer wrote: On Fri, 2002-07-12 at 14:56, Keith Whitwell wrote: Looks good, but I think I've got an even better patch: http://www.penguinppc.org/~daenzer/DRI/radeon-nommio.diff I've moved the initialization and put the scratch registers right behind the ring read pointer, this should work with PCI GART and all kinds of AGP GART. I'll commit this now. This looks ok. The one thing I'd say is that we've added functionality to the kernel module, so we should bump the minor version number (ie 1.4.0) -- this means that you can test rmesa-drm.minor (or whatever) instead of firing off the ioctl checking for EINVAL. Bumping the minor strikes me as overkill for this. It's not a new ioctl or something. What about the attached patch? It's a change to the interface -- an extension. It doesn't matter that it's not a new ioctl, this is exactly what bumping the minor number is supposed to do. Bumping the minor number is free - it doesn't cost anything or break anything. One thing that we haven't really made clear is when a 'release' is. However, given that 1.3 is in the 2.5 kernel sources, I'd say wherever the line is, we've crossed it. So - bump the minor don't worry too much. You're the boss. :) Changed and committed. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
Michel Dänzer wrote: On Sun, 2002-07-14 at 15:36, Keith Whitwell wrote: Michel Dänzer wrote: On Fri, 2002-07-12 at 14:56, Keith Whitwell wrote: Looks good, but I think I've got an even better patch: http://www.penguinppc.org/~daenzer/DRI/radeon-nommio.diff I've moved the initialization and put the scratch registers right behind the ring read pointer, this should work with PCI GART and all kinds of AGP GART. I'll commit this now. This looks ok. The one thing I'd say is that we've added functionality to the kernel module, so we should bump the minor version number (ie 1.4.0) -- this means that you can test rmesa-drm.minor (or whatever) instead of firing off the ioctl checking for EINVAL. Bumping the minor strikes me as overkill for this. It's not a new ioctl or something. What about the attached patch? It's a change to the interface -- an extension. It doesn't matter that it's not a new ioctl, this is exactly what bumping the minor number is supposed to do. Bumping the minor number is free - it doesn't cost anything or break anything. One thing that we haven't really made clear is when a 'release' is. However, given that 1.3 is in the 2.5 kernel sources, I'd say wherever the line is, we've crossed it. So - bump the minor don't worry too much. You're the boss. :) Changed and committed. Michel, Please don't think of Keith as being heavy handed. His suggestion is exactly what we need to do in order to preserve compatability. Thanks for working with us on this issue. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Fri, 2002-07-12 at 14:56, Keith Whitwell wrote:
Looks good, but I think I've got an even better patch:
http://www.penguinppc.org/~daenzer/DRI/radeon-nommio.diff
I've moved the initialization and put the scratch registers right behind
the ring read pointer, this should work with PCI GART and all kinds of
AGP GART. I'll commit this now.
This looks ok. The one thing I'd say is that we've added functionality to the
kernel module, so we should bump the minor version number (ie 1.4.0) -- this
means that you can test rmesa-drm.minor (or whatever) instead of firing off
the ioctl checking for EINVAL.
Bumping the minor strikes me as overkill for this. It's not a new ioctl
or something. What about the attached patch?
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Index: lib/GL/mesa/src/drv/radeon/radeon_ioctl.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c,v
retrieving revision 1.19
diff -p -u -r1.19 radeon_ioctl.c
--- lib/GL/mesa/src/drv/radeon/radeon_ioctl.c 11 Jul 2002 20:31:10 - 1.19
+++ lib/GL/mesa/src/drv/radeon/radeon_ioctl.c 13 Jul 2002 16:30:17 -
-614,13 +614,20 static int radeonWaitForFrameCompletion(
int i;
while ( 1 ) {
- drmRadeonGetParam gp;
int ret;
+ int minor = rmesa-dri.screen-drmMinor;
+ int patchlevel = rmesa-dri.screen-drmPatch;
+
+ if (minor 3 || (minor == 3 patchlevel = 2) ) {
+ drmRadeonGetParam gp;
+
+ gp.param = RADEON_PARAM_LAST_FRAME;
+ gp.value = (int *)frame;
+ ret = drmCommandWriteRead( rmesa-dri.fd,
+ DRM_RADEON_GETPARAM, gp, sizeof(gp) );
+ } else
+ ret = -EINVAL;
- gp.param = RADEON_PARAM_LAST_FRAME;
- gp.value = (int *)frame;
- ret = drmCommandWriteRead( rmesa-dri.fd,
- DRM_RADEON_GETPARAM, gp, sizeof(gp) );
if ( ret == -EINVAL ) {
frame = INREG( RADEON_LAST_FRAME_REG );
} else if ( ret ) {
-824,13 +842,20 static void radeonClear( GLcontext *ctx,
/* Throttle the number of clear ioctls we do.
*/
while ( 1 ) {
- drmRadeonGetParam gp;
int ret;
+ int minor = rmesa-dri.screen-drmMinor;
+ int patchlevel = rmesa-dri.screen-drmPatch;
+
+ if (minor 3 || (minor == 3 patchlevel = 2) ) {
+ drmRadeonGetParam gp;
+
+ gp.param = RADEON_PARAM_LAST_CLEAR;
+ gp.value = (int *)clear;
+ ret = drmCommandWriteRead( rmesa-dri.fd,
+ DRM_RADEON_GETPARAM, gp, sizeof(gp) );
+ } else
+ ret = -EINVAL;
- gp.param = RADEON_PARAM_LAST_CLEAR;
- gp.value = (int *)clear;
- ret = drmCommandWriteRead( rmesa-dri.fd,
- DRM_RADEON_GETPARAM, gp, sizeof(gp) );
if ( ret == -EINVAL ) {
clear = INREG( RADEON_LAST_CLEAR_REG );
} else if ( ret ) {
Index: programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon.h
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon.h,v
retrieving revision 1.2
diff -p -u -r1.2 radeon.h
--- programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon.h 5 Jul 2002 08:31:11 - 1.2
+++ programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon.h 13 Jul 2002 16:30:17 -
-47,11 +47,11
#define DRIVER_NAME radeon
#define DRIVER_DESC ATI Radeon
-#define DRIVER_DATE 20020611
+#define DRIVER_DATE 20020713
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 3
-#define DRIVER_PATCHLEVEL 1
+#define DRIVER_PATCHLEVEL 2
/* Interface history:
*
Re: [Dri-devel] Radeon scratch register writeback patch
Looks good, but I think I've got an even better patch: http://www.penguinppc.org/~daenzer/DRI/radeon-nommio.diff I've moved the initialization and put the scratch registers right behind the ring read pointer, this should work with PCI GART and all kinds of AGP GART. I'll commit this now. This looks ok. The one thing I'd say is that we've added functionality to the kernel module, so we should bump the minor version number (ie 1.4.0) -- this means that you can test rmesa-drm.minor (or whatever) instead of firing off the ioctl checking for EINVAL. Keith --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Thu, 2002-07-11 at 19:04, Tim Smith wrote: On Tuesday 09 Jul 2002 12:11 am, Michel Dänzer scribed numinously: On Mon, 2002-07-08 at 20:17, Tim Smith wrote: On Monday 08 Jul 2002 12:49 am, Michel Dänzer scribed numinously: The scratch register values need to be read with DRM_READ32(), which accounts both for endianness and memory barriers. So it would be u32 done_age = DRM_READ32(dev_priv-scratch[1]); That's good to know; I'll file that a little closer to my forebrain. I'd noticed the macros before but not taken enough notice. I thought the card took care of that when it wrote the value back (I believe it can) but maybe not. It can, but that would mean extra code to set the control registers according to endianness and wouldn't really buy us anything as reading little endian data is free with a decent big endian CPU and the memory barriers would still have to be dealt with. Yes that makes sense. Like I said, I wasn't paying enough attention :-/ Still I live and learn; or at least live :-) Here's a newer patch, against the latest CVS, that incorporates that change and also falls back to MMIO if the ioctl fails. If this is OK (no other mucking around required to make it work on the mac c) then I'll commit it. Looks good, but I think I've got an even better patch: http://www.penguinppc.org/~daenzer/DRI/radeon-nommio.diff I've moved the initialization and put the scratch registers right behind the ring read pointer, this should work with PCI GART and all kinds of AGP GART. I'll commit this now. PS: Sorry if you wasted time on this. I worked on it on Monday but haven't gotten around to finish it until now, and I thought you didn't have time to work on it this week. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
The scratch register values need to be read with DRM_READ32(), which accounts both for endianness and memory barriers. So it would be u32 done_age = DRM_READ32(dev_priv-scratch[1]); etc. Nice work! I think it's probably worthwhile to commit this now. Michel, if you have a version that's endian-aware, can you do the honors, with credit to Tim? Keith --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
Michel Dänzer wrote: On Mon, 2002-07-08 at 13:07, Keith Whitwell wrote: The scratch register values need to be read with DRM_READ32(), which accounts both for endianness and memory barriers. So it would be u32 done_age = DRM_READ32(dev_priv-scratch[1]); etc. Nice work! I think it's probably worthwhile to commit this now. Michel, if you have a version that's endian-aware, can you do the honors, with credit to Tim? PCI GART probably also needs special treatment, I was going to look into that. Also, it's not backwards compatible right now, should we just fall back to reading the register directly if the ioctl fails? Hmm. Probably. Keith --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Mon, 2002-07-08 at 20:17, Tim Smith wrote: On Monday 08 Jul 2002 12:49 am, Michel Dänzer scribed numinously: The scratch register values need to be read with DRM_READ32(), which accounts both for endianness and memory barriers. So it would be u32 done_age = DRM_READ32(dev_priv-scratch[1]); That's good to know; I'll file that a little closer to my forebrain. I'd noticed the macros before but not taken enough notice. I thought the card took care of that when it wrote the value back (I believe it can) but maybe not. It can, but that would mean extra code to set the control registers according to endianness and wouldn't really buy us anything as reading little endian data is free with a decent big endian CPU and the memory barriers would still have to be dealt with. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Mon, 2002-07-08 at 20:17, Tim Smith wrote: On Monday 08 Jul 2002 12:49 am, Michel Dänzer scribed numinously: The scratch register values need to be read with DRM_READ32(), which accounts both for endianness and memory barriers. So it would be u32 done_age = DRM_READ32(dev_priv-scratch[1]); That's good to know; I'll file that a little closer to my forebrain. I'd noticed the macros before but not taken enough notice. I thought the card took care of that when it wrote the value back (I believe it can) but maybe not. It can, but that would mean extra code to set the control registers according to endianness and wouldn't really buy us anything as reading little endian data is free with a decent big endian CPU and the memory barriers would still have to be dealt with. That surprises me, WHY would you go throught all the trouble of making avalibul a control register that changes byte ordering? Is the GPU big endian, and thay are just letting you turn off there endianness schem? I don't know mutch about modern technology but I allways thought that in the olden days endianness was an optimisation, like the way singed intergers are handeled. Could tweaking this have any effect, even /w little endian CPUs or do any thing? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Tue, 2002-07-02 at 00:32, Tim Smith wrote:
Here it is. It'll need cleaning up if it works, but it'll do as a test.
Took me quite some fiddling to get it working here, but that's mostly
due to the non-standard and not-quite-finished agpgart implementation
for Macs. Nothing to worry about, works great now (just played a couple
minutes of bzflag with it :).
Comments:
+ fprintf( stderr, %s( %d )\n, __FUNCTION__, clear );
s/clear/frame/ - typo, I presume.
@@ -1189,7 +1188,11 @@ drm_buf_t *radeon_freelist_get( drm_devi
start = dev_priv-last_buf;
for ( t = 0 ; t dev_priv-usec_timeout ; t++ ) {
+ /* Testing scratch register writeback
u32 done_age = RADEON_READ( RADEON_LAST_DISPATCH_REG );
+ */
+ u32 done_age = dev_priv-scratch[1];
+ DRM_DEBUG(done_age = %d\n,done_age);
for ( i = start ; i dma-buf_count ; i++ ) {
buf = dma-buflist[i];
buf_priv = buf-dev_private;
[...]
Index: xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_state.c
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_state.c,v
retrieving revision 1.17
diff -u -3 -p -r1.17 radeon_state.c
--- xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_state.c 27 Jun
2002 17:56:39 - 1.17
+++ xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_state.c 1 Jul
2002 21:36:58 -
@@ -1878,6 +1878,15 @@ int radeon_cp_getparam( struct inode *in
case RADEON_PARAM_AGP_BUFFER_OFFSET:
value = dev_priv-agp_buffers_offset;
break;
+ case RADEON_PARAM_LAST_FRAME:
+ value = dev_priv-scratch[0];
+ break;
+ case RADEON_PARAM_LAST_DISPATCH:
+ value = dev_priv-scratch[1];
+ break;
+ case RADEON_PARAM_LAST_CLEAR:
+ value = dev_priv-scratch[2];
+ break;
default:
return -EINVAL;
}
The scratch register values need to be read with DRM_READ32(), which
accounts both for endianness and memory barriers. So it would be
u32 done_age = DRM_READ32(dev_priv-scratch[1]);
etc.
Nice work!
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
---
This sf.net email is sponsored by:ThinkGeek
We have stuff for geeks like you.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Thu, 4 Jul 2002 02:00:32 -0400 Zilvinas Valinskas [EMAIL PROTECTED] wrote: On Wed, Jul 03, 2002 at 08:50:22AM +0100, Ian Molton wrote: the QD is a 7200? I was ripped off! I was told it was a 7500! back then when I bought my card there were no such things as 7x00 enumerations I think that is must be 7200 ... :) Keith can confirm or deny that ... as he has specs. for sure :) having done a quick google, I /think/ the QD has a TCL unit. but is it a 7500 chip? --- This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Wednesday 03 Jul 2002 5:03 am, David Willmore scribed numinously: On Tue, Jul 02, 2002 at 10:48:29PM +0100, Tim Smith wrote: Great. So we're OK on Radeon 7500 Radeon 7200 anyone got a Radeon 7000 or old Radeon no-number to try it on? 7200 is the old Radeon no-number AFAIK ;) This brings up something that I've been meaning to ask. Is there a mapping between card number, features, and chipset revision? I have an ATI branded board, 64 MB SDR, chipset name 'QD'. Anyone know what I have? 7000, 7200, 7500? I think the generic Radeon driver for windows called it a 7200 last time I looked, but I don't trust that as it doesn't even read the monitor resolution settings right. Dunno. I was going by ATI's web site, which lists the Radeon 7500, Radeon 7200, Radeon 7000 aka Radeon VE, and plain old Radeon (inc Radeon VIVO) under separate headings. That could just be the marketing department of course... -- Tim Smith ([EMAIL PROTECTED]) 75% of wookies over the age of three hundred wear hairpieces. --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Tue, 2002-07-02 at 17:48, Tim Smith wrote: On Tuesday 02 Jul 2002 12:27 am, Vedran Rodic scribed numinously: On Mon, Jul 01, 2002 at 11:32:04PM +0100, Tim Smith wrote: Here it is. It'll need cleaning up if it works, but it'll do as a test. Thanks Tim Works fine here on my old Radeon 7200 32MB SDR. Great. So we're OK on Radeon 7500 Radeon 7200 anyone got a Radeon 7000 or old Radeon no-number to try it on? I have both of these: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY 02:00.0 VGA compatible controller: ATI Technologies Inc Radeon VE QY The VE is the exact same as the 7000. I might need to locate a machine with a supported agp gart, though... I'll test it sometime this week (probably tomorrow). -Al Tobey -- Tim Smith ([EMAIL PROTECTED]) If I slay everone, I am bound to get the ones I am mad at! -- Groo the Wanderer --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the Priority Health Information Services Department at (616) 942-0954. --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Wed, Jul 03, 2002 at 08:50:22AM +0100, Ian Molton wrote: the QD is a 7200? I was ripped off! I was told it was a 7500! back then when I bought my card there were no such things as 7x00 enumerations I think that is must be 7200 ... :) Keith can confirm or deny that ... as he has specs. for sure :) -- Zilvinas Valinskas --- This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Tuesday 02 Jul 2002 12:27 am, Vedran Rodic scribed numinously: On Mon, Jul 01, 2002 at 11:32:04PM +0100, Tim Smith wrote: Here it is. It'll need cleaning up if it works, but it'll do as a test. Thanks Tim Works fine here on my old Radeon 7200 32MB SDR. Great. So we're OK on Radeon 7500 Radeon 7200 anyone got a Radeon 7000 or old Radeon no-number to try it on? -- Tim Smith ([EMAIL PROTECTED]) If I slay everone, I am bound to get the ones I am mad at! -- Groo the Wanderer --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Tue, Jul 02, 2002 at 10:48:29PM +0100, Tim Smith wrote: Great. So we're OK on Radeon 7500 Radeon 7200 anyone got a Radeon 7000 or old Radeon no-number to try it on? 7200 is the old Radeon no-number AFAIK ;) --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Tue, Jul 02, 2002 at 10:48:29PM +0100, Tim Smith wrote: Great. So we're OK on Radeon 7500 Radeon 7200 anyone got a Radeon 7000 or old Radeon no-number to try it on? 7200 is the old Radeon no-number AFAIK ;) This brings up something that I've been meaning to ask. Is there a mapping between card number, features, and chipset revision? I have an ATI branded board, 64 MB SDR, chipset name 'QD'. Anyone know what I have? 7000, 7200, 7500? I think the generic Radeon driver for windows called it a 7200 last time I looked, but I don't trust that as it doesn't even read the monitor resolution settings right. Cheers, David --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Tue, Jul 02, 2002 at 11:03:15PM -0500, David Willmore wrote: I have an ATI branded board, 64 MB SDR, chipset name 'QD'. Anyone I think it must be 7200 (I have the same QD chipset - but the card is ATI radeon VIVO 64MB DDR) ... know what I have? 7000, 7200, 7500? I think the generic Radeon driver for windows called it a 7200 last time I looked, but I don't trust that as it doesn't even read the monitor resolution settings right. Cheers, David -- Zilvinas Valinskas --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon scratch register writeback patch
Here it is. It'll need cleaning up if it works, but it'll do as a test.
--
Tim Smith ([EMAIL PROTECTED])
A fray
-- Groo the Wanderer
Index: xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c,v
retrieving revision 1.16
diff -u -3 -p -r1.16 radeon_ioctl.c
--- xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c 18 Jun 2002 22:40:26 - 1.16
+++ xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c 1 Jul 2002 21:36:54 -
@@ -614,7 +614,22 @@ static int radeonWaitForFrameCompletion(
int i;
while ( 1 ) {
- frame = INREG( RADEON_LAST_FRAME_REG );
+ /* frame = INREG( RADEON_LAST_FRAME_REG ); */
+ drmRadeonGetParam gp;
+ int ret;
+
+ gp.param = RADEON_PARAM_LAST_FRAME;
+ gp.value = frame;
+ ret = drmCommandWriteRead( rmesa-dri.fd,
+ DRM_RADEON_GETPARAM,gp, sizeof(gp));
+ if (ret) {
+ fprintf(stderr, drmRadeonGetParam: %d\n, ret);
+ exit(1);
+ }
+ if ( RADEON_DEBUG DEBUG_IOCTL ) {
+ fprintf( stderr, %s( %d )\n, __FUNCTION__, clear );
+ }
+
if ( sarea-last_frame - frame = RADEON_MAX_OUTSTANDING ) {
break;
}
@@ -803,12 +818,28 @@ static void radeonClear( GLcontext *ctx,
/* Throttle the number of clear ioctls we do.
*/
while ( 1 ) {
- clear = INREG( RADEON_LAST_CLEAR_REG );
+ /* clear = INREG( RADEON_LAST_CLEAR_REG ); */
+ drmRadeonGetParam gp;
+ int ret;
+
+ gp.param = RADEON_PARAM_LAST_CLEAR;
+ gp.value = clear;
+ ret = drmCommandWriteRead( rmesa-dri.fd,
+ DRM_RADEON_GETPARAM,gp, sizeof(gp));
+ if (ret) {
+ fprintf(stderr, drmRadeonGetParam: %d\n, ret);
+ exit(1);
+ }
+ if ( RADEON_DEBUG DEBUG_IOCTL ) {
+ fprintf( stderr, %s( %d )\n, __FUNCTION__, clear );
+ }
+
if ( sarea-last_clear - clear = RADEON_MAX_CLEARS ) {
break;
}
/* Spin in place a bit so we aren't hammering the bus */
for ( i = 0 ; i 1024 ; i++ ) {
+ delay();
}
}
Index: xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h,v
retrieving revision 1.3
diff -u -3 -p -r1.3 radeon_common.h
--- xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h 12 Jun 2002 15:50:27 - 1.3
+++ xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h 1 Jul 2002 21:36:55 -
@@ -336,5 +336,8 @@ typedef struct drm_radeon_getparam {
} drmRadeonGetParam;
#define RADEON_PARAM_AGP_BUFFER_OFFSET 0x1
+#define RADEON_PARAM_LAST_FRAME 0x2
+#define RADEON_PARAM_LAST_DISPATCH 0x3
+#define RADEON_PARAM_LAST_CLEAR 0x4
#endif
Index: xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_cp.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_cp.c,v
retrieving revision 1.23
diff -u -3 -p -r1.23 radeon_cp.c
--- xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_cp.c 12 Jun 2002 15:50:28 - 1.23
+++ xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_cp.c 1 Jul 2002 21:36:57 -
@@ -905,17 +905,16 @@ static int radeon_do_init_cp( drm_device
dev_priv-ring.high_mark = RADEON_RING_HIGH_MARK;
-#if 0
/* Initialize the scratch register pointer. This will cause
* the scratch register values to be written out to memory
* whenever they are updated.
* FIXME: This doesn't quite work yet, so we're disabling it
* for the release.
+ * TCS 2002-07-01 enabled again for testing
*/
RADEON_WRITE( RADEON_SCRATCH_ADDR, (dev_priv-ring_rptr-offset +
RADEON_SCRATCH_REG_OFFSET) );
RADEON_WRITE( RADEON_SCRATCH_UMSK, 0x7 );
-#endif
dev_priv-scratch = ((__volatile__ u32 *)
dev_priv-ring_rptr-handle +
@@ -1189,7 +1188,11 @@ drm_buf_t *radeon_freelist_get( drm_devi
start = dev_priv-last_buf;
for ( t = 0 ; t dev_priv-usec_timeout ; t++ ) {
+ /* Testing scratch register writeback
u32 done_age = RADEON_READ( RADEON_LAST_DISPATCH_REG );
+ */
+ u32 done_age = dev_priv-scratch[1];
+ DRM_DEBUG(done_age = %d\n,done_age);
for ( i = start ; i dma-buf_count ; i++ ) {
buf = dma-buflist[i];
buf_priv = buf-dev_private;
Index: xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_drm.h
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_drm.h,v
retrieving revision 1.11
diff -u -3 -p -r1.11 radeon_drm.h
--- xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_drm.h 12 Jun 2002 15:50:28 - 1.11
+++ xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_drm.h 1 Jul 2002 21:36:57 -
@@ -458,6 +458,9 @@ typedef struct drm_radeon_indirect {
*
