OpenHandhelds.org

This post is edited to provide up-to-date summary of project.

Issue:
Programmable graphics accelerator contained inside Pandora CPU, called SGX is effectively closed-source product. There's no detailed HW specification, description of internal architecture, instruction set or data structures. Driver for SGX contains two parts - open-sourced kernel-space driver (kmd) which contains some basic 2D functionality and is able to pass-though commands to SGX. Second, closed-source part is a user-space driver (umd) that exposes standard OpenGL ES interface to applications. These applications issue OGL ES calls to 'umd' which get compiled into commands and data structures and passed to 'kmd'.
Since all complex work is done on closed-source 'umd' part we cannot easily analyze it for sake of optimization fixing bugs and improvement.
Additionally - HW has more capabilities that OpenGL ES is exposing, limiting both creativity and performance.

Solution:
In this project, unofficially called 'libsgx' we want to decipher and describe inner workings of SGX, its instruction set and all data structures and algorithms necessary to directly access SGX capabilities bypassing closed-source 'umd' driver.
The result of this process will be detailed documentation and sample source code that would allow developers to implement full standard-compliant OpenGL/OpenGL ES driver, or interface to SGX directly. Side (read: optional, secondary) result would be creation of paper-thin API making interfacing to SGX easier.
This project will not result in creation of OpenGL/OpenGL ES driver itself. It will provide basis for other to do it.

How you can help ?:

• If you are programmer with strong 3D knowledge and Linux background (kernel driver development is a plus) - we'll find something interesting for you.
• If you are non-programmer, but do not afraid of some tinkering (like replacing a kernel with custom one) and lots of testing - we'll have some tests to run and data to collect (when or Pandoras arrive).
• If you have some information (documents, specs.) that you can legally share on SGX (and SGX only) - please share them (PMig me will do).

Legaility:
All the signs suggest that reverse-engineering for sake of improved compatibility, performance and functionality is legal in European Union. In fact, you can find 'legal' commentary and link to EU directive in thread itself. If you're not in EU - you should verify it yourself.


Before submitting questions I encourage to read through this thread before submitting questions (they may already be answered).

And thanks for great input so far!

previous contents:

Hi guys.

I'm thinking about designing paper-thin API to access SGX directly. The chip itself is DirectX 10.1-capable, but for Linux only closed-source OGL ES driver is available (without any 'fancy' extensions).

Driver would allow using SGX to the maximum of it's capabilities, and would be nice baseline for more high-level API...

This of course means that I must either get behavioral specification of SGX or reverse-engineer it. If closed-sourceness of OGL ES driver is any indication - I'm assuming that my questions to Imtec about those docs will not be answered...

I'm capable of reverse-engineer SGX (I'm programming similar architectures on daily basis) - but it would take large amount of time (think 1y+ with community help).

So my question to you all is: Do you feel it's worth the trouble ?

Of course it's worth it!

I wonder how much progress other developers have made with reverse-engineering the SGX/MBX, but such a driver would be valuable not only because it would allow linux to utilise the graphics hardware, but also other operating systems, such as the *BSDs... While I'm fairly comfortable with C/low-level development, the prospect of reverse-engineering seems a bit daunting for a single person. So I'd be happy to work with you on that one

Guy form Imagination Technologies has responded to my query about docs here(link). A I was expecting getting those docs is impossible.

I'm trying to determine how ImTech will respond to reverse-engineering SGX... I don't want to find myself (and others) in the middle of legal battle...

vladimir: every bit of help would be greatly appreciated

What you're suggesting is to basically expose the low level interface details of the SGX to everyone, right? It's natural that you won't get the docs legitimately (or else everyone would get them) and I doubt you'll make it very far reverse engineering something so complex. Especially considering the shaders which I'm sure have some kind of specific protocol for uploading code to.

I think you should ask yourself honestly what real purpose this will serve. It's a basic assumption that it'll give you more power and flexibility, but that's all that it is, an assumption. I think before really considering this you should have a more specific pragmatic reason to go about it.

Right...

I would guarantee you that if you try to do that kind of reverse engineering work, you will probably get into deep shit with ImgTech.

The graphics accelerator market for mobile is very hot right now.
ARM is putting a lot of effort in it. ATI also, NVidia also, Qualcomm too...
Read between the line that there is a big fight for the money here.

By putting the inner guts of the hardware into a public place,
I would say it not something good for the community right now.

