Sgx Clock & Shader Execution Speed

[TomCooksey]

I was wondering, what clock speed does the SGX run at? Reading what little info I could find, it seems the SGX has basically 2 clocks: One for the interface (I assume this is the memory bus?) and an internal clock. The internal clock is derrived from the interface clock via a multiplier. So, does anyone have any idea what a) the interface clock is, B) what the multiplier is and c) what the final SGX internal clock will be?

This leads me onto the second question...

What's the relationship between clock-speed and shader execution speed? I realise this is probably a very complex topic, but I'm curious what the architecture is. Looking at the block-diagram, it seems the SGX has multiple execution units - does anyone know how many the OMAP3530's SGX has? Do these execution units execute 1 shader instruction per clock cycle?

Assuming the tile-based defferred rendering magic is perfect and there's no transparency, there will be one fragment being processed per pixel on the screen or 384000 fragments being processed per frame. If we know the number of clock cycles each shader instruction takes to execute, how many instructions are in our shader program and we know how many execution units there are, surely we can work out a ball-park figure for how fast the thing is?

 

[TomCooksey]

Bump?

Anyone know anything about the SGX?

 

[argor]

Bump?

Anyone know anything about the SGX?

try asking here http://forum.beyond3d.com/forumdisplay.php?f=63

 

[Adventus]

I don't think many of the answers to these questions are available to the general public. The best we can speculate about the SGX has already been discussed in this thread:

http://www.gp32x.de/board/index.php?showt...42277&st=80

QUOTE
Looking at the block-diagram, it seems the SGX has multiple execution units - does anyone know how many the OMAP3530's SGX has? Do these execution units execute 1 shader instruction per clock cycle?
I don't know how many execution units it has, but we do know each USSE has 16 threads. Each unit is also SIMD, so their not 100% equivalent to conventional shaders. According to dmdm (one of the SGX designers) taking into account data hazards each USSE should manage about 1 instruction per clock. The SGX has 2 USSE.

QUOTE
Assuming the tile-based defferred rendering magic is perfect and there's no transparency, there will be one fragment being processed per pixel on the screen or 384000 fragments being processed per frame. If we know the number of clock cycles each shader instruction takes to execute, how many instructions are in our shader program and we know how many execution units there are, surely we can work out a ball-park figure for how fast the thing is?
Yea i did one of these in the linked thread:
QUOTE

1 [instruction/cycle] * 2 [USSE] * 200M [cycle/sec] = 400M [instructions/sec]
400M [instructions/sec] / 30 [frame/sec] = 13.33M [instructions/frame]

Guessing maybe a third of those instructions will be neccessary for vertex transforms (~120,000 tri's @ ~12 instructions per transform) . Your left with:

8.89M [instructions/frame] / 384 000 [pixels/frame] = ~ 23 [instructions / pixel] @ 800x480
8.89M [instructions/frame] / 96000 [pixels/frame] = ~ 92 [instructions / pixel] @ 400x240


I assumed a 200mhz clock rate, which may or may not be completely wrong.... its what ImgTec use anyway.

 

[TomCooksey]

This kindof maps to what a collegue of mine told me: ~6 instructions per fragment to achieve 60 fps.

Thanks for the link, I'll have a read through.

 

[Exophase]

I think the default clock speed is 90MHz, but can go as high as something like 160MHz. I haven't heard about it going all the way up to 200MHz on OMAP3530. One thing to bear in mind is that despite being billed as SIMD shaders these are still 32bit, meaning that you aren't going to get 4-way floating point SIMD operations out of this. The best you will get is 4-way 8bit operations (for color calculations), which is good for pixel shaders but less so for vertex shaders. If you need as much pixel shading as possible then you should probably use NEON instructions for vertex processing.