Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Erik Faye-Lund]

On Wed, 2019-12-04 at 01:48 -0500, Marek Olšák wrote:
> On Wed., Dec. 4, 2019, 01:20 Tapani Pälli, 
> wrote:
> > Hi;
> > 
> > On 12/4/19 2:39 AM, Marek Olšák wrote:
> > > Hi,
> > > 
> > > Here are 2 proposals to simplify and better optimize the GL-
> > >Gallium 
> > > translation.
> > > 
> > > 1) Move classic drivers to a fork of Mesa, and remove them from
> > master. 
> > > Classic drivers won't share any code with master. glvnd will load
> > them, 
> > > but glvnd is not ready for this yet.
> > > 
> > > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only 
> > > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to
> > be 
> > > forked and mesa/state_tracker moved. src/gallium/state-
> > trackers/gl/ can 
> > > be the target location.
> > > 
> > > Option 2 is more acceptable to people who want to keep classic
> > drivers 
> > > in the tree and it can be done right now.
> > > 
> > > Opinions?
> > > 
> > 
> > I'm still quite newbie with gallium side of things and I'd like to
> > know 
> > more about the possible simplifications and optimizations that
> > could be 
> > done if this happened. Is this more about 'cleaning up the tree' or
> > are 
> > there also some performance opportunities we are missing right now
> > with 
> > current state?
> 
> It's possible to reduce CPU overhead even more by moving state
> translation from st_validate_state to GL functions. This is possible
> already, but at the cost of effectively adding dead code to classic
> drivers. In theory we could do slightly better without classic
> drivers, but we don't know for sure.
> 
> If we had nir_to_tgsi, we could remove TGSI support from st/mesa.
> Option 1 would leave st/mesa as the only consumer of Mesa IR and GLSL
> IR, so both IRs could be eliminated in favor of NIR more easily. 

Implementing nir_to_tgsi is something I've considered several times
while working on VirGL; there's a lot of useful lowering-code in NIR
that sometimes has to be re-implemented in TGSI, and writing new
lowering code targetting NIR is just so much nicer than when targetting
TGSI.

For both SVGA and VirGL, TGSI can't be completely eliminated without
breaking compatibility, because TGSI is part of their protocols. And I
believe in both cases, it's a slightly divergent variation of TGSI.

So yeah, just wanted to say: +1 on this part :)

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Marek Olšák]

On Wed., Dec. 4, 2019, 01:20 Tapani Pälli,  wrote:

> Hi;
>
> On 12/4/19 2:39 AM, Marek Olšák wrote:
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium
> > translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from master.
> > Classic drivers won't share any code with master. glvnd will load them,
> > but glvnd is not ready for this yet.
> >
> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
> > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be
> > forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/ can
> > be the target location.
> >
> > Option 2 is more acceptable to people who want to keep classic drivers
> > in the tree and it can be done right now.
> >
> > Opinions?
> >
>
> I'm still quite newbie with gallium side of things and I'd like to know
> more about the possible simplifications and optimizations that could be
> done if this happened. Is this more about 'cleaning up the tree' or are
> there also some performance opportunities we are missing right now with
> current state?


It's possible to reduce CPU overhead even more by moving state translation
from st_validate_state to GL functions. This is possible already, but at
the cost of effectively adding dead code to classic drivers. In theory we
could do slightly better without classic drivers, but we don't know for
sure.

If we had nir_to_tgsi, we could remove TGSI support from st/mesa. Option 1
would leave st/mesa as the only consumer of Mesa IR and GLSL IR, so both
IRs could be eliminated in favor of NIR more easily. Although I guess a
simpler option is not to touch anything.

Marek

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Tapani Pälli]

Hi;

On 12/4/19 2:39 AM, Marek Olšák wrote:

Hi,

Here are 2 proposals to simplify and better optimize the GL->Gallium 
translation.


1) Move classic drivers to a fork of Mesa, and remove them from master. 
Classic drivers won't share any code with master. glvnd will load them, 
but glvnd is not ready for this yet.


2) Keep classic drivers. Fork src/mesa for Gallium. I think only 
mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be 
forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/ can 
be the target location.


Option 2 is more acceptable to people who want to keep classic drivers 
in the tree and it can be done right now.


Opinions?



I'm still quite newbie with gallium side of things and I'd like to know 
more about the possible simplifications and optimizations that could be 
done if this happened. Is this more about 'cleaning up the tree' or are 
there also some performance opportunities we are missing right now with 
current state?


