Back to Open Graphics
Newsletter Archives

Nov 1st 2006 Open Graphics Project Newsletter

Over 235 Posts covered in this Newsletter

ANNOUNCEMENTS

OGD1

we now have the prototypes for the OGD1 board sans RAM chips. Testing is ongoing. Timothy:

At the moment, the most critical thing for me is to test the OGD1 prototype board and make sure it's bug-free. We're going to use (the test pattern software) next week, after we have checked out the XP10, and I think we're going to try to do memory next.

Drivers

Timothy

With regard to software, I will often offer code and make suggestions about how I think things should be done. But as for assignment of software tasks, who will do it, and other details of that nature, I personally would prefer to take a relatively hands-off approach. In part because I want to focus on hardware, part out of desire to not interfere, and part laziness. As such, the only suggestion I feel I can make is for other people with experience in this area to speak up, make suggestions and help out... (...) we could use more people ... (with DRI, Mesa, and BIOS)

Several have offered help OGP drivers – We need a few more volunteers for drivers (such as MESA), or you could help our current volunteers. Offers are made via the Mailing List.
Nicholas:

I would be interested in (..) the fbcon driver. (...) I figure that I need to learn this stuff anyway, and need to get ODG1 anyway, so saving about $600+ never hurts.

Jesper Juhl

I'd want to help out write the Linux kernel driver so we can get a fully supported kernel driver for the card for my favourite platform

Some interesting List Quotes:
Timothy

This is why working with the community is so much fun. (Other Graphic card companies) minimise development costs by avoiding development. We can minimise development costs by sharing with the community and letting them share with us the innovations that we come up with together.

Terry:

OGP graphics card has the potential to put an open hardware product in people's hands, and give them real benefits — just like the GNU utilities did in the late 1980s.

Progress and developments

Many were startled to hear of the NVIDIA Binary Driver exploit. There were a wide variety of opinions made. Here are a few random ones.

Lance

At the risk of sounding naive, I don't think there's anything negative or cynical about speaking out against a company that forces you to let people run arbitrary code as root on your computer.

Vinicius

Before having that vulnerability known, it was all about "Binary blobs could be insecure", but now it's a proven fact

Why the heavy weight graphic card designers will never release specifications for their chips

Timothy

ATI and nVidia see their newer high-end cards as money-makers. Therefore, they will not give away the specs.

Raphael

they didn't need to write docs, because the driver was written internally. then when card n is superseded by card n+1, it makes no economical sense to spend money on writing docs for it, because that's not what they are going to sell next.

Work for volunteers

Timothy posted a couple of jobs that needs caretakers

we need someone to police the licensing headers for all source files. If someone volunteers for that position, we should just give them proper access. (...) Another job for the repository is to have someone actively work to maintain a sensible hierarchy. They would be responsible for classifying things, creating a sensible directory structure, and moving things around in the tree. Obviously, one person could do multiple jobs if they like.

Also a Poster asked

Is there anything else a learner like myself could work on? i was thinking about looking a bit more on how the interfacing with the dvi transmitters work and see if I could write some module for that. But I guess that without a development board it's better to work on something internal to the fpga.

Timothy

How about simulating a video device? (For one project) we developed simulation code that watched video signals coming out of the design and pretended to be a monitor. Each frame of raster scan got output to an ASCII-format PPM file (the kind with "P3" as the first line) that we could look at later with an image viewer.(...)

There are actually a number of things we could use simulation models for. The one for SPI, I think, was okay, but it could be expanded. We need one for DDR SDRAM; the one from Samsung won't work with Icarus Verilog, so we either fix it, or we write our own (that does NOT have to be as sophisticated). Also, if you work on something related to OGD1, then that will really help, but really, you can work on other things, and I'll be glad to help with those too.

Simon had a go and also Nicolas posted an initial effort and promised more. Surprising us all, it seemed that in less than an hour he posted his second version:

