although I'm sure debian are correct, I don't think this change is
appropriate for a stable release, it adds extra user space requirements..
so I won't be applying it in its current form, I might try firmware
loading and fall back to using the in-built microcode, it won't satisfy
Debian but
It looks good to me.
Dave.
confirmation of the patch before I apply it. (I applied the other three).
Can someone take a look at this?
In the future DRI-related patches should probably be sent to the dri-devel
list.
-Brian
Tilman Sauerbeck wrote:
Hi,
the attached patch fixes a
On Sun, Apr 25, 2004 at 11:57:28PM -0500, Ryan Underwood wrote:
I think I'll be doing some footwork on this one.
I wrote a quick program to parse out the microcode from the XFree86
mga_ucode.h files. From here a disassembler can be written if we can
ever figure out the op codes. The DDK
On Mon, Apr 26, 2004 at 02:49:36AM -0500, Ryan Underwood wrote:
I wrote a quick program to parse out the microcode from the XFree86
mga_ucode.h files.
attaching sample output. seems that g200 and g400-mt ucodes are much
bigger than g400 ucodes in general.
--
Ryan Underwood, [EMAIL
Martin Spott wrote:
Alex Deucher wrote:
I don't know about that. I can forsee IGP becoming _the_ standard
method for video. Look at sgi... all of their video systems use
system memory, [...]
Really ? Which one ?
I know the O2 does, but MGRAS and VPro ? I'm not absolutely sure
but
gcc -c -I../../include -I../../src/mesa -I../../src/mesa/main
-I../../src/mesa/glapi -I../../src/mesa/math -I../../src/mesa/tnl
-I../../src/mesa/shader -I../../src/mesa/swrast -I../../src/mesa/swrast_setup
-Wall -O -march=athlon -ansi -pedantic -fPIC -D_POSIX_SOURCE
-D_POSIX_C_SOURCE=199309L
Am Mittwoch, 18. Februar 2004 18:11 schrieb Dieter Nützel:
Background isn't empty/black but the normal desktop background.
Buffer wouldn't be cleared?
SOLVED.
After Fridays DRI/Mesa changes and before yesterdays bug in
drivers/x11/xm_api.c.
Greetings,
Dieter
Am Donnerstag, 5. Februar 2004 19:38 schrieb Dieter Nützel:
Have you seen, that it is much faster (hardware accelerate?) in the broken
area (on the right and right/below corner)?
progs/demos ./stex3d
Mesa: software DXTn compression/decompression available
GL_RENDERER: Mesa DRI R200 20030328
TaskParallelism
Maybe due to Ian's SMP multicontext fix.
Cheers,
Dieter
---
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up
Thanks Dieter,
I'll fix that up asap as soon as CVS is working again on pdx.
Alan.
On Mon, Apr 26, 2004 at 02:09:57PM +0200, Dieter Nützel wrote:
gcc -c -I../../include -I../../src/mesa -I../../src/mesa/main
-I../../src/mesa/glapi -I../../src/mesa/math -I../../src/mesa/tnl
Am Montag, 26. April 2004 14:44 schrieb Alan Hourihane:
Thanks Dieter,
I'll fix that up asap as soon as CVS is working again on pdx.
OK,
now I get a GCC-3.3.1, Athon-MP, SSE build instruction error in
src/mesa/swrast_setup/ss_triangle.c.
if (ctx-Light.ShadeModel == GL_FLAT) {
You should probably report internal compiler errors to the gcc project.
-Brian
Dieter Nützel wrote:
Am Montag, 26. April 2004 14:44 schrieb Alan Hourihane:
Thanks Dieter,
I'll fix that up asap as soon as CVS is working again on pdx.
OK,
now I get a GCC-3.3.1, Athon-MP, SSE build instruction
--- Alan Cox [EMAIL PROTECTED] wrote:
On Llu, 2004-04-26 at 03:38, Vladimir Dergachev wrote:
So the next question would be how does one hack radeon or r200
driver to
get down to a particular function ?
When I was trying to debug the sis6326 and via drivers the best way I
found with
On Mon, 26 Apr 2004, Alan Cox wrote:
On Llu, 2004-04-26 at 03:38, Vladimir Dergachev wrote:
So the next question would be how does one hack radeon or r200 driver to
get down to a particular function ?
When I was trying to debug the sis6326 and via drivers the best way I
found with those
This is just a friendly reminder that the weekly dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or
5:00PM EDT or 2:00PM PDT, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
Logs of previous
Im trying to confirm if the new savage driver is actually in cvs now,
anyone know? (And anyone here actually use it? Does it work?)
--
Patrick Diablo-D3 McFarland || [EMAIL PROTECTED]
Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
all be running around in
--- Patrick McFarland [EMAIL PROTECTED] wrote:
Im trying to confirm if the new savage driver is actually in cvs now,
anyone know? (And anyone here actually use it? Does it work?)
yes, yes, and yes. All savages except the savage2000 are supported.
see this page for more info:
Or xf86drm.c buf free changes?
Sorry, no more time for testing, tonight.
-Dieter
---
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up
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:
I've fixed this and checked in, the .S files needed special lines in the
Imakefile for radeon/r200
Dave.
On Tue, 27 Apr 2004, Dieter Nützel wrote:
Or xf86drm.c buf free changes?
Sorry, no more time for testing, tonight.
-Dieter
---
Well, I dug a bit deeper into writing R300 driver (using R200 one to
start with) and I have more questions:
1. What does rmesa-TclFallback do and how should I activate it ?
2. What is state ? More specifically:
A) I noticed that state holds contents of a lot of registers,
28 matches
Mail list logo
