Re: [Dri-devel] Rage Fury Maxx
Speaking of r128's, does anyone know of any cheap notebooks with r128's in them? I'm thinking of trying to add dualhead support again. I wrote a patch a while back (check bugzilla), but without hardware (and docs at the time), I wasn't able to get it sorted out. iBook comes to mind.. older iBooks had r128. David Bronaugh Alex --- 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] mach64 and new tree
> > tomorrow (I'm GMT+10, should probably use .au a/c :-) > > > > I'll work on the XFree bits and the DRM should be similiar enough soon.. > > I think it should be fine to go in at Mesa head. Okay what about the DRI tree bits? DRM and changes to ATI driver?, should I go with mach64-0-0-7 or should I just make sure the ati bits work and not add mach64 to the host.def (I can see that messing up the snapshots a bit though), or maybe I just add a big huge warning to the DRM module and the X startup stating the mach64 DRM is inherently insecure and shouldn't be used on multi-user systems? 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] Rage Fury Maxx
--- Ryan Underwood <[EMAIL PROTECTED]> wrote: > > Anyone know anything about it? I just picked one up because it > looked > interesting (dual R128Pro chips). They are cheap now because there > is > no more driver support from ATI. I see on the DRI page that it is > unsupported but wondered if any folks with R128 docs had more info > about > it, esp how the two chips divide up rendering tasks. Also, was there > a > dual head version made? There is a place on the board for a second > VGA > connector, but I can't find any info about that either. > It was basically two rage128 chips on a single board. It looks like they could have been set up to drive multiple heads the way an appian or matrox mms board worked (one chip per head), although I know of no dualhead version. Each chip was wired to it's own bank of memory, so while the boards claimed to be 64 (?) MB they were really only 32. As I recall, the driver did some sort of AFR (alternative frame rendering) where each chip would render every other frame. I don't recall the boards ever really performing very well and I think there were issues with maintaining proper memory state on each chip. the drivers were ALWAYS buggy. It never really worked too well and I suspect that is why ATI eventually dropped it. You could probably get it to work with the r128 driver, but I doubt you could ever get both chips working. None of the r128 stuff from ATI I've seen has anything about the Maxx. Speaking of r128's, does anyone know of any cheap notebooks with r128's in them? I'm thinking of trying to add dualhead support again. I wrote a patch a while back (check bugzilla), but without hardware (and docs at the time), I wasn't able to get it sorted out. Alex > -- > Ryan Underwood, <[EMAIL PROTECTED]> > > ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html --- 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] Rage Fury Maxx
Anyone know anything about it? I just picked one up because it looked interesting (dual R128Pro chips). They are cheap now because there is no more driver support from ATI. I see on the DRI page that it is unsupported but wondered if any folks with R128 docs had more info about it, esp how the two chips divide up rendering tasks. Also, was there a dual head version made? There is a place on the board for a second VGA connector, but I can't find any info about that either. -- Ryan Underwood, <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: [Dri-devel] mesa / radeon / r200 texrect fixes
Ian Romanick wrote:
Roland Scheidegger wrote:
Here are the cleaned-up texrect fixes - last time there was still some
disagreement about how some things should be fixed.
If there are no objections I'm just going to try out my newly aquired
super-powers and commit it ;-).
Nervous about your first commit? :)
Yes, I thought I'd begin with something simple ;-)
With the exception of one minor
suggestion (below), the patch looks good to me.
Index: src/mesa/main/texobj.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/main/texobj.c,v
retrieving revision 1.81
diff -u -r1.81 texobj.c
--- src/mesa/main/texobj.c27 Jan 2004 16:34:46 -1.81
+++ src/mesa/main/texobj.c5 Feb 2004 00:03:38 -
@@ -818,7 +818,16 @@
newTexObj->WrapT = GL_CLAMP_TO_EDGE;
newTexObj->WrapR = GL_CLAMP_TO_EDGE;
newTexObj->MinFilter = GL_LINEAR;
- }
+if (ctx->Driver.TexParameter) {
+ GLfloat fparam[1];
+ fparam[0] = (GLfloat) GL_CLAMP_TO_EDGE;
I'd make this 'static const GLfloat fparam[1] = (GLfloat)
GL_CLAMP_TO_EDGE;'
You mean 'static const GLfloat fparam[1] = {(GLfloat) GL_CLAMP_TO_EDGE};
right? The compiler isn't happy about the other version ;-). Also, this
way two variables are needed, though I guess it's worth 4 bytes of
memory to make this nicer :-).
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] mesa / radeon / r200 texrect fixes
Roland Scheidegger wrote:
Here are the cleaned-up texrect fixes - last time there was still some
disagreement about how some things should be fixed.
If there are no objections I'm just going to try out my newly aquired
super-powers and commit it ;-).
Nervous about your first commit? :) With the exception of one minor
suggestion (below), the patch looks good to me.
Index: src/mesa/main/texobj.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/main/texobj.c,v
retrieving revision 1.81
diff -u -r1.81 texobj.c
--- src/mesa/main/texobj.c 27 Jan 2004 16:34:46 - 1.81
+++ src/mesa/main/texobj.c 5 Feb 2004 00:03:38 -
@@ -818,7 +818,16 @@
newTexObj->WrapT = GL_CLAMP_TO_EDGE;
newTexObj->WrapR = GL_CLAMP_TO_EDGE;
newTexObj->MinFilter = GL_LINEAR;
- }
+if (ctx->Driver.TexParameter) {
+ GLfloat fparam[1];
+ fparam[0] = (GLfloat) GL_CLAMP_TO_EDGE;
I'd make this 'static const GLfloat fparam[1] = (GLfloat) GL_CLAMP_TO_EDGE;'
+ (*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_WRAP_S, fparam );
+ (*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_WRAP_T, fparam );
+ (*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_WRAP_R, fparam );
+ fparam[0] = (GLfloat) GL_LINEAR;
+ (*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_MIN_FILTER, fparam );
+}
+ }
}
else {
/* if this is a new texture id, allocate a texture object now */
---
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 / radeon / r200 texrect fixes
Here are the cleaned-up texrect fixes - last time there was still some
disagreement about how some things should be fixed.
If there are no objections I'm just going to try out my newly aquired
super-powers and commit it ;-).
Roland
Index: src/mesa/drivers/dri/r200/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
--- src/mesa/drivers/dri/r200/r200_tex.c26 Jan 2004 23:57:19 - 1.12
+++ src/mesa/drivers/dri/r200/r200_tex.c5 Feb 2004 00:03:37 -
@@ -888,10 +888,6 @@
_mesa_lookup_enum_by_nr( pname ) );
}
- if ( ( target != GL_TEXTURE_2D ) &&
- ( target != GL_TEXTURE_1D ) )
- return;
-
switch ( pname ) {
case GL_TEXTURE_MIN_FILTER:
case GL_TEXTURE_MAG_FILTER:
Index: src/mesa/drivers/dri/r200/r200_texmem.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_texmem.c,v
retrieving revision 1.5
diff -u -r1.5 r200_texmem.c
--- src/mesa/drivers/dri/r200/r200_texmem.c 27 Jan 2004 16:34:46 - 1.5
+++ src/mesa/drivers/dri/r200/r200_texmem.c 5 Feb 2004 00:03:37 -
@@ -231,7 +231,7 @@
tex = (char *)texImage->Data + done * src_pitch;
memset(®ion, 0, sizeof(region));
-r200AllocDmaRegion( rmesa, ®ion, lines * dstPitch, 64 );
+r200AllocDmaRegion( rmesa, ®ion, lines * dstPitch, 1024 );
/* Copy texdata to dma:
*/
@@ -240,10 +240,10 @@
__FUNCTION__, src_pitch, dstPitch);
if (src_pitch == dstPitch) {
- memcpy( region.address, tex, lines * src_pitch );
+ memcpy( region.address + region.start, tex, lines * src_pitch );
}
else {
- char *buf = region.address;
+ char *buf = region.address + region.start;
int i;
for (i = 0 ; i < lines ; i++) {
memcpy( buf, tex, src_pitch );
Index: src/mesa/drivers/dri/radeon/radeon_tex.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_tex.c,v
retrieving revision 1.10
diff -u -r1.10 radeon_tex.c
--- src/mesa/drivers/dri/radeon/radeon_tex.c26 Jan 2004 23:57:19 - 1.10
+++ src/mesa/drivers/dri/radeon/radeon_tex.c5 Feb 2004 00:03:37 -
@@ -623,10 +623,6 @@
_mesa_lookup_enum_by_nr( pname ) );
}
- if ( ( target != GL_TEXTURE_2D ) &&
- ( target != GL_TEXTURE_1D ) )
- return;
-
switch ( pname ) {
case GL_TEXTURE_MIN_FILTER:
case GL_TEXTURE_MAG_FILTER:
Index: src/mesa/drivers/dri/radeon/radeon_texmem.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_texmem.c,v
retrieving revision 1.4
diff -u -r1.4 radeon_texmem.c
--- src/mesa/drivers/dri/radeon/radeon_texmem.c 27 Jan 2004 16:34:46 - 1.4
+++ src/mesa/drivers/dri/radeon/radeon_texmem.c 5 Feb 2004 00:03:37 -
@@ -135,10 +135,10 @@
__FUNCTION__, src_pitch, dstPitch);
if (src_pitch == dstPitch) {
- memcpy( region.address, tex, lines * src_pitch );
+ memcpy( region.address + region.start, tex, lines * src_pitch );
}
else {
- char *buf = region.address;
+ char *buf = region.address + region.start;
int i;
for (i = 0 ; i < lines ; i++) {
memcpy( buf, tex, src_pitch );
Index: src/mesa/main/texobj.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/main/texobj.c,v
retrieving revision 1.81
diff -u -r1.81 texobj.c
--- src/mesa/main/texobj.c 27 Jan 2004 16:34:46 - 1.81
+++ src/mesa/main/texobj.c 5 Feb 2004 00:03:38 -
@@ -818,7 +818,16 @@
newTexObj->WrapT = GL_CLAMP_TO_EDGE;
newTexObj->WrapR = GL_CLAMP_TO_EDGE;
newTexObj->MinFilter = GL_LINEAR;
- }
+if (ctx->Driver.TexParameter) {
+ GLfloat fparam[1];
+ fparam[0] = (GLfloat) GL_CLAMP_TO_EDGE;
+ (*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_WRAP_S, fparam );
+ (*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_WRAP_T, fparam );
+ (*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_WRAP_R, fparam );
+ fparam[0] = (GLfloat) GL_LINEAR;
+ (*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_MIN_FILTER, fparam );
+}
+ }
}
else {
/* if this is a new texture id, allocate a texture object now */
Re: [Dri-devel] GL_VERSION 1.5 when indirect rendering?
Andreas Stenglein wrote: Am 2004.02.04 21:00:14 +0100 schrieb(en) Brian Paul: Ian Romanick wrote: [snip] Making that change and changing the server-side to not advertise a core version that it can't take protocol for would fix the bug for 4.4.0. Do you think anything should be done to preserve text after the version? That is, if a server sends us "1.4.20040108 Foobar, Inc. Fancypants GL", should we return "1.2" or something more elaborate? It would be nice to preserve the extra text, but it's not essential. why not just add the "1.2 " before the original text? 1.2 1.4.20040108 Foobar, Inc. Fancypants GL so you would see that the renderer could support 1.4 if GLX could do it. Yeah, I guess that could be done. -Brian --- 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] r200 new "revolutionary" lighting
Roland Scheidegger wrote: > Keith Whitwell wrote: > >> The rendering errors are a harder problem though, I can see now why > >> the material between begin/end fallback was needed in the first place. > >> There doesn't seem to be an easy way currently to submit material > >> changes between vertices, so it looks like the fallback needs to stay > >> (even though it doesn't really seem to work correctly neither for some > >> reason). > > > > > > Certainly the bug with the current code should be resolved - I can't > > think it's too difficult - as the r100 will need it. > > > > The r200 *can* do material changes inside begin/end - basically by using > > the R200_LM1_SOURCE_VERTEX_COLOR_0..7 arrays to track the material > > attributes and then wiring each of these up just like in the > > glColorMaterial case. > I don't doubt the *chip* can do - I just doubt *I* can do it ;-). > Wouldn't it be necessary (and sufficient) just to update the two (front > and back) materials, or are you suggesting that it's necessary to send > the materials along with the other vertex parameters such as the > normals, colors etc. > But updating the current materials would mean that the vertices up to > now have to be flushed (?), since as far as I understand the driver it > doesn't allow vertex data to be mixed arbitrarily with other state > change commands. I'll admit though I don't understand it really... > I tried to implement something like that as a quick hack - it fixed the > errors, but looking a bit closer not for the reasons I thought it might > help. I just called _tnl_FlushVertices( ctx, ~0 ) at the end of > _tnl_Materialfv (t_vtx_api.c), but the strange thing is as far as I can > see this won't do anything if it's called inside a primitive. > Nevertheless, it fixed the rendering errors in specivewperf proe-02. Wierd. Your GREAT patch let me run viewperf-6.1.2 DRV-07 for the FIRST time. _All_ trials before hang the chip (even killing X remotely) lock the system solid. But some broken (huge) triangles with right (?) colors. Picture available. Impressive speedup for all the other tests. Wireframe could be faster (and was). Advanced Visualizer (AWadvs-04) Viewset --- Test Weight Frames DList Visual Double Frame Buffer Accumulation #%Per Sec BuildID Buffer R G B A Z Stencil R G B A --- 1 21.00 86.00 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0 2 21.00 97.70 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0 3 14.00 89.60 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0 4 14.00 86.10 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0 5 6.00 97.70 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0 6 5.00 90.20 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0 7 5.00 96.10 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0 8 4.00 102.00 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0 9 4.00 107.00 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0 10 3.00 102.00 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0 11 3.00 107.00 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0 Weighted Geometric Mean = 92.746 Design Review (DRV-07) Viewset --- Test Weight Frames DList Visual Double Frame Buffer Accumulation #%Per Sec BuildID Buffer R G B A Z Stencil R G B A --- 1 75.006.60 0.000 0X29 True 8 8 8 8 24 0 16 16 16 16 2 13.005.30 0.000 0X29 True 8 8 8 8 24 0 16 16 16 16 3 4.006.60 0.000 0X29 True 8 8 8 8 24 0 16 16 16 16 4 4.005.70 0.000 0X29 True 8 8 8 8 24 0 16 16 16 16 5 4.004.10 0.000 0X29 True 8 8 8 8 24 0 16 16 16 16 Weighted Geometric Mean = 6.256 Data Explorer (DX-06) Viewset --- Test Weight Frames DList Visual Double Frame Buffer Accumulation #%Per Sec BuildID Buffer R G B A Z Stencil R G B A --- 1 40.00 29.70 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0 2 20.00 29.90 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0 3 10.00 28.20 0.060 0X27 True 8 8 8 8 24 0 0 0 0 0 4 8.00 31.80 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0 5
Re: [Dri-devel] r200 new "revolutionary" lighting
> Roland Scheidegger <[EMAIL PROTECTED]> -- Dieter Nützel @home: --- 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@lists.sourceforge.net
Have you seen, that 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 AGP 4x x86/MMX+/3DNow!+/SSE TCL GL_MAX_3D_TEXTURE_SIZE: 256 Current 3D texture size: 64 x 64 x 64 creating 3d textures... setting up 3d texture... finished setting up 3d texture image. Usage: stex3d cmd line options: -wxxx Width of the texture (Default=64) -hxxx Height of the texture (Default=64) -dxxx Depth of the texture (Default=64) Keyboard Options: up/down rotate around X left/right rotate around Y z/Z rotate around Z a toggle animation s toggle smooth shading t toggle texgen mode o toggle object: torus/sphere i toggle texture image: noise/gradient Texgen: glTexCoord3f (no texgen) Texgen: texgen fixed to object coords Texgen: texgen fixed to eye coords Texgen: glTexCoord3f (no texgen) 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
Re: [Dri-devel] mesa / radeon / r200 texrect fixes
Am Donnerstag, 5. Februar 2004 15:52 schrieb Roland Scheidegger: > Here are the cleaned-up texrect fixes - last time there was still some > disagreement about how some things should be fixed. > If there are no objections I'm just going to try out my newly aquired > super-powers and commit it ;-). Works for me on r200 with your GREAT r200_newlight-2.diff and latest S3TC. gloss (and ipers) seems to be a little bit faster. VTK, too ;-))) Best results, summary : - i686 running Linux 2.6.1-0-smp-DN - VTK 4.5.0 (rev: 1.1813, 2004/02/05 02:45:41) - OpenGL - Visual is 1280x1024, truecolor/truecolor/24 - Tcl/Tk 8.4.4 - window was 400 x 400 1) 512x512 : 5819.7 kpolys/s : [stripper] 2) 256x256 : 3107.3 kpolys/s : [transparency] 3) 512x512 : 3090.4 kpolys/s : [small_sphere] 4) 512x512 : 3084.6 kpolys/s : [] 5) 512x512 : 2484.1 kpolys/s : [texture] 6) 512x512 : 2483.9 kpolys/s : [texture, transparency] 7) 512x512 : 1030.5 kpolys/s : [wireframe] I think wireframe has some regression. http://marc.theaimsgroup.com/?l=dri-devel&m=102927516130941&w=2 Best results, summary : - i686 running Linux 2.4.19-jam0-pc - VTK 4.1.1 (rev: 1.1305, 2002/08/13 02:45:03) - OpenGL - Visual is 1280x1024, truecolor/truecolor/24 - Tcl/Tk 8.3.3 - window was 400 x 400 1) 512x512 : 5981.7 kpolys/s : [stripper] 2) 512x512 : 3633.6 kpolys/s : [small_sphere] 3) 512x512 : 3624.2 kpolys/s : [] 4) 512x512 : 3620.4 kpolys/s : [transparency] 5) 256x256 : 2911.0 kpolys/s : [texture, transparency] 6) 512x512 : 2908.9 kpolys/s : [texture] 7) 512x512 : 2603.1 kpolys/s : [wireframe] Same with TimeRenderer/TimeRenderer2. Best was (before Mesa merge, last year around summer): TimeRenderer: ~171 fps, Wall Time ~0,7 sec TimeRenderer2: ~127 fps, Wall time ~0.9 sec, ~10 million Tri http://marc.theaimsgroup.com/?l=dri-devel&m=104208174717713&w=2 TimeRenderer2 was down to _half_ (~66 fps) before your TCL patch. But isn't on pair, now. VTK/bin> ./TimeRenderer Mesa: software DXTn compression/decompression available Wall Time = 0.888276 FrameRate = 135.093 VTK/bin> ./TimeRenderer Mesa: software DXTn compression/decompression available Wall Time = 0.875947 FrameRate = 136.995 VTK/bin> ./TimeRenderer Mesa: software DXTn compression/decompression available Wall Time = 0.875895 FrameRate = 137.003 VTK/bin> ./TimeRenderer2 Mesa: software DXTn compression/decompression available Wall Time = 1.23883 FrameRate = 96.8657 TriRate = 7.74925e+06 VTK/bin> ./TimeRenderer2 Mesa: software DXTn compression/decompression available Wall Time = 1.23643 FrameRate = 97.0535 TriRate = 7.76428e+06 VTK/bin> ./TimeRenderer2 Mesa: software DXTn compression/decompression available Wall Time = 1.24 FrameRate = 96.7743 TriRate = 7.74195e+06 cubemap has four wrong textures (all blue and white). => TMU3 patch needed Going back to before Ian's "texture patches" 'cause SMP (quake3) is broken (empty black window). Greetings, 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] [Bug 1141] i830waitlpring() lockup in Blender 2.31
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=1141 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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] [Bug 1141] i830waitlpring() lockup in Blender 2.31
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=1141 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-02-05 12:16 --- Fixed in the latest XFree86 CVS as per submitter's tests. Closing. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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] mesa / radeon / r200 texrect fixes
Roland Scheidegger wrote: Here are the cleaned-up texrect fixes - last time there was still some disagreement about how some things should be fixed. If there are no objections I'm just going to try out my newly aquired super-powers and commit it ;-). Roland (btw sorry if this appears twice on the list. The mail list server seems to have silently dropped it the first time.) Looks OK to me. 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
[Dri-devel] mesa / radeon / r200 texrect fixes
Here are the cleaned-up texrect fixes - last time there was still some
disagreement about how some things should be fixed.
If there are no objections I'm just going to try out my newly aquired
super-powers and commit it ;-).
Roland
(btw sorry if this appears twice on the list. The mail list server seems
to have silently dropped it the first time.)
Index: src/mesa/drivers/dri/r200/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
--- src/mesa/drivers/dri/r200/r200_tex.c26 Jan 2004 23:57:19 - 1.12
+++ src/mesa/drivers/dri/r200/r200_tex.c5 Feb 2004 00:03:37 -
@@ -888,10 +888,6 @@
_mesa_lookup_enum_by_nr( pname ) );
}
- if ( ( target != GL_TEXTURE_2D ) &&
- ( target != GL_TEXTURE_1D ) )
- return;
-
switch ( pname ) {
case GL_TEXTURE_MIN_FILTER:
case GL_TEXTURE_MAG_FILTER:
Index: src/mesa/drivers/dri/r200/r200_texmem.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_texmem.c,v
retrieving revision 1.5
diff -u -r1.5 r200_texmem.c
--- src/mesa/drivers/dri/r200/r200_texmem.c 27 Jan 2004 16:34:46 - 1.5
+++ src/mesa/drivers/dri/r200/r200_texmem.c 5 Feb 2004 00:03:37 -
@@ -231,7 +231,7 @@
tex = (char *)texImage->Data + done * src_pitch;
memset(®ion, 0, sizeof(region));
-r200AllocDmaRegion( rmesa, ®ion, lines * dstPitch, 64 );
+r200AllocDmaRegion( rmesa, ®ion, lines * dstPitch, 1024 );
/* Copy texdata to dma:
*/
@@ -240,10 +240,10 @@
__FUNCTION__, src_pitch, dstPitch);
if (src_pitch == dstPitch) {
- memcpy( region.address, tex, lines * src_pitch );
+ memcpy( region.address + region.start, tex, lines * src_pitch );
}
else {
- char *buf = region.address;
+ char *buf = region.address + region.start;
int i;
for (i = 0 ; i < lines ; i++) {
memcpy( buf, tex, src_pitch );
Index: src/mesa/drivers/dri/radeon/radeon_tex.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_tex.c,v
retrieving revision 1.10
diff -u -r1.10 radeon_tex.c
--- src/mesa/drivers/dri/radeon/radeon_tex.c26 Jan 2004 23:57:19 - 1.10
+++ src/mesa/drivers/dri/radeon/radeon_tex.c5 Feb 2004 00:03:37 -
@@ -623,10 +623,6 @@
_mesa_lookup_enum_by_nr( pname ) );
}
- if ( ( target != GL_TEXTURE_2D ) &&
- ( target != GL_TEXTURE_1D ) )
- return;
-
switch ( pname ) {
case GL_TEXTURE_MIN_FILTER:
case GL_TEXTURE_MAG_FILTER:
Index: src/mesa/drivers/dri/radeon/radeon_texmem.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_texmem.c,v
retrieving revision 1.4
diff -u -r1.4 radeon_texmem.c
--- src/mesa/drivers/dri/radeon/radeon_texmem.c 27 Jan 2004 16:34:46 - 1.4
+++ src/mesa/drivers/dri/radeon/radeon_texmem.c 5 Feb 2004 00:03:37 -
@@ -135,10 +135,10 @@
__FUNCTION__, src_pitch, dstPitch);
if (src_pitch == dstPitch) {
- memcpy( region.address, tex, lines * src_pitch );
+ memcpy( region.address + region.start, tex, lines * src_pitch );
}
else {
- char *buf = region.address;
+ char *buf = region.address + region.start;
int i;
for (i = 0 ; i < lines ; i++) {
memcpy( buf, tex, src_pitch );
Index: src/mesa/main/texobj.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/main/texobj.c,v
retrieving revision 1.81
diff -u -r1.81 texobj.c
--- src/mesa/main/texobj.c 27 Jan 2004 16:34:46 - 1.81
+++ src/mesa/main/texobj.c 5 Feb 2004 00:03:38 -
@@ -818,7 +818,16 @@
newTexObj->WrapT = GL_CLAMP_TO_EDGE;
newTexObj->WrapR = GL_CLAMP_TO_EDGE;
newTexObj->MinFilter = GL_LINEAR;
- }
+if (ctx->Driver.TexParameter) {
+ GLfloat fparam[1];
+ fparam[0] = (GLfloat) GL_CLAMP_TO_EDGE;
+ (*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_WRAP_S, fparam );
+ (*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_WRAP_T, fparam );
+ (*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_WRAP_R, fparam );
+ fparam[0] = (GLfloat) GL_LINEAR;
+ (*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_MIN_FILTER, fparam );
+}
+ }
}
else {
/* if this is a new texture id, allocate a texture object now */
[Dri-devel] [Bug 1141] i830waitlpring() lockup in Blender 2.31
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=1141 --- Additional Comments From [EMAIL PROTECTED] 2004-02-05 09:34 --- The bug seems to be fixed in the latest DRI CVS. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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] mach64 and new tree
Dave Airlie wrote: track him down at some point, but for now I'd like to bring the current branch up to the top of tree at least, So should I use the mesa tip and start a new mach64 branch on the DRI tree or should I make a branch on both trees? oh yeah I'm unsure who brought it up on IRC so if you are on the list speak up :-) I've just brought the mesa driver from mach64-0-0-6 so it compiles in the top of the Mesa tree (I doubt it works, but building is a good start) so if someone tells me where to put it I'll commit it for a start point tomorrow (I'm GMT+10, should probably use .au a/c :-) I'll work on the XFree bits and the DRM should be similiar enough soon.. I think it should be fine to go in at Mesa head. 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] mach64 and new tree
> track him down at some point, but for now I'd like to bring the current > branch up to the top of tree at least, > > So should I use the mesa tip and start a new mach64 branch on the DRI tree > or should I make a branch on both trees? > > oh yeah I'm unsure who brought it up on IRC so if you are on the list > speak up :-) I've just brought the mesa driver from mach64-0-0-6 so it compiles in the top of the Mesa tree (I doubt it works, but building is a good start) so if someone tells me where to put it I'll commit it for a start point tomorrow (I'm GMT+10, should probably use .au a/c :-) I'll work on the XFree bits and the DRM should be similiar enough soon.. 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
[Dri-devel] mach64 and new tree
I noticed it came up during the IRC meeting this week about moving the mach64 up to the top of tree, So how should this be done in terms of CVS, the mach64 driver as is insecure, so I'd rather not put into an official tree until those issues are sorted out, I know Jose has some ideas on these and I'll see if I can track him down at some point, but for now I'd like to bring the current branch up to the top of tree at least, So should I use the mesa tip and start a new mach64 branch on the DRI tree or should I make a branch on both trees? oh yeah I'm unsure who brought it up on IRC so if you are on the list speak up :-) 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] fix for i810 issues of late..
Keith Whitwell wrote: Dave Airlie wrote: I think I'll give up for today and go at it again later, perhaps the i810 just can't do this in hardware and I need to fallback or perhaps the number of vertices being output is out by one .. who knows :-) Okay I found it and checked in the fixes for it, the macro expansion was catching the code on ALLOC_VERTS(nr+1) for i810,i830 and mga, these all did nr * x type things, instead of (nr) * x in their ALLOC_VERTS macro expansions.. Funny enough I now know how the mesa vertex code works very well!!! I'll be hiding for a while I think.. my brain is fried... Nice one Dave. It's worth checking the rest of the drivers for this as well. Ah, OK, I see you already have... 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] fix for i810 issues of late..
Dave Airlie wrote: I think I'll give up for today and go at it again later, perhaps the i810 just can't do this in hardware and I need to fallback or perhaps the number of vertices being output is out by one .. who knows :-) Okay I found it and checked in the fixes for it, the macro expansion was catching the code on ALLOC_VERTS(nr+1) for i810,i830 and mga, these all did nr * x type things, instead of (nr) * x in their ALLOC_VERTS macro expansions.. Funny enough I now know how the mesa vertex code works very well!!! I'll be hiding for a while I think.. my brain is fried... Nice one Dave. It's worth checking the rest of the drivers for this as well. 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
