I didn’t know where exactly to post this question, this isn’t exactly a coding question.
I’m on a project now to design an OpenGL-compatible GPU. I’m able to use an already available OpenGL ES 2.0 design. So I wanted to know what exactly are the hardware differences between the two and whether it’s possible to improve on the previous project to make it 4.2 compatible, or it’s better to design a new one from the ground up.
I came upon this file | www(dot)seas(dot)upenn(dot)edu/~pcozzi/OpenGLInsights/OpenGLInsights-Pipeline(dot)pdf, which is a great file, but I wanted to hear from experts if there are some more details to the matter than just that.
First… why OpenGL 4.2? What I mean is why pick such an arbitrary number? The most recent GL version is 4.5. The most recent GL version supported by Mac OSX is 4.1. What makes GL 4.2 so special that you want to stop with that version?
Second, there are no “hardware differences” between versions of OpenGL. Because OpenGL does not define hardware at all; there is simply the implementation. Whether the implementation provides the features required by the standard through hardware or software is irrelevant to the specification.
Third, even if we did assume that every functionality difference between GL 4.2 and ES 2.0 was indicative of actual hardware… you’re basically asking us to write a very, very long list. One that is highly likely to not be comprehensive.
Fourth… I find it kinda hard to believe that a GPU engineer, someone who is expected to design the actual transistors and layout of a GPU, is ignorant of the feature-set of modern GPU hardware.
I’m not building a cutting edge GPU, it’s only a design for simulation purposes, also I’m still a student, not a GPU engineer to the fullest yet. I said 4.2 because it’s considered to be somewhat new, not very old standard, and from my search starting from 4.3 OpenGL had major changes so I thought 4.2 would be suitable as a first step to the field and know how to build a GPU.
As Alfonse says, the list of differences would be very large, and I’m not aware that any such centralised list exists.
A smaller list can be found in appendices D, E and F of the OpenGL ES 3.2 specification, which list the major changes between OpenGL ES 2.0 and OpenGL ES 3.2. That still doesn’t tell you the differences between OpenGL ES 3.2 and OpenGL 4.2, but it narrows the gap significantly.
Thanks a lot. Of course I’m not asking for the full differences between the two standards feature by feature. What I meant is that each implementation has some specific hardware specs to make it possible to run the standard. Like I read somewhere that OpenGL ES uses fixed-point while OpenGL uses floating-point hardware. These kinds of differences are what I’m looking for.
I said 4.2 because it’s considered to be somewhat new, not very old standard, and from my search starting from 4.3 OpenGL had major changes
What, compute shaders? They’re little more than fragment shaders that you can fire off without the rest of the rendering pipeline.
SSBOs? They’re just 4.2’s image load/store with a nicer interface.
What I meant is that each implementation has some specific hardware specs to make it possible to run the standard.
Which is a matter of the implementation and the hardware it runs on. It has nothing to do with the standard per-se.
Like I read somewhere that OpenGL ES uses fixed-point while OpenGL uses floating-point hardware.
That’s not true.
GLSL ES has syntax for declaring general categories of precision. But it never mandates anything in particular about it. highp is not equivalent to floating-point, nor is lowp equivalent to fixed-point. Exactly what they mean is implementation specific.
It should also be noted that desktop GLSL has the same notation (though in that spec, it doesn’t actually do anything).
The precision requirements of GLSL ES 1.00 permit implementations to not use full IEEE-754 floating-point computations. But nowhere does it require that implementations use fixed point math.
You can implement OpenGL in software, on any CPU architecture. So, the hardware “requirements” are nothing more than the basic requirements of any computing device running any program (read & write memory, add, branch.)
GPU designers choose to accelerate specific portions of the GL with dedicated hardware (i.e. texel filtering) because that makes real-world applications “go fast”. Which portions you choose to dedicate transistors to, and exactly how to arrange those transistors for “efficient” operation is what you’re really talking about as a hardware designer. “Possible” is very different from “efficient”.
If you want to think about hardware design for a few blocks of GL4.2, as compared to simpler requirements for ES2, consider:
how to buffer inputs and outputs between a set of programmable stages of execution (i.e vertex, tess, tess, geom, fragment / compute)
atomic access to resources from any stage, guaranteeing memory ordering among many execution units
data format conversions (vertex, texel read write, blits) (10-, 11-, 14-, 16-, 32-bit floats) and computation (64-bit doubles)
higher range requirements (how many multiply-add bits does the rasterizer need, to support a 2k viewport? a 16k viewport? how about texel address wrapping?)
The thing is, you can’t just implement specific parts of the pipeline in isolation.
Some features can be implemented entirely on the CPU. Some features can be implemented as code which is integrated with the shader to form the GPU program. And some features have to be implemented directly in hardware otherwise most of the pipeline has to be implemented on the CPU (i.e. software fall-back).
It seems fairly clear to me that what the OP is essentially asking is “what do I need to add to ES 2.0 hardware so that I can use the upgraded hardware for 4.2?”. Implementing 4.2 in software and reducing the hardware portion to a RAMDAC doesn’t count.
Of course you can. Remember the ATI Rage 128, or the Intel GMA 950? Millions of customers bought products with those OpenGL-complaint GPUs. And they didn’t implement any of the TCL portion of the pipeline in hardware.
Again, “possible” is not the same as “efficient”.
I offered several examples of functionality differences that impact hardware design. But my point is that deriving “hardware requirements” from reading a thousand pages of an abstract software library description is actually… not so clear at all. GL4.2 requires asinh(), and ES2 does not. Does that need new hardware? Well, how efficient do you want it to be? “Efficiency” isn’t required anywhere in the GL spec.
I think “arbitrary” would have been a better choice of words than “specific” here. A counter example is a hypothetical vendor who decides to hardware-accelerate vertex processing but implement fragment processing in software. Possible? Yes. Practical? No, at least not unless you have very weird hardware. On balance it’s somethiing that probably didn’t need to be nitpicked over.
Yes, of course practical concerns will end up dictating where to spend engineering resources. And the efficiency of the implementation will affect the success of the resulting product.
I was merely attempting to correct the OP’s misconception:
The OP is free to read the software specifications, and make his own decisions about how much extra silicon to design for asinh(), line stipple, tessellation, glEvalMesh(), border texels, glConvolutionFilter2D(), etc, etc.
Thanks all for your valuable input. I think I have big misconception and a lot to learn before I can reach a good decision on what to improve on the previous hardware if any. Any resources or hints on that would be much appreciated.
Exactly. Reading the specs doesn’t actually tell you the whole story as an implementer. It’s perfect if you’re a programmer but if you want to implement it you can’t just rely on it. So any resources for the implementer, especially GPU one, would be great.
[QUOTE=m.mn3m;1282162]
Exactly. Reading the specs doesn’t actually tell you the whole story as an implementer. It’s perfect if you’re a programmer but if you want to implement it you can’t just rely on it.[/QUOTE]
The specification is the only thing which you can rely upon.
And it’s written largely from the perspective of implementation. As a programmer, it should be the last thing you read, once you’ve exhausted the more explanatory sources and need to know the fine details which they may have glossed over.
The main problem with the specification is that it’s rather large. That and the fact that it’s split into two distinct specifications (the C API and GLSL), which is awkward when you’re dealing with the interactions between the two.
If you’re trying to construct a more concise description, one way to approach it is to look at the state tables (section 23 of the OpenGL 4.5 specification; in general, it’s the last numbered section, before the appendices) then figure out where each piece of data fits into the rendering pipeline.