PowerVR SGX 535 (Intel GMA 500 / Poulsbo) – Any Documentation Still Available?

Uncategorized
1

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.

2

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.

3

Poulsbo ! :open_mouth:

image
image240×143 56.5 KB

I don’t know if many at IMG now would even have heard of it. I’m not sure who to even ask.

4

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

5

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
6

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.

7

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
8

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

9

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. :slight_smile: (It was a matter of just two hours.) Still no driver yet, unfortunately.

10

Well, it happened :smiley:

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 :smiley:

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 :slight_smile:

11

Here is the proof

IMG_20261006_040949
IMG_20261006_0409491920×1442 300 KB

1 Like
12

Nice :smiley:

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?

13

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

14

yo Simon, there’s one more thing I wanted to ask about René’s SGX535 driver

I checked T2 Linux’s original patch (SVN r96340), and it explicitly references the “vendor’s own DDK”, including sgxdefs.h:8865, 3d.asm:714-776, and sgx_utils.asm:2390-2560.

What caught my attention is the provenance of those files. Some SGX5 DDK sources have circulated online with unclear licensing histories, and I know there’s been concern about using such material in open-source driver development.

Since I’m developing reMESA independently, I also want to make sure I don’t accidentally introduce code with questionable provenance

Do you know whether those particular SGX535 DDK sources were officially released for public use?

15

sgxdefs.h:8865, 3d.asm:714-776, and sgx_utils.asm:2390-2560 is all leaked files

16

A little update on the SGX535-reMESA project :smiley:

Things have been moving pretty quickly since the first hardware-rendered triangle. I’ve now managed to get a real triangle rendered through the Mesa Gallium path on the SGX535, with the GPU doing the actual rendering and the resulting pixels matching the expected output.

I’ve also been working on NIR support and putting together an OpenGL 2.0/2.1/3.0 capability matrix to figure out what the hardware can actually handle, what Mesa might be able to emulate, and what simply isn’t supported.

OpenGL itself isn’t working yet, though. I’m currently dealing with vertex shaders and some missing state handling before I can get a proper OpenGL context running. OpenGL 3.0 is more of an ambitious experiment than a promise at this point.

Still a long way to go, but seeing actual GPU-rendered pixels come out of this thing without relying on Imagination’s proprietary driver stack has been pretty satisfying.

Hopefully I’ll have something more interesting than a triangle to show soon. :slight_smile:

17

Just a small update on my investigation into T2 Linux’s SGX535 driver

As I mentioned here about two weeks ago, I managed to recover some historical Intel Poulsbo Linux packages containing psb_dri.so and Xpsb.so.

I still had those packages, and while going through them again, I found the original COPYING file distributed with xpsb-glx.

The license identifies Intel Corporation and Imagination Technologies as copyright holders and explicitly states:

> No reverse engineering, decompilation, or disassembly of the Software is permitted.

It also restricts redistribution to unmodified binaries and prohibits redistribution under different license terms.

This caught my attention because T2 Linux’s original SGX535 Mesa patch (SVN r96340) contains comments explicitly describing parts of its Xpsb replacement as transcribed from the disassembly of Xpsb.so.

The patch also states that a 440-byte GPU shader image was extracted from the original binary and reproduced verbatim in the source code.

I verified that my local copy of the patch matches the original SVN revision exactly using SHA-256.

Combined with the SGX5 DDK references I mentioned in my previous post (sgxdefs.h, 3d.asm, and sgx_utils.asm), this raises additional questions about the provenance and licensing of some parts of the implementation.

For clarity, I haven’t established whether the exact Xpsb.so binary referenced by T2 was covered by this particular license, or whether any additional permissions or legal exceptions applied.

I’m sharing these findings for transparency and documentation, not as a claim of proven copyright infringement.

18

After days without sleep, insomnia, red eyes, deep dark circles, irregular sleep patterns, and mental confusion, I discovered that 0x07000345 means: ALWAYS (yes, that’s all) This is a PDS execution condition; the USSE compiler is almost being completely exposed!

and with a Galaxy Tab S7 (without root lol)

19

yo Simon, there’s one more thing I wanted to ask about René’s SGX535 driver

Sorry, I’ve not looked at the code - got enough on my plate at the moment!

20

No worries, Simon!

I’ll keep posting updates on SGX535-reMESA here, so you can catch up whenever you have some free time.

Thank you so much for giving me that tip about Intel EMGD, we’ve already got the first experimental driver!