Varying material inputs were not being picked up from the same slots
where the VBO code is currently placing them (GENERIC0 and above).
Most often they were just being ignored.
This was only present for the sake of GL_ARB_shadow_ambient which we
never implemented in Gallium. If we someday want GL_ARB_shadow_ambient
we can implement it in the state tracker by adding a MAD after the
relevant TEX instructions.
Swrast was missing a free for the culmination of driConcatConfigs.
Use free(), not _mesa_free() since we shouldn't be calling any Mesa
functions from the GLX code. driConcatConfigs() should probably use
regular malloc/free to be consistant but the Mesa functions just wrap
the libc functions anyway.
When a buffer was mapped for write and no explicit flush range was provided
the existing semantics were that the whole buffer would be flushed, mostly
for backwards compatability with non map-buffer-range aware code.
However if the buffer was mapped/unmapped with nothing really written --
something that often happens with the vbo -- we were unnecessarily assuming
that the whole buffer was written.
The new PIPE_BUFFER_USAGE_FLUSH_EXPLICIT flag (based from ARB_map_buffer_range
's GL_MAP_FLUSH_EXPLICIT_BIT flag) allows to clearly distinguish the
legacy usage from the nothing written usage.
Required as some applications
retrieve and call these functions regardless of the fact that we
don't advertise the extension and further more the results of
wglGetProcAddress are NULL.
mesa allocates both frontface and pointcoord registers within the fog
coordinate register, by using swizzling. to make it cleaner and easier
for drivers we want each of them in its own register. so when doing
compilation from the mesa IR to tgsi allocate new registers for both
and add new semantics to the respective declarations.
Fix xdemos which default to using display :0.0 to default to $DISPLAY,
this is kind of irritating when testing on a display other than :0.0
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Where vbo save nodes are terminated with a call to DO_FALLBACK(), as in
the case of a recursive CallList which is itself within a Begin/End pair,
there two problems:
1) The display list node's primitive information was incorrect, stating
the cut-off prim had zero vertices
2) On replay, we would get confused by a primitive that started in a
node, but was terminated by individual opcodes.
This change fixes the first problem by correctly terminating the last
primitive on fallback, and the second by forcing the display list to
use the Loopback path, converting all nodes into immediate-mode rendering.
The loopback fix is a performance hit, but avoiding this would require
a fairly large rework of this code.
Add a simple version of _mesa_lookup_enum_by_nr() which expects a primitive
enum (GL_POINTS..GL_POLYGON). This avoids some annoying duplicates
when looking up primitives, such as the GL_FALSE/GL_POINTS clash.
Currently, state-changes in mesa display lists are more or less
a verbatim recording of the GL calls made during compilation.
This change introduces a minor optimization to recognize and eliminate
cases where the application emits redundant state changes, eg:
glShadeModel( GL_FLAT );
glBegin( prim )
...
glEnd()
glShadeModel( GL_FLAT );
glBegin( prim )
...
glEnd()
The big win is when we can eliminate all the statechanges between two
primitive blocks and combine them into a single VBO node.
This commit implements state-change elimination for Material and ShadeModel
only. This is enough to make a start on debugging, etc.
The gl_PointCoord attribute is currently expected to be in the fog coord
register's z/w components. This was never totally fleshed out though.
This is just some placeholder code.
This reverts commit de447afff2 but
puts the lock under DRI1-only.
From keithw:
> It's there because the DRI1 code doesn't actually achieve the mutexing
> which it looks as if it should. For multi-threaded applications it was
> always possible to get two threads inside locked regions -- I have no
> idea how, but it certainly was and presumably still is possible.
This would cause LOCK_HARDWARE to mutex all contexts in this process on
both DRI1 and DRI2. On DRI1, LOCK_HARDWARE already does it for all
processes on the system. On DRI2, LOCK_HARDWARE doesn't, but there shouldn't
be any state outside the context that needs any additional protection.
Notably, the bufmgr is protected by its own mutex and not
LOCK_HARDWARE.
This code was originally introduced with the i915tex code dump, so it's not
clear what it was there for.
