summaryrefslogtreecommitdiff
path: root/Development/Documentation/GlamorPerformance.mdwn
diff options
context:
space:
mode:
authorAdamJackson <AdamJackson@web>2016-09-26 17:15:20 +0000
committerxorg <iki-xorg@freedesktop.org>2016-09-26 17:15:20 +0000
commit29e04d0283c604f97a9ee87e03f9594bb5fcd7b9 (patch)
treec8f7040fc145d11bf587538909dbc7c7d528f0d7 /Development/Documentation/GlamorPerformance.mdwn
parent0fd1289646a4ca7fde5f7f95044b9371766a51ee (diff)
formatting, typos
Diffstat (limited to 'Development/Documentation/GlamorPerformance.mdwn')
-rw-r--r--Development/Documentation/GlamorPerformance.mdwn22
1 files changed, 10 insertions, 12 deletions
diff --git a/Development/Documentation/GlamorPerformance.mdwn b/Development/Documentation/GlamorPerformance.mdwn
index 38a62ef0..a22dc267 100644
--- a/Development/Documentation/GlamorPerformance.mdwn
+++ b/Development/Documentation/GlamorPerformance.mdwn
@@ -32,33 +32,31 @@ TODO
### Span ops
-SetSpans, like PutImage, operates on the texture so can't accelerate non-GXcopy operations.
-
FillSpans might benefit from an alternate calling convention, where rather than being passed a span list the caller asks the driver to allocate the span storage, fills that in, then calls Set or Fill. This would let us eliminate the copy into the vbo and just store there directly.
-GetSpans is irrelevant, you can't hit it unless you're using the mi blit routines, and we're not.
+GetSpans and SetSpans are irrelevant, you can't hit it unless you're using the mi blit routines, and we're not.
## Render
The Render implementation needs major work:
-0) Determine if the largepixmap code is salvageable or easily replaceable.
+0. Determine if the largepixmap code is salvageable or easily replaceable.
-Right now modification of the Render extension support is nearly impossible because of the largepixmap render support. If we got rid of this it would be easy to hack on, but it may be that we need it for performance (For example, on Firefox's scaling of large photographs).
+ Right now modification of the Render extension support is nearly impossible because of the largepixmap render support. If we got rid of this it would be easy to hack on, but it may be that we need it for performance (For example, on Firefox's scaling of large photographs).
-1) Use GL_ARB_texture_view to reinterpret pixmaps as various sets of channels.
+1. Use GL_ARB_texture_view to reinterpret pixmaps as various sets of channels.
-Without this, Render ops with a2r10g10b10 or r5g6b6 will fall back to software because we only store pixmaps as either a8r8g8b8 or a8.
+ Without this, Render ops with a2r10g10b10 or r5g6b5 will fall back to software because we only store pixmaps as either a8r8g8b8 or a8.
-This requires use of GL_ARB_texture_storage and therefore GL_ARB_sampler_objects. See https://github.com/anholt/xserver/tree/glamor-sampler-objects
+ This requires use of GL_ARB_texture_storage and therefore GL_ARB_sampler_objects. See [[https://github.com/anholt/xserver/tree/glamor-sampler-objects]]
-2) Use the new program infrastructure for transformations.
+2. Use the new program infrastructure for transformations.
-We do a ton of computation on the CPU for the coordinates of our Render ops. These are best done in shader code, instead.
+ We do a ton of computation on the CPU for the coordinates of our Render ops. These are best done in shader code, instead.
-3) Accelerate trapezoids
+3. Accelerate trapezoids
-With modern GL, we should be just fine writing the trapezoids rendering in a shader, improving xlib-cairo path performance massively. Today, we allocate in an memory pixmap, rasterize traps into it, then upload to GL and do a Composite from there.
+ With modern GL, we should be just fine writing the trapezoids rendering in a shader, improving xlib-cairo path performance massively. Today, we allocate an in-memory pixmap, rasterize traps into it, then upload to GL and do a Composite from there.
## XVideo