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
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
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
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, even though
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
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 follows:
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 needs a
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 (which is
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 wasn't
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?
-
--- 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 wiki so
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 by:
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 switches.
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
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
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
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
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 a
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 the
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 kernel
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
577 frames in
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 for
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, the code should
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 each
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)
xf86glx.c:481:
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
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
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
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
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
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.
--
--- 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, not DMA),
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
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
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 think
-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 is
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
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
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, my only
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
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 it
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 might
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 that
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 put a
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
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 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-branch snapshots.
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
[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 mach64 driver
secure and elegible to go the the trubk then there is quite a simple
solution: disable DMA
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? I
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
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
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
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
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
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 on
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 should I
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 (and I
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 (which I
-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't be any binary incompatabilities problems (which I
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 agpgart
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 report
Size: 220 kB
i
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 broken
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
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,
Thank you
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 relevant
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 only uses
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 MMIO.
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
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
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
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 changes to
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
[...] 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 find
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
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
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.
--
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 the
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 nice to
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 software.
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.
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
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
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.
Sorry for
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.
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
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
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
Leif Delgass writes:
On Thu, 28 Nov 2002, Svante Signell wrote:
Leif Delgass writes:
On Wed, 27 Nov 2002, Svante Signell wrote:
I have now tested at 1024x768, and everything works OK, but I think there is
memory not returned to the card in the 3D driver, see below.
On Thu, 28 Nov 2002, Svante Signell wrote:
Leif Delgass writes:
On Wed, 27 Nov 2002, Svante Signell wrote:
Leif Delgass writes:
Have you tried a lower resolution?
Not yet.
Try restarting X with 1024x768@16bpp for a while and see if you still have
the same problem.
Leif Delgass writes:
On Wed, 27 Nov 2002, Svante Signell wrote:
Leif Delgass writes:
Have you tried a lower resolution?
Not yet.
Try restarting X with 1024x768@16bpp for a while and see if you still have
the same problem.
I have now tested at 1024x768, and everything works
Leif Delgass writes:
Have you tried a lower resolution?
Not yet.
If it's some sort of memory leak, I'd
expect that you'd run into it eventually even at a lower resolution. If
it doesn't happen at lower resolutions, maybe you really just don't have
enough offscreen memory at 1280x1024.
On Wed, 27 Nov 2002, Svante Signell wrote:
Leif Delgass writes:
Have you tried a lower resolution?
Not yet.
Try restarting X with 1024x768@16bpp for a while and see if you still have
the same problem.
If it's some sort of memory leak, I'd
expect that you'd run into it eventually
Hello,
I have problems with the latest mach64 branch from dri-cvs. After a
successful view of an .avi clip next time the card memory does not
seem to be available, i.e. the card is left in a bad state? The only
way to rerun the application is to exit X and restart.
The example given below is
Have you tried a lower resolution? If it's some sort of memory leak, I'd
expect that you'd run into it eventually even at a lower resolution. If
it doesn't happen at lower resolutions, maybe you really just don't have
enough offscreen memory at 1280x1024. Also, did you run any GL apps
before
1 - 100 of 571 matches
Mail list logo
