Wrote a couple drivers
Saturday, 14. November 2009, 13:27:09
Since I got an S24 for the promise of writing drivers I had to follow through - tcx as sbus now uses the 'blitter' for scrolling and the stipple 'engine' for filling rectangles and drawing characters. This card is seriously weird.
First the non weird characteristics - it's got 4MB video memory, each pixel is 26bit with 2 bits control and either 8 bit palette or 24bit colour with or without gamma correction. It plugs into the SPARCStation 5's AFX slot which is basically the MicroSPARC's graphics bus which is 64bit wide and apparently works at more or less the same speed as the memory interface. To that add a DAC which understands the control bits, supports a hardware sprite etc, and different viesw on the graphics memory, either as 24bit without control, 24bit with control bits or 8 bit. So far so standard. The weird thing is how this card does graphics acceleration. It doesn't have a graphics processor, instead it has a 'blit space' and a 'stipple space'. Both respond to 64bit writes where the address you write to defines a target pixel in video memory and what you write into it defines a command which can be 'copy up to 32 pixels from one location to another' or 'write this 32 pixel pattern in this colour'. Stipple space supports only transparent patterns and they have to be aligned to 32 pixel boundaries. Blit space can copy 1 to 32 pixels without any alignment requirements. Both exist in two versions, either with access to the control bits or without ( although copies without control bits are kind of useless ).
I also added acceleration support to Xorg's suntcx driver, it uses EXA and supports block copies and rectangle fills.
After that I finally got around to write a console driver for the Sun PGX32 / TechSource Raptor GFX 8P. It's nothing special, just a Permedia 2 with 8MB SGRAM. For now pm2fb at pci uses the blitter for scrolling and rectangle fills. For some reason I couldn't get the drawing engine to actually draw anything, therefore characters are drawn by software and rectangle fills use SGRAM-specific fast fill operations. I must be missing something here since Xorg's glint driver clearly manages to get it to draw stuff. The whole thing is a mess - a dozen subunits, each with enable bits in a dozen different registers. I probably forgot to enable one crucial subunit which keeps drawing operations from doing anything else than zeroing rectangles out. Ah well, at least copy operations work right.
Finally, last week hell froze over and I had another look at my rev. 5 Shark's graphics chip. Finally cleaned up the igsfb hacks that have been sitting in my source tree for years, committed the mode setting code, made sure it doesn't behave any different than before on Krups, added support for Sun-like video mode specifiers in OpenFirmware's output-device variable.
So, on a rev. 5 Shark you can now
And igsfb will switch to 1280x1024 in 60Hz. Any mode defined in src/sys/dev/videomodes/ should work as long as the graphics chip can support it. There is no support for TV output yet.
The firmware doesn't support modesetting but it will happily ignore the mode specifier so we can use it and users can now treat the shark more or less like a weird Sun
That said, I also finally got around to write an Xorg driver. The xf86-video-igs driver so far only supports the VLB CyberPro 2010 but adding support for PCI variants and the CyberPro 2000 should be trivial - I don't have the hardware though. The driver is still quite immature, it uses wscons ioctl()s for the hardware cursor, doesn't contain any modesetting support ( it uses whatever it finds, that's why I added the code described above ), it only accelerates rectangle fills and block copies and there is no support to switch colour depth either. This will be added to the kernel driver though, make it switch to whatever is the highest colour depth possible in the given mode when switching to graphics mode.
First the non weird characteristics - it's got 4MB video memory, each pixel is 26bit with 2 bits control and either 8 bit palette or 24bit colour with or without gamma correction. It plugs into the SPARCStation 5's AFX slot which is basically the MicroSPARC's graphics bus which is 64bit wide and apparently works at more or less the same speed as the memory interface. To that add a DAC which understands the control bits, supports a hardware sprite etc, and different viesw on the graphics memory, either as 24bit without control, 24bit with control bits or 8 bit. So far so standard. The weird thing is how this card does graphics acceleration. It doesn't have a graphics processor, instead it has a 'blit space' and a 'stipple space'. Both respond to 64bit writes where the address you write to defines a target pixel in video memory and what you write into it defines a command which can be 'copy up to 32 pixels from one location to another' or 'write this 32 pixel pattern in this colour'. Stipple space supports only transparent patterns and they have to be aligned to 32 pixel boundaries. Blit space can copy 1 to 32 pixels without any alignment requirements. Both exist in two versions, either with access to the control bits or without ( although copies without control bits are kind of useless ).
I also added acceleration support to Xorg's suntcx driver, it uses EXA and supports block copies and rectangle fills.
After that I finally got around to write a console driver for the Sun PGX32 / TechSource Raptor GFX 8P. It's nothing special, just a Permedia 2 with 8MB SGRAM. For now pm2fb at pci uses the blitter for scrolling and rectangle fills. For some reason I couldn't get the drawing engine to actually draw anything, therefore characters are drawn by software and rectangle fills use SGRAM-specific fast fill operations. I must be missing something here since Xorg's glint driver clearly manages to get it to draw stuff. The whole thing is a mess - a dozen subunits, each with enable bits in a dozen different registers. I probably forgot to enable one crucial subunit which keeps drawing operations from doing anything else than zeroing rectangles out. Ah well, at least copy operations work right.
Finally, last week hell froze over and I had another look at my rev. 5 Shark's graphics chip. Finally cleaned up the igsfb hacks that have been sitting in my source tree for years, committed the mode setting code, made sure it doesn't behave any different than before on Krups, added support for Sun-like video mode specifiers in OpenFirmware's output-device variable.
So, on a rev. 5 Shark you can now
setenv output-device screen:r1280x1024x60
And igsfb will switch to 1280x1024 in 60Hz. Any mode defined in src/sys/dev/videomodes/ should work as long as the graphics chip can support it. There is no support for TV output yet.
The firmware doesn't support modesetting but it will happily ignore the mode specifier so we can use it and users can now treat the shark more or less like a weird Sun
That said, I also finally got around to write an Xorg driver. The xf86-video-igs driver so far only supports the VLB CyberPro 2010 but adding support for PCI variants and the CyberPro 2000 should be trivial - I don't have the hardware though. The driver is still quite immature, it uses wscons ioctl()s for the hardware cursor, doesn't contain any modesetting support ( it uses whatever it finds, that's why I added the code described above
), it only accelerates rectangle fills and block copies and there is no support to switch colour depth either. This will be added to the kernel driver though, make it switch to whatever is the highest colour depth possible in the given mode when switching to graphics mode.
WIDGETIZE