On Tue, 2002-04-09 at 07:53, Jens Owen wrote:
> Eric,
>
> First off, let me say: Good work on the porting, it's nice to see the
> OS independence put to the test.
Thanks. Things are going well. I've been approved for a commit bit to
the FreeBSD repository, and the OS-templated DRM (mostly the
In my quest for algorithmic optimizations, I have stumbled onto what I
believe must be a bug. Please take a look at the client_state function (the
first function) in enable.c. You will find the following code:
if (*var == flag)
return;
If I am correct this should actually be:
if (
On 2002.04.19 04:37 Leif Delgass wrote:
> On Thu, 18 Apr 2002, José Fonseca wrote:
>
> [snip]
>
> > I didn't take over the DMA part, but that will eventually happen. For
> now
> > I'm moving all register programming from GL driver to the DRM, but
> faking
> > DMA at the same time. This will allo
The code in i830_dma.c got broken with newer kernels.
This has already been reported several times but AFAIK nothing was done
about it. This is the first time that report comes from a person that
really has a i830, so I guess that the solution to the problem can't be
delayed any further.
I do
Thank you very much for your quick reply.
I've just sent the other mail to xpert ml that contains my quick
hack.
I am using the X with that patch for 10 minutes, and it seems working.
Unfortunately I am not an expert on this area, but I can test on the
real i830MG if someone send me a patch.
I
On Fri, Apr 19, 2002 at 12:21:04AM -0700, Raystonn wrote:
> In my quest for algorithmic optimizations, I have stumbled onto what I
> believe must be a bug. Please take a look at the client_state function (the
> first function) in enable.c. You will find the following code:
>
>if (*var == fl
Raystonn wrote:
>
> In my quest for algorithmic optimizations, I have stumbled onto what I
> believe must be a bug. Please take a look at the client_state function (the
> first function) in enable.c. You will find the following code:
>
>if (*var == flag)
> return;
>
> If I am correc
On Tue, Apr 09, 2002 at 02:02:59PM -0700, Ian Romanick wrote:
> After doing some cursory Maya testing, I decided to put the TCL branch up
> against glean, and glean won. It consistently explodes in one of the
> blendFunc tests. This is with the latest glean CVS trunk and DRI TCL branch
> as of t
Michael wrote:
>
> On Tue, Apr 09, 2002 at 02:02:59PM -0700, Ian Romanick wrote:
> > After doing some cursory Maya testing, I decided to put the TCL branch up
> > against glean, and glean won. It consistently explodes in one of the
> > blendFunc tests. This is with the latest glean CVS trunk an
Couple more things with radeon tcl.
a) tuxkart hangs (in SwapBuffers) works with RADEON_NO_TCL=1
b) Shrinking a window crashes with the following log entry, hangs
sometimes too (but that's probably just when the cmd_type isn't bad just
junk?)
Apr 17 07:13:36 debian kernel: [drm:radeon_cp_cmdbu
Hi Jose,
I will certainly test the branch on my Sony Vaio (but I will keep the
mach64-0-0-3 branch for occasionally playing Unreal;-)). Please tell us
when the branch is stable enough to test it and what tests we should run.
Thanks for all the work you do for the Mach64,
Greetings,
Michael
___
On 2002.04.19 09:02 moto kawasaki wrote:
>
> Thank you very much for your quick reply.
>
> I've just sent the other mail to xpert ml that contains my quick
> hack.
> I am using the X with that patch for 10 minutes, and it seems working.
>
You must make sure you exercise that code. The only way
Oops, intended to send this to the list...
-Original Message-
From: Alexander Stohr
Sent: Friday, April 19, 2002 13:54
To: 'Gareth Hughes'
Subject: RE: [Dri-devel] New cards (GPU's) from old card makers? DRI
support?
> > I really hope not... and at least in with the cards that I
> may
Hi,
I'm using DRI on a G400 card with 16MB video RAM. When using graphics
extensively (FlightGear) in a high-resolution set-up (1600x1200,
16bpp), the X server hangs after a few minutes of starting the
program. On 1280x1024, 16bpp, it can also hang, but it usually takes
hours before it does. The
It's available from http://dri.sourceforge.net/snapshots/cf/ the first
binary snapshots made from the SF compiler farm.
I would appreciate that people tested if they are working properly as
they'll replace the snaphsots made in my workstation.
There were a lot of changes in the building scripts:
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.
- Frank
___
On Fri, Apr 19, 2002 at 01:26:40PM +0100, Major A wrote:
> I'm using DRI on a G400 card with 16MB video RAM. When using graphics
> extensively (FlightGear) in a high-resolution set-up (1600x1200,
> 16bpp), the X server hangs after a few minutes of starting the
> program. On 1280x1024, 16bpp, it c
On Fri, 19 Apr 2002, José Fonseca wrote:
> On 2002.04.19 04:37 Leif Delgass wrote:
> > On Thu, 18 Apr 2002, José Fonseca wrote:
> >
> > [snip]
> >
> > > I didn't take over the DMA part, but that will eventually happen. For
> > now
> > > I'm moving all register programming from GL driver to the
On 2002.04.19 20:38 Leif Delgass wrote:
> On Fri, 19 Apr 2002, José Fonseca wrote:
> > ...
> >
> > It's commited. As I'm stuck in this point, there is no reason to delay
> > any further.
> >
> > I've commited in steps to document the changes in the several parts.
> >
> > As I still don't know how
On Fri, Apr 19, 2002 at 08:29:59PM +0100, Major A wrote:
> > I sent an e-mail to the list a few days ago explaining how to reproduce this
> > problem with Quake 3. In that mail there were some instructions for
> > enabling debug messages in the MGA driver. Could you please follow those
> > step
On Fri, Apr 19, 2002 at 12:53:54PM -0700, Ian Romanick wrote:
> I filed a bug report with all the text from the message. The bug is #546281.
>
>
>http://sourceforge.net/tracker/index.php?func=detail&aid=546281&group_id=387&atid=100387
This may also be the same as #442693 & #522096/515182. Th
Jeff,
I've really been trying to figure this out but with no success so far. I
don't know if there's a bug somewhere or if I'm forgeting to make some
step.
I need to access the contents of a DMA buffer allocated from AGPGART
within the DRM.
Initialy I attemped to use the "buf->address" direct
"José Fonseca" wrote:
>
> Jeff,
>
> I've really been trying to figure this out but with no success so far. I
> don't know if there's a bug somewhere or if I'm forgeting to make some
> step.
>
> I need to access the contents of a DMA buffer allocated from AGPGART
> within the DRM.
> Initialy I a
On 2002.04.20 00:36 Keith Whitwell wrote:
> "José Fonseca" wrote:
> ...
>
> Jose,
>
> The radeon drm module accesses dma memory in the
> radeon_cp_dispatch_indirect()
> function:
>
> u32 *data = (u32 *)
> ((char *)dev_priv->buffers->handle
>
On 2002.04.19 20:51 José Fonseca wrote:
> ...
> The only reason I didn't made what you're saing is because I already got
> the psued DMA stuff running at the client, now I've put it in the DRM,
> and I don't want to do more than one change at each time otherwise if
> there is a error I won't kn
25 matches
Mail list logo
