Back to Open Graphics
Newsletter Archives

Mar 1st 2007 Open Graphics Project Newsletter

Over 363 Posts covered in this Newsletter

ANNOUNCEMENTS

Linux Tag

A. Kinali will be representing OGP at Linux Tag from 30th May until 2nd June together with the folks from MPlayer and FFmpeg. L. Veens will also be present for some of the time.

Video Controller Released:

This is an interesting section of our design that allows us to ignore many issues of generating a frame.
Here’s the La TeX source*:
https://svn.suug.ch/repos/opengraphics/main/trunk/docs/vid_ctl.tex
Here the link to the pdf:
http://www.mwyann.info/opengraphics/vid_ctl.pdf


interesting List Quotes:
60Hz is usually fine for LCDs, since they don’t have a flicker problem.

Progress and developments

Board Testing Progress

Timothy confirmed

Howard believes he’s identified all of the bugs in OGD1 except for anything possibly in (analog video and TV). Our PCB guy is working on the changes. As soon as analog video is tested, we’re going to start taking orders. ... The big challenge is ...the TV chip. The bug count ..so far, but it’s small, and the guy who is implementing the fixes is up to the minute on them, so that will constitute a zero delay when we finally decide to go to production. The fact that we have uncovered a number of bugs is encouraging us to be as thorough as possible in our tests.

He asked the list for assistance with testing the TV chip.

Rodolphe

Aren’t you using the same chip as the GP2X game console (a Conexant CX25874)?

Apparently, some fan programmer of this game console claimed to drive its TV chip directly for NTSC TV-out back in november (see: http://www.gp32x.com/board/index.php?showtopic=33218 ).

Timothy reported back.

It turns out that Connexant has a DOS program that will generate register settings for any TV mode you want. We hope that does the trick.

Source Code

Martin queried the list about where he could read the source code for the Open Graphics Project. Because this has been raised a few times here are the links again:

https://svn.suug.ch/repos/opengraphics/main/trunk/
http://www.opengraphics.org

PCI Compression

Chris noted our recent thoughts on PCI bus monitoring and reported that he had seen something relevant at a conference:

It seems that the experiences from snooping the AMBA bus could be quite useful when applied to a PCI bus. Of note, they gave brief mention to compression schemes (omit sequential addresses, store data differentials, encode status bits) which they claimed allowed an average compression rate of 96%.

Registers
Simon queried:

Would I be cluttering the list if I started asking questions about the RTL code?

Timothy:

This is a GOOD place to ask these sorts of questions.

Simon replied

Right now, I’m wondering why the filename of vid_ctl/RAMB16_S36_36.v doesn’t match the module name declared within.

Timothy welcomed the check:

This one may ..be a typo.

Congratulations to Simon. This my be the first bug found by the list. More eyes are welcome.

Work for volunteers

A poster queried:

I’d appreciate it if someone who is more in the loop than I am could give me something to work on

Timothy:

Something we’re severely lacking in is a set of extensive test benches for our various logic modules and a policy for creating and managing those test benches....(and) We need more documentation. :)

Many people don’t seem to think of test engineering as particularly glorious. But I disagree. At Tech Source, the job of the test engineers is to break our stuff. The development engineers pride themselves in doing a good job, so we don’t like to be proven wrong. But the culture there is one where we’re impressed when the test engineer finds something wrong, rather than having our pride hurt. I think this is a good philosophy, and I’d like the OGP to emulate it. Test benches should, in fact, be harder to write and bulkier than the logic being tested. If not, then you’re likely not considering enough corner cases. Also, the test should be written by someone other than the engineer who designed the thing being tested. ...The OGP should strive to approach that standard so that end users can really rely on our hardware.

Probably the most critical thing to test, actually, is the PCI target. If you have access to a specification or the Shanley book (*), then you can probably make sense of it yourself. Otherwise, you can work with me via email. I’ve emailed to a number of people on the list a set of explanations and links and stuff, so maybe I can get one of them forward them to you. But don’t choose PCI unless you’re up for a major challenge. Otherwise, yes, video is good. Fifos are simple enough that they shouldn’t require extensive testing. Yes, they’re fundamental, but they’re small enough that we can apply more mathematical sorts of proofs to them rather than test suites. Another thing that has tests and which could get more tests is the memory controller. ...Just take some small pieces at a time and work your way up. There’s a lot to do, but if you can help with a small piece of it, that will help others help more, etc. Snow-ball effect. We just need to choose some key but managable things to do.