Thanks;

// Tapani
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Jason Ekstrand]

On Tue, Dec 3, 2019 at 8:19 PM Dave Airlie  wrote:

> On Wed, 4 Dec 2019 at 10:39, Marek Olšák  wrote:
> >
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium
> translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from master.
> Classic drivers won't share any code with master. glvnd will load them, but
> glvnd is not ready for this yet.
>

I'm usually the first person to tell people to stop mucking about with old
hardware and I fear even I think this would be a bit premature.  We've not
turned iris on by default yet and I'd really like it to bake as the default
distro driver for a while (maybe a year) before we put i965 on
life-support.  If we were having this discussion in another year's time, I
might be in favor of this but, as it currently stands, I'm not sure this is
a good idea.


> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
> mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be forked
> and mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the
> target location.
>

I really don't like this option.  For one thing, this means two copies of
code that will get out-of-sync.  If we had the classic drivers in their own
branch, we could at least cherry-pick bugfixes back to the classic branch.
However, if we have two copies of everything, our version control tool
can't help us.

The bigger problem is headers.  Currently, the GLSL compiler includes
mtypes.h so we would need to somehow separate the GLSL compiler out from
src/mesa/main because we'll have two mtypes.h files.  Unfortunately, GLSL
isn't the only thing that includes stuff from src/mesa/main.  Our header
situation has been a disaster for years and I'm afraid it hasn't gotten any
better with the addition of src/util.  Most people who move stuff don't
actually do due diligence to keep the includes clean and the result is that
I'm pretty sure even the Vulkan drivers are including
src/mesa/main/imports.h.  If we have two copies of src/mesa/main and the
headers begin to diverge, it's going to be a total disaster.  I would love
to see someone clean this all up properly and I think Mesa would be better
for it.  However, it is a LOT of work.

If we did the above cleaning, would I be ok with this approach?  Possibly.
However, I suspect it'd end up being the worst of both worlds.  We still
have maintenance of effectively two branches and bugfixes have to be
ported.  At the same time, we'd still have core changes to things like the
GLSL compiler breaking old drivers so we wouldn't lighten any of the
maintenance burden.


> > Option 2 is more acceptable to people who want to keep classic drivers
> in the tree and it can be done right now.
>
> These both seem pretty horrible to me right now. Like i965 still
> supports a lot of hardware that exists right now even if we move to
> iris.
>

I'm less concerned about the support burden.  When it comes to bugfixes, I
feel like most of the bugs on gen7 and earlier hardware at this point are
due to churn in the core and if it lives in a maintenance branch, we'll
stop breaking it.  The biggest thing we'd loose would be additional
features that we might get thanks to core changes.  The major ones that
come to mind are:

 - GL_ARB_gl_spirv (It could be enabled on gen7 in theory but we haven't
due to a lack of testing)
 - GL_EXT_direct_state_access (still underway last I knew)
 - GL_EXT_gpu_shader4
 - Compat context support

All four of those are more-or-less software-only features that older intel
drivers could pick up as the core advances.  Compat support likely requires
a bit of driver work but it should be doable.

The real question is, "How much do we care?"  I can't say I like the idea
of leaving Gen4-7 out in the cold.  Again, in a year's time, we might have
most of the above implemented and then it'd be less of a concern.


> I sorta feel there should be a
> 3) make life harder for classic drivers and optimise things more for
> gallium add more dd.h entrypoints, force the classic drivers to jump
> through hoops to degallium.
>

I'd be interested to see what that would look like.  I'm not actually
convinced that it would work if I'm honest.  Part of gluing them together
in my mind is deleting dd.h entirely and making the GL state tracker just
call gallium stuff.

There may be a 4th option here: Write a gallium driver for Intel Gen4-7.
Unfortunately, it would be a really hard sell to convince anyone (myself
included) that this is worth anyone's time.  Sure, it might be a fun
project, but the engineering effort required to get it to be as good as
i965 is very non-trivial.  I think it's tractable and someone who knows
what they're doing would probably be able to get something working in less
than a year if they steal heavily from i965 and iris.  However, getting it
to the point where performance is no worse may take longer.  While it'd
probably be a fun project for someone, I can't in good conscience say 

[Mesa-dev] gallium: rename "state tracker" to "api" in most places

[Marek Olšák]

Hi,

