So after an off-line chat with Christian we decided to drop this series, since I don't have the cycles to fix this up.
For completeness, if anybody decides at some point to (re)use some of the code, some comments below. On 03/03/2017 01:32 PM, Christian König wrote: > Hi Thomas, > > Am 02.03.2017 um 21:00 schrieb Thomas Hellstrom: >> This patch series introduces a postprocessor abstraction. It could be >> promoted >> to a gallium interface but for now it's implemented as a utility. > > Well, first of all use a gallium interface for this. Putting this into > utility doesn't look like it makes much sense when it is supposed to > be a driver interface. > >> The idea >> is that a driver wanting to implement the whole or part of the >> postprocessing >> pipeline using video hardware can do that. It also significantly >> simplifies >> implementing a future full postprocessor pipeline also in the libVA >> state tracker. >> >> Some highlights: >> - The postprocessor abstraction is very similar to the vl compositor >> API, >> except it add filters. > > NAK on that, we already had that design and it was a pain to support. > > If you want to implement parts of the post processing pipeline in the > driver make each pipeline step a separate object. The compositor API very well suited our needs and was very easy and straightforward to work with. I guess mostly because it resembles the postprocessing pipeline of both VAAPI, VDPAU and DXVA/D3D11. > >> - The bounce buffer cache. Caches buffers where we know more about >> the usage. >> This may duplicate driver functionality but for drivers with strongly >> typed >> buffers, it's a big win. > > That's similar to what I've done for the video buffers, but in general > I think that this doesn't belong into the state tracker. > > The driver should implement buffer reuse if it can do this without > problems, but how many buffers should be in there and when they are > reclaimed is strongly hardware dependent. True. Although for drivers with strongly typed buffers, that becomes difficult since caches needs to be quite large to facilitate hits. The caching needs for this pipeline is also special in that the number of cached buffers is small very predictable and there's no need to wait for idle before reusing buffers... > >> - Moving the bicubic filter. Avoids duplicated code and makes things >> like >> rotation and blending straightforward. > > A BIG NAK on that as well. The bicubic filter doesn't work on all > hardware, so creating the shaders all the time while it isn't use is > clearly not an option. > > Additional to that I would rather remove functionality from the > compositor than stuffing even more into it. Compiling on-demand is an easy fix. Having all scaling options in one place logically and physically seemed attractive and helped avoiding unwanted behaviour like filtering overlaid or already scaled surfaces and video-background borders, double scaling of overlay surfaces. Also enabled blending and rotation. Thanks, Thomas > >> - A g3dvl implementation. Mostly replicates the old implementation >> using the >> vl compositor, but with provisions to replace part of the postprocessing >> pipeline. >> - State tracker modifications for VDPAU and VA. >> >> - Tested with mplayer -vo vdpau software playback on Nouveau. > > Please test that with radeon hardware as well if possible. Nouveau > doesn't fully support all the functionality and project like Kodi > don't test with it. > > Regards, > Christian. > >> >> >> _______________________________________________ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=DwICaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=GDt3ZtrRjpa7Se4bsMYXF18gBs6IXAqtSW_3Y3df0Bs&s=-HnyAt6aoAvWpesLw7KAHyyQmiJVv43cJNL7VmIjOh0&e= > > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev