I'll pile on what Benoit G said --- this is the kind of work that would require very careful performance measurements before we commit to it.
Also, like Benoit said, we have seen no indication that glUseProgram is hurting us. General GPU "wisdom" is that switching programs is not per se expensive as long as one is not relinking them, and besides the general performance caveat with any state change, forcing to split drawing into multiple draw-calls, which also applies to updating uniforms, so we're not escaping it here. In addition to that, not all GPUs have real branching. My Sandy Bridge Intel chipset has real branching, but older Intel integrated GPUs don't, and I'd be very surprised if all of the mobile GPUs we're currently supporting did. To put this in perspective, in the world of discrete desktop NVIDIA GPUs, this was only introduced in the Geforce 6 series. Old, but a lot more advanced that some integrated/mobile devices we still support. On GPUs that are not capable of actual branching, if...else blocks are implemented by executing all branches and masking the result. On such GPUs, a "unified shader" would run considerably slower, basically N times slower for N branches. Even on GPUs with branching, each branching has a cost and we have N of them, so in all cases the "unified shader" approach introduces new (at least potential) scalability issues. So if we wanted to invest in this, we would need to conduct careful benchmarking on a wide range of hardware. Benoit 2013/10/10 Benoit Girard <bgir...@mozilla.com> > On Thu, Oct 10, 2013 at 7:59 AM, Andreas Gal <andreas....@gmail.com> > wrote: > > > Rationale: > > switching shaders tends to be expensive. > > > > In my opinion this is the only argument for working on this at moment. > Particularly at the moment where we're overwhelmed with high priority > desktop and mobile graphics work, I'd like to see numbers before we > consider a change. I have seen no indications that we get hurt by switching > shaders. I suspected it might matter when we start to have 100s of layers > in a single page but we always fall down from another reason before this > can become a problem. I'd like to be able to answer 'In which use cases > would patching this lead to a user measurable improvement?' before working > on this. Right now we have a long list of bugs where we have a clear answer > to that question. Patching this is good to check off that we're using the > GPU optimally on the GPU best practice dev guides and will later help us > batch draw calls more aggressively but I'd like to have data to support > this first. > > Also old Android drivers are a bit touchy with shaders so I recommend > counting some dev times for resolving these issues. > > I know that roc and nrc have some plans for introducing more shaders which > will make a unified shader approach more difficult. I'll let them weight in > here. > > On the flip side I suspect having a single unified shader will be faster to > compile then the several shaders we have on the start-up path. > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
