Back to Open Graphics
Newsletter Archives

Dec 10th 2006 Open Graphics Project Newsletter

Over 130 Posts covered in this Newsletter

ANNOUNCEMENTS

OGD1

We know how long you have dreamt about the possibility of a fully open graphics card. We have the First Photographs of what will be a genuinely Open Graphics Card.

This card is not a dream. The card is real.

The prototype, is a PCI based FPGA development card with dual DVI output, TV-out and three 300MHz Analog to Digital Converters. After it finishes stress testing, Traversal the company founded by members of the Open Graphic Project will not only be selling this board for those interested in a serious FPGA development tool but will offer the card at a great discount for the Open Graphics Project. Under the Open Graphics Project this development board will continue to grow until it becomes a graphic card in it's own right. However the project does not finish there, because we will need to move from the standard PCI interface onto other faster interfaces. And after the engine and drivers have been finished we then want to investigate moving the graphic's engine into an ASIC, which will enable our design to reach even greater speeds and very reasonable prices. Before we reveal the photographs, lets review some of the targets of OGP, the Open Graphics Project.

This is a card that will give you back your right of freedom over your computer.

OGD1 Features

• Full technical documentation
• Programmable internal logic
• Dual dual-link DVI-I ports
• S-video port
• PCI

Because OGDI can drive two dual-link DVI monitors, Timothy noted: as a graphics card, for some applications, OGD1 is actually cheaper than existing solutions (in the market today). As Daniel pointed out: a "quad link" panel.. could be done with OGD1.


Patrick McNamara, President of the Open Hardware Foundation: The development card OGD1 represents a significant milestone for the Open Graphics Project and the larger hardware development community. It provides a development platform on which the project members can begin the process of turning simulations into silicon. While this card was developed in order to support development for the Open Graphics project, it contains such a serious FPGA it has the capability to be used in a wide variety of designs. The release of the OGD1 will provide a new resource for serious hobbyists, University curricula, and professional engineers. As part of our support for the Open Graphics Project and open hardware in general, the Open Hardware Foundation will be making OGD1 cards available to qualified contributors through the Open Graphics Project Developer Assistance Program.

How can you help? There are three ways.

1. Verilog developers are always welcome.
2. Those able to write Drivers can support their favorite hardware
3. The Open Hardware Foundation will soon be accepting Donations. They will help our developers purchase and work together on this Development board

Now, we have finished teasing you with the details - lets see the first photo's of the ODG1 prototypes. OGD1-256DDAV



OGD1 makes use of two programmable chips; The small Lattice chip already holds the PCI code separate from the enormous Xilinx chip, where developers program the graphics engine. It is the beginning.


The board designer Howard gave us all a brief walk through:
the 3 square looking devices on the right hand side of the top of the board are power supply inductors. The High speed DACs are on the bottom side near the DVI video connector. The JTAG programming headers are all placed along the top edge of the board. Looking down on the top side, the leftmost connector on the top edge (J4,J5,J6) is the JTAG header for the Lattice XP device. Just to the right of it, and a little towards the center of the board is the JTAG header for directly programming the Xilinx Spartan 3. (J8, J9, J10) The two pin header near the center of the top edge (J11) are INIT and DONE test points from the Xilinx FPGA. Just to the right of these are some more test points that could be used as inputs to or outputs from the Lattice device (J12,J13,J14). To the right of these are programming headers (J16, J17,J18) to program the 16Mb SPI PROM for the Xilinx device via the Lattice FPGA. To the right of these are 8 test points(J20). These test points have corresponding ground pins (J19) so that its possible to connect a 16 way ribbon cable via an IDC connector with alternate ground wires.

The progress of OGD1 Hardware Testing

Howard Parkin:
Testing of OGD1 is going well. We have tested the PCI Interface and verified read and write operations to/from both SPI PROMs (Boot PROM and Xilinx Config PROM). We have successfully programmed the Spartan 3 FPGA from the SPI PROM and written and read registers in this device via PCI. The next step is to test memory and then later add a simple video controller to check the Analogue and DVI Video out.

Licensing

There are expected to be three licenses with certain OGA (Open Graphics Architecture) components (video, memory, PCI, SPI, etc.):

1. Via GPL — you can use it on your own design, as long as you conform to GPL
2. Single-use proprietary — when you buy N OGD1 boards, you get N individual proprietary licenses to use those OGA IP blocks however you want, regardless of the GPL.
3. Full proprietary — You pay a license fee and can use those blocks anywhere in any design, without concern for the GPL.

