[Dri-devel] Re: r200 texture problems

2004-01-27 Thread Michel Dänzer
On Sat, 2004-01-24 at 15:28, Keith Whitwell wrote:
 Michel Dnzer wrote:
  On Fri, 2004-01-23 at 03:45, Michel Dnzer wrote:
  
 On Fri, 2004-01-23 at 02:28, Michel Dnzer wrote:
 
 [...] most if not all textured apps spew
 
 [driAllocateTexture:577] unable to allocate texture
 
 all over the place and seem to fall back to software rendering. In
 contrast to the other problem, this doesn't occur on R100. Reverting
 Ian's commit from Wednesday doesn't help.
  
  But reverting Mesa/src/mesa/drivers/dri/common/texmem.c to revision 1.3
  does. Keith, any idea what's up there?
 
 I've lost the beginning of this thread - 

That's fine, this problem isn't related to that. :)

 how should I reproduce the problem?

Start any textured app (e.g. the xscreensaver lament hack) with current
libGL from DRI CVS and current r200 driver from Mesa CVS.


-- 
Earthling Michel Dnzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] Re: libGL backwards compatibility broken

2004-01-27 Thread Michel Dänzer
On Fri, 2004-01-23 at 03:45, Michel Dnzer wrote:
 On Fri, 2004-01-23 at 02:28, Michel Dnzer wrote:
  
  [...] (works with current libGL):
 
 Actually, most if not all textured apps spew
 
 [driAllocateTexture:577] unable to allocate texture
 
 all over the place and seem to fall back to software rendering. In
 contrast to the other problem, this doesn't occur on R100. Reverting
 Ian's commit from Wednesday doesn't help.

But reverting Mesa/src/mesa/drivers/dri/common/texmem.c to revision 1.3
does. Keith, any idea what's up there?


-- 
Earthling Michel Dnzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] radeon bugs

2004-01-27 Thread Alan Hourihane
On Tue, Jan 27, 2004 at 07:38:59PM +, Keith Whitwell wrote:
 This is a good time to remind people/establish the principle that driver 
 bug fixes should be propogated to the mesa-6_0_branch of the Mesa 
 repository. Brian's always done a good job of making sure core mesa fixes 
 get copied over, but it shouldn't come down to him alone.
 
 In particular, the recent TCL lighting fixes for the radeon  r200 drivers 
 should get pushed down into Mesa 6.0.

Do we want to bring Mesa 6.0's branch into the DRI repository now or
stick with the way we have it currently ?

I guess if we stick with the way it is now, then most developers will
track Mesa's trunk and we may start to lag stable releases.

Alan.


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] radeon bugs

2004-01-27 Thread Keith Whitwell
Alan Hourihane wrote:
On Tue, Jan 27, 2004 at 07:38:59PM +, Keith Whitwell wrote:

This is a good time to remind people/establish the principle that driver 
bug fixes should be propogated to the mesa-6_0_branch of the Mesa 
repository. Brian's always done a good job of making sure core mesa fixes 
get copied over, but it shouldn't come down to him alone.

In particular, the recent TCL lighting fixes for the radeon  r200 drivers 
should get pushed down into Mesa 6.0.


Do we want to bring Mesa 6.0's branch into the DRI repository now or
stick with the way we have it currently ?
I guess if we stick with the way it is now, then most developers will
track Mesa's trunk and we may start to lag stable releases.
I like the way we have it now, to be truthful.  If we develop on a branch or 
branches, we get little or no testing, and we really want testing.

If someone wants a stable branch, they will be able to get one.  It doesn't 
take too much effort to ensure bugfixes make their way onto the stable branch 
also.  If someone has a bug with the stable branch, the information that it is 
fixed on the trunk will help track it down.

What I'd really like to be able to do now is build the dri drivers directly 
out of the Mesa tree.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] radeon bugs

