| Age | Commit message (Collapse) | Author |
|---|
|
Changes in v3:
- Renumber caps to accomodate caps to add to master in the meantime
- Document caps
- Add unsupported caps to *_screen.c too
Changes in v2:
- Split for properties patch
- Use positive caps instead of negative caps
This adds 4 caps to indicate support of each of the fragment coord
conventions.
All drivers are also modifed to add the appropriate caps.
Some drivers were incorrectly using non-Gallium-default conventions,
and caps for them have them set so that they will behave correctly
after the later state tracker patches.
This drivers are softpipe/llvmpipe (uses integer rather than half
integer) and pre-nv50 Nouveau (uses lower left rather than upper left).
Other drivers might be broken. With this patchset, fixing them is
only a matter of exposing the appropriate caps that match the behavior
of the existing code.
Drivers are encouraged to support all conventions themselves for better
performance, and this feature is added to softpipe in a later patch.
|
|
Conflicts:
src/gallium/drivers/softpipe/sp_screen.c
src/gallium/include/pipe/p_defines.h
|
|
there's no point in keeping deprecated PIPE_CAPS around since there's no
stable interface (yet).
Reuse the enum for PIPE_CAP_DUAL_SOURCE_BLEND. Drivers advertizing this
will accept the pipe blendfactors with SRC1 in them and be able to do dual
source blending (src color from pixel shader output 0, and blendfactor with
SRC1 will come from output 1, only one render target may be bound when using
any of these blend factors).
|
|
|
|
|
|
This patch removes PIPE_TEX_FILTER_ANISO.
Anisotropic filtering is enabled if and only if max_anisotropy > 1.0.
Values between 0.0 and 1.0, inclusive, of max_anisotropy are to be
considered equivalent, and meaning to turn off anisotropic filtering.
This approach has the small drawback of eliminating the possibility of
enabling anisotropic filter on either minification or magnification
separately, which Radeon hardware seems to support, is currently
support by Gallium but not exposed to OpenGL. If this is actually
useful it could be handled by splitting max_anisotropy in two values
and adding an appropriate OpenGL extension.
NOTE: some fiddling & reformatting by keithw to get this patch to
apply. Hopefully nothing broken in the process.
|
|
For conditional rendering predicated on results of an occlusion query.
If this driver function is NULL, conditional rendering is not supported by
the driver.
|
|
using the draw module allows us to enable geometry shading even on hardware
that doesn't support it.
|
|
|
|
|
|
Previously, gallium shared sampler and texture state between vertex
and fragment shader stages. This change generalises this concept by
providing separate entrypoints for vertex and fragment sampler state
setting.
A new capability bit is added to query the driver for the number
of samplers that can be utilised by a vertex and fragment shader
at the same time.
|
|
|
|
There is little point in having a special TGSI token just to handle
predicate register updates. Remove tgsi_dst_register_ext_predicate token
and instead use a new PREDICATE register file to update predicates.
Actually, the contents of the obsolete token are being moved
to tgsi_instruction_ext_predicate, where they should be
from the very beginning.
Remove the NVIDIA-specific condition code tokens -- nobody uses them
and they can be emulated with predicates if needed.
Introduce PIPE_CAP_SM3 that indicates whether a driver supports
SM3-level instructions, and in particular predicates.
Add PIPE_CAP_MAX_PREDICATE_REGISTERS that can be used to query the driver
how many predicate registers it supports (currently it would be 1).
|
|
It's really just another define. No need for its own header.
|
|
Asks the driver to map the texture storage directly or return NULL if that's
not possible.
|
|
gcc 4.4 seems particularly picky with int -> enum conversions.
|
|
|
|
No longer used. S3TC support is queried via
pipe_screen::is_format_supported.
|
|
|
|
default extension list
|
|
Conflicts:
src/mesa/vbo/vbo_exec_draw.c
|
|
buffer_flush_mapped_range.
When a buffer was mapped for write and no explicit flush range was provided
the existing semantics were that the whole buffer would be flushed, mostly
for backwards compatability with non map-buffer-range aware code.
However if the buffer was mapped/unmapped with nothing really written --
something that often happens with the vbo -- we were unnecessarily assuming
that the whole buffer was written.
The new PIPE_BUFFER_USAGE_FLUSH_EXPLICIT flag (based from ARB_map_buffer_range
's GL_MAP_FLUSH_EXPLICIT_BIT flag) allows to clearly distinguish the
legacy usage from the nothing written usage.
|
|
|
|
Conflicts:
Makefile
src/gallium/drivers/softpipe/sp_screen.c
src/mesa/main/version.h
|
|
|
|
|
|
Also implement context member functions to optimize away those
flushes whenever possible.
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|
|
|
Only allows clearing currently bound buffers, but colour and depth/stencil in
a single call.
|
|
|
|
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
|
|
To prevent blocking when mapping a buffer.
|
|
|
|
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.
|
|
When passed to map() signals that the buffer's previous contents are
not required, allowing the driver to allocate a new buffer if the
current buffer can not be mapped immediately.
|
|
Knowing how the client intends to use the texture will give the
driver the opportunity to optimize for such cases.
|
|
|
|
|
|
|
|
|
|
Check for these caps in state tracker and enable corresponding GL extensions
if supported.
|
|
|
|
|
|
|
|
Conflicts:
src/mesa/state_tracker/st_atom_sampler.c
src/mesa/state_tracker/st_cb_texture.c
|
|
|
|
|
|
|
|
The cell driver still uses an internal CELL_FLUSH_WAIT flag, in the long run
proper fencing should be implemented for it.
|
|
Hardware almost universally expects us to set a special filtering mode
when anisotropic filtering is enabled, as opposed to varying a max-aniso
values. Do this once in the state tracker & simplify the driver code.
|
