There are three pools of DMA memory, low (below 16MB?), normal, high (64b). If
the kernel can't identify your hardware it returns a buffer from the low pool
because it assumes it is an ISA device. With the new code the kernel can look at
the PCI capabilities of the device and the device says its su
The new PCI probing code seems to break the mach64 driver, it looks like
the pci_alloc_consistent is returning a different buffer when the driver
uses the new probing scheme, this is messy to debug for me until I get
another machine I can connect to my laptop to debug it...
If i make the system f
I finally got to look at this patch, the patch puts the options in
atioption.c in a different order than in atioption.h
this stops tv out from working properly with the previous patch, there is
an updated patch at
http://freedesktop.org/~airlied/mach64-tvout-070504.diff
it still doesn't look gr
Thanks fot your input. I have now built a new xserver and the drm kernel
modules. glxgears runs at approx 160 fps for 1280x1024x16, with mmio and
agp 2x. This seems a little slow, how much is speed improved by
asynchronous or synchronous DMA? Which one is preferred?
A note on the build process of
On Tue, 27 Apr 2004 01:12:27 +0100 (IST)
Dave Airlie <[EMAIL PROTECTED]> wrote:
> > cvs -d:pserver:[EMAIL PROTECTED]:/cvs/mesa co -D 2004-03-28 Mesa
> >
> > Besides that one bit it should build fine.
> >
> > /me pokes the mach64 maintainers. ISTR some discussion about merging mach64
> > anyway, e
On Monday 26 April 2004 20:18, Alex Deucher wrote:
> > So it's been merged then? As in, I should go update the wiki so we
> > don't get this complaint in the future?
>
> Already done.
You're my hero.
- ajax
---
This SF.net email is sponsored
--- Adam Jackson <[EMAIL PROTECTED]> wrote:
> On Monday 26 April 2004 17:59, Felix Kühling wrote:
> > The mach64 driver has moved to the trunk. Try building it there.
> The
> > branch is broken for quite a while now. It won't be fixed.
>
> So it's been merged then? As in, I should go update the
On Monday 26 April 2004 17:59, Felix Kühling wrote:
> The mach64 driver has moved to the trunk. Try building it there. The
> branch is broken for quite a while now. It won't be fixed.
So it's been merged then? As in, I should go update the wiki so we don't get
this complaint in the future?
- aj
On Tue, Apr 27, 2004 at 12:41:06AM +0200, Svante Signell wrote:
> Hello,
>
> I made a fresh checkout of the mach64-0-0-7 cvs branch together with the
> Mesa and drm modules according to the Building and ATIMach64 web pages.
> However the build fails. The tail of world.log is as follows:
If it was
> cvs -d:pserver:[EMAIL PROTECTED]:/cvs/mesa co -D 2004-03-28 Mesa
>
> Besides that one bit it should build fine.
>
> /me pokes the mach64 maintainers. ISTR some discussion about merging mach64
> anyway, even though it's insecure, perhaps with Big Fat Warning Signs or
> defaulting to mmio mode (wh
On Monday 26 April 2004 17:41, Svante Signell wrote:
> Hello,
>
> I made a fresh checkout of the mach64-0-0-7 cvs branch together with the
> Mesa and drm modules according to the Building and ATIMach64 web pages.
> However the build fails. The tail of world.log is as follows:
> ...
mach64-0-0-7 ne
On Tue, 27 Apr 2004 00:41:06 +0200
Svante Signell <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I made a fresh checkout of the mach64-0-0-7 cvs branch together with the
> Mesa and drm modules according to the Building and ATIMach64 web pages.
> However the build fails. The tail of world.log is as follo
Hello,
I made a fresh checkout of the mach64-0-0-7 cvs branch together with the
Mesa and drm modules according to the Building and ATIMach64 web pages.
However the build fails. The tail of world.log is as follows:
...
ln -s /usr/CVS/dri-cvs/Mesa/src/mesa/main/accum.h accum.h
make[5]: *** No rule
He did respond you should be able to find his comments on the user list.
IIRC He said that xv != tvout and that xv was in 0-0-7 and this seams to
be the case. I think there is some dependant code missing from the tvout
patch that also needs to be brought over.
I used /linux/tvout-patches/mach64-
On Saturday 27 March 2004 09:55 pm, you wrote:
> I'm glad too see it has worked for you. I have had problems with my
> patch, may I ask how you use it and what you do to make it work? What I
> did was use atitvout while in X and this worked but only if I didn't do
> any mode changes or VT switche
I'm glad too see it has worked for you. I have had problems with my
patch, may I ask how you use it and what you do to make it work? What I
did was use atitvout while in X and this worked but only if I didn't do
any mode changes or VT switches. Withought the patch atitvout bails
saying it can do
On Tuesday 23 March 2004 05:16 am, Mike Mestnik wrote:
> This is nothing more than a HUNK fixed copy of the TVOut patch found on
> leif's linux page. With this patch the TVOut and other related options
> are evaluated and it is posible to use atitvout while in X. However I
> notesed some problems
This is nothing more than a HUNK fixed copy of the TVOut patch found on
leif's linux page. With this patch the TVOut and other related options
are evaluated and it is posible to use atitvout while in X. However I
notesed some problems with this patch that only a reboot would fix. There
was corup
I've checked in the changes for the mach64 to use the new interface, I
haven't turned it on as I had to change some stuff I'm unsure off...
I've had to set
modes->drawableType = GLX_WINDOW_BIT | GLX_PIXMAP_BIT;
the r200 just had the GLX_WINDOW_BIT ..
Apart from that, 24-bit needs looking at..
I've fixed up the mach64-0-0-7-branch it should build and run again..
haven't tested it yet, no enough disk space on my laptop.. tomorrow
hopefully..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG perso
I've been reading the state and dma code. I have some questions.
> The intention is to instead use
> a pool of private buffers not mapped to userspace (rather than continually
> unmapping and mapping client buffers). The part that is missing (and
> preventing us from merging with the trunk) is
Leif Delgass <[EMAIL PROTECTED]> writes:
[snip]
> > but glxgears only gets about 115.3 frames:
> >
> > # glxgears -display :1 &
> > [1] 6381
> > 577 frames in 5.0 seconds = 115.400 FPS
> > 576 frames in 5.0 seconds = 115.200 FPS
> > 576 frames in 5.0 seconds = 115.200 FPS
> >
On 8 Mar 2004 [EMAIL PROTECTED] wrote:
> Leif Delgass <[EMAIL PROTECTED]> writes:
>
> > I forgot to bring in the drm_linux_list.h for bsd that was added on
> > the mach64-0-0-6-branch. I just added it and it is included from drmP.h.
> > With any luck that should fix the compile errors in the
Leif Delgass <[EMAIL PROTECTED]> writes:
> I forgot to bring in the drm_linux_list.h for bsd that was added on
> the mach64-0-0-6-branch. I just added it and it is included from drmP.h.
> With any luck that should fix the compile errors in the kernel module.
ok, thank you again, that does fix
I forgot to bring in the drm_linux_list.h for bsd that was added on
the mach64-0-0-6-branch. I just added it and it is included from drmP.h.
With any luck that should fix the compile errors in the kernel module.
Leif
On 7 Mar 2004 [EMAIL PROTECTED] wrote:
> Thank you for your time and your r
Thank you for your time and your replies.
Dave Airlie <[EMAIL PROTECTED]> writes:
> >
> > Thank you! It dies in xc/programs/Xserver/GL/mesa/X/xf86glx.c :
> >
> > xf86glx.c: In function `__MESA_setVisualConfigs':
> > xf86glx.c:481: error: `kernel8' undeclared (first use in this function)
> > xf86g
>
> Thank you! It dies in xc/programs/Xserver/GL/mesa/X/xf86glx.c :
>
> xf86glx.c: In function `__MESA_setVisualConfigs':
> xf86glx.c:481: error: `kernel8' undeclared (first use in this function)
> xf86glx.c:481: error: (Each undeclared identifier is reported only once
> xf86glx.c:481: error: for e
Leif Delgass <[EMAIL PROTECTED]> writes:
> On Sun, 7 Mar 2004, Dave Airlie wrote:
>
> >
> > > What is the status of mach64 dri support on freebsd 5.2 ?
> >
> > nobody has tested it for a while, so I say it suffers from bitrot...
> >
> > mach64-0-0-7 is the DRI branch to go with, and Mesa head,
On Sun, 7 Mar 2004, Dave Airlie wrote:
>
> > What is the status of mach64 dri support on freebsd 5.2 ?
>
> nobody has tested it for a while, so I say it suffers from bitrot...
>
> mach64-0-0-7 is the DRI branch to go with, and Mesa head, the code should
> all be there, just needing some updates
> What is the status of mach64 dri support on freebsd 5.2 ?
nobody has tested it for a while, so I say it suffers from bitrot...
mach64-0-0-7 is the DRI branch to go with, and Mesa head, the code should
all be there, just needing some updates for FreeBSD 5.2,
I'll look into it over the next whi
What is the status of mach64 dri support on freebsd 5.2 ?
I tried to checkout from cvs and build the mach64-0-0-7, mach64-0-0-6,
and current mesa trees. mach64-0-0-7 builds, but does not support dri
on freebsd. mach64-0-0-6 seems to have the requisite code for
supporting dri on freebsd, but does
Ok, so I'l build X at 64 bits as having a 32bit kmod would proble mean I'd
need a 32bit kernel. I have stoped working on this cause I can't build
the DRI tree. I have a working copy of Xfree86(provided by debian) so it
must be posible to build xfree86. Could I get a list of all the files
that I'
Mike Mestnik wrote:
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
On Mon, 2004-02-16 at 21:14, Mike Mestnik wrote:
[...] Other than that and endianess and byte size issues is there any
thing else that might not work?
FWIW, people have been running Mach64 DRI on PPC for a while (only with
MMIO tho
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Mon, 2004-02-16 at 21:14, Mike Mestnik wrote:
> > [...] Other than that and endianess and byte size issues is there any
> > thing else that might not work?
>
> FWIW, people have been running Mach64 DRI on PPC for a while (only with
> MMIO though,
On Mon, 2004-02-16 at 21:14, Mike Mestnik wrote:
> [...] Other than that and endianess and byte size issues is there any
> thing else that might not work?
FWIW, people have been running Mach64 DRI on PPC for a while (only with
MMIO though, not DMA), so endianness shouldn't be a problem.
--
Eart
Mike Mestnik wrote:
I have a UltraSparc5 with an onboard Rage3D, workes with the mach64
driver. There are some problems with the kernel and PCI domains, but I
got thoes cleared out. There is still a problem that the chip is stuck in
whaterver mode is set by openboot(the bios), but I can change t
I have a UltraSparc5 with an onboard Rage3D, workes with the mach64
driver. There are some problems with the kernel and PCI domains, but I
got thoes cleared out. There is still a problem that the chip is stuck in
whaterver mode is set by openboot(the bios), but I can change the bit
depth. Other
>
> As for the glxgears thing, I got some output from it when I ran it with gdb
> from an ssh session:
>
> glxgears: vblank.c:338: driWaitForVBlank: Assertion `interval != (unsigned)-1'
> failed.
try updating from CVS both trees, I fixed this I just can't remember which
tree it went into :-) I th
On Sat, 14 Feb 2004 13:27:03 -0800
James Jones <[EMAIL PROTECTED]> wrote:
> Yeah, got a couple things here.
>
> First, the dmesg. the dma test is failing. It worked fine on the old branch.
> This of course happens when starting X. Here's a dmesg clip:
[snip]
>
> As for the glxgears thing, I
Yeah, got a couple things here.
First, the dmesg. the dma test is failing. It worked fine on the old branch.
This of course happens when starting X. Here's a dmesg clip:
--
agpgart: Putting AGP V2 device at :00:00.0 into 2x mode
agpgart: Putting AGP V2 device a
>
> -X starts up fine now, window manager comes up, etc.
> -xvinfo reports xv working, playing mpeg with mplayer confirms this.
> -glxinfo reports correct info
> -glxgears locks up. Rest of X is locked, but mouse can be moved around. I
> can ssh in, but can't seem to kill the X server. A reboot
Dave,
Here's a test report:
-X starts up fine now, window manager comes up, etc.
-xvinfo reports xv working, playing mpeg with mplayer confirms this.
-glxinfo reports correct info
-glxgears locks up. Rest of X is locked, but mouse can be moved around. I
can ssh in, but can't seem to kill the X
> When I updated and using the XFree86 from the snapshot directory, I was
> missing an I2C symbol, the ati driver in DRI CVS seems to need a newer
> version of libi2c.a, mine was from Fedora Core 1...
>
> The 2d driver builds now but 3d seems to crap it out .. it'll be a day or
> two until I figure
Okay I wasn't as complete as I thought, the Mesa and the DRM I was using
were from the branch but I never updated my 2d driver, it was still the
old branch... so then I noticed something else which might cause problems
with the snapshots
When I updated and using the XFree86 from the snapshot
On Fri, Feb 13, 2004 at 01:31:59AM +, Dave Airlie wrote:
>
>
> > So should we just work on getting everything running on newtree then and not
> > worry about the security issues for now?
> >
>
> Sounds good to me, I'll look into disabling DMA by default, if we have the
> option we are okay,
Dave Airlie wrote:
So should we just work on getting everything running on newtree then and not
worry about the security issues for now?
Sounds good to me, I'll look into disabling DMA by default, if we have the
option we are okay, my only issue is though should there be something in
the DRM tha
> So should we just work on getting everything running on newtree then and not
> worry about the security issues for now?
>
Sounds good to me, I'll look into disabling DMA by default, if we have the
option we are okay, my only issue is though should there be something in
the DRM that it affects?
ot; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; "Dave Airlie" <[EMAIL PROTECTED]>
Sent: Thursday, February 12, 2004 10:53 AM
Subject: Re: [Dri-devel] mach64 and new tree
> José Fonseca wrote:
> > If it's OK to sacrifice some speed in order to make the ma
José Fonseca wrote:
If it's OK to sacrifice some speed in order to make the mach64 driver
secure and elegible to go the the trubk then there is quite a simple
solution: disable DMA by default (using the MMIO pseudo-DMA). Users still
have the option to force DMA in XF86Config if they so wish.
I th
If it's OK to sacrifice some speed in order to make the mach64 driver
secure and elegible to go the the trubk then there is quite a simple
solution: disable DMA by default (using the MMIO pseudo-DMA). Users still
have the option to force DMA in XF86Config if they so wish.
I think this would make
On Thu, 12 Feb 2004 14:01:01 +0100
Felix Kühling <[EMAIL PROTECTED]> wrote:
> On Thu, 12 Feb 2004 10:17:11 + (GMT)
> Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> > >
> > > While I'm at it (see driinterface-0-0-3-branch mails) I could update the
> > > snapshot scripts to build mach64-0-0-7-branc
On Thu, 12 Feb 2004 10:17:11 + (GMT)
Dave Airlie <[EMAIL PROTECTED]> wrote:
> >
> > While I'm at it (see driinterface-0-0-3-branch mails) I could update the
> > snapshot scripts to build mach64-0-0-7-branch snapshots.
>
> please do it, I'm sure a bit more testing would help a lot ...
Done. I
> It's great that you are picking this up. It's been on my todo list for a
> long while but free time is nonexistant for me these days (full time grad
> student + half time research assistant = - half time DRI developer?!)
>
well a few things came together, I got specs at work for the rage pro t
>
> While I'm at it (see driinterface-0-0-3-branch mails) I could update the
> snapshot scripts to build mach64-0-0-7-branch snapshots.
please do it, I'm sure a bit more testing would help a lot ...
Thanks,
Dave.
>
> >
> > Dave.
> >
>
> Felix
>
>
>
On Thu, 12 Feb 2004 06:42:29 + (GMT)
Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> Okay the last few fixes make tuxracer and glxgears work again, so the new
> branch should be as useable as the old one, I think there are still a few
> cleanups in the native vertex code (using macros for a few th
On Thu, 12 Feb 2004, Dave Airlie wrote:
>
> Okay the last few fixes make tuxracer and glxgears work again, so the new
> branch should be as useable as the old one, I think there are still a few
> cleanups in the native vertex code (using macros for a few things), and
> then a texmem converison mi
Okay the last few fixes make tuxracer and glxgears work again, so the new
branch should be as useable as the old one, I think there are still a few
cleanups in the native vertex code (using macros for a few things), and
then a texmem converison might be in order.
But it's good enough for me t
Okay everything should be checked in and building, it doesn't work yet
though :-)
I'll hopefully get time over the next few days to hack on it again, I'm in
the middle of moving apartments and work only pay me the odd hack to
i810/radeon stuff, the mach64 is personal (as my laptop has it), if I g
Dave,
I was the one that brought this up. I have a little time (a few hours a
week only) to work on it, and since no one else seemed to care I was
going to tackle this very slowly. I was going to work on the DRM
insecurities once I dug up the old conversations with Jose detailing
what needed
Okay I've checked in the DRM and Xserver changes to the above branch, I've
added the PCI ids I think are correct for the chip variations,
I'll hopefully get around to testing it in the next couple of days, (just
have to drag out the laptop :-)
If anyone else has a chance feel free to give it
> > tomorrow (I'm GMT+10, should probably use .au a/c :-)
> >
> > I'll work on the XFree bits and the DRM should be similiar enough soon..
>
> I think it should be fine to go in at Mesa head.
Okay what about the DRI tree bits? DRM and changes to ATI driver?,
should I go with mach64-0-0-7 or shoul
Dave Airlie wrote:
track him down at some point, but for now I'd like to bring the current
branch up to the top of tree at least,
So should I use the mesa tip and start a new mach64 branch on the DRI tree
or should I make a branch on both trees?
oh yeah I'm unsure who brought it up on IRC so if you
> track him down at some point, but for now I'd like to bring the current
> branch up to the top of tree at least,
>
> So should I use the mesa tip and start a new mach64 branch on the DRI tree
> or should I make a branch on both trees?
>
> oh yeah I'm unsure who brought it up on IRC so if you are
I noticed it came up during the IRC meeting this week about moving the
mach64 up to the top of tree,
So how should this be done in terms of CVS, the mach64 driver as is
insecure, so I'd rather not put into an official tree until those issues
are sorted out, I know Jose has some ideas on these and
On Sun, 2003-12-07 at 18:43, Josà Fonseca wrote:
>
> On Thu, Dec 04, 2003 at 05:02:17PM -0500, Christopher Gleba wrote:
> >
> > It turns out that I mis-configured lilo and when I rebooted a kernel
> > with the software suspend patch was being booted rather then a clean one
> > as I had thought (
Chris,
On Thu, Dec 04, 2003 at 05:02:17PM -0500, Christopher Gleba wrote:
> Hello Jose,
>
> > It's very strange that this doesn't work. If you compile the driver
> > and the Xserver into /usr/X11R6-DRI/ and use that XFree86 server there
> > shouln't be any binary incompatabilities problems (whic
ROTECTED]
Subject: Re: [Dri-devel] mach64-0-0-6-branch dri bug report
Date: Thu, 04 Dec 2003 17:02:17 -0500
Hello Jose,
> It's very strange that this doesn't work. If you compile the driver
> and the Xserver into /usr/X11R6-DRI/ and use that XFree86 server there
> shouln&#x
just a few words for the future, nothing serious...
> -Original Message-
> From: Christopher Gleba [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 04, 2003 23:02
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Dri-devel] mach64-0-0-6-branch dri bug
Christopher,
On Tue, Dec 02, 2003 at 02:57:50PM -0500, Christopher Gleba wrote:
>
> Hello Jose,
>
> Thank you for the response.
>
> > Do you have a PCI card? If not make sure the agpgart kernel module is
> > loaded before the mach64 module, by adding
> >
> > pre-install mach64 modprobe -k ag
Forgot the attachment in the last post.
-Forwarded Message-
From: Christopher Gleba <[EMAIL PROTECTED]>
To: José Fonseca <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: [Dri-devel] mach64-0-0-6-branch dri bug report
Date: Tue, 02 Dec 2003 14:57:50 -0500
Hello Jose,
T
Hello Jose,
Thank you for the response.
> Do you have a PCI card? If not make sure the agpgart kernel module is
> loaded before the mach64 module, by adding
>
> pre-install mach64 modprobe -k agpgart
Yes, it is an AGP card:
lspci -vv:
01:00.0 VGA compatible controller: ATI Technologies Inc
Christopher,
On Mon, Dec 01, 2003 at 12:46:55AM -0500, Christopher Gleba wrote:
>
> Hello,
>
> I had been using the mach64-0-0-5-branch in
> linux for a while but recently I upgraded my
> install and thus gave a shot at the
> mach64-0-0-6-branch and encountered a problem.
> This report is b
Hello,
I had been using the mach64-0-0-5-branch in
linux for a while but recently I upgraded my
install and thus gave a shot at the
mach64-0-0-6-branch and encountered a problem.
This report is broken into sections:
1 - Problem description
2 - System information
3 - XF86Config-4
On Sat, 31 May 2003, Leif Delgass wrote:
> Here's some more info on HOSTDATA:
> In MMIO/pseudo-DMA mode, when we see a descriptor with BM_HOSTDATA as the
> GUI master target register (rather than BM_ADDR), we feed the blit data to
> the card through the HOST_DATA[0-15] registers, so it's still MMI
On Sat, 31 May 2003, Paul Mackerras wrote:
> José Fonseca writes:
>
> > On Wed, May 21, 2003 at 10:38:45PM +1000, Paul Mackerras wrote:
> > > * The hang always occurs within a mach64_dma_dispatch_vertex call for
> > > primitive 8 (MACH64_PRIM_QUAD_STRIP), at least with glxgears.
> >
> > glxgears
José Fonseca writes:
> On Wed, May 21, 2003 at 10:38:45PM +1000, Paul Mackerras wrote:
> > * The hang always occurs within a mach64_dma_dispatch_vertex call for
> > primitive 8 (MACH64_PRIM_QUAD_STRIP), at least with glxgears.
>
> glxgears only uses quads primitives, so the primitive is not relev
On Tue, 25 Mar 2003, Michael Thaler wrote:
> Hello,
>
> I just compiled and installed the latest linux developer kernel. I
> tried to install the Mach64 binary drivers from
> www.retinalburn.com. With kernel 2.4.20 it works fine for me, but with
> kernel 2.5.66 I get the following error message:
Hello,
I just compiled and installed the latest linux developer kernel. I
tried to install the Mach64 binary drivers from
www.retinalburn.com. With kernel 2.4.20 it works fine for me, but with
kernel 2.5.66 I get the following error message:
:/usr/local/src/dripkg# modprobe mach64
FATAL: Error in
Hello list, there seem to be 2 bugs with the mach64 driver (for
some time now, but they still appear with latest branch 0-0-5 with
XV/tvout patch from Leif).
- in Emilia Pinball (the problem was reported by someone in july but no
one answered), some textures don't appear right (they look quite
str
On 15 Feb 2003, Eric Anholt wrote:
> On Tue, 2003-02-11 at 20:11, Leif Delgass wrote:
> > I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been
> > updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've
> > updated the mach64 driver to Mesa 5 based on the chang
On Tue, 2003-02-11 at 20:11, Leif Delgass wrote:
> I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been
> updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've
> updated the mach64 driver to Mesa 5 based on the changes to the Rage 128
> driver. Testing hasn't
Leif Delgass wrote:
I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been
updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've
updated the mach64 driver to Mesa 5 based on the changes to the Rage 128
driver. Testing hasn't shown any problems so far.
I haven'
> [...] Since the GATOS head is now based
> on current XFree86 cvs, I may not have a new patch until 4.3.0 is released
> and changes get propagated back to the DRI and GATOS trees.
Could anyone tell me if I'll find recent GATOS stuff merged into the current
XFree86-4.3 pre-releases ? I did not fin
I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been
updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've
updated the mach64 driver to Mesa 5 based on the changes to the Rage 128
driver. Testing hasn't shown any problems so far.
I haven't adapted the mach64
On Thu, 6 Feb 2003 00:44:12 +0200
"Arkadi Shishlov" <[EMAIL PROTECTED]> wrote:
>
> Now I think it is texture alpha. Quite pointless to have RGBA texture
> without ability to use it alpha channel.
> http://idea.hosting.lv/a/tmp/quakeforge-mach64-blend.jpg
Hows Quakeforge comming, btw - it'd be ni
On Tue, Feb 04, 2003 at 09:51:30PM -0500, Leif Delgass wrote:
> On Wed, 5 Feb 2003, Arkadi Shishlov wrote:
> > What do you mean by aren't fully compliant? Final A = Fragment A or
> > Final A = Texture A? It looks like Fragment A..
>
> Yes, I think that's right. As an example, there's a texture in
On Mit, 2003-02-05 at 17:50, Albert Cohen wrote:
> (II) ATI(0): [drm] drmSetBusid failed (7, PCI:0:5:0), Permission denied
> (EE) ATI(0): [dri] DRIScreenInit Failed
This has been discussed several times here: you need to make sure the
DRM is built with the same compiler as the kernel.
--
Earth
First of all, congratulations for the new drivers for ATI Mach64 and
for the support of more and more video cards, even older ones...
Still, I could not successfully use DRM and 3D acceleration on my
AGP-disabled 4MB Mach64 card, using the Debian-package
xserver-xfree86-dri-mach64. Even in the 16b
On Wed, 5 Feb 2003, Arkadi Shishlov wrote:
> On Tue, Jan 28, 2003 at 11:01:53PM -0500, Leif Delgass wrote:
> > On Wed, 29 Jan 2003, Arkadi Shishlov wrote:
> > > - 'Texture environment modes: GL_BLEND is done in software..' - mean
> > > glTexEnv(GL_BLEND) is software. GL_DECAL is hw accelerated.
On Tue, Jan 28, 2003 at 11:01:53PM -0500, Leif Delgass wrote:
> On Wed, 29 Jan 2003, Arkadi Shishlov wrote:
> > - 'Texture environment modes: GL_BLEND is done in software..' - mean
> > glTexEnv(GL_BLEND) is software. GL_DECAL is hw accelerated.
> > GL_MODULATE with GL_LUMINANCE_ALPHA is softwar
> No they aren't supported in DRI. For existing apps, they would probably
Thanks for these very good explanation. My ergo: no use. So, it seems
Mach64 does not have any good usable compression technique.
Cheers,
--
Sergey
signature.asc
Description: This is a digitally signed message part
On 2 Feb 2003, Sergey V. Oudaltsov wrote:
> > According to the docs, mach64 implements 4:1 VQ de-compression, but
> > there's no other info. Rage 128 also has a VQ texture format bit,
> > according to the register header file. Sega dreamcast used a form of VQ
> > compression also, I think.
> So
> According to the docs, mach64 implements 4:1 VQ de-compression, but
> there's no other info. Rage 128 also has a VQ texture format bit,
> according to the register header file. Sega dreamcast used a form of VQ
> compression also, I think.
Sorry for my ignorance, are these compression methods s
According to the docs, mach64 implements 4:1 VQ de-compression, but
there's no other info. Rage 128 also has a VQ texture format bit,
according to the register header file. Sega dreamcast used a form of VQ
compression also, I think.
On Fri, 31 Jan 2003, Ian Romanick wrote:
> While I was search
While I was searching around the net for papers on texture memory
management, I came across some references to Talisman and DirectX 6.0
texture compression. It seems that the compression algorithm used is
called "TREC," which is short for "Texture and Rendering Compression."
http://www.ubicom.
On Tue, 28 Jan 2003, Leif Delgass wrote:
> > BTW, when particular operation is implemented in software but require some
> > on-screen content, driver copy already rendered chunk from framebuffer, pass
> > it to Mesa, then copy back?
>
> To be honest, I don't know the gory details of the Mesa soft
On Wed, 29 Jan 2003, Arkadi Shishlov wrote:
> Hi.
> I'm working on QuakeForge engine, and some things related to transparency
> (player damage blood) and 'dynamic lighting' (grenade explosion) are very
> slow. Quake3 runs faster in mean time.
Quake3 has some "hacks" built in to work around the ma
Hi.
I'm working on QuakeForge engine, and some things related to transparency
(player damage blood) and 'dynamic lighting' (grenade explosion) are very
slow. Quake3 runs faster in mean time.
I want to investigate problem further on Quake side, but I want to be sure
I understood mach64 limitation co
On Fri, 6 Dec 2002, Svante Signell wrote:
> Sorry for continuing this thread but I think there are some open issues:
>
> 1. There is a memory leak (or something similar) in the mach64 driver
>since consecutive calls to the Xv driver fails . (With a call to a
>GL application in between)
>
Sorry for continuing this thread but I think there are some open issues:
1. There is a memory leak (or something similar) in the mach64 driver
since consecutive calls to the Xv driver fails . (With a call to a
GL application in between)
2. Does the lack of feedback indicate that the issue i
1 - 100 of 746 matches
Mail list logo
