| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
Configs without a renderable type are still informative for programs
such as eglinfo.
|
| |
|
|
|
| |
There is now _eglGetAPIContext that can return the current context of
the given API.
|
| |
|
|
|
|
| |
This reverts commit 627a45848faf9e6d19d386b9eb30d36bf18d0998.
I was wrong. Who could have known? :3
|
| | |
|
| |
|
|
|
|
| |
Bisected so that only this commit has to be reverted if I'm wrong.
...Pfft, like I'm ever wrong. :3
|
| | |
|
| |
|
|
| |
Hmm, need to cross-ref those TGSI things. My work is never done... :3
|
| | |
|
| |
|
|
|
| |
Signed-off-by: Corbin Simpson <[email protected]>
Tested-by: Mathias Fröhlich <[email protected]>
|
| |
|
|
| |
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).
|
| | | |
|
| | |
| |
| |
| | |
some drivers will complain if they don't know the cap bit
|
| | | |
|
| | |
| |
| |
| | |
works with tests/drawbuffers2
|
| | |
| |
| |
| | |
uses the new gallium per-rt blend functionality
|
| | |
| |
| |
| |
| | |
In some places blending was enabled even though it wasn't necessary.
Also remove a (bogus) reenabling of color writes, which wasn't really used.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
