Ray Heasman 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.
This certainly a valid concern. Specifically, we do not want to build
the bus interface into the chip. Currently we would need support for
AGP and PCIe based MotherBoards, but we have no way of knowing what we
would need next year.
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.
Yes. I would advocate using existing ASICs where possible and CPLDs for
low level functions if possible.
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.
I am also concerned about that. We need to consider how to amortize one
time costs, and where the break even point is. Unless we can get VC
backing, I think that we would have to break even at 5,000 units which
is a rather small production run.
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. 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.
This is a valid point but ... . We can compete with commodity items as
long as the commodity items have closed source drivers. However, we can
only compete on this basis with Linux and BSD users.
If the design is done in Verilog (or other VHDL), there isn't really a
question of hardware generations with the design. The issue is that
newer hardware generations are going to cost more money to implement.
So, being one generation behind is a reality that needs to be
considered. Can we get the performance we need with 65 nm or do we need
to go smaller?
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.
Hardware OpenGL is what is needed for some users. Actually, it doesn't
need to be OpenGL, but rather just needs to do the parts of the SGI
pixel pipeline that can best be hardware accelerated.
If I want an OpenGL card, I will buy a nVidia or ATI card that is
reasonably well supported by an open source driver. 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 something to consider. While nVidia and ATI do not actually
make native OpenGL cards they do dominate the market to the detriment of
the *NIX graphics market.
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?
Yes, I agree that there is a large market that doesn't need hardware 3D
acceleration.
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. OGP would be far better
off saying "You have a clean slate. Tell us what you want, exactly,
and we'll implement it". OpenGL in this context is a millstone around
OGP's neck. 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.
This idea clearly has merit. However, we still have the same issue: do
we have hardware 3D acceleration? Perhaps we should have a card design
that offers it as an option. If the card has only a generic pixel
pipeline and the OpenGL parts are in the diver, it could be used for
both the new X and OpenGL. We should also consider if the 2D hardware
needs to be optimized to do Cairo.
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.
I have not experienced what you are talking about but I do experience
what I think that you are complaining about. IIUC, this is not a
function of the graphics card but rather of the way that *NIX does
multitasking. UNIX will block user I/O to do other things -- a very
broken idea for GUIs. Some distros try to ameliorate this by bumping X
up to Nice=-10, but I don't see that this really helps.
I want a fast and responsive GUI with rock solid software support and
hardware that always does what the software needs. I want a mouse
that always responds within a frame. I want transparent scaling,
windowing and compositing in the hardware. I want sub-pixel rendering
in hardware for LCD displays. I want Porter-Duff compositing. I want
super smooth hardware scrolling. 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. Oh, and I
want that to be low bandwidth and to require few CPU cycles.
I think that what you need to address this without rewriting parts of
the Linux Kernel is to have a CPU dedicated to running X.
Nowhere in that description do I see "3D" or "OpenGL". 3D can kiss my
ass.
You have a point. Perhaps software 3D is more than adequate for many
users -- especially now that > 1GHz CPUs are standard and 3GHz CPUs are
not uncommon. Yet, Linux is known for running well on slower hardware.
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.
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.
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.
I don't think that a production card based on FPGAs is practical.
Another thing to consider is whether a CPU could do some things as fast
as a FPGA or ASIC.
IAC, I think that a design that would address your issues would be one
that was based on a CPU that was dedicated to running X. Actually, we
don't need to limit ourselves to only one CPU. Dedicating a inexpensive
CPU to the mouse and keyboard is something to consider.
--
JRT
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
