On Thu, May 04, 2017 at 07:46:34PM -0700, Dmitry Rogozhkin wrote: > > > On 5/4/2017 9:51 AM, Kenneth Graunke wrote: > > MediaSDK is not a benchmark. If I'm not mistaken, it's a userspace > > driver produced by Intel engineers, one which Intel has the full > > capability to change. What you're saying is that Intel's MediaSDK > > engineers are unwilling to change their software to provide better > > performance for their Linux users. > > > > That's pretty mental. > You are mistaken. Media SDK is not a driver. It is a user space library > which talks to the user space driver. And Media SDK does not set _any_ > caching policies you are discussing here. That's the driver who sets these > policies. I don't want to go further here who supports this driver, Intel or > not, but there are mediasdk engineers whom you blame to not willing to do > something and who actually only indirectly are related to this topic. > Please, if you mean driver, say a driver. You are right. It is very unfortunate that those two were confused. To further clarify, here's an excerpt from MediaSDK's README.md: "Intel Media SDK depends on a special version of LibVA which comes with Intel Media Server Studio installation and is not in upstream, so this version is not compatible with the LibVA/driver available at 01org." Nonetheless, the main question still stands: How big is the performance gap when using appropriate, existing entries entries vs the entries proposed here? Also a couple more questions arise: * What about versioning schema? We definitely need a consumer for that. * The libva you use is a **closed** UMD. It this enough of a reason to do the change (sans the versioning)? It starts to get blurry here. Don't get me wrong, I've seen the spec and believe that a lot of hard work was put into determining the entries and the usage scenarios, and that they can benefit us. I even have some patches ready[0] and I would love to get them upstream, but they have to be tested in reproducible manner, with clear methodology. They need to be discussed and deemed useful by providing real value. We cannot simply relay on opaque claims that they are good for us. To do the above I am fiddling with Mesa - if we will see performance boost, then this would provide both a solid reason to add the entries and a consumer for the versioning API. As of proprietary libva/MediaSDK combo I see at least three options to do "the 3" vs "extended mocs" testing: 1. change the libva you use to utilize only the basic 3 entries only and do the testing - if you can change the source 2. change kernel and fill in entries with copies of the 3 basic ones and do the testing - will work even without the source code of libva 3. port the MOCS changes to 01org's libva and either use this version from MediaSDK for testing or use some other benchmarks - this could be the consumer we need I hope that this will move us forward. [0]: https://github.com/ivyl/linux/commits/mocs -- Cheers, Arek _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
