On Mon, Feb 6, 2017 at 11:48 PM, Marek Olšák <mar...@gmail.com> wrote: > On Mon, Feb 6, 2017 at 9:27 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote: >> Hello >> >> I am against application profiles - in the form of "a >> community-maintained whitelist of apps" or in any other form >> explicitly associating the name/ID of an app with a Mesa variable >> which controls the behavior of Mesa. >> >> Application profiles would be a manifestation of poor algorithms in >> the OpenGL implementation. > > No, it's called incremental progress. > > The Mesa community doesn't have resources to develop a multithreaded > solution that is perfect from day 1. Incremental progress will get us > there eventually. Or not. But it's the only way to get somewhere with > our limited resources. > > Marek
No. The point is: You are proposing a transient solution that isn't automated (i.e: a solution that isn't resembling machine learning in any way). https://en.wikipedia.org/wiki/Machine_learning Instead, why don't you introduce a simple C/C++ variable controlling whether to use glthread? The variable needs to be initially fed with simple statistics about whether glthread has positive or negative effect on performance. The simple statistics can be obtained from alternate frame rendering: // Machine learning bool use_thread = 0; float fps[2] = {}; for i=0; i<1000; i++ { if use_thread render the frame with glthread=on else render the frame with glthread=off fps[use_thread] += 1.0 / frame_time; use_thread = 1 - use_thread; } const bool glthread_means_higher_fps = (fps[1] > fps[0]); // Using the learned information while(1) { if glthread_means_higher_fps render the frame with glthread=on else render the frame with glthread=off } The above solution would be totally simple to implement in Mesa. A human-maintained whitelist is clearly a subpar solution due to multiple factors. Jan _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
