Program Epiphany to act as a GPU

[Terra854]

Hello there.

Just wondering though, is it possible to program the Epiphany SoC so that it acts as a GPU that is OpenGL as well as OpenCL/OpenMP compatible? I am thinking of improving an ARM64 SBC so that it will have a vastly improved graphics and floating-point performance while at the same time, maintain it's low cost.

(It's like Nvidia Geforce with the FP64 capability of Tesla)

[sebraa]

No. The Epiphany simply does not have enough memory for OpenGL usage. OpenCL is available, though.

[Terra854]

What about OpenGL ES? Is it possible or it cannot be done due to the memory constraint?

[sebraa]

The Epiphany can't store a single uncompressed 400x400 RGBA texture in its total internal memory. If you want a GPU, buy a GPU.

[jar]

GPUs do not store large textures in their internal memory either, but they benefit from high bandwidth off-chip memory and specialized texture memory caches. You could hypothetically create an OpenGL implementation for Epiphany using off-chip memory, but it's not a great idea. If you were building an SoC, you would probably use some other GPU IP, not Epiphany. Intel tried pulling off a software defined GPU with the , but it turns out that specialized hardware for specialized tasks (graphics) is a more effective model.

With that being said, you could still have very interesting software-based graphics for Epiphany that does something cool. For example, ray tracers, procedural textures, and other rendering techniques can be developed if you have the time, interest, or need (Larrabee had some cool ray tracing demos). But writing an OpenGL implementation for Epiphany means you're trying to compete with specialized GPU hardware that was built to support OpenGL. It's a nonstarter.

[mchampigny]

Incidentally, an OpenGL driver was once built for the IBM Cell:

http://www.mesa3d.org/cell.html

The Cell had a similar architecture to the Epiphany but had a very high bandwidth bus to external memory and larger local stores (256K) on the SPUs (the equivalent of the RISC cores on the Epiphany). The Cell also had a small atomic DMA cache (only 4 lines) which could be used for low latency synchronization between the SPU cores and the PPC host CPU. I think the same tiled rendering model could be used to offload rendering/shading to the Epiphany but I doubt it would be as capable as Cell for the reasons I outlined.

If anyone would like to take a crack at implementing a hardware accelerated render pipeline, the Gallium code and Cell driver are probably a good place to start.

[dobkeratops]

GPUs are so widespread that you should seek out a GPU if you want graphics

Tangentially, my own armchair speculation:
I think the epiphany architecture could serve a good purpose in a graphics pipeline for vertex & geometry processing, if wired up correctly in an SoC. (e.g. think of tessellation & transformations). it could also handle most 'GPGPU' type roles better (e.g. GPUs are used to accelerate game physics).

My 'dream system' might be a cpu, e-cores in the middle, and GPU cores, all with on chip communication. The PS3 CELL was supposed to be like this, but in the end it didn't pan out because they clumsily retrofitted a traditional GPU without on-chip communication (making the potential vertex-processing power of the SPUs clumsy to use, requiring communication via main memory).

I'd be curious to know what kind of enhancements the latest Epiphany 5 has toward machine-learning (I think it has 64bit registers and 2x32bit Float SIMD ?) If it has further reduced-bit arithmetic SIMD capability (e.g. 8x8bit in one 16bit register) maybe it could better suit vision and graphics applications ..

[mchampigny]

Intel is already taking the heterogeneous processor cluster approach on a die by integrating the Altera FPGA fabric on the SoC along with GPU cores. I believe all of these share a unified virtual address space at least for on-chip memory. See Stellarton for an early example which used an Atom core with Arria fabric.

I think you could at least simulate this configuration on the Parallella by reprogramming the Zynq FPGA logic as a soft-GPU using one of the open source GPU designs that are floating around. But you still have the problem of lack of memory bandwidth and I believe you might not have room for the GPU after taking into account the e-Link IP.

It would be a fun student project though.

[CarstenT]

Hi all,
I just got an epiphany 111 as my christmas-present .. and I'm getting the feeling that I've got more than I've bargained for.
One of my joys are programming opengl graphics, and it was with this in mind, that I bought the board.
Opengl is a hardware-driver. If there is no graphics-card, like at my win7 asus, the "graphics-card" is emulated on the cpu.

raspberry pi & its linux-distribution can use one of the minor named subsets of opengl (es 1 or 2). That means that it (raspberry) interfaces with an opengl hardware-driver.

Are you telling me that ubuntu get it's image on the screen from anything else but opengl?
In case not, how does it produce an image on the screen? It's this question that makes me pop my message.

About gpu memory .. it's a minor issue. Give me two triangles ..
The virtue of modern Opengl is, that it utilizes parallelism when running .. it's a server/client model. The more cores, the faster it digests.
Anyway, if parallella is born as such a perfect communicator between cores, couldn't it be extended with a graphics-card or 'video-memory', whatever that exactly is in this context.

cheers

[jar]

OpenGL is a graphics software interface and the generic interface doesn't care about the underlying hardware. The Parallella board does not have hardware GPU and nobody has written an OpenGL backend for Epiphany.

If you're seeing a display with your Parallella board, it's because the CPU is rendering to the frame buffer. If you're interested in computational graphics, I will point you to one code that I've ported: https://github.com/jar/c-ray-1.1-coprthr2

There are also many other graphics examples here: https://github.com/parallella/parallella-examples

I would encourage you to look into computational graphics beyond just the OpenGL interface. It can be fun and interesting.