> At 16bpp I also have texture problems in q3demo (I see white
> walls/floors, no textures but damage textures from weapons show up
> over the white) and the above mentioned problem with alpha blending.
The q3demo texture problem only appears with lightmap lighting -- vertex
lighting works fine.
On Tue, 23 Oct 2001, Malte Cornils wrote:
[snip]
> gltron does 5-15 on mach64, 5-15 on plain mesa, too; although it
> subjectively seems to be a bit jerkier. Anyway, with the old Utah code
> I got more (at least 20fps, but on a K6-2 333) but that has time. I'm
> more concerned about glxgears: in
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 goi
Hello.
I'm interesting in writing drivers for new hardware and helping DRI
project with anything I can. How can I get started?
-Igor
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
On Mon, Oct 22, 2001 at 11:19:41PM -0400, Carl Busjahn wrote:
> Hello,
> The Mach64 driver calls for agp, which is why it's failing, I suppose
> that you could take out that call for machines with PCI cards, but
> AGPgart won't mess up machines even without AGP chipsets. What kind of
With Mac
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 usi
>> #1 A kernel API for mode setting, mmaping of the framebuffer and
>> video memory management.
>Truely needed. Something like the Linux version of the VESA
>interface. I think the Linux framebuffer project took this thing
>as their basic idea.
The basic idea in the framebuffer is fine, but the
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
s
> From: Sottek, Matthew J [mailto:[EMAIL PROTECTED]]
[...]
> #1 A kernel API for mode setting, mmaping of the framebuffer and
> video memory management.
Truely needed. Something like the Linux version of the VESA interface.
I think the Linux framebuffer project took this thing as their basic idea
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 i
>>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 m
From: Brian Paul <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2001 10:16:38 -0700 (PDT)
Jeff's in the process of moving from Colorado to Oklahoma. I'm sure
he'll tend to this when he gets settled in.
I already fixed the problem in current 2.4.13-preX linux sources.
The FFB DRI driver is
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
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 list can take
a look at this issue.
-Original Message-
From: David S. Miller [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 11, 2001 4:07 PM
To: [EMAIL PRO
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
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 gui
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 t
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 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 y
> 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, 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
21 matches
Mail list logo
