| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The draw module provides a similar interface to the driver which
is retained as various bits of hardware may be able to take on
incremental parts of the vertex pipeline. However, there's no
need to advertise all this complexity to the state tracker.
There are basically two modes now - normal and passthrough/screen-coords.
|
|
|
|
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().
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
Instead, a new pipe_transfer object has to be created and mapped for
transferring data between the CPU and a texture. This gives the driver more
flexibility for textures in address spaces that aren't CPU accessible.
This is a first pass; softpipe/xlib builds and runs glxgears, but it only shows
a black window. Looks like something's off related to the Z buffer, so the
depth test always fails.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/gallium/auxiliary/tgsi/tgsi_exec.c
src/gallium/drivers/cell/spu/spu_command.h
src/gallium/include/pipe/p_shader_tokens.h
src/mesa/main/config.h
src/mesa/main/mtypes.h
src/mesa/shader/prog_execute.c
src/mesa/shader/slang/slang_emit.c
src/mesa/state_tracker/st_program.c
src/mesa/state_tracker/wgl/stw_wgl.h
src/mesa/state_tracker/wgl/stw_wgl_pixelformat.h
|
|
Not really an error, as we only care for the lower 4 bits.
|
|
As advised by gcc -pedantic.
|
|
|
|
|
|
Conflicts:
src/gallium/winsys/gdi/SConscript
|
|
|
|
|
|
|
|
|
|
The Minimum Resolvable Depth factor depends on the driver and can't just
be computed from the number of Z buffer bits.
Glean's polygon offset test now passes with softpipe.
Still need to determine the MRD factor for other gallium drivers, if they use
the draw module's polygon offset stage...
|
|
|
|
|
|
|
|
|
|
vertex shaders
This may only be practical for the softpipe driver at this time.
|
|
|
|
|
|
This allows us to use SSE codegen with debug builds again.
When PIPE_ARCH_SSE is set (w/ gcc -msse -msse2) we will also use the
gcc SSE intrinsic functions.
|
|
|
|
|
|
Conflicts:
src/gallium/auxiliary/rtasm/rtasm_execmem.c
src/mesa/shader/slang/slang_emit.c
src/mesa/shader/slang/slang_log.c
src/mesa/state_tracker/st_atom_framebuffer.c
|
|
This prevents vertex shaders from referencing invalid memory locations when
the shader is operating on less than four vertices or fragments.
|
|
|
|
|
