Re: [Mesa-dev] [PATCH] mesa: Use _mesa_has_OES_geometry_shader() when validating draws

On Thu, Mar 2, 2017 at 5:41 PM, Kenneth Graunke wrote: > On Wednesday, March 1, 2017 6:09:30 PM PST Ilia Mirkin wrote: >> So, I have a few conflicting thoughts: >> >> (a) I hate having to saddle the code with impossible conditions. This >> change may seem minor but it's an

Re: [Mesa-dev] [PATCH] mesa: Use _mesa_has_OES_geometry_shader() when validating draws

On Wednesday, March 1, 2017 6:09:30 PM PST Ilia Mirkin wrote: > So, I have a few conflicting thoughts: > > (a) I hate having to saddle the code with impossible conditions. This > change may seem minor but it's an admission that non-sensical context > settings are OK. I don't think the code should

Re: [Mesa-dev] [PATCH] mesa: Use _mesa_has_OES_geometry_shader() when validating draws

On Wed, Mar 1, 2017 at 8:47 PM, Tomasz Figa wrote: > Hi, > > On Fri, Feb 24, 2017 at 9:38 AM, Tomasz Figa wrote: >> On Fri, Feb 24, 2017 at 5:00 AM, Kenneth Graunke >> wrote: >>> >>> On Thursday, February 23, 2017 10:46:54 AM PST

Re: [Mesa-dev] [PATCH] mesa: Use _mesa_has_OES_geometry_shader() when validating draws

Hi, On Fri, Feb 24, 2017 at 9:38 AM, Tomasz Figa wrote: > On Fri, Feb 24, 2017 at 5:00 AM, Kenneth Graunke > wrote: >> >> On Thursday, February 23, 2017 10:46:54 AM PST Ilia Mirkin wrote: >> > The assumption was that if you're setting that ext, you can

Re: [Mesa-dev] [PATCH] mesa: Use _mesa_has_OES_geometry_shader() when validating draws

On Fri, Feb 24, 2017 at 5:00 AM, Kenneth Graunke wrote: > On Thursday, February 23, 2017 10:46:54 AM PST Ilia Mirkin wrote: > > The assumption was that if you're setting that ext, you can do gles31. Is > > there a driver/hw combo where that's not the case? If so, we should

Re: [Mesa-dev] [PATCH] mesa: Use _mesa_has_OES_geometry_shader() when validating draws

On Thursday, February 23, 2017 10:46:54 AM PST Ilia Mirkin wrote: > The assumption was that if you're setting that ext, you can do gles31. Is > there a driver/hw combo where that's not the case? If so, we should fix > that instead... ChromeOS/ARC++ currently disables GLES 3.1 on i965 because we

Re: [Mesa-dev] [PATCH] mesa: Use _mesa_has_OES_geometry_shader() when validating draws

The assumption was that if you're setting that ext, you can do gles31. Is there a driver/hw combo where that's not the case? If so, we should fix that instead... On Feb 23, 2017 3:05 AM, "Tomasz Figa" wrote: > In validate_DrawElements_common() we need to check for

Re: [Mesa-dev] [PATCH] mesa: Use _mesa_has_OES_geometry_shader() when validating draws

On Thu, Feb 23, 2017 at 12:05 AM, Tomasz Figa wrote: > In validate_DrawElements_common() we need to check for OES_geometry_shader > extension to determine if we should fail if transform feedback is > unpaused. However current code reads ctx->Extensions.OES_geometry_shader >

Re: [Mesa-dev] [PATCH] mesa: Use _mesa_has_OES_geometry_shader() when validating draws

On Thursday, February 23, 2017 12:05:18 AM PST Tomasz Figa wrote: > In validate_DrawElements_common() we need to check for OES_geometry_shader > extension to determine if we should fail if transform feedback is > unpaused. However current code reads ctx->Extensions.OES_geometry_shader > directly,

Re: [Mesa-dev] [PATCH] mesa: Use _mesa_has_OES_geometry_shader() when validating draws

On Thu, Feb 23, 2017 at 5:05 PM, Tomasz Figa wrote: > In validate_DrawElements_common() we need to check for OES_geometry_shader > extension to determine if we should fail if transform feedback is > unpaused. However current code reads ctx->Extensions.OES_geometry_shader >

[Mesa-dev] [PATCH] mesa: Use _mesa_has_OES_geometry_shader() when validating draws

In validate_DrawElements_common() we need to check for OES_geometry_shader extension to determine if we should fail if transform feedback is unpaused. However current code reads ctx->Extensions.OES_geometry_shader directly, which does not take context version into account. This means that if the