summaryrefslogtreecommitdiffstats
path: root/DOCS
diff options
context:
space:
mode:
authorNiklas Haas <git@haasn.xyz>2017-07-16 17:17:39 +0200
committerNiklas Haas <git@haasn.xyz>2017-07-16 17:46:24 +0200
commitdead206873c1840a21adf789b9e4b5d167012b19 (patch)
tree5de62f71ae89cd902019a315b786c239dd09327b /DOCS
parent46bfa3726f6163cb812425b49a8483c635b6d623 (diff)
downloadmpv-dead206873c1840a21adf789b9e4b5d167012b19.tar.bz2
mpv-dead206873c1840a21adf789b9e4b5d167012b19.tar.xz
vo_opengl: use glBufferSubData instead of glMapBufferRange
Performance seems pretty much unchanged but I no longer get nasty spikes on NUMA systems, probably because glBufferSubData runs in the driver or something. As a simplification of the code, we also just size the PBO to always have the full size, even for cropped textures. This seems slower but not by relevant amounts, and only affects e.g. --vf=crop. It also slightly increases VRAM usage for textures with big strides. This new code path is especially nice because it no longer depends on GL_ARB_map_buffer_range, and no longer uses any functions that can possibly fail, thus simplifying control flow and seemingly deprecating the manpage's claim about possible image corruption. In theory we could also reduce NUM_PBO_BUFFERS since it doesn't seem like we're streaming uploads anyway, but leave it in there just in case some drivers disagree...
Diffstat (limited to 'DOCS')
-rw-r--r--DOCS/man/options.rst3
1 files changed, 0 insertions, 3 deletions
diff --git a/DOCS/man/options.rst b/DOCS/man/options.rst
index 07f961af83..5c25794588 100644
--- a/DOCS/man/options.rst
+++ b/DOCS/man/options.rst
@@ -4136,9 +4136,6 @@ The following video options are currently all specific to ``--vo=opengl`` and
source video size is huge (e.g. so called "4K" video). On other drivers it
might be slower or cause latency issues.
- In theory, this can sometimes lead to sporadic and temporary image
- corruption (because reupload is not retried when it fails).
-
``--dither-depth=<N|no|auto>``
Set dither target depth to N. Default: no.