On Fri, 2006-05-12 at 19:28 -0400, Timothy Miller wrote: > On 5/12/06, Ray Heasman <[EMAIL PROTECTED]> wrote: > > Please take the following message as constructive criticism, and try to > > make your replies the same. > >
> This is precisely why the stated primary target market for OGA is > embedded systems, not open source. Our analysis suggests that OGA > will compete extremely well on both price and performance in that > market. Power consumption is an issue we're going to have some > trouble predicting, but many embedded systems are not so > power-constrained. They're small but not necessarily battery-powered. Well, I have been doing embedded development (hardware, firmware, HDL, circuit design and software) in various fields for around eight years now, and this is the way I would see it today: I have to design a device and I need some kind of graphical output. Ok: 1) If I am running am embedded windows application, I can use a proprietary chipset and its drivers. Done. 2) If I am running an x86 CPU, but not any well defined OS, I can use whatever is in the support chipset, in VESA mode. 3) If I am running an embedded x86 CPU, and it has an integrated framebuffer, I use that. 4) If I am running an embedded non-x86 CPU with an integrated framebuffer, I use that. 5) If I am running an embedded non-x86 CPU without integrated framebuffer, I will either: A) change the spec to use one with integrated framebuffer B) switch to an x86 processor C) sign the necessary NDAs with a company to get access to programming information for a proprietary chipset, and program it myself. D) (Not a real option today) use an open chipset that is well supported and program it myself and/or use open source libraries. Given a framebuffer that I have to program for, I will want the framebuffer to be as simple to deal with as possible. i.) If I am doing boring UI stuff with limited input (say for example, a GPS navigation map), I will use the simplest framebuffer mode available for the task, program it and be done. ii.) If I am doing something that requires video, I will use a chip with a framebuffer that accepts YUV directly, and potentially has MDCT acceleration or motion compensation. Once the task reaches a certain level of complexity, it makes sense to use something supported by code that does the job you need. I'd probably use one of the VIA processors with a VIA supporting (CN400, say) chipset and ffmpeg or mplayer running in fbdev mode. ie. No X. So, there is a little wiggle room for an OGP chipset in 5C, because inter-operating with any chipset is hard, and the support from companies for their proprietary stuff usually sucks (although pointy haired bosses always seem to think it's great), and software that you can download and use freely is not likely to be all that useful. But, look at the second set of items I gave. In every case, I ended up using a framebuffer, and did everything I could to avoid work using it. Now, there are usually things you try hard to optimise for in embedded design. Cost is normally really high on the list. This means using the slowest parts you can make do with, and with the fewest number of pins. They usually equates to "cheaper", and can remove dealing with cooling from the equation altogether. Smaller packages are good because they reduce board space and thus cost. BGA and other such packages are sometimes a loss because they are hard to rework and hard to route to and from. So, that means I'll use the slowest CPU I can, with the supporting chips that require the least amount of work to use. The CPU in question probably won't support PCI, or not do a very good job of supporting it. I will use the lightest smallest kernel, RTOS, or OS that gives me what I need. I will be peeved if I have to figure out how to make PCI DMA stuff work and integrate with my embedded device that has limited PCI support. The fewer interrupts and DMA/MMU issues I have to program for in my custom OS/licensed RTOS/custom whatever the better. So, if I look at the current OGC spec today, and was hoping to use it for my project, my questions would be: 1) Hm. It has a 3D pipeline. I wonder how I turn it off? I wonder if it still uses power when its turned off? 2) Hm. It uses DMA queues. Can I use it without turning on DMA? 3) Great, it does YUV. Hope I can use it without DMA. 4) I wonder how I set up the outputs for my requirements? 5) Is there any weird VGA BIOS stuff that I have to work through or can I just disable all that weird PC legacy crap? 6) Is the DAC integrated, or do I have to include that too? 7) What voltages does it use? 8) What other support circuitry does it require? 9) How much does it cost? 10) No, really, how much does it cost? Let's dream a little, about what I would love to see available. In an ideal world, I would want a video support chip to be completely memory mapped with no bus in the way, for maximum compatibility. So: 1) It would look like an SRAM or DRAM to the CPU. It would then have its own external RAM that it would map so the CPU can see it too. This might even give me a way to use DRAM with a CPU that only does SRAM. Cool! 2) It would have YUV support and/or a fairly simple bit blitter with YUV support. 3) Setup would be through some support registers. 4) Interrupts would be tied to one of the interrupt pins on the CPU, with control being through some nice memory mapped registers. 5) There would be no "DMA" in the sense that the support chip plays in the CPUs memory. The CPU will use the support chip RAM as it's own RAM. Why add a bus I don't need then use DMA to get around the bus? Now that is a chip I would have a use for. Useful, integrates with just about anything, easy to program, saves me time during development. > > I think there is space for an open source hardware graphics card or > > chipset. I also think that trying to do an OpenGL implementation in the > > card is a terrible idea. At every level, doing anything that is anything > > like what is out there today is a terrible idea. We can't compete with > > high volume chipsets, even if our drivers and specs are fully open. We > > can only compete by providing something that isn't out there. It has to > > be _different_. Even better if it is different and simple. Complexity is > > a cost, not a feature. > > The 2D vs. 3D argument has been beaten to death. You may want to sift > through the archives (and LKML posts on this topic) where the number > of people in favor of a 2D-only design were a tiny minority. Hm. If you are going to run this project as a democracy, then OGP is really in trouble. The number of votes for any particular argument should be irrelevant. It's the strength of the arguments backing a vote that counts. Someone (that's you), makes a final determination and sticks with it until its obviously wrong. The rest of us think you're brilliant or swear at you, or both. :-) > The decision was made to design a pipeline compliant with OpenGL 1.3 > (and some later features) and tweak it so that it would perform well > on 2D tasks as well. In fact, the stated primary intended uses of > this design are "2D desktops plus the simple 3D eye candy that is > popular in recent UIs." And there we start diverging. The problem is that things don't stand still. There will always be a proprietary chipset with open source drivers that beats what an OGP design could do. This proprietary chipset will always be cheaper, because of volume. The average desktop user might pay a little extra for an open source chipset, but the keyword is "little", as in 25%, assuming the same performance as the competitor. The user might pay more for "different" if they think "different" is in some way cooler. Look at the history of the Apple Mac for an example. They are a lot less likely to pay more or accept a design if it is inferior to just about anything out there and does exactly what the other chips do. Any high volume embedded provider that actually needs 3D will either: A) Use a custom CPU core + 3D core + whatever else is needed SoC that you can order from any number of providers nowadays. You give them a list of cores picked from their catalogue and you get an ASIC with those cores. ie. A nice cost reduced design with intermediate NRE and a production life that's good for as long as you keep buying them. B) Use an x86/graphics chipset combination they pick, along with the drivers available from the manufacturer. Their volume of use will probably ensure continued availability of their chosen chipset, and if not, they will just pick another chipset that their OS supports and rev the design. There is some opportunity in replacing B, but how many high volume/high cost generic 3D consumer electronic applications are that that OGP could count on? How would you compete with the big names for promises of support, volume, driver features, and speed? A medium volume provider might be interested in OGP stuff, assuming they need 3D, but their selling price will probably be high and they would save a lot of money during development using an off-the-shelf x86 CPU/chipset combo (or perhaps even standard motherboard) with support that is good enough. > The fact that the design is based on a 3D pipeline doesn't mean that > we weren't attentive to the needs of 2D desktops. Sure, having > floating point and textures and such in there complicates things, but > the tradeoff is worth it to maximize the market as much as we can. > > What do you think will get bought more? A 2D only engine? Or a 3D > engine that's also good at 2D? The real question is "Would the 3D engine be bought more, and if so, would the extra sales justify the increase in cost, development time, and complexity to everyone else". If you are talking deeply embedded stuff, the designer would see your 3D pipeline as a cost not a feature. > The only thing that 2D-only would give us for the same amount of logic > is wider issue, which helps in some cases and not in others. Having > read and responded to some of your later comments, I am of the opinion > that what you're asking for is NOT a 2D design. 2D designs don't have > scaling and rotation. Now we slip away from what I was trying to achieve. I wasn't asking, I was just showing how my _desktop_ needs don't call for 3D. I am partially arguing that maybe we should just use less logic and do a really good and simple 2D design (that doesn't do the cool stuff I was talking about). It would be quick to do, and could be made much higher performance than a card running in some VESA mode. Maybe even a design that would be commercially viable implemented in FPGA only. Alternatively, it could be implemented in a cell-based ASIC for only a few tens of thousands of dollars, and you could have sales very soon. > > If I want an OpenGL card, I will buy a nVidia or ATI card that is > > reasonably well supported by an open source driver. > > What happens when Radeon 9250's run into short supply? I will buy a card that is currently cheap and has open source support equivalent to that of the Radeon 9250, and it will probably be several times faster. And I will be able to do so, because there are lots of open source developers making it happen. An OGP-designed card provides no special value for me there, beyond a mild wish to help out open source projects. Most real world people don't have that wish. > > OpenGL is more than we need. It's also less than what we need. Reality > > has quietly gnawed at this list, and people are now talking about doing > > most of the hard stuff off of the card, or doing something besides a > > graphics card. Great, so why are we here again? > > We're here because we have something we'd like to accomplish. Not > every thing is easy, but I have build a number of real and potential > business relationships around this project that, should they come to > fruition, will give us the boost we need. Hm. My experience is that words are cheap. I might feel more enthusiastic about OGP if I had more detail about those relationships, but I have learned that such relationships aren't usually worth much until after there is a contract and money on the table. They increase your chance of success from 1% to about 3%. > > Furthermore, as process feature sizes get smaller, it becomes harder and > > harder to design for them. FPGAs don't suffer from that problem, because > > the tiny feature sizes only impact the initial design of an FPGA cell, > > and every design uses many repeats of the same cell. FPGAs are getting > > cheaper and more powerful. Perhaps we should just count on that and use > > it to do things a static ASIC simply can't do? I can see the point of > > freezing a subset and implementing it as an ASIC, because it would make > > money, but if the FPGA version of OGP doesn't have a real value > > proposition for people, it may as well not exist. > > Well, before we do the ASIC, we're already going to implement > everything in the FPGA, doing exactly what you're suggesting. There > are many unknowns about the next step that will become much easier to > answer at that time. The ASIC will cost millions to make, especially if you go for any remotely custom design on a bleeding edge process. That puts it in the "future" category. In the meantime, people have a limited interest in working on things that have no direct and immediate value to them. Sure there will be idle chatter on the mailing list, but you won't get a whole lot of real work out of people unless they are directly benefiting from that work. That is another of my points. Unless you can find something to do that is "cool" with the FPGA based cards, you are going to be seriously in the hole for making them and people won't do much with them. If perhaps you see this as more of an open project, where you do work in the open, and other paid programmers in open source companies help you because they see a benefit for their companies, then great, you are probably doing the right thing - you are getting other companies to pay for part of your development. Don't expect a whole lot from anyone else, though. > While it's very likely that you could think of something we haven't > considered, please don't assume we're idiots that haven't sifted > through most of the tradeoffs and risks when setting out to design > this thing. I haven't... I have just watched things over time, and come to the conclusion that those conclusions need to be re-examined. > That all being said, your input on the nature of our design is > encouraged. If you see a missing feature, an existing feature we > couldn't possibly benefit from, or some radical new approach to this > whole thing, by all means, post it! I am worried about things at a very high level. The spec you have is meant to meet a particular need. I am not complaining about the spec. I am complaining about the perceived need the spec is written for. I am complaining about the implied requirements of the spec and the tradeoffs they force, and how those tradeoffs compromise the original logic that specified the need. It's just that when I look at the spec and the stated goals of OGP, and the world I see outside, and a desire for OGP to succeed, I can't make them all meet each other. I appreciate the relaxed and open way you have replied to these posts, and I hope that some good comes of this discussion. Keep well, Ray _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
