Well, I knocked one item off the list. I implemented sequential
multi-register writes in the primitive functions. Seems to help my
framerate a bit even with pseudo-DMA. I changed the primitive functions
to supply the register addresses as the memory-mapped addresses, which is
what the GUI-maste
On Wednesday 17 April 2002 09:46, José Fonseca wrote:
> For the record,
>
> I just want to say I'm really sorry for started this thread. When I did it
> I had hope to bring Robert Lunnon (which is currently working on the
> Utah-GLX's Mach64 driver) to join efforts, as I though he wasn't using DRI
On Thu, 18 Apr 2002 23:37:20 -0400 (EDT)
Leif Delgass <[EMAIL PROTECTED]> wrote:
> I can provide some background on this, since I played around with the
> locks back when Manuel was working on this. First off, it'll probably be
> most productive to work on this on the new branch, when all the
On 2002.04.20 22:41 Leif Delgass wrote:
> On Sat, 20 Apr 2002, José Fonseca wrote:
>
> ...
> > The question is what do next? These are some things that we could do:
> > - check the FIFO when PseudoDMAing (as in Utah)
> > - Texture Uploads through the DRM (blits)
> > - DMA buffer aging (even
On Sat, 20 Apr 2002, José Fonseca wrote:
> On 2002.04.20 21:21 Leif Delgass wrote:
> > Jose,
> >
> > I added the remaining bits to copy the agp texture region info to the
> > drm.
> > It's not used, but the information is there in case we need it later.
> >
> > I hope you don't mind, but I took
On 2002.04.20 21:21 Leif Delgass wrote:
> Jose,
>
> I added the remaining bits to copy the agp texture region info to the
> drm.
> It's not used, but the information is there in case we need it later.
>
> I hope you don't mind, but I took the liberty of converting your drm
> emit_state functions
Jose,
I added the remaining bits to copy the agp texture region info to the drm.
It's not used, but the information is there in case we need it later.
I hope you don't mind, but I took the liberty of converting your drm
emit_state functions to use the DMA* macros, which ensures that enough
f
The idea was that people who don't have XFree86 4.1 or later can just
use the Extras package to upgrade their X server, instead of upgrading
all of X.
This worked pretty well in the past for people who had version problems
with the X server being too old for the binary package.
- Frank
On Sat,
Manfred,
On 2002.04.20 09:52 Manfred Odenstein wrote:
> Hi there,
> I've only a few questions :
> 1.)
> @Radeon: I'm using mdk 8.2 which comes with XFree86 4.2.0, kernel
> 2.4.18, is there any difference with the driver (except T&L) in the CVS
> ?. ...
The CVS trunk includes Mesa 4.x, which has
On 2002.04.19 19:16 Frank Worsley wrote:
> Hi,
>
> I'm getting repeated emails from people asking for an extras package.
> Anybody want to volunteer to make one? All it needs to contain is an
> updated X server binary and a shell script that installs the binary and
> does suid root on it.
>
> -
Nightly snapshots of tcl-0-0-branch are now also available from
http://dri.sourceforge.net/snapshots/bleeding-edge/ with the name
radeon-tcl-* . Now is really very easy to build any other branch.
All the scripts I use are available in
http://dri.sourceforge.net/snapshots/scripts/. Here is a br
Hi there,
I've only a few questions :
1.)
@Radeon: I'm using mdk 8.2 which comes with XFree86 4.2.0, kernel
2.4.18, is there any difference with the driver (except T&L) in the CVS
?. CannonSmash crashes whole X, Tux in TuxRacer isn't rendered
correctly, Tulpas crashes during startup.
8<---
I've commited some preliminary changes necessary for AGP texturing to the
mach64-0-0-4-branch. The changes are only in the DDX and Mesa portions of
the driver, no drm changes yet. I've added necessary fields to the
structures in mach64_dri.h (DDX), using r128 as a model. I've disabled
the ring
13 matches
Mail list logo
