[Dri-devel] using DRI (mga400/vodoo3)with xmame.xgl (opengl renderer)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dear dri team,

we have made some experiences with using
DRI with the mga400/vodoo3 hardware and
xmame.xgl (opengl renderer).

getting xmame.xgl:
====================

the latest xmame.xgl can be obtained from:

	pre1 of B13.1 is available at

         http://x.mame.net/download/xmame-0.37b13.1pre1.tar.bz2

or download the b12.1 from:

	http://x.mame.net

and my patch from 

	http://www.jausoft.com/Files/GLMame/

	http://www.jausoft.com/Files/GLMame/xmamexgl-0_74-glmamejau_cab.tar.bz2

problem description:
	http://www.jausoft.com/Files/GLMame/xmame-doc-4.html#ss4.2

	last subsection: Common Questions (FAQ), last entry !

xmame.xgl description:
======================

xmame.xgl has some cmdline option, modifying the opengl usage:
	-gllib <libname> (<libname> := libGL.so is default
	    the opengl library is loaded dynamically at runtime 
		(dlopen (libGLName, RTLD_LAZY | RTLD_GLOBAL))
	    all gl, glu and glx functions are fetched by
		- glXGetProcAddress[ARB]
	      or, if this does not work
		- dlsym

	-[no]glext (-glext is default)

            - IF use glext
		 - try to use extension(s):
			EXT_color_table (and EXT_color_subtable)
			glColorTableEXT (and glColorSubTable) 
                 - setting up the color table using glColorTableEXT
                 - using the mame orig. palleted bitmap for the texture
                 - this texture must be ! _not_ transfered to rgba space !
                   within the opengl driver, because of the glColorTableEXT usage !
                 - so, the texture is opengl internally used as a it is, a palleted texture
                 - the texture is transformed to rgba space only in the last finishing,
                   the final writing to the frame buffer !

             - IF use noglext
                 - setting up the color table using glPixelMapusv
                 - using the mame orig. palleted bitmap for the texture
                 - this texture ! _is_ ! to rgba space, immediatly after reading (slow) !
                 - so, the texture is opengl internally used as as a rgba texture !	

	-[no]glaa (-glaa is default)
		IF -glaa
			glShadeModel (GL_SMOOTH);
			glEnable (GL_POLYGON_SMOOTH);
    			glEnable (GL_LINE_SMOOTH);
    			glEnable (GL_POINT_SMOOTH);
		ELSE
			glShadeModel (GL_FLAT);
			glDisable (GL_POLYGON_SMOOTH);
			glDisable (GL_LINE_SMOOTH);
			glDisable (GL_POINT_SMOOTH);
		FIN

	- [no]glbilin (-glbilin is default)
		IF -glbilin
        		glBindTexture (GL_TEXTURE_2D, <texname>); 
	       		glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
        		glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
		ELSE
        		glBindTexture (GL_TEXTURE_2D, <texname>);
			glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
			glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
		FIN

the texture which is being mapped, 
is a color index one.

to bind it, is use:
	glPixelStorei (GL_UNPACK_ROW_LENGTH, memory_x_len);
	glPixelStorei (GL_UNPACK_ALIGNMENT, 8);

	IF -noglaa
		glPixelTransferi (GL_MAP_COLOR, GL_TRUE);

	glEnable (GL_TEXTURE_2D);

	glBindTexture (GL_TEXTURE_2D, <texname>);

	IF -glext
	  IF -glaa
		glColorTableEXT (GL_TEXTURE_2D, GL_RGBA,
                                 ctable_size, GL_RGBA, GL_UNSIGNED_BYTE, ctable);
	  ELSE
		glColorTableEXT (GL_TEXTURE_2D, GL_RGB,
                               ctable_size, GL_RGB, GL_UNSIGNED_BYTE, ctable);
	  FIN
	ELSE
	  glPixelMapusv (GL_PIXEL_MAP_I_TO_R, ctable_size, rcolmap);
          glPixelMapusv (GL_PIXEL_MAP_I_TO_G, ctable_size, gcolmap);
          glPixelMapusv (GL_PIXEL_MAP_I_TO_B, ctable_size, bcolmap);
	  IF -glaa
		glPixelMapusv (GL_PIXEL_MAP_I_TO_A, ctable_size, acolmap);
	FIN

	glTexSubImage2D (GL_TEXTURE_2D, (GLint)bitmap_lod,
                         0, 0,
                         width, height,
                         GL_COLOR_INDEX, GL_UNSIGNED_BYTE, <texname>);

results:
=========

Sven Goethel reported:

Mesa 3.4 standalone:
    - everything runs well ;-), but slow
      with the options: "-noglaa -noglbilin"
      the performance is better !

