Philip Brown wrote:
I'm reading through http://dri.sourceforge.net/doc/drm_low_level.html
int drmDMA(int fd, drmDMAReqPtr request)
drmDMA can be used to reserve DMA buffers and to dispatch previously
reserved DMA
Philip Brown wrote:
http://dri.sourceforge.net/doc/drm_low_level.html
should be updated with a functional description of
drmScatterGatherAlloc()
[and probably a few other drmXXXYYY() routines that have appeared
since 1999 ;-) ]
Patches welcome... :-)
Keith
On Tue, 11 Mar 2003, Dave Jones wrote:
On x86_64 (probably any 64bit arch also, but I haven't tested
ia64 or alpha yet), tuxracer experiences texture corruption on
ice patches and the sides of some hills. This is occurs on the
very first race, so it's not hard to reproduce. AS you're
On Wed, Mar 12, 2003 at 08:39:31AM +, Keith Whitwell wrote:
Philip Brown wrote:
http://dri.sourceforge.net/doc/drm_low_level.html
should be updated with a functional description of
drmScatterGatherAlloc()
Patches welcome... :-)
love to.. if I understood it... which would be
Keith Whitwell wrote:
Keith Whitwell wrote:
Linus Torvalds wrote:
On Sun, 2 Mar 2003, Linus Torvalds wrote:
The _second_ DRI-enabled X startup caused problems, even if I had done
multiple non-DRI X sessions in between. This is what makes me think
that
the DRI kernel modules keep some history
On Mit, 2003-03-12 at 10:55, Keith Whitwell wrote:
In fact the lockup comes down to this one line:
--- radeon_driver.c 28 Oct 2002 02:21:14 - 1.44
+++ radeon_driver.c 29 Oct 2002 13:49:25 - 1.45
@@ -4639,6 +4639,7 @@
save-cap0_trig_cntl = 0;
On Mit, 2003-03-12 at 12:29, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mit, 2003-03-12 at 11:51, Keith Whitwell wrote:
In fact the lockup comes down to this one line:
--- radeon_driver.c28 Oct 2002 02:21:14 -1.44
+++ radeon_driver.c29 Oct 2002 13:49:25 -
OK, now that the recycle lockup has been found fixed, I don't see any
problems with this patch. Has anyone got any objections to merging it to the
trunk?
Eric, do you think this will be impossible to support on bsd? It seems to fix
some fundamental braino's in the orignal drm...
Keith
Am Dienstag, 11. März 2003 11:06 schrieb Keith Whitwell:
Charl P. Botha wrote:
On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote:
Charl P. Botha wrote:
In anycase, if you have wxPython and VTK with working Python wrappings
installed, please run the attached example. Manipulate the 3D cone
Am Dienstag, 11. März 2003 18:29 schrieb Michel Dänzer:
RADEON_NO_VTXFMT=1
NO, not for me.
VTK/bin ./TaskParallelism
Speicherschutzverletzung (core dumped)
DRI CVS taken on 10.03.2003.
-Dieter
---
This SF.net email is sponsored by:Crypto
On Wed, Mar 12, 2003 at 01:57:03PM +, Keith Whitwell wrote:
OK, now that the recycle lockup has been found fixed, I don't see any
problems with this patch. Has anyone got any objections to merging it to
the trunk?
FW(L)IW, you have my vote. As mentioned earlier, your filp work fixes
Keith Whitwell [EMAIL PROTECTED] wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/
Changes by: [EMAIL PROTECTED] 03/03/12 05:54:45
Log message:
Fix recycle lockup (Michel Danzer)
Modified files:
I just noticed that in drivers/ati, every single function related to DRI
initialization,etc. is named RADEONDRIXxxxYyyy ... except
RADEONPreInitDRI()
Here's a patch to fix that, and R128PreInitDRI()
I had to make the patch by hand this time, since cvs seems down or
something.
---
Philip Brown wrote:
http://dri.sourceforge.net/doc/drm_low_level.html
should be updated with a functional description of
drmScatterGatherAlloc()
[and probably a few other drmXXXYYY() routines that have appeared
since 1999 ;-) ]
I'm talking from my hat a bit here, but how hard would it be to mark
Am Mittwoch, 12. März 2003 16:42 schrieb Dieter Nützel:
Am Dienstag, 11. März 2003 11:06 schrieb Keith Whitwell:
Charl P. Botha wrote:
On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote:
Charl P. Botha wrote:
In anycase, if you have wxPython and VTK with working Python wrappings
Hello!
Seems this is right list/person to post this.
I am looking at ./drivers/char/drm/drm_drv.h::drm_init() (latest 2.4), and
it seems there is a memleak on error exit path.
If DRM(stub_register)(DRIVER_NAME, DRM(fops),dev) fails,
DRM(device) and DRM(minor) memory areas are not
On Wed, Mar 12, 2003 at 11:34:08PM +0300, Oleg Drokin wrote:
Hello!
Seems this is right list/person to post this.
I am looking at ./drivers/char/drm/drm_drv.h::drm_init() (latest 2.4), and
it seems there is a memleak on error exit path.
If DRM(stub_register)(DRIVER_NAME,
On Mit, 2003-03-12 at 19:15, Philip Brown wrote:
I just noticed that in drivers/ati, every single function related to DRI
initialization,etc. is named RADEONDRIXxxxYyyy ... except
RADEONPreInitDRI()
Here's a patch to fix that, and R128PreInitDRI()
This change doesn't seem obvious to me; the
On Wed, Mar 12, 2003 at 10:21:17PM +0100, Michel Dänzer wrote:
On Mit, 2003-03-12 at 19:15, Philip Brown wrote:
I just noticed that in drivers/ati, every single function related to DRI
initialization,etc. is named RADEONDRIXxxxYyyy ... except
RADEONPreInitDRI()
Here's a patch to fix
Philip Brown wrote:
On Wed, Mar 12, 2003 at 10:21:17PM +0100, Michel Dänzer wrote:
This change doesn't seem obvious to me; the RADEONDRIxxx() functions are
in radeon_dri.c and directly related to the DRI, whereas
RADEONPreInitDRI() (along with other RADEONPreInitxxx() functions) is in
On Mit, 2003-03-12 at 23:14, Philip Brown wrote:
On Wed, Mar 12, 2003 at 10:21:17PM +0100, Michel Dänzer wrote:
On Mit, 2003-03-12 at 19:15, Philip Brown wrote:
I just noticed that in drivers/ati, every single function related to DRI
initialization,etc. is named RADEONDRIXxxxYyyy ...
Philip Brown wrote:
On Wed, Mar 12, 2003 at 10:21:17PM +0100, Michel Dänzer wrote:
On Mit, 2003-03-12 at 19:15, Philip Brown wrote:
I just noticed that in drivers/ati, every single function related to DRI
initialization,etc. is named RADEONDRIXxxxYyyy ... except
RADEONPreInitDRI()
Here's a patch
Jens Owen wrote:
Philip Brown wrote:
On Wed, Mar 12, 2003 at 10:21:17PM +0100, Michel Dänzer wrote:
On Mit, 2003-03-12 at 19:15, Philip Brown wrote:
I just noticed that in drivers/ati, every single function related to
DRI
initialization,etc. is named RADEONDRIXxxxYyyy ... except
On Wed, 12 Mar 2003, Philip Brown wrote:
I just noticed that in drivers/ati, every single function related to DRI
initialization,etc. is named RADEONDRIXxxxYyyy ... except
RADEONPreInitDRI()
Here's a patch to fix that, and R128PreInitDRI()
This change doesn't seem obvious to me; the
On Wed, Mar 12, 2003 at 06:26:44PM -0500, Mike A. Harris wrote:
[]
IMHO, the names of functions and the file they are located in
should be based on the functionality that they are providing, and
should be grouped based on similar functionality and not based on
similarities in portions
On Wed, 12 Mar 2003, Philip Brown wrote:
[]
IMHO, the names of functions and the file they are located in
should be based on the functionality that they are providing, and
should be grouped based on similar functionality and not based on
similarities in portions of their names.
I
Mike A. Harris wrote:
On Wed, 12 Mar 2003, Philip Brown wrote:
[]
IMHO, the names of functions and the file they are located in
should be based on the functionality that they are providing, and
should be grouped based on similar functionality and not based on
similarities in portions of
On Wed, Mar 12, 2003 at 11:56:42PM +, Keith Whitwell wrote:
Well, I didn't have much to do with this code when it was written, but I'm
happy for it to stay where it is and as it is named for now.
If someone wanted to take on a bigger task of comprehensively spring-cleaning
the radeon
On Tue, 11 Mar 2003 18:34:16 -0700
Brian Paul [EMAIL PROTECTED] wrote:
Smitty wrote:
Hi Brian
In light of your well maintained:
http://dri.sourceforge.net/doc/dri_driver_features.phtml
I think it's about time that:
http://dri.sourceforge.net/doc/dri_radeon_features.html
The DRI website contains a few other inaccuracies about ATI's
Radeon video hardware. Nothing mission critical, but it is
incorrect:
http://dri.sourceforge.net/doc/radeon_naming.html
Radeon VE a.k.a Radeon 7000, is not R100, it is RV100.
So what does this mean for users of DRI?
PS: Editing files like this makes me kind of nervous, we should really
work out a way to handle the website in CVS.
What's the difficulty in having it in CVS? it's extremely trivial to set
up, you just tell the web server to cvs up from the repository every few
hours or so.
The website
On Wed, 2003-03-12 at 05:57, Keith Whitwell wrote:
OK, now that the recycle lockup has been found fixed, I don't see any
problems with this patch. Has anyone got any objections to merging it to the
trunk?
Eric, do you think this will be impossible to support on bsd? It seems to fix
On Mit, 2003-03-12 at 23:15, Smitty wrote:
PS: Editing files like this makes me kind of nervous, we should really
work out a way to handle the website in CVS.
What's the difficulty in having it in CVS? it's extremely trivial to set
up, you just tell the web server to cvs up from the
http://arstechnica.com/cpu/03q1/x86-64/x86-64-1.html
When AMD's engineers started looking for legacy x86
features to jettison, the first thing to go was the
segmented memory model. Programs written to the x86-64
ISA will use a flat, 64-bit virtual address space.
Furthermore, legacy x86
On Wed, 12 Mar 2003, Keith Whitwell wrote:
With several people in disagreement with you though, I guess it
might be a decision perhaps that should fall more into the lap of
the driver maintainer or project lead or somesuch.
Well, I didn't have much to do with this code when it was written,
On Thu, 2003-03-13 at 00:20, Philip Brown wrote:
On Wed, Mar 12, 2003 at 11:56:42PM +, Keith Whitwell wrote:
Well, I didn't have much to do with this code when it was written, but I'm
happy for it to stay where it is and as it is named for now.
If someone wanted to take on a bigger
On Thu, 13 Mar 2003 00:15:41 +0200
Smitty [EMAIL PROTECTED] wrote:
7200 aka Radeon 64 DDR, is the type and speed of the memory,
and that the TCL unit is somehow disabled via software.
7200 is SDR.
You sure about that?
My Radeon DDR VIVO identified itself (under windows) as a 7200...
On Wed, 12 Mar 2003, Jon Smirl wrote:
So if the x86-64 is getting rid of real mode when
running a 64b OS, how is XFree going to make those
nasty old vm86 INT 10 calls for things like getting
DDC and resetting secondary adapters?
It contains an emulator for real-mode 8086. How do you think
--- Peter \Firefly\ Lund [EMAIL PROTECTED] wrote:
On Wed, 12 Mar 2003, Jon Smirl wrote:
So if the x86-64 is getting rid of real mode when
running a 64b OS, how is XFree going to make those
nasty old vm86 INT 10 calls for things like
getting
DDC and resetting secondary adapters?
It
On 13 Mar 2003 03:24:10 +
Alan Cox [EMAIL PROTECTED] wrote:
A journey of 1000 miles begins with a single step
But not if that step is over a cliff, onto a landmine or down a
hole...
I like that ;-)
---
This SF.net email is sponsored
On Thu, 13 Mar 2003, Ian Molton wrote:
7200 aka Radeon 64 DDR, is the type and speed of the memory,
and that the TCL unit is somehow disabled via software.
7200 is SDR.
You sure about that?
My Radeon DDR VIVO identified itself (under windows) as a 7200...
The original Radeon R100 chip
Norton AntiVirus
2003
Sale 59.95
only $ 29.99
Limited Time
Downloadable Version
Simple and powerful, Norton AntiVirus 2003
protects your PC against viruses--and it covers e-mail and
instant
Michel Dänzer wrote:
On Mit, 2003-03-12 at 12:29, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mit, 2003-03-12 at 11:51, Keith Whitwell wrote:
In fact the lockup comes down to this one line:
--- radeon_driver.c28 Oct 2002 02:21:14 -1.44
+++ radeon_driver.c29 Oct 2002 13:49:25
In fact the lockup comes down to this one line:
--- radeon_driver.c28 Oct 2002 02:21:14 -1.44
+++ radeon_driver.c29 Oct 2002 13:49:25 -1.45
@@ -4639,6 +4639,7 @@
save-cap0_trig_cntl = 0;
save-cap1_trig_cntl = 0;
save-bus_cntl =
On Mit, 2003-03-12 at 11:51, Keith Whitwell wrote:
In fact the lockup comes down to this one line:
--- radeon_driver.c28 Oct 2002 02:21:14 -1.44
+++ radeon_driver.c29 Oct 2002 13:49:25 -1.45
@@ -4639,6 +4639,7 @@
save-cap0_trig_cntl = 0;
Michel Dänzer wrote:
On Mit, 2003-03-12 at 11:51, Keith Whitwell wrote:
In fact the lockup comes down to this one line:
--- radeon_driver.c28 Oct 2002 02:21:14 -1.44
+++ radeon_driver.c29 Oct 2002 13:49:25 -1.45
@@ -4639,6 +4639,7 @@
save-cap0_trig_cntl = 0;
46 matches
Mail list logo
