On Fri, May 05, 2017 at 01:31:37PM +0200, Arkadiusz Hiler wrote: > 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. Michal (W or W) has some patches to allow contexts to set their own mocs, which is definitely my preferred solution. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
