Now the question is whether we are allowed to ignore gl_rasterization_rules and
pipe_rasterizer_state::multisample. The former is invariant anyway and
I think the latter would need re-emitting the AA state which is quite costly,
considering that it implicitly flushes the whole pipeline (all AA regs
in the AA state are *unpipelined*).
we used to create and cache unltimited number of variant, this
change limits the number of variants kept around to a fixed number.
the change is based on a similar patch by Roland for llvmpipe fragment
shaders.
...instead of waiting until glGetString(GL_EXTENSIONS) is called.
This fixes a problem where the MESA_EXTENSION_OVERRIDE env var is
ignored if the app never calls glGetString(GL_EXTENSIONS).
NOTE: this is a candidate patch for the 7.8 branch.
I'm not sure if I really got it right. This seems like one of those
"Duh, of course it works that way" things, but I'd like the
documentation to be readable by people not acquainted with OGL/D3D.
Only for first RT at the moment, as there is no trivial way in galahad
to look at framebuffer state and (sadly) people don't usually calloc
their CSOs, so flags could be wrongly set.
On the other hand, of course, galahad will hopefully encourage more
people to calloc their CSOs. :3
1. Move all GL entrypoint functions and files into src/mesa/main/
This includes the ARB vp/vp, NV vp/fp, ATI fragshader and GLSL bits
that were in src/mesa/shader/
2. Move src/mesa/shader/slang/ to src/mesa/slang/ to reduce the tree depth
3. Rename src/mesa/shader/ to src/mesa/program/ since all the
remaining files are concerned with GPU programs.
4. Misc code refactoring. In particular, I got rid of most of the
GLSL-related ctx->Driver hook functions. None of the drivers used
them.
Conflicts:
src/mesa/drivers/dri/i965/brw_context.c
We were previously calculating a value which was either the geometry
shader output primitive or the application's input primitive, and
passing that to the various front/middle/back components for use as
the ultimate rendering primtive.
Unfortunately, this was not correct -- if the vcache decomposition
path is active and geometry shaders are *not* active, we can end up
with a third primitive -- specifically the decomposed version of the
input primitive.
Rather than trying to precalculate this, just let the individual
components inform their successors about which primitive type they are
recieving.
