photo of Macallan

Rants & Ramblings

Subscribe to RSS feed

Posts tagged with "Xorg"

BeagleBoard progress

, , , ...

I've been working on omapfb and friends in the last few weeks, some of the results are:
  • Proper console selection via firmware variable - omapfb will no longer steal the console unconditionally. Output on the serial port remains active until omapfb takes over.
  • I added a driver for the on-chip DMA controller ( and in a bout of creativity named it omapdma ) - omapfb will use it for basic acceleration ( things like scrolling and drawing rectangles ). No putchar() acceleration, no anti-aliasing support (yet). Other drivers will need it as well, for example the audio part doesn't have its own DMA facility.
  • For hardware where we use DMA buffers as video memory I added a flag to tell bus_dmamem_mmap() to map memory cache-inhibited but with things like write combining, write buffering, relaxed ordering etc. enabled. Added support for it to ARM's bus_dma implementation and made omapfb use it.
  • omapfb now supports the WSDISPLAYIO_GVIDEO and WSDISPLAYIO_SVIDEO ioctl()s so screen blanking in X will turn off video output and that way allow both the monitor and the display controller to go to sleep.
  • wsdisplay finally got a new ioctl() to get all relevant framebuffer geometry info in one go, including things like pixel format and the actual amount of video memory. Now wsfb no longer needs to guess based on ioctl(WSDISPLAYIO_GTYPE). Added a generic implementation that just takes data from rasops_info. This also includes a flag to tell userland that the video memory it's about to map is normal main memory ( as opposed to memory sitting behind a potentially slow and/or laggy bus ) - wsfb uses this to turn off shadow, which gives a nice speedup in these cases. Made omapfb and Raspberry Pi's genfb backend support it.

A simple guide to Sun graphics hardware on NetBSD

, , , ...

NetBSD/sparc and sparc64 support quite a few different graphics cards and onboard chips these days, obviously they all have rather different strengths and weaknesses. Let's start with SBus cards:
  • CG3 - a dumb framebuffer with an 8 bit DAC that doesn't even support a hardware cursor. Slow. Avoid unless there really is no alternative. Firmware obeys mode specifiers on newer variants, older boards can switch video modes only by jumper or not at all. No significant heat output.
  • CG6/GX/Lego - a family of accelerated 8 bit graphics boards and onboard chips. Can have 1MB or 2MB of usable video memory, sometimes twice the amount to allow double buffering. The blitter is quite fast for its age, it can certainly keep up with any mach64, especially the Turbo variants. Boards with more than 1MB RAM support quite high resolutions as well. Firmware obeys mode specifiers on most boards. No significant heat output.
  • CG14/SX - VRAM module and onboard rendering engine found in SPARCstation 20 and some SPARCstation 10 models. CG14 is an oversized memory module with a DAC bolted to its side which fits into one of two special memory slots. It's available with 4MB and 8MB VRAM, acceleration relies on the SX chip on the mainboard which is unsupported in NetBSD for lack of documentation. Supports 8bit and 24bit output with a hardware cursor. Since it's sitting on the memory bus it's faster than any unaccelerated SBus board and thus actually usable. Firmware obeys mode specifiers. No significant heat output.
  • ZX/Leo - a monstrosity designed for 3D graphics. Supports up to 1280x1024 in 24 bit. These boards get very hot, especially the TurboZX. It's not very fast as a console, even with acceleration, and X in 24bit isn't supported yet for lack of documentation ( relavent bits about the DAC are missing in available docs ) - beats dumb framebuffers but not by a big margin. Firmware ignores mode specifiers, only tools shipping with Solaris can switch modes.
  • Fujitsu AG-10e - same size as ZX/Leo but a very different beast. Has separate graphics chips for 8bit and 24bit planes and WIDs. Decent speed in both X and the console, gets warm but nowhere near as hot as the ZX/Leo. Currently the only way to get accelerated X in 24bit with an SBus-only machine. Firmware ignores mode specifiers. It's supposed to support DDC2 but I see no evidence of that.

So, these are your options on 32bit Suns. If you want a reasonably fast console and by X you mean 'bunch of xterms' get a CG6. If you need more than 1152x900 get a GX+, TurboGX+, XGX+ etc. - they can go up to 1600x1200. Newer variants all occupy a single SBus slot. The Turbo prefix indicates a model with higher clock speed, the Plus indicates more than 1MB VRAM. Older variants may occupy two slots.
If you need 24bit and have two free SBus slots go find an AG-10e. The problem with this is that it won't obey mode specifiers and we lack documentation to switch video modes ourselves so it's 1152x900 in 66Hz, even though the board itself should support significantly higher resolutions. If you need 24bit in high resolution you'll need an 8MB VRAM module. It will happily switch to pretty much whatever mode you want ( as long as it fits into 8MB VRAM ) - speed isn't great but not too bad.
ZX/Leo, for now at least, should be avoided. As a console it's slower than a CG6 and burns a lot more electricity which is all converted into heat. And it's a two slot beast.

Now to UPA boards:
  • Creator/Creator3D - family of graphics boards, all have 5MB VRAM, the 3D variants have two 5MB buffers and a Z-buffer. These boards can also support higher resolutions by combining their two buffers. Newer boards are significantly faster than old ones ( UPA clock speed ranges from 66MHz up to 120MHz ). All boards support 1280x1024 in 24 bit, Creator3D can go up to 1920x1200.
  • Elite3D - more or less a Creator3D with geometry processors. Can not combine buffers for higher resolutions and for our purposes it's not significantly faster than a last generation Creator3D, it produces a lot more heat though ( nowhere near ZX/Leo levels though )
  • XVR-1000 - next generation Creator3D, with lots more VRAM, its own CPU, loads of texture memory. We support it only as a dumb framebuffer but thanks to its fast interface and even faster VRAM it beats some accelerated PCI graphics boards in X even without any kind of acceleration. Supports whatever your monitor needs and then some. Although it has a huge heat sink it doesn't seem to get all that warm, probably because we run it as a dumb framebuffer.

