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. Even With Re-Clocking, Nouveau Remains Behind NVIDIA's Proprietary Linux Driver
  2. The Power Consumption & Efficiency Of Open-Source GPU Drivers
  3. AMD R600g/RadeonSI Performance On Linux 3.16 With Mesa 10.3-devel
  4. Intel Pentium G3258 On Linux
Latest Linux Articles
  1. AMD Catalyst 14.6 Does Slightly Better With APITest OpenGL Tests
  2. Updated Source Engine Benchmarks On The Latest AMD/NVIDIA Linux Drivers
  3. Nouveau vs. Radeon vs. Intel Tests On Linux 3.16, Mesa 10.3-devel
  4. KVM Benchmarks On Ubuntu 14.10
Latest Linux News
  1. SteamOS Beta 126 Better Handles XBMC
  2. Ubuntu 14.10 Alpha 2 Released
  3. KDE 4.14 Release Candidate Ships
  4. Drivers & Drama Dominated Linux Talk In July
  5. Fedora Assembles A Security Team
  6. AMD Launches The A10-7800, The 65 Watt Kaveri
  7. Builder: A New Development IDE Being Built For GNOME
  8. GDB 7.8 Betters Python Scripting, Adds Guile Support
  9. GNOME's GTK+ Is Still Striving For A Scene Graph, Canvas API
  10. Unreal Tournament Looks Great For Team Deathmatch
Latest Forum Discussions
  1. Linus Torvalds On GCC 4.9: Pure & Utter Crap
  2. Updated and Optimized Ubuntu Free Graphics Drivers
  3. Grand Theft Auto Running On Direct3D Natively On Linux Shows Gallium3D Potential
  4. Updated graphics drivers for Ubuntu 12.04 Precise LTS
  5. Debian + radeonsi
  6. AMD Publishes Open-Source Linux HSA Kernel Driver
  7. Open-source drivers on ATI R7 260X
  8. AMD Athlon 5350 APU On Linux