Am Freitag, den 24.03.2006, 23:50 +0200 schrieb Micha Feigin:
> On Thu, 28 Jul 2005 16:30:47 -0400
> Alex Deucher <[EMAIL PROTECTED]> wrote:
>
> > On 7/28/05, Svante Signell <[EMAIL PROTECTED]> wrote:
> > > Is anything happening on the Mach64 front for DRI/X.org? It would be
> > > nice to use the
On 3/24/06, Micha Feigin <[EMAIL PROTECTED]> wrote:
> On Thu, 28 Jul 2005 16:30:47 -0400
> Alex Deucher <[EMAIL PROTECTED]> wrote:
>
> > On 7/28/05, Svante Signell <[EMAIL PROTECTED]> wrote:
> > > Is anything happening on the Mach64 front for DRI/X.org? It would be
> > > nice to use the 3D capabili
On Thu, 28 Jul 2005 16:30:47 -0400
Alex Deucher <[EMAIL PROTECTED]> wrote:
> On 7/28/05, Svante Signell <[EMAIL PROTECTED]> wrote:
> > Is anything happening on the Mach64 front for DRI/X.org? It would be
> > nice to use the 3D capabilities, now that Debian has upgraded unstable
> > to Xorg.
>
> t
On Wednesday 23 November 2005 18:32, Alan Cox wrote:
> On Mer, 2005-11-23 at 11:46 -0500, Adam Jackson wrote:
> > On Wednesday 23 November 2005 07:48, Michael Frank
wrote:
> > > Testing 2.6.15-rc2 in-kernel DRM, why still no
> > > mach64 support which works fine for me from
> > > snapshots/cvs?
>
On Mer, 2005-11-23 at 11:46 -0500, Adam Jackson wrote:
> On Wednesday 23 November 2005 07:48, Michael Frank wrote:
> > Testing 2.6.15-rc2 in-kernel DRM, why still no mach64
> > support which works fine for me from snapshots/cvs?
>
> Because it's still insecure.
Michael - If you've got a Mach64 a
On Wednesday 23 November 2005 07:48, Michael Frank wrote:
> Testing 2.6.15-rc2 in-kernel DRM, why still no mach64
> support which works fine for me from snapshots/cvs?
Because it's still insecure.
- ajax
pgpRVEStYxIcP.pgp
Description: PGP signature
On 7/28/05, Svante Signell <[EMAIL PROTECTED]> wrote:
> Is anything happening on the Mach64 front for DRI/X.org? It would be
> nice to use the 3D capabilities, now that Debian has upgraded unstable
> to Xorg.
there is a DRI driver for mach64, but the drm is not yet secure so
it's not built by defa
thanks alex and leif,
I'm trying to recompile using the ubuntu source package... If I only
want to build the mach64 dri/drm drivers... do I still need to rebuild
the whole x server?... :-S
On 4/24/05, Alex Deucher <[EMAIL PROTECTED]> wrote:
> That code is old. please try the new DRI instructions
On 4/23/05, Rolando Abarca <[EMAIL PROTECTED]> wrote:
> I'm trying to compile the mach64 dri and kernel modules for powerpc
> (lombard powerbook)... I followed the instructions im
>
> http://www.retinalburn.net/linux/dri_HOWTO.html
>
> (checked out mach64-0-0-6-branch)
> I also modified the confi
Dave Airlie wrote:
That's very possible, but I did reinstall from my local copy of the DRI/Mesa
cvs tree.
where did the drm come from?
The drm branch of the DRI cvs. From back in September. What's the current
state of the cvs tree? I don't mind upgrading to the most recent code, but
g
>
> That's very possible, but I did reinstall from my local copy of the DRI/Mesa
> cvs tree.
>
> > where did the drm come from?
> >
> >
> The drm branch of the DRI cvs. From back in September. What's the current
> state of the cvs tree? I don't mind upgrading to the most recent code, but
> given
Dave Airlie wrote:
Mind you, I haven't updated my copy of the DRI cvs tree in a very long time.
Certainly not since I last did a "make install". Any ideas?
The only thing I'm noticing now that I don't remember seeing before is this:
mach64: Ignoring new-style parameters in presence of obsolete one
>
> Mind you, I haven't updated my copy of the DRI cvs tree in a very long time.
> Certainly not since I last did a "make install". Any ideas?
>
> The only thing I'm noticing now that I don't remember seeing before is this:
>
> mach64: Ignoring new-style parameters in presence of obsolete ones
> [
>
> I first tried installing the binaries from the dri project, but when I tried
> to restart X I got error messages saying it couldn't open the virtual console.
> So I uninstalled, got the dri/drm/mesa sources and built/installed. X starts
> fine, and DRI is now a listed extension. glxinfo runs. B
>
> That's ugly, and probably unnecessary. I'll take a look.
>
they should be all gone .. I fixed and actually tested for once the other
night..
Dave.
> - ajax
>
>
> ---
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite! GU
On Wed, Jun 02, 2004 at 06:41:26PM -0500, Adam Jackson wrote:
> On Wednesday 02 June 2004 15:27, Jon Smirl wrote:
> > Does anyone know how to get rid of the 500 warnings from the Mach64 driver?
> > None of the other drivers have this problem.
>
> ((GLubyte *)dst)++;
>
> That's ugly, and probably
On Wednesday 02 June 2004 15:27, Jon Smirl wrote:
> Does anyone know how to get rid of the 500 warnings from the Mach64 driver?
> None of the other drivers have this problem.
((GLubyte *)dst)++;
That's ugly, and probably unnecessary. I'll take a look.
- ajax
--
> Can you fix the 500 compiler warnings while you're in there?
okay it's finally done there shouldn't be all those warnings, and I've
tested it on my laptop and it seems to still work, I also fixed the
version check code that was recently put in ..
wouldn't mind someone on a big endian testing i
> Can you fix the 500 compiler warnings while you're in there?
I actually have the fixes for all those warnings in a tree already,
however they defo require testing as they are to do with building the
vertex info for sending to the card..
Dave.
>
> --- Dave Airlie <[EMAIL PROTECTED]> wrote:
>
Can you fix the 500 compiler warnings while you're in there?
--- Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> okay I'll have a go and making the m64 use the Mesa stuff tonight if I can
> drag myself away from nwn :-)
>
> Dave.
>
> On Sun, 6 Jun 2004, Jon Smirl wrote:
>
> > CPU_TO_LE32() etc seem
okay I'll have a go and making the m64 use the Mesa stuff tonight if I can
drag myself away from nwn :-)
Dave.
On Sun, 6 Jun 2004, Jon Smirl wrote:
> CPU_TO_LE32() etc seems to already be defined in mesa/main/glheader.h. Should
> mach64 be using that version?
>
> =
> Jon Smirl
> [EMAIL PROT
CPU_TO_LE32() etc seems to already be defined in mesa/main/glheader.h. Should
mach64 be using that version?
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
On Mon, 2004-06-07 at 00:52 +0100, Dave Airlie wrote:
> >
> > I'm afraid that's glibc specific.
>
> If I use on FreeBSD can I do the same thing?
>
> it'll look messy but to avoid the X includes we should do it ..
>
> #ifdef __linux__
> #include
> #else
> #include
> #define __BYTE_ORDER BYTE_O
I see use of MESA_BIG_ENDIAN in the other drivers, could you use that instead?
mach64 is the only driver using the X headers.
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://me
How about a copy/rename of teh X include and then s/X/dri/ it till it's
good to go. This would make (re)porting a no task task.
--- Dave Airlie <[EMAIL PROTECTED]> wrote:
> >
> > I'm afraid that's glibc specific.
>
> If I use on FreeBSD can I do the same thing?
>
> it'll look messy but to avoi
>
> I'm afraid that's glibc specific.
If I use on FreeBSD can I do the same thing?
it'll look messy but to avoid the X includes we should do it ..
#ifdef __linux__
#include
#else
#include
#define __BYTE_ORDER BYTE_ORDER
#define __LITTLE_ENDIAN LITTLE_ENDIAN
#define __BIG_ENDIAN BIG_ENDIAN
#en
On Mon, 2004-06-07 at 00:32 +0100, Dave Airlie wrote:
> I've changed it to include /usr/include/endian.h rather than Xarch, it
> should work...
I'm afraid that's glibc specific.
--
Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://s
I've changed it to include /usr/include/endian.h rather than Xarch, it
should work... but I can't test it until I get back to my laptop...
Dave.
On Sun, 6 Jun 2004, Jon Smirl wrote:
> The mach64 driver includes Xarch.h. In the mesa-solo model it can't do this
> since there is no X around. Is th
It's been on my todo at home list for a while ... I'll see about getting
it done this evening, I wanted to test the mach64 but I needed to wait for
the DRI to get back to working ...
Dave.
On Wed, 2 Jun 2004, Jon Smirl wrote:
> Does anyone know how to get rid of the 500 warnings from the Mach64
from my laptop
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M
AGP 2x (rev 64) (prog-if 00 [VGA])
looks the same to me and mine works :-) so yours should ...
On Fri, 12 Mar 2004, Mike Mestnik wrote:
> I don't know, if it loads or not, I stoped trying when I found ought
I don't know, if it loads or not, I stoped trying when I found ought that
only Rage pro was supported. However the 2d driver workes fine.
01:00.0 Class 0300: 1002:4c4d (rev 64)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M
AGP 2x (rev 64) (prog-if 00 [VGA])
Sub
Send your cards PCI ids to the list,
Mike what card have you the DRM shouldn't load for any card that doesn't
have the triangle engine really..
Dave.
On Thu, 11 Mar 2004, Mike Mestnik wrote:
> At first I thought it just might have been my system. In debuging the
> problem I found ought that m
At first I thought it just might have been my system. In debuging the
problem I found ought that my chip dose not have triangle setup. It's not
likely that it will be supported by DRI. However the 2d driver gave me
xrendr support, this will help with TV out for me.
As for the kmod if you post t
> What makes you think that Red Hat Linux is marketed at "gamers"?
> I'm not sure where you've gotten that disillusion.
Well, probably I've taken the idea of "general purpose distro" too far.
Alan and you, Mike, has already proved I was wrong:)
> on their Microsoft Windows CDROM. People go to t
On Wed, 12 Feb 2003, Martin Spott wrote:
>Date: Wed, 12 Feb 2003 14:36:41 +0100 (CET)
>From: Martin Spott <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>List-Id:
>Subject: Re: mach64-0-0-6-branch
>
>> [...] Since the GATOS head is now based
>> on current XFr
On Wed, 17 Jul 2002, Keith Whitwell wrote:
> >>I've done all the others. Lets see if testing was required...
> >>
> >
> > So, should I commit the fix for r128? I've tested that and it works fine.
>
> Yes, go ahead.
>
> > I took a look at the other drivers concerning the read buffer fix. I
Leif Delgass wrote:
> On Wed, 17 Jul 2002, Keith Whitwell wrote:
>
>
>>Leif Delgass wrote:
>>
>>>On Wed, 17 Jul 2002, Leif Delgass wrote:
>>>
>>>
>>>
On 17 Jul 2002, Michel Dänzer wrote:
>On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote:
>
>
>>I've fixed this
On Wed, 17 Jul 2002, Keith Whitwell wrote:
> Leif Delgass wrote:
> > On Wed, 17 Jul 2002, Leif Delgass wrote:
> >
> >
> >>On 17 Jul 2002, Michel Dänzer wrote:
> >>
> >>
> >>>On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote:
> >>>
> I've fixed this for drivers that use t_dd_triemit.h -- cur
Leif Delgass wrote:
> On Wed, 17 Jul 2002, Leif Delgass wrote:
>
>
>>On 17 Jul 2002, Michel Dänzer wrote:
>>
>>
>>>On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote:
>>>
I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon
and r200.
>>>Great job! The clippin
On Wed, 17 Jul 2002, Leif Delgass wrote:
> On 17 Jul 2002, Michel Dänzer wrote:
>
> > On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote:
> > > I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon
> > > and r200.
> >
> > Great job! The clipping problems I originally repo
On 17 Jul 2002, Michel Dänzer wrote:
> On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote:
> > I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon
> > and r200.
>
> Great job! The clipping problems I originally reported with the
> xscreensaver gears hack and fsv are fixe
On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote:
> I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon
> and r200.
Great job! The clipping problems I originally reported with the
xscreensaver gears hack and fsv are fixed.
--
Earthling Michel Dänzer (MrCooper)/ Debia
Michel Dänzer wrote:
> On Tue, 2002-07-16 at 20:17, Leif Delgass wrote:
>
>>On Tue, 16 Jul 2002, Keith Whitwell wrote:
>>
>>
Well, it's not high on my list. I don't think flat-shading is used that
often, and the changes don't have any effect on smooth shading. Actually,
it _elimin
On Wed, 17 Jul 2002, Leif Delgass wrote:
> On 17 Jul 2002, Michel Dänzer wrote:
>
> > On Tue, 2002-07-16 at 20:17, Leif Delgass wrote:
> > > On Tue, 16 Jul 2002, Keith Whitwell wrote:
> > >
> > > > > Well, it's not high on my list. I don't think flat-shading is used that
> > > > > often, and
On 17 Jul 2002, Michel Dänzer wrote:
> On Tue, 2002-07-16 at 20:17, Leif Delgass wrote:
> > On Tue, 16 Jul 2002, Keith Whitwell wrote:
> >
> > > > Well, it's not high on my list. I don't think flat-shading is used that
> > > > often, and the changes don't have any effect on smooth shading. Ac
On Tue, 2002-07-16 at 20:17, Leif Delgass wrote:
> On Tue, 16 Jul 2002, Keith Whitwell wrote:
>
> > > Well, it's not high on my list. I don't think flat-shading is used that
> > > often, and the changes don't have any effect on smooth shading. Actually,
> > > it _eliminates_ some saves/restor
Thanks for the snapshots Leif. For what you've shown me it seems that
the problem lives in TAG(interp) of mach64_native_vbtmp.h.
Unfortunetaly I haven't been able to do much testing yet, because after
updating my local CVS tree with the recent changes I was forced to recompile
the whole tree aga
I saw a similar problem in torcs. First I thought it was just a problem
with too little z-buffer accuracy. But when you look closely you see
that the polygon is too bright.
http://www.dd.chalmers.se/~kuhlfeli/torcsbug.jpg
On Mon, 15 Jul 2002 19:08:29 -0400 (EDT)
Leif Delgass <[EMAIL PROTECTED]>
The problem only appears when the procedural texture in the center of the
octagon is clipped by the window edge. Here's a shot of it unclipped:
http://retinalburn.net/linux/q3a-unclipped.jpg
So far, I've only noticed this on a few of the procedural textures that
rotate and/or stretch. This one
I forgot to mention that commenting out the fallback primitive functions
didn't have an effect.
On Mon, 15 Jul 2002, Leif Delgass wrote:
> Here's a couple screenshots of the multitexture bug in quake3 lightmap
> mode (two slightly different angles):
>
> http://retinalburn.net/linux/q3a-bug1.j
On Fri, 21 Jun 2002, Stefan Lange wrote:
> >Another question. I am using the Gatos driver for hardware accelerated
> >DVD watching. Can I use them together with the DRI Mach64 drivers?
> >
>
> I doubt that mixing these drivers will work, because gatos uses its own
> drm-module (correct me if I'
>
>Another question. I am using the Gatos driver for hardware accelerated
>DVD watching. Can I use them together with the DRI Mach64 drivers?
>
I doubt that mixing these drivers will work, because gatos uses its own
drm-module (correct me if I'm wrong). You'd probably have to merge both
codeba
Also you might want to know that I had problems getting the wrong kernel
headers under woody. It seams that 'as explained in the docs for
kernel-header-*' the debian headers may not be the same as the kernel headers.
If you compile a kernel module ought side the kernel tree it's doomed to get
th
Hello,
> I just tried to compile the newest mach64-0-0-4 branch to do some
> tests and got the following error:
>
> make[10]: Entering directory
>
>`/usr/local/src/DRI-CVS/build/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel'
> === KERNEL HEADERS IN /lib/modules/2.4.18/build/include
>There are some problems remaining on the DMA which could affect
>certain slower machines. Could you tell me what's your processor
>and its speed? Also check if there is any message in
>/var/log/messages. Just to be sure...
The CPU is Celeron 433 mhz.
Latest message was: Jun 15 08:35:41 fede k
On 2002.06.01 23:49 Leif Delgass wrote:
> ...
>
> I found and fixed this problem (I was using ring.tail to set the offset
> for buffer "aging" before it was incremented).
>
> ...
>
> I've cleaned this up a bit and done the work in COMMIT_RING.
>
> ...
>
> OK, I'm still not sure if I have this
On Sat, 1 Jun 2002, Leif Delgass wrote:
> the ring_wait is really not necessary, since 128 16kB buffers can use a
> max of 512 of the 1024 descriptors. We'd need 4MB of buffers to fill
> the ring.
On second thought, this is only true as long as we're not reusing buffers.
If we reuse buffers f
On Fri, 31 May 2002, José Fonseca wrote:
> On 2002.05.31 02:53 Leif Delgass wrote:
> > On Thu, 30 May 2002, José Fonseca wrote:
> >
> > I've fixed one bug already that was related to the ring tail being left
> > pre-incremented (the table_end I had before wasn't). Some of my problems
> > were r
On 2002.05.31 02:53 Leif Delgass wrote:
> On Thu, 30 May 2002, José Fonseca wrote:
>
> > Leif,
> >
> > On 2002.05.30 02:02 José Fonseca wrote:
> > > ... Tomorrow I'll take a look more carefully to see if I find
> anything
> > > suspicious. ...
> >
> > I've been analyzing the diff very carefully a
On Thu, 30 May 2002, José Fonseca wrote:
> Leif,
>
> On 2002.05.30 02:02 José Fonseca wrote:
> > ... Tomorrow I'll take a look more carefully to see if I find anything
> > suspicious. ...
>
> I've been analyzing the diff very carefully and what I've found so far are
> just some details which
Leif,
On 2002.05.30 02:02 José Fonseca wrote:
> ... Tomorrow I'll take a look more carefully to see if I find anything
> suspicious. ...
I've been analyzing the diff very carefully and what I've found so far are
just some details which can be taken care later (i.e., no bugs sorry) :
- This co
On 2002.05.30 01:13 Leif Delgass wrote:
> Jose,
>
> It's taking me a little longer than expected to finish the changes I
> mentioned. I'm trying to set this up so that it will be possible to test
> emitting buffers to the ring as they come in, but keep the original code
> in place, while sharing
On Thu, 23 May 2002 23:05:32 +0100
José Fonseca <[EMAIL PROTECTED]> wrote:
> On 2002.05.23 22:37 Leif Delgass wrote:
> > I've committed code to read BM_GUI_TABLE to reclaim processed buffers and
[...]
> > Monday the 20th but after Saturday the 18th, could you test to see if
> > this
> > happens?
On 2002.05.23 22:37 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
> disabled
> saving/restoring the pattern registers in the DDX and moved the wait for
> idle to the XAA Sync. Thi
Hi all
So, I took the first snapshot with textures - and ready to say something
good. Well, DRI now works even in 1280x1024 - great thanks to Leif and
others. At least I don't have to modify XF86Config every time...
1. glxinfo - OK, usual report.
2 glxgears does not show me any real difference
Leif,
On 2002.05.18 16:59 Leif Delgass wrote:
> ...
>
> I was just thinking that we could replace buffer aging with a check of
> BM_GUI_TABLE in freelist_get when searching the pending list, similar to
> what I'm doing with the dispatch. Since we know the physical address of
> each buffer, we c
On Sat, 18 May 2002, José Fonseca wrote:
> On 2002.05.18 10:33 Leif Delgass wrote:
> > OK, I finally committed my changes thus far as a checkpoint. I'm reading
> > BM_GUI_TABLE in the dispatch routine to see when we hit the hardware
> > pointer and wait once we reach it. So the dispatch is trea
On 2002.05.18 10:33 Leif Delgass wrote:
> OK, I finally committed my changes thus far as a checkpoint. I'm reading
> BM_GUI_TABLE in the dispatch routine to see when we hit the hardware
> pointer and wait once we reach it. So the dispatch is treating the
> descriptor table as a ring, and it help
On Wednesday 15 May 2002 06:51 am, Leif Delgass wrote:
> I'm getting close to committing this now. I got gui-master blits working,
> and pseudo-DMA is stable. Actually, the pseudo-DMA is probably faster
> without blits, but I'm hoping that it will help with DMA. The DMA is
> still prone to loc
> Leif, to be able to do a) I would like to base on the buffer aging code
> you have already written. There is no need for commiting anything as I
> don't want to update my tree now - could you just send me a diff of your
> current tree as is so that I can see how you did?
I'm getting close to
> fixing this :) Anyway, you should not expect 2D + 3D acceleration too
> soon.
OK. At least - thanks for explanation.
> problems right now (especially on the mach64 branch :).
:)) I see. It makes sense.
> I solved both the resolution and 2d acceleration problems for me by
> having two X servers
On 02 May 2002 23:19:10 +0100
"Sergey V. Udaltsov" <[EMAIL PROTECTED]> wrote:
> BTW, it was mentioned it was easy to enable 2D acceleration back. Is it
> true? Can it be done in snapshots (by checking this illustrious
> pATI->directRenderingEnabled). So people could use snapshot drivers in
> ever
> Yes, that's the goal. "Synchronous" DMA means that we wait for the card
> to idle after submitting each DMA pass, rather than going on to do other
> things and polling or handling interrupts to check for completion of the
> DMA transfer. Synchronous operation isn't meant to be fast, it's just
On 2 May 2002, Sergey V. Udaltsov wrote:
> Hi
>
> > Whoops. The oops is my fault, it's a bug in _cleanup_dma. It's fixed in
> > CVS now. Just update and rebuild and install the kernel module. This is
> > not related to your original problem though, I'm not sure what would be
> > causing a
Hi
> Whoops. The oops is my fault, it's a bug in _cleanup_dma. It's fixed in
> CVS now. Just update and rebuild and install the kernel module. This is
> not related to your original problem though, I'm not sure what would be
> causing a lockup on vt switches if no GL contexts are running.
On Thu, May 02, 2002 at 06:34:11AM -0400, Mike A. Harris wrote:
> >mtrr: Serverworks LE detected. Write-combining disabled.
>^^
> Ick. Problem #1
Yeah, I suspected as much. This damned computer has given me quite a bit
of trouble in the details.
Yup.
> unfortunately. Ser
On Wed, 1 May 2002, Kees Cook wrote:
>I've finally had a chance to upgrade to XFree86 4.2.0, and am trying out
>the bleeding edge builds for mach64. :)
>
>Quick version: it doesn't work.
>
>Long version: I think I have an AGP problem.
>
>glxinfo reports that direct rendering is off.
>the mach64
Hi
> Whoops. The oops is my fault, it's a bug in _cleanup_dma. It's fixed in
> CVS now. Just update and rebuild and install the kernel module. This is
> not related to your original problem though, I'm not sure what would be
> causing a lockup on vt switches if no GL contexts are running.
On 1 May 2002, Sergey V. Udaltsov wrote:
> Hi
>
> > Do you use some framebuffer device?
> To the best of my knowledge - no.
>
> > You can start to give us the last lines of /var/log/messages, as I think
> > that there should be a kernel oops in there. The XFree86.log may be
> > interesting to
Hi
> Do you use some framebuffer device?
To the best of my knowledge - no.
> You can start to give us the last lines of /var/log/messages, as I think
> that there should be a kernel oops in there. The XFree86.log may be
> interesting too.
YESS! There is OOPS. See attached.
Cheers,
Sergey
M
On 2002.04.30 22:33 Sergey V. Udaltsov wrote:
> Hi
>
> I cleaned up all modules and run 0-0-4 from clean state - still same
> lockup on X termination. Actully, I get the lockup not in termination
> but in attempts to switch to any textual console.:(
Do you use some framebuffer device?
>
> > Th
Hi
I cleaned up all modules and run 0-0-4 from clean state - still same
lockup on X termination. Actully, I get the lockup not in termination
but in attempts to switch to any textual console.:(
> The reason is that I've changed the dripkg/install scripts sometime, and I
Could you please give me
On Tue, 30 Apr 2002, José Fonseca wrote:
> On 2002.04.30 10:54 Sergey V. Udaltsov wrote:
> > > No. There isn't any yet. But we can arrange to something be printed
> > on
> > > the system log when the DMA is enabled on runtime.
> > That would be nice. Also, Leif offered to turn DMA on if bus mas
> In the previous 0-0-3 branch we almost never messed with the DRM, so it
> was binary compatible between all snapshots. Now is exactly the opposite.
> Nevertheless you shouldn't need to stop X if you're running your distro X.
> You need only if you are running X from a mach64 branch, because i
On 2002.04.30 10:54 Sergey V. Udaltsov wrote:
> > It seems that the mach64 kernel moduled wasn't replaced from memory,
> > causing a kernel oops. Usually you need to run install.sh without X
> > running (I usually do init 3).
> Well, at least with 0-0-3 I managed to do in without stopping X. Just
> It seems that the mach64 kernel moduled wasn't replaced from memory,
> causing a kernel oops. Usually you need to run install.sh without X
> running (I usually do init 3).
Well, at least with 0-0-3 I managed to do in without stopping X. Just
"install.sh" and restarting X was enough. OK, if you
On 2002.04.30 09:38 Sergey V. Udaltsov wrote:
> > From this moment the mach64 binary snapshots in
> > http://dri.sourceforge.net/snapshots/bleeding-edge/ are taken from the
> > 0-0-4 branch.
> Thanks. Just tried. Well, it seems 0-0-4 has long way to go:)
> First, I just run "install.sh" and resta
> From this moment the mach64 binary snapshots in
> http://dri.sourceforge.net/snapshots/bleeding-edge/ are taken from the
> 0-0-4 branch.
Thanks. Just tried. Well, it seems 0-0-4 has long way to go:)
First, I just run "install.sh" and restarted X. I got segmentation fault
on glxinfo - after di
On 2002.04.29 20:49 Leif Delgass wrote:
> On Mon, 29 Apr 2002, José Fonseca wrote:
> > ...
> > From this moment the mach64 binary snapshots in
> > http://dri.sourceforge.net/snapshots/bleeding-edge/ are taken from the
> > 0-0-4 branch.
> >
> > Note that the DMA is disabled by default, and there w
On Mon, 29 Apr 2002, José Fonseca wrote:
> On 2002.04.29 16:14 Sergey V. Udaltsov wrote:
> > Actually, Leif is right. DRI really works on 1024x768 but... very slow
> > (thanks to PIO?). My Rage Mobility cannot run Counter-Strike properly
> > (the game is unplayable in this mode). In 800x600 it is
On Sat, 2002-04-27 at 21:24, Leif Delgass wrote:
>
> I've just commited the endianess conversion for register reads/writes to
> the branch, so you won't have to keep applying Michel's patch. I used
> le32_to_cpu/cpu_to_le32 since that's what the other drivers use and I
> was getting a compiler w
On Sat, 27 Apr 2002, Peter Andersson wrote:
> > Hi,
> >
> > I cvs updated mach64-0-0-4-branch last night and recompiled (previous
> > update was on sunday). Right after starting glxgears the screen switched
> > off (like with xset dpms force off) and the machine hung. The sysrq keys
> > did
> Hi,
>
> I cvs updated mach64-0-0-4-branch last night and recompiled (previous
> update was on sunday). Right after starting glxgears the screen switched
> off (like with xset dpms force off) and the machine hung. The sysrq keys
> didn't work.
>
> Maybe Peter Anderson's problems are not P
On 2002.04.21 21:13 Leif Delgass wrote:
> On Sun, 21 Apr 2002, Leif Delgass wrote:
> > ...
> >
> > Yes, I think waiting for idle here is overkill. According to the
> > programmer's guide, you only need to wait for idle when reading a
> register
> > or bit field updated by the draw engine, or when
On Sun, 21 Apr 2002, José Fonseca wrote:
> On 2002.04.21 19:40 Leif Delgass wrote:
> > On Sun, 21 Apr 2002, José Fonseca wrote:
> >
> > > > We just need to add the fifo check now.
> > >
> > > I've just add it but it makes gears drop from 222 to 185 fps in my
> > system.
> > > I don't know if thi
On 2002.04.21 19:40 Leif Delgass wrote:
> On Sun, 21 Apr 2002, José Fonseca wrote:
>
> > > We just need to add the fifo check now.
> >
> > I've just add it but it makes gears drop from 222 to 185 fps in my
> system.
> > I don't know if this is caused by droped triangles when there is no
> FIFO
>
On Sun, 21 Apr 2002, José Fonseca wrote:
> > We just need to add the fifo check now.
>
> I've just add it but it makes gears drop from 222 to 185 fps in my system.
> I don't know if this is caused by droped triangles when there is no FIFO
> check, or if the FIFO check makes a big overload. So
On 2002.04.21 07:56 Leif Delgass wrote:
> 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 memo
> I found that calls to TexParameter were not setting the texture wrapping
> and texture filter in some cases (where the driver private texture object
> struct had not already been allocated). This is now fixed and solves the
> following bugs:
Well done! It seems armagetron is really fixed.
S
Leif Delgass
> http://www.retinalburn.net
>
> -- Forwarded message --
> Date: Thu, 7 Mar 2002 22:40:14 -0500 (EST)
> From: Leif Delgass <[EMAIL PROTECTED]>
> To: José Fonseca <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: [Dri-devel] Re: mach6
1 - 100 of 115 matches
Mail list logo
