On Friday, October 11, 2013 5:50:05 AM UTC+13, Benoit Girard wrote: > 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. >
I think almost the opposite :-) I am not sure if it is true that switching shaders is expensive - my understanding is that it is common in games to have many more shaders than we have and to switch them more frequently - and that is what GPUs are optimised for. Perhaps Dan G can confirm or refute that. The advantage to me is that we have a single shader and avoid the combinatorial explosion when we add more shaders for things like SVG filters/CSS compositing. That may well be worth a performance hit to facilitate. There may also be other options - there is prior art here, the search term is 'shader permutations' (I looked into this a little 18 months ago, but do not remember if I found anything useful). We should explore all options before jumping on this, I think. In terms of performance - there is a trade off here between branching and switching shaders, both of which are 'known' to be slow and also known to have been optimised in some GPUs/drivers. So we need to do some serious investigation to find out where the better perf is. In particular I think this may be a case where low end mobile GPUs and very old GPUs (the two areas where we really care about perf) may have very different characteristics. So, the right answer for b2g may not be the right answer for Firefox on Windows XP. I have not recently been discussing new shaders, perhaps you are thinking of mstange who is looking at HW implementations of SVG filters? > 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
