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]
