On 01/03/2015 01:10 PM, Rob Clark wrote: > On Sat, Jan 3, 2015 at 12:35 PM, Keith Packard <[email protected]> wrote: >> Rob Clark <[email protected]> writes: >> >>> hmm, what minimum gl and gles version do we need to expose instanced >>> drawing? Or any other useful extensions that glamor could use? Not >>> sure if that would make a difference between gl vs gles? >> >> We use instanced drawing on anything with GLSL version 1.30 or later. >> >> As for extensions, we check for: >> >> GL_EXT_texture_format_BGRA8888 >> GL_KHR_debug >> GL_MESA_pack_invert >> GL_EXT_framebuffer_blit >> GL_ARB_map_buffer_range >> GL_ARB_buffer_storage >> GL_NV_texture_barrier >> GL_OES_EGL_image >> >>> At any rate, we still have the problem that glamor will see that the >>> driver supports both gles and gl, and would have to somehow choose >>> which paths to use.. although I guess we could just pick based on >>> vendor name for freedreno/vc4/etc.. >> >> I think we'd rather use real GL on devices that have a real GL driver; >> however, we need to avoid fallbacks in the driver, which means creating >> some way for the driver to tell glamor what paths to avoid... > > I guess to start with, we could use hard-coded table keyed by vendor > name, perhaps.. although that is a bit lame
The way 100% of applications do this is by having a table of enables for different hardware / driver combinations. Since the GLES backend was created to support drivers we don't control, adding support for "is it fast" queries will only have limited utility. The tables are usually based on a combination of PCI ID (or other unique-ish hardware identifier) and driver version. This would also allow glamor to work around bugs in specific versions of drivers. > maybe inventing a glIsEmulatedMESA(GLenum) type thing would be a good idea? GL has resisted having something like this, for good reason, for over 20 years. There are a number of problems with such a query. In a large number of cases, knowing whether a feature is emulated it doesn't matter. In a large number of other cases, a feature may only be emulated if some other part of the GL is configured in a particular way. How many open source drivers accelerate anything if selection is enabled? What matters is whether a particular combination of GL features is fast _enough_, and there's no credible way that the driver can know if the implementation of a particular feature is fast enough for the application... whether it's natively done in hardware or not. The i915 vertex shader case that Keith mentioned at LCA is a perfect example. Both i915c and i915g implement software vertex shaders, so both would say "emulated." There is, however, a significant difference in the vertex shader performance on each... and i915g is probably fast enough for glamor while i915c is not. So the query tells you nothing useful. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