This one should draw correctly, and it turns out gimp directly supports PPM! Next step is to integrate gen_head0_signals into test_head0, so that I can actually use the DDR FF and [r,g,b][0,1]. After that, another rewrite of vidsim and it should all work reasonably. Once I get a single frame displayed correctly, I'll do the string magic to get each frame into a separate file. I also noticed some glitching at the end of the image on lines 599 & 600 which I need to fix.

Timothy had the enviable position of selecting the best from both designs:

Simon's video state machine is simple, straight-forward, and readable. (...) However, what Nicholas did do for us that was excellent is produce a video capture block. This module acts like a monitor, watching video signals, and spits the video frame out to a PPM file.

Nicolas

I will try to get Simon's version of the head0_video_out module to work with my video monitor,(...) Also, a point of caution: the VCD file is ballooning in size. It is now approx. 450MB. I couldn't open it in GTKWave to analyse waveforms because while it did load, the (User Interface) was so slow that it still hadn't redrawn the screen after 30 min! I resorted to looking at the scanimage.ppm file instead.

Timothy

I would like for you and Simon to converge to a single project. We need

# a test bench

# a monitor simulator, and

# a synthesizable test-pattern generator.

You two can split things up, but feel free to add to each other's work.

A few days later Simon posted:

It is committed to rtl/test_video_out now.

If you want to help out – just ask or jump in. The water is warm.

Bølge

The GTK Wave alternative

Nicolas' work also helped with the development of our VCD viewer that Peter has being working on.
Nicolas commented on one of his earlier versions:

gtkwave testDVI.vcd now complains about the file being 172 MB and it might not load, but it works on this end.

Peter:

188MB here — and bølge's memory footprint when I load it grows to at least 2G! (and then I killed it so I don't know what the limit is). This is a fantastic test for my VCD parser and data structures. I already knew I would need something better than what I currently do (and I pretty much know how to improve it).

And he added

PS: the zooming/drawing still needs some work before I release v0.1.

He later posted:

I got that down to 400 MB last night and since I have 1G RAM it worked fine without thrashing. (...) It should be possible to view your new, bigger VCD file comfortably on a 256 MB RAM machine. But that's for v0.2, I'm afraid. (...)

For the curious:

http://vax64.dk/bølge/

http://vax64.dk/b%c3%b8lge/

The tarball won't be up until the 0.1 release but the darcs repository works fine.

PCI Simulation developments

Atilla:

Unfortunately, the result is that we may not be able to use bochs for a system level simulation including the operating system. Bochs uses a too abstract model of the PCI bus (basically just read and write of arbitrary size data), so that we would need to rewrite quite some bit of bochs to extract those signals (or add a huge layer between bochs and our simulation). (...) Currently i suggest either to stick with a pure functional verification in verilog and driver development using OGD1 or to write a low level PC simulator in a HDL.

Nicolas

Be careful with system wide simulation. Bochs or qemu are near real speed software. around ~50% of the PC speed, which is a real performance. A VHDL simulation are often 100 000 times slower than reality. If you connect bochs to the OGD HDL code, you could wait hours before the start-up code ends. If you want to write drivers, i think that we should use the software model with the simplify PCI model of bochs. Then you only need one more thin software layer for the real code to handle on real hardware. So you could write 98% of the drivers and test it at near full speed. Then you could extract the interaction with the pci bus model and use it as test vector for testing the HDL code. The software model are then used as "golden model".

Petter

I had a quick look at qemu. They have an interface where you register memory regions, and then implement read/write operations for those regions (see e.g. cirrus_init_common in hw/cirrus_vga.c). (...) The qemu code is quite readable and the emulator is easy to use, but they don't have a plug-in interface which I think Bochs has, meaning we would have to modify qemu itself. I kind of expected we would have to write the PCI bus simulator ourselves, since these emulators don't need to interface with real hardware. (...) Nicolas' concern about the speed may be an issue. If we can launch the emulator in the evening and check on it the next day, I think it's still useful (...)

Rodolphe

