1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Generic Buffer Formats, YUV For Wayland

Intel

Published on 20 April 2012 01:05 PM EDT
Written by Michael Larabel in Intel
1 Comment

A few interesting patch-sets were published today concerning Wayland.

Gwenole Beauchesne, the developer who formerly worked at Splitted Desktop Systems to create various VA-API drivers including the NVIDIA VDPAU back-end to VA-API and VA-API over AMD XvBA, has been working at Intel since last year. He hasn't had many user-facing patches hit the public lists in the past few months, but that changed this morning.

It appears that Gwenole Beauchesne may be in the midst of some interesting developments today. He kicked off the morning by publishing the patches to add generic buffer format support to Wayland, in particular introduced YUV format support. He then published separate patches that implement this format support for Weston, then he went on to publish some Mesa patches.

Here's his set of five patches concerning generic buffer format support for Wayland.
This series adds generic buffer formats (at the wl_buffer level) and YUV formats in particular. I believe this is generally useful because even for SHM buffers, we could also represent YUV contents in there. e.g. gstreamer sink.

Patch 1 adds the generic buffer types. Those are the most commonly used formats only. Besides, I also dropped YUV/YVU variants as YVU is YUV with different layout.

Talking of which, Patch 2 adds some layout infrastructure. If you already have an allocated SHM buffer around, it's theoritically possible to attach a particular layout to it. However, I didn't want to expose that because if the user allocates a YUV buffer, it will tend to have the same layout for the lifetime of the object. And, if the layout needs to be changed, allocating a new buffer should not be that expensive.

Since I added the layout right into the wl_buffer base object, Patch 3 bumps the version of its interface.

Patch 4 fills in layout information for SHM buffers.

Patch 5 adds some helpers to extract a sensible layout even if the buffer was implemented for a former interface.
This support can be useful for video handling with Wayland.

To Weston were then a set of four patches (on the mailing list) to add in support for YUV buffers with Weston. Gwenole's already tested this YUV buffer support in Wayland's Weston with VA-API on Intel hardware. This isn't the first time that VA-API on Wayland has come to light, but back in February I reported on VA-API for Wayland was being worked on by Intel.
Here is a first round of patches for supporting YUV buffers in Weston. It theoritically possible to support planar YUV from SHM buffers but I have only tested with VA-API on GenX (NV12, YUV 4:2:0 and 4:2:2).

Some changes are needed in Mesa, but I wanted to get your opinion on this model first. Rationale: a Wayland buffer is actually several individual sub buffers (one for each plane) that can be passed to eglCreateImageKHR(). Some people would argue to use OES_EGL_image_external, but I wanted to make the usage of shaders explicit. Besides, for other projects, there was also a need to map individual planes as separate buffers so that to perform some postprocessing with further shader code (noise reduction, sharpening, etc.).

So, I extended EGL_WAYLAND_BUFFER_WL spec to use a new attribute that specifies that actual plane to map: EGL_WAYLAND_BUFFER_PLANE_WL. The whole magic to calculate stride, offsets et al. is performed in Mesa with the help of Wayland buffer layouts.

For rendering, you just need to create an EGLImage and the corresponding texture for each plane of the YUV buffer. Then, you provide the shader with the current restriction that EXT_texture_rg is required. i.e. single components (e.g. Y) are mapped to GL_R8 [.r] and two components (e.g. UV for NV12) are mapped to GL_RG8 [.r/.g]. I could have sticked to standard GL_LUMINANCE [.x] and GL_LUMINANCE_ALPHA [.x/.w] but those tended to be deprecated in desktop GL IIRC and I wanted a means that could let the user use single glsl source code for rendering (depending on his winsys).

The other idea to hide stride, offsets into Mesa was that wl_drm_create_buffer_with_layout() could also take a future "flags" argument that would denote interleaved frames
(top/bottom fields).

Issues:
- EXT_texture_rg requirement, could be fixed with an extra EGL attribute.
- Use shaders to render from YUV even if some HW could sample from YUV textures directly.
Next on Gwenole's agenda for the day was to then publish the Mesa support for handling the GL_EXT_texture_rg extension within Mesa for OpenGL ES 2.0. As far as hardware drivers go for GL_EXT_texture_rg, he implemented the support inside the Mesa DRI driver. The mailing list message can be found here.

Last but not least, the latest Gwenole Beauchesne patch-set coming out today to cache regions plus an offset within the Mesa DRI driver. The patches under an "RFC" (Request For Comments) flag hit the mesa-dev list. This too is also part of the YUV surface work going on for Wayland.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. AMD Radeon R9 290: Gallium3D vs. Catalyst Drivers
  2. AMD Radeon R9 290 Open-Source Driver Works, But Has A Ways To Go
  3. Trying The Configurable 45 Watt TDP With AMD's A10-7800 / A6-7400K
  4. Sumo's Omni Gets Reloaded
Latest Linux Articles
  1. Testing For The Latest Linux Kernel Power Regression
  2. The Most Energy Efficient Radeon GPU For AMD Linux Gaming
  3. 20-Way Radeon Comparison With Open-Source Graphics For Steam On Linux Gaming
  4. Preview: OS X 10.10 Yosemite vs. Ubuntu Linux GPU Performance
Latest Linux News
  1. Enlightenment E19 RC3 Shows Off The New Wayland Compositor
  2. Metro Redux Is Going To Require OpenGL 4.x On Linux
  3. Jailhouse v0.1 Released As A Basic Hypervisor For Linux
  4. Google's Chromebook "Samus" Now Supported By Coreboot
  5. Chrome 38 Now In Beta With Exciting Advancements
  6. Ubuntu's Utopic Unicorn 14.10 Beta 1 Released
  7. Genode OS 14.08 Has New GUI Architecture, Pluggable VFS
  8. Another Intel Linux Power Regression Is Being Investigated
  9. DNF Makes It A Step Closer To Replacing Yum On Fedora
  10. OS Battle: Linux Takes 1.7% Desktop Marketshare
Latest Forum Discussions
  1. Canonical Joined The Khronos Group To Help Mir/Wayland Drivers
  2. Users defect to Linux as OpenBSD removes Lynx from base system
  3. Radeon HD5670 and Ubuntu 14.04
  4. Updated and Optimized Ubuntu Free Graphics Drivers
  5. AMD Releases UVD Video Decode Support For R600 GPUs
  6. Best Radeon for a Power Mac G5?
  7. OC capability - Intel Core i5 4690K & Biostar Hi-Fi Z97WE
  8. Announcing radeontop, a tool for viewing the GPU usage