2013/5/1 Robert O'Callahan <rob...@ocallahan.org> > On Wed, May 1, 2013 at 4:11 PM, Andreas Gal <g...@mozilla.com> wrote: > > > I wonder whether we should focus on one fast GPU path via GLSL, and have > > one precise, working, I-don't-care-how-slow CPU fallback. > > > I agree that should be our top priority, and it may not be worth doing CPU > SIMD at all. But if we can get it cheaply via Skia or somewhere else, maybe > it's worth having. I didn't mean to imply CPU SIMD should be a priority. > > As for the filters on GLContext, I wonder whether thats really the best > > approach. Don't most filter applications want to be injected into the > > shader pipeline instead? We would have to be able to compose filters for > > that and generate a composite GLSL program from that. So for example we > > want a BGRXTextureLayer, with Mask3D, with ColorMatrix, and we want GLSL > > source generated from that. So isn't really what we want a GLSL shader > > program generator (and cache) that we give an EffectChain and that gives > us > > back a compiled shader? (with added effects including ColorMatrix, etc). > > > > That's a good point: for optimal performance with simple filters we need to > be able to combine the EffectChain with the filter. However I think adding > filters to the EffectChain is probably not the right way to do that, > because some filters require multiple passes with intermediate buffers and > can't be compiled to a single program.
I am not very familiar with the spec. Could you please give an example of such a filter that would absolutely require multiple passes? Andreas' suggestion above is really important for performance. It will perform much better to implement the entire rendering in a single shader, than to do it in multiple passes, for the following reasons: - it's always bad to introduce sequence points in otherwise parallel operations; - splitting a program into separate pieces takes away optimization opportunities; - on desktop GPUs and tegras, doing it in one pass means better cache-friendliness (traversing the textures only once, and eliminating the temporary texture); - on tile-based deferred mobile GPUs, multi-pass rendering is specially unfriendly, as the fragment shaders are otherwise running in parallel with geometry processing (and multi-pass forces them to sync again). So if such filters exist in the spec, I would argue for taking them out, at least for now. You don't want portable-but-with-big-performance-caveats things in a 1.0 spec. I realize that we do have intermediate surfaces in our own compositor, but at least that's (for all I know) just an implementation detail, not something explicitly required by a spec. Benoit > I think to keep basic compositing > simple we want an EffectChain to always compile to a single program. So I > suspect the best approach might be to pass the EffectChain as an additional > parameter to the GLContext filter implementation. However, I'm no expert on > GL or GPU programming so I hope the usual suspects will chime in here. (I > was deliberately vague about "GL objects" for the same reason.) > > Rob > -- > q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq > qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq > qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq > qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q > qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq > qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q" > _______________________________________________ > 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