Nvidia 0.769 + Xfree86 4.0.2:
    - everything runs fine (sorry ..)

Vodoo3 and DRI (from xfree86 4.0.2 std. distribution)
MESA DRI V3 20001101, 1.2 Mesa 3.4:
    -16bpp:
	- with "-glext" and "-glaa" (defaults)
	  we only see the "MESA" texture ;-)

	- with "-glext" and "-noglaa"
	  everything runs fine !

	-with "-noglext"
	  everything runs fine .. but is very slow, of course !

    -24/32bpp:
	- with "-glext"
	  we only see the "MESA" texture ;-)

	-with "-noglext"
	  everything runs fine .. but is very slow, of course !

Matt Lowry reported:

Matrox G400 with 32M ram / AGPx4,
XFree86-4.0.3 (official binary distro) on top,
Mesa DRI G400 20000510, 1.2 Mesa 3.4, 16 bit / 1280x1024:

 - With -noglaa the colours are still messed, but at least the prog runs at
    normal speed. Here normal speed is around 320% for normal window size
    and around 170% for fullscreen.
 - With -noglext the colours are fixed. If I run at fullscreen size then
    the prog is unresponsive, but if I run a normal window size the prog is
    "slightly responsive" (does actually respond to input eventually,
    emulates 3-4 frames a second).
 - With -noglaa AND -noglext the colours are fixed and the prog is
    responsive; runs at normal speed. Here normal speed is around 50-60%
    for both normal window size and fullscreen window.

    -16bpp:
	- with "-glext" and "-glaa" (defaults)
	  we only see the "MESA" texture ;-)

	- with "-glext" and "-noglaa"
	  everything runs fine !

	-with "-noglext"
	  everything runs fine .. but is very slow, of course !

    -24/32bpp:
	- with "-glext"
	  we only see the "MESA" texture ;-)

	-with "-noglext"
	  everything runs fine .. but is very slow, of course !

 - Running without any cmdline params the colours are messed and the prog
    is unresponsive.
 - With -noglaa the colours are still messed, but at least the prog runs at
    normal speed. Here normal speed is around 320% for normal window size
    and around 170% for fullscreen.
 - With -noglext the colours are fixed. If I run at fullscreen size then
    the prog is unresponsive, but if I run a normal window size the prog is
    "slightly responsive" (does actually respond to input eventually,
    emulates 3-4 frames a second).
 - With -noglaa AND -noglext the colours are fixed and the prog is
    responsive; runs at normal speed. Here normal speed is around 50-60%
    for both normal window size and fullscreen window.

So .. is this a bug within DRI (MGA400, Vodoo3) ?

please help

cheers, sven

- -- 
mailto:sgo...@ja...
www   : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/
voice : +49-521-2399440; fax: +49-521-2399442; icq-uin: 108264795
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6vCjlHdOA30NoFAARAiCSAJ98cD4/y9SkgjOs/CEgrJcohVJGBQCeNMQ1
GGO5itSDycE+69X0XjwWm+M=
=G3SJ
-----END PGP SIGNATURE-----