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.
I am very concerned. I think that the Open Graphics Project is on the
road to nowhere. As it currently stands, it is doomed. It is doomed to
irrelevance. It is doomed to produce something
state-of-the-last-century. It is doomed to produce something that so few
people will care about that it will pass away unnoticed.
There is some risk that our fixed-function shader is so out of date
that it won't meet the needs of many users, but your suggestion of
doing 2D only doesn't address that problem.
OGP has to fill a need, and it has to fill that need with something that
can fit in a reasonable cost FPGA. And the need has to be worth the cost
of a low volume design. Any hopes for a final ASIC based on the design
are just that: hopes. If every step of the way along the path doesn't
provide real benefit for someone, the project will fail. That is the way
of open source projects.
This is why I have spent so much time trying to set up business
relationships so that we can afford to produce this ASIC. Some of the
answers to what we'll do in the future, however, dependent on what
happens with OGD1. One of its purposes is to attract business
partners. Once they know we're serious and capable of building real
hardware, we hope we'll attract attention from companies with money
wanting to share in the market.
Whatever OGP does, it is unlikely to have volume on its side. Any design
or idea that does not take that into account is doomed. We can't compete
with commodity items, and we can't compete with non-commodity items that
use many more gates than we have available. Even if a design made it to
ASIC, it would be three process generations behind the state of the art,
and implemented with far fewer gates than any potential competitor.
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.
Its
OpenGL performance would most likely suck, and that will always matter
at some level. It's cost/performance ratio will really suck, and that
really matters.
Actually, its performance will be right around what you'd get from any
fixed-function engine that can move 6.4 gigabytes/sec through its
memory controller.
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.
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."
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 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.
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?
In fact, I already
have, several times. Sure, I can't play games with texture compression,
or using the very latest card, but that will apply to an OGP card too.
But, guess what? The Radeon 9200 (with open source drivers) in my
machine will probably outmatch any OGP design, and will cost a
negligible amount of money by the time any OGP design tapes out.
This is a well-understood point. However, on performance and price,
we'll still compete nicely with ATI's embedded offerings. Oh, and
keep in mind that ATI don't support non-x86 platforms. The Pegasos
board has to emulate an x86 processor on boot in order to properly
initialize its 9200SE.
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.
Also, I think you're mischaracterizing the on-card and off-card
processing load. Also, given that OGD1 is a general FPGA-based
development board, it is interesting to talk about other uses for it.
The X.org people are happily writing a next generation X server, and
even if they plan to base it on OpenGL, the reality is that they will
not be using most of OpenGL's capabilities.
Sounds like you're getting trapped by the "OpenGL" buzzword. A 3D
engine is a 3D engine. It just so happened that we modeled ours after
the OpenGL spec. That doesn't stop us from supporting the most
important DirectX features, nor is it any sort of problem for 3D
desktops. Using OpenGL to do a desktop would be inefficient, because
it adds an extra layer of abstraction and processing overhead; given
the openness of our design, it would make more sense for the X server
to use the rendering engine directly.
OGP would be far better off
saying "You have a clean slate. Tell us what you want, exactly, and
we'll implement it".
That's what we did, which is why we're at the point we are at. The
OGA architecture is precisely what the experts on this list, those who
joined in 2004 and 2005, told us we would need. If you disagree with
their architectural decisions, you should first carefully review them
then attack specific points. Of course, there would possibly be some
value in revisiting the 2D vs. 3D issue, but that seemed like an
open-and-shut case to me, based on the feedback I got.
OpenGL in this context is a millstone around OGP's
neck.
Stop calling it OpenGL. OGA is a pretty basic 3D pipeline with
nothing particularly special about it. It just happens to be modeled
after the OpenGL spec, with some bits of insight from people who were
familiar with DirectX and necessary 2D logic added.
The fact that it is a 3D pipeline MAY be a millstone around our neck,
but "OpenGL" has nothing to do with it. OpenGL is a high-level API
that puts some constraints on what should go into the hardware
pipeline. And don't tell me I'm being pedantic because you "mean 3D"
when you say "OpenGL". It's this sort of misuse of terminology that
causes some of the confusion that is happening here.
We could rather give the X people what they need, and then
implement an OpenGL wrapper around that for general compatibility. The
final result should implement exactly what X needs, not more or less.
And, it should do so in a way that makes X designers wish the other
cards out there were OGP cards.
OGA was spec'd based on what X11 experts told us they needed now and
what they would need in the near future. Given the slow pace of X11
adoption of 3D, I think their opinions haven't changed much since
then.
However, if you have a better design, and you have insight that they
didn't give us, I invite you to present it. I'm not arguing with you
because I don't want to change. I'm arguing with you because I feel
like we've already done what you're telling us to do, while coming to
a completely different conclusion. How does your analysis differ?
I, personally, do not want a 3D card for GUI use at all. I want a GUI
that works, and works responsively, and smoothly. Ex-Amiga users will
know what I mean. Everyone else has yet to experience what I am talking
about.
How is the proposed design not going to be able to provide this?
I want a fast and responsive GUI with rock solid software support and
hardware that always does what the software needs.
Same question as above.
I want a mouse that
always responds within a frame.
This is an orthogonal issue. Solaris handles this by having the mouse
driver talk directly to the graphics kernel driver via a standardized
ioctl interface. We can do the same and we should.
I want transparent scaling, windowing
and compositing in the hardware.
That basically amounts to the extra "3D" hardware that is spec'd in
OGA. I am getting the feeling that either you don't know what is
different between 2D and 3D engines, or you don't know what OGA is
spec'd for, or both.
I want sub-pixel rendering in hardware
for LCD displays.
That's mostly only useful for text, and it's a minor implementation issue.
I want Porter-Duff compositing.
I just looked quickly over a paper on this. This pretty much amounts
to our entire 3D pipeline. So, what you're telling me is that you
don't want a 3D pipeline... you just want the one we've implemented.
:)
I want super smooth
hardware scrolling.
No problem.
I want updates that are fully synchronised with the
vertical blank, so that I can actually read a web page with no eye
strain while it is smooth scrolling.
Trivial. Any card with a vertical blank interrupt can do this.
Oh, and I want that to be low
bandwidth and to require few CPU cycles.
Well, for most 2D stuff, our design does this, but for anything with a
high triangle count, it'll load the CPU a bit more, because we do the
vertex processing on the host. Otherwise, what you're asking for is a
geometry engine in the GPU, which is much more ambtious. It's ironic:
In one email you both disparage our choice to go with 3D and demand
that we design a 3D engine even more ambitious than the one we've
proposed.
Nowhere in that description do I see "3D" or "OpenGL". 3D can kiss my
ass.
I see "functionality of a typical 3D pipeline" in every word of your
requirements. Perhaps you should do some additional reading on our
design and what 3D hardware is typically designed to do.
If we are going to provide something based on an FPGA, well, take
advantage of that. Leave off the fancy ideas about standards we'll
support, and just provide the software people with what they actually
need. Force them to ask for what they need (rather than what they think
they need), and figure out a clever way of giving it to them. Make them
realise we can give them stuff they can't get from anyone else.
Given that what you're asking for is essentially what we're already
intending to provide, any FPGA it would fit in is likely to be too
expensive for a mass-produced product.
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.
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 have a constructive suggestion for what the OGP card should be, but
will send it in a later email, as I do not want it to be mixed in with
this discussion.
Well, carefully consider what I've said before posting your
suggestion. Either I'm badly misinterpreting what you're saying, or
you're not really familiar with our design and are getting confused by
useless buzzwords like "OpenGL". Make sure you understand what you're
suggesting that we replace before you suggest replacing it, because I
think there's a big chance that perhaps we're already doing what you
want.
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!
Tim
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
