Re: [Dri-devel] another texture compression patch (hopefully IP safe)
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. Thanks, 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] Re: DRI compile problems, missing includes
On Wed, 21 Jan 2004 02:02:58 +0100 Andreas Happe [EMAIL PROTECTED] wrote: On 2004-01-17, Micha Feigin [EMAIL PROTECTED] wrote: If I got things right then the dri tree is not a complete X tree. You need a working X installation to install over. It installs only the modified files. I've got the same problem here (Slackware 9.1), but it seems related to changing ProjectRoot to another (also valid) directory. --Andreas I usually have ProjectRoot set to /usr/X11R6-DRI. Before the first build you need to make a few preparations: ~ cd /usr /usr mkdir X11R6-DRI /usr cd X11R6-DRI /usr/X11R6-DRI mkdir bin /usr/X11R6-DRI mkdir include /usr/X11R6-DRI mkdir lib /usr/X11R6-DRI cd lib /usr/X11R6-DRI/lib lndir ../../X11R6/lib . /usr/X11R6-DRI/lib cd ../include /usr/X11R6-DRI/include lndir ../../X11R6/include . Now the build should work. After installing make sure that /usr/X11R6-DRI/XFree86 is used as Xserver and add /usr/X11R6-DRI/lib to your LD_LIBRARY_PATH or add it in the beginning of /etc/ld.so.conf and rerun ldconfig. Felix --- 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: [Mesa3d-dev] device driver interface changes
Ian Romanick wrote: Brian Paul wrote: Brian Paul wrote: Crap. I missed an aspect to this. The texmem manager explicitly free's the data pointed to by texObj-DriverData when the texture's swapped out of VRAM. I'll fix things up ASAP. OK, I think I've got it right now. A longer term issue is still open: Do we really want to delete the driver data hanging off texObj-DriverData when we swap out a texture? Wouldn't it be better to simply mark it as swapped out? Okay, DriverData just points to the driTextureObject associated with the texture (the gl_texture_object). The only time when that gets deleted is in driDestroyTextureObject. That is only called from the driver's DeleteTexture handler or when a dummy texture is being swapped out. The dummy textures are used for the regions of memory owned by some other process / GL context. That said, something is still wrong because the assertion in r200DeleteTextures fails in glxinfo when the context is destroyed. There seems to be some funny interaction between driInitTextureObjects and NewTextureObject. I suspect we could eliminate the need for driInitTextureObjects by having r200NewTextureObject call r200AllocTexObj. That would make r200BindTexture a no-op (or just 'assert(texObj-DriverData != NULL)' in the first if-statement). I'll have to look at it more tomorrow. I'll assume this is also caused by these changes: (in XFree log): Symbol _mesa_init_driver_functions from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! DRI still works, but the use of LIBGL_ALWAYS_INDIRECT causes the instant death of the X server (something about unresolved function called) (don't know if this is really the reason, but it seems possible). (btw I've just seen I also caused unresolved symbols in the texture compression patch - any ideas how to fix this, looks like some linking problem) Symbol dlclose from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! Symbol dlerror from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! Symbol dlsym from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! Symbol dlopen from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! etc. 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] MGA font corruption revisited - now reproducible
On Wed, Jan 21, 2004 at 03:24:23PM +0100, Michel Dänzer wrote: Well, yes, it's hard to package future changes. :) (BTW, the XFree86 tag is only relevant in XFree86 CVS, and Ville's fixes likely happened after 2003/10/05.) Oops, you're right. They were from November. PS: You get the trunk with -r HEAD or just no -r at all. Now this is going to sound doubly stupid, but I *swear* I checked out CVS HEAD yesterday, and all that showed up was FreeType and X-TrueType stuff along with some basic directory structure. Which is why I went searching for further instructions and thought perhaps I was supposed to use -rtrunk instead. I've just checked a complete copy and am building it now. Thanks for the tutelage. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
Keep in mind that if you have previously checked out a branch, the 'no -r' option will keep you on that branch. If you have previously checked out a branch into your working area, make sure you do a update with '-A' which forgets the sticky tags (in this case a branch). Regards, Matthew Ryan Underwood wrote: On Wed, Jan 21, 2004 at 03:24:23PM +0100, Michel Dänzer wrote: Well, yes, it's hard to package future changes. :) (BTW, the XFree86 tag is only relevant in XFree86 CVS, and Ville's fixes likely happened after 2003/10/05.) Oops, you're right. They were from November. PS: You get the trunk with -r HEAD or just no -r at all. Now this is going to sound doubly stupid, but I *swear* I checked out CVS HEAD yesterday, and all that showed up was FreeType and X-TrueType stuff along with some basic directory structure. Which is why I went searching for further instructions and thought perhaps I was supposed to use -rtrunk instead. I've just checked a complete copy and am building it now. Thanks for the tutelage. -- Matthew Tippett - [EMAIL PROTECTED] Project Team Leader, Linux Platform Software ATI Technologies Inc., Markham, Ontario, Canada Ph: +1 905 882 2600 x8014 Fx: +1 905 882 9339 Cell: +1 416 671 0673 --- 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] GL_MESA_ycbcr_texture and GL_NVX_ycrcb
Dave Airlie wrote: Hi all, I've just implemented output for ffmpeg to opengl using rectangular ycbcr textures, and the speed is quite good (compared to non-ycbcr mipmapped textures :-), but now I've noticed of course I can't use it on the NVIDIA (*evil*) closed source drivers... (a couple of developers using NV cards...) I don't mind that much and maybe NVIDIA will pickup the MESA extension at some stage, but I've spotted an extension called GL_NVX_ycrcb in my extension list and I wonder has anyone here heard of it? I know go ask NVIDIA and I will just thought someone on this list might have seen or heard of it (google turns up nought).. I asked NVIDIA about the extension a while back and got some info. Basically, GL_NVX_ycrcb defines two new image formats (GL_CRYCBY_422_NV and GL_YCRYCB_422_NV) that can be passed to glRead/DrawPixels, glTexImage, etc. that specify the image data is stored in 4:2:2 format. The 4:2:2 data is unpacked into (Y, Cr, Cb) triplets prior to pixel transfer. It's up to you, then, to transform these triplets into RGB by setting up an appropriate GL_COLOR_MATRIX. My testing indicated, unfortunately, that the color matrix transformation is a software path in their driver and is pretty slow. Depending on your NVIDIA hardware you can efficiently do YCbCr - RGB conversion using register combiners or fragment programs. It would be nice if NVIDIA would support Mesa's GL_MESA_ycbcr_texture extension, but I don't expect that to happen. -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
[Dri-devel] [Bug 1092] Multitexture does not work with vertex arrays and indirect rendering
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=1092 --- Additional Comments From [EMAIL PROTECTED] 2004-01-21 11:43 --- I think Ian applied the patch(es) to DRI CVS over the last couple days. -- 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 1091] SecondaryColor FogCoord not support for indirect rendering
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=1091 --- Additional Comments From [EMAIL PROTECTED] 2004-01-21 11:42 --- I think Ian applied the patch(es) to DRI CVS over the last couple days. -- 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] Re: [Mesa3d-dev] device driver interface changes
On Wed, 2004-01-21 at 15:29, Roland Scheidegger wrote: I'll assume this is also caused by these changes: (in XFree log): Symbol _mesa_init_driver_functions from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! DRI still works, but the use of LIBGL_ALWAYS_INDIRECT causes the instant death of the X server (something about unresolved function called) (don't know if this is really the reason, but it seems possible). Probably, looks like Keith fixed it. (btw I've just seen I also caused unresolved symbols in the texture compression patch - any ideas how to fix this, looks like some linking problem) Symbol dlclose from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! Symbol dlerror from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! Symbol dlsym from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! Symbol dlopen from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! etc. AFAIK the XFree86 module loader doesn't support these, so you'll have to wrap the code so it's not built into the X server module. -- 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] [2.6 patch] disallow DRM on 386
On Mer, 2004-01-21 at 00:28, Adrian Bunk wrote: Fix system.h to always define cmpxchg.h and check its presence at runtime when the DRM module loads, then you can build 386 kernels that support DRI on higher machines. The problem isnt that cmpxchg definitely doesn't exist, so system.h is wrong IMHO ??? AFAIR cmpxchg wasn't present in cpus earlier than the 486. This is not relevant to the discussion assuming you are talking about kernels for 386 and higher as well as kernels solely for Intel 386. If the kernel is for 386 and higher then the DRI modules should be built but should check for cmpxchg at run time - as we do with many other CPU features --- 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] GL_MESA_ycbcr_texture and GL_NVX_ycrcb
--- Dave Airlie [EMAIL PROTECTED] wrote: Hi all, I've just implemented output for ffmpeg to opengl using rectangular ycbcr textures, and the speed is quite good (compared to non-ycbcr mipmapped textures :-), but now I've noticed of course I can't use it on the NVIDIA (*evil*) closed source drivers... (a couple of developers using NV cards...) I don't mind that much and maybe NVIDIA will pickup the MESA extension at some stage, but I've spotted an extension called GL_NVX_ycrcb in my extension list and I wonder has anyone here heard of it? I know go ask NVIDIA and I will just thought someone on this list might have seen or heard of it (google turns up nought).. I'm not familair with it either, but I know sgi has a similar extension, and I think there are others so in theory this could be supported on lots of platforms. Alex Thanks, 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 __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus --- 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] [Bug 1091] New: SecondaryColor FogCoord not support for indirect rendering
Ian Romanick wrote: I think the patch is not complete though, I believe you'd need to add some missing values (like GL_FOG_COORDINATE_SOURCE, which can get used in glFog[if]v if you have the FogCoord Extension to singlesize.c and compsize.c), at least until before everything is converted to the new templates. I could be wrong though (well I've added them and it didn't hurt ;-)). You need to do a 'cvs update'. :) I added a *ton* of missing enums to singlesize.c and compsize.c yesterday. If I see that correctly, the one mentioned above though is still missing - or isn't it necessary? Anyway, secondary color and fogcolor work now indeed correctly with LIBGL_ALWAYS_INDIRECT. 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] GL_MESA_ycbcr_texture and GL_NVX_ycrcb
Is anyone here on the ARB so they can go bug for these specs to be made part of the OpenGL core? With OpenML etc. popping up now, and the advent of DVD players with 3D hardware in them (NUON, Playstation 2, X-Box, Panasonic Q Gamecube, Sony PSX) it seems the time to stop running around making the same extensions with different names, and start unifying them a bit so these new technologies can take advantage. -- Matt Sealey [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave Airlie Sent: 21 January 2004 04:06 To: [EMAIL PROTECTED] Subject: [Dri-devel] GL_MESA_ycbcr_texture and GL_NVX_ycrcb Hi all, I've just implemented output for ffmpeg to opengl using rectangular ycbcr textures, and the speed is quite good (compared to non-ycbcr mipmapped textures :-), but now I've noticed of course I can't use it on the NVIDIA (*evil*) closed source drivers... (a couple of developers using NV cards...) I don't mind that much and maybe NVIDIA will pickup the MESA extension at some stage, but I've spotted an extension called GL_NVX_ycrcb in my extension list and I wonder has anyone here heard of it? I know go ask NVIDIA and I will just thought someone on this list might have seen or heard of it (google turns up nought).. Thanks, 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 --- 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 color material enable fix / endgame
This one-byte patch fixes the endgame xscreensaver (both version 4.05 and 4.14). Don't know if it's actually correct, but after looking at endgame with gdb it looked like some likely necessary state updates were omitted. Reversing the condition when to call the update material function fixes this. Maybe someone could take a look at it? Roland btw the same code is also in the radeon driver. If endgame doesn't work there correctly, it's likely for the same reason I guess. Index: r200_state.c === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_state.c,v retrieving revision 1.9 diff -u -r1.9 r200_state.c --- r200_state.c21 Jan 2004 16:08:43 - 1.9 +++ r200_state.c21 Jan 2004 22:30:21 - @@ -1695,7 +1734,7 @@ case GL_COLOR_MATERIAL: r200ColorMaterial( ctx, 0, 0 ); - if (!state) + if ( state ) r200UpdateMaterial( ctx ); break;
Re: [Dri-devel] r200 color material enable fix / endgame
Roland Scheidegger wrote: This one-byte patch fixes the endgame xscreensaver (both version 4.05 and 4.14). Don't know if it's actually correct, but after looking at endgame with gdb it looked like some likely necessary state updates were omitted. Reversing the condition when to call the update material function fixes this. Maybe someone could take a look at it? Roland btw the same code is also in the radeon driver. If endgame doesn't work there correctly, it's likely for the same reason I guess. Index: r200_state.c === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_state.c,v retrieving revision 1.9 diff -u -r1.9 r200_state.c --- r200_state.c21 Jan 2004 16:08:43 - 1.9 +++ r200_state.c21 Jan 2004 22:30:21 - @@ -1695,7 +1734,7 @@ case GL_COLOR_MATERIAL: r200ColorMaterial( ctx, 0, 0 ); - if (!state) + if ( state ) r200UpdateMaterial( ctx ); break; How about just removing the test altogether? 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] even more r200 mesa test failures
Just noticed that there are other mesa tests which also don't work correctly :-(. redbook/alpha3D: nothing is shown, unless you keep pressing a - some buffering problem? redbook/polys: the 2nd and 3rd rectangle use the same pattern (that from the 3rd poly). Looks like the driver can't handle multiple poly patterns currently? samples/blendeq: first 6 blend modes are correct, almost all of the remaining ones (including all logic op modes) not. samples/blendxor: doesn't xor the patterns at all (given the results of blendeq, no surprise). samples/sphere: the texture on the sphere looks wrong, almost reversed (seems to be the same problem as with isosurf, both use GL_SPHERE_MAP - GL_SPHERE_MAP seems to work correctly in the gloss demo though interestingly). tests/texrect: the girl texture is completely messed up, the other looks a bit better. If you prefer (or force) 16bit textures with driconf, it will crash instead (r200_cmdbuf.c:354: r200EmitBlit: Assertion `(src_offset 1023) == 0' failed.). xdemos/wincopy: destination window is empty (actually first time I tried it it was not empty but showed some pieces of demos previously run). xdemos/glthreads: I didn't have the courage to test this (I just didn't feel like rebooting ;-)) - in the past it always locked up immediately when at least 33 threads were specified, or locked up after some time if less than 33 threads were specified (generally, the more threads, the faster it would lock up). Can try that later if someone is interested in the results... 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] r200 color material enable fix / endgame
Keith Whitwell wrote: Roland Scheidegger wrote: This one-byte patch fixes the endgame xscreensaver (both version 4.05 and 4.14). Don't know if it's actually correct, but after looking at endgame with gdb it looked like some likely necessary state updates were omitted. Reversing the condition when to call the update material function fixes this. Maybe someone could take a look at it? Roland btw the same code is also in the radeon driver. If endgame doesn't work there correctly, it's likely for the same reason I guess. Index: r200_state.c === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_state.c,v retrieving revision 1.9 diff -u -r1.9 r200_state.c --- r200_state.c21 Jan 2004 16:08:43 -1.9 +++ r200_state.c21 Jan 2004 22:30:21 - @@ -1695,7 +1734,7 @@ case GL_COLOR_MATERIAL: r200ColorMaterial( ctx, 0, 0 ); - if (!state) + if ( state ) r200UpdateMaterial( ctx ); break; How about just removing the test altogether? Tried that, doesn't work (same (or similar) errors as before). Strange, that doesn't really make sense, or does it? 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] even more r200 mesa test failures
On Thu, 2004-01-22 at 00:16, Roland Scheidegger wrote: samples/sphere: the texture on the sphere looks wrong, almost reversed (seems to be the same problem as with isosurf, both use GL_SPHERE_MAP - GL_SPHERE_MAP seems to work correctly in the gloss demo though interestingly). It's also wrong in foobillard, e.g.; works with SW TCL. tests/texrect: the girl texture is completely messed up, the other looks a bit better. Seems to work fine here (same as with software rendering) - try disabling codegen maybe? Didn't you notice yuvrect being broken though? :\ If you prefer (or force) 16bit textures with driconf, it will crash instead (r200_cmdbuf.c:354: r200EmitBlit: Assertion `(src_offset 1023) == 0' failed.). I see that as well. xdemos/glthreads: I didn't have the courage to test this (I just didn't feel like rebooting ;-)) - in the past it always locked up immediately when at least 33 threads were specified, or locked up after some time if less than 33 threads were specified (generally, the more threads, the faster it would lock up). Can try that later if someone is interested in the results... FWIW, I ran it a couple of times recently without problems, but I think I only went up to 16 or so. -- 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] [Bug 1092] Multitexture does not work with vertex arrays and indirect rendering
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=1092 --- Additional Comments From [EMAIL PROTECTED] 2004-01-21 17:33 --- I realize that, but Ian's committed a boat load of other updates for the GLX code too. What we need to go into the XFree86 CVS is an isolated patch to cover this particular problem. -- 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] r200 color material enable fix / endgame
On Thu, 2004-01-22 at 00:27, Roland Scheidegger wrote: Keith Whitwell wrote: Roland Scheidegger wrote: --- r200_state.c21 Jan 2004 16:08:43 -1.9 +++ r200_state.c21 Jan 2004 22:30:21 - @@ -1695,7 +1734,7 @@ case GL_COLOR_MATERIAL: r200ColorMaterial( ctx, 0, 0 ); - if (!state) + if ( state ) r200UpdateMaterial( ctx ); break; How about just removing the test altogether? Tried that, doesn't work (same (or similar) errors as before). Strange, that doesn't really make sense, or does it? No, and it works here; you did remove only the test, not the r200UpdateMaterial() call as well, right? :) -- 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] r200 color material enable fix / endgame
Michel Dnzer wrote: On Thu, 2004-01-22 at 00:27, Roland Scheidegger wrote: Keith Whitwell wrote: Roland Scheidegger wrote: --- r200_state.c21 Jan 2004 16:08:43 -1.9 +++ r200_state.c21 Jan 2004 22:30:21 - @@ -1695,7 +1734,7 @@ case GL_COLOR_MATERIAL: r200ColorMaterial( ctx, 0, 0 ); - if (!state) + if ( state ) r200UpdateMaterial( ctx ); break; How about just removing the test altogether? Tried that, doesn't work (same (or similar) errors as before). Strange, that doesn't really make sense, or does it? No, and it works here; you did remove only the test, not the r200UpdateMaterial() call as well, right? :) Right, I even rechecked it... However, you're suggestion is interesting, removing the r200UpdateMaterial() call there works too here (for endgame at least). Removing only the state test does absolutely nothing for endgame (4.05 or 4.14) unfortunately for me. Maybe we have different other patches attached? I'm using your http://penguinppc.org/~daenzer/DRI/r200-attenuation-2.diff patch (and also the texture compression stuff, but this can't make a difference here). (I also have a RV250, not R200, but let's hope this doesn't make a difference.) 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] even more r200 mesa test failures
Michel Dnzer wrote: On Thu, 2004-01-22 at 00:16, Roland Scheidegger wrote: samples/sphere: the texture on the sphere looks wrong, almost reversed (seems to be the same problem as with isosurf, both use GL_SPHERE_MAP - GL_SPHERE_MAP seems to work correctly in the gloss demo though interestingly). It's also wrong in foobillard, e.g.; works with SW TCL. tests/texrect: the girl texture is completely messed up, the other looks a bit better. Seems to work fine here (same as with software rendering) - try disabling codegen maybe? Didn't you notice yuvrect being broken though? :\ Well I've reported yuvrect as broken in the earlier email - no need to repeat everything. No idea why texrect doesn't work here but works for you though. tcl_mode makes no difference at all. If you prefer (or force) 16bit textures with driconf, it will crash instead (r200_cmdbuf.c:354: r200EmitBlit: Assertion `(src_offset 1023) == 0' failed.). I see that as well. xdemos/glthreads: I didn't have the courage to test this (I just didn't feel like rebooting ;-)) - in the past it always locked up immediately when at least 33 threads were specified, or locked up after some time if less than 33 threads were specified (generally, the more threads, the faster it would lock up). Can try that later if someone is interested in the results... FWIW, I ran it a couple of times recently without problems, but I think I only went up to 16 or so. IIRC I got it pretty easy to crash with only 16 threads when moving around the glthreads windows. 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] r200 color material enable fix / endgame
On Thu, 2004-01-22 at 01:38, Roland Scheidegger wrote:
Michel Dnzer wrote:
you did remove only the test, not the r200UpdateMaterial() call as well,
right? :)
Right, I even rechecked it...
However, you're suggestion is interesting, removing the
r200UpdateMaterial() call there works too here (for endgame at least).
That doesn't sound right.
Removing only the state test does absolutely nothing for endgame (4.05
or 4.14) unfortunately for me.
Maybe we have different other patches attached?
Indeed, I had forgotten about something I had been playing with, see
attachment. Looks like the stuff in the block needs to be done
unconditionally as well?
I'm using your http://penguinppc.org/~daenzer/DRI/r200-attenuation-2.diff
patch
So am I; BTW, does everyone agree it's better than the first cut?
(I also have a RV250, not R200, but let's hope this doesn't make a
difference.)
My M9 is RV250 as well.
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Index: r200_state.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_state.c,v
retrieving revision 1.6
diff -p -u -r1.6 r200_state.c
--- r200_state.c 27 Dec 2003 22:06:39 - 1.6
+++ r200_state.c 22 Jan 2004 01:19:50 -
@@ -963,7 +970,7 @@ void r200UpdateMaterial( GLcontext *ctx
fcmd[MTL_SHININESS] = mat[MAT_ATTRIB_FRONT_SHININESS][0];
}
- if (R200_DB_STATECHANGE( rmesa, rmesa-hw.mtl[0] )) {
+ if (R200_DB_STATECHANGE( rmesa, rmesa-hw.mtl[0] ) || 1) {
for (p = 0 ; p MAX_LIGHTS; p++)
update_light_colors( ctx, p );
Re: [Dri-devel] even more r200 mesa test failures
On Thu, 2004-01-22 at 02:01, Roland Scheidegger wrote: Michel Dnzer wrote: On Thu, 2004-01-22 at 00:16, Roland Scheidegger wrote: tests/texrect: the girl texture is completely messed up, the other looks a bit better. Seems to work fine here (same as with software rendering) - try disabling codegen maybe? Didn't you notice yuvrect being broken though? :\ Well I've reported yuvrect as broken in the earlier email - no need to repeat everything. Right. No idea why texrect doesn't work here but works for you though. tcl_mode makes no difference at all. Are you sure your texture compression patch doesn't matter here? :) xdemos/glthreads: I didn't have the courage to test this (I just didn't feel like rebooting ;-)) - in the past it always locked up immediately when at least 33 threads were specified, or locked up after some time if less than 33 threads were specified (generally, the more threads, the faster it would lock up). Can try that later if someone is interested in the results... FWIW, I ran it a couple of times recently without problems, but I think I only went up to 16 or so. IIRC I got it pretty easy to crash with only 16 threads when moving around the glthreads windows. Granted, I only moved them around a little. -- 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
