| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Add a function to get whether a resource is likely on the GPU or not.
Currently always returns TRUE.
|
| |
|
| |
|
| |
|
|
|
|
| |
A source line was put in the wrong place.
|
| |
|
| |
|
| |
|
|
|
|
| |
Thanks to Jose Fonseca for pointing out they were missing.
|
| |
|
| |
|
|
|
|
|
| |
C++ doesn't accept function <-> void* conversions without a putting a
fight.
|
|
|
|
| |
Unused now that check_os_katmai_support was removed.
|
|
|
|
|
|
|
|
|
|
| |
The trace driver's implementation of sampler_view_destroy was calling
directly into the underlying pipe's sampler_view_destroy implementation.
This causes problems for pipes that keep references to sampler views
even after the state tracker has released them. Instead, we'll simply
drop the trace driver's reference to the pipe's sampler view.
Signed-off-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
| |
The trace driver was tracing the unwrapped version of the index buffer
when setting the index buffer. This caused an assert validating that
a resource belonged to the trace driver to fail. Instead, we'll log
the unmodified index buffer structure when setting the index buffer.
Signed-off-by: José Fonseca <[email protected]>
|
| |
|
|
|
|
|
| |
mapi.h is included by vgapi and st/vega. On win32, the macro expands to
dllexport and dllimport respectively.
|
|
|
|
|
|
|
| |
That is, replace the old _glapi_* names by new names that start with
u_current_. When MAPI_GLAPI_CURRENT is defined, u_current.h defines
rename macros to restore the old names. That is done for ABI
compatibility.
|
|
|
|
|
|
|
| |
glapi defines an interface that is used by DRI drivers. It must not be
changed in an ABI incompatible way. This commit moves all
functions/variables belong to the interface to glapi.h. Instead of
including u_current.h from glapi.h, u_current.h now includes glapi.h.
|
| |
|
|
|
|
|
|
|
| |
Only 8 out of the up to 13 regs are for source/dest depth, so the name
wasn't particularly appropriate. Note that this doesn't count the
constant or URB payload regs. Also, don't pre-divide by 2, so it's
actually a number of registers.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
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 <[email protected]>
|
| |
|
|
|
|
| |
Signed-off-by: Jerome Glisse <[email protected]>
|
|
|
|
| |
Signed-off-by: Jerome Glisse <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|