Commits on Source (24)
-
Carried over from gl-renderer's equivalent code. Signed-off-by: Daniel Stone <daniels@collabora.com>
89d0d903 -
We've got a nice shiny ARRAY_COPY macro, so use it rather than memcpy or hand-unrolled assignments. Signed-off-by: Daniel Stone <daniels@collabora.com>
d696f8df -
Rather than checking all the pixel-format components which are currently duplicated inside gl-renderer, just check for equality of the pixel format itself, which will become useful as we remove some of the duplicate content. This means that the texture storage will now be reallocated when clients switch between pixel formats which could've had compatible GL storage (e.g. XRGB <-> ARGB) on the same surface. However this does not seem like a case worth optimising, and simplifies the code somewhat. Signed-off-by: Daniel Stone <daniels@collabora.com>
2e6827d7 -
Instead of checking for each format whether we need compatibility workarounds for GL implementations not supporting ES3.x or when GL_EXT_texture_rg isn't present, have each format declare the ideal case and fix it up later. Signed-off-by: Daniel Stone <daniels@collabora.com>
38f933dd -
pixel-formats already stores the gl_format, at least for single-planar formats; use that instead of storing our own copies. Signed-off-by: Daniel Stone <daniels@collabora.com>
badd774c -
Clients can't reach this because libwayland-server already checks whether the format is supported. Signed-off-by: Daniel Stone <daniels@collabora.com>
2c402603 -
Since the buffer now has a pixel_format hook, just use that consistently instead of the SHM code. Signed-off-by: Daniel Stone <daniels@collabora.com>
d37d73a9 -
'depth' isn't actually used to determine the bit depth of meaningful components generally, but specifically to determine whether we can use the legacy drmModeAddFB (pre-AddFB2) with those formats. Rename the member to make it more clear what it's used for. Signed-off-by: Daniel Stone <daniels@collabora.com>
c54eace9 -
Doing this allows us to get rid of some open-coded per-format calculations inside gl-renderer. Signed-off-by: Daniel Stone <daniels@collabora.com>
2ade128a -
No need to open-code bits per pixel and shader variants. Signed-off-by: Daniel Stone <daniels@collabora.com>
e08df66b -
We already had these with effective width and height, but they're useful externally as well. Pull them out to a helper. Signed-off-by: Daniel Stone <daniels@collabora.com>
4161948d -
If we're doing partial uploads from SHM buffers, we need to use the vertical subsampling factor rather than the horizontal for secondary planes. Signed-off-by: Daniel Stone <daniels@collabora.com>
742f10f3 -
No need to open-code everything here. Signed-off-by: Daniel Stone <daniels@collabora.com>
c2cfadfc -
We support this as an explicit YUV fallback path in gl-renderer's dmabuf EGLImage import path, so might as well support it in the SHM path, given it's just YUV420 with no subsampling. Signed-off-by: Daniel Stone <daniels@collabora.com>
820f3ae8 -
This was just a duplicate of shader variants, for historical reasons. Signed-off-by: Daniel Stone <daniels@collabora.com>
32ee42d2 -
Add a new hide_from_clients flag which, if set, specifies that the format is only for internal information and processing, and should not be advertised for clients. This will be used for formats like R8 and GR88, which are not useful for client buffers, but are used internally to implement YUV -> RGB conversion. Signed-off-by: Daniel Stone <daniels@collabora.com>
1db2fbef -
These formats are used within gl-renderer to do YUV -> RGB colourspace conversion. Signed-off-by: Daniel Stone <daniels@collabora.com>
727c4ef6 -
We already have this elsewhere. Signed-off-by: Daniel Stone <daniels@collabora.com>
16548139 -
We already have the subsampling levels in pixel-formats - no need to type it out again here. Signed-off-by: Daniel Stone <daniels@collabora.com>
1a86963d -
Now that we can pull everything we need from pixel-formats, go one step further and reuse the same YUV format descriptors we use to emulate dmabuf/EGLImage imports for SHM. This eliminates all special-case YUV/SHM handling. Signed-off-by: Daniel Stone <daniels@collabora.com>
18a31a6a -
Try to describe this and yuv_plane_descriptor as well, since they're not blindingly obvious. Signed-off-by: Daniel Stone <daniels@collabora.com>
67fc7121 -
There's just no good reason to do this. The query entrypoints already tell us if we need to use GL_TEXTURE_EXTERNAL_OES for a particular format/modifier. We also have RGB -> YUV fallbacks which should be able to work well with TEXTURE_2D. TEXTURE_EXTERNAL pessimises quite hard, forcing GPU-side reloads as well as bad filtering. Allowing multi-planar formats to use TEXTURE_2D should thus result in performance and quality improvements. Signed-off-by: Daniel Stone <daniels@collabora.com>
f36d77a1 -
It's three planes, not two. Signed-off-by: Daniel Stone <daniels@collabora.com> Fixes: 8b167a17 ("gl-renderer: Store EGL buffer state in weston_buffer")
c3d84293 -
Most everything else only supports 3 planes, and we don't support any four-plane YUV formats, so. Signed-off-by: Daniel Stone <daniels@collabora.com>
dfaba9f1
This diff is collapsed.