i830 texture compression working version with mipmaps and all..
Okay finally after using a pen and paper to draw some pictures I've gotten compressed textures to work with Neverwinter nights!! http://www.skynet.ie/~airlied/patches/dri/i830_texcmp.diff Now I can get back to playing it :-) It also proves you probably don't need the docs most of the time, thanks to Keith for answering my questions none the less.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Introduce DRI_VERSION?
Thomas Winischhofer wrote: Would you DRI guys mind adding a #define for DRI_VERSION_CURRENT in the same style as XORG_VERSION_CURRENT so that changes like the types from drmHandle - drm_handle_t can be handled smoothly with the C preprocessor for older versions? Point being: I would like to compile my DDX driver with both XFree86 and X.org as I don't have time to maintain two or more versions. Since the preprocessor can't check for typedefs (AFAIK...) a DRI_VERSION_CURRENT would come extremely handy. That shouldn't cause too much hassle... Thomas, Versioning has always been a tricky issue for DRI developers, and consequently keeping version numbering simple and up to date is important. I'd encourage you to considering using/enhancing the existing DRI and DRM versioning. For example, I'm wondering if the runtime version already built into DRM would help. It could be extended to use compile time #define's in places where we currently hard code constants, for example in drmGetLibVersion it looks like the minor version was just bumped to 2. The source for the linux version of this example be seen at: xc/programs/Xserver/hw/xfree86/drivers/os-support/linux/drm/xf86drm.c -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Introduce DRI_VERSION?
Thomas Winischhofer wrote: Jens Owen wrote: Thomas Winischhofer wrote: Would you DRI guys mind adding a #define for DRI_VERSION_CURRENT in the same style as XORG_VERSION_CURRENT so that changes like the types from drmHandle - drm_handle_t can be handled smoothly with the C preprocessor for older versions? Point being: I would like to compile my DDX driver with both XFree86 and X.org as I don't have time to maintain two or more versions. Since the preprocessor can't check for typedefs (AFAIK...) a DRI_VERSION_CURRENT would come extremely handy. That shouldn't cause too much hassle... Thomas, Versioning has always been a tricky issue for DRI developers, and consequently keeping version numbering simple and up to date is important. I'd encourage you to considering using/enhancing the existing DRI and DRM versioning. For example, I'm wondering if the runtime version already built into DRM would help. It could be extended to use compile time #define's in places where we currently hard code constants, for example in drmGetLibVersion it looks like the minor version was just bumped to 2. The source for the linux version of this example be seen at: xc/programs/Xserver/hw/xfree86/drivers/os-support/linux/drm/xf86drm.c Jens, thanks for your response. Just to avoid a misunderstanding: This version definition is not meant as an ABI/API/whatever number; I'd just need that for compilation reasons. If it is complicated for the DRI folks, why not keep such a version #definition in the x.org tree which is updated each time a merge from the DRI tree happens? For example, in xf86drm.h just add #define DRI_DATE 20040616 That would solve my particular problem quite easily. The name of the #define is entirely up to you... choose freely. The date format should be in a form suitable for comparison. That isn't too much work, is it? Thomas Thomas, Adding the define is easy, what's difficult is cleaning up these little hacks later without breaking binary compatability. As Keith W. suggested earlier this week, there is a good chance the X portion of the DRI development could end up in the X.org project. What would you set the DRI_DATE string to then? Perhaps it's time to bump the XORG_VERSION_CURRENT string to differentiate between the last release of X.org and the next. Would that help you? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Introduce DRI_VERSION?
Jens Owen wrote: Thomas Winischhofer wrote: If it is complicated for the DRI folks, why not keep such a version #definition in the x.org tree which is updated each time a merge from the DRI tree happens? For example, in xf86drm.h just add #define DRI_DATE 20040616 That would solve my particular problem quite easily. The name of the #define is entirely up to you... choose freely. The date format should be in a form suitable for comparison. That isn't too much work, is it? I guess I'm not sure what the point is. Adding that define to xf86drm.h would let you know that you should be using structures from drm.h that have *always* existed. Given that the structures have always existed in drm.h with the same binary format as the ones in xf86drm.h (which is the whole reason for the changes!), there's no reason to have any '#ifdef OLD_XF86DRM_H' stuff in the code. Just new the structures from drm.h and be done with it. Code using the structures from drm.h will compile no matter what version of xf86drm.h is being used. Adding the define is easy, what's difficult is cleaning up these little hacks later without breaking binary compatability. As Keith W. suggested earlier this week, there is a good chance the X portion of the DRI development could end up in the X.org project. What would you set the DRI_DATE string to then? None of these changes should have anything to do with binary compatibility. The only changes that have been made (so far) to xf86drm.h affect source-level compatibilty. When the changes are made that affect binary compatibility on LP64 systems, they will be no source-level compatibility problems. That's why things are being done in the order that they're being done. :) --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Introduce DRI_VERSION?
Jens Owen wrote: Thomas Winischhofer wrote: Would you DRI guys mind adding a #define for DRI_VERSION_CURRENT in the same style as XORG_VERSION_CURRENT so that changes like the types from drmHandle - drm_handle_t can be handled smoothly with the C preprocessor for older versions? Point being: I would like to compile my DDX driver with both XFree86 and X.org as I don't have time to maintain two or more versions. Since the preprocessor can't check for typedefs (AFAIK...) a DRI_VERSION_CURRENT would come extremely handy. That shouldn't cause too much hassle... Thomas, Versioning has always been a tricky issue for DRI developers, and consequently keeping version numbering simple and up to date is important. I'd encourage you to considering using/enhancing the existing DRI and DRM versioning. For example, I'm wondering if the runtime version already built into DRM would help. It could be extended to use compile time #define's in places where we currently hard code constants, for example in drmGetLibVersion it looks like the minor version was just bumped to 2. The source for the linux version of this example be seen at: xc/programs/Xserver/hw/xfree86/drivers/os-support/linux/drm/xf86drm.c Jens, thanks for your response. Just to avoid a misunderstanding: This version definition is not meant as an ABI/API/whatever number; I'd just need that for compilation reasons. If it is complicated for the DRI folks, why not keep such a version #definition in the x.org tree which is updated each time a merge from the DRI tree happens? For example, in xf86drm.h just add #define DRI_DATE 20040616 That would solve my particular problem quite easily. The name of the #define is entirely up to you... choose freely. The date format should be in a form suitable for comparison. That isn't too much work, is it? Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Introduce DRI_VERSION?
Jens Owen wrote: Thomas, Versioning has always been a tricky issue for DRI developers, and consequently keeping version numbering simple and up to date is important. I'd encourage you to considering using/enhancing the existing DRI and DRM versioning. For example, I'm wondering if the runtime version already built into DRM would help. It could be extended to use compile time #define's in places where we currently hard code constants, for example in drmGetLibVersion it looks like the minor version was just bumped to 2. The source for the linux version of this example be seen at: xc/programs/Xserver/hw/xfree86/drivers/os-support/linux/drm/xf86drm.c Jens, thanks for your response. Just to avoid a misunderstanding: This version definition is not meant as an ABI/API/whatever number; I'd just need that for compilation reasons. If it is complicated for the DRI folks, why not keep such a version #definition in the x.org tree which is updated each time a merge from the DRI tree happens? For example, in xf86drm.h just add #define DRI_DATE 20040616 That would solve my particular problem quite easily. The name of the #define is entirely up to you... choose freely. The date format should be in a form suitable for comparison. That isn't too much work, is it? Thomas Thomas, Adding the define is easy, what's difficult is cleaning up these little hacks later without breaking binary compatability. Again: What I suggest has nothing to do with binary compatibility. It is just for compiling one and the same DDX code with different DRI versions. However, I understand that this is something not many would need. Perhaps I am just too kind to people stuck with Debian stable (XFree86 4.1)...? ;) As Keith W. suggested earlier this week, there is a good chance the X portion of the DRI development could end up in the X.org project. What would you set the DRI_DATE string to then? Erm got me, didn't consider that. Perhaps it's time to bump the XORG_VERSION_CURRENT string to differentiate between the last release of X.org and the next. Would that help you? Yes, sure. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Introduce DRI_VERSION?
Jens Owen wrote: Perhaps it's time to bump the XORG_VERSION_CURRENT string to differentiate between the last release of X.org and the next. Would that help you? The big dri merge seems a good time to label snapshot 6.7.0.90 or however we want to start identifying the pre-6.7.1 snapshots. (How do we want to do that?) -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
tdfx driver still broken
Hi, just a reminder: the tdfx driver is broken for six month now (there still don't show up any textures - like described by ajax in May - on my 3dfx Voodoo5 5500). In this state the driver it's practically useless. I'm still desperately waiting for someone being able to repair it... Ignaz -- Ignaz Forster [EMAIL PROTECTED] --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 760] severe flickering with rendering on root window
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://freedesktop.org/bugzilla/show_bug.cgi?id=760 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-06-17 12:32 --- Duplicated with ATI All-in-Wonder (Radeon) 9000 AGP 64MB and glmatrix. -- Configure bugmail: http://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tdfx driver still broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 June 2004 15:26, Ignaz Forster wrote: Hi, just a reminder: the tdfx driver is broken for six month now (there still don't show up any textures - like described by ajax in May - on my 3dfx Voodoo5 5500). In this state the driver it's practically useless. I'm still desperately waiting for someone being able to repair it... Ignaz Trust me, I know. http://freedesktop.org/bugzilla/show_bug.cgi?id=706 - - ajax -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA0fhKW4otUKDs0NMRAgNWAJ487BuZ8fMbcwdv9LVrltcTG4G7ZgCdGNZ+ aPj4V6En3MroFJ/RwAe4gIA= =aOM5 -END PGP SIGNATURE- --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 760] severe flickering with rendering on root window
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://freedesktop.org/bugzilla/show_bug.cgi?id=760 --- Additional Comments From [EMAIL PROTECTED] 2004-06-17 12:59 --- ~$ /usr/lib/xscreensaver/glmatrix -visual 39 -root glmatrix: ignoring `-visual 39' because of `-root'. glmatrix: using root window's visual 0x23. 0x23 is not double-buffered. -- Configure bugmail: http://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i830 texture compression working version with mipmaps and all..
Dave Airlie wrote: Okay finally after using a pen and paper to draw some pictures I've gotten compressed textures to work with Neverwinter nights!! http://www.skynet.ie/~airlied/patches/dri/i830_texcmp.diff Ok, I've updated my patch. http://homepage.hispeed.ch/rscheidegger/dri_experimental/mesa_r200_radeon_i830_txc_cvs040617.diff.gz http://homepage.hispeed.ch/rscheidegger/dri_experimental/libtxc_dxtn040524.tar.gz Now I can get back to playing it :-) btw how's performance? The reviews I've seen about Intel Extreme Graphics / Extreme Graphics 2 weren't too enthusiastic about its performance... It also proves you probably don't need the docs most of the time, thanks to Keith for answering my questions none the less.. Having docs though would make life certainly easier sometimes. At least intel hands out docs to some developers though, as far as I can see it's the only one as far as new graphic chipsets are concerned... Roland (btw I'm no longer sure that RGBA_DXT1 can't work correctly if it's setup exactly the same as RGB_DXT1 - because the base texture format is different (RGBA vs. RGB) the tex env combiner stages will be setup differently. So it probably works just fine.) --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
r200/radeon intensity/luminance/alpha formats
I've converted the r200 and radeon driver to use I8 internal format for GL_INTENSITY, GL_LUMINANCE and GL_ALPHA formats (so that bug with conversion to GL_LUMINANCE_ALPHA wouldn't get triggered in the first place now...), the textures are stored by mesa in mesa_texformat_i8, -l8, and -a8 respectively. I think this is the correct thing to do, but if it isn't just complain. At least it passes glean (texEnv) on r200, the change is completely untested on radeon. R200 driver now even passes glean texCombine with 4 texture units, yay! Roland --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
GL_ARB_texture_compression GLX protocol (was Re: CVS Update: xc (branch: trunk))
Ian Romanick wrote:
Log message:
Add client-side GLX protocol support for GL_ARB_texture_compression. The
extensions are *not* currently enabled. This is for several reaons. First,
the server-side does not support texture compression, so there's no
advantage to supporting it (yet) on the client-side. Second, I tried
testing it with an IHV's closed-source driver (that advertises GL 1.3), but
their server-side driver doesn't support the protocol. That means this code
is largely untested.
I tested this on Nvidia, but their driver doesn't fully support the
texture compression GLX protocol. Could someone try this with ATI's
close-source driver? Apply the attached patch to the DRI tree and
rebuild. Then, with ATI's drivers installed, cd to progs/tests in the
Mesa tree and run with 'LD_PRELOAD=path to DRI
tree/build/xc/exports/lib/libGL.so.1.2 LIBGL_ALWAYS_INDIRECT=y ./texcmp'.
You should get one of four results:
1. It fails because neither GL_ARB_texture_compression or GL 1.3 are
supported.
2. It fails with 'X Error of failed request: BadRequest'. This will
mean ATI's driver has the same problem as Nvidia's. Note that, until a
few months ago, the open-source server-side GLX had the same problem.
3. It works the same as with direct-rendering.
4. It fails in some other way.
If someone can get #3, then I'll enable the extensions in our libGL.
On a side note, it might be worth enabling FXT1 in on the server-side.
For those rare apps that use it (ha!), it will reduce the bandwidth
required to transfer textures.
? foo
Index: glxextensions.c
===
RCS file: /cvs/dri/xc/xc/lib/GL/glx/glxextensions.c,v
retrieving revision 1.21
diff -u -d -r1.21 glxextensions.c
--- glxextensions.c 17 Jun 2004 21:23:05 - 1.21
+++ glxextensions.c 17 Jun 2004 21:23:48 -
@@ -123,7 +123,7 @@
{ GL(ARB_shadow), VER(1,4), Y, N, N, N },
{ GL(ARB_shadow_ambient), VER(0,0), Y, N, N, N },
{ GL(ARB_texture_border_clamp), VER(1,3), Y, N, N, N },
- { GL(ARB_texture_compression),VER(1,3), N, N, N, N },
+ { GL(ARB_texture_compression),VER(1,3), Y, N, N, N },
{ GL(ARB_texture_cube_map), VER(1,3), Y, N, N, N },
{ GL(ARB_texture_env_add),VER(1,3), Y, N, N, N },
{ GL(ARB_texture_env_combine),VER(1,3), Y, N, N, N },
@@ -166,7 +166,7 @@
{ GL(EXT_subtexture), VER(1,1), Y, N, N, N },
{ GL(EXT_texture),VER(1,1), Y, N, N, N },
{ GL(EXT_texture3D), VER(1,2), Y, N, N, N },
- { GL(EXT_texture_compression_s3tc), VER(0,0), N, N, N, N },
+ { GL(EXT_texture_compression_s3tc), VER(0,0), Y, N, N, N },
{ GL(EXT_texture_edge_clamp), VER(1,2), Y, N, N, N },
{ GL(EXT_texture_env_add),VER(1,3), Y, N, N, N },
{ GL(EXT_texture_env_combine),VER(1,3), Y, N, N, N },
@@ -178,7 +178,7 @@
{ GL(EXT_texture_object), VER(1,1), Y, N, N, N },
{ GL(EXT_texture_rectangle), VER(0,0), Y, N, N, N },
{ GL(EXT_vertex_array), VER(0,0), Y, N, N, N },
- { GL(3DFX_texture_compression_FXT1), VER(0,0), N, N, N, N },
+ { GL(3DFX_texture_compression_FXT1), VER(0,0), Y, N, N, N },
{ GL(APPLE_packed_pixels),VER(1,2), Y, N, N, N },
{ GL(APPLE_ycbcr_422),VER(0,0), Y, N, N, N },
{ GL(ATI_texture_env_combine3), VER(0,0), Y, N, N, N },
@@ -210,7 +210,7 @@
{ GL(NV_multisample_filter_hint), VER(0,0), Y, N, N, N },
{ GL(NV_point_sprite),VER(0,0), Y, N, N, N },
{ GL(NV_texgen_reflection), VER(0,0), Y, N, N, N },
- { GL(NV_texture_compression_vtc), VER(0,0), N, N, N, N },
+ { GL(NV_texture_compression_vtc), VER(0,0), Y, N, N, N },
{ GL(NV_texture_env_combine4),VER(0,0), Y, N, N, N },
{ GL(NV_texture_rectangle), VER(0,0), Y, N, N, N },
{ GL(SGIS_generate_mipmap), VER(1,4), Y, N, N, N },
