| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Hmm, need to cross-ref those TGSI things. My work is never done... :3
|
|
|
|
Signed-off-by: Corbin Simpson <MostAwesomeDude@gmail.com>
Tested-by: Mathias Fröhlich <Mathias.Froehlich@gmx.net>
|
|
The spec says that it only works with OpenGL ES.
|
|
A context can be bound to a surface just like it can be bound to a
thread. CurrentContext is a more consistent name.
|
|
if independent blend state was disabled, only the data from first rt was
stored, however the comparison used the full state, hence there never was
a match and always a new object was created.
Fixes a huge performance drop with llvmpipe due to recompilation.
|
|
|
|
Changes in v4:
- Rebase and modify for changes in previous patches
Changes in v3:
- Use positive caps instead of negative caps
Changes in v2:
- Now takes the fragment convention directly from the fragment shader
Adds internal support for all fragment coord conventions to softpipe.
This patch is not required for use with the current state trackers, but it
allows softpipe to run any TGSI program and enhances performance.
|
|
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.
|
|
Changes in v3:
- Documented the new properties
- Added comments for property values
- Rebased to current master
Changes in v2:
- Caps are added in a separate, subsequent patch
This adds two TGSI fragment program properties that indicate the
fragment coord conventions.
The properties behave as described in the extension spec for
GL_ARB_fragment_coord_conventions, but the default origin in
upper left instead of lower left as in OpenGL.
The syntax is:
PROPERTY FS_COORD_ORIGIN [UPPER_LEFT|LOWER_LEFT]
PROPERTY FS_COORD_PIXEL_CENTER [HALF_INTEGER|INTEGER]
The names have been chosen for consistency with the GS properties
and the OpenGL extension spec.
The defaults are of course the previously assumed conventions:
UPPER_LEFT and HALF_INTEGER.
|
|
|
|
|
|
|
|
progs/tests/drawbuffers should work, except I can't test it. GG new
shader parser. GG.
|
|
|
|
Hmm, does this belong in context, next to set_constant_buffer? Maybe
a paragraph in shaders might be useful.
|
|
|
|
|
|
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 is to maintain backward compatibility with drivers
that don't support arrays of constant buffers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This will allow us to declare two-dimensional constant buffers.
|
|
|
|
Oh look, that one question about map_buffer_range is answered.
|
|
|
|
|
|
There might be some optimizations possible here...
|
|
_eglMakeCurrent is a big hammer that is not easy to use. Migrate
drivers to use _eglBindContext and un-export _eglMakeCurrent.
|
|
When no context or surface are given, the display is allowed to be
uninitialized. Most drivers cannot handle an uninitialized display.
But they are updated to at least throw a fatal message.
|
|
|
|
|
|
|
|
|
|
|
|
|
