On 02/21/2014 05:47 AM, Juha-Pekka Heikkilä wrote:
On Mon, Feb 17, 2014 at 11:03 PM, Ian Romanick <i...@freedesktop.org> wrote:
On 02/17/2014 08:21 AM, Juha-Pekka Heikkila wrote:
Resend of the earlier glx patches with the issue pointed out by Petri fixed.
Patch number five is a bit special. hash_table_insert() and
hash_table_replace() don't really have a way to report errors and I did not
want to go changing the api since these are called from so many places thus
the case of null (c)allocation is handled just inside the functions and
relied low memory situation is handled outside the function properly.
Right. I'm a bit skeptical about patches 5 and 9 for that reason. I
think if we add a function _mesa_error_no_memory(void) to
src/mesa/errors.c that can at least set GL_OUT_OF_MEMORY in the context,
I'd be a bit more happy. The GL spec allows us to leave things in an
indeterminate state when we're out of memory. We really do need to let
the application know what happend, though.
Something like...
void
_mesa_error_no_memory(void)
{
GET_CURRENT_CONTEXT(ctx);
_mesa_error(ctx, GL_OUT_OF_MEMORY, "out of memory");
}
ought to be enough. We do need to audit the various paths through
_mesa_error to make sure they can handle no memory situations.
These seem to be a bit more tricky as patches five and nine affect
glsl compiler side also where I don't have the context. I guess I need
to see a way to leak the error through some return values for whoever
called here. Previous places where such errors were trying to be
reported seem to be mostly returning -1 lacking any additional
information why error was given.
That's why I was suggesting the helper function. The macro
GET_CURRENT_CONTEXT(ctx) gets the context. It's always available somewhere.
/Juha-Pekka
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
