CVS update (matrox accel)

The latest SDL CVS update contains some matrox hardware acceleration.
http://www.devolution.com/~slouken/SDL/cvs.html

I’d appreciate somebody looking at it, as the blit clipping doesn’t
work, and the colorkey blitting does strange things.
(code in src/video/fbcon/SDL_fbmatrox.c)

To test the hardware colorkey blits, run the testsprite program with
the -hw and -flip command line arguments.

What works: Allocating hardware surfaces, normal accelerated blits,
and normal color fills.

I am also including an unofficial patch to the framebuffer console
driver which enables SDL to wait for the vertical retrace. I’ve
seen some discussion on how this could be done, but I haven’t seen
any code doing it in the framebuffer console driver yet.

BTW, I noticed that one of the Matrox blit parameters was a YUV
colorspace flag. grin Anyone have the Matrox specifications handy?

See ya,
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
-------------- next part --------------
diff -ru tmp/linux/include/linux/fb.h linux/include/linux/fb.h
— tmp/linux/include/linux/fb.h Sat Apr 24 17:51:48 1999
+++ linux/include/linux/fb.h Sun Dec 19 18:50:58 1999
@@ -26,6 +26,7 @@
/* #define FBIOSWITCH_MONIBIT 0x460E */
#define FBIOGET_CON2FBMAP 0x460F
#define FBIOPUT_CON2FBMAP 0x4610
+#define FBIOWAITRETRACE 0x4611

#define FB_TYPE_PACKED_PIXELS 0 /* Packed Pixels /
#define FB_TYPE_PLANES 1 /
Non interleaved planes */
diff -ru tmp/linux/drivers/video/fbmem.c linux/drivers/video/fbmem.c
— tmp/linux/drivers/video/fbmem.c Mon Aug 9 12:04:40 1999
+++ linux/drivers/video/fbmem.c Sun Dec 19 18:55:26 1999
@@ -23,6 +23,7 @@
#include <linux/console_struct.h>
#include <linux/init.h>
#include <linux/proc_fs.h>
+#include <asm/io.h>
#ifdef CONFIG_KMOD
#include <linux/kmod.h>
#endif
@@ -411,6 +412,14 @@
if (copy_from_user(&cmap, (void *) arg, sizeof(cmap)))
return -EFAULT;
return (fb->fb_get_cmap(&cmap, 0, PROC_CONSOLE(info), info));

  • case FBIOWAITRETRACE:
    +#ifdef i386
  •   while (!(inb_p(0x3da) & 8));
    
  •   while (inb_p(0x3da) & 8);
    
  •   return 0;
    

+#else

  •   return -EINVAL;
    

+#endif
case FBIOPAN_DISPLAY:
if (copy_from_user(&var, (void *) arg, sizeof(var)))
return -EFAULT;

http://www.devolution.com/~slouken/SDL/cvs.html
The Matrox acceleration on the framebuffer console is mostly complete.
I’ve only tested it with the Millenium I, so it should be tested on
the Millenium II, the G200 and G400.

Currently double-buffering, vertical retrace synchronization, color-fill,
and video <–> video blitting are all accelerated. Theoretically colorkey
blitting is also accelerated on the Millenium II and GX00, but I haven’t
tested either of those configurations.

There might be subtle bugs left in the blitter related to blit offsets,
but I think I tested everything. Currently surfaces in video memory are
limited in pitch to the current video surface width. This isn’t
necessarily required by all video drivers, but it guarantees that
the alignment will be correct, and greatly simplifies memory management. :slight_smile:

I did notice support for YUV surfaces in the chipset… :slight_smile:

Whew. :slight_smile:

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec