On 05/11/2015 10:09 PM, Ilia Mirkin wrote:
On Mon, May 11, 2015 at 3:02 PM, Ian Romanick <[email protected]> wrote:
On 05/11/2015 08:23 AM, Ilia Mirkin wrote:
On Mon, May 11, 2015 at 9:03 AM, Marta Lofstedt
<[email protected]> wrote:
From: Marta Lofstedt <[email protected]>
Signed-off-by: Marta Lofstedt <[email protected]>
---
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)?
I'm not sure what the worry is here but for a user it's the same end
result if it's the app or library that causes crash/bug. In my
experience apps (especially games) do crash when using version
overrides. They don't expect symbol lookup to fail, shader compilation
to fail or some format support to not exist. Using version override
already means that you are on a dangerous path where things may fail
unexpectedly.
-ilia
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
// Tapani
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
