Hello,
I’m writing regarding the PowerVR SGX 535 used in the Intel GMA 500 (Poulsbo platform).
I know this hardware is quite old, but there are still a few people maintaining Atom Z500 Series devices (like the Dell Inspiron Mini 10 and similar systems). On Linux, support is limited to basic display functionality through the gma500 driver, and there is no usable 3D acceleration due to the lack of public documentation.
I understand there may be licensing agreements between Intel and Imagination that prevent releasing full drivers. However, I wanted to ask:
- Is there any technical documentation for SGX 535 that could be shared today?
- Even partial architectural information?
- Or any guidance about whether legacy documentation might ever become public?
This is mostly for preservation and educational purposes. Many of these devices still function perfectly well except for graphics support.
I appreciate your time, and thank you for maintaining this forum.
I also reached out to Intel engineers through their official community forums regarding the GMA 500 (Poulsbo) and the SGX 535 driver situation.
The response I received was that any questions related to the 3D driver stack and GPU documentation should be directed to Imagination Technologies, since the core graphics IP was licensed from PowerVR.
This suggests that responsibility for the platform was historically divided between Intel (integration and product delivery) and Imagination (GPU IP and associated components), which may explain why documentation and long-term driver support became difficult to access publicly.
I am sharing this for context, as there still appears to be some interest in understanding the technical and historical aspects of this platform.
Poulsbo ! 
I don’t know if many at IMG now would even have heard of it. I’m not sure who to even ask.
It’s funny how this GPU is almost 20 years old yet there’s still occasional news about it, even the Linux driver received updates in recent kernel versions
It was part of my childhood so even though it’s very old hardware now, I still use it occasionally when i’m away from home etc
I didn’t work directly on it, but I have a very foggy, and thus probably unreliable, recollection that Intel might have written their own drivers for Atom’s 535.
1 Like
Hello! I did an intense search for 4 days and found some previously unpublished material related to the SGX535 on Intel Poulsbo, including historical DDK code, SGX535-specific definitions, and traces of an explicit Poulsbo integration that had been removed from later source trees. I’m now organizing and cross-referencing everything with the modern Linux gma500 driver to reconstruct as much technical documentation as possible: github: github (only docs for now)
(It’s actually in Portuguese, too)
Some links are broken because they point to reference files from my workspace, so I’ll be rewriting the documentation soon to fix this.
Intel really did create its own drivers for the SGX535 through EMGD! Your answer really helped me dig deeper into the SGX535. Thank you!
1 Like
It seems I’ve reached the point where there is no more public documentation to be found on the internet! Even with AI-assisted search, I couldn’t find any further files online
Unexpected things happened, LOL. Two hours after I said there was nothing left publicly available on the internet, I ended up finding old Poulsbo Linux packages that preserved key parts of the original graphics stack, including psb_dri.so and Xpsb.so. Since then, I’ve started performing static analysis on these binaries and comparing the results with historical code from the Xorg driver, libdrm, and the PSB kernel. I’m not executing these binaries or sending commands to the GPU; for now, the work remains purely static analysis (though we’ll likely see a triangle rendered in the coming days I HOPE). One of the most interesting discoveries was that psb_dri.so itself contains an internal USC/USSE compilation path. My earlier claim that there was “no more public documentation available on the internet” didn’t age well at all. 
(It was a matter of just two hours.) Still no driver yet, unfortunately.
Well, it happened 
The SGX535 finally drew a triangle.
After around 20 days of reverse engineering Poulsbo / SGX535 rev121, I now have the first established triangle from SGX535-reMESA.
The successful run produced a 32×32 readback with:
- 120 pixels exactly
0xffff00ff
- 904 pixels exactly
0x00000000
- the expected triangular footprint
- TA completion confirmed
- end-render confirmed
- 3D-memory-free confirmed
- retirement confirmed
- response, operation evidence and readback all attributable to the same operation
The important part is that this isn’t based only on seeing the completion bits and assuming rendering worked.
My previous run actually reached TA completion, end-render, 3D-memory-free and retirement successfully, but returned a completely zeroed 4096-byte color buffer.
For the next experiment I kept the rest of the qualified rendering setup unchanged and replaced the suffix-only fragment program with a constant-color diagnostic program, expecting opaque magenta (0xffff00ff).
And this time I got exactly that: 120 magenta pixels forming the expected triangle.
So:
triangle established
The next step is getting those pixels out of the qualified GPU-memory/readback path and onto the actual display. I’m currently mapping the gma500 framebuffer/scanout path and preserving the successful FIRE #3 configuration as a reproducible milestone.
I’ll put the successful triangle work, documentation and reproduction details on GitHub soon as well, once I’ve cleaned everything up enough that someone other than me can actually follow it
It’s slightly ridiculous how much archaeology was required to convince a 2008 GPU to draw three vertices, but here we are.
Also, thanks @SimonFenney for the help
Nice
BTW, assuming the following isn’t from you, one of my colleagues saw this on LinkedIn:
(Basically someone else doing SGX dev)
Might be worth teaming up?
Thanks Simon! That isn’t me. I hadn’t seen René’s work before. Very interesting that he’s working on SGX/Poulsbo too. I’ll reach out to him, comparing notes could definitely be useful since I’ve been approaching the SGX535 from the reverse engineering/documentation side.
For now, while I figure out the next steps towards a Mesa driver, I’ll also try adapting the old proprietary driver to a modern kernel.
It will probably be a lot more problematic, though, since even the original Intel driver didn’t contain enough information to fully reconstruct some parts of the GPU’s behavior. One example was 0x07000345: I eventually had to make an educated guess based on the evidence I had, and it turned out to be correct. It also gave me some serious dark circles under my eyes, I swear I dream about that DWORD now
