Hi, Following up on my SGX535 render architecture RFC.
Since the original RFC, the experimental implementation has demonstrated physical Gallium/NIR scene submission, GPU command completion and retirement, and successful COLOR/Z24 readback on PowerVR SGX535 (GMA500) hardware These results have been validated on an Intel Poulsbo GMA500 system running a Linux 5.10-based kernel. I'm currently looking for a lightweight Linux distribution with a recent kernel to begin testing against newer kernel versions I'm currently planning a modular architecture, with clearly separated responsibilities for GPU memory management and MMU mappings, GEM buffer ownership and lifetime management, GPU command submission and execution, completion fences and synchronization, and timeout handling, error recovery, and device removal. My current preference is to integrate SGX535 rendering within the existing drm/gma500 driver, rather than introduce a completely separate DRM driver. The intention is to preserve the existing display infrastructure while adding rendering capabilities through modular components that can be reviewed and maintained independently. However, this is still a proposed direction, and I'm open to a separate DRM render driver if the maintainers consider that a better architectural fit. Before proceeding with the initial patch series, I'd appreciate feedback on three architectural questions: 1- Should SGX535 rendering remain within drm/gma500, sharing display-device ownership, or would a separate DRM render driver be preferable? 2- What would be the preferred ownership model for GPU MMU mappings, GEM buffer lifetimes, and completion fences, particularly when coordinating rendering with the existing display infrastructure? 3- What is the minimum acceptable recovery contract for GPU submission failures, timeouts, suspend/resume, and device removal? The overall implementation remains experimental. However, parts of the kernel-side infrastructure may already be suitable for an initial RFC patch, subject to architectural review I'm considering submitting a small initial RFC patch within the next few days, focusing on foundational infrastructure and architectural integration rather than submitting the entire experimental implementation at once My goal is to keep the initial changes small, reviewable, and compatible with the existing gma500 driver, while establishing a foundation for subsequent SGX535 rendering support I'd appreciate any early feedback on the proposed architecture, particularly regarding driver ownership and the preferred upstream integration path :D Thanks! Em dom., 1 de nov. de 2026 17:13, Operating System's Depression < [email protected]> escreveu: > Resending after subscribing to dri-devel, as I could not confirm whether > my original message reached the list. Apologies if this is a duplicate. > > Hello Patrik and DRM developers, > > I'm developing SGX535-reMESA, an independent Mesa/Gallium rendering path > for Intel Poulsbo/GMA 500. Before designing a production submission UAPI, > I'd appreciate advice on the ownership and lifetime model alongside > existing gma500 display support. My intention is to preserve the existing > display functionality while exploring render support under appropriate > shared-device ownership. > > This is an architecture discussion, with no patch series or request to > merge the experimental interfaces. > > The test machine is a Dell Inspiron Mini 12, Atom Z520, PCI 8086:8108, > SGX535 core 0x01130000/revision 0x00010201. Kernel work currently targets > antiX 5.10.240-antix.1-486-smp on 32-bit x86; it has not been ported or > qualified against current mainline. > > There is physical evidence for a restricted 1280x800 > 600-frame/600-submission glxgears run, isolated native 2D copy/fill, and > bounded fixed-profile private-MMU jobs. These results do not qualify the > general renderer. > > Recent experimental runs have also exercised the general-scene submission > path on physical hardware. Completion was observed, but COLOR/Z readbacks > did not establish correct rendered output. General-scene execution remains > unqualified. > > Gallium frontend integration and shared COLOR/Z fence handling have passed > selected offline tests. Physical qualification of the integrated path is > still pending. Whole-desktop acceleration, GLES 2.0, desktop OpenGL 2.1 and > an installable driver remain goals. > > The experimental design is deliberately serialized: > > * GEM-backed objects are held by jobs with generation-checked private IDs. > A private GPU page directory maps retained backing with narrowed access; > CPU-only storage is excluded. Mapping/control pages and backing lifetimes > remain held until a verified release, or are quarantined on uncertainty. > > * Native 2D, rendering and IRQ attribution share device exclusion. The > existing fixed-profile executor holds an endpoint mutex and the MMU writer > semaphore across root binding, issue, completion, CPU visibility, > default-root restoration and source closure. It does not yet implement a > production asynchronous queue or a complete dma_fence/dma_resv/syncobj > contract. > > * Failure does not fabricate completion or root restoration. Unplug guards > revoke admission, while uncertain GPU state prevents unsafe reclamation or > rebinding. This is not proof that SGX DMA has stopped. PCI save/restore and > power-management admission checks do not establish reset, suspend or > runtime-PM safety. > > My questions, in priority order: > > 1. Device ownership and gma500 integration > > Would extending the existing gma500 DRM device be the preferred starting > point for SGX535 render support, given the shared PCI function, GEM/GTT/MMU > resources, IRQ handling and power state? > > I intend to preserve existing display support rather than introduce a > competing PCI driver. What separation between display and render components > would you recommend before proposing a render node or submission UAPI? > > 2. GEM, MMU and synchronization > > For an initially single-job design, should job-held GEM references, > explicit per-job GPU mappings and one global exclusion domain be the > baseline, with dma_resv fences for object hazards and CPU access? > > Which current DRM helpers or small driver would you recommend as a model? > > I want root switching and cache publication to have explicit ownership > without treating the current private IDs or synchronous ioctl as ABI. > > 3. Failure handling, removal and suspend > > Without a demonstrated SGX reset/stop sequence, is a terminal wedged state > with retained backing a reasonable development policy? > > What stop/isolation proof must removal provide before translations can be > reclaimed, and how should active hardware detach be separated from later > GEM destruction? > > In particular, old file/VMA/fault callbacks must not touch MMIO/GTT or PM > state after unplug or a later rebind. > > Should suspend be refused while work/root state is uncertain until that > same stop-and-restore contract is demonstrated? > > 4. Upstream development sequence > > Which current DRM tree should host the first reviewable work: small gma500 > lifetime/admission fixes first, then submission/synchronization together > with real open Mesa userspace? > > I intend to forward-port and use current GEM/PM APIs rather than propose a > cross-version abstraction around this 5.10 experiment. > > Are there specific gma500 constraints that should change that order, > especially before enabling runtime PM? > > Project and public evidence index: > https://github.com/reMESA-devgroup/SGX535-reMESA > > The current development snapshot includes local, unpublished changes; the > public repository alone does not reproduce the latest experimental kernel > or physical runs. > > The relevant source areas are kernel/remesa/gma500/ > (remesa_gem_private_execute.inc, remesa_mmu_private.inc, > remesa_mmu_switch.inc and the private lifetime/power guards), integrated > for the experiment by tools/remesa/stage_twod_reservation.py. > > Source staging is a build aid, not the proposed upstream patch format. > > I understand that a future DRM UAPI needs corresponding real open-source > userspace, including error handling, reviewed for a suitable upstream > project. > > I can follow up with a small current-kernel diff and a focused > lifetime/state-transition description once the integration direction is > clear. > > Feedback on the ownership boundary or the most useful first diff would be > particularly helpful. > > Thanks, > Gabriel Gama > [email protected] >
