login
Search
Timothy Miller is a long time developer of graphics chips and drivers. He has observed that there is a growing trend by graphics hardware vendors to provide less and less information to free and open source operating system developers. Without this information, it is becoming more and more difficult to purchase new graphics hardware that is stable and reliable on Linux and other free and open source operating systems. In response, Timothy worked with his employer, Tech Source, to form the Open Graphics Project.
The Open Graphics Project is a collaboration between the Free and Open Source Software (FOSS) Community and Tech Source Inc. to develop new 3D graphics products that are compatible with Free Software, both philosophically and practically. The project is currently designing an "open source friendly graphics card" which will offer quality 3D and 2D acceleration with an impressive feature set at an affordable price, aiming for availability as early as June of 2005. Though the project was only started in October of 2004, it has already released the card's specifications, a design document, and a software model for early testing and driver development. In this interview, Timothy provides a wealth of information about the project and its current status, highlights contributions needed from the free and open source community, and fully describes the specific capabilities of the card.
Opening statement by Timothy Miller:
"In the recent past, graphics hardware vendors have tightened their focus on Windows support and their competition with each other. The result is that what was once difficult has now become impossible: getting open source drivers for your graphics card. Members of the FOSS Community, such as myself, have identified this as a growing need for new graphics hardware that is designed with the FOSS community specifically in mind.
"To have open source driver support, the minimum that FOSS developers need is documentation on how the hardware works. Since other vendors don't provide documentation anymore, I decided it would be a top priority to provide it. Another thing that is often nice to have is vendor involvement in open source driver development. Since other vendors don't provide driver source anymore, this also would be a high priority. Even when they did provide documentation and source code, vendors were still providing very little information about the inner workings of their designs. I decided that our design process would be open; this way, many people can educate themselves about 3D graphics and developers can have more intimate knowledge of the inner-workings of the hardware to help them maximize conformance and performance. The open design process also ensures that we include all the features that are essential to the Free Software community.
"These principles boil down to what it means to be a cooperative member of the FOSS Community: Open specs, open drivers, and even open BIOS.
"The benefits will be many, not the least of which will be the ability to plug the graphics card into your computer, have it 'just work' out of the box with your favorite OS, and not have to worry about buggy proprietary drivers crashing your system.
"It has been a great privilege to work with the FOSS Community on this project up to this point. I know it's cliché to say it that way, but this project has come a LONG way since it started, and the community has played a major role in that progress. We have had to learn a great deal about 3D graphics in a short period, and we would never have been able to do it if it were not for a significant number of very knowledgeable people who have been helping us. It's wonderful to be able to ask questions and get prompt answers or post an algorithm and have people critique and correct it. The "many eyes" mantra of the open source movement really is true!"
Background:
Jeremy Andrews: In October of 2004 you started a discussion on the Linux Kernel Mailing list about creating an "Open Source Friendly Graphics Card". What exactly is an "Open Source Friendly Graphics Card?"
Timothy Miller: In the past, we could ask graphics companies for their specs, and they would grudgingly give them to us so that we could write drivers for their products. Unfortunately, in the recent past, the tide has turned, and all graphics manufacturers that did publish specs have stopped doing so. Cards that are supported by open source drivers are years old and fast approaching obsolescence. Before long, you will not be able to buy a new graphics card off the shelf that has open source driver support.
Since Linux and other Free operating systems have grown in popularity, graphics card makers have started paying attention to us, the FOSS Community. But despite the growing mind-share of Linux, their response to FOSS has been to produce closed drivers. While many people are satisfied with the closed drivers, they taint the Linux kernel (making it impossible to debug video-related issues and problematic to debug anything else), usually contain bugs that can't/won't be fixed, do not conform to established Linux driver methodologies, typically break with each new revision of the Linux kernel, and have quality and performance that is generally poor compared to their Windows counterparts. These companies certainly have both the financial and technical resources to make great drivers, yet the drivers they produce for Linux are sub-standard. [1]
I started the Open Graphics Project to rectify these problems. When I use the phrase "open source friendly", I am talking about disclosure. To make hardware work well with open source, you need open specifications. You need to be able to read about the full register interface, and the drivers need to be open source.
As a developer, I want to be able to know how the hardware works so I can write drivers for it. As a user, I want the drivers to be open source and incorporated into the mainline Linux kernel (and X11 and Mesa) so that when I plug the card in, it will JUST WORK.
The goal of the Open Graphics Project is open development of open-spec graphics hardware that will be supported by open source drivers.
My employer, Tech Source Inc., is now offering to fund that project, and should the project succeed, they will commit to making the product available as long as sufficient demand exists.
JA: How did you come up with this idea?
Timothy Miller: I am an experienced graphics chip designer and driver developer, working for an experienced graphics company. It seemed only natural that we should pay attention to market demands and give people what they want. Plus, I had trouble finding a new graphics card for my Linux boxes at home and work that would work properly with open source drivers, and I found that to be incredibly irritating.
JA: How long have you been designing graphics chips and drivers? What are some chips that you have worked on?
Timothy Miller: When I was in highschool, back in the late 80's, I developed a terminal program, ANSITerm, for my Atari ST which was unique in that it could display 80 column text in 16 colors, something that was "impossible" for the Atari ST but very important for most bulletin boards. For that, I had to write text rendering code in carefully-optimized 68000 assembly. I guess you could say that was one of my early exposures to something resembling graphics driver development.
When I was in college, my senior project was a ray tracer. Certainly nothing like Pov Ray, but it got me an A. I also took a grad course in graphics.
At Tech Source, I've developed the bulk of the code for X11 drivers for at least 13 different GPU chips from a number of different vendors, including our own chip, TROZ.
My first exposure to ASIC design was MOX. MOX (named for the X11 extension Multiple Overlay eXtension) is a video post-processing chip that manages multiple bit-plane groups of overlays on a per-pixel basis. It's necessary for ATC systems that need an efficient way to deal with multiple independent layers of information. MOX is an open standard that was published in the May 1996 issue of The X Journal, written by John Kulesza and Peter Feil. I didn't contribute much to the design of the MOX chip, although I did the X11 extension code for it.
In 2000, we decided to develop our own GPU to be optimized for ATC applications. We named this chip "TROZ" after something a famous cartoon character liked to say. I was picked to do the job, because I had the most intimate understanding of what we needed the chip to do. (Among other things, ATC (Air Traffic Control) systems require high resolution (2048x2048@60 and above), high dot rates, and certain minimum performance figures on various functions.) I taught myself Verilog and chip design in general, although I should say that learning Verilog is about 1% of what you need to know to design chips. In the end, I developed the HDL for the PCI interface, the rendering core, the video controller, and various bits of interconnect logic. Other engineers did the memory controller, the peripheral/PROM interface, and all the physical stuff involving timing analysis, floor-planning, layout, pinouts, electrical, etc. This chip is currently in use in a number of our products, mostly ATC.
I've also contributed to a number of FPGA designs since then, including video post-processing for Medical Imaging and an updated version of MOX.
Open Graphics Project:
JA: Does the project have an official name?
Timothy Miller: Depends on what you mean by "official". We're calling ourselves the "Open Graphics Project", and that's alright. We're still trying to come up with a good name for the chip.
JA: What's the current status of the graphics card?
Timothy Miller: We're winding down the second phase. The first phase was to get community feedback to find out what features are necessary for a finished product. The second phase was to implement a software model of the 3D renderer so that the correctness of our design could be proven.
Right now, the software model is nearly complete. At this point, it's been through a number of successful tests but needs more testing, and it needs the missing 2D features to be added in.
The design we have at present basically amounts to the second half of the OpenGL pipeline. We've been going from the OpenGL 2.0 spec, but we're leaving out a number of features that our experts determine to be not so important that they're worth impacting other features. I guess you could say that we implement most of OpenGL 1.3 plus a number of features from 1.4 onward. All geometry and vertex processing will be done in software in the host computer. That will generate rasterizer parameters for our hardware which implements a fixed-function fragment pipeline.
Here are links for the spec, software model, and design documentation so far.
JA: What does this mean to a non-graphics card developer? Will performance suffer because geometry and vertex processing is done in software on the host computer?
Timothy Miller In short, yes, for a lot of really high-end 3D graphics, performance will suffer. Geometry and vertex processing takes a fair amount of computational power, and those GPUs that do it in hardware will naturally have a performance advantage.
But it needs to be clear that this project is intending to meet a common need, not push the bleeding edge of 3D technology. For 90% of what you want to do, its performance will be MORE than adequate. Our first priority is to provide acceleration for desktop and workstation graphics, including the new 3D GUIs that people are working on. (Think MacOS X whose "2D" desktop is really done entirely by the 3D engine; Longhorn will do the same, and KDE and GNOME are catching up too.) Our second priority is acceleration for the most common 3D graphics applications.
One of the most common causes of slow graphics cards is poorly-written drivers...
I haven't looked intensively at XFree86 drivers in a long time, but one thing I noticed about some of them in the past was that they didn't take advantage of parallelism between GPU and CPU. There are times when you have to wait on the GPU. One is when the command queue is full. Another is when the GPU is busy but you need to flush it so that you can directly access graphics memory (like if you need to read it). What I noticed is that the drivers would just busy-wait under those conditions. That's silly, because you're just burning CPU cycles for nothing. I am working on solutions to this problem.
Another way to squeeze out extra speed is to use DMA. Accessing the expansion bus (PCI, AGP, etc.) is VERY slow compared to accessing main memory. Even if you do sleep when you have to wait on the GPU, if you're programming the GPU via PIO (Programmed I/O, explicit reads and writes to the bus initiated by the CPU), you're still waisting loads of CPU cycles. The solution there is to put commands into main memory and talk directly to the GPU only to initiate DMA. This way, the CPU finishes its work quickly, and then the GPU can fetch commands in the background.
My intention is to include all the necessary features so that we can minimize wasted CPU cycles and maximize GPU utilization. This sort of thing will make up for all kinds of ways that our GPU might otherwise be considered "slow."
JA: What's involved in testing the 3d model? Who can be involved?
Timothy Miller: Working with the model is almost the same as writing directly to registers in a graphics chip on the AGP bus, although instead of writing to a memory region mapped to hardware, you're just filling in
variables.
At this point, we have successfully run a number of simple tests. Those include gouraud shading, texture mapping, and alpha blending. Writing tests involves a fair amount of computation. I've written some code which demonstrates how to compute rasterization parameters for the model, and I have written documentation to explain it.
There are lots of ways it needs to be tested:
There are many more ways to test it, and they all need to be tried.
Who can be involved? Anyone! I have written code that does some simple vertex processing, and people can use that to see how to use the model. I welcome everyone to have a look at the code and tinker with it, whether it's for curiosity, checking for OpenGL conformance, or trying to see who can find the largest number of bugs. :)
BTW, just because you may not know a lot about 3D graphics doesn't mean you can't help. I've gotten plenty of very useful assistance from people who CLAIM to be novices. They just underestimate themselves. :)
Challenges:
JA: What has been the most difficult aspect of the project so far?
Timothy Miller: I think the hardest part for me is maintaining the enthusiasm and attention in the FOSS Community. People who find out about the project are usually very interested, but the word doesn't spread or doesn't spread well enough. For instance, I responded to a recent slashdot link to a THG article on Linux gaming on open source, where I mentioned the Open Graphics Project. Someone responded to me, saying they thought the our project was 2D only. The project hasn't been 2D only since the first post I made to LKML in October, and that lasted about a day before it became clear that we had to do 3D.
Another problem is that once we've gotten attention, it's hard to maintain it. People want hardware in their hands, so it's hard for them to stay excited about an idea indefinitely. I'm hoping the release of our software model will get more people involved.
Another challenge has to do with tempering expectations. The first generation of this product won't be cutting-edge. But on the other hand, it's as good as many of the graphics cards that are currently in use by countless Linux users. We've had lots of people asking for advanced OpenGL 2.0 features like programmable vertex shaders, but some things are just unrealistic right now.
JA: What are some other major challenges that still need to be tackled?
Timothy Miller: I think at this point, they're all technical and financial. We have to actually design the chip. I have a really clear idea of what we need to do (in part because we've done it before), but it just takes time and effort.
The second problem is funding the project. Production of a graphics card is expensive and Tech Source will need to satisfy a number of financial questions before we start building graphics Printed Circuit Boards. That being said, the break-even point isn't that many cards, as the initial design is "modest" by most graphics standards.
Another "technical" problem is really more social and has to do with developing software for it. We want to go from nothing to a completed product by about June of 2005. While I have designed both graphics chips and graphics drivers myself before, the whole design effort is very time-consuming. Having the help of volunteers to develop the driver software will help the schedule considerably. The challenge here is that FOSS developers are used to having to beg for access to hardware specs. It's the good guys versus the big, mean hardware company. So when a hardware company comes along and asks people to assist in development of drivers, they get suspicious and worry they're going to get cheated. People expect to get taken advantage of by commercial vendors, and it's hard to convince them otherwise.
We will commit to developing initial versions of our drivers, but for the project to finish in a reasonable time, we're going to need a lot of help.
Supporting Free and Open Source Operating Systems:
JA: What's to keep Tech Source from closing down the next revision of this card, after developers have donated their time to create a functional driver?
Timothy Miller: Let me first say that I am first an advocate of Free Software. Only second am I an employee of Tech Source. My employer and I have a bond of trust, and I know that they would never ask me to violate my ethical principles.
(1) The truth is that we only have a really good idea of what to do in
the first place because people in the community were willing to help. It's also clear that our rate of progress would be much slower without their help. There's no way we're going to want to give that up.
(2) _I_ work there. The Open Graphics Project IS NOT A TECH SOURCE PROJECT. It's a community project that Tech Source is willing to fund. I came up with the idea, and after some discussion, my boss decided to let me do it. In return, there are certain things Tech Source wants to get out of it, and I think that's fair. But the point is that although Tech Source interests may influence the design, we are all together in a symbiotic relationship that would fall apart if either Tech Source or the FOSS Community dropped the ball.
(3) Balance. Tech Source's other business and the Open Graphics Project will benefit each other in many ways. I'm sure the community will appreciate how mission-critical design requirements and lessons learned from Air Traffic Control and Medical Imaging systems will creep into the hardware and software we develop for the Open Graphics Project. I know this sounds odd, but what we're building here is a relationship with the community, and you can't buy a relationship.
(4) Value. Tech Source would benefit from a long string of FOSS products. The FOSS community, being what it is, would quickly and wisely pull support from Tech Source's products if Tech Source acted in a heavy-handed manner.
JA: What information about the card will not be freely available?
Timothy Miller: Nothing of much value to the FOSS Community. The founding principles of the FOSS community are Free and Open Source SOFTWARE. In that regard, we are going well beyond the minimum level of disclosure. Every aspect of the design and interface is being carefully documented and made freely available. There's not much else to publish. There is the internal logic of the chip (HDL, Hardware Description Language), but looking at that would generally be more confusing than helpful to most people.
A few people have asked to see the HDL. One problem we face is that hardware design is expensive. Compilers are readily available and software is easy to copy. Hardware design tools, on the other hand, are expensive, and so too is the reproduction of chips and boards. Oh, and don't forget inventory, marketing, sales, packaging, and technical support, just to name a few. Tech Source needs to be able to recoup that expense. We feel it's important to keep the HDL as our "value add" so that another company doesn't copy the design before we've recouped the initial investment.
However, for a variety of reasons, the HDL will be published no earlier than when the initial investment is recouped and no later than when the product reaches end of life.
I don't think any other hardware vendor has ever before been so open and cooperative. No other hardware vendor releases their internal chip logic, so if anyone thinks we're not giving away enough by not releasing the HDL immediately, think again. I think what is being put forward is FAR more open than any hardware vendor has ever been before (excepting, of course, some of the computer kits you could buy in the 70's).
Capabilities:
JA: What sorts of capabilities will this graphics card provide, and how will it compare to the current competition?
Timothy Miller: Just a few highlights:
OpenGL support includes most of what you'd expect, including trilinear filtering, multitexturing, etc. The rendering pipeline is fully floating-point, internally. Framebuffer pixel format is always 32-bit ARGB.
JA: What are some examples of 3D graphics applications that will benefit from this card?
Timothy Miller: In terms of existing software, there are lots of things that make use of 3D, like CAD and graphing software, games, animation, and the latest desktop environments. Games are the most important, and while we're not trying to develop cutting-edge technology here, many games will still perform very well on this hardware. In addition, new application developers can make use of the 3D features to perform special effects for TV applications.
JA: Earlier you mentioned that you still need to add some 2D features. What 2D features are missing?
Timothy Miller: Well, "missing" may be putting it too strongly. Most 2D operations are a simply a special case of 3D, so we can accelerate them just fine with the 3D pipeline as it is. There are some 2D things, however, that would be very inefficient to support that way.
For instance, simple repeating patterns can be accelerated as textures, but the most common size for color tiles is 8x8, and the most common for monochrome stipples is 32x32. Adding a little extra logic can make those common 2D operations a LOT faster and easier to program.
Another thing is text. For xfs (the X Font Server), which handles smooth/antialiased characters, the 3D pipeline is well suited to rendering them. But for native X11 fonts which are monochrome, a more efficient way of dealing with them would be nice. One thing that is still truly missing still is arbitrary 1D line patterns, because even if you use the 3D pipeline, the patterns are resticted to powers of two in length. (Note that it's actually uncommon to accelerate dashed lines anyway.)
Some other things not supported directly (but for which there will be already at least a reasonable way of supporting them) include XCopyPlane and non-power-of-two stipples and tiles.
I've had to deal with other graphics chips which did not support some of these things well. For those situations, I have developed tricks to making them perform well, despite a lack of direct support. I intend to share some of those algorithms.
For Windows GDI support, they have something called ROP3 and ROP4. In the X11 world, we're used to raster operators that you can set using XSetFunction(). These let you combine source and destination pixels according to 16 different logical operators. Windows ROP3 lets you combine source, destination, and a pattern in arbitrary ways (256 different logical functions), and ROP4 lets you combine those three also with a mask (65535 functions). I have added a bit of logic to support ROP3, but only if the pattern can be fit into 8x8. There's no direct support for ROP4, but you can emulate it using multitexturing here one of the textures sets the alpha channel to 0.0 or 1.0. Anything outside of these constraints will have to be supported in a less convenient way.
One of the challenges is that it's a bit awkward to combine 3D, which deals with floating point color values, with 2D, which deals with integer color values. As a result, I have put the 2D-specific stuff near the end of the pipeline, which has resulted in it being a bit less flexible than it would be if I could put it a lot earlier.
I've said all along that combining the 2D and 3D rendering (necessary due to cost constraints) would compromise 2D performance. However, I don't think it'll compromise 2D performance in a way that anyone would notice.
JA: What programs will benefit from these 2D features?
Timothy Miller: While we're focusing heavily on 3D in this project, 2D graphics is still dominant. All of your usual X11 and Windows applications are dependent on certain drawing features that are obsoleted or ignored by 3D. In order for existing 2D apps, like GNOME, OpenOffice.org, etc. to be efficient, most of those "legacy" 2D features still need to be supported.
JA: How well should these specs be able to handle the graphics intensive games that are currently out on the market, and those yet to be released?
Timothy Miller: Keep in mind that no graphics card on the market can fully support Doom III, with all features turned on, at a high framerate. So the fact that a card like this couldn't handle it shouldn't surprise anyone.
Also keep in mind that this card is targeted at an audience that values Free Software and system stability [3] over high performance.
However, there are lots of existing games that'll probably work just fine. It all depends on the nature of the game, really.
Pricing
JA: How do you intend to assess whether enough people will buy this graphics card to meet minimum volumes? Is it possible that after all your development effort, the card will never be produced?
Timothy Miller: It's very hard to predict the market. There has been a lot of feedback to support the project so far, but plenty of people also say they'd rather buy a used Rage128 from eBay for $20. I'm just hoping enough Free Software believers will invest in their future and buy a product that is specifically intended to advance the availability of good hardware that is compatible with Free Software.
To reach large enough volumes, we're looking for other places to sell the product. There's a fair-sized market for embedded GPUs. If we can increase our volumes with the embedded folks, it'll allow us to succeed even if our first generation product isn't interesting enough to most people.
What drives me on this project is the idea of having the finished product in my hands. My dream is to be able to move my Radeon card from my Linux box into a Windows box where it belongs and replace it with one which is designed to work well with Free Software. I should consider the economic aspects of it more, but this is my "itch to scratch", as it were, and the drive to do it is very compelling.
Here's how people can help with this: If you are a Linux hardware vendor, contact Tech Source. If you KNOW a Linux hardware vendor, contact them and tell them to contact Tech Source. If we could get three Linux hardware resellers to commit to buying cards in volume, that would help solve some of our challenges.
JA: At what price range does Tech Source intend to market the graphics card?
Timothy Miller: We haven't yet determines the retail price. It really depends on the kind of volume we can get. The greater the volume, the lower the parts cost and the more that development costs can be amortized against sales volume.
Note that we are taking every effort to minimize the price. We need to strike a balance between offering an affordable product and making enough extra to be able to fund future products. Our hope is that the price will be a maximum of $200.
For those who want to voice their opinion, one of our mailing list members put up a petition/poll.
JA: How many cards would have to be sold in order for Tech Source to break even?
Timothy Miller: Since we haven't yet finalized our design, we can't predict the parts cost. We also don't have a clear idea of the volumes, which affects parts costs. And on top of that, we have to amortize development costs. At this point, if we got a clear commitment for 10,000 cards, we'd be in good shape.
Availability:
JA: When can I expect to be able to buy one of these graphics cards?
Timothy Miller: I'm an optimist. I'm shooting for June of 2005. If we can get enough help from the community, I believe we can do it.
JA: Is it, or will it be possible to pre-order a card?
Timothy Miller: We are considering the idea of accepting pre-orders. There are two ways to go about it, and I don't see why we couldn't do both at the same time. One is a "promise to buy" which states that you intend to buy one when it comes out, but you're not giving us your credit card number. The other is an actual "order" where we do take your credit card number but don't charge it until we ship.
Drivers:
JA: What operating systems do you intend to support by June?
Timothy Miller: At the very least, Linux on x86. The hope is that the FOSS Community will help us quickly port to all other platforms.
There are other important platforms we want to get to quickly, like *BSD and Linux for PowerPC. Due to the fact that the drivers and specs are open, it shouldn't be hard for us all to work together to port to any platform people like.
BTW, we will be offering engineering samples of the card. If you are a developer and you want a pre-production version of the card so you can develop drivers for your favorite platform, talk to us about it! If enough developers get on board, we can have drivers for dozens of platforms ready in time for the hardware roll-out.
JA: Do you expect to support non-free operating systems, too?
Timothy Miller: I want Windows drivers mostly for people who dual-boot. The ReactOS people have expressed some interest in that, and we'd love to have their support in developing for ReactOS and Windows.
There are really no restrictions on what platforms people can port to. If you can develop drivers at all, you can develop drivers for this card. Drivers for all platforms will be as open source as is legal, and the specifications will be out there for anyone to look at.
Looking forward:
JA: If everything works out, and you sell enough cards to make a profit, what happens next?
Timothy Miller: The very next thing to support is multi-head. The two most important features people ask for are TV-out and multi-head. We think we'll already have TV-out, so we'll follow the single-head version with a dual-head. If there's still more demand, we can go on to do quad-head.
Following that, we'll start working on enhancing the design to include more features that people want. These include things like cube-mapping, 3D textures (voxels), programmable fragment processing, and hardware-accelerated geometry (vertex processing).
I hesitate to talk too much about future plans, because if people decide to skip the first version and wait around for the next version, there won't be a next version to wait for. Future products are contingent on the success of the first one!
JA: Thanks for your time answering these questions, and for your efforts in making an open source friendly graphics card! I'll be standing in line to preorder, and eager to try my new card in June.
Timothy Miller: Thank you. I can't wait for it either!
This seems a fantastic projec
This seems a fantastic project.
I would gladly buy one of these.
I will also be more than glad
I will also be more than glad to buy such a graphics card. I use my old duron with Freebsd and Radeon9200 Card and my Linux desktop in the university with i865. I plan to buy someday a ppc but not with that nasty nvidia/ati cards. I delay my shopping until the card is out :-) It would be wonderful to use this card on a Pegasos PPC with the forthcoming 7447A upgrade. TRULY OPEN SOURCE. Even if it is 200$ I would buy it.
I'd buy at least two
I would buy this card for every computer I have, regardless of the price and performance, just to show vendors that the Linux Community would support vendors willing to support us. It excites me to think about how far this project could go since they've got a company to *BUILD SILICON*. Isn't the lack of a fab what is keeping down the Freedom CPU project? Man, this one could actually work.
I would buy a dozen at least.
I would buy a dozen at least. Since I would know I could use these cards my complete BSD based network.
I am probably going to buy on
I am probably going to buy one of those.
Very savvy moves by Tim's emp
Very savvy moves by Tim's employers. The market is sick and tired of vendors who can't be bothered to support Linux deployments.
The bottom line is that if this card is stable and comparable in price to other 3D cards, my family's company will buy 80+ seats on our next upgrade cycle.
Tim: I'd consider an advertisement on www.vtk.org
Advertizing.
There and probably a number of other places too. Mind you, advertizing costs money. The more we can skate by on "word of mouth" the less cost we have to recoup. But I can't see how we can get through without ultimately doing a fair amount of advertizing. Not everyone reads KernelTrap and Slashdot.
Asking linux folks to tell ab
Asking linux folks to tell about it on their sites? I know i could write about it where ever i do write on thee net.
Telling others
I personally have posted to a lot of different web sites about this. The more the word spreads around, the better. Please tell everyone you can!
Others way of funding?
I will not buy a 200$ card if I don't need it. On the other side, if there's a way to donate 20-30$, I would probably do it...
These kinds of projects are great and they need to work. If people can fund a NY times advert for 100 000$ I don't see why the open source community cannot help making an open graphic card project be successful.
Another idea: make a deal with RH/Mandrake etc.. and if one buys a license to install Linux on a system with an open graphic card, a part of the linux distrib cost (e.g. 2$) is paid from the linux distribution to the graphic card builder. The reason? open graphic card should result in decreased costs for the linux distributor. That idea needs to be redefined, but there should probably be some synergy between the linux distributions and this project.
What about grants from the local government? In some countries, you can get a grant if you have a novel busiess idea. The product is not new, but the business relationship with the users is, at least in this market.
Donations could be a nice ide
Donations could be a nice idea, that way maybe we atleast can pay for cards to give to the "right" people (Xorg and kernel developers). But I guess it takes time and effort to set up donations and such.
$200 is too much
For a card that will be about the speed of a Radeon 9000 ($50) I don't see how that many will be sold. The next generation will be much better, and hopefully they don't take too long to get it out. The entire reason people would want to buy an open source card would be for 3D performance... although nVidia's drivers are increasingly becoming better, and the new ATi drivers are showing that they can finally be used.
Not to be all negative, this idea is needed, but the viability of it isn't there right now. I'll just hope that the next generation will be worth looking at.
3D performance is not the top concern!
Mind you, as the designer, I think 3D performance is very important, but the needs of the community center around FREEDOM and STABILITY. When you pay $200 (retail--street price usually lower) for the card, you're not just buying a graphics card. You're buying the ability to have a graphics card that will work with every Linux/BSD/whatever kernel version you want to use and not have to worry about the system crashing because of it.
Put the idea of a "next generation" out of your mind. IF THE FIRST GENERATION FAILS TO SELL WELL ENOUGH, THERE WILL BE NO NEXT GENERATION. I don't mean to put pressure on people, but paying "extra" for the first version of the card is a small price to pay to ensure a long line of better, faster, cheaper ones in the future.
You're not buying a graphics card. You're buying a piece of the future. :)
windows support?
Are you considering Windows support?
I know, most of windows people are happy with their nvidia/ati card, but there's a small group of expert windows usrs who hate nvidia/ati tricks to get better performance which crash lots of boxes (http://weblogs.asp.net/oldnewthing/archive/2004/03/05/84469.aspx). Who knows, perhaps that can help to sell some cards more :)
Yes, Windows support
We want Windows support for people who dual-boot. And it would be nice if it could do DirectX and everything. We're going to need help with that, though.
Amen to Windows drivers
Especially once you get the dual-head card out - my brother's XP box has hideous driver problems with his ATI dual-head setup.
I'm going to pre-order as soon as you guys have it available - keep the update postings on LKML. I'm no video hacker, but it'd be really nice to have one thing that just works in my machines.
Jim
Dual-Head
I'd agree on the dual-head. Most of my machines are headless or need nothing but the most basic VGA console, so I doubt I'll be buying too many of these cards, but it sounds awesome for my main desktop machine. Right now though I'm using a dual-head Matrox setup. While it's not perfect (especially in the 3D stuff) the dual-head mostly rocks. If/when I replace the matrox card, I really want something with good dual-head support.
All the above said, if/when I move and have room for more machines/monitors to be set up, you can bet I'll put one of these in a machine somewhere. Maybe a MythTV box or something. Dunno, but I love the idea and I really don't think $200 would be too much to pay.
If you need support for Windo
If you need support for Windows, the best people for the job are the Wine(X)/Cedega guys. They have an incredibly intimate knowledge of all DirectX-related stuff, perhaps second only to M$ itself. So I think you need to contact those guys to see what they think of it. ;-)
Wine(X)/Cedega & Windows
Not only do they know how this stuff works almost inside out, but they know how to translate most of these functions to existing Linux-friendly interfaces (wether it be X functions or OpenGL).
Which brings up another point. Some of these translations are SLOW. Perhaps either a later model card or even just new drivers could provide direct hooks for better (almost native) DirectX support. This would deinitely improve the speed of running DirectX apps through Wine(X)/Cedega, and for those that use these apps, it's an incentive to buy the card.
Let's do it right.
We want fully native drivers for every platform. This includes Windows. Of course, it may have to happen in stages. First, just a miniport driver with a dumb (no accel) display driver. Then we add basic acceleration support and publish the pieces that we can (anything that doesn't require copying pieces of the ddk). Finally, we get all the DMA stuff in and make it run at full speed.
Indeed, that's kinda how most driver development will work here. Users will be aware that they'll have to download new drivers periodically or wait for the next Linux kernel version or whatever.
But I see no reason to do clunky translations. With the freedom of open source, we can just do things the right way.
Actually what I was trying to
Actually what I was trying to imply is that the speed of Wine(X)/Cedega on Linux is limited by these cludgey translation hacks, and having support for some native Windows driver functions on Linux via an API that Wine(X)/Cedega can utilise will improve the speed of Wine(X)/Cedega no end, particularly if the main ones supported are the ones that are the slowest to translate in code. For those people who use Wine(X)/Cedega, this could be a huge incentive to buy the card.
Definitely
Anyone who wants to write a driver of any kind for this card will get our support. Another idea I had was to see if the VMware people would be interested in developing drivers that could share the graphics card with Linux in an efficient way.
Heck, why not make it possibl
Heck, why not make it possible for cedega to use this card in conjunction with a high-end nvidia, and do the translations with this card and feed the results to the nvidia one??
Price
Well, I think $200 is kinda expensive, but I'd most definately pick one up for $100, no problem. At $100, he card is worth the time lost over the frustration of my crashed computer. I'm tired of shitty drivers. At $150, I'd think twice, but probably buy it. At $200, I'd look at my limited student budget, and really ask if I needed it.
yeah
I have to agree. I'd even say up to $120 you have me for sure. At $150, probably. But $200 is a hard decision.
$200 too much???
If you're not prepared to spend a measly $200 now, whether you're a hard up student or not, you deserve to suffer shitty proprietary drivers for the rest of your life.
Stay off the beer for the next few months and put the money you save in a jar. How often does it need to be said: you're buying a better future for graphics card hardware and drivers and maybe other hardware too, not just a single card. You can't even compare that kind of investment to just buying an equivalently featured 2nd hand proprietary card like some people here are doing - it just doesn't make sense.
Yes, it's too much
Now hold up on your thunder there brother.
"Hard up student or not"? Come on, at 200 bucks this thing approaches a months rent for me, and I'm already 3 months behind, looking at eviction. The fact that I'm willing to shell out 150 for this card is already a sign of my dedication to opening up the hardware world, but come on. Tim has shown himself to be a reasonable, honest, stand up guy, calling people names here is kind of silly if you have an idealogical goal.
I understand your frustration.
I've been poor like that too, so I understand. Believe me, if I could make it cost $20, I would. Unfortunately, we must deal with the realities of engineering and parts costs, to name just two. Maybe in the future, Tech Source can make a real profit from this, but for the time being, our goals are restricted to having the product pay for itself plus the R&D for the next version. This isn't a big money-making venture for us. It's purely forward-looking. In terms of money-making, Tech Source will only succeed in this venture by doing the right thing and treating its customers well, always.
This is the nature of dealing with the FOSS community. It keeps you honest. :)
Radeon 9200
What about ATI's Radeon range? Every Radeon up till the 9200 is supported by 2D and 3D. Every other ATI card is supported by 2D driver by definition.
This is different than NVidia's situation. NVidia's closed source Linux drivers are often regarded as better than ATI's though ATI's Windows drivers are regarded as better than NVidia's Windows drivers. But as for open source 3D drivers, you can only get than with a Radeon 9200 or less.
Friend of mine bought his Radeon 9200 for 100 EUR a year or so ago. It should cost a lot less right now, near 50-75.
PS: ATI even supports the Linux kernel's open source drivers by developing for the open source 2D driver.
ATI's radeon range up to r200
ATI's radeon range up to r200 has open source drivers but not open specs and not support for tv-out (no specs and possible DMCA-problems to reverse engineer it).
I love my radeon 8500 for being one of the fastest cards with open source drivers out there, but I would probably starve myself a month to get a fully open card with tv-out and really good drivers for X.
Hmm
Well from my point of view the 9200 would probably fit. And for me, it'll be available. I'd even buy one second hand.
Why would it fit? I just want to play a simple FPS game and/or have proper X.Org support with an open soure driver. I'd care less for TV in/out.
I'm not saying i will not buy this card because i bought a Radeon 9800 PRO for ~ 250 EUR half a year ago. If i get a ~ similar (or slightly less) card for 200 EUR then i am fine by any means.
BUT if i can't use X.Org features (which i believe will become popular, also see Avalon! See the other thread here at kernetrap.org for discussion) or can't game (i have reasons to believe Linux gaming will get a bit more popular than right now) then, probably not...
I have some 9200s
I bought some 9200s specifically because there is open source support. The issue is: How long will the 9200s be available?
Good point. And what does the
Good point. And what does the community get out of it? Or when the product is EOL? Nothing.
After i read the interview i actually got more and more convinced. I made a few remarks in this thread (about ATI mostly) which may seem like i'm not interested but i'm not sure. I really don't know wether i'd buy 1 or 2 cards (or maybe none) but i'm certainly interested as in following the project.
I just don't know if this card will do what i want, and all the technical terms don't help me. For example, no OpenGL 2. I say: DO i care for that? I DON'T KNOW! I need _some_ OpenGL support to play games, but which?
You see, freedom sometimes comes with a price, but if i can't do roughly what i like to do then perhaps a less free but more feature-rich for a similar price IS worth it... i mean right now i'm just not recompiling the kernel or use the ATI kernel module in a newer kernel (dirty, but worked marvelous in 2.6.7 -> 2.6.8!)...
9200 is at EOL
As it turns out, the 9200 has already reached EOL. I think ATI is still selling the 9250, but that won't be for long either.
Re: 3D performance is not the top concern!
Good luck getting rev. 1 out the door.
The Cell processor might have enough FP horse power to provide a competitive 3D solution for any follow-on products.
Check out Intel
A commenter on Slashdot pointed out that Intel's GPUs do only fragment processing, leaving all the vertex processing for the CPU, and they pointed out that the performance hit isn't appreciable. Intel's GPUs perform very well with games.
Looking good!
Hi Timothy,
I looked through the graphics pipeline outline and I'm really pleased to see that it's now specced to include proper perspective correction. I think this is going to work, it's looking like a great project, not to mention breaking much new ground.
Another big thing I'd really like to see is being able to reload the gate array without rebooting. If it can do that then I can see the card hitting the 10,000 goal easily even at the somewhat high $200 price level. The reason is, the enthusiast market will really be able to work with it a lot more easily. The firmware will improve faster and it will of course be repurposed for other applications besides graphics. People will be able to justify the purchase based on these other possibilities, even if they are just waiting for somebody else to code them.
Taking a page out of the Firefox book, how about loading the names of project donors and pre-order customers into the rom and let that be displayed, easter egg style?
Regards,
Daniel
Can't reload on the fly
I'm afraid that the FPGA simply does not provide a means to selectively reload pieces of it. The problem with reloading the whole thing on the fly is that the whole chip, including PCI configuration, disappears off the bus for the entire duration of the reload which is "a long time" in computer terms. Also, reloading the FPGA on the fly would require additional external hardware which is unacceptable because it would add to the parts cost. Adding to the parts cost for a small portion of the users would not be a good idea.
Re: Can't reload on the fly
I'm afraid that the FPGA simply does not provide a means to selectively reload pieces of it. The problem with reloading the whole thing on the fly is that the whole chip, including PCI configuration, disappears off the bus for the entire duration of the reload which is "a long time" in computer terms
But what is wrong with that? This card won't be the only video card sitting in the box during development, so it's not like the developer's working display will disappear. Taking care of the PCI re-configuration is just a matter of more hotplug fiddling.
Partial reload really wasn't what I was thinking of.
Also, reloading the FPGA on the fly would require additional external hardware which is unacceptable because it would add to the parts cost. Adding to the parts cost for a small portion of the users would not be a good idea
It could be as basic as a reset line on the card that can be taken out to an external button, which the developer supplies. Sure, it would be nice to have the reload under software control, that way each development iteration becomes a fire and forget, but it's not essential. The important thing is to not require repowering the PC which suddenly means everybody needs a spare PC to tinker with it. Which many do have, but many don't as well, particularly in lower income countries where a lot of the hardware hacking tends to happen. You don't want to be constantly rebooting your IRC machine.
If there's a way to pull off software reset for free then great, but an external reset line would also do the trick. It's hard to see how this would cost anything measurable.
By the way, how long does it take to fully load the fpga?
Regards,
Daniel
Oh, I misunderstood!
I didn't realize that what you were asking for was something only for developers.
Ok, good idea. What we need is a way to force the FPGA to reload while powered up. That shouldn't be a problem. We can provide an external switch that you connect to some pins of the header. Then the OS will have to deal with reloading the PCI config information.
Thanks!
Re: Oh, I misunderstood!
I didn't realize that what you were asking for was something only for developers.
Ok, good idea. What we need is a way to force the FPGA to reload while powered up. That shouldn't be a problem. We can provide an external switch that you connect to some pins of the header. Then the OS will have to deal with reloading the PCI config information.
Great! My theory is: where the developers go on this is where the users will go. There just isn't any better or cheaper way to get good publicity, never mind good hacks.
I'm really looking forward to doing my first logic-level hacking on this. Looks like I have a lot of mailing list to catch up on.
Regards,
Daniel
can reload on the fly
so what, you need a chip to programm the fpga e.g. a cpld using the jtag pins. if you would do the pci stuff on the cpld you could easily reprogramm the fpga. even more you needn't to put the hole graphic card programm in the flash only an minimal version for textoutput and therefore save space and reducing the cost for it by buying a smaler flash with less pins and save again some money by reducing the cost for layouting, or if you get the minimal graphic card in the cpld (i know, they are small) save a hole lot of money. the hole graphic card would then be loaded by the driver. the only thing is: the graphic card driver must be unloaded, and the programming driver must be loaded and vice versa.
PCI in CPLD???
That's an interesting suggestion. I'm sure the parts cost for the extra chip would be unacceptable, and I'm also sure that a PCI controller would not fit into a CPLD, at least not a cheap one. But it's still an interesting idea. Actually, to completely follow your suggestion, we'd need to fit both PCI/AGP and code to access both BIOS and FPGA proms in there. I think that would necessitate another small FPGA. We really don't want to be increasing cost here, though.
Well, it would incur some ext
Well, it would incur some extra transfer latency and suck money.
Another suggestion: use a small CPU (really simple, maybe a microcontroller, $5), some Flash (enough for a copy of the FPGA bitstream, $5) and same amount of SRAM ($10 tops).
The CPU loads the FPGA from Flash at bootup. Then, the FPGA contains a block in the AGP controller that acts as a bridge to the CPU so the host can download new FPGA bitstream to SRAM and ask the CPU to reload the FPGA). Then, after a predetermined time, the host tries to contact the CPU through the FPGA. If the CPU doesn't see this, it automatically reloads the FPGA with the "backup" bitstream from Flash.
This provides graceful error recovery and field upgradability. Note that you no longer need a separate FPGA bitstream memory, so you gain some $$$ here.
FPGA programming.
How is FPGA reprogramming done when upgrading the graphics card?
Is the problem with using it for other projects that you have to be very
carefull to not make any mistakes with the part handling the AGP och PCI
bus to not leave the card in a bad state? Is there any way to recover from
such a state? There will surely be intrest in optimizing the card and people
will hack untill it breaks and have a need to reload the card.
I have another idea for using the graphics card as an FPGA development platform.
Would it be possible to include software to let one graphics card reprogram
another via the jtag ports? That would make FPGA hackers buy two graphics
cards and use one as the systems graphics card and programmer for the
other card. Dont include extra hardware for everybody, (exept for a few pins
and a cable), motivate the hardware hackers to buy additional cards.
Reprogram FPGA
There's no way to reprogram the FPGA "on the fly", because it can only be reprogrammed all at once. You can, however, reprogram the serial prom and then reset the FPGA so that it reloads. But then you lose PCI config state. There are ways of dealing with THAT too using hotplug. You wouldn't want to do this with your console card, but for developers, it'll be nice.
We'll provide headers for all vital things that need to be reprogrammed, plus some user I/O that could be used for anything you like.
Another reason to buy it
What I'd be buying is the assurance that future generations of the kernel and the X servers will not obsolete my video board. Considering what I've already put into the system, that's worth paying some money for. I'd hope it would be somewhat less than $200, though.
If it's going to have flashable BIOS, I'd hope that there'd be a jumper plug that could be removed to write-protect it by physically disabling the write circuitry. I'd sure like to have absolute assurance that no physically possible hardware or software malfunction could corrupt something so vital as the video board BIOS.
Wishlist item: it would be desirable to have a way to field-configure the board for fixed-frequency monitors, powering up with a custom modeline.
I'm guessing that I'm one of
I'm guessing that I'm one of many who would like sufficient 3D to be able to run a CAD program and, say, Flightgear at usuable speeds. $200 is a bit steep, but I'd buy one. I guess I need to put off my next computer purchase until after June, eh?
That's the problem
Linux is driven from a designer's perspective, and it has always been and will always be the wrong perspective.
You can blow $50 on a card that will give you dual-head and equal performance on Linux/SCO/Windows using either open-source or proprietary drivers. Why should we pay $200 for your card?
Strengths and Weaknesses
We don't have to go into the fact that most software developers are unskilled in human factors. What Linux loses in user interface pleasantness, it makes up for in being exquisitely engineered.
If you want to use Windows, buy your $20 card.
The people who use Linux aren't looking for a $500 Dell box that they use only for web surfing, virus collecting, and the occasional Word document.
Due to the nature of the Linux user mentality, stability is a huge concern, and closed source drivers translates into instability. This card is designed to sell to those people. Those people want to be able to stay up to date on the latest kernel features and still be able to have X11 work properly. Sometimes you pay a premium for something that's just going to work right.
Just today, I was buying a memory stick for one of my PCs. I could have bought some cheap junk memory for $30. Instead, I chose to pay $100 from Crucial because I know what kind of mess bad memory can make out of your computer.