On Mon, 2009-12-14 at 08:19 -0800, Keith Whitwell wrote:
> 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)
> 

Obviously I would have meant to say something cleaner like:

 do {
   if (0) { (void)(expr);  }
 }
 while (0)

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

Reply via email to