On Fri, May 24, 2002 at 06:35:36PM -0700, Linus Torvalds wrote:
On Sat, 25 May 2002, Michael wrote:
As you surmise, it takes hours, more so now, because I'm pouring through
DEBUG_VERBOSE output. (I've noticed a couple of places where the packet
type isn't 6 because there's no
Hi!, this might look like an stupid question, but well ...
I have recently bought an ATI Radeon 7000 and its working very well with
dri, but my problem is this, my old Voodoo Banshee is giving 958.2 FPS
with glxgears, and my Radeon is only giving 611.6 FPS, both in the
same conditions and with
On 2002.05.25 06:10 Leif Delgass wrote:
On Fri, 24 May 2002, Frank C. Earl wrote:
On Thursday 23 May 2002 04:37 pm, Leif Delgass wrote:
I've committed code to read BM_GUI_TABLE to reclaim processed buffers
and
disabled frame and buffer aging with the pattern registers. I've
Louis Garcia wrote:
This messages is for Keith. I am planning on getting a Radeon8500 soon
and would like to test the driver you are working on. Let me know.
Louis, I don't even *have* an 8500, let alone a driver for one...
Also on the developers FAQ you talk about pre-TL code. What does
thork wrote:
Hi!, this might look like an stupid question, but well ...
I have recently bought an ATI Radeon 7000 and its working very well with
dri, but my problem is this, my old Voodoo Banshee is giving 958.2 FPS
with glxgears, and my Radeon is only giving 611.6 FPS, both in the
same
quote who=Keith Whitwell
Louis Garcia wrote:
This messages is for Keith. I am planning on getting a Radeon8500 soon
and would like to test the driver you are working on. Let me know.
Louis, I don't even *have* an 8500, let alone a driver for one...
Well, I'm one up - at least I have
d then it still require regular maintenance and management.
Getting DRI into XFree86 CVS seems like a relatively low-overhead way to
reduce the lag between the two systems, perhaps we can try to restart
those discussions.
Well, I confess I was unaware of this, and it's really not my choice,
Interestingly, I just got this response from ATI regarding my request for
info:
We are not providing information for 3D development (DRI Project) for the
8500 as of yet. This may change in the future but at this point not in
the near future.
I was under the impression that they
Keith Whitwell writes:
thork wrote:
Hi!, this might look like an stupid question, but well ...
I have recently bought an ATI Radeon 7000 and its working very well with
dri, but my problem is this, my old Voodoo Banshee is giving 958.2 FPS
with glxgears, and my Radeon is only giving
[EMAIL PROTECTED] wrote:
Keith Whitwell writes:
thork wrote:
Hi!, this might look like an stupid question, but well ...
I have recently bought an ATI Radeon 7000 and its working very well with
dri, but my problem is this, my old Voodoo Banshee is giving 958.2 FPS
with
Louis,
Let'me straight this out, since it's mainly my fault that the Devel FAQ
(http://dri.sourceforge.net/doc/faq/hardware.html#RADEON-8500-PLANS) isn't
clear about it:
Kevin Martin is the one working on the Radeon 8500. He has benn working on
the 2D driver and recentely made a status
José Fonseca wrote:
On 2002.05.25 11:05 Keith Whitwell wrote:
Interestingly, I just got this response from ATI regarding my request
for
info:
We are not providing information for 3D development (DRI Project)
for the
8500 as of yet. This may change in the future but at this point
On 2002.05.25 13:03 Keith Whitwell wrote:
José Fonseca wrote:
On 2002.05.25 11:05 Keith Whitwell wrote:
Interestingly, I just got this response from ATI regarding my request
for
info:
We are not providing information for 3D development (DRI Project)
for the
8500 as of yet.
Oh! That's ok then. It's understandable, even if it can be little harsh
with newbies, it's better
I think that I'll remove from the FAQ the direct links for the specs
requesting forms of ATI and others vendors - its existence can give the
impression that they are easily obtainable -
On Fri, 2002-05-24 at 19:54, Smitty wrote:
6) What is required in order to produce drivers for other architectures
- If people tell me this, I will add it to the 'help us' section of the
site.
Do you mean other architectures as in other OSs or as in other processor
architectures for an
On Fri, May 24, 2002 at 11:44:05PM -0400, Al Tobey wrote:
Want ATI to give you 8500 docs? Sure, go fix the 3dfx driver, and you'll
have a much better chance of getting them.
I have three choices now:
1) stay with Voodoo3
2) buy Radeon 7500
3) buy Radeon 8500
If Radeon driver will be much
On Sat, 2002-05-25 at 09:06, Jacek Popawski wrote:
So: If ATI want to sell more 8500 - it should help fix 3dfx driver.
What I was saying is if you want specs for the 8500 to develop the
driver for it, you need to have a track record. Fixing the 3dfx driver
is a good way to show that you have
I think that I'll remove from the FAQ the direct links for the specs
requesting forms of ATI and others vendors - its existence can give the impression
that they are easily obtainable - which is not true. As you said, if we pest too
much we are killing the golden egg chicken and we must
On Saturday 25 May 2002 12:10 am, Leif Delgass wrote:
So it would appear that allowing clients to add register commands to a
buffer without verifying them is _not_ secure. This is going to make
things harder, especially for vertex buffers. This is going to require
copying buffers and
On Saturday 25 May 2002 03:01 am, José Fonseca wrote:
Wow! Bummer... I already had convinced myself that the card was secure!
It is, if you don't rely on a register being set by something for your
control of things. You may get peak performance with the design in question,
but it's not
(Yay finished assignments and stuff! ;-)
Having upgraded to the latest tcl-0-0-branch code (as well as the
latest fgfs code), the situation's back where it started - airports
in the US have very dark scenery, whereas everywhere else seems to
be fine.
I've also noticed something that's either
On 2002.05.25 17:16 Frank C. Earl wrote:
On Saturday 25 May 2002 03:01 am, José Fonseca wrote:
Wow! Bummer... I already had convinced myself that the card was secure!
It is, if you don't rely on a register being set by something for your
control of things. ...
Frank, Leif was pretty
Forgot to cc the list...
--
Leif Delgass
http://www.retinalburn.net
-- Forwarded message --
Date: Sat, 25 May 2002 12:56:08 -0400 (EDT)
From: Leif Delgass [EMAIL PROTECTED]
To: Frank C. Earl [EMAIL PROTECTED]
Subject: Re: [Dri-devel] Mach64 dma fixes
On Sat, 25 May 2002,
On Saturday 25 May 2002 11:48 am, José Fonseca wrote:
On 2002.05.25 17:16 Frank C. Earl wrote:
Frank, Leif was pretty clear and I quote:
it IS possible to derail a bus master in progress and set it
processing from a different table in mid-stream. Plus, if the address is
bogus or the
On Saturday 25 May 2002 11:56 am, you wrote:
What prevents a client from modifying the contents of a buffer after it's
been submitted? Sure, you can't send new buffers without the lock, but
the client can still write to a buffer that's already been submitted and
dispatched without holding
Hello,
I noticed a thread in April, 2002 about DRI lockups people were seeing
when using a Radeon card with the AMD 760MP chipset. I didn't see a
resolution, though, and as I am seeing the same thing now, I wanted to ask
what the status is.
I'm using a Radeon VE QY with a Tyan S2460
On Sat, 25 May 2002, Frank C. Earl wrote:
On Saturday 25 May 2002 11:56 am, you wrote:
What prevents a client from modifying the contents of a buffer after it's
been submitted? Sure, you can't send new buffers without the lock, but
the client can still write to a buffer that's already
Frank,
On 2002.05.25 18:24 Frank C. Earl wrote:
... This is extremely disappointing to say the least. Doing the
copying is going to eat at least part if not all the advantage of doing
either route.
Yes, it's something we have to deal regardless of how we flush the DMA
buffers..
Of course
On Saturday 25 May 2002 11:48 am, José Fonseca wrote:
So if you can't secure it in the end, your extra effort will be in vain.
I just thought of something to try to change the nature of the test case
problem. What happens if you have a second descriptor of commands that
merely resets the
On Saturday 25 May 2002 01:14 pm, Leif Delgass wrote:
I'm using the same model you had set up. When a client submits a buffer,
it's added to the queue (but not dispatched) and there's no blocking.
The DRM batch submits buffers when the high water mark is reached or the
flush ioctl is called
On 2002.05.25 20:36 Frank C. Earl wrote:
On Saturday 25 May 2002 11:48 am, José Fonseca wrote:
So if you can't secure it in the end, your extra effort will be in
vain.
I just thought of something to try to change the nature of the test case
problem. What happens if you have a second
I noticed there are two conflicting definitions for this in
programs/Xserver/hw/xfree86/drivers/ati/r128_common.h. One of them used
to be in programs/Xserver/hw/xfree86/os-support/xf86drmR128.h, the other
one was introduced with the drmCommand stuff.
Does this fix look good?
--
Earthling
On Sat, 25 May 2002, José Fonseca wrote:
On 2002.05.25 20:36 Frank C. Earl wrote:
On Saturday 25 May 2002 11:48 am, José Fonseca wrote:
So if you can't secure it in the end, your extra effort will be in
vain.
I just thought of something to try to change the nature of the test
Keith Whitwell writes:
[EMAIL PROTECTED] wrote:
OK, this is slightly confusing for me. I have a dual 1800+ athlon and
an 7500. I'm running the CVS version (tcl-0-0-branch) of DRI and I only
see 574fps from glxgears. (Every other application I've tried
(Cyrstalspace's walktest,
On Sat, 25 May 2002, Leif Delgass wrote:
On Sat, 25 May 2002, José Fonseca wrote:
On 2002.05.25 20:36 Frank C. Earl wrote:
On Saturday 25 May 2002 11:48 am, José Fonseca wrote:
So if you can't secure it in the end, your extra effort will be in
vain.
I just thought of
On Saturday 25 May 2002 03:44 pm, Leif Delgass wrote:
This had crossed my mind too. The only problem is that there could still
be a short period of time where BM_GUI_TABLE isn't accurate, so it still
leaves the problem of being able to trust the contents of BM_GUI_TABLE for
buffer aging and
On Saturday 25 May 2002 03:50 pm, Leif Delgass wrote:
It just occurred to me that resetting BM_GUI_TABLE could put the card into
a loop. You might have to put in an address two descriptors away. We'd
need to test this.
Hmm... Didn't think about that possibility. I had this last line of
On Sat, 2002-05-25 at 12:03, Keith Whitwell wrote:
d then it still require regular maintenance and management.
Getting DRI into XFree86 CVS seems like a relatively low-overhead way to
reduce the lag between the two systems, perhaps we can try to restart
those discussions.
Well, I
On 2002.05.25 21:50 Leif Delgass wrote:
On Sat, 25 May 2002, Leif Delgass wrote:
On Sat, 25 May 2002, José Fonseca wrote:
...
This had crossed my mind too. The only problem is that there could
still
be a short period of time where BM_GUI_TABLE isn't accurate, so it
still
On Saturday 25 May 2002 04:27 pm, you wrote:
Anyway, this doesn't prevent to use the buffer aging. On the end of
processing a buffer we still end up with the correct value of BM_GUI_TABLE
and we can use the last bit of BM_COMMAND to know if it's processing the
last entry or not. The only
I'm using a very recent pull of the TCL branch and am happy to report page
flipping working here (with really impressive increases in speed), and no
lock-ups.
However, some GL apps that I've tried end up creating a few pixels of
distortion across the top of the screen (the full width, and
Does anyone have any ideas on this? I haven't seen compiler messages like
this before when compiling the drm.
--
Leif Delgass
http://www.retinalburn.net
-- Forwarded message --
Date: Sun, 26 May 2002 00:37:11 +0200
From: Gerard Delafond [EMAIL PROTECTED]
To: Leif Delgass
On Saturday 25 May 2002 06:07 pm, Leif Delgass wrote:
Does anyone have any ideas on this? I haven't seen compiler messages like
this before when compiling the drm.
Did Gerard indicate what distribution and C compiler he was working with?
This is the same bizarre things I usually saw when
Le Dimanche 26 Mai 2002 01:14, Frank C. Earl a écrit :
On Saturday 25 May 2002 06:07 pm, Leif Delgass wrote:
Does anyone have any ideas on this? I haven't seen compiler messages
like this before when compiling the drm.
Did Gerard indicate what distribution and C compiler he was working
On Sat, 25 May 2002, Frank C. Earl wrote:
Linus, if you're still listening in, can you spare us a moment to tell us
what consequences quickly mapping and unmapping memory reigons into userspace
has on the system?
It's reasonably fine on UP, and it often _really_ sucks on SMP.
On UP, the
On 2002.05.26 00:49 Linus Torvalds wrote:
On Sat, 25 May 2002, Frank C. Earl wrote:
Linus, if you're still listening in, can you spare us a moment to tell
us
what consequences quickly mapping and unmapping memory reigons into
userspace
has on the system?
It's reasonably fine on
On Sun, 26 May 2002, José Fonseca wrote:
The vertex data alone (no textures here) can be several MBs per frame
Yes, yes, I realize that the cumulative sizes are big. The question is not
the absolute size, but the size of one bunch.
Throwing some numbers just to get a rough idea:
Around 18 o'clock on May 25, Linus Torvalds wrote:
You can often make things go faster by simplifying and streamlining the
code rather than trying to be clever and having a big footprint. Ask Keith
Packard about the X frame buffer code and this very issue some day.
The frame buffer code has
On Sat, May 25, 2002 at 07:37:33AM +0100, Michael wrote:
On Fri, May 24, 2002 at 06:35:36PM -0700, Linus Torvalds wrote:
which certainly seems to imply that there are bogus command packets being
sent to the kernel by tuxracer.
Nod, this should be relatively easy given the nice way it
49 matches
Mail list logo
