Michel Dänzer wrote:
>
> 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
Linus Torvalds wrote:
> A hot system call takes about 0.2 us on an athlon (it takes significantly
> longer on a P4, which I'm beating up Intel over all the time). The ioctl
> stuff goes through slightly more layers, but we're not talking huge
> numbers here. The system calls are fast enough that
On Mon, 2002-05-27 at 00:02, Michael wrote:
> On Sun, May 26, 2002 at 08:17:18PM +0200, Michel Dänzer wrote:
> > I've updated the patch, unless someone comes up with an argument against it
> > I'll commit it soon.
>
> I don't have anything to test, so if it doesn't break i386 it works for me :o)
On Mon, 2002-05-27 at 00:20, Ian Molton wrote:
> How do I check out the Radeon TCL code?
cvs co -r tcl-0-0-branch xc
> (sorry, but I cant find the branch. how do I list all the available
> branches?)
Well, zsh completes them when I hit tab after the -r. :)
Or use cvs status -v on a file, or th
How do I check out the Radeon TCL code?
(sorry, but I cant find the branch. how do I list all the available
branches?)
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.spr
On Sun, May 26, 2002 at 08:17:18PM +0200, Michel Dänzer wrote:
> I've updated the patch, unless someone comes up with an argument against it
> I'll commit it soon.
I don't have anything to test, so if it doesn't break i386 it works for me :o)
> > Last, but not least, there's an off-by-one error
On Sun, 2002-05-26 at 20:17, Michel Dänzer wrote:
>
> > Another arch-independent issue I found is that sometimes parts of
> > objects aren't rendered (correctly), as seen in
> > http://penguinppc.org/~daenzer/DRI/morph3d.jpeg and
> > http://penguinppc.org/~daenzer/DRI/armagetron.jpeg (both trails
The VT switching lockup problem with DRI is different from the one (AMD 761)
discussed lately. The XFree CVS or RH73 code has the fix for that one, see
http://www.geocrawler.com/lists/3/SourceForge/2634/25/8680261/.
This one (VT switching lockup with DRI) has been haunting us for a while. It
appea
Following up to myself...
On Tue, 2002-05-21 at 19:55, Michel Dänzer wrote:
>
> Patch against the trunk is at
> http://penguinppc.org/~daenzer/DRI/radeon-ppc.diff
>
> Requests for comments before I commit:
[...]
> - Is this a good way to detect endianness? And there's probably a better
>
Al Tobey wrote:
> Per the "Cards & Specs" discussion, you could mention the 3dfx drivers
> and possibly some other areas that need work. The link to the 3dfx
> specs might also be a good idea.
Links to published specs is a good idea. Intel's i810 specs are
published as well. There may be othe
On Friday 24 May 2002 11:17 am, I wrote:"
> The XFree 4.2 driver is stable, but drops textures on the floor somwhere.
>
> The CVS code produces correct textures, but locks up under heavy use with
> the symptoms described. I've been using the binaries from
> dri.sourceforge.net to test this with. I
On Fri, May 24, 2002 at 01:54:52PM -0700, Keith Packard wrote:
>We have an agreement in principle for DRI to use the XFree86 CVS tree
>instead of their separate tree on sourceforge, but that hasn't happened
>for reasons I don't understand. While that won't fix everything, it
I think that's o
Brian,
Is it possible some behavioral changes were introduced into the internal
GLX interface when you cleaned up this code a while back?
The root of the issue appears to be how the two distinct sets of visuals
(those supported by Mesa's SW renderer and those supported by a
particular HW driver)
Al Tobey wrote:
>
> Didn't find much in the wild, I did find that there are DRI/Linux
> drivers for the Kryo and KyroII series chips. Looks like the Kyro is
> going down similar paths as Nvidia. There's even a cute comment about
> DRI in the README.
>
> http://www.powervr.com/downloads.asp
Al
Adam K Kirchhoff wrote:
> 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.
There are a couple of problems with the technique of blitting 2d changes
between the buffers - try moving a
Adam K Kirchhoff wrote:
> 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
Michael wrote:
> 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 eas
Linus and Keith P.,
Thank you very much for your valuable insights - they cleared a
misconception I had about memory transfers.
Of course, to get to the bottom of this, we will have to test several
buffer sizes - I'm sure it will be an interesting study.
Regards,
José Fonseca
On Sat, 25 May 2002, Keith Whitwell wrote:
>> (IMHO: The specs should be accessible to anyone... While in certain
>> fields this is happening due to the spread of Linux, 3D graphics isn't
>> surely one of them. In any case we can't really blaim ATI, as they have
>> been one of the most open an
19 matches
Mail list logo
