Dear Experts,
I have some basic graphics questions here, my interest is basically with ARM MALI 400 MP2.
Please provide your inputs
3 . Does the GPU works like some state machine processing the commands generated by OpenGL/ES APIs? 4. Does Mali 400MP has any Instruction-set like ARM Cortex CPUs? I think few GPGPUs have like NVIDIA, ATI/AMD.
5. What happens to Shader programs after they gets compiled? the compiled out put is some instructions for Shader-HW? Or some commands OR what ?
6.How the parallelism is achieved in ARM MALI 400 MP GPU? Does it because we have multiple Pixel processors?
I am not interested with GPGPU or GPComputing , Interested only Graphics content rendering case. I am trying to understand how GPU is performing better than CPU for graphics content creation? does GPU do some SIMD instruction execution like DSP?
Thanks,
Ravinder Are
The "conformance tests" are the official tests from Khronos which you have to pass to be able to say that a GPU supports OpenGL ES, etc. A conformant GPU passes all of the conformance test suites.
HTH,Pete
OK, so hardware-wise there is no such thing as any kind of special tailored API support? Or how much do the HW design guys build th GPU towards the needs of OpenGL ES? I don't have any background knowledge on this but I'd like to understand how the OpenGL ES standard itself is considered when such a design is made?
Not sure a forum post can give you a good answer here - your question is basically "how do you design a GPU?" which is literally a topic that fills many books . To get you started I would highly recommend this book:
It's one of the few books which includes any detail on GPU hardware (including a Mali-based case study).
HTH, Pete
No no you don't get my point. I don't care about the insights of GPU design. I want to know if the Mali GPU was tailor towards the needs to support OpenGL ES? What can a GPU do to pass the "conformance tests"? I thought any GPU could be interfaced using OpenGL ES independent of its design.
What can a GPU do to pass the "conformance tests"?
Implement the specification correctly.
I thought any GPU could be interfaced using OpenGL ES independent of its design.
Most GPUs are designed to meet the specifications they need to support (OpenGL, OpenGL ES, OpenCL, DirectX, etc). There is no point having hardware exposing features the APIs don't support, and a GPU which doesn't do what the specifications require isn't usable.
You can't really separate the GPU design and the API specification - one is built to meet the needs of the other.
Peter Harris schrieb:You can't really separate the GPU design and the API specification - one is built to meet the needs of the other.
Peter Harris schrieb:
Thank you, that is what I was looking for.
I guess my assumptions where considerable in the beginning of openGL, where the HW was released before the first version of the API.
Anyway, this topic is now clearer to me!
Peter Harris wrote:There is no point having hardware exposing features the APIs don't support
Peter Harris wrote:
There is no point having hardware exposing features the APIs don't support
I would just add that when the hardware supports functionality which is not exposed through the core GLES API, we and other vendors do sometimes expose new features via extensions, which are published and available at Khronos OpenGL ES Registry. Some of these extensions are vendor specific, while others are supported by multiple vendors.
Hth,
Chris
I'd add too that the GPU is also used more and more nowadays as a compute engine as well as for graphics. The requirements for things like OpenCL mean that for instance floating point is now IEEE conformant whereas when they were only used for graphics many GPUs did not bother doing rounding in accordance with the standard. This also provides extra impetus to the drive for memory coherence as in HSA between the GPU and the CPU.