[Mesa-dev] [PATCH] i965: Use new/delete instead of realloc() in brw_ir_allocator.h

Ian Romanick idr at freedesktop.org
Wed Feb 11 16:11:37 PST 2015


On 02/11/2015 12:15 PM, Francisco Jerez wrote:
> Matt Turner <mattst88 at gmail.com> writes:
>> [...]
>> Indeed. And another thing to consider is that we've discussed
>> compiling with -fno-exceptions.
>>
> 
> Heh, the benefit you get from doing that is virtually zero.  And in
> cases like this where failure would have to be handled many levels up in
> the stack and require redesigning an interface used in hundreds of
> places making it more awkward to use, not using exceptions is a really
> strong incentive not to handle failure at all.  I cannot see any better
> solution here other than throwing an exception or letting the program
> segfault.

Except OpenGL is a C API.  I don't see how an exception could even get
delivered to a C program calling down into our driver through the GL API.

Since our driver can be called from the X server, just letting the
program segfault is, at best, not cool.

If some of our internals are designed so that we can't handle possibly
handle a resource allocation failure, that internal is designed wrong.
Looking at src/mesa/drivers/dri/i965/brw_ir_allocator.h, there are
several trivial ways that simple_allocator::allocate could be modified
to allow error reporting.

>> I think it's okay to add out-of-memory checks where we can reasonably
>> do something about them, but code churn *just* to silence a tool (one
>> that I'm not aware of catching any meaningful bugs) doesn't seem good.
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150211/bb401e5e/attachment.sig>


More information about the mesa-dev mailing list