| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Include p_compiler.h for boolean symbol.
Include u_debug.h for assert symbol.
|
|
Include p_format.h for enum pipe_format symbol.
Include p_state.h for pipe_box symbol.
|
|
Remove p_defines.h.
Remove unnecessary forward declarations.
Add forward declaration for pipe_context.
|
|
|
|
|
|
This begins a process of repurposing this file. The existing usage is
as a header file for some software blit fallbacks, which should be
moved to a more appropriately named header.
|
|
UNDEFINED_VERTEX_ID is used by draw_pipe_vbuf to decide whether a vertex
has been emitted or not. The non-pipeline pathes do not use it (they
tell the frontend the max vertex count when prepare() is called).
|
|
Update all drivers to use draw_set_index_buffer,
draw_set_mapped_index_buffer, and draw_vbo. Remove
draw_set_mapped_element_buffer and draw_set_mapped_element_buffer_range.
|
|
This commit adds draw_set_index_buffer, draw_set_mapped_index_buffer,
and draw_vbo. The idea behind the new functions is that an index buffer
should be a state.
draw_arrays and draw_set_mapped_element_buffer are preserved, but the
latter will be removed soon.
|
|
Include p_format.h for enum pipe_format symbol.
|
|
Include p_compiler.h for boolean symbol.
|
|
Fixes #29771.
|
|
|
|
s->close_first was on the wrong side of the inequality.
Caught by blender.
Thanks to AndrewR for reporting this.
|
|
|
|
util_fill_rect could not handle formats with more than 32 bits,
since the fill color was a uint32_t value. Fix this by using
a util_color union instead, and also expand the union so it
works with formats which have up to 256 bits (the max of any
format currently defined).
|
|
Before, we were discarding the compiled vertex program on each
vertex program change.
Now we compile the program as if there were 6 clip planes and
dynamically patch in an "end program" bit at the right place.
Also, nv30 should now work.
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Changed by me to use movd instead of movss to avoid penalties.
|
|
|
|
|
|
This is a typo fix of earlier commit 0f3b3751b8643352dcc242567b3696bd1505df1d.
|
|
dump_cpu is used only when DEBUG is defined.
Fixes the following GCC warning on builds without DEBUG defined.
util/u_cpu_detect.c:76: warning: 'debug_get_option_dump_cpu' defined but not used
|
|
Initialize variables on error paths.
|
|
This is valid input, and asserting here does causes the test suites that
verify this to crash.
Also, the assert was wrongly accepting the case
max_index == vert_info->count
which, IIUC, is the first vertex outside the buffer. Assuming the
vert_info->count is precise (which often is not the case).
|
|
|
|
Fixes build error with MSVC.
|
|
See comments for detailed rationale.
Thanks to Michal Krol and Zack Rusin for detecting and investigating this
in detail.
|
|
Add u_linear.c and u_linkages.c to SCons build.
Reorder list of files to be more alphabetical.
|
|
This patch reorders the list of files so that the order is more alphabetic.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
