Roland Scheidegger wrote:
When I was playing around with texenv (I'm trying to implement
GL_EXT_blend_func_separate and GL_EXT_blend_equation_separate for the
R200, though my attempts to modify texenv to make it a useful test for
that were unsuccesful), I've noticed that the radeon and r200
Dave Airlie wrote:
So should we just work on getting everything running on newtree then and not
worry about the security issues for now?
Sounds good to me, I'll look into disabling DMA by default, if we have the
option we are okay, my only issue is though should there be something in
the DRM
On Fri, Feb 13, 2004 at 01:31:59AM +, Dave Airlie wrote:
So should we just work on getting everything running on newtree then and not
worry about the security issues for now?
Sounds good to me, I'll look into disabling DMA by default, if we have the
option we are okay, my only
Hi,
one of our developers mentioned that depth-n can be negative.
I didn't checked the whole code but even if depth-n is unsigned,
count is signed and can be negative by using a depth-n INT_MAX.
Is this a real problem or do we just hunt ghosts here?
On Wed, 14 Jan 2004, Alan Cox wrote:
I
Okay I wasn't as complete as I thought, the Mesa and the DRM I was using
were from the branch but I never updated my 2d driver, it was still the
old branch... so then I noticed something else which might cause problems
with the snapshots
When I updated and using the XFree86 from the snapshot
Keith Whitwell wrote:
Roland Scheidegger wrote:
When I was playing around with texenv (I'm trying to implement
GL_EXT_blend_func_separate and GL_EXT_blend_equation_separate for the
R200, though my attempts to modify texenv to make it a useful test for
that were unsuccesful), I've noticed that
Just to be sure, did you check out the savage-2-0-0-branch of DRI cvs?
do you see any files that start with 'savage' in
xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel?
Alex
hi,
at first i just pulled the head revision and extracted the tarball with
the 2d driver into
El Viernes, 13 de Febrero de 2004 01:29, Ville Syrjälä escribió:
mga? The poster said it was observed on ATI cards.
That's right. That's why I asked in the dri lists. I previously posted a
similar mail in debian-powerpc and Michel Dänzer suggested that the
problem could be DRI specific. I also
--- Georgi Hristov [EMAIL PROTECTED] wrote:
Just to be sure, did you check out the savage-2-0-0-branch of DRI
cvs?
do you see any files that start with 'savage' in
xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel?
Alex
hi,
at first i just pulled the head
Am I missing something -- isn't this setting the appropriate blend
modes? Is the constant color not getting updated correctly?
Yes, exactly, the constant color isn't updated at all (so the color is
_really_ constant ;-)). Mesa would call ctx-Driver.BlendColor to inform
the driver of the
On Tue, 10 Feb 2004 22:38:58 +
Sérgio Monteiro Basto [EMAIL PROTECTED] wrote:
[snip]
Well looking at rubik cube screen saver, we have (I think) one bug that
I think I know this bug from mesa code in same source, so update the
Mesa code may could be a good idea, that I am able to do it, but
Keith Whitwell wrote:
Am I missing something -- isn't this setting the appropriate
blend modes? Is the constant color not getting updated
correctly?
Yes, exactly, the constant color isn't updated at all (so the color
is _really_ constant ;-)). Mesa would call ctx-Driver.BlendColor
to
Ian Romanick wrote:
Anyone know of any good, simple pbuffers tests? :)
The ATI fglrx linux driver contains source code (the rpm installs it
under /usr/src/ATI) for an enhanced glxgears that renders glxgears to a
rotating cube using pbuffers, along with some documentation on using
pbuffers in
Roland Scheidegger wrote:
Keith Whitwell wrote:
Am I missing something -- isn't this setting the appropriate blend
modes? Is the constant color not getting updated correctly?
Yes, exactly, the constant color isn't updated at all (so the color
is _really_ constant ;-)). Mesa would call
El Viernes, 13 de Febrero de 2004 16:22, Brian Paul escribió:
No, not glPushAttrib(). glPopAttrib() is where the problem probably
occurs.
Sorry, my mistake O:-)
Great.
I attach a very stupid program. It draws two cubes (one big blue, and
another red small). Press 'r' to rotate both. I use
Roland Scheidegger wrote:
Keith Whitwell wrote:
ok, I'll try to implement it. This register is just before the
ABLENDCNTL and CBLENDCNTL, so that makes it easier to support these (for
the GL_EXT_blend_xx_separate extensions) at the same time. Unfortunately
requires a drm change, and unfortunately
Keith Whitwell wrote:
As far as I can see though this would get very ugly, with lots of if
drm_version code. And it might not be necessary (for instance if the
BLENDCNTL register just mirrors the CBLENDCNTL, but leaves the
values in ABLENDCNTL alone then it would be no problem at all). Maybe
El Viernes, 13 de Febrero de 2004 22:59, Roland Scheidegger escribió:
I've just tested this demo here (r200 driver) and it works fine (the big
cube remains blue, the red remains red).
Which snapshot of DRI are you using ? I've got one from 2003-10-05... ,
too old :-/
I'm not sure, but
Roland Scheidegger wrote:
Keith Whitwell wrote:
As far as I can see though this would get very ugly, with lots of if
drm_version code. And it might not be necessary (for instance if the
BLENDCNTL register just mirrors the CBLENDCNTL, but leaves the
values in ABLENDCNTL alone then it would be
Just tried ut2003 on R100 with current DRI+MESA cvs HEAD.
Now with the MULT-code in radeon_state.c radeon_state_init.c
(change lighting to use MULT instead of PREMULT ...)
the shading/lighting of warriors changed a little bit in tcl-mode.
It's been buggy before in tcl-mode, but differently.
Now
Andreas Stenglein wrote:
Just tried ut2003 on R100 with current DRI+MESA cvs HEAD.
Now with the MULT-code in radeon_state.c radeon_state_init.c
(change lighting to use MULT instead of PREMULT ...) the
shading/lighting of warriors changed a little bit in tcl-mode.
It's been buggy before in
#lspci -n
00:00.0 Class 0600: 1106:0305 (rev 80)
00:01.0 Class 0604: 1106:8305
00:07.0 Class 0601: 1106:0686 (rev 42)
00:07.1 Class 0101: 1106:0571 (rev 06)
00:07.2 Class 0c03: 1106:3038 (rev 1a)
00:07.4 Class 0680: 1106:3057 (rev 40)
00:07.5 Class 0401: 1106:3058 (rev 50)
00:09.0 Class 0780:
On Fri, Feb 13, 2004 at 11:52:05PM +0100, Andreas Stenglein wrote:
Just tried ut2003 on R100 with current DRI+MESA cvs HEAD.
I just tried it on my Radeon 9100 and Athlon XP 1800+.
OpenGL renderer string: Mesa DRI R200 20030328 AGP 4x x86/MMX+/3DNow!+/SSE TCL
OpenGL version string: 1.3 Mesa 6.1
Am Samstag, 14. Februar 2004 00:13 schrieb Sérgio Monteiro Basto:
#lspci -n
00:00.0 Class 0600: 1106:0305 (rev 80)
00:01.0 Class 0604: 1106:8305
00:07.0 Class 0601: 1106:0686 (rev 42)
00:07.1 Class 0101: 1106:0571 (rev 06)
00:07.2 Class 0c03: 1106:3038 (rev 1a)
00:07.4 Class 0680: 1106:3057
When I updated and using the XFree86 from the snapshot directory, I was
missing an I2C symbol, the ati driver in DRI CVS seems to need a newer
version of libi2c.a, mine was from Fedora Core 1...
The 2d driver builds now but 3d seems to crap it out .. it'll be a day or
two until I figure it
Ian Romanick wrote:
Roland Scheidegger wrote:
Keith Whitwell wrote:
As far as I can see though this would get very ugly, with lots
of if drm_version code. And it might not be necessary (for
instance if the BLENDCNTL register just mirrors the
CBLENDCNTL, but leaves the values in ABLENDCNTL alone
On Sat, 2004-02-14 at 00:11, Roland Scheidegger wrote:
Just the other day, I've noticed not even the good old tuxracer runs
correct on the R100 on my 2nd PC - the ice areas flickered a lot,
That's a long standing tuxracer bug, Z fighting between several passes.
but it runs fine on R200.
On Gwe, 2004-02-13 at 11:31, Thomas Biege wrote:
Hi,
one of our developers mentioned that depth-n can be negative.
I didn't checked the whole code but even if depth-n is unsigned,
count is signed and can be negative by using a depth-n INT_MAX.
Is this a real problem or do we just hunt
On Sat, 2004-02-14 at 00:04, Dieter Nützel wrote:
BTW, could you be more specific what's wrong with the rubik cube demo? I
don't see any errors with it.
The bug is in some depths of the image for example in queens screen
saver, some queens in the back overlaps the queens in
Michel Dnzer wrote:
On Sat, 2004-02-14 at 00:11, Roland Scheidegger wrote:
Just the other day, I've noticed not even the good old tuxracer runs
correct on the R100 on my 2nd PC - the ice areas flickered a lot,
That's a long standing tuxracer bug, Z fighting between several passes.
but it
you sure you were running top of tree?
Yeah, I did this patch with cvs diff -u in my mach64-0-0-7-branch check out.
That should work right?
I fixed this a while back in
http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xf
I just caught on to something - the Gatos 3D driver that's been
referred to as the cause of my woes. While reading the documentation
(http://dri.sourceforge.net/cgi-bin/moin.cgi/DriverFiles) I realized
that the 3D driver is under xc/lib/GL/mesa/src/drv. The Gatos folks
distribute that as a patch
32 matches
Mail list logo
