SiS 315 Graphics Engine Introduction to some capabilities of graphics accelerator hardware.
Published byModified over 4 years ago
Presentation on theme: "SiS 315 Graphics Engine Introduction to some capabilities of graphics accelerator hardware."— Presentation transcript:
SiS 315 Graphics Engine Introduction to some capabilities of graphics accelerator hardware
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
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!
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
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
Module requirements Must define __KERNEL__ and MODULE before any #include statements Must have: #include Maybe others: e.g., #include Must have these two public functions: int init_module( void ); void cleanup_module( void ); Usually device-specific function(s), too
Driver-Module Structure init_module() cleanup_module() MODULE_LICENSE struct file_operations write() lseek() mmap() read() static data objects #define ----------- #include --------- typedef ------------- // filename and module abstract This is the device-driver core These are for module mgmt
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
How it works kernel-spaceuser-space application program runtime library syscall handler device-driver module int $0x80 iret mmap ret call ret
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
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
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
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!
#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
Truecolor Graphics We used VESA graphics mode 0x413B Screen-resolution is 800x600 Pixels are 32-bits in size (‘Truecolor’) Recall the Truecolor pixel-format: Alpha channel byte0byte3 byte2byte1
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