On Mon, 2009-12-14 at 08:04 -0800, José Fonseca wrote:
> 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.
It's not hard to avoid excuting code... For instance we could always
have it translated to something like:
if (0) {
(void)(expr);
}
(void)(0)
> I believe the problem is we sometimes have
>
> assert(very_expensive_check());
>
> and it should be really
>
> #ifdef DEBUG
> assert(very_expensive_check());
> #endf
I think the above translation is fine, without the extra ifdefs.
> 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.
There are other issues as well, such as unused variable warnings for
vars used only in asserts, etc.
Keith
------------------------------------------------------------------------------
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
