On Thu, 2011-06-30 at 03:27 -0700, Jose Fonseca wrote:
>
> ----- Original Message -----
> > On Thu, 2011-06-30 at 03:36 +0200, Roland Scheidegger wrote:
> > > Ok in fact there's a gcc bug about memcmp:
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
> > > In short gcc's memcmp builtin is totally lame and loses to glibc's
> > > memcmp (including call overhead, no knowledge about alignment etc.)
> > > even
> > > when comparing only very few bytes (and loses BIG time for lots of
> > > bytes
> > > to compare). Oops. Well at least if the strings are the same (I'd
> > > guess
> > > if the first byte is different it's hard to beat the gcc
> > > builtin...).
> > > So this is really a gcc bug. The bug is quite old though with no
> > > fix in
> > > sight apparently so might need to think about some workaround (but
> > > just
> > > not doing the comparison doesn't look like the right idea, since
> > > apparently it would be faster with the comparison if gcc's memcmp
> > > got
> > > fixed).
> >
> > Looking at the struct again (it's been a while), it seems like it
> > could
> > be rearranged to be variable-sized and on average significantly
> > smaller:
> >
> > struct lp_rast_state {
> > struct lp_jit_context jit_context;
> > struct lp_fragment_shader_variant *variant;
> > };
> >
> > struct lp_jit_context {
> > const float *constants;
> > float alpha_ref_value;
> > uint32_t stencil_ref_front, stencil_ref_back;
> > uint8_t *blend_color;
> > struct lp_jit_texture textures[PIPE_MAX_SAMPLERS];
> > };
> >
> > If we moved the jit_context part behind "variant", and then hopefully
> > note that most of those lp_jit_texture structs are not in use. That
> > would save time on the memcmp *and* space in the binned data.
>
> Yeah, sounds a good idea.
>
> But there's some subtletly to computing the number of textures: it
> can't be just the NULL textures, because they may be reffered by the
> JIT code, which has no NULL checks and relies on the state setup to
> provide storage for all textures, or dummy memory if one is not bound.
So it's a property of the variant, right? We should just store that
information when we generate the llvm variant.
> I think a better idea would be:
> - split the texture/sampler state
> - to make the lp_jit_context::textures an array of pointers, and put the
> struct lp_jit_texture in the pipe_texture object themselves
> - to make the lp_jit_context::samplers an array of pointers, and put the
> struct lp_jit_sampler in the pipe_sampler_state CSO
I like this too - it's somewhat more involved of course.
In fact the two are orthogonal -- the struct below can still be shrunk
significantly by knowing how many samplers & textures the variant refers
to. Interleaving them or packing them would reduce the bytes to be
compared.
Alternatively there could be just a pointer in jit_context to
textures/samplers binned elsewhere.
> struct lp_jit_context {
> struct lp_jit_texture *textures[PIPE_MAX_SAMPLERS];
> struct lp_jit_sampler *samplers[PIPE_MAX_SAMPLERS];
> };
The jit context above seems to have lost some of its fields...
The next step might be to split the context into four parts: textures,
samplers, constants, "other", and have jit_context just be a set of
pointers into the binned data:
struct lp_jit_context {
struct lp_jit_texture **textures;
struct lp_jit_sampler **samplers;
const float *constants;
const struct lp_jit_other *other;
};
struct lp_jit_other {
float alpha_ref_value;
uint32_t stencil_ref_front;
uint32_t stencil_ref_back;
uint8_t *blend_color;
};
> struct lp_jit_texture
> {
> uint32_t width;
> uint32_t height;
> uint32_t depth;
> uint32_t first_level;
> uint32_t last_level;
> uint32_t row_stride[LP_MAX_TEXTURE_LEVELS];
> uint32_t img_stride[LP_MAX_TEXTURE_LEVELS];
> const void *data[LP_MAX_TEXTURE_LEVELS];
> /* sampler state, actually */
> float min_lod;
> float max_lod;
> float lod_bias;
> float border_color[4];
> };
>
> struct lp_jit_sampler
> {
> float min_lod;
> float max_lod;
> float lod_bias;
> float border_color[4];
> };
>
>
> Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
