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 i
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 h
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: 2[MB/f
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 reaso
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, th
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 work
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
On Saturday 25 May 2002 06:37 pm, David Willmore wrote:
> I'm new to the devel list--I got on to help test the new Mach64
> code. I don't have much time these days to contribute coding,
> but I can test. ;)
Everything is welcome- and your testing is appreciated. (Nice domain name,
BTW. I lik
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 <[
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 usuall
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
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
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.
> >
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 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
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.
> > >
> >
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 walktes
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
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 Mich
On Friday 24 May 2002 11:39 pm, Michel Dänzer scribed numinously:"
> Logging the buffer age in radeon_cp_discard_buffer() and looking at what
> happened after the buffer with the age shown in 'done=x' was
> discarded might be interesting.
Just saw your message as I was about to post. I've act
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 se
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 cal
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 DM
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 cour
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 a
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 motherboard
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 holdin
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
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, F
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 pre
(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 ne
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 secu
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 ad
> 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 >
On Sat, 2002-05-25 at 09:06, Jacek Popławski 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
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 b
Maybe it's a stupid idea, but probably a new one in this discussion :)
The main problem that DRI is concerned with is rather low level hardware
support. There is a lot more stuff in XFree86 that DRI just doesn't
worry about. I'm just thinking of input devices, the plethora of
extensions, fonts, a
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 a
>
> 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 obtaina
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)
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
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 no
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 update
[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
> > >
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 onl
> 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 impressio
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 m
> 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 an 8500 ;)
Intere
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
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-T&L code. What doe
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.
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 the
52 matches
Mail list logo