2004-01-27 Thread Alan Hourihane
On Tue, Jan 27, 2004 at 08:41:45PM +, Keith Whitwell wrote:
 Alan Hourihane wrote:
 On Tue, Jan 27, 2004 at 07:38:59PM +, Keith Whitwell wrote:
 
 This is a good time to remind people/establish the principle that driver 
 bug fixes should be propogated to the mesa-6_0_branch of the Mesa 
 repository. Brian's always done a good job of making sure core mesa fixes 
 get copied over, but it shouldn't come down to him alone.
 
 In particular, the recent TCL lighting fixes for the radeon  r200 
 drivers should get pushed down into Mesa 6.0.
 
 
 Do we want to bring Mesa 6.0's branch into the DRI repository now or
 stick with the way we have it currently ?
 
 I guess if we stick with the way it is now, then most developers will
 track Mesa's trunk and we may start to lag stable releases.
 
 I like the way we have it now, to be truthful.  If we develop on a branch 
 or branches, we get little or no testing, and we really want testing.
 
I actually agree with you on this Keith. It's just too much of a pain
to keep merging back and forward.

 If someone wants a stable branch, they will be able to get one.  It doesn't 
 take too much effort to ensure bugfixes make their way onto the stable 
 branch also.  If someone has a bug with the stable branch, the information 
 that it is fixed on the trunk will help track it down.
 
O.k.

 What I'd really like to be able to do now is build the dri drivers directly 
 out of the Mesa tree.

Definately. Slate that up for 6.1, I'll certainly work on that issue.

Alan.


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] radeon bugs

2004-01-27 Thread Keith Whitwell
Alan Hourihane wrote:


What I'd really like to be able to do now is build the dri drivers directly 
out of the Mesa tree.


Definately. Slate that up for 6.1, I'll certainly work on that issue.
It's not too hard - I had it working on the embedded branch a while ago.

In general, the Mesa make system could use a little modernization and spring 
cleaning.  It'd be nice to see what improvements could be made with minimal or 
no additional toolchain requirements.

Again - the embedded branch has/had a nice build system, although one that 
relied (very minimally) on GNU make.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] radeon bugs

2004-01-27 Thread Alex Deucher

--- Alan Hourihane [EMAIL PROTECTED] wrote:
 On Tue, Jan 27, 2004 at 07:38:59PM +, Keith Whitwell wrote:
  This is a good time to remind people/establish the principle that
 driver 
  bug fixes should be propogated to the mesa-6_0_branch of the Mesa 
  repository. Brian's always done a good job of making sure core mesa
 fixes 
  get copied over, but it shouldn't come down to him alone.
  
  In particular, the recent TCL lighting fixes for the radeon  r200
 drivers 
  should get pushed down into Mesa 6.0.
 
 Do we want to bring Mesa 6.0's branch into the DRI repository now or
 stick with the way we have it currently ?

I'm not sure I see the use.  it's too late for xfree 4.4 and it'll be
too old for 4.5 since by that time we'll be on to mesa 7 or 8.

 
 I guess if we stick with the way it is now, then most developers will
 track Mesa's trunk and we may start to lag stable releases.
 

I think it's easier to have them in mesa, so that we can track the
latest mesa fixes/features in the 3d drivers, but I'm not an expert.
the only problem I can see is that we would have to merge mesa and dri
into xfree86 when we did merges.  either that or just package them
separately.  if a user wants 3D she/he will have to install a mesa
package.  then users can upgrade 3D without needing a new xfree86.

Alex


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] radeon bugs

2004-01-27 Thread Alan Hourihane
On Tue, Jan 27, 2004 at 01:17:20PM -0800, Alex Deucher wrote:
 
 --- Alan Hourihane [EMAIL PROTECTED] wrote:
  On Tue, Jan 27, 2004 at 07:38:59PM +, Keith Whitwell wrote:
   This is a good time to remind people/establish the principle that
  driver 
   bug fixes should be propogated to the mesa-6_0_branch of the Mesa 
   repository. Brian's always done a good job of making sure core mesa
  fixes 
   get copied over, but it shouldn't come down to him alone.
   
   In particular, the recent TCL lighting fixes for the radeon  r200
  drivers 
   should get pushed down into Mesa 6.0.
  
  Do we want to bring Mesa 6.0's branch into the DRI repository now or
  stick with the way we have it currently ?
 
 I'm not sure I see the use.  it's too late for xfree 4.4 and it'll be
 too old for 4.5 since by that time we'll be on to mesa 7 or 8.