Seen from TI, it is a troublesome sales, 5,000 to 15,000 chips sold and...
Well, they sell MILLIONS of these to phone makers and would have less trouble.

For now, wait and see... First I would like to see the ES 2.0 drivers.

My 2 cents,
Laxer3a

Yup, that's it.


I was thinking the same, but for sake of completeness (not to mention good manners) I ought to ask. And I did.


Why do you say so ? If it's too complex for you - don't attempt it. Sorry, I don't mean to be rude, I just know what I'm talking about. It's not complex - it's just extremely repetitive and very time consuming.


I could think of few:

1. ability to program GFX HW directly allowing:
   
   • geoemetry shaders
   • hull, evaluation shaders
   • raycasting/raytracing
   • general GPGPU algorithms
   • volumetric effects
   • ...and whatever you like, really
2. basics for open-source OpenGL ES implementation [with useful extensions]
3. learn a thing or two in the process

Everything is assumption until somebody proves it.


Ok. Reason: learn something new.

Damn... this is a long post.

I hope not, but I asked them if this would be problem. Let's see what they'll say.


Why ? Better drivers, more 'hype' means more units sold for them... And custom API would never be threat to OpenGL ES, so their SW division should not feel threaten... And I have gut feeling that competition has tools to get those information anyways...

BTW, THX for the input Laxer3a

AFAIK, if you are in Europe and you do clean room reverse engineering then its perfectly legal.

If not, then I am somewhat screwed. :p

An Open Source driver would be fantastic! Building an OpenGL 2.0 library on top of it would greatly ease porting other apps to the Pandora.

I'd help but I only have experience programming Windows drivers :/ If you can abstract stuff away from the OS, it would be even cooler.

Hmm - I went looking for the legal base and I found this(link).

Council Directive 91/250/EEC of 14 May 1991 on the legal protection of computer programs, Article 5 (Exceptions to the restricted acts), point 3. states:
The person having a right to use a copy of a computer program shall be entitled, without the authorization of the rightholder, to observe, study or test the functioning of the program in order to determine the ideas and principles which underlie any element of the program if he does so while performing any of the acts of loading, displaying, running, transmitting or storing the program which he is entitled to do.

So if I observe PowerVR GFX driver by means of running it and repetitive testing in order to determine principles how it programs HW - it's legal. I'm entitled to do it.

Isn't is great to live in EU ?

It would be nice of one of you guys could confirm/decline this findings...

THX andy_js.

in short - yes. but let me elaborate:

aside from all possible es-unexposed hw functionality an oss driver could offer, it can also be used as a foundation for a full-fledged gl 2 driver (an early version already exists for the intel menlow) which, in itself, is impotant leverage in getting desktop gl-based ports. more importantly, an oss gives the oss community a long-term assurance in the architecture, so if tomorrow imgtec decided to discontinue the part (hypotetically), it won't put the open pandora community in check. /beos experience

Hi blu and THX for great input. Can you point me to repository containing this driver for Menlow ?

No, I'm not interested in reverse engineering a piece of hardware like this. But I'd like to know exactly what credentials you hold that allow you to think that reverse engineering a modern GPU could not be "complex." Because from where I stand I have yet to see anyone release any reversed drivers for any of the 3D accelerators nVidia or ATi have made for the past several years.



"Whatever you like"? Yeah, if the hardware supports it. Most of your suggestions to generalize the shaders are pretty silly given that there are only two shaders and they're not even proper VFPUs. The raw computational power is very limited compared to any desktop graphics cards released in the past 4+ years. Any hard coded features that are present in silicon but are not in OpenGL ES 2.0 will surely be exposed in extensions. I can't imagine that ImgTech wouldn't want anyone to be able to use them.

Basics for an OpenGL ES implementation - don't you think it'd be much easier to do that on a platform that already has open source specifications, or even better, already has open source OpenGL drivers? Besides, you said you want to open the raw hardware directly, not write OpenGL ES drivers.

Learning a thing or two? What is there to learn for someone who already doesn't consider the process complex??



Thanks for taking what I said completely out of context to make a pithy (but generally inaccurate) proverb out of it. Generally it helps to have a good reason to go forward in doing something, rather than do it to prove lack of a reason.



I'm sure there are a lot of other potential new things to be learned still available >_>



