Originally posted by HokTar
View Post
Originally posted by HokTar
View Post
Originally posted by HokTar
View Post
Classic GL driver
=================
GLSL
compiler generats GLSL IR
utility routine converts to Mesa IR
--------
Mesa IR
driver converts to hardware
(dashed line is the interface between common mesa and HW driver)
Gallium3D GL driver
===================
GLSL
compiler generates GLSL IR
utility routine converts to Mesa IR
utility routine converts to TGSI
----
TGSI
driver converts to hardware
(Mesa IR is converted to TGSI in the common mesa code then passed to the Gallium3D HW driver)
Video state tracker implementing full H.264 decode
==================================================
H.264 slice
CPU does bitstream parse, entropy decode, probably IDCT
tracker generates TGSI for MC, deblock
----
TGSI
driver converts to hardware
Video state tracker implementing MC/deblock only
================================================
partially decoded surfaces
tracker generates TGSI for MC, deblock
----
TGSI
driver converts to hardware
The potentially confusing thing about nearly all of the video interfaces is that their definitions include multiple entry points -- bitstream/slice, XvMC-like, and (IIRC) Xv-like. Drivers typically implement only one of those entry points and the player needs to do the rest (which means that a player that "supports VA-API" might only support one of the entry points while a "VA-API driver" might only support a different entry point.
Most of the driver implementations so far have been for use with hardware decoders and have implemented the top level entry point, but things will get more interesting as other entry points start to get used more. I expect the most common stack for shader-assisted decode will be whichever of the lower level entry points for an existing API (VA-API or VDPAU) best aligns with the MC/deblock functions, and if none of them fit then an enhanced XvMC would probably be used instead.
Originally posted by HokTar
View Post
What I see happening is a state tracker that exposes a few standard functions (MC, deblock) which can be used by a higher level decode routine (eg ffmpeg). The existing ffmpeg codecs would be modified to call into the generic MC/deblock state tracker and perform those functions on the GPU rather than the CPU, so the additional per-format work should be relatively small.
Originally posted by HokTar
View Post
Originally posted by HokTar
View Post
Originally posted by HokTar
View Post
Comment