Re: [Dri-devel] MGA font corruption revisited - now reproducible
Ville, On Thu, Dec 11, 2003 at 02:02:36PM +0200, Ville Syrjälä wrote: I can't reproduce any font corruption with crack-attack (or any other gl app) and quake2 just segfaults when I try to run it. Maybe it doesn't like to run with the demo pak file... But running quake3 and crack-attack at the same time does cause some really nasty texture corruption. They appear to step on each others' textures... Just to let you know, it appears the RENDER bug has been solved. I think I didn't properly replace the driver before. :) However, I was doing my own driver hacking, so I was forced to replace it correctly this time. The only problem I have with the mga driver right now is lack of mouse cursor in UT, though there is a claim in bugzilla that you fixed it. Do you have any details on the fix? On another topic, do you use a dualhead G400? If so, are you able to properly use DPMS on the second head? I don't run XFree86 except when trying to hunt DRI related bugs. It's been well over a year since I really used XFree86 and I honestly don't remember if DPMS ever worked with the second head. I don't have a second monitor to test right now. I just uploaded a patch to the bug tracker that makes DPMS work on the second head among other things (i2c/maven related). -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Tue, Jan 20, 2004 at 03:52:37AM -0600, Ryan Underwood wrote: Ville, On Thu, Dec 11, 2003 at 02:02:36PM +0200, Ville Syrjälä wrote: I can't reproduce any font corruption with crack-attack (or any other gl app) and quake2 just segfaults when I try to run it. Maybe it doesn't like to run with the demo pak file... But running quake3 and crack-attack at the same time does cause some really nasty texture corruption. They appear to step on each others' textures... Just to let you know, it appears the RENDER bug has been solved. I think I didn't properly replace the driver before. :) However, I was doing my own driver hacking, so I was forced to replace it correctly this time. Ah good. The only problem I have with the mga driver right now is lack of mouse cursor in UT, though there is a claim in bugzilla that you fixed it. Do you have any details on the fix? http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/mesa/src/drv/mga/Attic/mga_xmesa.c.diff?r1=1.66r2=1.67hideattic=0 http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/mesa/src/drv/mga/Attic/mgaioctl.c.diff?r1=1.37r2=1.38hideattic=0 The _mesa_notifySwapBuffers() call is the important bit. Without that the pipeline wasn't flushed properly. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- 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 881] 3D acceleration doesn't work
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=881 --- Additional Comments From [EMAIL PROTECTED] 2004-01-20 05:27 --- Tested again with XFree86 CVS 04-01-16. Q3A runs for a while, but then hangs with these messages in the XFree log: (EE) R128(0): Idle timed out, resetting engine... ET hangs completely. Again, these messages appeared in the syslog: kernel: [drm:r128_freelist_get] *ERROR* returning NULL! And also these: kernel: agpgart: Device is in legacy mode, falling back to 2.x kernel: agpgart: Putting AGP V2 device at 00:00.0 into 1x mode kernel: agpgart: Putting AGP V2 device at 01:00.0 into 1x mode So, anything else I can try to make XFree functional again? -- 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] MGA font corruption revisited - now reproducible
--- Ryan Underwood [EMAIL PROTECTED] wrote: [snip] On another topic, do you use a dualhead G400? If so, are you able to properly use DPMS on the second head? I don't run XFree86 except when trying to hunt DRI related bugs. It's been well over a year since I really used XFree86 and I honestly don't remember if DPMS ever worked with the second head. I don't have a second monitor to test right now. I just uploaded a patch to the bug tracker that makes DPMS work on the second head among other things (i2c/maven related). if you copied any code directly from the mga FB driver, you need to ask Petr Vandrovec if you can release it with a X11 license because the FB driver is GPL'ed. I think in the past Petr said he didn't care, but it's worth asking again. FWIW, I'd love to see native maven support in the X11 driver. Alex -- Ryan Underwood, [EMAIL PROTECTED] __ 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
[Dri-devel] SGI will polish Linux for Visualization Systems
http://www.sgi.com/visualization/linux.html http://www.sgi.com/visualization/ Report on German's c't magzine (Heise) http://www.heise.de/newsticker/data/akr-20.01.04-005/ Regards, 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] SGI will polish Linux for Visualization Systems
Wow that's awesome! if we are lucky SGI may contribute the guts we need to get the DRI working with xinerama/dmx/chromium. It looks like their multipipe GL already works with xinerama. Does anyone know anymore about this or know what sort of license their code will have? Alex --- Dieter Nützel [EMAIL PROTECTED] wrote: http://www.sgi.com/visualization/linux.html http://www.sgi.com/visualization/ Report on German's c't magzine (Heise) http://www.heise.de/newsticker/data/akr-20.01.04-005/ Regards, Dieter __ 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] SGI will polish Linux for Visualization Systems
DRI already works with DMX/Chromium. Any OpenGL implementation should. -Brian Alex Deucher wrote: Wow that's awesome! if we are lucky SGI may contribute the guts we need to get the DRI working with xinerama/dmx/chromium. It looks like their multipipe GL already works with xinerama. Does anyone know anymore about this or know what sort of license their code will have? Alex --- Dieter Nützel [EMAIL PROTECTED] wrote: http://www.sgi.com/visualization/linux.html http://www.sgi.com/visualization/ Report on German's c't magzine (Heise) http://www.heise.de/newsticker/data/akr-20.01.04-005/ Regards, Dieter __ 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 --- 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] SGI will polish Linux for Visualization Systems
Alex Deucher wrote: Wow that's awesome! if we are lucky SGI may contribute the guts we need to get the DRI working with xinerama/dmx/chromium. It looks like their multipipe GL already works with xinerama. Does anyone know anymore about this or know what sort of license their code will have? It should already work. Chromium and DMX sit on top of OpenGL. Xinerama is another story, however. In some sense, the GL driver has to sit on top of Xinerama. --- 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] [2.6 patch] disallow DRM on 386
I got the following compile error in 2.6.1-mm5 with X86_CMPXCHG=n. This problem is not specific to -mm, and it always occurs when you include support for the 386 cpu (oposed to the 486 or later cpus) since in this case X86_CMPXCHG=n and therefoore cmpxchg isn't defined in include/asm-i386/system.h . The patch below disallows DRM if X86_CMPXCHG=n. Please apply Adrian --- linux-2.6.1-mm5/drivers/char/drm/Kconfig.old2004-01-20 14:42:27.0 +0100 +++ linux-2.6.1-mm5/drivers/char/drm/Kconfig2004-01-20 14:43:02.0 +0100 @@ -6,6 +6,7 @@ # config DRM bool Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) + depends on !X86 || X86_CMPXCHG help Kernel-level support for the Direct Rendering Infrastructure (DRI) introduced in XFree86 4.0. If you say Y here, you need to select --- 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_ATI_envmap_bumpmap
Ryan Underwood wrote: GL_ATI_envmap_bumpmap seems to describe identical functionality to DirectX6 EMBM. ATI's drivers support this extension and it is implemented in Mesa apparently. Does anyone know of a demo or sample code that utilizes this extension? ATI's drivers do support it, but Mesa does not. This would be a useful extension to have in Mesa since R100, R200, G400, and i830 all support it in hardware. I looked at adding support for it once. The main barrier is that the DUDV texture formats (which are the same as the DSDT texture formats in NV_texture_shader) are *signed*. Mesa doesn't currently have any support for signed texture formats. --- 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_ATI_envmap_bumpmap
Ian Romanick wrote:
Ian Romanick wrote:
Ryan Underwood wrote:
GL_ATI_envmap_bumpmap seems to describe identical functionality to
DirectX6 EMBM. ATI's drivers support this extension and it is
implemented in Mesa apparently. Does anyone know of a demo or sample
code that utilizes this extension?
ATI's drivers do support it, but Mesa does not. This would be a
useful extension to have in Mesa since R100, R200, G400, and i830 all
support it in hardware. I looked at adding support for it once. The
main barrier is that the DUDV texture formats (which are the same as
the DSDT texture formats in NV_texture_shader) are *signed*. Mesa
doesn't currently have any support for signed texture formats.
Let me elaborate on that a bit. Texture data with a format of
GL_DUDV_ATI should have a type of GL_BYTE. All of the signed types,
like GL_BYTE, have a range of [-1,1]. In all existing cases, texture
data has a range of [0,1]. When Mesa gets a texture of GL_BYTE, it
modifies each value by (x+128)*2 to convert it to a GL_UNSIGNED_BYTE.
Each texture has a function to fetch raw, unsigned color data from the
texture. We'd either have to add a new function to fetch raw, signed
DSDT data or do some sort of trickery. The GL_ATI_envmap_bumpmap says
that fetch color data from a DSDT texture give {0,0,0,1}. Since I
didn't see an obvious, architecturally clean way to do it, and I already
had (have!) a lot of other stuff on my plate, I left off there.
One of these days I'm going to add support for signed/floating point
texture formats. They'd be pretty handy in conjuction with fragment
programs.
I'll probably wind up adding new texel Fetch functions that return 4
GLfloats.
Fetching DSDT texels as floats would probably be good since you need
to apply a floating point rotation matrix to the fetched texel.
How does that sound, Ian?
-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] GL_ATI_envmap_bumpmap
Brian Paul wrote:
Ian Romanick wrote:
Let me elaborate on that a bit. Texture data with a format of
GL_DUDV_ATI should have a type of GL_BYTE. All of the signed types,
like GL_BYTE, have a range of [-1,1]. In all existing cases, texture
data has a range of [0,1]. When Mesa gets a texture of GL_BYTE, it
modifies each value by (x+128)*2 to convert it to a GL_UNSIGNED_BYTE.
Each texture has a function to fetch raw, unsigned color data from the
texture. We'd either have to add a new function to fetch raw, signed
DSDT data or do some sort of trickery. The GL_ATI_envmap_bumpmap says
that fetch color data from a DSDT texture give {0,0,0,1}. Since I
didn't see an obvious, architecturally clean way to do it, and I
already had (have!) a lot of other stuff on my plate, I left off there.
One of these days I'm going to add support for signed/floating point
texture formats. They'd be pretty handy in conjuction with fragment
programs.
I'll probably wind up adding new texel Fetch functions that return 4
GLfloats.
Fetching DSDT texels as floats would probably be good since you need to
apply a floating point rotation matrix to the fetched texel.
How does that sound, Ian?
That would do the trick. I guess the default internal type for DSDT
textures would be GLfloat instead of GLchan?
That doesn't solve the whole problem for DSDT textures (or depth
textures?), though. If a DSDT texture is bound to a texture unit, the
idea is that the texture environment will be set up to have the output
of that texture unit modify the texture coordinates for some other unit.
However, it is still possible to use that texture unit in the regular
(color) blending environment. In that case, the color is supposed to be
{0,0,0,1}, not {DS, DT, 0, 1} or some such.
I guess if the float-point fetch function is only used for depth, DSDT,
and fragment programs it should be okay. The various other (primarilly
SGI) extension that add either signed or floating point textures to the
classic fragment pipeline probably aren't too interesting anymore.
---
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_ATI_envmap_bumpmap
Ryan Underwood wrote: On Wed, Jan 21, 2004 at 12:23:17AM +0200, Ville Syrjälä wrote: On Tue, Jan 20, 2004 at 03:47:49PM -0600, Ryan Underwood wrote: GL_ATI_envmap_bumpmap seems to describe identical functionality to DirectX6 EMBM. ATI's drivers support this extension and it is implemented in Mesa apparently. Does anyone know of a demo or sample code that utilizes this extension? Last time I looked Mesa didn't support this extension. My plan was to add bumpmap support to the mga driver if/when someone added the relevant Mesa bits... You're right, I was looking only at glext.h. My intent was to implement it to the mga driver too because it is sort of a unique functionality that can create some nice eye candy. A secondary intent was to implement DX6 EMBM in WINE and pass it through to this extension if available. That way you could run DX6+ games that utilize EMBM in WINE. Does that extension really provide all of DX6 EMBM? I seem to recall there being that modified the texture coordinates AND had an intensity (or is it luminosity?) value. The ATI extension doesn't have that. It could be simulated on ATI hardware by using an extra texture blend stage. --- 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
--- Ryan Underwood [EMAIL PROTECTED] wrote: On Tue, Jan 20, 2004 at 12:57:11PM +0200, Ville Syrjälä wrote: The only problem I have with the mga driver right now is lack of mouse cursor in UT, though there is a claim in bugzilla that you fixed it. Do you have any details on the fix? http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/mesa/src/drv/mga/Attic/mga_xmesa.c.diff?r1=1.66r2=1.67hideattic=0 http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/mesa/src/drv/mga/Attic/mgaioctl.c.diff?r1=1.37r2=1.38hideattic=0 The _mesa_notifySwapBuffers() call is the important bit. Without that the pipeline wasn't flushed properly. Are those fixes on a branch somewhere? It appears trunk's version is: /* $XFree86: xc/lib/GL/mesa/src/drv/mga/mga_xmesa.c,v 1.19 2003/03/26 20:43:49 tsi Exp $ */ but that is from Michel's trunk packages, so I don't know if he is completely up to date. The changes may have been committed after the 3D drivers moved to mesa cvs. Alex __ 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] GL_ATI_envmap_bumpmap
Ian Romanick wrote:
Brian Paul wrote:
Ian Romanick wrote:
Let me elaborate on that a bit. Texture data with a format of
GL_DUDV_ATI should have a type of GL_BYTE. All of the signed types,
like GL_BYTE, have a range of [-1,1]. In all existing cases, texture
data has a range of [0,1]. When Mesa gets a texture of GL_BYTE, it
modifies each value by (x+128)*2 to convert it to a GL_UNSIGNED_BYTE.
Each texture has a function to fetch raw, unsigned color data from
the texture. We'd either have to add a new function to fetch raw,
signed DSDT data or do some sort of trickery. The
GL_ATI_envmap_bumpmap says that fetch color data from a DSDT texture
give {0,0,0,1}. Since I didn't see an obvious, architecturally clean
way to do it, and I already had (have!) a lot of other stuff on my
plate, I left off there.
One of these days I'm going to add support for signed/floating point
texture formats. They'd be pretty handy in conjuction with fragment
programs.
I'll probably wind up adding new texel Fetch functions that return 4
GLfloats.
Fetching DSDT texels as floats would probably be good since you need
to apply a floating point rotation matrix to the fetched texel.
How does that sound, Ian?
That would do the trick. I guess the default internal type for DSDT
textures would be GLfloat instead of GLchan?
The internal type could be anything. I'm just saying that the Fetch
function would return floating point data.
That doesn't solve the whole problem for DSDT textures (or depth
textures?), though. If a DSDT texture is bound to a texture unit, the
idea is that the texture environment will be set up to have the output
of that texture unit modify the texture coordinates for some other unit.
However, it is still possible to use that texture unit in the regular
(color) blending environment. In that case, the color is supposed to be
{0,0,0,1}, not {DS, DT, 0, 1} or some such.
Sure, adding signed float texture support doesn't solve the whole
problem, but I think it's a good first step.
I guess if the float-point fetch function is only used for depth, DSDT,
and fragment programs it should be okay. The various other (primarilly
SGI) extension that add either signed or floating point textures to the
classic fragment pipeline probably aren't too interesting anymore.
I think we're on the same page.
-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] [2.6 patch] disallow DRM on 386
On Maw, 2004-01-20 at 21:24, Adrian Bunk wrote: I got the following compile error in 2.6.1-mm5 with X86_CMPXCHG=n. This problem is not specific to -mm, and it always occurs when you include support for the 386 cpu (oposed to the 486 or later cpus) since in this case X86_CMPXCHG=n and therefoore cmpxchg isn't defined in include/asm-i386/system.h . The patch below disallows DRM if X86_CMPXCHG=n. Ugly. 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 --- 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-20 19:03 --- Ian, Can you attach a patch for this ? -- 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-20 19:03 --- Attach a patch for this too ? -- 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] MGA font corruption revisited - now reproducible
On Wed, 2004-01-21 at 00:02, Ryan Underwood wrote: Are those fixes on a branch somewhere? It appears trunk's version is: /* $XFree86: xc/lib/GL/mesa/src/drv/mga/mga_xmesa.c,v 1.19 2003/03/26 20:43:49 tsi Exp $ */ but that is from Michel's trunk packages, so I don't know if he is completely up to date. Just look at the package version... if you want to follow or even do development, my snapshot packages aren't for you, use CVS directly. -- 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] GL_ATI_envmap_bumpmap
Hi, GL_ATI_envmap_bumpmap seems to describe identical functionality to DirectX6 EMBM. ATI's drivers support this extension and it is implemented in Mesa apparently. Does anyone know of a demo or sample code that utilizes this extension? -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
[Dri-devel] Re: [Mesa3d-dev] device driver interface changes
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. --- 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 Wed, Jan 21, 2004 at 12:04:59AM +, Alan Cox wrote: On Maw, 2004-01-20 at 21:24, Adrian Bunk wrote: I got the following compile error in 2.6.1-mm5 with X86_CMPXCHG=n. This problem is not specific to -mm, and it always occurs when you include support for the 386 cpu (oposed to the 486 or later cpus) since in this case X86_CMPXCHG=n and therefoore cmpxchg isn't defined in include/asm-i386/system.h . The patch below disallows DRM if X86_CMPXCHG=n. Ugly. 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. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI compile problems, missing includes
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 --- 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_ATI_envmap_bumpmap
--- Ryan Underwood [EMAIL PROTECTED] wrote: Hi, GL_ATI_envmap_bumpmap seems to describe identical functionality to DirectX6 EMBM. ATI's drivers support this extension and it is implemented in Mesa apparently. Does anyone know of a demo or sample code that utilizes this extension? I'm not sure of an app that uses it, but as I recall mga g4xx cards could, in theory, support that extension as well since they had dx6 EMBM support. Alex -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ 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] GL_ATI_envmap_bumpmap
On Tue, Jan 20, 2004 at 03:47:49PM -0600, Ryan Underwood wrote: Hi, GL_ATI_envmap_bumpmap seems to describe identical functionality to DirectX6 EMBM. ATI's drivers support this extension and it is implemented in Mesa apparently. Does anyone know of a demo or sample code that utilizes this extension? Last time I looked Mesa didn't support this extension. My plan was to add bumpmap support to the mga driver if/when someone added the relevant Mesa bits... -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- 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 01:30:15AM +0100, Michel Dänzer wrote: On Wed, 2004-01-21 at 00:02, Ryan Underwood wrote: Are those fixes on a branch somewhere? It appears trunk's version is: /* $XFree86: xc/lib/GL/mesa/src/drv/mga/mga_xmesa.c,v 1.19 2003/03/26 20:43:49 tsi Exp $ */ but that is from Michel's trunk packages, so I don't know if he is completely up to date. Just look at the package version... if you want to follow or even do development, my snapshot packages aren't for you, use CVS directly. Right, I just used them as a matter of convenience, no having to maintain separate XFree86 installation and such. Rebuild, dpkg -i *.deb, and test. Your package version is 2003.10.05-2 which is much newer than the above CVS tag. Seemed strange to me that there would be no trunk merges in 7 months, but I guess that is the case. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] GL_ATI_envmap_bumpmap
On Wed, Jan 21, 2004 at 12:23:17AM +0200, Ville Syrjälä wrote: On Tue, Jan 20, 2004 at 03:47:49PM -0600, Ryan Underwood wrote: Hi, GL_ATI_envmap_bumpmap seems to describe identical functionality to DirectX6 EMBM. ATI's drivers support this extension and it is implemented in Mesa apparently. Does anyone know of a demo or sample code that utilizes this extension? Last time I looked Mesa didn't support this extension. My plan was to add bumpmap support to the mga driver if/when someone added the relevant Mesa bits... You're right, I was looking only at glext.h. My intent was to implement it to the mga driver too because it is sort of a unique functionality that can create some nice eye candy. A secondary intent was to implement DX6 EMBM in WINE and pass it through to this extension if available. That way you could run DX6+ games that utilize EMBM in WINE. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
[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
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Wed, Jan 21, 2004 at 01:30:15AM +0100, Michel Dänzer wrote: On Wed, 2004-01-21 at 00:02, Ryan Underwood wrote: Are those fixes on a branch somewhere? It appears trunk's version is: /* $XFree86: xc/lib/GL/mesa/src/drv/mga/mga_xmesa.c,v 1.19 2003/03/26 20:43:49 tsi Exp $ */ but that is from Michel's trunk packages, so I don't know if he is completely up to date. Just look at the package version... if you want to follow or even do development, my snapshot packages aren't for you, use CVS directly. I remembered another reason I used your package. When I tried to check out DRI CVS, I used: cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvs/dri -z4 co -rtrunk xc trying to get the trunk branch as CvsBranches in the Wiki mentions. However: cvs [server aborted]: no such tag trunk How should this preferably be done? -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
--- Ryan Underwood [EMAIL PROTECTED] wrote: [snip] No code was copied, only some defines. I need other people to check the code and tell me if it will break on other video cards. I only have a G400 DH, but there is G450, G550, G200 DH, G200 non-maven DH, etc which need to be tested, and some changes were made to the main driver code too so there is a potential I made a mistake that would affect even non-G series matrox cards. The main thing I am worrying about is how some of the maven registers I used will behave on different cards. Right now I am trying to get DDC working on port 2 so I can be sure my i2c code is 100% correct. You might ask Petr or one of the kernel fbdev or directfb developers. they might be able to help you. unfortunately all my matrox cards have either died or or are no longer around :( Alex __ 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] MGA font corruption revisited - now reproducible
On Tue, Jan 20, 2004 at 02:13:50PM -0800, Alex Deucher wrote: --- Ryan Underwood [EMAIL PROTECTED] wrote: [snip] No code was copied, only some defines. I need other people to check the code and tell me if it will break on other video cards. I only have a G400 DH, but there is G450, G550, G200 DH, G200 non-maven DH, etc which need to be tested, and some changes were made to the main driver code too so there is a potential I made a mistake that would affect even non-G series matrox cards. The main thing I am worrying about is how some of the maven registers I used will behave on different cards. Right now I am trying to get DDC working on port 2 so I can be sure my i2c code is 100% correct. You might ask Petr or one of the kernel fbdev or directfb developers. they might be able to help you. unfortunately all my matrox cards have either died or or are no longer around :( I got DDC working. It was my second monitor that was the problem; its EDID data seems to be corrupt. It doesn't even work on the first head, and I can read my first monitor's EDID on the second head, so looks like we are in business. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