Why can't you do without such a PCI bus simulator? (The board simulator model needs to interface with it?) It's not for the software only simulator I guess? Purely from the device driver software development point of view, we can't stick to OS-provided PCI API? (From what I know, all device programming is done via MMIO nowadays from the drivers, only the very early initialisation part uses another way via a few PCI config regs to set up the MMIO spaces.)

Atilla

Most hardware these days use memory addresses as an abstraction layer. But using only the OS provided PCI interface does not suffice in writing a sufficient test for the card. It would be possible to write a driver if we had a c model this way, but then we would need to test everything again against the real hw.

Petter

I was thinking about a quite generic PCI IO-space coupled with a Verilog-simulation, and that could be useful to other PCI-based hardware projects, as well. The OGP specific part would be the vanilla OGA driver loaded by the OS.

Code Care

Lourens

If you copy-paste code that someone else wrote, that other person still has copyright, and the GPL does require that you place a copyright notice listing that person as a copyright holder, along with the note that it is GPL-ed.

OGP and Traversal

In reply to a question about investing in OGP and Traversal Timothy explained one potential area of development:

Business partners, for instance. Rather than investing, some company could fund, for instance, ASIC development. They then have rights to resell the chip. We buy chips from them and resell them in our products.

Building Exposure for OGP

One poster wondered if we might benefit from coming more vocal and activist about OGP and Open Hardware.
Terry:

(..) you need a sustaining impression of "competent progress".(...) at this point your interest is keeping developers interested and piquing the curiosity of potential early-adopters. The key here is to maintain the image of competence and confidence. (...) (...) Awareness of OGP will grow naturally in time. (...) You're not trying to be a "smash hit", you're trying to be "reliable" and "capable" and other good solid words that give people confidence that you will get to where you are trying to be. Meanwhile, you should prepare materials for a "big launch" when you do release a product. You should do some "launch" publicity even for the OGD1, even though the actual market is small. This serves three purposes:

1) Making real hardware proves you can

2) It will attract FPGA developers

3) It provides a teaser for a later OGA1 launch

Patrick

To back up the philosophies claim, we need a piece of hardware. (...) As we move forward and make milestones or new projects use the OGD1 for other things, we do not want to miss the opportunity to point out the technical benefits of having access to open hardware, as well as the limitations that are imposed by commercial closed hardware when compared to our approach.

Terry:

(initial OGP graphic cards) will not be competitive in features, price, or performance with the proprietary competition (i.e. ATI and nVidia). Their primary benefit is to people who are already using Linux or BSD. These are much more sophisticated customers who *will* be swayed by both the ideology and the quality (both present and future) of the product. (...) For that group of consumers, it is very important that OGP remain firmly a "white hat": solid supporters of the ideology that is encouraging them to spend a little extra on a product they believe will support them in the future.

Lance:

we should make our views visible. We have a very legitimate grievance and we are trying to reach everyone who has it too. So yes, OHF should be the body for our philosophical and (economical)political standard. OGP should be considered as another action that we are taking:

1. Speaking out (OHF)

2. Leading by example (OGP)

3. Maintaining a meeting place for like-minded people to act and participate in whichever way they prefer (both).

Writing Drivers

Ye An asked where to find the software model.
Timothy

Here's the old model: https://svn.suug.ch/repos/opengraphics/main/trunk/model/ And here's a clean-room of it: https://svn.suug.ch/repos/opengraphics/main/trunk/new_model/

Atilla

the PCI stuff (for drivers) is relatively easy, you just tell the kernel what you are looking for and it does everything for you. If you need an example for this, have a look at mga_vid ( http://attila.kinali.ch/mga/ ), there mga_vid_find_card() searches for the cards and cards_init() initialises the data structures. (please be aware that the code is very ugly)

Rudolf asked if it would be feasible to start writing the kernel driver using the simulator? I'm thinking to user-mode Linux, or maybe a full emulator like qemu or Bochs. (BTW, in this case, maybe the simulator itself may be viewed as something useful by the emulator's developers...)

Timothy

