[Interest] Crash with Qt application that use OpenGL

[Till Oliver Knoll]

[with reference to:
http://lists.qt-project.org/pipermail/interest/2016-October/025009.html]

Am 21.04.17 um 15:17 schrieb Xavier Bigand:
> This is not directly related, but that it is why I thought it was a Qt
> bug. It it so easy in OpenGL to use badly API and having a good result
> that will work on almost all configurations.

While it is not (directly) related to the nVidia driver crash that you
are observing it demonstrates nicely my prior point "a driver must not
crash" by example. Even if you feed the driver with bogus data.

When you look at the actual Qt bug report that resulted out of this:

  https://bugreports.qt.io/browse/QTBUG-56234

"it will call API glVertexAttribPointer but input parameter pointer is a
pointer to system memory vertex data, which violates spec because
OpenGL 4.1 context needs to bind a vertex buffer before calling
glVertexAttribPointer, so AMD OGL driver will report the following error
" glVertexAttribPointer in a Core context called without a bound
Vertex Array Object [which is now required for Core Contexts]"

Yes, Qt uses the OpenGL API wrong here (for the simple reason that the
code in question was written against OpenGL 2, where it was perfectly
valid - jut not with a "Core Context" anymore).

But note the two points:

  1. "which violates spec" and
  2. "AMD OGL driver will report the following error"

This is how a properly validating driver is supposed to behave :)

Disclaimer: I am neither working for AMD nor nVidia and I acknowledge
that both drivers may have their quirks ;)

> 
> Dislike in Vulkan there is no way to check if APIs are correctly used,
> so when we test our engine we can't really expect that it will run
> everywhere just because it runs on our computer.

"There is no way" because with Vulkan most of what the driver did
previously - that includes input validation -  is now in the
responsibility of the application itself.

In fact, the application is now in control of the "command queue", and
as such also responsible that the "data types fit together" and the data
arrives in the proper order (or is otherwise synchronised with
"barriers"). The Vulkan driver only does the bare minimum, but if you
pass it a pointer which points into system RAM instead of GPU RAM (when
such one is expected) then Bad Things Happen(tm).

That's why people say you are "closer to the metal" - there is much much
much less between the GPU and your application. Namely much less
validation (which in OpenGL is required by the specs, see above).

Simply said: most of the code (logic) which was previously in the OpenGL
driver is now in your application (which knows much better about the
nature of the data it wants to render, and hence can also spare most of
the input validation which - again by the specs - a former OpenGL driver
always *had* to do).

So it is not quite correct when you say "there is no way to check if the
API is used correctly" - it just happens that it is YOUR application now
that is supposed to validate the data (or at least it has to know
exactly what it does ;)).


Cheers, Oliver