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.
|
|
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.
|
|
Exposing it was incorrect, as the GLSL part of the extension is
missing.
We still keep the ARB_fragment_coord_conventions field, so that the
ARBfp parser can know whether to accept or reject the keywords.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Note that when detaching the PBO from the region and making a new BO
for the region, we don't make it tiled even if the region originally
was.
Fixes piglit pbo-teximage-tiling.
|
|
|
|
|
|
|
|
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.
|
|
MakeCurrent unbinds the current context of the current API. Modify the
current API to make sure all contexts are correctly unbound.
|
|
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.
|
|
It works similar to _eglMakeCurrent, except that the old context and
surfaces are returned instead of destroyed. _eglMakeCurrent is now
calling the new _eglBindContext.
|
|
The driver pointer of the display was used to decide whether a display
is initialized. Use a boolean for that purpose allows accessing the
driver of an uninitialized display.
|
|
|
|
|
|
|
|
|
|
|
|
|