The drawing engine needs to be broken down more carefully into a pipeline. Andy's done a good job already with his "new model". I'll eventually get around to it, but if someone wants to get a jump on it, go ahead. Note that most of what will be in the kernel driver won't use the drawing engine much. That's mostly initialisation. And we haven't even figured out where things like the video controller and such are going to "live" in the address space.

Getting Started
Patrick

(...) I've seen a number of people at various times note that the register interface is not well defined and that some of the functional interface is still up in the air as to how it will work. That shouldn't stop people from starting on the drivers.

With proper abstraction in the driver, it should be possible to write a pretty complete driver that could use any number of transport methods to talk to the back end display device, be it the software model or a hardware device. The driver should have a high level section and a hardware interface section. The high level code does all the setup and handling of application calls including any software emulation needed. For things that are passed off to the hardware for acceleration, a call is then made to the interface code, which like you noted above, provides a very simple interface. Registers are easily abstracted and readily changeable if the code is properly written. Changing a register location should be as simple as changing a single #define. As for the functional interface, pick something and figure out how it should work. Start with something simple like a non-shaded coloured triangle. How should that be sent to the card. Check the archives from a while back and see what has been said. You didn't find enough information? Then propose a method of doing it. The hardware folks and Timothy will let you know if it's impossible our breaks any other assumption. If it doesn't, congratulations, your way is now "the way" until someone comes up with a better way and implements it.

There will be large amounts of work and rework in this process. As drivers are written decisions there will influence the design and implementation of the hardware. As hardware is implemented it may very well be found that a chunk of the driver has to be stubbed out or re-written because of hardware limitations. It's OK to get it wrong in the first pass, just make sure that things are modular and it's not hard to fix later.

Timothy

I think the thing to start with is a non-driver, actually. I do this with (my other employer) when bringing them up. Use lspci to find the device. Use libpci to get its physical address. Use mmap to map it into a user process. Do PIOs. No interrupts, of course, but this is a good way to get first connect. It's very simple and completely generic (it would work with any variation on OGD1 devices).

Atilla

There are system calls to get the addresses directly. Even in user space. Though i would need to look up which ones they were.

Registers
Timothy

There will be one PCI BAR dedicated to all configuration registers. This includes peripherals, the drawing engine, video controller, memory controller, etc.

We don't need to be very "efficient" with how we assign addresses into that space. So let's break up the address space and leave lots of extra room. For instance, the programmable things (video and DMA controllers) will have 512-word instruction memories.

The DMA controller may have more than that. Fine. Give these 4096-word ranges.

Next, there's the drawing engine. Just for fun, give it 32768 words (the first 8 "blocks"). Upon examination of the engine pipeline, we'll divide it up into power-of-two sized sub regions such that there is at least one for each major pipeline stage. If the engine needs more space (unlikely), we'll just push the other blocks around a bit (or start assigning them addresses from the top).

Dividing things up this way is nice because as addresses are being processed, each level of the hierarchy only needs to test some part of the address.

What the registers are is fairly well nailed down, but exactly what the register numbers turn out to be will be affected by how exactly the pipeline breaks down. (soon)

Recommended Reading
Timothy noticed that book(Linux Device Drivers, 2nd Edition) is under the GNU Free Documentation License:

http://www.xml.com/ldd/chapter/book/

http://www.oreilly.com/catalog/linuxdrive2/

Andreas posted

http://lwn.net/Kernel/LDD3/ ("Linux Device Drivers, third edition", to the kernel 2.6).

http://www.kroah.com/log/2006/05/25/#ddk (Linux Driver Development Kit) (ed: link fixed)

Atilla

I can really recommend LDD3, it's a book worth buying if you want to do Linux driver development. For additional information on current issues see also http://lwn.net/Kernel/ especially http://lwn.net/Articles/2.6-kernel-api/ for API changes. For further information on the inner working of the Linux kernel, i suggest you to read "Understanding the Linux kernel" from Bovet and Cesati, published by O'Reilly.

Future developments

KDE 4

