Newsletter Archives

July 2nd 2006 Open Graphics Project Newsletter

• July 2nd 2006 Open Graphics Project Newsletter
• ANNOUNCEMENTS
  • OGD1 Revision
• Progress and developments
  • OGP and Traversal
    • Documentation logs
    • Artwork by Artists
    • Verilog Tutorials
  • Web Presence
  • Framebuffer design
  • Programming the ODG1 graphics development board
  • Frame rates and Video Capture
  • Drivers
  • Future designs
  • Commercial Graphic Chip Designs
• OGD Architecture
• Hardware Selection and Revision
  • Hardware Clarifications
  • Chip Change
    • Using more than one chip
    • Asic Selection
    • PCI roadmap
    • DVI and ODG1
• Who is Who..
  • Mini FAQ for the Open Graphics Mailing list.

Over 270 Posts covered in this Newsletter

ANNOUNCEMENTS

OGD1 Revision

OGD1 Main FPGA change: Timothy announced: Howard, Andy, and I did our due dilligence on the OGD1 design to make sure that it was really going to meet our needs. To test that we would be able to fit an OGA-compliant design into the ECP2-50. (...) Our determination is that the 3S4000 is the only chip available within the next 6 months that will meet our needs, so we're switching
Some results of this change:
About two weeks setback in OGD1 PCB design schedule
10-bit triple-DAC fully connected
Some extra user I/O signals
Potentially wider local bus between the two FPGAs
More versatility on the signal types for the user I/Os
Increase in OGD1 parts cost
Potential to populate 3S5000, if necessary
Some challenges with having to use ISE 6.3i to syntesize for the 3S4000.

Progress and developments

OGP and Traversal

Documentation logs

Jack clarified regarding OGP and Traversal Documentation: OGP documents should describe the graphics architecture, but not a particular implementation of it. They would cover register layouts, command sets, technical rationale, application notes, model driver code, and the like. Anything related specifically to OGD1, such as the FPGA pinout list, should be a Traversal document, with a drawing number generated from the OGD1 root number. The sooner we have an approved standard for the Traversal drawing number system, the sooner we can identify these revision-controlled documents. Timothy quickly reviewed the numbering system and then gave an initial go ahead

Artwork by Artists

We have hosted Lourens logo as well to help viewers compare between the two and a number of comments were made. Join in and add your view. Luc pointed out that one of his logo designs was made for OGA, and his TT logo for Traversal was designed with the requirements for printing on an IC package in mind. As Rene noted: It makes minimal demands on the resolution of the printing process, so it will fit in a small space and still be recognizable

We need a lot of artwork for our project, both for printing logo's on the circuit boards as well as in advertising, manuals and packaging so any contributions are welcome. You can either post to the list or contact us privately via email.
http://wiki.duskglow.com/tiki-index.php?page=OGP+Artwork.

Verilog Tutorials

The tutorials continued a pace with the fourth lesson posted to the wiki. These have seen benefits with Hamish surprising the list with Bresenhams line drawing algorithm. The experts reviewed his work and then helped with the implementation. If you want to learn, please join in. The lessons assume you have a cursory knowledge of C and helps you to progress to Verilog. You can check them out on the front page for OGP.

Web Presence

We have noticed a website name that has some significance to us.
opengraphicsproject.org is not held by OGP or Traversal. If you know who owns this one, or can find out we would be interested. Is this from someone supporting OGP? We would appreciate finding out. If you want to contact us privately, feel free to drop Timothy, or JB a line.

Framebuffer design

John surprised the list by posting his work on a frame buffer: I've finally completed a quick-n-dirty EPP driven framebuffer. The full design, Linux driver code, design documents, and some misc pictures are posted at www.johnculp.net. I am placing everything in the public domain. This design takes up about 42% of a Xilinx spartan XC2S200E FPGA and is currently driven by a 50Mhz clock. I don't think reaching 100Mhz is out of the question, but this was not a design goal.

Programming the ODG1 graphics development board

