Hi Christian,
 
We have enabled vsync, hence we wait for page flip and renderer will block.
 
I prefer having control at the application level. If all goes easy and you don't
push the system to its limits, all fine. The fun part starts if you have to skip
decoding cycles or drop frames to catch up from being late. Or playing i.e.
60fps material on a 30hz screen.
I want to make sure that decoding has finished before I schedule a frame for
rendering.
 
Regards,
Rainer
 
Gesendet: Sonntag, 11. Februar 2018 um 19:23 Uhr
Von: "Christian König" <christian.koe...@amd.com>
An: "rainer.hochec...@onlinehome.de" <rainer.hochec...@onlinehome.de>
Cc: "Philipp Kerling" <pkerl...@casix.org>, s...@jkqxz.net, peter.fruehber...@gmail.com, mic...@daenzer.net, mesa-dev@lists.freedesktop.org, harry.wentl...@amd.com, lru...@libreelec.tv
Betreff: Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI v2
Hi Rainer,

well at the end of the pipeline the page flip waits for all previous operations on a buffer to be completed before displaying it. But even that wait is asynchronous.

So as long as you don't wait for the page flip your render thread won't be blocked.

Using vaSyncSurface is only good in two occasions:
1. You want to access the data with the CPU. And even then it is not necessary most of the time because of how Mesa is designed.
2. You need to limit how many jobs are in flight. Depending on how you do resource management that is necessary to prevent the application from scheduling mass amount of jobs and running away with all the resources for that.

Regards,
Christian.

Am 11.02.2018 um 13:26 schrieb rainer.hochec...@onlinehome.de:
Hi Christian,
 
Finally something in the render pipeline has to wait until decoding is finished or the
frame can't be rendered and this will result in blocking the render thread.
 
Regards,
Rainer
 
Gesendet: Sonntag, 11. Februar 2018 um 13:13 Uhr
Von: "Christian König" <christian.koe...@amd.com>
An: "rainer.hochec...@onlinehome.de" <rainer.hochec...@onlinehome.de>
Cc: "Philipp Kerling" <pkerl...@casix.org>, s...@jkqxz.net, peter.fruehber...@gmail.com, mic...@daenzer.net, mesa-dev@lists.freedesktop.org, harry.wentl...@amd.com, lru...@libreelec.tv
Betreff: Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI v2
Hi Rainer,

the render thread doesn't wait either.

See when you dispatch some work the AMD drivers always wait for prerequisites in the background, not in the foreground.

The older radeon driver uses hardware semaphores for this while amdgpu has a GPU scheduler which handles that stuff.

This is very important because when you hold back rendering work in the application the driver stack won't know about it and power management starts to stutter.

Not so important for 1920p because power management should be able to compensate the work peaks, but for 4K that's something mandatory to let the driver be able to estimate future load.

We even discussed in our multimedia meeting if we shouldn't limit 3D power management when UVD/VCN decoding is active because of that problem. But I'm not very keen about those workarounds because it's really counterproductive for transcode use cases to have the 3D engine idling around with high clocks.

Regards,
Christian.

Am 11.02.2018 um 12:51 schrieb rainer.hochec...@onlinehome.de:
Hi Christian,
 
For Kodi it is better to wait on the thread that does decoding than later 
by the render thread. Means it is desired to call it.
 
Does vaSyncSurface block as stated by the docs?
 
Regards,
Rainer
 
Gesendet: Sonntag, 11. Februar 2018 um 11:02 Uhr
Von: "Christian König" <christian.koe...@amd.com>
An: "Philipp Kerling" <pkerl...@casix.org>, s...@jkqxz.net
Cc: rainer.hochec...@onlinehome.de, peter.fruehber...@gmail.com, mic...@daenzer.net, mesa-dev@lists.freedesktop.org, harry.wentl...@amd.com, lru...@libreelec.tv
Betreff: Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI v2
Am 09.02.2018 um 21:35 schrieb Philipp Kerling:
> Hi,
>
> resurrecting this thread again since there's been some progress on the
> Kodi side.
>
>> For the EGL part, see <https://github.com/01org/libva/pull/125>
>> and <https://lists.freedesktop.org/archives/mesa-dev/2017-October/171246.html>.
> We recently started testing vaExportSurfaceHandle support, so we will
> have this covered soon.
>
>> I have been testing with mpv and ffmpeg; any thoughts from the
>> Kodi point of view would be most welcome.
> It generally works quite well, but we still have the unresolved
> vaSyncSurface problem.
> To recap: vaExportSurfaceHandle requires calling vaSyncSurface to make
> sure that the decode is actually finished and the buffer is usable
> before rendering the frame. However, vaSyncSurface was largely
> unimplemented on mesa back then and it was unclear how to proceed with
> regard to decode (VAAPI)/present (EGL+GL) synchronization.
>
> So on to the question: Is this still the case, or has there been
> progress on implementing vaSyncSurface in mesa? In either case, do we
> need that support or does this syncing work implicitly somehow on AMD?
>
> I've noticed that mpv does not seem to call vaSyncSurface, although it
> technically should.

Actually the mpv approach is correct.

Calling vaSyncSurface is unnecessary and undesired for AMD hardware
because it moves synchronization to the CPU while it should happen on
the GPU and/or GPU scheduler.

E.g. our 3D pipeline can wait for hardware video decoding to finish
before starting the rendering. We even have some implementations which
allow the 3D pipeline to start when only the first halve of the picture
is decoded etc..

If we don't do this the 3D pipeline runs dry between frame decoding
which leads to problems with power management.

We should probably add a flag or bit or feature or something like this
to note that the application explicitly should NOT call vaSyncSurface
before exporting the surface.

Regards,
Christian.

>
> Best regards,
> Philipp
> _______________________________________________
> 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

Reply via email to