On 5/12/06, Ray Heasman <[EMAIL PROTECTED]> wrote:
Probably the most useful response I can give immediately is to say:
When I say OpenGL or 3D, I think they are both a bad idea. We don't need
3D, and when talking about 3D, we don't need to be contaminated with the
idea of adding OpenGL-like features. It's a bad idea layered on a bad
idea. They are bad influences, both, because they jump to solutions
before problems are considered fully.
I see your point. But keep in mind that yours is only one opinion.
It might be the only right one, but you're coming here a significant
length of time after "3D" was a foregone conclusion. Thus, you have a
lot of beliefs to tear down before you can build things back up again.
Porter-Duff compositing implies sub-pixel alpha blending and does not
imply 3D.
There are a lot of things that can be implied by this. Are you saying
that there is more than one alpha value per pixel? Are you saying
that there is more than one pixel in the framebuffer per pixel on the
monitor
For a long time I read everything that went by on this list, and my
impression is that you came out of the gates with the idea of doing 3D,
That's not accurate. I came out of the gates suggesting a fast 2D
design, which was universally rejected.
and that part was never really discussed in a meaningful way.
Actually, it was discussed extensively.
The
alternative was too simple and badly defined to be meaningful.
What was the alternative that you're thinking of?
I
eventually stopped reading everything a month or two ago when I lost
hope in OGP's future.
You know, sowing the seeds of doubt is hardly a good way to help a
project like this succeed. If you think there's a problem, help fix
it. (Like you're trying to do right now!)
The fact that you say everything I say implies "3D pipeline" to you
illustrates my point exactly to me. You are stuck in an box of
preconceptions. You have never been out of this box, and your proposed
solution is overcomplicated as a result.
My reasoning here is that everything you described is something that
is supportable by the "3D pipeline" that we had defined. I make no
claim that this design is an optimal one!
One of your obstacles is that you've not yet given a frame of
reference for this new and improved idea you say you have. What you
might want to do is have a look at the OGA model and point out
specific examples from its design that are unadaptable to a better
design.
I have a feeling that a better design would have at least a
superficial resemblance to the design we've already spec'd.
Therefore, it makes a good frame of reference for describing a new
design.
Also, you've made statements that you believe that 3D isn't
appropriate. Ok, fine. If you're right, then it shouldn't be too
hard to convince me with solid logical argument. I have a history of
changing my mind in the face of arguments that run counter to my
preconceived notions.
Tell me why it's not useful to support an OpenGL-like 3D rendering pipeline.
Describe to me your alternative and explain how it meets our needs better.
Tell me how I'm going to sell this new design to a buzzword-driven
market that expects everything to be 3D whether they use it or not
(something I've seen in ATC requirements specs more than a few
times!).
My requirements imply several things to me:
1) Polygons
2) Layers
3) 2D
4) Compositing
5) An efficient representation for data that takes advantage of the
above, and allows efficient encoding of scale, rotation, translation and
depth for objects and their children.
That sounds great.
There is a useful concept that I think needs to be kept in mind in
graphics:
The fastest way to do something is to not do it. This is a comment on
the general way in which people should implement graphics primitives
nowadays. Why copy something when you can just read the data from the
new address?
I've had some of these ideas too, actually.
Similarly, we need things to layer over other things, but we don't need
perspective correction. The Z axis implies visibility only, not scale,
and we can encode that information without requiring Z values on each
input polygon.
Fair enough. So if we can add perspective correction cheaply enough,
does it do any harm to keep it?
Similarly, we don't need texture mapping. Sure, we need some way to
represent rectangles of pixels, but use the word "texture" and you have
already jumped to a potentially suboptimal solution for our problem
space. If we can do sub-pixel rendering and handle a ridiculous number
of polygon fragments in parallel, it's a lot less painful to do what we
want, without ever resorting to texture maps. And we could do it because
rasterizing could be implemented in a way that requires no texture
reads, no zbuffer reads, and little or no overdraw.
Well, I kinda generalized the texture idea a bit. It's basically a
bitblt source where how you walk the pixels doesn't have to be
rectilinear. I call it "texturing" because what we spec'd is capable
of doing what OpenGL requires, but it's a bit more capable than that.
Do you want to be able to do scaling and rotations?
I'm not sure it's suboptimal just because a special case of its
functionality is capable of doing texture mapping.
BTW, please be more specific about what you mean by "subpixel
rendering." I've seen different documents and people mean different
things by it. If the final image is one pixel word per monitor pixel,
then the subpixel rendering is all dependent on the pipeline's ability
to make every target pixel effectively the result of rendering
multiple pixels, but they're averaged in the end. There's more than
one way to do this.
We don't need to do 3D transforms, because we only have 2 dimensions for
any object, and a layer depth for that object, and 2D transforms are
enough. That's a lot fewer gates or operations.
Actually, the only 3D transform that OGA is capable of is perspective
correction. "Texture mapping" is just a generalized 2D distortion on
an image. You can walk the source image any way you like, and you can
apply perspective correction to it or not.
In the case of perspective correction, it's only a handful of extra
pipeline stages (out of hundreds) that does a reciprocal lookup
followed by a multiply for certain numbers in the fragment data. This
is really NOT a whole heck of a lot of logic, especially when you
consider what's required to do what you're asking for.
In other words, we can throw away a lot of what makes 3D rendering
"hard" in terms of gates and bandwidth, and implement some pretty
dramatic parallelism in the rendering stages because each rendering unit
doesn't refer to any external data.
I'm not sure I agree with you about which bits are hard. All you've
done is thrown away a few reciprocals and multiplies.
And finally, most of the things that you mark as "trivial" are never
done, and it would be really nice to fix that, because the "trivial"
things are often the most important things when it comes to making a
smooth GUI. If we just implemented all the trivial stuff, we'd have
something better than anything else out there.
Well, yes, and in MY work, I HAVE implemented these things. I call
them trivial because they truly are. It's just that most chips and
drivers, for some reason, don't implement interrupts for things that I
think are obvious. And even for the things that ARE implemented,
driver developers don't use them.
Here's an example:
There's a popular graphics engine I did a driver for where I made
extensive use of DMA. (Much moreso than existing XAA drivers, so my
performance was much better.) This engine lacked something that I
thought was just balls obvious. You see, when you've told it to fetch
words from its DMA ring buffer, you can get it to interrupt when it's
emptied the buffer. The problem with that is, with interrupt, context
switch, and processing overhead, there is this huge idle period before
you can get the engine fetching again. What they needed was an
interrupt that was asserted when the ring buffer was ALMOST empty.
You have no idea how much easier that would have made things for me.
Instead, I ended up doing something embarrassingly crazy that I
wouldn't want to tell you about if I were allowed to. :) There were
a number of other nice things that would helped to go along with that.
Hm, this is a lot more than I intended to say, but it should start the
ball rolling.
Keep rolling....
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