Given these terms, we're planning on explicitly permitting someone to reprogram only the XC3S4000, leaving the PCI controller intact and reselling it commercially... because effectively, they're reselling OGD1 boards as another product and conforming to the single-use commercial license for the IP that comes with it. Note that some of this ("Logic Core") won't come with OGD1 right away. But it doesn't matter where you get the code from (as long as it's Traversal's version); you can use it with OGD1 without restriction. Source OGPN15

The Numbers

Power

The projected power requirements of OGD1 are "between 18 and 23 watts".

Performance

We are initially developing a card for the desktop computer running 2D and 3D applications. Based on the hardware, our design has the potential to better a Radeon 7000 graphics card.

(1) Projections for the OGA graphics design running on the FPGA Development board OGD1
(2) Ge Force 2 GTS http://techreport.com/reviews/2000q2/geforce2/
(3) Radeon 7000 PCI
http://www.newegg.com/Product/Product.asp?Item=N82E16814102447
http://www.scan.co.uk/Products/ProductInfo.asp?WebProductID=47607

Hardware

Description	OGD1/OGA	Ge Force 2 GTS	Radeon 7000 PCI
Memory clock rate (DDR MHz)	350-400	333	300
Memory bus width (bits)	128	128	64
Video memory (MiB)	256	128	64
Maximum display resolution	6144x2048	??	2048x1536
Total memory bandwidth	1600	1333	600

Performance Targets

With these specifications we feel the following are reasonable targets for the development board with the OGA graphics code.

Description	OGD1/OGA	Ge Force 2 GTS	Radeon 7000 PCI
GPU clock rate (Mhz)	150	200	150
Memory bandwidth minus video	1517	1250	517 ?
Usable memory bandwidth	1350	1060 ?	430
Maximum GPU pixel rate (2D)	600-800	800 ?	??
Maximum GPU pixel rate (3D)	300-400	800	150
Solid fill (2D)	600-800	800 ?	430 +
Gouraud shaded fill (3D)	300-400	800	150 ?
Bitblt (2D)	600-675	530 ?	190 +
Single-texture fill (3D)	300-400	530 ?	150 ?
Bitblt+XOR (2D)	450	353 ?	129 +
Two-texture fill (3D)	300-400	353 ?	143 ?
Polylines (2D/3D)	150-200	200 ?	44.5 +

The numbers explained

It's not a gaming card, but Quake III should, we think, be usable. For 1280x1024, a Ge Force 6200 AGP 256MB running a Linux Quake Benchmark demo (from ftp.idsoftware.com) drops down to 1346 frames, 23.7 seconds, 56.9 fps, and for 1280x1024, a Radeon 7000 drops down to 1346 frames, 137.7 seconds, 9.8 fps. With our development card and the OGA1 GPU, our target is a frame rate of between 20 and 30 FPS on Quake III at 1280x1024.


Notes:
? Indicates a figure that is based on estimation and extrapolation.
+ Indicates a figure that comes from real benchmarks.
All pixels are 32 bits. Where exact numbers are not available or published benchmarks are ambiguous, estimates are made by calculating from available numbers. The unit 1Mp is equal to 1,000,000 pixels. All numbers are given in units of Mp/s, unless otherwise stated.
With ODG1, the video controller's physical resolution limit is at least tens of thousands of pixels horizontally by tens of thousands vertically. However, each video output has a maximum pixel rate of 330 Mp/s. The value of 6144x2048 was therefore chosen as a practical maximum for a frame rate of between 50 and 60Hz.
For the GPU clock rate, Timothy: We've done other things with the 3S4000, 100Mhz is generally quite easy, and 150 isn't overly difficult. (Our target is 150Mhz).

• Projections for the OGA-1 open graphics architecture running on the OGD1 are calculated based on projected clock rates, and design characteristics.
• GeForce 2 GTS performance figures are estimates based on published benchmarks from reviews.
• Radeon 7000 PCI performance figures are based on actual x11perf tests, using the open source Radeon drivers. *However 3D performance figures are estimated from 2D performance figures and published clock rates and design characteristics.

Progress and developments

Video Head 0 Tests

Nicholas posted a “trivial Makefile” (...)
Type something like "make analog; make" or "make both; make debug; make" to test it out.

Timothy explained what was wanted
The idea is to get something we can look at on a scope and also something simple to see on a monitor. A good test pattern that we like to use is to put a big boxed X on the screen. Start with a black screen. If you're on the first or last scanline, make the pixel white. If you're on the first or last column, make the pixel white. The tricky part is the line. I would suggest something vaguely resembling a bresenham algorithm. For every column, add the height of the screen to a register. For every row, subtract the width. Whenever the number is within some range make the pixel white. Something like that. (experiment) with the math in software first, watching the numbers and seeing what they look like along the diagonal.

Licensing and SVN Files

