misc fixes for VC4

[Ian Romanick]

On 01/03/2015 01:10 PM, Rob Clark wrote:
> On Sat, Jan 3, 2015 at 12:35 PM, Keith Packard <keithp at keithp.com> wrote:
>> Rob Clark <robdclark at gmail.com> 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.