I think you missed my point. It had no relation to XFree86 4.4.0.

Alan.


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] radeon bugs

2004-01-27 Thread Michel Dänzer
On Tue, 2004-01-27 at 21:41, Keith Whitwell wrote:
 Alan Hourihane wrote:
  
  Do we want to bring Mesa 6.0's branch into the DRI repository now or
  stick with the way we have it currently ?
  
  I guess if we stick with the way it is now, then most developers will
  track Mesa's trunk and we may start to lag stable releases.
 
 I like the way we have it now, to be truthful.  If we develop on a branch or 
 branches, we get little or no testing, and we really want testing.

Agreed. What about a branch corresponding to the Mesa stable branch
though? Then David could grab that for XFree86.


 What I'd really like to be able to do now is build the dri drivers directly 
 out of the Mesa tree.

Indeed, that'd be very nice.


-- 
Earthling Michel Dnzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Dri-devel] Re: Re: Machine hangs/screen hangs with newer kernels + GL screensavers

2004-01-27 Thread Michel Dänzer
On Wed, 2004-01-21 at 22:57, Marco van Zwetselaar wrote:
 Michel Daenzer wrote:
   Ariel Garcia wrote:
both on my desktop and my laptop i am getting strange hangs
when running XFree packages (both debian testing/unstable,
4.2.1-{12.1,15}) with the newer linux kernels. This happens
for me since one of the 2.5.5* kernels (and it still happens

BTW, it'd be interesting to know which 2.5.x kernel exactly it stopped
working at.

with 2.6.0) and now i also checked the same happens with
4.2.23 (but doesn't happen with 4.2.22).

[...]

 I can confirm this.  I got just the same problem on my laptop, a Dell 
 with an ATI Radeon card, X version 4.2.1-12.1.  When I start glxgears on 
 kernel 2.4.23 or 2.6.0-test9, it all hangs.  No problems on 2.4.22 (or 
 earlier), which were configured just the same as .23, apart from the low 
 latency patches (which aren't available yet for .23).

Sounds like the radeon DRM broke backwards compatibility for XFree86 4.2
and older somewhere along the way. :( Just to be sure, can either of you
please try the DRM from current DRI CVS?

 Should I file a bug in the BTS?

Against what, the kernel packages? I'm not sure that'll be too useful,
CC'ing the dri-devel list.


-- 
Earthling Michel Dnzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] radeon bugs

2004-01-27 Thread Alan Hourihane
On Wed, Jan 28, 2004 at 12:25:23AM +0100, Michel Dänzer wrote:
 On Tue, 2004-01-27 at 21:41, Keith Whitwell wrote:
  Alan Hourihane wrote:
   
   Do we want to bring Mesa 6.0's branch into the DRI repository now or
   stick with the way we have it currently ?
   
   I guess if we stick with the way it is now, then most developers will
   track Mesa's trunk and we may start to lag stable releases.
  
  I like the way we have it now, to be truthful.  If we develop on a branch or 
  branches, we get little or no testing, and we really want testing.
 
 Agreed. What about a branch corresponding to the Mesa stable branch
 though? Then David could grab that for XFree86.
 
It's currently mesa_6_0_branch. 

Alan.


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] radeon bugs

2004-01-27 Thread Michel Dänzer
On Wed, 2004-01-28 at 00:28, Alan Hourihane wrote:
 On Wed, Jan 28, 2004 at 12:25:23AM +0100, Michel Dnzer wrote:
  
  What about a branch corresponding to the Mesa stable branch though? 
  Then David could grab that for XFree86.
  
 It's currently mesa_6_0_branch. 

Yes, I mean a corresponding branch in DRI CVS.


-- 
Earthling Michel Dnzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Dri-devel] mesa test failures with radeon (7200)

2004-01-27 Thread Roland Scheidegger
Just for fun, tried all mesa demos/tests etc. with a radeon 7200 sdr.