One Post noted KDE 4 with Qt likes OpenGL triangles, as one developer pointed out. However there is a bottleneck:

The most popular Linux desktop environment will accelerate its 2D desktop (SVG's, Flash, fonts as paths, complex shapes or actual vector shapes) with OpenGL. So it would be cool to look at the bottlenecks to make the GPU a fast OpenGL SVG desktop accelerator even if it will not be an OpenGL 3D games monster.

Article:

http://zrusin.blogspot.com/2006/10/benchmarks.html

Dennis:

The more complex SVGs get, either because of beauty or just by 'amature adding add lots of cool stuff without cleaning up' design, the slower they render, easily falling behind live rendering. Optimizations or knowing and minimising bottlenecks on the OpenGL implementation will help a lot.

In case you were wondering, our card design does have a selected measure of Open GL features. If you want to help with profiling or implementation, check with the mailing lists.

Using graphic cards for computing applications

William Posted an announcement by CHREC

“NSF Center for High-Performance? Reconfigurable Computing (CHREC)

We are pleased to announce the official award and formation of a new national research center and consortium, the NSF Center for High-Performance? Reconfigurable Computing (CHREC, pronounced "shreck"), under the auspices of the Industry/University Cooperative Research Centers (I/UCRC) program of the National Science Foundation. Having successfully completed a two-year development, review, and selection process at NSF, CHREC will become operational in January 2007.

Timothy

This is a long-term sort of project idea for us. The holy grail would be to convert arbitrary C or Fortran code into FPGA logic. (This would be especially good for Cray computers that arrange Opterons with Xilinx FPGAs.) A more realistic goal, however, would be to convert a restricted subset of C into gates.

Arnaud

there is such a project that is being developed. You can have a look at it here:

http://www-asim.lip6.fr/recherche/disydent/doc.html "Disydent" (Digital System Design Environment) is a framework for co-design of embedded systems. In this framework, an application is described as a set of modules communicating through FIFOs. Each modules is written in a subset of the C language, and these modules can be either run in software directly, or synthesised as a hardware coprocessor with the "ugh" (user guided high level synthesis) tool. "Disydent" is publicly available and distributed under the GPL license, so if you like you can try to play with it :)

Licensing

Mark posted

I would like to propose the following clarifications to the license and copyright statements of the files residing on the Open Graphics's SVN server (https://svn.suug.ch/repos/opengraphics/main/):

Along with a full list of 7 points he said:

#Add the full dual-licensing explanation and a line stating “Copyright (c) Traversal Technology” to all the files.

#Make it automatic: If they don't (include the license), SVN should refuse to commit the change

Timothy

Not all files in SVN need contain this license. Text files containing only facts don't need any license. Software drivers, under BSD and MIT licenses, need an entirely different license heading.

Petter:

I made some tests. We can do it if we want.

It is now live so you are welcome to check it out or check it in ;-)

Drivers Contributors and SVN access

A discussion arose about the Maintainers of the Drivers. Atilla suggested that everyone who volunteers to help should have SVN write access.
Atilla

Control on whether people misbehave is done by the commit messages from SVN. These commit messages are regularly reviewed by most developers and things that are not how they should be are immediately discussed.

Timothy

at the moment, we should see these things from someone who wants write access:

#Post to the list some code they want to contribute, with some evidence that it works.

#Declare agreement to our licensing policy.

(though, we will have exceptions)

Atilla

(Moving things around SVN) is one of the things that should be discussed on the mailing list first. Moving around files at random can be major pain for everyone if it is done carelessly or without considering everything that is involved.

(Ed: These are jobs for a volunteer who would like to have an important impact for our project. Would you like to step up and be counted as part of the solution to the problem of closed graphics.)

Vinicius

I believe people should start by submitting patches/files(or link to them) to the list, and after a period of "test" receive write access if requested. That's how it works on most projects with centralised version control.

Timothy

Sure. And on top of that, we can simply let in people who we know. If someone has been a member for a while and seems halfway sensible, then they should just ask, and we can give them access.

