blob: 429def75660bb895dfd31cc5dee19ffc78eefb9c (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
This page lays out a plan how correctly handling direct rendering (and consequently accelerated indirect rendering with AIGLX) to windows redirected using the Composite extension could be implemented. Parts of it may also apply to rendering to GLXPixmaps, implementing GLX_EXT_texture_from_pixmap with direct texturing out of pixmap memory or providing per-drawable back and depth buffers. Others are encouraged to add or refine items, but please use the dri-devel mailing list for discussion to avoid cluttering up this page.
The plan is structured by various events and the flow of control between the DRI components when they occur.
Work on a prototype implementation of this is happening in airlied and krh's xserver and xf86-video-intel git repos.
* Pixmap allocation in X server
* EXA/glucose/... calls 2D driver hook.
* 2D driver allocates from unified memory manager, e.g. TTM. May need to share memory manager objects between smaller pixmaps for performance.
* DRI drawable creation
* Client calls new variant of DRICreateDrawable which informs the DRI module that the client can handle redirection.
* DRI module calls 2D driver hook to allocate renderbuffers (only covering the bounding box of the drawable cliprects for back and depth) and retrieve memory manager IDs. May want to allow for several back buffers.
* DRI module pushes memory manager IDs (as opaque u64s) and additional information (offset from start of each memory manager object, pitch, drawable deltas from upper left corner of backing pixmap, ?) to DRM via [[UpdateDrawableInfo|UpdateDrawableInfo]].
* Context binding
* Client retrieves memory manager IDs and additional information from DRM.
* Buffer swap
* Client blits back buffer to drawable backing pixmap.
* May want to track swap counter, e.g. for flipping when the drawable occupies the whole backing pixmap or for several back buffers.
* 3D driver makes Damage extension request to generate damage.
* glFlush
* When rendering to front buffer, 3D driver makes Damage extension request to generate damage.
* Window resizing
* DRI module repeats appropriate steps (reallocate renderbuffers if necessary and push new MM IDs and additional info to DRM) from DRI drawable creation item.
* DRI module and/or 2D driver may reduce number of renderbuffer allocations, e.g. by reducing granularity of size deltas, for performance.
* 3D driver repeats appropriate steps from Context binding item.
* Window (un)redirection
* DRI module (de)allocates renderbuffers and pushes/pulls memory manager IDs and additional information to/from the DRM.
* **XXX**: Where to hook this into? KRH: We need notification when a drawble get new backing BOs anyway - e.g. when a redirected window pixmap is resized. Unredirection is pretty much the same case: we move the drawable from one set of backing BOs (those backing the redirected window) to another (those backing the root window).
* X hardware rendering
* 2D driver binds pixmap memory manager objects into GPU space in accel hooks.
* X software rendering
* 2D driver maps pixmap memory manager objects into CPU space in (equivalent of) [[PrepareAccess|PrepareAccess]] hook.
|
