| Age | Commit message (Collapse) | Author |
|---|
|
Most of the time unfilled rendering requires a lot more thought than
just translating triangles to lines or points. But sometimes, you can
do exactly that, and it can be quite a bit quicker. Add code to do the
translation. The caller has to determine whether it's a legal thing
to do in the current state, in particular you'd need:
- culling disabled
- offset disabled
- same front and back fill modes
- possibly other stuff I can't think of.
|
|
|
|
The core reference counting code is centralized in p_refcnt.h.
This has some consequences related to struct pipe_buffer:
* The screen member of struct pipe_buffer must be initialized, or
pipe_buffer_reference() will crash trying to destroy a buffer with reference
count 0. u_simple_screen takes care of this, but I may have missed some of
the drivers not using it.
* Except for rare exceptions deep in winsys code, buffers must always be
allocated via pipe_buffer_create() or via screen->*buffer_create() rather
than via winsys->*buffer_create().
|
|
Conflicts:
src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
|
|
|
|
|
|
|
|
Conflicts:
scons/gallium.py
src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
src/gallium/include/pipe/p_defines.h
src/mesa/vbo/vbo_exec_api.c
src/mesa/vbo/vbo_exec_draw.c
|
|
|
|
Conflicts:
src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
|
|
No real change, as we're not tracking relocations read/write access yet.
|
|
|
|
|
|
|
|
Don't print the meaningless and confusing CONSTANT interpolation
attribute after everything else.
|
|
(cherry picked from commit 1350f2efba5eeceebe0e711db6152c29e9889ce7)
|
|
BSD supports pipe in the same way as linux hence options which
are safe for linux are also safe for BSD. Define PIPE_OS_BSD in
include/pipe/p_config.h and adjust the defines to make use of it.
Also define MAP_ANONYMOUS for BSD systems which use MAP_ANON
Signed-off-by: Benjamin Close <Benjamin.Close@clearchain.com>
|
|
|
|
Not supported by MSVC.
|
|
Saves code, and will simplify future interface changes.
|
|
|
|
Conflicts:
src/gallium/auxiliary/pipebuffer/pb_bufmgr_mm.c
src/gallium/auxiliary/util/u_tile.c
|
|
instructions
These texture types were defined but never put to use.
For the time being though, the Mesa->TGSI translater isn't emitting these
targets. See the XXX comment in map_texture_target().
|
|
Useful to replay traces which use DXTC textures...
|
|
Hard to believe... but true.
|
|
When there is a console attached, and no debugger attached.
|
|
Not much useful until we have symbol lookup.
|
|
|
|
The template makefile that most libraries in
gallium included was based on dri and had a bunch
unrelevant junk in it.
Update it and improve the depending makefiles.
|
|
|
|
|
|
It will give the same result 2nd time too, as fencing is done at a
higher level.
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/gallium/drivers/softpipe/sp_tile_cache.c
|
|
Conflicts:
src/gallium/auxiliary/draw/draw_vs_aos.c
|
|
Conflicts:
src/mesa/state_tracker/st_cb_accum.c
src/mesa/state_tracker/st_cb_drawpixels.c
|
|
|
|
The debug functions depend on several util function for os abstractions, and
these depend on debug functions, so a seperate module is not possible.
|
|
|
|
|
|
RSQ test 2 (reciprocal square toot of negative value)
|
|
|
|
Previously draw module asked for a pointer into (mapped) vertex data,
which it would incrementally fill and emit draw commands against. This
was hard for the drivers to deal with, especially in the case where a
draw command would force a flush and thus an unmap of the vertex data.
With this change, the draw module explicitly maps & then unmaps vertex
data prior to emitting draw commands.
|
|
A lot more test programs work.
|
|
Missed these for the initial gallium-texture-transfer commit.
|
|
Make sure the stats for TGSI_FILE_IMMEDIATE are uptodate. Previously
we just had immediate_count, but file_*[TGSI_FILE_IMMEDIATE] were
bogus.
|
|
|
