On Mon, May 11, 2015 at 3:02 PM, Ian Romanick <i...@freedesktop.org> wrote:
> On 05/11/2015 08:23 AM, Ilia Mirkin wrote:
>> On Mon, May 11, 2015 at 9:03 AM, Marta Lofstedt
>> <marta.lofst...@linux.intel.com> wrote:
>>> From: Marta Lofstedt <marta.lofst...@intel.com>
>>>
>>> Signed-off-by: Marta Lofstedt <marta.lofst...@intel.com>
>>> ---
>>> src/mesa/main/bufferobj.c | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
>>> index 66dee68..07f82cd 100644
>>> --- a/src/mesa/main/bufferobj.c
>>> +++ b/src/mesa/main/bufferobj.c
>>> @@ -91,8 +91,9 @@ get_buffer_target(struct gl_context *ctx, GLenum target)
>>> case GL_COPY_WRITE_BUFFER:
>>> return &ctx->CopyWriteBuffer;
>>> case GL_DRAW_INDIRECT_BUFFER:
>>> - if (ctx->API == API_OPENGL_CORE &&
>>> - ctx->Extensions.ARB_draw_indirect) {
>>> + if ((ctx->API == API_OPENGL_CORE &&
>>> + ctx->Extensions.ARB_draw_indirect) ||
>>> + _mesa_is_gles31(ctx)) {
>>
>> Similar to my comment on the other patch (and if this occurs in the
>> other patches, I'd have the same comment there again). I think it's
>> confusing, the way you're mixing things. Also it'll lead to backend
>> drivers potentially receiving things they're not ready for. IMHO this
>> should become
>>
>> if ((ctx->API == API_OPENGL_CORE || _mesa_is_gles31(ctx)) &&
>> ctx->Extensions.ARB_draw_indirect)
>
> Before these patches were sent out for review, they were written in this
> way. I had suggested changing it to the current method.
> GL_ARB_draw_indirect isn't an ES extension, so checking that case seemed
> weird to me.
Yeah, but we don't have GL vs GLES vs GLES3.1 driver API's. We just
have a single API, and the enable bit for "I can do indirect draws" is
that you set Extensions.ARB_draw_indirect to true. In a desktop GL
context, this also means that GL_ARB_draw_indirect is reported in the
extension string. I could easily imagine a hypothetical GLES ext that
could be enabled by the same bit (although there is none afaik).
Basically the question is what do we want to have happen when you have
a driver that doesn't quite support GL (ES) version X, but you use a
version override, and then try to use one of the features that version
X provides but the driver isn't quite ready for. Do you get a
(potential) library crash/otherwise inconsistent state? Or do you just
get an error at the API level (which the spec doesn't allow for, since
the feature is supposed to exist)?
-ilia
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
