| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Flushing the vertices after having already updated the state doesn't
do any good. Fixes useshaderprogram-flushverts-1. As a side effect,
by moving it to the right place we end up skipping no-op state changes
for traditional glUseProgram.
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Rebuilding the vertex format from scratch every time we see a new
vertex attribute is rather costly, new attributes can be appended at
the end avoiding a copy to current and then back again, and the full
attr pointer recalculation.
In the not so likely case of an already existing attribute having its
size increased the old behavior is preserved, this could be optimized
more, not sure if it's worth it.
It's a modest improvement in FlightGear (that game punishes the VBO
module pretty hard in general, framerate goes from some 46 FPS to 50
FPS with the nouveau classic driver).
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
|
|
|
|
And run SConscripts if they are present.
Also make dri depend on both drm and x11.
|
|
Silences warning about missing packages
|
|
Drivers scons files for a later time
|
|
|
|
This is a temporary work around to prevent crashes with glean/glsl1
(for example) which try to do vertex shader texturing.
|
|
|
|
Need to increment the array index to point to the last value.
Before, we were calling lp_build_array_alloca() over and over for
no reason.
|
|
Silences this GCC warning.
brw_wm_fp.c: In function 'brw_wm_pass_fp':
brw_wm_fp.c:966: warning: 'last_inst' may be used uninitialized in this function
brw_wm_fp.c:966: note: 'last_inst' was declared here
|
|
Silences this GCC warning.
brw_wm_fp.c: In function 'precalc_tex':
brw_wm_fp.c:666: warning: 'tmpcoord.Index' may be used uninitialized in this function
|
|
Fixes this GCC warning with linux-x86 build.
radeon_dataflow.c: In function 'get_readers_normal_read_callback':
radeon_dataflow.c:472: warning: ISO C90 forbids mixed declarations and code
|
|
|
|
Fixes this GCC warning with linux-x86 build.
radeon_pair_schedule.c: In function 'merge_presub_sources':
radeon_pair_schedule.c:312: warning: ISO C90 forbids mixed declarations and code
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
|
|
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
|
|
|
|
|
|
We want to do the scatter store to sequential locations in memory
for the vector of pixels we're processing in SOA format.
|
|
|
|
The requested window size is of the client area,
so account for surrounding borders and bars when
creating the window.
|
|
|
|
|
|
Commit 8dfafbf0861fe3d2542332658dd5493851053c78 forgot to update r300g.
There is a buf == NULL check, but buf is used before for var init.
Tested-by: Guillermo S. Romero <gsromero@infernal-iceberg.com>
|
|
Make private those functions that are used internally only.
|
|
|
|
As a result remove some nasty macros.
|
|
Fixes this GCC warning.
nouveau_vbo_t.c: In function 'nv10_vbo_render_prims':
nouveau_render_t.c:161: warning: 'max_out' may be used uninitialized in this function
nouveau_render_t.c:161: note: 'max_out' was declared here
|
|
|
|
Something is not quite right, however. The piglit tests mentioned in
fd.o bug 31226 still don't pass.
|
|
Found by inspection.
|
|
It's already been determined that length == 3, so clearly swiz->next is
a valid S-Expression.
|
|
There's really no reason to return the base class when we have more
specific information about what type it is.
|
|
We really only want to print spaces -between- elements, not after each
element. This cleans up error messages from IR reader, making them
(mildly) easier to read.
|
|
|
|
In particular, calling the abs function is silly, since there's already
an expression opcode for that. Also, assigning to temporaries then
assigning those to the final location is rather redundant.
|
|
For consistency with the vec2/vec3/vec4 variants.
|
|
Trivial change that avoids a segmentation fault when the blitter state
happens to be bound when the context is destroyed.
The free calls should probably removed altogether in the future -- the
responsibility to destroy the state atoms lies with whoever created it,
and the safest thing for the pipe driver is to not touch any bound state
in its destructor.
|
