I would just add that if you're using a kernel that uses a
better source
directory naming scheme (e.g. 2.4.19 unpacks to linux-2.4.19 whereas
2.4.18 unpacks to just linux), you'll want to use the
TREE=/usr/src/linux-2.4.XX/include option in your make
command. Like so:
make -f
Leif Delgass wrote:
On Wed, 5 Feb 2003, Ian Romanick wrote:
Leif Delgass wrote:
Those assumptions seem to be correct. For the most part, your patch
looks a lot like what I have in my local tree. :) The only thing I did
different was I overlapped the zero and one tables.
static GLuint
On Wed, 5 Feb 2003, Leif Delgass wrote:
Also, should I go ahead and commit my revised texmem patch?
Yes.
OK, will do. Do you want to commit your patch for combine3 to texmem? I
don't have an R200, so I can't test that, but it looks like it should be
easy to add there too. If
Keith Whitwell wrote:
Felix Kühling wrote:
On Wed, 05 Feb 2003 16:25:27 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
I attached a patch that fixes the problem. It introduces a new
TCL_FALLBACK if there are too many vertices to fit into one DMA buffer.
Looks kind of
On Don, 2003-02-06 at 01:55, Keith Whitwell wrote:
Felix Kühling wrote:
On Wed, 05 Feb 2003 16:25:27 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
I attached a patch that fixes the problem. It introduces a new
TCL_FALLBACK if there are too many vertices to fit
Ian Romanick wrote:
Keith Whitwell wrote:
Felix Kühling wrote:
On Wed, 05 Feb 2003 16:25:27 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
I attached a patch that fixes the problem. It introduces a new
TCL_FALLBACK if there are too many vertices to fit into one DMA
Leif Delgass wrote:
On Wed, 5 Feb 2003, Leif Delgass wrote:
Also, should I go ahead and commit my revised texmem patch?
Yes.
OK, will do. Do you want to commit your patch for combine3 to texmem? I
don't have an R200, so I can't test that, but it looks like it should be
easy to add there
On Thu, 6 Feb 2003, Ian Romanick wrote:
Some time ago there were some scissor problems that caused every glean
test to always fail. I think those were fixed in the radeon and r200
drivers about 6 months ago. On my R100 the only tests that failed for
me were the subtract tests and the
Ian Romanick wrote:
Leif Delgass wrote:
On Wed, 5 Feb 2003, Ian Romanick wrote:
[...]
Regarding glean, I need to test again, but I was seeing some other
failures even with the mesa-4-0-4 and trunk. I think there were some
off-by-one scissor errors and a couple of others. One question I
On Thu, 6 Feb 2003, Ian Romanick wrote:
I went ahead and committed my texmem changes as well as combine3 for
radeon and r200 (including the change to the zero/one table). I can't
test the r200 version, but it looks almost identical to R100.
Cool. I can't think of any reason why those
Leif Delgass wrote:
On Thu, 6 Feb 2003, Brian Paul wrote:
The mask values indicate which bits in the pixel (word) correspond to each
color channel. The buffer size is the sum of the red, green, blue, and alpha
bits.
Mach64/R128
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0
Brian Paul wrote:
Leif Delgass wrote:
On Thu, 6 Feb 2003, Brian Paul wrote:
The mask values indicate which bits in the pixel (word) correspond to
each color channel. The buffer size is the sum of the red, green,
blue, and alpha bits.
Mach64/R128
r g b a amaskbsz ar ag ab aa
Someone sent me this patch to build my Debian packages on alpha. Is
there any reason not to apply it to the trunk?
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
---
Brian Paul wrote:
Err, he updated the texmem branch. I've updated the mesa-4-0-4 branch
so it matches the trunk. Perhaps Ian can update the texmem branch again
with the mga and glint changes. I don't have a copy of that branch
checked out.
Done.
first let me separate the framebuffer data from GL data
by four more spaces.
MGA
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 8 32 16 16 16 0 24
alphaMask should be 0xff00.
In the argb
On Fri, Feb 07, 2003 at 12:04:59AM +0100, Michel Dänzer wrote:
Someone sent me this patch to build my Debian packages on alpha. Is
there any reason not to apply it to the trunk?
Technically we shouldn't be compiling with any CPU options. So I'm
o.k. with removing them for all architectures.
Alexander Stohr wrote:
first let me separate the framebuffer data from GL data
by four more spaces.
MGA
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 8 32 16 16 16 0 24
alphaMask should be
Leif Delgass wrote:
Well, the interesting thing is that when running X at depth 24 w/ 32 fbbpp
on Radeon, glxinfo still shows buffer size as 24 after the patch. Is this
because it's being intersected with the X visual depth of 24? Afaik,
there's no such thing as a depth 32 in the Xserver
On Thu, Feb 06, 2003 at 04:39:11PM -0700, Brian Paul wrote:
Alexander Stohr wrote:
GLINT
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn-depth)
8 8 8 0 24 16 16 16 0 24 (pScrn-depth)
Hey and why does 5+5+5+5
I found another one: i830_dri.c sets alphaSize = 0, alphaMask =
0xff00, and bufferSize = 32. In i830_span.c 255 is returned for alpha
in the 32-bit read functions, with a comment:
/* Note to Self:
* Don't read alpha from framebuffer, because its not correct. From a
* reading of the
On Fre, 2003-02-07 at 00:19, Alan Hourihane wrote:
On Fri, Feb 07, 2003 at 12:04:59AM +0100, Michel Dänzer wrote:
Someone sent me this patch to build my Debian packages on alpha. Is
there any reason not to apply it to the trunk?
Technically we shouldn't be compiling with any CPU options.
in XFree86 log
Symbol xf86strtof from module
/usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved!
this function doesn't exist in XFree86 trunk, nor DRI trunk (going by
grep), how ever it is used in extras/Mesa/src/imports.c
did someone forget to commit its definition?
On Fri, Feb 07, 2003 at 01:49:29AM +0100, Michel Dänzer wrote:
On Fre, 2003-02-07 at 00:19, Alan Hourihane wrote:
On Fri, Feb 07, 2003 at 12:04:59AM +0100, Michel Dnzer wrote:
Someone sent me this patch to build my Debian packages on alpha. Is
there any reason not to apply it to the
On Fri, Feb 07, 2003 at 10:55:33AM +1000, Chris Ison wrote:
in XFree86 log
Symbol xf86strtof from module
/usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved!
this function doesn't exist in XFree86 trunk, nor DRI trunk (going by
grep), how ever it is used in
On Fri, Feb 07, 2003 at 01:06:22AM +, Alan Hourihane wrote:
On Fri, Feb 07, 2003 at 10:55:33AM +1000, Chris Ison wrote:
in XFree86 log
Symbol xf86strtof from module
/usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved!
this function doesn't exist in XFree86 trunk, nor DRI
On Fre, 2003-02-07 at 01:53, Alan Hourihane wrote:
On Fri, Feb 07, 2003 at 01:49:29AM +0100, Michel Dänzer wrote:
On Fre, 2003-02-07 at 00:19, Alan Hourihane wrote:
On Fri, Feb 07, 2003 at 12:04:59AM +0100, Michel Dnzer wrote:
Someone sent me this patch to build my Debian packages on
Please try the current DRM, I'm curious if recent changes make a
difference.
Using the DRI-CVS from the evening of Feb 5, 2003, I saw no change.
Textures still flicker and it is still possible to lock up the server
with endgame (and possibly others. It's just easiest to get that
behavior with
Hi Alan!
Friday 07, at 01:06:22 AM you wrote:
On Fri, Feb 07, 2003 at 10:55:33AM +1000, Chris Ison wrote:
in XFree86 log
Symbol xf86strtof from module
/usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved!
this function doesn't exist in XFree86 trunk, nor DRI trunk (going by
ok, after a system upgrade, a cvs up and a compile for the new system,
dri trunk has a weird problem.
when ever a gl app tries to use textures, the system locks, glxgears
runs fine, x11perf runs fine till it hits the texture tests then locks.
System is now a p2 350, Radeon 9000 pci, yes the
29 matches
Mail list logo