The general policy should be to deal with "disagreements" via `ifdef directives, `include's and such so that the end user can select the features they want. Convergence should be our general strategy. That doesn't mean people can't contribute wholly new ideas. You can't converge two totally different ways of characterising a problem (e.g. state machine in Verilog like our memory controller vs. von Neumann programmable like our video controller). But we should strive to have a "main" version of something that adopts good ideas from other contributions. Meanwhile, we can have "auxiliary" projects that likewise adopt from related projects, and at some point, we may choose to redefine who is "main".

Sub Projects
With the development of the board, it is expected that there would be a number of sub projects. This is something that we will need to monitor and change to meet it's needs but a recent discussion raised a few comments:
Atilla

IMHO every sub-project should be in the tree for anyone to see, So that we can prevent divergence of various sub-projects that do basically the same thing. (...) I hope (we don't have a lot of ifdefs) in the verilog code, there we should have a fixed set of features. Otherwise we end up with a ton of slightly incompatible cards. The driver code on the other hand will not need many (other than to account for different OS kinds and versions) ifdefs as its functionality is defined by the interface it has to provide and by the functionality of the card. Disputable code or patches that change a lot of things are first send to the mailing list for discussion. Indisputable changes are directly committed to SVN and reviewed by those who read the SVN log mailing list.

Timothy

We'll have three kinds of projects:

# OGA-specific — these things are used ONLY for OGA, so the direction should be clear, and all changes will be percolated through people in charge, like myself.

# Completely unrelated — hobbyist projects that will not be used in OGA, at least not in the short term. Those projects will get SUGGESTIONS, but no strict controls.

# Components used by both — these include things like standard video, memory, and PCI controllers. They will be (carefully monitored). But if someone wants to fork one, that's cool too.

(...)Forking is always an okay thing, although for some things, we may request that people flesh it out really well before requesting space on the SVN server. We especially don't want to have a lot of forks. 2 or 3 major ones are okay. But beyond that, people will be asked to combine their ideas with an existing fork.

Documentation
Lourens

Could we perhaps aspire to create some decent overview-type documentation to everything we produce? So that new developers can join in more easily?

Jack

I make that a standard practise in hardware design. In addition to the schematic, assemble drawing, and parts list, I write a document called a "Technical Reference". It's a written explanation of how the product works, and the reasons for the less obvious design decisions. It often includes key design calculations. It's meant to help engineering technicians, test engineers, and design engineers who come along later and need to update the design. The combination of the schematic and the tech ref amount to a technical manual for the product.

OGD Architecture

Roger

is it possible to implement pixel ownership fields in the frame buffer? so we can have protected regions for example?

Timothy

The 3D engine has an "ownership buffer", which has a number per pixel that identifies the owner of the pixel. When drawing, the engine can be programmed to write only to those pixels with the corresponding owner. The application and driver, obviously, have to comply with this somewhat voluntarily. But this allows for complex clipping regions with reduced overhead. Typically, the X server would be responsible for maintaining the ownership buffer with values corresponding to, perhaps, the X11 resource ID of the window. With that, overlapping windows with multiple OpenGL apps is a snap.

Compatibility
Have you ever thought that it would be way cool to have a LCD in the side of your case? Well, Nick has been working at that idea. Here is the background to his question...
Nick:

There are many other options, but if you just look at the costs of an LVDS LCD controller, it is about $400+, even with only 4 MB RAM. If we can integrate a laptop connector, that means that the LCD will have 256MB RAM, and cost less (not to mention Linux compatible)! There are embedded and PCI cards that are much cheaper, but they only support TFT whereas almost all current displays are LVDS. (...) I am trying to connect an old iBook display to an FPGA (currently Actel Fusion or ProASIC3/3E due to integration and cost of routing for external chips) as a proof-of-concept, and possibly write some Verilog to implement some version of the OpenGL ES standard (in a sense, make a mini-ODG ;-) ).

So with this in mind he popped the question:
Nick

