| Age | Commit message (Collapse) | Author |
|---|
|
Creates a display list with redundant call to glShadeModel.
View dlist contents with MESA_VERBOSE=list
|
|
Reorganization of ShadeModel to avoid flushing vertices too often
ended up never flushing vertices due to omitted line of code.
|
|
Switch over to specialized enum lookup for primitives
|
|
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.
|
|
(cherry picked from commit b1f2f92d9b2d190d39fb1b5c919c59c9539a025a)
|
|
|
|
|
|
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.
|
|
|
|
|
|
Never crashed on x86, ptx is in the same stack slot in either case.
Thanks to Bob Gleitsmann for catching this.
|
|
|
|
There doesn't appear to be any driver impact for enabling this, and
tests/prog_parameter passes.
|
|
|
|
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.
|
|
All gallium drivers should be able to support mixed-size color/depth/stencil
buffers. If not, we'll need a new PIPE_CAP_ query.
|
|
|
|
|
|
This fixes a segfault seen with piglit's fdo20701 test.
|
|
This reverts commit de447afff26706e3bf8bdcd5cfb8b1daf49b4b21 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.
|
|
|
|
|
|
|
|
Call Init() from CompileShaderFile, was previously only called for the
Text version of this function.
|
|
Get most of these working with scons.
|
|
Unfortunately scons does not check if a tool exists before it invokes
its generate function.
|
|
gcc-4.2's optimizer has a strange bug where it looses code from inner
loops in certain situations. For example, if the appearently innocent
looking code below is compiled with gcc-4.2 -S -O1, the inner loop's
code is missing from the outputed assembly.
struct Size {
unsigned width;
};
struct Command {
unsigned length;
struct Size sizes[32];
};
extern void emit_command(void *command, unsigned length);
void
create_surface( struct Size size, unsigned faces, unsigned levels)
{
struct Command cmd;
unsigned face;
unsigned level;
cmd.length = faces*levels*sizeof(cmd.sizes[0]);
for(face = 0; face < faces; ++face) {
for(level = 0; level < levels; ++level) {
cmd.sizes[face*levels + level] = size;
// This should generate a shrl statement, but the whole for body
// disappears in gcc-4.2 -O1/-O2/-O3!
size.width >>= 1;
}
}
emit(&cmd, sizeof cmd.length + cmd.length);
}
Note that this is not specific to MinGW's gcc-4.2 crosscompiler (the
version typically found in debian/ubuntu's mingw32 packages). gcc-4.2 on
Linux also displays the same error. gcc-4.3 and above gets this
correctly though.
Updated MinGW debian packages with gcc-4.3 are available from
http://people.freedesktop.org/~jrfonseca/debian/pool/main/m/
|
|
This prevents the error
relocation R_X86_64_PC32 against symbol `_gl_DispatchTSD' can not be used when making a shared object; recompile with -fPIC
when building on x86_64 architecture.
|
|
|
|
Link fails if too many varying vars.
(cherry picked from master, commit cc58fbcf2c5c88f406818db60910f537e03610d6)
|
|
|
|
|
|
|
|
|
|
16 is the limit for now because of various 32-bit bitfields.
(cherry picked from master, commit 4e762395ef7e8c332c16fd0c11025cfa52763a45)
|
|
To maintain correctness, the server will copy the real front-buffer to
a newly allocated fake front-buffer in DRI2GetBuffersWithFormat.
However, if the DRI2GetBuffersWithFormat is triggered by glViewport,
this will copy stale data into the new buffer. Fix this by flushing
the current fake front-buffer to the real front-buffer in
intel_viewport.
Fixes bug #22288.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A new node type (SLANG_OPER_RETURN_INLINED) is used to denote 'return'
statements inside inlined functions which need special handling.
All glean glsl1 tests pass for EmitContReturn=FALSE and TRUE.
|
|
Fixes glean "function with early return (3)" case (when EmitContReturn=FALSE).
|
|
|
|
|
|
|
|
|