Wow, okay, if your reasoning held water then hardware specifications would be made open all the time (when they almost never are). No, the competition does not have tools to get low level information in the way you propose, but even if they did, I'm sure there are chip developers in China who would love to ripoff a GPU design without having to go through that kind of hassle.

Their software division being threatened... their software division exists to support their hardware division. I'm not even aware of them licensing drivers. They want people to buy their hardware, not a clone which can be cheaper because it circumvents lots of R&D money.

We are all entitled to our own opinions I'm not so sure why this is turning into a debate about whether having open-source drivers for previously closed-source hardware is a good idea or not...

Generally speaking, shouldn't hardware just provide an interface generic enough to implement a set of standards, without revealing the innards and design of the hardware? You don't exactly see AMD or Intel giving out the design to their CPUs, but they do give excellent documentation... I don't see why the same logic can't be applied to GPU makers. Of course, ATI is ahead of NVidia in terms of having fully open-source drivers for some of its chipsets, but that is just not enough! Exophase: I think you've heard of http://nouveau.freedesktop.org/wiki/ ?

this i cannot do, as i am not even aware if that driver is actually publicly available. i can tell you who's behind it, though - tungsten graphics, who've been traditionally covering intel's bare ass on the linux gpu front. with that i believe i pretty much exhaust my disclosure freedoms. i'd advise you to contact tungsen, if they are willing to cooperate then great.

@Exophase:

i don't really understand your position on this subject. or did you just get off the bed the wrong way?

Sorry, but I cannot give you even scent of hint 'what's my credentials'. It's strictly forbidden and I'm ony a corporate ant... In other words - too afraid to be trampled by legal depratment.
Anyways - why do you care ? If task will be too hard - no harm, no foul, and nobody the wiser. If it succeeds - everybody (interested) might benefit from it.


Yup, but we're not talking about desktop graphics. And if you download OGL ES 2.0 Emulator from PowerVR Insider SDK you will not see them geometry shader extension... (even if your HW has it).


Yes, it's easier.


Yup, I want to create API that would allow to access HW directly. But maybe somebody else will use it to write open-source driver. Sadly I cannot participate in this effort, because I'm writing graphics JIT compilers in my current job and it would be collision of interests.


I don't intend to learn the process. I know the process. I'm intend to use (mundane, and not very complex) process to learn how to program this very nice piece of HW.
And - simple things are the most interesting ones. (That's ZEN for 'ya).


So - it's obvious now, that English is not my first language, huh ?
But joking aside. If you don't like my reason, if you think that I 'prove lack of reason' - you're entitled to.
But maan, I just don't care.


I've always wanted to learn to play sax...


I just want to determine behavioral specification... It has nothing to do with GPU design.

I'm fairly relaxed, tongue-in-cheek person, and make jokes from everything (primarily myself). I know that it can hard to take on some more 'intense' individuals. But so be it.

The most intriguing part is why developer like you (or maybe this(link) is not yours ) would want to discourage me from writing low-level API to access fairly powerful GFX chip on platform we both like...

Anyway, THX for the input Exophase.

edit: there was rather heavy freudian slip... edited-out

Sorry if you feel like I'm discouraging you - if you want to give it a shot then by all means be my guest. If you manage to succeed then it will be a worthy and useful accomplishment. I just think that the work to value profit is very low... I'm a software developer, but I tend to prefer working on things that I think there's a genuine need for. A lot of other programmers do not need to fulfill an external need by programming. In this case, maybe you can do both. I just think don't expect very much to come of it, but please prove me wrong.

A waste of time imho..

Imagine trying to write code based on your API ... with 50% of features being in "experimental" state, half-implemented and basically based on guess work ... that would make for some seriously stressful coding sessions…

Thanks, but no thanks, I will stick to OpenGL ES.

I would say, as long as something positive came from this, you should do this...provided it's legal.

If the end result from all this work is:
(the current situation we are in now) + (More Features/better performance/ease of development)

That's good

If the end result from all this work is

(the current situation we are in now) + (More features) - (better performance)

I probably would not elect to use it.

What I do when I install ubuntu and it asks me if I want to download the closed source drivers, I do so because the performance is better. Bottom line is if its somehow better, I don't think it should be a question if you should do it. More: If you are allowed to do it, What are you waiting for?

I'm waiting for my Pandora to arrive, of course.

...but I'm not sure if it will be easier to program. It should be good base for some more 'friendly' utility library (think GLUT).

THX Phawx.