On Mon, 2009-12-14 at 08:58 -0800, michal wrote:
> José Fonseca pisze:
> > On Mon, 2009-12-14 at 08:22 -0800, Keith Whitwell wrote:
> >
> >> 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)
> >>
> >
> > This only works if expr has no calls, or just inline calls. Using my
> > earlier example, if very_expensive_check() is in another file then the
> > compiler has to assume the function will have side effects, and the call
> > can't be removed.
> >
> > I'm not sure __assume keyword that Michal mentioned helps. It's more a
> > hint to the compiler to help him optimize code around the assertion, but
> > perhaps it helps with the warnings too.
> >
> >
> If I try to compile this:
>
> __assume(lalala);
>
> I get:
>
> error C2065: 'lalala' : undeclared identifier
>
> On the other side, the compiler is going to be serious about the
> assumptions inside __assume(), and if they happen to be false, the
> application can behave not as expected. This is against current gallium
> paradigm, where we put assertions, but also do the same check in
> non-debug builds to early out from a function or provide default values
> (e.g. in switch-case statements).
Bummer... that's no good.
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
