Direct (close-to-the-metal) open-source SGX driver

[ldesnogu]

The default bandwidth, latency, etc are normally unchanged. Unless TI changed something in the process ( don't think so ). So far, the information about the 256MB upgrade is limited. Most things like the extra battery drain etc, are pure guesswork, based on doubling the 128's figures.

All information is on Micron site here(link).
Basing on OMAP3530 specs it seems that Pandora team switched memory from 512Mbit (128MB) MT46H16M32LFCG-6(link) to 1Gbit (256MB) MT46H32M32LFJG-6(link).
Both are x32 LDDR333, so memory bandwidth is still 4*2*166M = 1266.5MB/s.
Sadly, for both parts datasheets are not available (but you can send a request). Looking at similar parts (VFBGA package instead of POP) power consumption should be in fact greater. Burst read current in 256MB part is up to 20% greater, but deep power down current is the same... So all depends on usage scenario.

As I like to be off-topic... The new Micron 256 MB chips have been tested on BeagleBoard with OMAP3530 ES3.0 and bring 20% more bandwidth (measured by Mans Rullgard who has highly tuned assembly routines for memory copying, using or not the PLE). This probably is a combination of enhancements to the RAM chips and of revision r1p3 of Cortex-A8.

 

[ldesnogu]

We're currently in organizing phase, and 'in the meantime' we're analyzing aviailable code & documents.

Can you summarize what you already have?

 

[maciek_urbanski]

We're currently in organizing phase, and 'in the meantime' we're analyzing aviailable code & documents.

Can you summarize what you already have?

Agreed, and implemented method of information sharing & doc development, installed & configured dummy source repository, started analysis of control flow inside open-source kernel-part of SGX driver (2D initialization, work submission, etc.).
Some high-level design decisions are yet to be made, shader instruction deciphering will start when we'll get our Pandoras, but fairly large number of information is stored in publicly available source code, so we have our hands full.
If you want to know more - PM me ( and perhaps join in ).

 

[Phawx]

The default bandwidth, latency, etc are normally unchanged. Unless TI changed something in the process ( don't think so ). So far, the information about the 256MB upgrade is limited. Most things like the extra battery drain etc, are pure guesswork, based on doubling the 128's figures.

All information is on Micron site here(link).
Basing on OMAP3530 specs it seems that Pandora team switched memory from 512Mbit (128MB) MT46H16M32LFCG-6(link) to 1Gbit (256MB) MT46H32M32LFJG-6(link).
Both are x32 LDDR333, so memory bandwidth is still 4*2*166M = 1266.5MB/s.
Sadly, for both parts datasheets are not available (but you can send a request). Looking at similar parts (VFBGA package instead of POP) power consumption should be in fact greater. Burst read current in 256MB part is up to 20% greater, but deep power down current is the same... So all depends on usage scenario.

As I like to be off-topic... The new Micron 256 MB chips have been tested on BeagleBoard with OMAP3530 ES3.0 and bring 20% more bandwidth (measured by Mans Rullgard who has highly tuned assembly routines for memory copying, using or not the PLE). This probably is a combination of enhancements to the RAM chips and of revision r1p3 of Cortex-A8.

20% more bandwidth than 1266.5MB/s? So the 256 Config runs at 1519.8MB/s? Can you link the source?

 

[wimomacon]

I am interested to join

 

[phrosty]

If you want to know more - PM me ( and perhaps join in ).

No no, please post here, so any knowledge will be available to people potentially helping later.

 

[maciek_urbanski]

If you want to know more - PM me ( and perhaps join in ).

No no, please post here, so any knowledge will be available to people potentially helping later.

Using forum for detailed discussions about instruction encoding (which itself can fill tens of pages), HW initialization, IRQ-based resource tracking, texture tiling, instruction stream fencing and alike is not a good idea.

Don't get me wrong - project is open source, and high-level information will be posted on forum, but for detailed analysis there are better means of collaboration. Most of people on the forum are not interested in gritty details, and those that are - should join. :wink:

When specs will be usable, both content-, and form-wise, they will be shared with anyone that cares to see them.

In the meantime, lots of analysis to be done, tests to write (and games to play).

 

[ldesnogu]

20% more bandwidth than 1266.5MB/s? So the 256 Config runs at 1519.8MB/s? Can you link the source?

No, 20% more bandwidth seen from the Cortex-A8, that is real life bandwidth not theoretical never reachable bandwidth
BTW, it's slightly more complex than that: cacheable reads are 20% faster, non-cacheable writes are 90% faster (this is very important for framebuffer). It's not known if these improvements come from the newer revision of Cortex-A8 or from the new POPed RAM module (which is known to be faster) ; it's probably a combination of both.

For reference:
- measured bandwidth on es3.0 here
- for the above quoted improved bandwidth, it's a personal mail, so you will have trust me

 

[maciek_urbanski]

(...)BTW, it's slightly more complex than that: cacheable reads are 20% faster, non-cacheable writes are 90% faster (this is very important for framebuffer).

In thread you've shown Mans measured beast-case read bandwidth (PLE+NEON case) as 741113693 B/s = 706.78MB/s
Is this +20% of read bandwidth relative to this case (thus being 848.1MB/s) ?

But back to SGX.

I've started deciphering instructions for SGX 2D engine (it's a separate, dedicated entity for 2D fill/blit operations). And I must say I'm impressed by both design decision and (potential) capabilities of unit.
Separate 2D pipe is very good design decision from power efficiency standpoint. Simple, dedicated 2D blitter does not occupy complex resources of 3D pipes (think tile accelerator, shaders engines), and it should be 'good enough' to perform most tasks required do display OS GUI.
As for capabilities - it can do block fills, pattern fils, 3-parameter raster ops, format conversions (source can be (A)RGB, paletted and even YUV 4:2:2), flip and rotation and many modes of alpha blending. Im not sure if this can be exposed in DRI driver framework, though (if somebody knows - PM me). I didn't found any indication that in can do rescaling, so for stretch-blits we'll have to use 3D pipeline... But it still look very good.

 

[Polossatik]

It might be an idea to update your first post with a little summary on what the idea is and what skills are needed when you want to help out on the coding side and also include in the summary that if / how "non coding" people can help...

there is also a thread on gpx32 reffering to this...

 

[maciek_urbanski]

It might be an idea to update your first post with a little summary on what the idea is and what skills are needed when you want to help out on the coding side and also include in the summary that if / how "non coding" people can help...

Good idea - did that.

And small status update. We're working steadily, some basic 2D functionality exposed in kernel mode driver of SGX535 (bigger part, used in Intel SCH bridge for Atom, early source code is available on the net) has been documented.
In few weeks we'll run out of code to analyze and we hope to get our hands on proper SGX driver for OMAP... They have to release it eventually, right ? If we don't get it - we'll have to wait for Pandoras to arrive (assuming it will contain SGX driver...).
Then - few weeks of gaming, and then again - reverse-engineering fun.

 

[Phawx]

WOO!

 

[cb88]

I have 2 questions...

from what you currently know... does the SGX support GPGPU type acceleration of any form?

is an LLVM backend possible advisable or even desirable? It is being used by apple to implement opengl optimisation and openCL i think... used for the iPhone... you probably know more about it than me with your jit compiler background.

From what I can tell LLVM is poised to eventually replace GCC since it seems from my point of view as a user to have some serious flaws that make optimization in the compiler difficult

 

[maciek_urbanski]

from what you currently know... does the SGX support GPGPU type acceleration of any form?

Currently I know that SGX shader engines have fairly sophisticated instruction set and they might support GPGPU. I have yet to figure out how shader reads it's input, stores it's output and what event creates shader thread. Without this information i cannot honestly say that it will support GPGPU for sure, but I didn't yet found any information that suggest otherwise.

is an LLVM backend possible advisable or even desirable? It is being used by apple to implement opengl optimisation and openCL i think... used for the iPhone... you probably know more about it than me with your jit compiler background.

I'm not sure about LLVM. In fact I'm not sure if going GPGPU on SGX is worth the effort. Don't get me wrong - it's most probably possible, but SGX architecture is very much 'tailored' to rendering-like tasks. I could say that if you have GPGPU algorithm very similar to rendering (coherent input data accesses, low volume of output, explicit parallelism, fixed and space coherent output) - it would be good candidate for SGX, but otherwise - probably not worth it.
For other GPGPU-like code I'd suggest using NEON or DSP.

 

[maciek_urbanski]

Guys - in order to keep the thread alive I've crossed over to the GP32X forum.

It can be found here(link).

Please direct your suggestions/question there.

 

[Svartalf]

Link's gone on the board...not sure why.

 

[maciek_urbanski]

Link's gone on the board...not sure why.

There's a risk, that this project may have negative impact on relations between Pandora team and Texas Instruments.

In effort to reduce risk I'll move this effort to my private site.

I'll provide specifics when I'll finish configuration of my local forum.

For now - just be patient. :wink:

 

[timofonic]

Maciek, any news? Please post an update when you have the site ready, I'm curious at looking the progress effort.

You can send me an email when the site is running too

 

[cb88]

you could just use my forum? I can setup a private area... and you wouldn't be associated with any official pandora sites.. since it is just my personal forum and nobody is ever on it

cb88.freeforums.org

 

[maciek_urbanski]

Hi guys.

Sorry for not updating you all for a while, but be sure that reverse engineering is going strong.
For a reasons described in my previous post I cannot tell you specifics, but in this week my private forum should be configured well enough to let you all in.

cb88 - thanks for your offer, but I have my private site, and forum is already pre-configured. There are still some kinks in th scripts, because I've used very young - but pretty - forum, and I still need to fix some bugs.
But I must tell you this - most of guys implementing PHP forums should go back to school. <_<

For a teaser I can tell you that I have all data that makes complete SGX specification just a matter of time.

Soon enough I'll be blocked by lack of Pandora...