| Age | Commit message (Collapse) | Author |
|---|
|
Whenever the accumulator results are needed, this bit must be set.
|
|
|
|
|
|
This makes reading the code easier when matching up to the specs,
which also use this format.
|
|
The SIMD16 message no longer has the goofy interleaved format that
made Compr4 compression necessary before.
|
|
|
|
This might technically not always be correct, because va_copy might
be a function, or a system might not have va_copy, and not work with
assignment.
Hopefully this is never the case.
Without configure tests, it doesn't seem possible to do better.
|
|
|
|
|
|
Again, this is a one-element struct that was incorrectly missing the
field.
|
|
This was triggered by the previous bug, but is a separate problem
in the general sense.
|
|
According to both GLSL 1.20 and 4.0, these are a struct with one field
called "sceneColor".
Fixes a crash on loading in FlightGear.
|
|
If we hit the linear blit path, we'd come up with a pitch of 0, then
divide by zero.
Fixes vbo-subdata-zero, made for bug #28931 (warsow).
|
|
This function was apparently missing from the display list dispatch
table, causing the generic no-op function to be called instead. To make
matters worse, the no-op function is indistinguishable from a successful
call to GetUniformLocation. GL specifies that GetUniformLocation is
executed immediately when compiling display lists.
Fixes fdo bug 29622.
Signed-off-by: Nick Bowler <nbowler@draconx.ca>
|
|
|
|
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
|
|
This commit adds the ability to produce a log file containing all
reference count changes, and object creation/destruction, on Gallium
objects.
The data allows to answer these crucial questions:
1. This app is exhausting all my memory due to a resource leak: where
is the bug?
2. Which resources is this app using at a given moment? Which parts of
the code created them?
3. What kinds of resources does this app use?
4. How fast does this app create and destroy resources? Which parts of
the code create resources fast?
The output is compatible with the one produced by the similar facility
in Mozilla Firefox, allowing to use Mozilla's tools to analyze the data.
To get the log file:
export GALLIUM_REFCNT_LOG=<file>
To get function names and source lines in the log file:
tools/addr2line.sh <file>
To process the log file, see:
http://www.mozilla.org/performance/refcnt-balancer.html
|
|
|
|
|
|
Without this, any form of logging that dumps stack traces continuously
will spend a lot of time resolving symbol names.
|
|
|
|
|
|
|
|
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
|
|
|
|
These sources compile to nothing when FEATURE_ES is not defined and thus
were overlooked. Note that api_exec_es[12].c are still missing on the
list. They should be added when they can be generated on the fly.
|
|
Note that GLES headers use GL_APIENTRY, not GLAPIENTRY.
|
|
mfeatures.h defines ASSERT_NO_FEATURE to ASSERT, which is defined in
compiler.h. Header files using the macro should include compiler.h.
|
|
It is needed to support calling eglGetProcAddress before eglInitialize.
|
|
The API of the context was not checked against EGL_RENDERABLE_TYPE when there
was no attribute list. Move the check to _eglInitContext, and be verbose about
common mistakes (EGL_RENDERABLE_TYPE not set, EGL_CONTEXT_CLIENT_VERSION not
set, or eglBindAPI not called).
|
|
Without the .def file, function names are decorated and cannot be
queried by GetProcAddress easily.
|
|
When _EGL_GET_CORE_ADDRESSES is defined, eglGetProcAddress can be used to query
core functions. This is non-standard, but some apps expect it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Currently Gallium internals always use PIPE_TEXTURE_2D and normalized
coordinates to access textures.
However, PIPE_TEXTURE_2D is not always supported for NPOT textures,
and PIPE_TEXTURE_RECT requires unnormalized coordinates.
Hence, this change adds support for both kinds of normalization.
|
|
Currently Gallium internals always use PIPE_TEXTURE_2D and normalized
coordinates to access textures.
However, PIPE_TEXTURE_2D is not always supported for NPOT textures,
and PIPE_TEXTURE_RECT requires unnormalized coordinates.
Hence, this change adds support for both kinds of normalization.
|
|
|
|
This seems to make sense, although I suspect the semantics of
TGSI_TEXTURE_RECT need to be closely reviewed.
|
|
Searched for them with:
git grep -E '[!=]=.*PIPE_TEXTURE_2D|PIPE_TEXTURE_2D.*[!=]=|case.*PIPE_TEXTURE_2D'
Behavior hasn't been changed.
|
|
This allows to properly support OpenGL rectangle textures in a well
defined way, especially on drivers that don't expose
PIPE_CAP_NPOT_TEXTURES.
|
|
format ‘%d’ expects type ‘int’, but argument 2 has type ‘long int’
|