Would it be reasonable to have an interface board for laptop LCDs come off the IDC connector (or somewhere else on the board)? If that would be possible, it would be a HUGE boost in sales. There are thousands or more case modders (I am not one!) who would be willing to pay an extra $100-$200 for a video card with Laptop LCD connections, simply because discrete laptop LCD connectors cost in the order of $275-$350. This would be the favourable video card for 2 niche markets, which is always nice.

Daniel

I'm working on a product for "this market", but it will be connected to Ethernet instead of PCI, see http://diary.rozsnyo.com/2006/08/29/eat-dc/

Nick

I am personally working on a board with a Spartan-3 or Spartan-3E FPGA interfaced to some RAM (128mBit or so) and an LVDS LCD interface on a really small board, which can be used as an embedded video card. The FPD-Link interface is actually quite simple, just sending 3/4 LVDS data signals and a clock line, and I think we could integrate it onto the OGP quite easily.

Luc asked if he wanted to make a daughter board for each different (LCD) interface?

Nick

That is one solution that we could try, but another option is to have a daughter board with a few common connectors wired up, and then either sell or direct to another store that sells adaptors between connector types. either way could work.

Timothy

What I want to do, within reason, is put various video output standards on TRV10. LVDS for laptop monitors is one of them. We'll hack up an OGD1 board at an appropriate time for that feature. What matters for TRV10 is having the physical signals. With even small amounts of revenue, making PCB's is not nearly as hard as making an ASIC.

Jack

It seems to me that once the TRV10 (The first Traversal Board) is available, it would be possible to spawn a variety of OGC boards and non-Traversal boards that implement different electrical interfaces, or external accessories that convert TRV10 logic outputs into electrical signals meeting different standards. Many computer cases have blank slots where there is no card socket; that's a place where a rear panel with an unusual connector could be mounted. Imagine, for just one example, LVDS signals leaving an OGC accessory connector, going up a 3" ribbon cable to an accessory board with bleeding-edge DACs and a 13W3 connector. The nice thing about it is that we don't have to deal seriously with such possibilities until the need appears.

Atilla:

that's a nice idea. The problem with this is, that it would require an additional connector on the board which is specified for high frequency signals. Those connectors tend to be very expensive unless you use one that is an industry standard (maybe SCSI?). But even then, it will increase the card cost

Jack

there can be more than one board-level product that uses the TRV10. It allows people who need special features to order them, without burdening everybody else with the parts cost.(...) some external interfaces might be implemented on alternate PCB layouts, and others might be provided on plug-in accessories. TRV10 could become the central building block for a large and long-lived family of products.

Atilla

Did you already account for this in the layout? IE does the lines going to the IDC have more or less a defined impedance? Yes, i know that the IDC is anything but a good high frequency connector, but if it's just the connector being mismatched, we could hack up something limiting its disturbance. (...)

Timothy

No. The IDC is not appropriate.

Atilla

Well, you can go up to 1GHz, even 2GHz over an IDC connector, given that the wires going to the connector are short. IE by using buffers immediately before and after the IDC.

Programmable Shaders

Timothy

Well, the Open Graphics GPU isn't programmable in the way that the latest high-end graphics chips are. Our design goals are to get the maximum result from a minimum of logic, and that requires us to implement only the OpenGL fixed-function fragment pipeline. This is another reason I'm skipping the GPU for high-performance computing. That doesn't stop us from developing a programmable shader later, but my perspective on using GPUs for HPC is that there's a better way, and I'd rather work on THAT.

Open Hardware Foundation

The goals

The foundation goals are often commented in the Mailing list. Here is one post.
Timothy:

I'm trying to create a critical mass of open hardware designers. Putting graphics and profit aside for a moment, I want to create a community of people who work on all sorts of interesting open hardware projects. Traversal, with permission, can build products out of many of those projects, turn over large amounts of profit from them to the OHF, and then OHF can use that to foster more community growth.

OGP in the News

• http://lxer.com/module/newswire/view/67622/index.html

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.