From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [Dri-devel] Radeon 8500, what's the plan?
Date: Tue, 2 Oct 2001 17:19:53 -0400 (EDT)
Well, we (GATOS) do have the docs, under similar NDA. I believe PI/VA was
more doc-rich ;) But (looking in them) they
On Wed, 3 Oct 2001, David Johnson wrote:
There is some seriously proprietary stuff with idct that for legal
reasons ATI wouldn't want to expose.
That is one of the most ridiculous statements I have heard. Substitute
some equivalent terms in there:
There is some seriously proprietary stuff
** well, let's see how many flames I can generate with this.. **
I'll see if I can generate more.
One point that I think has been missed is that while Open Source in
general (and Linux, in particular) improves a lot user and developer
experience, the binaries get even less value than in
Jeffrey W. Baker wrote:
On Wed, 3 Oct 2001, David Johnson wrote:
There is some seriously proprietary stuff with idct that for legal
reasons ATI wouldn't want to expose.
That is one of the most ridiculous statements I have heard. Substitute
some equivalent terms in there:
There is
From: Gareth Hughes [EMAIL PROTECTED]
To: Jeffrey W. Baker [EMAIL PROTECTED]
CC: David Johnson [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [Dri-devel] Radeon 8500, what's the plan?
Date: Tue, 02 Oct 2001 18:02:16 -0700
Jeffrey W. Baker wrote:
On Wed, 3 Oct 2001, David Johnson wrote:
On Wed, Oct 03, 2001 at 01:17:03AM +, David Johnson wrote:
Actually I think SiS offers an idct solution as well but beyond protecting
intellectual property there are potential legal issues with exposing how ATI
decodes copy righted, copy protected DVD.
I don't understand what this fuss
On Wed, Oct 03, 2001 at 12:57:55AM +, David Johnson wrote:
|... I think a major problem for Linux is forward and
| backward compatibility issues and compatibility issues between
| distributions. ...
There are (at least) two issues here: Binary compatibility for
On Wed, Oct 03, 2001 at 12:57:55AM +, David Johnson wrote:
Take a look at NVIDIA's linux driver website.
http://www.nvidia.com/view.asp?PAGE=linux Is that confusing to a
non-technical user or what? Is the average user going to know the
difference between Redhat 7.1 SMP Kernel vs
On Wed, 3 Oct 2001, Damien Miller wrote:
On Tue, 2 Oct 2001 [EMAIL PROTECTED] wrote:
With linux, it will say something along the lines of works with Redhat
6.2. (take a look at many CAD packages, for example - they are _not_ very
graphics intensive). Games are even trickier. I have
On Tue, 2 Oct 2001, Gareth Hughes wrote:
Jeffrey W. Baker wrote:
On Wed, 3 Oct 2001, David Johnson wrote:
There is some seriously proprietary stuff with idct that for legal
reasons ATI wouldn't want to expose.
That is one of the most ridiculous statements I have heard.
Loki didn't get low level (i.e. register level) idct docs. They got an
idct
library with docs on how to use that library. I don't think PI/VA got
them
either. There is some seriously proprietary stuff with idct that for
legal
reasons ATI wouldn't want to expose.
Would you know
Or it could be that the iDCT core was not developed by ATI, but by someone
else, and ATI just licensed it. This could explain why they are so
adamant about not releasing the docs. As for TV-out they might be afraid
that releasing the specs could be consired equivalent to providing
Macrovision
Around 3 o'clock on Oct 3, Peter Surda wrote:
I don't understand what this fuss about hardware accelerated idct is. In which
situation you actually get use of it? When I play DVDs on my Duron 650 I get
over 50% free CPU time with a software-only dvd decoder (vlc), the card only
does yuv-rgb
On Tue, 2 Oct 2001 [EMAIL PROTECTED] wrote:
On the other hand, perhaps, I should give a try to writing a game engine
myself.
I know of at least one open-source (LGPL) engine in development: Crystal
Space (http://crystal.linuxgames.com). It's a very ambitious project
which aims to be a
I will present my problem in it's full, may be you will help me:
I am grabbing frames from bt848 and should both store them for future reuse
and get them on the screen. The box is i810 based and has many other tasks
to do.
putting video on a screen should be fast and very low CPU consuming.
I haven't tried the mesa-3.5-branch for a bit and I thought I would test things out on
my Radeon to see how things are. Make World went fine and I grep'd the World.log file
for errors, there were none. I went into the drm dir and copied the radeon.o into my
kernel drm dir and went to modprobe
What you say is true, it isn't all that difficult for you and I, but compare
that to Windows where you have one driver set for a whole range of adapters
and all the user has to do is download and click. That is why Windows is so
popular. It is simple. Just because you can say something like
Um in addition to saving power in notebooks, you'd probably also end up
creating a lot less heat. Though this might not be the case with NVidia
cards ;-) Most reviewers of the Radeon came to the conclusion that the
fan was purely for looks, something that I couldn't even say about my K6-2.
Garry Reisky stated:
I haven't tried the mesa-3.5-branch for a bit and I thought I would test
grep'd the World.log file for errors, there were none. I went into the
drm dir and copied the radeon.o into my kernel drm dir and went to modprobe
it but I get this error.
modprobe radeon
On Tue, 2001-10-02 at 23:11, Steven P. Lilly wrote:
I just installed Slackware 8 with XFree86 4.1.0 and I've come across
some weirdness with glxgears. When I'm running a window manager everything is
fine but when I don't run a window manager I get a much higher frame
rate but what I
The current mesa-3-5-branch code has a bug dealing with GL_QUADS,
suffice it to say that it results in some, interesting, rendering bugs.
Thanks to relnav and lordhavic for helping pin down what was actually
happening. (And relnav for helping test.)
Patch is attached.
Zephaniah E. Hull.
--
This small patch fixes/works around a problem with tdfxDDTexturePalette
when glColorTable() is used with a proxy texture (it tries to access a
non-existent color table).
Steven Fuller
Index: tdfx_tex.c
===
RCS file:
On Wed, 3 Oct 2001 19:46, Steven Fuller wrote:
This small patch fixes/works around a problem with tdfxDDTexturePalette
when glColorTable() is used with a proxy texture (it tries to access a
non-existent color table).
Sorry Steven, I must have missed your earlier patches. Can you resend
I just installed Slackware 8 with XFree86 4.1.0 and I've come across
some weirdness with glxgears. When I'm running a window manager
everything is
fine but when I don't run a window manager I get a much higher frame
rate but what I see is some garbage with a piece of a large red
Take your kernel upto 2.4.10 and you'll be o.k.
Alan.
On Thu, Oct 04, 2001 at 04:28:33PM +0200, Huber, Matthias 6667 SFA-31 wrote:
Hi,
the subject says it: glxgears (and all other OpenGL-based programs)
abort with the message:
drmR128SwapBuffers = -14
My configuration:
Kernel 2.4.6
On Thu, 2001-10-04 at 16:28, Huber, Matthias 6667 SFA-31 wrote:
the subject says it: glxgears (and all other OpenGL-based programs)
abort with the message:
drmR128SwapBuffers = -14
My configuration:
Kernel 2.4.6
XFree86 4.1.0
ATI AIW 128 Pro
newly compiled drm kernel modules, r128
On Thursday 04 October 2001 07:06, Michel Dänzer wrote:
On Thu, 2001-10-04 at 03:56, Steven P. Lilly wrote:
Everything else seems to work fine, which points at a glxgears bug?
I encountered something very similar with glxgears when I was attempting to
get RagePRO DMA operation working for
On Thu, 2001-10-04 at 17:58, Frank Earl wrote:
On Thursday 04 October 2001 07:06, Michel Dänzer wrote:
On Thu, 2001-10-04 at 03:56, Steven P. Lilly wrote:
Everything else seems to work fine, which points at a glxgears bug?
I encountered something very similar with glxgears when I was
On Wed, 3 Oct 2001 19:19, Zephaniah E\. Hull wrote:
The current mesa-3-5-branch code has a bug dealing with GL_QUADS,
suffice it to say that it results in some, interesting, rendering bugs.
Looks like a cutpaste bug. I'll commit the fix.
Keith
On Thu, 4 Oct 2001 12:55, Zephaniah E\. Hull wrote:
On Thu, Oct 04, 2001 at 10:32:15AM -0600, Keith Whitwell wrote:
On Wed, 3 Oct 2001 19:19, Zephaniah E\. Hull wrote:
The current mesa-3-5-branch code has a bug dealing with GL_QUADS,
suffice it to say that it results in some,
On Thu, 2001-10-04 at 21:57, Steven P. Lilly wrote:
Sorry to have bothered everyone. I downloaded the source to glxgears and
found the problem. It wasn't setting up the viewport properly until the
reshape function got called. With a window manager it gets called right away
when the window is
On Fri, 2001-10-05 at 00:08, Nathan Hand wrote:
XV is completely independent of V4L and the DRI.
This is true conceptually and was true implementation-wise until
recently. However, the r128 driver uses the DRM to transfer the XvImage
data now when possible, and Peter Surda has been bug^Wasking
On Thursday 04 October 2001 12:30, you wrote:
Hardly, as this thread is about incorrect rendering, not lockups.
Ooops... Could have sworn that it was about lockups (since I get that with
my wife's machine with gears...)- that's what I get for trying to pass the
time during compiles, etc. up
On Thu, 4 Oct 2001 19:40, Dieter Nützel wrote:
Hello all,
after your latest fixes I've to report the following issues together with
my Voodoo5 5500 AGP.
First of all:
Do I have to use the Mesa-4.0 CVS tree?
Keith what was the name of the path variable, again?
No.
1. UT 436 show a
the subject says it: glxgears (and all other OpenGL-based programs)
abort with the message:
drmR128SwapBuffers = -14
My configuration:
Kernel 2.4.6
XFree86 4.1.0
ATI AIW 128 Pro
newly compiled drm kernel modules, r128 XFree86 driver, r128_dri.so,
etc.
Do you have the DRM from kernel
* accelerated 3d: glxgears are funny - they do not rotate, but
toggle from one position to another
My thought on this is that the gears are moving so fast that the only frames
that you actually get to see are of two alternating positions. The glxgears
program moves the gears a set
Dear DRI developers,
I read in the FAQ, that NVidia provide their own
binary closed source drivers. Yet visiting the Nvidia
homepage driver section I find, that there are not only
binary drivers for several distributions, but also a source
rpm and a source tarball for those interested.
* Johannes Prix ([EMAIL PROTECTED]) wrote:
Dear DRI developers,
I read in the FAQ, that NVidia provide their own
binary closed source drivers. Yet visiting the Nvidia
homepage driver section I find, that there are not only
binary drivers for several distributions, but also a source
rpm
On Fri, Oct 05, 2001 at 05:36:49PM +0200, Johannes Prix wrote:
I read in the FAQ, that NVidia provide their own
binary closed source drivers. Yet visiting the Nvidia
homepage driver section I find, that there are not only
binary drivers for several distributions, but also a source
rpm and a
The NV source is their kernel driver. This basic function
of this routine is to manage DMA transfers of buffers full
of graphics commands to the board. This is a very small
piece of code that exposes almost nothing of the architecture
of the graphics engine. The code that actually
builds the
The only source files that nVidia provides are very limited files for
compiling the necessary kernel driver (which, from what I understand,
contains very little info regarding nVidia's hardware). The source rpm
they have for NVIDIA_GLX is nothing more than the compiled libraries and X
On Friday 05 October 2001 10:46, you wrote:
i noticed your name on dri.sourceforge.net and was wondering if mach64
support was still being worked on or if the developers aren't going to
continue with the project. there are many questions about it in
I'd be happy to get to work making grabbing facilities, etc (for mga, which seems to
be the most stable accellerator) but for lack of experience and not much of a place to
start..
On the other hand, I'm getting paid to do it (part of my job), so chances are I'll
complete it.
Any pointers
Maybe I'm just paranoid, but why so much on the i810? This chipset is
slower than Mach64, and people never got it in the intention of doing
games, or other intense graphics.
Roberto Peon wrote:
I'd be happy to get to work making grabbing facilities, etc (for mga, which seems to
be the most
In our case, it isn't necessarily on the i810. We don't really care what accellerator
is used as long as it works well for textures and stenciling. Depth buffering is a
bonus, but not necessary for the majority of things that we do. Dest alpha, on the
other hand IS.
Right now we're evaluating
Hi,
I have a Dell Inspiron 4000 with an ATI Rage Mobility M3 on which DRI doesn't
work. The r128 module loads fine, when I try to read from /proc/dri/0/vm,
cat segfaults and I get this oops:
ksymoops 2.4.3 on i686 2.4.9-ac18. Options used
-V (default)
-k /proc/ksyms (specified)
Hello guys,
I hope you are not bored with me yet :(
short target description: I have 2 cameras that muxed in their way to bt848,
I have to draw contents of the cameras (while alternating the mux) to two
windows with as few CPU usage as possible. my video card is i810.
I get frames in
On Thu, 18 Oct 2001, Pasi Kärkkäinen wrote:
Red Hat Hires Former DRI Developers
http://biz.yahoo.com/bw/011017/172084_1.html
It doesn't say that at all, as far as I can see.
-jwb
___
Dri-devel mailing list
[EMAIL PROTECTED]
On Thu, 18 Oct 2001, Jeffrey W. Baker wrote:
On Thu, 18 Oct 2001, Pasi Kärkkäinen wrote:
Red Hat Hires Former DRI Developers
http://biz.yahoo.com/bw/011017/172084_1.html
It doesn't say that at all, as far as I can see.
Sorry, that was taken from the www.linuxgames.com
- Pasi
El Mié 17 Oct 2001 11:44, R C escribió:
On Sat, Oct 13, 2001 at 10:08:50PM +0200, Manuel Teira wrote:
Regarding theories on DMA and Mach64 and XFree 4.10:
I just finished a module that uses the System DMA unit for video capture
transfers, and it works fine under a (highly hacked) XFree
Michael Zayats wrote:
Hello guys,
short target description: I have 2 cameras that muxed in their way to bt848,
I have to draw contents of the cameras (while alternating the mux) to two
windows with as few CPU usage as possible. my video card is i810.
i just took a quick look at the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 18 October 2001 14:50, Michael Zayats wrote:
Do you know whether 2D textures might be used as a surface to draw video
on? Is DMA path of memory - texture implemented in i810 driver? (4.1.0)
what do you think of this path at all?
Liam Wilks writes:
Could anybody help me with this problem? DRI doesn't seem to want to
compile from CVS. I am running Redhat 7.1, with kernel 2.4.5 patched for
Win4Lin, and XFree86 4.10.
I have an ATI Rage Mobility P/M Graphics Card, which is a Mach 64 based
card. I downloaded the
[EMAIL PROTECTED] wrote:
/usr/bin/ld: cannot find -lXau
[...]
Perhaps the fastest solution is copying the /usr/X11R6 to the
/usr/X11R6-DRI directory to avoid this compilation problems. Then, the
installation will overwrite the important stuff.
I'm currently trying to compile this, too -
On Fri, 19 Oct 2001, Malte Cornils wrote:
Yep, I do have another question though. Is it necessary to specify
mach64 manually in xc/config/cf/host.def? If so, the patch should
probably modify this file in that regard, too.
That's not necessary, the mach64 driver is part of the ati (2D)
On Fri, 19 Oct 2001 17:24, Leif Delgass wrote:
Great work! I'll check this out soon.
Once we get DMA working for the 3D operations, I guess the next task is to
get the 2D acceleration routines synchronizing with the 3D ones so we can
reenable XAA, right? Also, it looks as if the AGP setup
Leif Delgass wrote:
Great work! I'll check this out soon.
Once we get DMA working for the 3D operations, I guess the next task is to
get the 2D acceleration routines synchronizing with the 3D ones so we can
reenable XAA, right? Also, it looks as if the AGP setup has not been
finished
Just a warning, with the direct register writes enabled in
mach64_dma_dispatch_clear (in mach64_state.c), switching to a virtual
terminal and back to X causes my box to hang hard -- I can't ssh in and
Alt-SysRq doesn't work.
--
Leif Delgass
___
Hey,
From what I can tell, it accesses 16mb. Aperature Base can be
allocated anywhere in the shaded region and is aligned to a multiple of
16MB This comes from page 17. Congratulations on your work on the
driver, and thanks.
Carl Busjahn
Gareth Hughes wrote:
Leif Delgass wrote:
El Sáb 20 Oct 2001 02:49, Keith Whitwell escribió:
On Fri, 19 Oct 2001 17:24, Leif Delgass wrote:
Great work! I'll check this out soon.
Once we get DMA working for the 3D operations, I guess the next task is
to get the 2D acceleration routines synchronizing with the 3D ones so we
can
Hi there,
I'm strugling with my G400 performance for months now, since the 4.1 tree.
Quake 3 is just not playable at some levels,
Return to castle wolfenstein is not playable.
Soldier of fortune is not playable anymore.
I had contact with Jeff Hartman, and he told me that this was supposed to
On Sat, 2001-10-20 at 11:18, Manuel Teira wrote:
Well, talking about CVS. What do you think is better? I would made
the update in the CVS if you give me access. It could be nice if
someone gives me a little recipe to made the upgrade without problems,
or at least, recommend some guide about
On Fri, 2001-10-19 at 14:52, M.G. Houtman wrote:
Before Xfree 4.1.0, I always used the DRI CVS version for Xfree,
'cause it had the latest and (nearly always) the best drivers. Since
4.1.0 the standard sources contain the latest DRI sources, so I
installed that version.
Normally, DRI
El Sáb 20 Oct 2001 18:02, Frank C. Earl escribió:
We can work on parts of it. If you want to do the DMA part (and I won't
stop you from it- having said this, I can do that part as well...), we
ought to come up with some agreed upon code interfaces to it so that
someone else can be plugging
On Saturday 20 October 2001 10:18 pm, Daryll Strauss wrote:
On Sat, Oct 20, 2001 at 07:49:56PM +0200, Manuel Teira wrote:
OK. Thank you for the clear explanation. Now I think I'm ready to put the
new branch in the repository. I'm waiting for the access, guys. As soon
as I have access (if
On Sun, 2001-10-21 at 12:43, Manuel Teira wrote:
El Dom 21 Oct 2001 04:18, Daryll Strauss escribió:
On Sat, Oct 20, 2001 at 07:49:56PM +0200, Manuel Teira wrote:
OK. Thank you for the clear explanation. Now I think I'm ready to put the
new branch in the repository. I'm waiting for the
El Dom 21 Oct 2001 16:30, Keith Whitwell escribió:
Manuel Teira wrote:
El Dom 21 Oct 2001 04:18, Daryll Strauss escribió:
On Sat, Oct 20, 2001 at 07:49:56PM +0200, Manuel Teira wrote:
OK. Thank you for the clear explanation. Now I think I'm ready to put
the new branch in the
El Dom 21 Oct 2001 16:56, Michel Dänzer escribió:
On Sun, 2001-10-21 at 12:43, Manuel Teira wrote:
El Dom 21 Oct 2001 04:18, Daryll Strauss escribió:
On Sat, Oct 20, 2001 at 07:49:56PM +0200, Manuel Teira wrote:
OK. Thank you for the clear explanation. Now I think I'm ready to put
On Sun, Oct 21, 2001 at 12:43:32PM +0200, Manuel Teira wrote:
El Dom 21 Oct 2001 04:18, Daryll Strauss escribi?:
On Sat, Oct 20, 2001 at 07:49:56PM +0200, Manuel Teira wrote:
OK. Thank you for the clear explanation. Now I think I'm ready to put the
new branch in the repository. I'm
El Dom 21 Oct 2001 17:56, R C escribió:
Well, it was a little late. I'm trying now, but having problems:
export CVSROOT=cvs.dri.sourceforge.net:/cvsroot/dri
export CVS_RSH=ssh
bash-2.05$ cvs rtag -b mach64-0-0-2-branch xc
The authenticity of host 'cvs.dri.sourceforge.net
El Dom 21 Oct 2001 18:56, [EMAIL PROTECTED] escribió:
On Sun, 21 Oct 2001, Manuel Teira wrote:
El Dom 21 Oct 2001 17:56, R C escribió:
Well, it was a little late. I'm trying now, but having problems:
export CVSROOT=cvs.dri.sourceforge.net:/cvsroot/dri
export CVS_RSH=ssh
As background I have a K7 system w/KT266 mb, and am using a Voodoo 3 card.
I have DRI working for XFree-4.1.0 (the one bundled with Mandrake 8.1), but am
seeing the color problem for Unreal Tournament.
I have successfully compiled the DRI CVS into a separate X tree, /usr/X11R6-DRI,
and this
No one responded to this :(. Does anyone know of any problems with r128
in 2D mode?
Joe
On Wed, Oct 17, 2001 at 03:14:32PM +0100, Josef Karthauser wrote:
Hi,
I'm using the r128.ko driver with a matrox rage mobility chipset under
FreeBSD:
info: [drm] Checking PCI vendor=32902,
On Sun, Oct 21, 2001 at 12:34:57PM -0600, Keith Whitwell wrote:
This is probably because most r128 2d acceleration was turned off when drm is
enabled. Michael Danzer has done some work to fix this.
Keith
Thanks Keith,
Does anyone know whether this code has been merged into the BSD
Frank C. Earl wrote:
On Saturday 20 October 2001 10:18 pm, Daryll Strauss wrote:
On Sat, Oct 20, 2001 at 07:49:56PM +0200, Manuel Teira wrote:
OK. Thank you for the clear explanation. Now I think I'm ready to put the
new branch in the repository. I'm waiting for the access, guys. As
Would you consider it a good ideato make DRI
part of the sourceof a kernel?Direct 3d graphicssupported from
theboot sequence.
I'm really concerned about your answer. There was a
whole thread on the linux-kernel mailing list about the hypothesis of the
release of an X-Kernel, a kernel which
On Mon, 22 Oct 2001, MichaelM wrote:
Would you consider it a good idea to blah blah blah?
Send us a mail that isn't from a windows machine, and you might get an
interesting discussion. As it stands, I can barely tell what you are
going on about.
-jwb
On Sun, Oct 21, 2001 at 10:01:33PM -0700, Jeffrey W. Baker wrote:
Send us a mail that isn't from a windows machine, and you might get an
interesting discussion. As it stands, I can barely tell what you are going
on about.
Dude, I think that Outlook is crap too, I had to administer a couple of
On Mon, 22 Oct 2001, MichaelM wrote:
Would you consider it a good idea to make DRI part of the source of a kernel? Direct
3d graphics supported from the boot sequence.
I'm really concerned about your answer. There was a whole thread on the linux-kernel
mailing list about the hypothesis
On Mon, Oct 22, 2001 at 05:48:56AM +0100, MichaelM wrote:
Would you consider it a good idea to make DRI part of the source of a
kernel? Direct 3d graphics supported from the boot sequence.
Hmm I thought DRI is part of the kernel? Perhaps you meant the DRM part of it.
I'm really
On Mon, Oct 22, 2001 at 02:27:23AM -0400, [EMAIL PROTECTED] wrote:
The biggest reason against this is that X (as it is now) support not only
Linux but many other OSes: in particular BSD(s) and Solaris. Moving
stuff into Linux kernel creates a fork of the drivers which is
undesirable..
That's
we move the whole driver structure to kernel? Drivers for every other device
Not really.
STRUCTURE. For a great UI, we need DMA, vsync and devices communicating with
each other directly or with little overhead. Why insist on doing this in
A video driver has to have extremely good latency,
On Mon, 22 Oct 2001, Peter Surda wrote:
On Mon, Oct 22, 2001 at 05:48:56AM +0100, MichaelM wrote:
Would you consider it a good idea to make DRI part of the source of a
kernel? Direct 3d graphics supported from the boot sequence.
Hmm I thought DRI is part of the kernel? Perhaps you
test!
sorry list, but messages were not coming to me.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
On Mon, 22 Oct 2001, Peter Surda wrote:
On Sun, Oct 21, 2001 at 10:01:33PM -0700, Jeffrey W. Baker wrote:
Send us a mail that isn't from a windows machine, and you might get an
interesting discussion. As it stands, I can barely tell what you are going
on about.
Dude, I think that
Manuel Teira wrote:
If you find any problem compiling the new branch, please make me know.
OK, let me see. With regards to that libXau problem: it
's sufficient to just copy /usr/X11R6/lib to /usr/X11R6-DRI/lib, the
rest of the tree isn't necessary. Otherwise, I followed the DRI
compilation
On Mon, Oct 22, 2001 at 05:48:56AM +0100, MichaelM wrote:
Would you consider it a good idea to make DRI part of the source of a
kernel? Direct 3d graphics supported from the boot sequence.
I'm really concerned about your answer. There was a whole thread on
the linux-kernel mailing list
Jeff's in the process of moving from Colorado to Oklahoma. I'm sure
he'll tend to this when he gets settled in.
-Brian
--- Leif Sawyer [EMAIL PROTECTED] wrote:
Don't know if this will get through or not, but since Jeff doesn't seem
to (want to?) respond directly, perhaps somebody on this
I'm really concerned about your answer. There was a whole thread
on the linux-kernel mailing list about the hypothesis of the
release of an X-Kernel, a kernel which would include built-in
desktop support. Most people answered, no, this would be
ridiculous, other said, yes, but hardware
El Lun 22 Oct 2001 17:52, Malte Cornils escribió:
Manuel Teira wrote:
If you find any problem compiling the new branch, please make me know.
OK, let me see. With regards to that libXau problem: it
's sufficient to just copy /usr/X11R6/lib to /usr/X11R6-DRI/lib, the
rest of the tree isn't
Manuel Teira wrote:
Have you got errores related to the glide library?
Perhaps you should comment out the line:
#define HasGlide3 YES
in the host.def file.
Or perhaps would be good to comment it out in our mach64 branch.
oops. That's likely the problem. I got so used to configure-like
Hello,
I've done some testing on my machine with the CVS branch that Manuel did
so well.
I find that it works great on my machine. I get about 27 fps in gltron,
but this is a k6 550mhz. Quake 3 was even nearly playable in
548x380(or whatever that mode is). I just saw now, that you are
On Mon, 22 Oct 2001, Sottek, Matthew J wrote:
The basic idea in the framebuffer is fine, but the implementation
isn't very good. It is more grown out of console functions rather
than starting from a graphics driver perspective.
Not to burst anyone's bubble here, guys, but shades of GGI going
what are the current developement status for radeon 7500 and 8500?
i know thers had talk about it before but many developement had advence sience.
thank you.
___
Dri-devel mailing list
[EMAIL PROTECTED]
On Monday 22 October 2001 18:58, Malte Cornils wrote:
BTW, why does mach64 module insertion
fail when agpgart isn't installed if it doesn't use any features
from AGP?
While we're opening the device, we're not using it because the code that we
have was stalled at DMA operations (It's just
On Monday 22 October 2001 22:41, R C wrote:
With Mach64, perhaps. With Radeon PCI, it locks up horribly in Xserver
initialization.
There could be several reasons for that- the code should be checking for the
lack of AGP support and do the right things. As for it needing it to be
loaded, we
B. van den Heuvel wrote:
But will it help if I lower my resolution ?
yep, and to reduce the color depth.
its printed in the X log:
(II) MGA(0): Reserved 12288 kb for textures at offset 0x140
but i just realized that my g400 box still runs with
some patch i made.
(no, i wont pollute the
ralf willenbacher wrote:
B. van den Heuvel wrote:
But will it help if I lower my resolution ?
yep, and to reduce the color depth.
its printed in the X log:
(II) MGA(0): Reserved 12288 kb for textures at offset 0x140
but i just realized that my g400 box still runs with
some
Your depth is 24. 3D depths are only 16bit and 32bit. The Mach64 is
really not powerful enough to handle 32bit (which is what 24 yeilds in
XFree86 4.1). I'm not even sure if the driver supports 32bit depth, but
it's not a good idea anyway. Plus you're going to get better overall
quality
Hi folks,
I'm attempting to incorporate DRI's mesa-4-0-branch into my
current X 4.1.0.1 (Debian sid from X 4_1 branch) setup but am running
into difficulties. I checked out the mesa-4-0-branch and created the build
tree as the DRI compilation guide instructed (which btw is rather
701 - 800 of 46322 matches
Mail list logo
