One working machine proves that a driver can render. A second machine with the same silicon shows which assumptions belonged to the hardware and which belonged to the first laptop’s BIOS.
Earlier we wrote about the Fujitsu Stylistic Q550, an Oak Trail tablet whose GMA600 platform puts a familiar SGX family behind different register offsets and display routing. Alongside that tablet, a second Poulsbo machine has now joined the lab: a Fujitsu FMV-BIBLO LOOX U/C50N, a 5.6-inch pocket convertible.
Where the 12.1-inch Dell Inspiron 1210 runs an Intel Atom Z520 at 1.33 GHz, the little LOOX carries an Atom Z550 at 2.00 GHz, near the very top of the Z5xx Silverthorne line (only the later 2.13 GHz Z560 sat one 133 MHz step higher), attached to the same US15W chipset and GMA500 graphics core. Bringing it up answered two questions at once: whether the driver could cold-boot cleanly on another Poulsbo board, and how much a 50 percent faster CPU clock changes frame rates when the SGX535 GPU stays the same.
Two Poulsbo machines, one graphics core
Both machines use the Intel US15W system controller hub, a 533 MT/s front-side bus, single-channel DDR2 memory and the same Debian 12 i686 installation with a 6.1 PAE kernel.
| Boundary | Dell Inspiron 1210 | Fujitsu LOOX U/C50N |
|---|---|---|
| CPU | Atom Z520, 1.33 GHz | Atom Z550, 2.00 GHz |
| Graphics device | GMA500, 8086:8108 rev 07 |
GMA500, 8086:8108 rev 06 |
| SGX core / revision | 01130000 / 00010201 |
01130000 / 00010201 |
| Built-in panel | 1280 × 800 LVDS on pipe B | 1280 × 800 LVDS on pipe B |
| BIOS display aperture | 0xD0000000 |
0xF0000000 |
The LOOX identifies as Fujitsu FMVLUC50N, with an FJNB1EE board and Phoenix BIOS 1.21. Its internal 1280 × 800 LVDS panel returns an all-zero EDID block and relies on the firmware’s Video BIOS Table timing path on pipe B. That display baseline came up immediately with a 5120-byte row stride.
The first guarded SGX check ended much earlier. The kernel module refused to program the engine before a single 2D or 3D command reached the hardware.
When 0xD0000000 meant two different things
Before kicking a queue, the driver’s engine guard checks the SGX virtual
requester bases. It requires the 2D requester to sit at 0xD0000000, matching
the private SGX MMU virtual window and the per-file 2D scratch page mapped at
that base. On the LOOX’s first guarded boot, the 2D requester register held
0xF0000000 instead, and submission stopped cleanly with -ENODEV and zero
completed jobs.
That value came from a single line inherited from the old probe path. During initialization, the driver read the physical PCI GATT display aperture base configured by the BIOS and wrote that address into the SGX 2D requester register.
On the Dell Inspiron 1210, the BIOS places the physical display aperture at
0xD0000000. Copying that physical base into the 2D requester happened to
produce 0xD0000000, matching the private SGX MMU 2D window by numerical
coincidence. On the LOOX U/C50N, Phoenix BIOS places the physical display
aperture at 0xF0000000. Display scanout and CPU GTT mappings belong to that
physical aperture, but SGX 2D blits do not. The 2D engine translates addresses
through the active SGX MMU page directory, where the 2D window lives at
0xD0000000.
Had the engine guard not refused that state up front, the first 2D blit would
have issued virtual addresses around 0xF0000000 against page tables populated
at 0xD0000000.
Binding the 2D requester directly to the private SGX virtual layout during
probe and reset separated the two address domains. On the next run, the LOOX
reported SGX535 core 01130000 and revision 00010201, locked in the
expected requester bases, and completed 29,909 3D jobs and 34,947 2D jobs
across the qualification suite with no faults, no held resources and matching
reference images.
Same GPU, 50 percent faster CPU clock
Having two qualified GMA500 machines in the lab makes it possible to measure something that single-machine profiling can only estimate: how much of a frame on Poulsbo is limited by the Atom processor rather than the SGX535 GPU and shared memory bus.
The Atom Z550 runs at 2.00 GHz, 50 percent higher than the Dell’s 1.33 GHz Atom Z520. Both processors still talk to the chipset over a 533 MT/s front-side bus, and both machines use the same Poulsbo SGX535 graphics core.
To compare them on equal footing, both machines ran the same November 6 driver
build under the three-repeat windowed benchmark procedure: a 1280 × 800 Xorg
desktop, the ondemand frequency governor and vertical synchronization
disabled, discarding the first five-second warmup interval of each run and
taking the median across three repeats. The earlier November 3 baseline on the
demo pages stays attached to its original Dell build.
Across both 300 × 300 and 640 × 640 windows, the 50 percent higher CPU clock raised 3D throughput by roughly 11 to 15 percent:
| Workload · windowed | Dell Z520 · 1.33 GHz | LOOX Z550 · 2.00 GHz | Change |
|---|---|---|---|
| poulscube, 300 × 300 | 393.4 FPS | 435.9 FPS | +10.8% |
| glxgears, 300 × 300 | 370.6 FPS | 421.5 FPS | +13.7% |
| poulscube, 640 × 640 | 116.1 FPS | 133.4 FPS | +14.9% |
| glxgears, 640 × 640 | 114.7 FPS | 131.2 FPS | +14.4% |
Where the saved milliseconds come from
The per-frame CPU breakdown explains why a 50 percent faster processor produces an 11 to 15 percent frame-rate increase rather than a 50 percent jump.
| Per-frame CPU time | Dell Z520 · 1.33 GHz | LOOX Z550 · 2.00 GHz | Client / Xorg / kernel on LOOX |
|---|---|---|---|
| poulscube, 300 × 300 | 2.68 ms | 2.36 ms | 1.45 / 0.60 / 0.30 ms |
| glxgears, 300 × 300 | 3.44 ms | 2.91 ms | 1.98 / 0.60 / 0.31 ms |
| poulscube, 640 × 640 | 3.05 ms | 2.82 ms | 1.81 / 0.66 / 0.37 ms |
| glxgears, 640 × 640 | 4.05 ms | 3.74 ms | 2.66 / 0.70 / 0.37 ms |
With vertex shading, tiling, fragment rasterization and the windowed Present copy all running on SGX535, the GPU itself sets much of the frame period. In a 640 × 640 window, a frame takes about 7.5 milliseconds of wall-clock time on the LOOX while total CPU work across the application, Xorg and the kernel is under 3.8 milliseconds.
What the faster Atom Z550 does reduce is user-space preparation. In 300 × 300 windows, client CPU time drops from 1.72 to 1.45 milliseconds per frame in poulscube and from 2.42 to 1.98 milliseconds in glxgears, while Xorg’s DRI3 and Present handling drops from 0.70 to 0.60 milliseconds. Kernel submission stays around 0.30 to 0.37 milliseconds on both machines because uncached writes and memory transactions still cross the same 533 MT/s bus.
That curve also shows how close the 2.00 GHz Z550 already sits to the platform’s practical ceiling. When a 667 MHz jump from 1.33 to 2.00 GHz lifts these GPU-paced 3D workloads by 11 to 15 percent, the one remaining Silverthorne bin, Intel’s 2.13 GHz Atom Z560, would add only about 1 to 2 percent more.
The x11perf 2D suite shows the same division between GPU-bound pixel traffic
and CPU-bound Xorg preparation:
| x11perf operation | Dell Z520 · 1.33 GHz | LOOX Z550 · 2.00 GHz | Change |
|---|---|---|---|
rect500, 500 × 500 solid fill |
1,420 / s | 1,520 / s | +7.0% |
copypixwin500, pixmap to window |
861 / s | 933 / s | +8.4% |
shmput500, MIT-SHM PutImage |
861 / s | 935 / s | +8.6% |
scroll500, vertical scroll |
364 / s | 404 / s | +11.0% |
copywinwin500, window to window |
248 / s | 280 / s | +12.9% |
ftext, anti-aliased text glyphs |
978,000 / s | 1,140,000 / s | +16.6% |
Large 500 × 500 solid fills and pixmap blits spend most of their time in the SGX 2D engine and memory bus, moving by 7 to 8 percent. Clipped window copies and small glyph operations spend more time in Xorg on the CPU, and gain 13 to 17 percent from the faster Atom core.
Two GMA500 baselines
With the 2D requester fix in place, the Dell Inspiron 1210 and the Fujitsu LOOX U/C50N now serve together as the project’s GMA500 reference machines. Having both systems makes it easier to separate CPU overhead from GPU scheduling while platform work continues on the Oak Trail Stylistic Q550. The hardware guide includes the two-domain aperture note alongside recent shader and render-target findings.