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 board
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 tru
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 e
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 packag
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 tr
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 extras/Mesa/src/i
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 t
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 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 opti
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 spec,
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
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 ("-dep
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
> >>>
>
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.
A
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 0xff0
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.
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
--- xc/config/cf/host.def.orig
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 ("-depth 32" doesn't
work
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 Xvisua
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 0
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
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
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 had
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
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 too
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
b
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 t
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 ha
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.
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 radeon
> 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
31 matches
Mail list logo