(*) PCI System Architecture, Mindshare Inc. on Amazon

Future developments

Vista

One post asked if we have any chance of making a Vista capable video board? ...The requirements are quite specific: Support for DirectX 9 graphics with:
• WDDM Driver
• 128 MB of graphics memory (minimum)
• Pixel Shader 2.0 in hardware
• 32 bits per pixel

Luc

Turn the question on it’s head. Maybe one should put the problem differently:

* when can we meet the Vista’s requirements?

*meanwhile, where can we still make business ?

Put like that, it seems that everywhere openGL is supported, OGP has a chance to place its products. ...(I let aside the embedded market since you’re speaking about PC)

Simon:

The only fail-safe solution for free software friendly hardware is to get a group of people that honestly want to support free software (that’s us) and gain the expertise needed to become self-sustaining.

High Definition and Video Displays

A news report posted to the list suggested that some High Definition displays would refuse to display unencrypted video. As Richard said:

The article states: The Mitsubishi LT-46231 DVI input starts looking for HDCP at resolutions higher than 1280×720 pixels.

Richard checked the HDCP (a digital rights restriction technology) license:

The HDCP license rules require that digital output of DRM restricted content higher than certain resolutions be encrypted with HDCP.

Several pointed out concerns with the concept and technology. As one poster noted:

The really odd thing is that its weaknesses aren’t even that relevant since all a pirate needs is a chip ... which comes with the keys already installed.

Dieter:

There is no reason for a display to not accept a HDCP-less signal. There may be displays out there that behave this way, but it wouldn’t be the first time a bug or misfeature made it out the door. Yes, there are displays that should be able to accept 1080p but don’t. And misc. other misfeature's. Someone dropped the ball.... Shop carefully

While pirates with funds may not find this a problem, for the average user, it is looking more likely that without the efforts of those like OGP who seek open and free (as in freedom) hardware you may lose some of your existing freedoms with your personal computer.
Raphael pointed out that our Video Card may be only the start.

if this turns out to be correct, then we may have to start the OpenLCDController project.

Timothy explained that there were other possible ways around the problem:

One thing I should note is that it’s always possible for Traversal to add a small piece of logic to our design that we all agree that we can’t legally open. That means anyone else who wishes to implement our design will have to design their own replacement piece of logic. So, it’s not great, but we can do it. In the GPL’d version, what you’ll get is an empty stub module in place of whatever logic we would otherwise include in order to implement HDCP. .... for the safety of the project. We’re going to be very careful

He then added that even this may not be necessary:

The only scenario under which OGC won’t be able to display HD content, is if all monitor manufacturers design their monitors not to accept unencrypted HD content.

Future Products

One Poster suggested a SATA controller which received a few suggestions. However Timothy both encouraged and cautioned:

That isn’t to say that the idea isn’t interesting, but I have two problems with it: (1) we need someone to take charge of that but not detract from the path we’re already on, and (2) we shouldn’t unnecessarily compete with other vendors like 3ware who do a good job of supporting Free Software, which we want to encourage.

James agreed:

Yes, we shouldn’t directly compete.

Open or Free (as in Freedom) Hardware

The TAPR Open hardware License was noted by Johannes : http://www.tapr.org/OHL It is good that others are looking and thinking about this important issue.

2D Drivers

Nicolas:

If i want to use ”“pure” 2D. What is the fastest choice ? Xlib gives some very impressive numbers , but it’s quite old. Opengl is fast but a good 3D card are needed. I don’t know the speed of SDL. It’s look like the ”“default” choice. Beside that i know that most of card and old 3D card have some means to draw fast 2D primitive without the use of the main CPU. Does a lib that use this exist ?

Raphael:

current video cards don’t have 2D acceleration any more. They do 2D acceleration out of 3D primitives...

Nicolas queried further:

most cards and old 3D card have some means to draw fast 2D primitive without the use of the main CPU. Does a lib that use this exist ?

Loris:

Sure. That’s what a recent X11 server does with certain known hardware, by accelerating Xlib functions (and thus other higher level drawing APIs like Cairo) by the means of XAA or, where possible, EXA (1) (2). Check these if you’ve got time:

1. http://cairographics.org/
2. http://lists.freedesktop.org/archives/xorg/2005-June/008356.html
3. http://wiki.x.org/wiki/ExaStatus

Look up Cairo and EXA on Wikipedia for a quick and simple overview.

SVN and Documentation

Attila:

may i ask you not to check in the pdf’s? They can be easily generated from the latex source. And checking in a new pdf every time something is changed in will cost a lot of disk space on the AVN server.

This raised a discussion about SVN, pdfs and Latex Timothy:

I’m sure most people don’t have the latex tools.

Attila:

I rather recommend a system that does build the pdfs automagicaly from the svn (repository) instead of letting the developers handle it. I used one of my tex-makefile templates and committed it instead. I hope you are OK with it :) The PDF’s are also gone from the repository, which means we should think about how to put them on to a web server. Easiest would be to run a cron job on the web server that rebuilds the pdfs once a day. But this approach needs a complete latex environment on the web server. A more complicated would be to generate them on a different machine and upload them.

Vesa Documentation
Russell S queried where (can) the Vesa standards can be downloaded for free?:

Timothy:

Traversal will have to become a member, so we’ll get access to all of that... Also, I’m sure you can find them in university libraries.

Peter:

http://www.vesa.org

As you can see, there are many VESA standards: http://en.wikipedia.org/wiki/VESA The one you are probably interested in is: http://en.wikipedia.org/wiki/VESA_BIOS_Extensions If you go to this page: http://www.vesa.org/Standards/summaries.htm you can click on the link in “Please click for a list of standards that are available in PDF format for immediate download”... What you want there is probably vbe3.pdf.

Russell S reported back:

I found a standard for 2D acceleration: http://www.vesa.org/public/VBE/VBE-AF07.pdf

OGD Architecture

What is the maximum resolution of OGD1?
Timothy:

The 2 dual-link DVI-I can reach a theoretical limit of 2048x1536 at 60 Hz each, digital or analog).

After querying this he replied:

People have asked why we have given more than one number as our "maximum resolution". The answer is because there isn't a simple limitation that we can point at. In fact, that dot clock (max 330MHz) is our only real limiting factor. However, to compute the maximum resolution requires that we know other information, particularly blanking intervals. Taking into account what we believe to be the minimum allowable blanking intervals for DVI monitors, we estimate that we have a maximum resolution of something on the order of 2700x2048 at 60Hz. Unfortunately, you can't get an LCD panel approaching that resolution within the typical consumer's budget for a luxury car. As such, we have decided to report 2560x1600 as our maximum resolultion, because that is the resolution of the Apple cinema display.

Simon:

60Hz is usually fine for LCDs, since they don’t have a flicker problem.

YUV and RGB

A post to the list queried about bandwidth savings with YUV

Attila:

Actually it’s not YUV that saves us bandwidth, but sub sampling. YUV just enables us to do sub sampling without much loss. ... YUV conversion ...is standard... a multitude of standards :-) ... There will be a conversion to RGB at some point which can be easily pipelined and thus does not impose any speed loss. The real problem with YUV comes from the sub sampling imposed. I.E for the up sampling we need to perform some form of interpolation and filtering on the image in either only vertical direction (4:2:2 -> 4:4:4) or both horizontal and vertical (4:2:0 -> 4:4:4). And also the UV samples may be half a pixel off from the Y samples, depending on the used video codec.

Timothy:

we see no reason to have an RGB->YUV conversion. .... So, basically, you give the GPU YUV numbers and have it work on that, and then at one point, just convert it over to RGB. The GPU doesn’t know or care about the difference.... Also, I expect that in some cases, the GPU may do the conversion slower than the CPU could (multiple passes and memory references), but what really matters is that we get it done in the time much less than one video output frame. We can eliminate the CPU overhead, and use DMA to transport the YUV data, and just let the GPU take its time to do the job.

Texture Compression

Timothy:

