On Friday, May 5, 2017 9:21:54 AM PDT Dmitry Rogozhkin wrote: > > My point largely stands, when redirected - someone is developing a > > broken closed source userspace driver and is apparently unwilling to > > change it. That's the real problem. > Broken? Have you ever attempted to run functional and performance > competitive between closed source and open source user space drivers? I > attempted and a number of others have attempted that. Result is that > open source driver has significantly worse encoding quality, worse to > the degree that any performance comparisons start to make no sense. > (Yep, work in progress to try to fix that, I know.) Decoding quality is > on par, but I saw cases when performance is 5-10% worse (and that's when > both drivers work on their presumably optimal settings). So, "broken" > closed source driver is in use for the _reason_. And which driver could > be considered "broken" after that: closed source one or open source one? I'm not in any way arguing that one driver is superior to the other, nor that anyone should do performance comparisons between the two. > So, why you are addressing that closed source driver is broken? If it > will be put in the environment with the upstream kernel, then it will > eventually be broken and that's what we are trying to fix here. But do > you realize that in the production environment where the driver is > intended to work there is a patched kernel mode driver in place with the > MOCS settings to satisfy the need of the driver? Or you naively think we > use non-modified KMD from the upstream or previously released versions > from kernel.org. Bad guess! In the production environment driver is not > broken. Yes, I'm aware that the closed source userspace relies on a patched non-upstream kernel, and that it's being used in some environments. Presumably it works just fine there. Isn't the goal to make that userspace driver run on the upstream Linux kernel, so people can use it in places other than the environment where it currently exists? Would it not make sense to have it run reasonably well on upstream kernels that are currently shipping? On released upstream kernels, there are only three MOCS entries: UC, PTE, and WB. Using any other entries is ill-advised (even broken), not only because they currently correspond to UC (leading to poor performance), but because they may change meaning in the future. Future upstream kernels may add new entries, and presumably would advertise that via a getparam (i.e. I915_PARAM_MOCS_TABLE_VERSION). The suggestion is to make your userspace driver use entry 2 (WB) for anything you want cached, when running on an upstream kernel (but keep using the existing entries on the patched kernel). That would perform much better than it currently does. You probably won't get the full 60%, but perhaps you'll get 50%. Then, add any additional entries you want to the kernel, advertise it via a GETPARAM, and make your driver use those new entries when they are supported. Benchmark. See how much faster your workload is with the new entries (compared to WB-for-everything). That's the number everyone here wants to see. This should be a trivial amount of work - nobody's asking for any combinatorial explosion of testing. Doing this exercise also means that your software would perform better on currently shipping upstream kernels (arguably improving the driver) - and once you have the full set of entries, it will perform even better. Does that make sense? --Ken
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
