SiS 315 Graphics Engine

1. SiS 315 Graphics Engine Introduction to some capabilities of graphics accelerator hardware

2. SVGA incompatibilities • SVGA manufacturers have different ways of implementing their accelerator features • SiS provides 2D and 3D graphics engines • Access is via memory-mapped i/o ports • This requires a new Linux device-driver, to allow mapping the io-ports into user-space • A suitable driver is our ‘engine2d.c’ • It only works with SiS graphics hardware

3. SiS policy • SiS officials say it is not company policy to provide individuals with programming info • But some programming info is available in ‘unofficial’ sources (e.g., in-line comments by programmers who wrote ‘open source’ device-drivers for Linux XFree86 systems) • Not everything is fully explained, though • So a lot of ‘trial-and-error’ is necessary!

4. Where to look for info • The source-code for drivers distributed with the Linux kernel can be found in: /usr/src/local/linux/drivers/video/sis • Recent versions of the SVGALIB package have some SiS-specific code you can view • There is also a website maintained by the author of the SiS driver for Linux (Thomas Winischhofer): http://www.winischhofer.net

5. Linux kernel modules • Linux permits installing new kernel code at runtime (i.e., without recompiling kernel) • A system administrator can install/remove kernel modules, and may grant users this same privilege (by adjusting permissions on the ‘insmod’ and ‘rmmod’ commands) • Modules are written in the C language (not C++) and include special header-files that are distributed with the kernel source-code

6. Module requirements • Must define __KERNEL__ and MODULE before any #include statements • Must have: #include <linux/module.h> • Maybe others: e.g., #include <linux/pci.h> • Must have these two public functions: int init_module( void ); void cleanup_module( void ); • Usually device-specific function(s), too

7. Driver-Module Structure // filename and module abstract #include --------- #define ----------- typedef ------------- static data objects This is the device-driver core read() write() lseek() mmap() struct file_operations init_module() These are for module mgmt cleanup_module() MODULE_LICENSE

8. Our ‘engine2d.c’ module • Our module only needs one extra function: int my_mmap( ); • Also needs a ‘struct file_operations’ object: struct file_operations my_fops; • The ‘init_module()’ function will install that structure-object in kernel-space, together with executable code which it references • The ‘cleanup_module()’ function removes that code and data after we’re finished

9. How it works user-space kernel-space int $0x80 runtime library syscall handler iret ret call mmap ret application program device-driver module

10. Pentium’s Page-Tables • Our driver’s ‘mmap’ method calls a kernel procedure that knows how to setup some new entries in the CPU’s page-directory and page-table data-structures which give the effect of mapping the GPU’s i/o-ports into an application’s virtual address-space • Then the program can read or write these i/o-ports as if they were memory-locations

11. The PCI Interface • The graphics hardware connects with the CPU using the AGP bus, conforming to a standard PCI-bus programming interface • Linux kernel functions can be called from our ‘init_module()’ to query the GPU chip • Identify the chip’s make and model • Get physical address for its i/o-memory • Determine the length of the i/o-memory

12. Linux device-nodes • Linux treats devices as if they were files • We must create a device-file for our GPU • Device-files normally go in ‘/dev’ directory • We invent a filename for our device-file • We pick an unused device id-number • A system administrator creates the file: root# mknod /dev/sismmio c 101 0 root# chmod a+rw /dev/sismmio

13. Our ‘sisaccel.cpp’ demo • We have written a short demo-program • It uses the SiS 315’s 2D graphics engine • It fills some rectangles with a solid color • It also shows how to draw a line-segment • These operations could be done, as we know, with software algorithms – but it’s faster to let the hardware do it instead • You are invited to experiment further!

14. #include “sisaccel.h” • This header defines symbolic names for some of the 2D engine’s i/o addresses • Accelerator commands involve writing the values for various parameters to these i/o port-addresses, concluding with a value that encodes a desired engine ‘command’ • Some Extended Sequencer registers must be initialized beforehand, to enable engine

15. Truecolor Graphics • We used VESA graphics mode 0x413B • Screen-resolution is 800x600 • Pixels are 32-bits in size (‘Truecolor’) • Recall the Truecolor pixel-format: byte2 byte1 byte3 byte0 Alpha channel

16. Makefile • In order to compile the ‘engine2d.c’ driver, we recommend using the ‘Makefile’ on our class website (copy it to your directory): $ make engine2d.o • Be sure you compile it BEFORE you try to run the ‘gpuaccel.cpp’ demo-program • Don’t forget that your IOPL needs to be 3 e.g., run the ‘iopl3’ program first