Texture compression and z-buffer compression are things I want to stay away from for a while, until we can be sure to come up with something that isn’t covered by a patent. For the most part, anything we’ve decided to use so far is either patent-free or unpatentable, and while the patent system is crap for overturning crap patents, we at least have the moral high-ground. There just aren’t that many ways of doing 3D graphics, and most of what we have is basically derived from first-principles and then tweaked to make it OpenGL compatible. On the other hand, finding a way to compress textures and z-buffers efficiently has room for some cleverness. I doubt that the whole concept of compressing them is patented; just the WAY they are compressed. So we just have to come up with a different way to do it. Also, in the future, I plan to pull an Intel and try to throw caching at it. For most rendering, caching is useless (and fast streaming is what we need to optimize), but for textures, there is some locality of reference. And we can also look ahead, fetch things out of order, and all sorts of cool stuff.

Phillip

Since the discussion on sale2x touched the topic of texture compression and Timothy stated that he wants to stay away from it for now because of patents I’d like to give an overview about the interesting texture compression algorithms. I think texture compression is important since it helps with the bottleneck of memory throughput.

He then gave an overview of some patented and royalty free options.

3D GPU size

A post queried whether we can fit a full 3D GPU in our large FPGA:

Timothy pointed out the experience behind the design:

I think it’ll be a tight squeeze, but I have evidence to suggest that a simple, fixed-function 3D GPU will fit into that FPGA. Your conception of how the GPU would be implemented may be different from mine. Also, I’m good at making logic fast, while Howard is good at making logic small. I think we can manage it. ... Traversal plans to have a single OGD1 outfitted with an xc3s5000

Hardware MPEG

AAttila:

OGD1 wont have enough real estate to implement a full MPEG2 decoder

For some on the list this was a surprise.
Attila explained:

The problem is that we work on a (relatively) small FPGA (for MPEG decoding). And decoding MPEG is something that does not neatly fit into hardware. To be done efficiently you need software too, which in turn requires a CPU. But we don’t have enough space to implement a (Graphics Processor) and a CPU while still maintaining a manageable system (systems where two units can access the same resources are magnitudes more complicated to design and implement).

Some wondered if MPEG would require some sort of hardware assist.
Timothy:

I think people figured out that on not too old hardware, they could do the full decoding in software with no problems. On the other hand, we will be providing YUV to RGB conversion, which will lighten the burden a bit.

Attila:

MPEG1/2/4 is more than fast enough in software. The problem is the I/O involved and the miss design of most video player that do not use DMA. h.264 is another matter and yes, there you can get into the situation that your CPU is not fast enough when all features are enabled. ...If you really think about implementing a h.264 decoder in hardware, then you need to put another spartan3 onto the board as there wont be much space left for anything else.

Andre tested High Definition Video with software decoding on his computer and reported that it was fine. However problems would be expected for software only decoding if there was the additional overhead of cryptography present:

I tested the HD version of elephant dream on my pc. It work well with only software decoding. The cpu usage was around 50% with low of 40% and max of approximately 80%. A normal mpeg on my computer use about 25% at 720x480 resolution. The pc spec are the following athlon 2GHz, geforce2mx. The video was played using mplayer on Gentoo with the nvidia binary driver. As I can see it playing HD video on a modern computer shouldn’t be a problem except if there is cryptography present in the stream.

Timothy brought the topic back:

To avoid creeping feature's, we would have to address this either via future revisions or entirely unrelated chips.

PCIe

Some wondered about the bus speed of OGC.
Timothy

(It) Depends on how many PCIe channels we design into it. There will be at least one (about as fast as PCI-32 66MHz).

This raised eyebrows as OGC is expected to be PCI

Timothy explained

A tentative plan has been proposed, and a PCI-PCIe bridge chip has been selected. Some potential customers have also expressed interest in PCIe. Money is the primary limiting factor here. That being said, everything to do with PCIe remains totally unofficial at this point.... If we’re putting a bridge chip between our chip and the PCIe slot, we can run the PCI side at whatever clock rate we want to.

So remember, you didnt hear it here<grin>

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, but the list is moderated. Suggestions for this newsletter are welcome and are made through the mailing lists.

Update Tue Apr 3
PDF link correction
PDF files can be easily generated from Latex files:

• Windows
  • http://en.wikipedia.org/wiki/TeXnicCenter
• Linux
  • http://en.wikibooks.org/wiki/Latex
  • downloading and typing pdflatex vid_ctl.tex on the command line should generate a PDF file.