GP-GPU on SGX

PowerVR Insider
1

Hello,
SGX product sheet refers to GP-GPU tasks potentially running on the USSEs. I’d like to learn more about the software API for such kind of programming. Couldn’t find any reference in the SDK. As far as I understand, GLSL is not general enough for GP-GPU…

Thank you

2

GLSL isn’t really suitable for GPGPU, as you say (obviously you can do some things, but it’s not really dedicated to this purpose). The SGX is eminently programmable and there should be some advance in this area in the near future, but unfortunately the SDK doesn’t support this at the moment. Please check back for further news.

3

Well, it has been a while. Is there any news?

4

Sadly, not yet. There will be announcements and SDK support when there si progress in this area.

5

It has been rather a while now, but is there any news or has this feature been dropped?





Also, has anyone managed to do any useful GPGPU processing using standard GLSL on an SGX chip?

6

All SGX and SGX-MP chips are capable of GP-GPU processing, but currently there are no devices on the market with these GPUs that provide APIs to expose this functionality (such as OpenCL).

When devices are released that provide developers with a GP-GPU API, we will release an SDK to support this development.

7

Thanks for your reply Joe.





What in particular needs to be done to expose such functionality? Would it be a case of a vendor in collaboration with yourselves writing a closed source e.g. OpenCL library (similar to the closed source OpenGL-ES libraries) which would then talk to the SGX* chip through e.g. the Linux open-source kernel driver?





Or, do the chips already support some abstracted “instruction set” that allows them to perform GPGPU computing without needing to know the nitty-gritty details of the low-level operations supported by the chips? If so, any chance of our seeing some details of this?





Thanks,





Simon.

8

Hi Simon,

It would be up to an OEM to expose drivers for a GP-GPU API - such as OpenCL - on their platform. I can't comment if/when these sort of drivers would be available and/or what devices, OSs etc they might end up on.

We don't expose an abstract instruction set or anything similar to this. Other than using shaders with graphics APIs our chips already support, there are currently no other options for performing GP-GPU work.

Cheers,
Joe



Joe2011-11-29 09:32:32
9

Hi Joe,

Don’t worry about commenting on when/if/who, I’m interested in doing it myself mainly, or at least having a go, as it looks interesting (and dare I say fun… ;)).

So you’re saying that I’d need to go back to the techniques used in the original GP-GPU work and use OpenGL calls and structures. That’s fine.

You also say you don’t expose an abstract instruction set, etc., does this mean there is one that is specifically tailored for GP-GPU (as opposed to a generic underlying hw abstraction instruction set/api that is used for all tasks - i.e. OpenGL-ES, OpenVG and potentially OpenCL, and which presumably would never be publicised)?

Thanks,

Simon



10

Hi Simon,



Yup. Your options are to either to stick with desktop GP-GPU APIs for now, or to see if you can use shaders in graphics APIs to do this work.

AFAIK, it's much more likely that a GP-GPU API (such as OpenCL) will be exposed than an abstract instruction set for these operations.

Cheers,
Joe

Joe2011-11-29 15:31:25
11

Thanks Joe.





For anyone else paying attention, I’ll report back how I get on as and when I find the time to do some experimentation.

12

Though not a progress report pre-se, a small group of us have got together to look at reverse engineering the opcodes, will report back when we have a site up.

Slightly related, it’s interesting to see the Lima project looking to reverse engineer the ARM Mali 200/400 GPUs. See http://limadriver.org/ and https://gitorious.org/lima/