On Jun 1, 2016 7:43 AM, "Eero Tamminen" <<a href="mailto:eero.t.tamminen@intel.com">eero.t.tamminen@intel.com</a>> wrote: > > Hi, > > > On 01.06.2016 16:53, Marek Olšák wrote: >> >> On Wed, Jun 1, 2016 at 3:02 PM, ⚛ <<a href="mailto:0xe2.0x9a.0x9b@gmail.com">0xe2.0x9a.0x9b@gmail.com</a>> wrote: >>> >>> On Wed, Jun 1, 2016 at 2:19 PM, Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote: >>>> >>>> I'll let you figure it out by yourself. >>> >>> >>> Why would you withhold information if you already have it? Are you a >>> "bad person" or something? >>> >>> As far as my memory goes, I have never posted the sentence "I'll let >>> you figure it out by yourself" to the Internet because I believe it is >>> wrong. >> >> >> :) >> >> Shader compilation at game loading time is never a problem, so we can >> ignore that. > > > Startup time may not be a problem for games (some gamers may disagree), but there are also devices which have legal / certification requirements for startup times, where shader compilation time could be a problem, especially as Mesa shader compilation tends to get slower over time (as compiler does more optimizations). Again, a problem with a different solution: Properly implementing glGetProgramBinary which should be pretty easy once the Timothy is done with the shader cache. > Those devices have pretty static content (at least for startup), so their shaders could be pre-compiled if 3D driver supports that and has offline compiler. Many proprietary drivers do, Mesa doesn't, at least not yet. You don't need an offline compiler. The developer of said app just needs to regenerate their program binaries after the update the driver. Not trying to be negative here. Just pointing out that delayed compilation isn't the best solution to that problem either. At one point in the past, I did consider a crazy scheme in which the driver did a quick-and-dirty compile up-front and then did a longer, better optimized, compile in the background. That idea may still have some merit, bit it's going to take a *lot* more plumbing in the front and back ends than just putting std::future on a field in gl_program. >> Shader compilation right before draw calls is what's unpleasant and >> when people talk about it in the negative sense, they mean this. >> >> Because of external factors you can't predict, your driver suddenly >> receives a bunch of shaders that take 2000 ms to compile right before >> a draw call. Your budget is 16 ms per frame to get 30 fps, but you >> can't render the frame if you don't compile those shaders. The problem >> is how to fit the compilation that takes 2000 ms and is required >> render the frame into 16 ms. Can you see where I'm going? > > > Besides application itself compiling a shader, some state change done by application may also trigger shader recompile in Mesa. While for application requested compilation nothing can be done to squeeze it into 16ms, there are some chances of reducing need for state-change triggered recompiles (and these improvements have been done to Mesa during the years). > > > - Eero > > > _______________________________________________ > mesa-dev mailing list > <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> > <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a>