Timothy agreed with Mark Baker's suggestion:
include the full copyright notice in every file. You can grab it out of this file:
https://svn.suug.ch/repos/opengraphics/main/trunk/new_model/ogmodel.h

Artwork

For those wanting to help with artwork for OGP, the font is Bitstream Charter Bold and Petter recommends:
"Filters"/"Enhance"/"Sharpen" and I think a value of 40--50 makes the image more pleasant to the eye without too bad side effects.
If you were wondering how we obtain such clear pictures, a scanner provides very clear pictures. Here are the raw pictures (4.7MB for the top, 2.3Mb for the bottom) "Copyright 2006, Traversal Technology, LLC"
http://www.traversaltech.com/ogd1_photos/ogd1_bot.bmp
http://www.traversaltech.com/ogd1_photos/ogd1_top.bmp

Post to the list if you wish to help with artwork.

OGD Architecture

OGD1 Part Numbers

{Root Number} – {Video Memory}{Video Output Interfaces}{Special Options eg: A1 OGA firmware installed}

Jack explained the naming conventions

Field	Example Value	Example Description
Root number	OGD1P-	OGD1 board with PCI Bus
Video memory	256	256 MiB
Video outputs, in order, skip any not installed
First interface	D	Dual-link DVI
Second interface	D	Dual-link DVI
Third interface	A	Analog video, 75 ohm, VGA compatible
Fourth interface	V	TV video
Special options, in alphanumeric order, each preceded by a dash
Factory firmware-RTL	A1	OGA1 Firmware

All OGD1 boards have DVI and analog video on connector #1 and DVI on connector #2 and are standard features. The numbers make it explicit that they're in the base product. Field separator in customer part numbers are '-', and the slash is reserved for internal part numbers based on the same root number. Customers are more used to the dash, and it makes a clean format separation between product part numbers and piece part numbers.


The Prototype which has been undergoing testing is known as an OGD1P-256DD.