redbook/alpha3d: nothing is seen unless a is pressed (and then only for 
a very short time, buffering problem? (same as with r200)

samples/fog: the red part seems to have the fog applied quite 
differently than with software mesa.

samples/prim: the top right rectangle (I believe that's the quad strip) 
has a wrong color pattern (both with smooth and flat shade model, 
correct with poly line mode which uses fallback) - assuming that 
software mesa is correct of course, I have really no idea...
Also, cycling through the colors, the original color pattern will never 
come back with software mesa - it will be completely blue instead. This 
works correctly with hardware acceleration.

samples/tri: basically works, but seems to trigger a bug in software 
mesa (with LD_LIBRARY_PATH pointing to the standalone Mesa GL lib) for 
some reason sometimes. I couldn't figure out what keys need to be 
pressed exactly to trigger the bug, but it seems quite easy to 
reproduce.  It will chew up all memory until the kernel kills it. At one 
time I was able to get some gdb output, looks the crash reason is some 
recursive loop:
#0  0x40210172 in _tnl_copy_pv () from ../../lib/libGL.so.1
#1  0x40212382 in generic_copy_pv_extras () from ../../lib/libGL.so.1
#2  0x40210184 in _tnl_copy_pv () from ../../lib/libGL.so.1
#3  0x40212382 in generic_copy_pv_extras () from ../../lib/libGL.so.1
#4  0x40210184 in _tnl_copy_pv () from ../../lib/libGL.so.1
#5  0x40212382 in generic_copy_pv_extras () from ../../lib/libGL.so.1
#6  0x40210184 in _tnl_copy_pv () from ../../lib/libGL.so.1
#7  0x40212382 in generic_copy_pv_extras () from ../../lib/libGL.so.1
#8  0x40210184 in _tnl_copy_pv () from ../../lib/libGL.so.1
#9  0x40212382 in generic_copy_pv_extras () from ../../lib/libGL.so.1
(continued almost indefinitely, gdb was unable to get the outermost 
frames unfortunately)
Doesn't seem to happen with hardware acceleration, but I'm not sure.

xdemos/wincopy: second window empty (or random content) (same as with r200)

seccolor: crashes with
seccolor: radeon_state.c:741: radeonUpdateSpecular: Assertion `(p  (1 
 21)) == 0' failed
#3  0x401bf42f in __assert_fail () from /lib/i686/libc.so.6
#4  0x40598425 in radeonUpdateSpecular (ctx=0x8059a98) at radeon_state.c:741
#5  0x404a5608 in _mesa_set_enable (ctx=0x8059a98, cap=33880, state=1 
'\001')
at enable.c:991
#6  0x404a78cd in _mesa_Enable (cap=33880) at enable.c:1012
(this bug can also be triggered by demos/spectex)
The assertion fails because the derived mesa state ctx-_TriangleCaps 
will only get calculated later. Removing the assertion makes seccolor 
work correctly.

stencilwrap: fails every test (always returns 0 or 255, respectively).

I also get:
glxinfo: radeon_tex.c:696: radeonDeleteTexture: Assertion `t' failed.
as well as application crashes when OGL applications (for instance 
QuakeIII) exit (this problem was present with r200 too but has already 
been fixed?).

Roland

---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Dri-devel] undefined reference to '_mesa_init_driver_functions'

2004-01-27 Thread Dieter Ntzel
uilding shared library /opt/VTK/V4.0/VTK/bin/libvtkParallelJava.so...
Building shared module /opt/VTK/V4.0/VTK/bin/libvtkParallelPython.so...
Building shared library /opt/VTK/V4.0/VTK/bin/libvtkParallelTCL.so...
./Wrapping/Tcl: building default_target
Building dependencies. cmake.depends...
Building object file vtkTkAppInit.o...
Building executable ../../../VTK/bin/vtk...
/usr/X11R6/lib/libOSMesa.so: undefined reference to 
`_mesa_init_driver_functions'
collect2: ld returned 1 exit status
make[3]: *** [../../../VTK/bin/vtk] Fehler 1
make[2]: *** [default_target] Fehler 2
make[1]: *** [default_target_Wrapping_Tcl] Fehler 2
make: *** [default_target] Fehler 2

What's wrong?

Cheers,
Dieter


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Dri-devel] ATI IGP340M on 2.6 Success report

2004-01-27 Thread Luis R. Rodriguez

I've built DRI CVS along with Mesa CVS to get test my IGP340M on the 2.6.1
kernel. I'd like to report success. Note: this chipset has no TCL.

glinfo (I cut GL_EXTENSIONS from here):
disabling TCL support
GL_VERSION: 1.2 Mesa 6.1
GL_RENDERER: Mesa DRI Radeon 20030328 AGP 4x x86/MMX/SSE2 NO-TCL
GL_VENDOR: Tungsten Graphics, Inc.
GLU_VERSION: 1.3
GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess
GLUT_API_VERSION: 3
GLUT_XLIB_IMPLEMENTATION: 13

If anyone complains of getting the following errors at startx:

mtrr: 0xf800,0x200 overlaps existing 0xf800,0x100
mtrr: 0xf800,0x200 overlaps existing 0xf800,0x100
[drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
[drm:radeon_unlock] *ERROR* Process 13128 using kernel context 0

where process 13128 is X, tell them to make sure to load ati_igp if they
enabled it as a module (2.6 now has the option to enable this as a
module).

Mesa demos results:

@ 1024x768 @ 16bpp:

glxgears reports:
2243 frames in 5.0 seconds = 448.600 FPS
2475 frames in 5.0 seconds = 495.000 FPS
2476 frames in 5.0 seconds = 495.200 FPS

tunnel reports 52 FPS

fire reports 31.8 FPS

On `reflect` I see the reflection of the objects in stripes, not sure if
this is how its supposed to look like.

gloss:
537 frames in 5 seconds = 107.4 FPS
541 frames in 5.004 seconds = 108.114 FPS

Quake 3 is next ;)

Luis



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] ATI IGP340M on 2.6 Success report

2004-01-27 Thread Luis R. Rodriguez


 If anyone complains of getting the following errors at startx:

 mtrr: 0xf800,0x200 overlaps existing 0xf800,0x100
 mtrr: 0xf800,0x200 overlaps existing 0xf800,0x100
 [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
 [drm:radeon_unlock] *ERROR* Process 13128 using kernel context 0

 where process 13128 is X, tell them to make sure to load ati_igp if they
 enabled it as a module (2.6 now has the option to enable this as a
 module).

strikeati_igp/strike

it's ati_agp ;)

Luis



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Dri-devel] r200 texrect (current mesa/dri cvs) trouble

2004-01-27 Thread Roland Scheidegger
(since the original email never made it to the list, a new one - it's 
not a resend though)

texrect is broken here (and I've no idea why it works for other people ;-)).
There are 2 problems in the driver which cause this:
First, if glGenTextures is called, there is no texture target yet. This 
will cause the r200 driver (in r200AllocTexObj) to initialize the 
texture min filter to GL_NEAREST_MIPMAP_LINEAR. The problem is when the 
texture object is now bound to a RECTANGLE_NV target, the min filter 
will not change, causing havoc (the also illegal clamp mode doesn't seem 
to hurt much).
Second problem is the r200TexParameter, it will only do anything for 1D 
and 2D targets - thus, even if an application explicitly sets a 
different texture filter, the hardware will still try to use mipmapping 
for rectangle targets. Removing the target condition will fix this (why 
is it there? Mesa already should have checked illegal combinations, or 
are there some OGL compliant target/param combinations which are not 
supported in hardware?)
Both problems are also present in the radeon driver, but texrect seems 
to work there nonetheless...

attached a quick patch (only for r200, and I doubt it will attach 
cleanly, but I guess it's too ugly anyway).

Roland
Index: r200_tex.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_tex.c,v
retrieving revision 1.12
diff -u -r1.12 r200_tex.c
--- r200_tex.c  26 Jan 2004 23:57:19 -  1.12
+++ r200_tex.c  28 Jan 2004 01:47:05 -
@@ -297,10 +297,10 @@
 
   make_empty_list(  t-base );
 
-  r200SetTexWrap( t, texObj-WrapS, texObj-WrapT, texObj-WrapR );
+/*  r200SetTexWrap( t, texObj-WrapS, texObj-WrapT, texObj-WrapR );
   r200SetTexMaxAnisotropy( t, texObj-MaxAnisotropy );
   r200SetTexFilter( t, texObj-MinFilter, texObj-MagFilter );
-  r200SetTexBorderColor( t, texObj-_BorderChan );
+  r200SetTexBorderColor( t, texObj-_BorderChan );*/
}
 
return t;
@@ -888,9 +1070,9 @@
   _mesa_lookup_enum_by_nr( pname ) );
}

-   if ( ( target != GL_TEXTURE_2D ) 
+/*   if ( ( target != GL_TEXTURE_2D ) 
( target != GL_TEXTURE_1D ) )
-  return;
+  return;*/

switch ( pname ) {
case GL_TEXTURE_MIN_FILTER:
@@ -950,6 +1132,13 @@
|| (target == GL_TEXTURE_RECTANGLE_NV) ) {
   assert( texObj-DriverData != NULL );
}
+  r200TexObj * t = (r200TexObj *) texObj-DriverData;
+
+  r200SetTexWrap( t, texObj-WrapS, texObj-WrapT, texObj-WrapR );
+  r200SetTexMaxAnisotropy( t, texObj-MaxAnisotropy );
+  r200SetTexFilter( t, texObj-MinFilter, texObj-MagFilter );
+  r200SetTexBorderColor( t, texObj-_BorderChan );
+
 }
 
 


Re: [Dri-devel] r200 texrect (current mesa/dri cvs) trouble

2004-01-27 Thread Roland Scheidegger
Sorry for the spam, but I forgot another thing:
in r200UploadRectSubImage, shouldn't r200AllocDmaRegion just call for a 
1024 byte alignment (since the blit offset looks like it needs to be 
1024 byte aligned)? That'll get rid of the failed assertion with texrect 
when using 16bit textures - the radeon driver already uses 1024 byte 
alignment. Also, the region.address used looks ugly - wouldn't it better 
to use region.address + region.start (I'm not sure how exactly that 
dma/region mechanism works, but I'd guess it might be possible that 
there is some other region used already in the same dma buffer which 
would get overwritten).

Roland

---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] radeon bugs

2004-01-27 Thread Otto Solares
On Tue, Jan 27, 2004 at 08:41:45PM +, Keith Whitwell wrote:
 What I'd really like to be able to do now is build the dri drivers directly 
 out of the Mesa tree.

Does this means that finally we will see XFree and linux-solo build
it's drivers from Mesa-newtree/src/drivers/dri or this is not the
case yet?

-solca



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Dri-devel] i810 breakage in past few days..

2004-01-27 Thread Dave Airlie

the i810 got broken by the texture changes over the last few days, the
imesa-i810Screen pointer wasn't setup before the call to
mesa_create_context and it in turn called i810SetTexFilter which used
IS_I815 which used i810Screen, I've checked in a fix (I've just moved all
the pointer assignments before the function calls ..)

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] another texture compression patch (hopefully IP safe)

2004-01-27 Thread Roland Scheidegger
Dieter Nützel wrote:
Am Freitag, 16. Januar 2004 20:00 schrieb Roland Scheidegger:

ok, here's another attempt, which uses an external dxtn library (patch
against current Mesa cvs trunk).


And, again? - After texture merge.
since you've asked ;-)

fixes:
- the dlopen stuff will no longer be built into libGLcore.a, so no more 
unresolved symbols and indirect rendering should work again (of course, 
without s3tc support). It will still break the build of mesa on 
platforms which don't support dlopen
- some minor flaw fixed in the radeon and r200 texstate.c regarding to 
valid texture formats
- should hopefully apply to mesa cvs again ;-)

the compression library also got an update:
- better handling of small color gradients (doesn't help much for Quake 
III high quality sky unfortunately)
- very minor code cleanup, some small bugs fixed
- it should be faster - thanks to the inclusion of the -O3 flag I forgot 
last time ;-)
Sometimes it still produces completely wrong colors. I've only seen this 
with forced compression via driconf on textures with an alpha component, 
it might or might not be because even values which are completely 
transparent (and thus might have a completely arbitrary color value in 
the original) are used for the base color search.

Roland


libtxc_dxtn.tar.gz
Description: Unix tar archive


mesa_r200_radeon_txc.diff.gz
Description: Unix tar archive


[Dri-devel] radeon bugs

2004-01-27 Thread David Dawes
There are quite a few Radeon-related bugs still outstanding in
bugs.xfree86.org, including several related to DRI lockups.

Has anyone followed them up?

David
-- 
David Dawes
developer/release engineer  The XFree86 Project
www.XFree86.org/~dawes


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] radeon bugs

2004-01-27 Thread David Dawes
On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote:
On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote:
 There are quite a few Radeon-related bugs still outstanding in
 bugs.xfree86.org, including several related to DRI lockups.
 
 Has anyone followed them up?

David,

I suspect not with XFree86's DRI drivers still being based on Mesa 4.0.4,
and the DRI developers aren't tracking Mesa 4.0.x anymore.

We are at Mesa 5.0.2.  Doesn't the DRI project maintain a Mesa
5.0.x-based stable branch of some sort?

David
-- 
David Dawes
developer/release engineer  The XFree86 Project
www.XFree86.org/~dawes


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] radeon bugs

2004-01-27 Thread Keith Whitwell
David Dawes wrote:
On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote:

On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote:

There are quite a few Radeon-related bugs still outstanding in
bugs.xfree86.org, including several related to DRI lockups.
Has anyone followed them up?
David,

I suspect not with XFree86's DRI drivers still being based on Mesa 4.0.4,
and the DRI developers aren't tracking Mesa 4.0.x anymore.


We are at Mesa 5.0.2.  Doesn't the DRI project maintain a Mesa
5.0.x-based stable branch of some sort?
David,

The hardware drivers are now being maintained in the Mesa tree.  Mesa does 
have a set of stable branches but the only one containing the DRI drivers is 
too recent for your purposes - Mesa 6.0.

This is a good time to remind people/establish the principle that driver bug 
fixes should be propogated to the mesa-6_0_branch of the Mesa repository. 
Brian's always done a good job of making sure core mesa fixes get copied over, 
but it shouldn't come down to him alone.

In particular, the recent TCL lighting fixes for the radeon  r200 drivers 
should get pushed down into Mesa 6.0.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] radeon bugs

2004-01-27 Thread Alan Hourihane
On Tue, Jan 27, 2004 at 02:21:42PM -0500, David Dawes wrote:
 On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote:
 On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote:
  There are quite a few Radeon-related bugs still outstanding in
  bugs.xfree86.org, including several related to DRI lockups.
  
  Has anyone followed them up?
 
 David,
 
 I suspect not with XFree86's DRI drivers still being based on Mesa 4.0.4,
 and the DRI developers aren't tracking Mesa 4.0.x anymore.
 
 We are at Mesa 5.0.2.  Doesn't the DRI project maintain a Mesa
 5.0.x-based stable branch of some sort?

Whoops, sorry I meant to say 5.0.2. 

It's moved to Mesa 6.0 now, but I don't believe there's anyone maintaining
a stable 5.0.2 branch.

Alan.


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] radeon bugs

2004-01-27 Thread David Dawes
On Tue, Jan 27, 2004 at 07:52:32PM +, Alan Hourihane wrote:
On Tue, Jan 27, 2004 at 02:21:42PM -0500, David Dawes wrote:
 On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote:
 On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote:
  There are quite a few Radeon-related bugs still outstanding in
  bugs.xfree86.org, including several related to DRI lockups.
  
  Has anyone followed them up?
 
 David,
 
 I suspect not with XFree86's DRI drivers still being based on Mesa 4.0.4,
 and the DRI developers aren't tracking Mesa 4.0.x anymore.
 
 We are at Mesa 5.0.2.  Doesn't the DRI project maintain a Mesa
 5.0.x-based stable branch of some sort?

Whoops, sorry I meant to say 5.0.2. 

It's moved to Mesa 6.0 now, but I don't believe there's anyone maintaining
a stable 5.0.2 branch.

OK, no worries.

Are the still-open DRI-related bugs in bugs.xfree86.org fixed in Mesa 6.0?

David
-- 
David Dawes
developer/release engineer  The XFree86 Project
www.XFree86.org/~dawes


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] Minimal fix for the R128 drivers

2004-01-27 Thread David Dawes
On Wed, Jan 14, 2004 at 01:39:39PM +, Alan Cox wrote:
I think this is about the minimal fix needed. I'm not entirely happy
with the limits picked, especially for spans, but maybe someone with
an R128 can verify it is ok, or change the code to loop each chunk
of pixels/span data.

I've attached a version of the patch relative to the XFree86 version of
this code, which I'm also committing there.  Have there been any further
updates on this?

David
-- 
David Dawes
developer/release engineer  The XFree86 Project
www.XFree86.org/~dawes


I've not yet looked at the new SiS allocator problems in detail. The
6326 really wants a different allocator anyway.

Alan


--- drivers/char/drm/r128_state.c~ 2004-01-14 13:42:38.0 +
+++ drivers/char/drm/r128_state.c  2004-01-14 13:46:27.0 +
@@ -23,8 +23,20 @@
  * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
  * DEALINGS IN THE SOFTWARE.
  *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * RED HAT AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * THIS SOFTWARE IS NOT INTENDED FOR USE IN SAFETY CRITICAL SYSTEMS
+ *
  * Authors:
  *Gareth Hughes [EMAIL PROTECTED]
+ *
+ * Memory allocation size checks added 14/01/2003, Alan Cox [EMAIL PROTECTED]
  */
 
 #include r128.h
@@ -901,6 +913,9 @@
   DRM_DEBUG( %s\n, __FUNCTION__ );
 
   count = depth-n;
+  
+  if( count  4096 )
+  return -EMSGSIZE;
   if ( copy_from_user( x, depth-x, sizeof(x) ) ) {
   return -EFAULT;
   }
@@ -994,6 +1009,9 @@
   DRM_DEBUG( %s\n, __FUNCTION__ );
 
   count = depth-n;
+  
+  if( count  4096 )
+  return -EMSGSIZE;
 
   x = kmalloc( count * sizeof(*x), GFP_KERNEL );
   if ( x == NULL ) {
@@ -1109,6 +1127,9 @@
   DRM_DEBUG( %s\n, __FUNCTION__ );
 
   count = depth-n;
+  
+  if ( count  4096 )
+  return -EMSGSIZE;
   if ( copy_from_user( x, depth-x, sizeof(x) ) ) {
   return -EFAULT;
   }


Index: r128_state.c
===
RCS file: 
/home/x-cvs/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/r128_state.c,v
retrieving revision 1.5
diff -u -r1.5 r128_state.c
--- r128_state.c2 Dec 2003 13:02:43 -   1.5
+++ r128_state.c25 Jan 2004 02:55:20 -
@@ -23,8 +23,20 @@
  * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
  * DEALINGS IN THE SOFTWARE.
  *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * RED HAT AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * THIS SOFTWARE IS NOT INTENDED FOR USE IN SAFETY CRITICAL SYSTEMS
+ *
  * Authors:
  *Gareth Hughes [EMAIL PROTECTED]
+ *
+ * Memory allocation size checks added 14/01/2003, Alan Cox [EMAIL PROTECTED]
  */
 
 #include r128.h
@@ -915,6 +927,10 @@
DRM_DEBUG( \n );
 
count = depth-n;
+
+   if ( count  4096 )
+   return DRM_ERR(EMSGSIZE);
+
if ( DRM_COPY_FROM_USER( x, depth-x, sizeof(x) ) ) {
return DRM_ERR(EFAULT);
}
@@ -1009,6 +1025,9 @@
 
count = depth-n;
 
+   if ( count  4096 )
+   return DRM_ERR(EMSGSIZE);
+
xbuf_size = count * sizeof(*x);
ybuf_size = count * sizeof(*y);
x = DRM_MALLOC( xbuf_size );
@@ -1125,6 +1144,10 @@
DRM_DEBUG( \n );
 
count = depth-n;
+
+   if ( count  4096 )
+   return DRM_ERR(EMSGSIZE);
+
if ( DRM_COPY_FROM_USER( x, depth-x, sizeof(x) ) ) {
return DRM_ERR(EFAULT);
}