On Mon, 2009-12-14 at 05:39 -0800, Keith Whitwell wrote:
> On Sun, 2009-12-13 at 15:27 -0800, Marek Olšák wrote:
> >
> > +static INLINE
> > +void util_blitter_save_fragment_sampler_states(
> > + struct blitter_context *blitter,
> > + int num_sampler_states,
> > + void **sampler_states)
> > +{
> > + assert(num_textures <= 32);
> > +
> > + blitter->saved_num_sampler_states = num_sampler_states;
> > + memcpy(blitter->saved_sampler_states, sampler_states,
> > + num_sampler_states * sizeof(void *));
> > +}
> > +
>
> Have you tried compiling with debug enabled? The assert above fails to
> compile. Also, can you use Elements() or similar instead of the
> hard-coded 32?
>
> Maybe we can figure out how to go back to having asserts keep exposing
> their contents to the compiler even on non-debug builds. This used to
> work without problem on linux and helped a lot to avoid these type of
> problems.
I wouldn't say without a problem: defining assert(expr) as (void)0
instead of (void)(expr) on release builds yielded a non-negligible
performance improvement. I don't recall the exact figure, but I believe
it was the 3-5% for the driver I was benchmarking at the time. YMMV.
Different drivers will give different results, but there's nothing
platform specific about this.
I believe the problem is we sometimes have
assert(very_expensive_check());
and it should be really
#ifdef DEBUG
assert(very_expensive_check());
#endf
We could go through the files with a fine-toothed comb and fix it, but
it's quite likely this sort of checks creep back in unnoticed and the
thing repeats again. Between having debug builds temporarily broken and
slower release builds I personally I'm for the former.
No suprise that (void)0 is the common practice: glibc, ms's headers,
etc. all do that.
Also, I don't understand why a developer wouldn't want to use a debug
build unless he's profiling. I don't see why we should make easy for a
developer not to test its code, and running a debug build is the bare
minimum.
Jose
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
