- February 17, 2009 at 3:53 pm #29713
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 youFebruary 17, 2009 at 4:14 pm #32761
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.September 4, 2009 at 12:38 pm #32763
Sadly, not yet. There will be announcements and SDK support when there si progress in this area.November 25, 2011 at 12:56 pm #32764
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?November 28, 2011 at 10:10 am #32765
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.November 28, 2011 at 12:46 pm #32766
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?
Simon.November 28, 2011 at 5:45 pm #32767
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.
Joe 2011-11-29 09:32:32November 28, 2011 at 6:26 pm #32768
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)?
SimonNovember 29, 2011 at 9:40 am #32769
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.
Joe 2011-11-29 15:31:25November 29, 2011 at 12:14 pm #32770
For anyone else paying attention, I’ll report back how I get on as and when I find the time to do some experimentation.February 23, 2012 at 9:51 am #32771
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.