If you want a fast console get a Creator(3D). If you already have an Elite3D keep it unless you need more than 1280x1024. There is no useful documentation available on the XVR-1000 so we probably won't be able to support acceleration any time soon.
All these boards obey firmware mode specifiers and DDC2.

PCI boards:
  • PGX - a 2MB ATI Rage II, also found on older Ultra 5/10 mainboards. Works alright as an accelerated console but X in 24 bit is limited by video memory.
  • PGX24 - a 4MB ATI Rage Pro, also found on newer Ultra 5/10 mainboards. Faster then a Rage II, more suitable for 24bit thanks to more VRAM, happily runs 1152x900 in 24bit at 75Hz or higher resolutions in 8 bit.
  • PGX64 - an ATI Rage XL, also found on Blade 1x0 mainboards. Should work fine, should be faster than a Rage Pro, but I don't have the hardware. Consider it untested.
  • PGX32 - an 8MB Permedia2. Made by TechSource as Raptor GFX 8P. Firmware is buggy but we have workarounds. Performance as console and in X is decent, image quality in high resolutions may not be all that great though.
  • XVR-100 - a 32MB Radeon RV100. By far the fastest of the bunch as a console, things aren't that clear in X though. Image quality at high resolutions is good, it has a DVI port too.

This one's easy - get an XVR-100. Supported well as a console and in X - it's a bog standard Radeon. All should obey video mode specifiers and support DDC2.

Now there are Suns which have both SBus and UPA or both PCI and UPA.
The Ultra2 can take an AG-10e but the U1E can't - no two SBus slots directly next to each other. If you don't need X in 24bit a TurboGX(+) isn't significantly slower than an old Creator, if you already have a Creator keep it. AG-10e vs. old Creator is more complicated. Creator supports hardware accelerated alpha blending, AG-10e does not ( well, in theory the chip does but only via DMA from main memory which is unsupported ). Creator also has a faster link to the mainboard. AG-10e however has more usable video memory and doesn't use the CPU for image copy operations. Your mileage may vary. In real life there's probably not that much of a noticeable difference.

PCI vs. UPA:
XVR-100 as a console is fastest. In X however, a last generation Creator3D can give it a run for the money, especially in a well equipped Ultra 60. UPA offers much more bandwidth than PCI, even if you stick the XVR-100 into a 66MHz slot ( as you should, the board supports it ) - UPA runs at 120MHz though ( in an U60 at least ), and is 64bit wide. If you need DVI the choice is easy - there's no way to add DVI to any Creator.
In real life you will probably notice differences between the XVR-100 and a Creator3D - sometimes the Creator will be faster, sometimes the XVR-100. If you need many PCI cards you'll probably want a Creator or two ( the U60 has two UPA slots after all ). It's difficult to pick a clear favourite here - Creator3D boards are much faster at image transfers between main memory and VRAM, they're also much faster in alpha blending operations ( think anti-aliased font rendering ) although this is broken in Xorg 1.6 ( works fine in 1.4 though ). The XVR-100 has much more usable off screen memory, VRAM-to-VRAM blits are faster and don't use the CPU, unlike Creator it also supports video overlays. Heat output is no concern with either of them.

In -current NetBSD will let you use pretty much any combination of graphics boards in X ( exceptions are the unaccelerated ones which will work only as console / primary head ).

Xorg on O2

, , ,

My CRIME driver for Xorg is now more or less complete. Hardware acceleration for xrender supports everything KDE and friends need, missing features have been added ( clipping, framebuffer image downloads, pattern fills etc. ) and the latest version should give some nice speedup as well thanks to increased parallelism between CPU and rendering engine.
With this KDE runs quite well for a machine this old, konqueror is working just fine and nowhere near as sluggish as you'd expect after running things like firefox on IRIX.
Right now the only known case where the driver produces visible artifacts is libXaw and the funny way it draws greyed-out menu items ( prominent example: xterm's menu ), something that XAA doesn't even try to accelerate. Guess I'll have to add my own font renderer too.

Xorg on NetBSD

,

NetBSD 5.0 will ship with Xorg on x86, sparc64, macppc and shark - most other ports will still ship with XFree86 for one or more of the following reasons:
  • special hardware-specific Xservers couldn't be ported to Xorg yet ( some DEC specific ones, probably others )
  • not all drivers have been ported from XFree86 ( that's the case on sparc and sgimips )
  • platform-specific code wasn't ready at branch time ( alpha )

Actually, getting Xorg to work on prep, bebox, ofppc, ibmnws and netwinder should be pretty much trivial, it's just a matter of the right combination of skill, time and hardware in the right hands.

Alpha and sgimips may still ship with Xorg - the platform support code for alpha is working on at least some models and I have both newport and crime drivers working on my machines. Both beat their XFree86 equivalents soundly - the old newport driver is unaccelerated and the old crime driver is highly experimental, required unreleased hacks to work and still produces visual glitches. Both Xorg drivers support the usual acceleration features, including alpha-blending.
May 2013
S M T W T F S
April 2013June 2013
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31