With the change to the Xilinx chip a few wondered how to program the new hardware. Timothy: physically programming the device is going to be a pain, if you have to use the external cable. But our goal is to make it programmable via PCI, though the XP10. For this, we'll need to develop our own programming tool anyhow.

Timothy: the only web pack that supports the 3S4000 is 6.3i. Benjamin tested it and confirmed he was able to set up a new project for an 3S4000. He then said: The application notes on the Xilinx website seem to be a good point to get started, too. (e.g XAPP473 - Using the ISE Design Tools for Spartan-3 FPGAs - http://direct.xilinx.com/bvdocs/appnotes/xapp473.pdf )

Obtaining the 6.3i software
You have to log in but you can download it for Windows here: http://www.xilinx.com/webpack/classics/wpclassic/index.htm. You apparently also need the service pack.
Some notes about running on an old version of Wine were found and a link added to our wiki here
http://wiki.duskglow.com/tiki-index.php?PHPSESSID=c14c1a527991ab4760fc8626f3b5aa78&page=Development_Tools
Unfortunately it doesn't appear to run in the latest Wine and if you are a coder, and wish to investigate this, you could be a real help to future developers of ODG1. Here is the Wine application Database entry http://appdb.winehq.org/appview.php?versionId=2501

Frame rates and Video Capture

A post to the list raised the query: can the OGC framerate / vertical refresh be finetuned by software without causing glitches in the output?
Timothy: there's going to be some latency between data getting into the framebuffer and it getting scanned out of our chip. Our video output is going to be behind the output. It might be a few scanlines, a frame, or multiple frames, depending on any software overhead. Unless we take some sort of direct video input feed right into our user I/O connector, there simply is no exact synchronization with another video feed. Even then, we're going to at least be some number of pixels behind, simply due to clocking the data into our chip, mixing it with our own video data, and then feeding it back out again. In this case, we do have to be pixel-exact, but I think it may be asking too much for us to provide this feature right now. I think the best we should ask for right now is for the captured video to get written to our video memory. Either via DMA or via a direct connect. No one would ever notice if we were dozens of scanlines behind. Given that, a drift of hundreds of clocks between input and output video (which we compensate for in blanking) is not going to be a problem.

Then the discussion turned to Video Capture and wondering about end user card called OGA Timothy clarified: OGP is trying to be realistic and not design products we can't build. We have decided not to develop video capture technology yet so that we can get much more important things done first. If you want de-interlacing, it'll be a function of whatever video capture card you decide to buy.

Drivers

After some discussion about the X Server, some speculated about whether using two chips would make for better graphics. Timothy: With the exception of some pathological things (like Poly Point and hitting against some of mi's O(n*n) or worse span rasterizing code), most things can be (...) shipped to the GPU while the X server sleeps. The reason for the high CPU usage is drivers that try to render mostly using PIO. (...) With properly-written drivers, this competition won't happen. (...) you shouldn't throw hardware at something as a solution to bad software.
Later he also pointed out the balance act between drivers and Hardware: The rule of thumb with hardware is to do as much as you can in software. That doesn't mean to overload the CPU, but if you cut you die area in half by offloading some things to software, costing you only a few % CPU load, that's a HUGE win. A lot of what you do in the X server doesn't require much CPU time. For instance, telling a GPU to draw a filled rectangle doesn't require much computation for the CPU. (...) for OGA.(the first in the planned OGP end user cards) We have only the fragment pipeline. We are relying the host to do the vertex processing in order that we could make a cost-effective design. We must rely on the host CPU.

Future designs

Dieter and several others discussed about video over Ethernet, but didnt expect to be able to convince anyone of that. Timothy expressed some interest but noted OGP's priority: I just have to get the more common case done first.

Commercial Graphic Chip Designs

One poster noticed A datasheet for a graphics chip and said I know this is very old technology, but maybe someone wants to take a look?

Howard: Before we started down the route of making our own chip, Traversal spent a good few weeks looking for an off-the-shelf solution with a fully documented register set. Up until recently, there were chips available from Trident, but these dissapeared when Trident became part of XGI. We've looked at:-

• Nvidia
• ATI
• Matrox
• 3D labs
• XGI
• S3
• AMD
• Intel
• Silicon Motion

If anybody knows a stone that we might not have looked under, please post it here.

A post to the list asked: would it be possible to use an existing chip for part of the design? A simple Northbridge for memory control, for example. Or does someone still make memory controller chips?
Timothy: We looked into using a northbridge chip as a graphics chip. It seems that we can't do it because northbridge chips are not designed to talk to other northbridge chips. More precisely, they're designed not just to be bus masters but a CENTRAL RESOURCE, and you can have only one of those.
Richard noted: In Linuxbios we get a lot of requests for support of newer Intel chipsets. The problem is that Intel will not release all the right docs for things like properly turning on the RAM. (...) The response is that they just aren't interested in having Linuxbios work with thier newer chipsets. So even though you have been able to look at the chipset docs I'm very doubtful that you would ever be able to actually release this GPL using an Intel chipset. AMD chips however _do_ have the necessary docs available. So you might actually be able to make something with an AMD northbridge.
Timothy pointed out that it was technically feasable : Its not that its not possible, its just not an attractive solution.

OGD Architecture

Hardware Selection and Revision

Hardware Clarifications

Chip Change

A number of questions were raised about using the new Xilinx chip.
How would this affect the price of ODG1?

• Timothy The actual price difference depends on volume. Suffice it to say that I think we can still hit our original developer price point and be okay.

Why couldn't we do the ecp2-70 now? (Rather than switch to the Xilinx).

• Timothy ECP2-70 is Not available until Q1 or Q2 2007.

Are the Spartan-3's a lot better than Virtex-2's, or just a lot cheaper?
Howard: The Spartan 3's are cheaper. Any of the Virtex 4 chips with the amount of logic we need are unfeasibly costly. XC4VLX60 = $600 (a bit smaller than Spartan 3 4000) XC4VLX200 = $8000

Using more than one chip

Several wondered about using two smaller FPGA instead on the large Xilinx chip.
Timothy: In the graphics case, the most heavily drawn-to part of memory is the same as the most heavily-scanned-for-video. So we can't separate video out. We might be able to do some things like put textures and z buffer in one place and video buffer in another. The problem is that with X11, pixmaps are used so heavily that they are accessed as much as the video buffer.

Asic Selection

Howard our Hardware expert was asked about the planned asic for the graphics card that Traversal will offer: How much logic is the TRV10 going to need? Could it be implemented with an older CMOS or SOI process that doesn't have such prohibitive up-front costs
Howard: It probably will fit on a large 250nm die. However, 250nm is quite slow, power hungry and there are end-of-life issues. A good compromise would be in the 130nm to 180nm range, where mask sets are in the order of a few hundred thousand dollars.

PCI roadmap

Dieter speculated: My crystal ball says AGP will go away very soon. My crystal ball says PCI will go away, but slower than AGP. The problem will be too few slots per board. (Even worse than now.) My crystal ball says PCIe will be good for several years.

Timothy: Thats why we chose PCI-X. That's because PCI will be around a while, and we can slap a PCIX-PCIe bridge chip on a board and get PCIe.

A poster queried about supporting a PCI 64 bit slot but then noted after some research: Upon further investigation, it looks like PCI-X uses the same connector as PCI 64 bit, aka PCI wide.

DVI and ODG1

Timothy clarified The way OGD1 is hooked up:
Head 1 is connected to 330MHz analog and dual-link DVI.
Head 2 is connected to TV/s-video and dual-link DVI. There are only two video controllers, and lots of pins are shared.

Who is Who..

Attila Kinali manages the moderation requests for our mailing lists

Mini FAQ for the Open Graphics Mailing list.

Where is the list?
Gmane.comp.graphics.opengraphics
How can I get it?
Using your favourite 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 favourite 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.

Updated Sept 9 2006 to clarify nature of Artwork is for logo and packaging.