Expected Product Models
OGD1P-256DDAV will be the OGD1 PCB, 256MiB of RAM, two dual-link DVI transmitters, analog (VGA) output, and TV. (The A and the V aren't on the current prototype).
OGD1P-256DDAV-A1 is expected to come with the OGA1 GPU logic in it.



For further information about this board please see the OGD1 page.

List Discussions

Dumb Terminals

The Development Board opens up the possibility of engineers, students and universities experimenting with graphics or using the card for other PCI based hardware designs. Nick L wondered about an application with Plan 9 (http://plan9.bell-labs.com/wiki/plan9/):
In my 'distributed' system, a '(thin client)'s video hardware just pushes image rectangles around the screen. For video requiring intensive computation, the a rectangle's image is streamed from a 'CPU server'. The 'CPU server' is just a 2.60 GHz Northwood — just one core, and probably can't cut (decent) real time 'raytracing'. Obviously it would be better to have 16 cores, but it seems PC hardware is going nuts and replacing everything — I have to upgrade from AGP and PCI to PCI Express, from DDR to DDR Two, from PATA to SATA. Now, not only are commodity parts useless, but drivers have to be written for Plan 9. (I guess we could just steal the drivers from Linux, but that still means all those great, old parts still go to straight to the dump.) So, instead of a new CPU for the 'CPU server'... how about an axillary processor, like the 'X/video/audio server' you mentioned? Like a 'Cell' processor on a PCI card on the 'CPU server' to take load off of the Northwood for 'raytracing'? Or if it wouldn't fit on a PCI card, a bigger board connected by ethernet. ... This (OGP) project currently conserves the old bag of tricks... but will it be possible to adapt it to 'raytrace'?

Timothy
Well, obviously, OGD1 can be used for anything that fits in the FPGA. Also, there has been at least one FPGA-based raytracing project. (...) Changing from rasterizing to ray-tracing would be an incredible paradigm shift, for which there is no existing software. Think hard about what would be required to translate OpenGL into what a raytracer
would need. (...) We can experiment with ray-tracing engines in hardware. We need to consider the general cases. How can we represent any object we want in a scene? How does the raytracing engine process the scene? What kind of interface would we provide to the applications? And how would legacy apps be emulated?

Ulf gave his thoughts about translating OpenGL into what a raytracer would need:
Not really doable (or useful). A raytracer would have to have an entirely different API. (...) I've got 3/4 vhdl raytracer implementations here, and I'd be willing to try it on the OGD board, if I can get one with an fpga (and I can get the University to pay for it). The raytracer still needs (at least) a memory controller, which I've been unwilling to implement. And a pci interface would also be nice.

Timothy
You can use the memory controller I designed for OGD1. It is, after all, released under GPL.

Nick L explained a bit about his application
In Plan 9, I work with rectangle images that translate throughout and translate on-off the visible rectangle. Also, rectangle images (should be able to) scale. Ideally, too, mathematical models could be visualized in real time. Abstract things as this can be done perfectly with our current bag of tricks, but any hack at portraying reality should work with light particles: id est, it should trace rays. And, could a 'raytracer' tackle abstract things just as well, or better, too?

Hugh
Implementing an OpenGL capable frame buffer / texture mapper gives you exactly these capabilities. You have double buffering, fully scalable rectangular images, and other 2D image capabilities such as alpha compositing and arbitrary image warping. OpenGL is a more powerful 2D rendering library than Xlib (Linux), GDI (Windows), or QuickDraw? (Mac). All the next generation 2D graphics libraries are based on 3D OpenGL capable hardware: Xrender/Xcomposite for Linux, Quartz Imaging for Mac, Avalon or whatever it is now called for Windows. (...) With multiple cores, real time ray tracing becomes possible. But it will still be useful to have a 'smart' framebuffer that can do image resizing and compositing itself instead of doing that on the CPU. So the open-graphics card will still be useful.
Implemented by video card developers? I doubt it. What is more likely is general purpose CPUs built onto the graphics card, so you can download a raytracer at runtime. (...) The first open graphics card *won't* try to implement an entire 3D pipeline, in particular there's no hardware T&L

Nick L
So, it's OpenGL stuff does 2D and 3D without the gimmicks? Sounds perfect.

Timothy
We've just boiled it down to the least common denominator for both 2D and 3D. (Well, not least, but minimum we considered to be of practical value.)

Nick S looked to the future..
Raytracing produces really, really beautiful and lifelike images, but it requires a lot of repetitive computation ==> Not well suited to CPU. In terms of OGA/ODG, we should probably support enough of OpenGL that linux apps are reasonably fast. Modern CPUs are reasonable at some things, so if a subset of OpenGL is supported (on intermediate boards), the most possible computation should be run on the graphics card. I use ratpoison as my window manager, but people using Metacity or the like might have varying results on performance - we should probably test these out in the future (the very, very far future) to see how pleasing it is. As for a smart framebuffer, I totally agree. Even the ability to quickly shade a 2D polygon in hardware can GREATLY speed up almost any graphics application (this is not from any real experience with HW-accelerated polys, but I know from testing framebuffer graphics apps on different processors how much of a difference it makes. I am sure this scale up the GFLOPs nicely :-)). Of course, we should support more than that, but starting small is always nice.

Hardware Selection and Revision

Potential Competition

Jon noticed:
USB FPGA Prototype 400K $139.95 USB FPGA Prototype Board. Xilinx Spartan 3 400K FPGA. USB 2.0 High Speed. Open Source software.
http://www.atrandomresearch.com/usbp/usbp_fpga.html
Isn't this the FPGA being used for prototyping?

Daniel explained that while it is the same Xilinx family it was not the same:
we use 10x bigger FPGA

Luc
Note that that "Open Source software" probably refers to their examples; you still need the Xilinx Webpack, which is proprietary (As we currently need to do).

Graphics Queries

One post queried why we use the term Xserver
Hamish
There's actually nothing weird about the way it uses server terminology. A server provides a service. You have an XServer because it provides an X Service to the X clients (Applications) that use it. Just like an NFS server provides an NFS service to an NFS client... You just have to realize that it's named for what it does...

Lourens
you have to understand that the X model sees rendering of things on a screen and reading events from input devices as a service. From the perspective of an end user, that's odd. The service I'm using right now is the "send an email" service, and it's provided by Kontact. But in X terminology, Kontact is a client, not a server. Which makes sense if you look at it from the perspective of the application, but not if you look at it from the perspective of the user.

Open Hardware Foundation (OHF)

Patrick Mc Namara who has been hard at work, explained what was left to do for the Open Hardware Foundation:
1. Filing of incorporation paperwork . This means the Foundation would soon be a legal entity.
2. Receipt of the articles of incorporation. At this point, the OHF would be a legal entity and we could start accepting donations (Ed eg: Donations for ODG1, and look at the start of helping OGP developers obtain boards).

In the future this foundation will accept donations for OGP and the OGP Developers Assistance Program, helping more Developers purchase the serious hardware we call OGD1.

Mini FAQ for the Open Graphics Mailing list.

Where is the list?
Gmane.comp.graphics.opengraphics
How can I get it?
Using your favorite newsreader point it toward news.gmane.org and subscribe to comp.graphics.opengraphics
Which newsreader can I use?
There are many. Specialist software such as Pan (Linux & Windows) or Gravity (Windows) are well known, but there are many others, and often your favorite email software can mostly function as a newsreader.
Can anyone post?
Yes, the list is moderated

Suggestions for this newsletter are welcome and are made through the mailing lists.