| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
src/mesa/vbo/vbo_exec_draw.c
|
|
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.
|
|
Signed-off-by: Arthur HUILLET <arthur.huillet@free.fr>
|
|
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.
|
|
|
|
Call Init() from CompileShaderFile, was previously only called for the
Text version of this function.
|
|
As prescribed by ARB_map_buffer_range.
|
|
buffer_flush_mapped_range.
|
|
buffer_flush_mapped_range.
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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).
|
|
|
|
|