FYI, this is a pretty big change, so I'm posting it here as well:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2956

Only the GL state tracker will keep its name. All other state trackers will
be called "API implementations".

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Dave Airlie]

On Wed, 4 Dec 2019 at 10:39, Marek Olšák  wrote:
>
> Hi,
>
> Here are 2 proposals to simplify and better optimize the GL->Gallium 
> translation.
>
> 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> Classic drivers won't share any code with master. glvnd will load them, but 
> glvnd is not ready for this yet.
>
> 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main, 
> mesa/vbo, mesa/program, and drivers/dri/common need to be forked and 
> mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target 
> location.
>
> Option 2 is more acceptable to people who want to keep classic drivers in the 
> tree and it can be done right now.

These both seem pretty horrible to me right now. Like i965 still
supports a lot of hardware that exists right now even if we move to
iris.

I sorta feel there should be a
3) make life harder for classic drivers and optimise things more for
gallium add more dd.h entrypoints, force the classic drivers to jump
through hoops to degallium.

I don't like forking src/mesa/main/* because really 99% of it is just
a GL frontend implementation, most bugs in it will be in a fork and
vice-versa, I'd rather refine the abstraction between mesa and
backends if possible to reduce the overheads.

I'm probably not convinced that any benefit is worth accepting 1 or 2
above, but hey I've been persuaded before to do crazy things.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: Add support for midstream bitrate change in encoder

[Liu, Leo]

+Boyuan

From: Marek Olšák 
Sent: December 3, 2019 7:21:23 PM
To: Sahu, Satyajit ; Liu, Leo 
Cc: ML Mesa-dev ; Sharma, Deepak 

Subject: Re: [Mesa-dev] [PATCH] radeonsi: Add support for midstream bitrate 
change in encoder

+Leo

On Mon, Dec 2, 2019 at 11:31 PM Satyajit Sahu 
mailto:satyajit.s...@amd.com>> wrote:
Added support for bitrate change in between encoding.

Signed-off-by: Satyajit Sahu 
mailto:satyajit.s...@amd.com>>

diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
b/src/gallium/drivers/radeon/radeon_vce.c
index 84d3c1e2fa4..7d7a2fa4eb3 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -268,7 +268,8 @@ static void rvce_begin_frame(struct pipe_video_codec 
*encoder,
enc->pic.rate_ctrl.rate_ctrl_method != 
pic->rate_ctrl.rate_ctrl_method ||
enc->pic.quant_i_frames != pic->quant_i_frames ||
enc->pic.quant_p_frames != pic->quant_p_frames ||
-   enc->pic.quant_b_frames != pic->quant_b_frames;
+   enc->pic.quant_b_frames != pic->quant_b_frames ||
+   enc->pic.rate_ctrl.target_bitrate != 
pic->rate_ctrl.target_bitrate;

enc->pic = *pic;
si_get_pic_param(enc, pic);
diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc.c 
b/src/gallium/drivers/radeon/radeon_vcn_enc.c
index aa9182f273b..c4fb9a7bd92 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc.c
@@ -247,6 +247,17 @@ static void radeon_enc_begin_frame(struct pipe_video_codec 
*encoder,
 {
struct radeon_encoder *enc = (struct radeon_encoder*)encoder;
struct vl_video_buffer *vid_buf = (struct vl_video_buffer *)source;
+   bool need_rate_control = false;
+
+   if (u_reduce_video_profile(enc->base.profile) == 
PIPE_VIDEO_FORMAT_MPEG4_AVC) {
+   struct pipe_h264_enc_picture_desc *pic = (struct 
pipe_h264_enc_picture_desc *)picture;
+   need_rate_control =
+   enc->enc_pic.rc_layer_init.target_bit_rate != 
pic->rate_ctrl.target_bitrate;
+   } else if (u_reduce_video_profile(picture->profile) == 
PIPE_VIDEO_FORMAT_HEVC) {
+struct pipe_h265_enc_picture_desc *pic = (struct 
pipe_h265_enc_picture_desc *)picture;
+   need_rate_control =
+   enc->enc_pic.rc_layer_init.target_bit_rate != 
pic->rc.target_bitrate;
+   }

radeon_vcn_enc_get_param(enc, picture);

@@ -266,6 +277,10 @@ static void radeon_enc_begin_frame(struct pipe_video_codec 
*encoder,
flush(enc);
si_vid_destroy_buffer();
}
+   if (need_rate_control) {
+   enc->begin(enc, picture);
+   flush(enc);
+   }
 }

 static void radeon_enc_encode_bitstream(struct pipe_video_codec *encoder,
--
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Marek Olšák]

Hi,

Here are 2 proposals to simplify and better optimize the GL->Gallium
translation.

1) Move classic drivers to a fork of Mesa, and remove them from master.
Classic drivers won't share any code with master. glvnd will load them, but
glvnd is not ready for this yet.

2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main,
mesa/vbo, mesa/program, and drivers/dri/common need to be forked and
mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target
location.

Option 2 is more acceptable to people who want to keep classic drivers in
the tree and it can be done right now.

Opinions?

Thanks,
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: Add support for midstream bitrate change in encoder

[Marek Olšák]

+Leo

On Mon, Dec 2, 2019 at 11:31 PM Satyajit Sahu  wrote:

> Added support for bitrate change in between encoding.
>
> Signed-off-by: Satyajit Sahu 
>
> diff --git a/src/gallium/drivers/radeon/radeon_vce.c
> b/src/gallium/drivers/radeon/radeon_vce.c
> index 84d3c1e2fa4..7d7a2fa4eb3 100644
> --- a/src/gallium/drivers/radeon/radeon_vce.c
> +++ b/src/gallium/drivers/radeon/radeon_vce.c
> @@ -268,7 +268,8 @@ static void rvce_begin_frame(struct pipe_video_codec
> *encoder,
> enc->pic.rate_ctrl.rate_ctrl_method !=
> pic->rate_ctrl.rate_ctrl_method ||
> enc->pic.quant_i_frames != pic->quant_i_frames ||
> enc->pic.quant_p_frames != pic->quant_p_frames ||
> -   enc->pic.quant_b_frames != pic->quant_b_frames;
> +   enc->pic.quant_b_frames != pic->quant_b_frames ||
> +   enc->pic.rate_ctrl.target_bitrate !=
> pic->rate_ctrl.target_bitrate;
>
> enc->pic = *pic;
> si_get_pic_param(enc, pic);
> diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc.c
> b/src/gallium/drivers/radeon/radeon_vcn_enc.c
> index aa9182f273b..c4fb9a7bd92 100644
> --- a/src/gallium/drivers/radeon/radeon_vcn_enc.c
> +++ b/src/gallium/drivers/radeon/radeon_vcn_enc.c
> @@ -247,6 +247,17 @@ static void radeon_enc_begin_frame(struct
> pipe_video_codec *encoder,
>  {
> struct radeon_encoder *enc = (struct radeon_encoder*)encoder;
> struct vl_video_buffer *vid_buf = (struct vl_video_buffer *)source;
> +   bool need_rate_control = false;
> +
> +   if (u_reduce_video_profile(enc->base.profile) ==
> PIPE_VIDEO_FORMAT_MPEG4_AVC) {
> +   struct pipe_h264_enc_picture_desc *pic = (struct
> pipe_h264_enc_picture_desc *)picture;
> +   need_rate_control =
> +   enc->enc_pic.rc_layer_init.target_bit_rate !=
> pic->rate_ctrl.target_bitrate;
> +   } else if (u_reduce_video_profile(picture->profile) ==
> PIPE_VIDEO_FORMAT_HEVC) {
> +struct pipe_h265_enc_picture_desc *pic = (struct
> pipe_h265_enc_picture_desc *)picture;
> +   need_rate_control =
> +   enc->enc_pic.rc_layer_init.target_bit_rate !=
> pic->rc.target_bitrate;
> +   }
>
> radeon_vcn_enc_get_param(enc, picture);
>
> @@ -266,6 +277,10 @@ static void radeon_enc_begin_frame(struct
> pipe_video_codec *encoder,
> flush(enc);
> si_vid_destroy_buffer();
> }
> +   if (need_rate_control) {
> +   enc->begin(enc, picture);
> +   flush(enc);
> +   }
>  }
>
>  static void radeon_enc_encode_bitstream(struct pipe_video_codec *encoder,
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] GL_INTEL_performance_query & null hw query

[Lionel Landwerlin]

Meant to Cc Mark too :)

On 03/12/2019 21:24, Lionel Landwerlin wrote:

Hi all,

Our Windows drivers ships with a particular query in 
GL_INTEL_performance_query called Intel_Null_Hardware_Query.
The query doesn't report any counter. The query isn't even listed if 
you go through the list using glGetNextPerfQueryIdINTEL().

It's only returned using glGetPerfQueryIdByNameINTEL().
When active, this query turns the draw operations & compute dispatches 
into noop at the command streamer level.


Applications like GPA [1] have been using this query to detect 
bottlenecks on the CPU side since there is no work going beyond the 
front end of the rendering engine. So you still exercise the full 
stack (in our case i965/iris + i915).


To minimize the work of getting GPA fully supported on i965/iris we 
could implement the same behavior.
Last time I asked (probably on IRC), it was kind of a no-go because 
that is somewhat abusing the meaning/goal of queries (at the time, 
applications like frameretrace didn't deal very well with a query 
having no counters).
I'm not particularly kind on having this either but I would like to 
know other people's feel.


Alternatively we have another extension providing the same feature [2].
I sent patches for i965 a bit over 18months ago, but because people 
started to using a patch implementing the Windows driver behavior, 
this didn't get much traction.

This will a require a change on the GPA side but

Which way should we go?

-Lionel

[1] : https://software.intel.com/en-us/gpa
[2] : 
https://www.khronos.org/registry/OpenGL/extensions/INTEL/INTEL_blackhole_render.txt


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] GL_INTEL_performance_query & null hw query

[Lionel Landwerlin]

Hi all,

Our Windows drivers ships with a particular query in 
GL_INTEL_performance_query called Intel_Null_Hardware_Query.
The query doesn't report any counter. The query isn't even listed if you 
go through the list using glGetNextPerfQueryIdINTEL().

It's only returned using glGetPerfQueryIdByNameINTEL().
When active, this query turns the draw operations & compute dispatches 
into noop at the command streamer level.


Applications like GPA [1] have been using this query to detect 
bottlenecks on the CPU side since there is no work going beyond the 
front end of the rendering engine. So you still exercise the full stack 
(in our case i965/iris + i915).


To minimize the work of getting GPA fully supported on i965/iris we 
could implement the same behavior.
Last time I asked (probably on IRC), it was kind of a no-go because that 
is somewhat abusing the meaning/goal of queries (at the time, 
applications like frameretrace didn't deal very well with a query having 
no counters).
I'm not particularly kind on having this either but I would like to know 
other people's feel.


Alternatively we have another extension providing the same feature [2].
I sent patches for i965 a bit over 18months ago, but because people 
started to using a patch implementing the Windows driver behavior, this 
didn't get much traction.

This will a require a change on the GPA side but

Which way should we go?

-Lionel

[1] : https://software.intel.com/en-us/gpa
[2] : 
https://www.khronos.org/registry/OpenGL/extensions/INTEL/INTEL_blackhole_render.txt


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Hardware assisted (VDPAU) decoding of MPEG-2 causes GPU lockup on Radeon HD6320

[Will DeBerry]

>
> well that's the very first APU generation and unfortunately nobody is
> working on that old hardware any more.
>

Agreed, definitely old hardware. Unfortunately we have 10,000 of these
things in production and they have been playing hardware accelerated mpeg2
fine until we upgraded to Ubuntu 16.04 and the new mesa package. Now to be
specific, our previous version of linux on these systems we were using an
older software stack and video acceleration pipeline but it worked
perfectly, so we know the hardware is capable.

*Old Software Stack:*

   - vlc 2.1.5
   - mesa 11.0.6
   - va-api hardware acceleration
   - libva info: VA-API version 0.38.1
   libva info: va_getDriverName() returns 0
   libva info: Trying to open /usr/lib/va/drivers/r600_drv_video.so
   libva info: Found init function __vaDriverInit_0_35
   libva info: va_openDriver() returns 0
   vainfo: VA-API version: 0.38 (libva 1.6.2)
   vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for
   VA-API - 0.7.4
   vainfo: Supported profile and entrypoints
 VAProfileMPEG2Simple: VAEntrypointVLD
 VAProfileMPEG2Main  : VAEntrypointVLD
 VAProfileMPEG4Simple: VAEntrypointVLD
 VAProfileMPEG4AdvancedSimple: VAEntrypointVLD
 VAProfileH264Baseline   : VAEntrypointVLD
 VAProfileH264Main   : VAEntrypointVLD
 VAProfileH264High   : VAEntrypointVLD
 VAProfileVC1Simple  : VAEntrypointVLD
 VAProfileVC1Main: VAEntrypointVLD
 VAProfileVC1Advanced: VAEntrypointVLD

*New Software Stack:*

   - vlc 2.2.2
   - mesa 18.2.8-2~bpo9+1
   - vdpau hardware acceleration

The reason we had to switch to VDPAU with Ubuntu 16.04 is that we saw a
major regression with mpeg2 playback using va-api. It was capable of
playing back mpeg4 without any issues. Now that we have switched to VDPAU
however, we are seeing this GPU thread lockup bug and thus causing X and
other GUI related programs to crash and requiring a reboot to recover.

Changing out hardware for the next best thing is not an option at our scale
and we know that the hardware is capable due to past experiences. We are
just in need of assistance with someone or some party that knows that stack
a lot more than us to help dig to the core issue of the lockup or help us
get VA-API working for mpeg2 in 16.04.

So the best approach is probably to not use hardware acceleration for MPEG2
> clips in general.
>

With software decoding, the performance doesn't produce something that is
watchable. One interesting tidbit to note. During our testing we put Ubuntu
19.10 on one of these boxes and noticed that full software acceleration has
improved to the point that VA-API nor VDPAU was required for VLC to render
the mpeg2 and mpeg4 streams correctly. Is this something that could
potentially be backported to Ubuntu 16.04? I know this is a much bigger
task that the one sentence ask alludes to, but figured I'd ask anyway.

We are more than welcome to work together on this, especially since the
hardware is older and probably hard to find. Just needing to find a
solution so we can move forward on upgrading the software and on these
older hardware.

On Thu, Nov 28, 2019 at 7:15 AM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:

> Hi Will,
>
> well that's the very first APU generation and unfortunately nobody is
> working on that old hardware any more.
>
> MPEG2 is known to not be fully supported by that chipset in general. So
> the best approach is probably to not use hardware acceleration for MPEG2
> clips in general.
>
> Regards,
> Christian.
>
> Am 27.11.19 um 18:35 schrieb Will DeBerry:
>
> Hi all,
>
> I am reaching out hoping to get some assistance with resolving a bug/crash
> that we see with the GPU when using VDPAU hardware acceleration on Ubuntu
> 16.04. This is specific to the r600 drivers interacting with VDPAU when
> trying to playback certain mpeg2 content.
>
> *GPU in question per lscpi: *
> 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
> Wrestler [Radeon HD 6320]
>
> We are highly invested in this GPU and would love to get this addressed as
> soon as possible and are also willing to sponsor this work if needed.
>
> *Steps to Recreate:*
>
>1. Launch VLC with VDPAU hardware acceleration and deinterlacing
>enabled
>2. Play the attached piece of known bad content
>3. Wait for GPU lockup
>
> Per dmesg, the GPU thread gets locked up within the kernel and thus breaks
> all GUI related activities until the PC is rebooted.
>
> *Mesa Version Tested:*
> 18.0.5-0ubuntu0~16.04.1
> 18.2.8-2~bpo9+1
>
> Let me know if you have any questions or are interested in discussing this
> further.
>
> Thanks,
>
> --
>
> *Will DeBerry*
>
> Manager, Client Devices
>
> GetWellNetwork
>
> o: 240.482.4237 | m: 813.330.0121 | getwellnetwork.com
> 
>
> 

Re: [Mesa-dev] Hardware assisted (VDPAU) decoding of MPEG-2 causes GPU lockup on Radeon HD6320

[Will DeBerry]

>
> Are you sure that the Gentoo based setup isn't software decoding based?
>

Yes 100% confident. We configured VLC to use VA-API decoding with software
based deinterlacing. The VA-API implementation is using the VDPAU backend
shim as shown in the vainfo output: *vainfo: Driver version:
Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.4.*

I would investigate this way. 1920x1080 is not a high resolution and should
> decode with the CPU just fine.


We know that software decoding on Ubuntu 16.04 does not produce something
that is watchable in quality. There are frame drops and
noticeable choppiness to the playback. Also since it was brought up
previously, using a different player doesn't result in any different
outcomes. This is specifically the case with mpeg4 playback. No software
based decoding solutions have been suitable here, but it is to be known
that mpeg4 has not shown itself to create the VDPAU GPU lockup. Continuing
to use VDPAU for mpeg4 is fine in this case.

We are totally open to changing the video decoding pipelines to avoid the
VDPAU GPU bug altogether but nothing outside of VDPAU produces the quality
that we could ship and put in front of people. We have the hardware and
available known video snippets that cause the VDPAU GPU lock up if someone
wants to dig in and see what's going on or have a stab at a good work
around.

On Mon, Dec 2, 2019 at 3:11 PM Christian König 
wrote:

> Well how was the stack configured then? Pure software playback?
>>
>
> In 19.10, yes the whole stack was told to use software playback and
> decoding.
>
>
> I would investigate this way. 1920x1080 is not a high resolution and
> should decode with the CPU just fine.
>
> Our older Gentoo based setup with the old software stack worked fine
>
>
> The hardware generally does not support some interlaced frame/field
> features rarely used in todays MPEG2 streams and a software fallback isn't
> easily doable with VA-API/VDPAU and so was never implemented.
>
> Are you sure that the Gentoo based setup isn't software decoding based?
>
> Regards,
> Christian.
>
> Am 02.12.19 um 16:02 schrieb Will DeBerry:
>
> What regression was that? The difference between VDPAU and VA-API is only
>> marginal for codec support.
>>
>
> The regression revolved around deinterlacing the content. If we had to
> deinterlace 1080i for instance, the playback was very choppy and dropped
> frames.
>
> Well how was the stack configured then? Pure software playback?
>>
>
> In 19.10, yes the whole stack was told to use software playback and
> decoding.
>
> As long as you don't do any high resolution H264 decoding the CPU in that
>> package should be capable of decoding both MPEG2 and MPEG4 with software
>> decode.
>>
>
> That's part of the problem. We do have high resolution (1920x1080) mpeg2
> at the places we are installed. We have no control over what content is
> available but have to support it.
>
> Our older Gentoo based setup with the old software stack worked fine but
> the Ubuntu 16.04 stack does not playback the same content without having to
> switch to VDPAU and thus introduce the GPU thread lockup issue. Ubuntu
> 18.04 looks to have the same VDPAU GPU lockup issue as well and cannot use
> software playback/decoding successfully.
>
> On Mon, Dec 2, 2019 at 9:16 AM Christian König 
> wrote:
>
>> The reason we had to switch to VDPAU with Ubuntu 16.04 is that we saw a
>> major regression with mpeg2 playback using va-api.
>>
>> What regression was that? The difference between VDPAU and VA-API is only
>> marginal for codec support.
>>
>> During our testing we put Ubuntu 19.10 on one of these boxes and noticed
>> that full software acceleration has improved to the point that VA-API nor
>> VDPAU was required for VLC to render the mpeg2 and mpeg4 streams correctly.
>>
>> Well how was the stack configured then? Pure software playback?
>>
>> As long as you don't do any high resolution H264 decoding the CPU in that
>> package should be capable of decoding both MPEG2 and MPEG4 with software
>> decode.
>>
>> In general I would also try with mpv instead of vlc to rule out player
>> issues.
>>
>> Regards,
>> Christian.
>>
>> Am 02.12.19 um 15:06 schrieb Will DeBerry:
>>
>> well that's the very first APU generation and unfortunately nobody is
>>> working on that old hardware any more.
>>>
>>
>> Agreed, definitely old hardware. Unfortunately we have 10,000 of these
>> things in production and they have been playing hardware accelerated mpeg2
>> fine until we upgraded to Ubuntu 16.04 and the new mesa package. Now to be
>> specific, our previous version of linux on these systems we were using an
>> older software stack and video acceleration pipeline but it worked
>> perfectly, so we know the hardware is capable.
>>
>> *Old Software Stack:*
>>
>>- vlc 2.1.5
>>- mesa 11.0.6
>>- va-api hardware acceleration
>>- libva info: VA-API version 0.38.1
>>libva info: va_getDriverName() returns 0
>>libva info: Trying to open 

Re: [Mesa-dev] Hardware assisted (VDPAU) decoding of MPEG-2 causes GPU lockup on Radeon HD6320

[Will DeBerry]

>
> What regression was that? The difference between VDPAU and VA-API is only
> marginal for codec support.
>

The regression revolved around deinterlacing the content. If we had to
deinterlace 1080i for instance, the playback was very choppy and dropped
frames.

Well how was the stack configured then? Pure software playback?
>

In 19.10, yes the whole stack was told to use software playback and
decoding.

As long as you don't do any high resolution H264 decoding the CPU in that
> package should be capable of decoding both MPEG2 and MPEG4 with software
> decode.
>

That's part of the problem. We do have high resolution (1920x1080) mpeg2 at
the places we are installed. We have no control over what content is
available but have to support it.

Our older Gentoo based setup with the old software stack worked fine but
the Ubuntu 16.04 stack does not playback the same content without having to
switch to VDPAU and thus introduce the GPU thread lockup issue. Ubuntu
18.04 looks to have the same VDPAU GPU lockup issue as well and cannot use
software playback/decoding successfully.

On Mon, Dec 2, 2019 at 9:16 AM Christian König 
wrote:

> The reason we had to switch to VDPAU with Ubuntu 16.04 is that we saw a
> major regression with mpeg2 playback using va-api.
>
> What regression was that? The difference between VDPAU and VA-API is only
> marginal for codec support.
>
> During our testing we put Ubuntu 19.10 on one of these boxes and noticed
> that full software acceleration has improved to the point that VA-API nor
> VDPAU was required for VLC to render the mpeg2 and mpeg4 streams correctly.
>
> Well how was the stack configured then? Pure software playback?
>
> As long as you don't do any high resolution H264 decoding the CPU in that
> package should be capable of decoding both MPEG2 and MPEG4 with software
> decode.
>
> In general I would also try with mpv instead of vlc to rule out player
> issues.
>
> Regards,
> Christian.
>
> Am 02.12.19 um 15:06 schrieb Will DeBerry:
>
> well that's the very first APU generation and unfortunately nobody is
>> working on that old hardware any more.
>>
>
> Agreed, definitely old hardware. Unfortunately we have 10,000 of these
> things in production and they have been playing hardware accelerated mpeg2
> fine until we upgraded to Ubuntu 16.04 and the new mesa package. Now to be
> specific, our previous version of linux on these systems we were using an
> older software stack and video acceleration pipeline but it worked
> perfectly, so we know the hardware is capable.
>
> *Old Software Stack:*
>
>- vlc 2.1.5
>- mesa 11.0.6
>- va-api hardware acceleration
>- libva info: VA-API version 0.38.1
>libva info: va_getDriverName() returns 0
>libva info: Trying to open /usr/lib/va/drivers/r600_drv_video.so
>libva info: Found init function __vaDriverInit_0_35
>libva info: va_openDriver() returns 0
>vainfo: VA-API version: 0.38 (libva 1.6.2)
>vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for
>VA-API - 0.7.4
>vainfo: Supported profile and entrypoints
>  VAProfileMPEG2Simple: VAEntrypointVLD
>  VAProfileMPEG2Main  : VAEntrypointVLD
>  VAProfileMPEG4Simple: VAEntrypointVLD
>  VAProfileMPEG4AdvancedSimple: VAEntrypointVLD
>  VAProfileH264Baseline   : VAEntrypointVLD
>  VAProfileH264Main   : VAEntrypointVLD
>  VAProfileH264High   : VAEntrypointVLD
>  VAProfileVC1Simple  : VAEntrypointVLD
>  VAProfileVC1Main: VAEntrypointVLD
>  VAProfileVC1Advanced: VAEntrypointVLD
>
> *New Software Stack:*
>
>- vlc 2.2.2
>- mesa 18.2.8-2~bpo9+1
>- vdpau hardware acceleration
>
> The reason we had to switch to VDPAU with Ubuntu 16.04 is that we saw a
> major regression with mpeg2 playback using va-api. It was capable of
> playing back mpeg4 without any issues. Now that we have switched to VDPAU
> however, we are seeing this GPU thread lockup bug and thus causing X and
> other GUI related programs to crash and requiring a reboot to recover.
>
> Changing out hardware for the next best thing is not an option at our
> scale and we know that the hardware is capable due to past experiences. We
> are just in need of assistance with someone or some party that knows that
> stack a lot more than us to help dig to the core issue of the lockup or
> help us get VA-API working for mpeg2 in 16.04.
>
> So the best approach is probably to not use hardware acceleration for
>> MPEG2 clips in general.
>>
>
> With software decoding, the performance doesn't produce something that is
> watchable. One interesting tidbit to note. During our testing we put Ubuntu
> 19.10 on one of these boxes and noticed that full software acceleration has
> improved to the point that VA-API nor VDPAU was required for VLC to render
> the mpeg2 and mpeg4 streams correctly. Is this something