summaryrefslogtreecommitdiff
path: root/Development/Documentation/GlamorPerformance.mdwn
diff options
context:
space:
mode:
authorAdam Jackson <ajax@redhat.com>2016-09-26 12:20:37 -0400
committerAdam Jackson <ajax@redhat.com>2016-09-26 12:20:37 -0400
commit2ad50a42553db587119228e587849883097349e1 (patch)
tree106e107c1983f1a52f7227a6b3219cd02b862b06 /Development/Documentation/GlamorPerformance.mdwn
parentdcc75b5d15f4cb4cf8e415ab426f63ac08a325f2 (diff)
start glamor performance
Diffstat (limited to 'Development/Documentation/GlamorPerformance.mdwn')
-rw-r--r--Development/Documentation/GlamorPerformance.mdwn29
1 files changed, 29 insertions, 0 deletions
diff --git a/Development/Documentation/GlamorPerformance.mdwn b/Development/Documentation/GlamorPerformance.mdwn
new file mode 100644
index 00000000..beae11dc
--- /dev/null
+++ b/Development/Documentation/GlamorPerformance.mdwn
@@ -0,0 +1,29 @@
+Glamor _should_ be able to accelerate all of X, given a sufficiently capable GL implementation. It doesn't, yet, and this document attempts to describe the remaining work.
+
+## Core ops
+
+The two bits of core GC state that tend to cause fallbacks are GCFunction and GXPlaneMask. For the former we try to use glLogicOp, which works for draw calls but not for texture image calls, and doesn't exist in GLES. For the latter we basically just punt if the planemask isn't trivial.
+
+We could probably accelerate both of the above if the GL(SL) below us has something like [[MESA_shader_integer_functions|https://www.opengl.org/registry/specs/MESA/shader_integer_functions.txt]] or [[EXT_framebuffer_fetch|https://www.khronos.org/registry/gles/extensions/EXT/EXT_shader_framebuffer_fetch.txt]].
+
+### Image ops
+
+PutImage is implemented with TexSubImage2D, so is only accelerated for GXcopy operations. If LogicOp works, you could accelerate this by using a temporary texture and drawing through it to the destination.
+
+PutImage can't accelerate XYPixmap because that's not an image format that GL hardware (or anything postdating the Amiga, really) is equipped to deal with. You basically can't accelerate this unless you can accelerate arbitrary planemasks.
+
+PutImage (not ShmPutImage) tends to memcpy once more than a classic X driver because it buffers the image data into the GL command stream, where exa might just blast the data directly into the pixmap. It's difficult to get around this without either a hint to the GL that the upload should be immediate (with all the stall/flush that implies), or some _serious_ surgery to the protocol buffering code.
+
+GetImage falls back for ZPixmap with non-trivial planemask. There's not really a sane way to accelerate that through the GL, but it's cheap to fix up in software by just zeroing out the unset planes before writing to the client.
+
+GetImage falls back entirely for XYPixmap, and again, GL very wisely doesn't believe in XYPixmap. Best approach is likely to download to a temporary as if ZPixmap, and then walk the planemask pulling out a plane at a time into the reply buffer.
+
+### Geometry ops
+
+### Text ops
+
+### Span ops
+
+## Render
+
+## XVideo