| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Signed-off-by: Jeff Smith <[email protected]>
Signed-off-by: Brian Paul <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
negative constant."
This reverts commit a05fdbcb719ac64e6be842372813f0f4ca2f4f93.
Removing the comparison is wrong. The comparison with -1 should be changed
to another value (probably PROGRAM_UNDEFINED) along with another
change in the shader assembler.
Conflicts:
src/mesa/shader/prog_execute.c
|
| |
|
| |
|
|
|
|
|
| |
Exit the function early on the error path, instead of continuing, to
prevent a null pointer dereference later on.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
GL_EXT_texture_array is different from the existing GL_MESA_texture_array
support in that the former is only supported for GLSL, not fixed-function.
The shadow compare versions of the sampler functions haven't been tested
yet. The non-shadow versions have been tested with a new piglit test.
|
| |
|
| |
|
|
|
|
|
|
| |
glapi/dispatch.h is a core Mesa header file. Move the header file to
main/ to make this clear. It also becomes clear after this change that
IN_DRI_DRIVER is only used in core Mesa to enable the remap table.
|
| |
|
| |
|
|
|
|
| |
This reverts part of commit 298be2b028263b2c343a707662c6fbfa18293cb2
|
| |
|
|
|
|
|
|
| |
This function is only used for the NV unpack instructions.
Negate/abs make no sense and removing the code fixes Windows
compiler warnings. Found by Karl Schultz.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This may break the SUNOS4 build, but it's no longer relevant.
|
|
|
|
| |
This may break the SUNOS4 build, but it's no longer relevant.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
To reduce casting elsewhere...
|
|
|
|
|
| |
Add explicit casts, fix constant types, fix variable types.
Fixes about 340 warnings in MSFT Visual Studio.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For GL_ARB_fragment_coord_conventions.
This only applies to gl_FragCoord and controls pixel center origin and
pixel center integer. For example:
layout (origin_upper_left, pixel_center_integer) varying vec4 gl_FragCoord;
This features introduces the idea of re-declaring variables with a changed
type. This may also apply to arrays in some cases but that's not
implemented at this time.
|
|
|
|
|
| |
Note: because of a weird dependency checking bug, a 'make clean' may be
needed before recompiling.
|
| |
|
| |
|
|
|
|
|
| |
Since extension name and extension name string are the same, collapse
them into one name.
|
|
|
|
|
|
|
|
|
| |
Both the #extension directive name and the preprocessor symbol start
with the GL_ prefix. For example:
...
New glean/glsl1 tests have been added to test the #extension feature.
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
src/gallium/drivers/nv10/nv10_state.c
src/gallium/drivers/nv20/nv20_state.c
src/gallium/drivers/nv50/nv50_program.c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The point size min/max registers (unused by mesa state tracker) were removed
since most hardware couldn't do much with them. However, we don't want to have
to rely on hw to do point size clamping correctly to implementation
dependent limits, hence have to do that in the vertex shader. This should also
solve a potential problem with (non-AA) points smaller than 1.0 which according
to OGL still have size 1.0.
Note that OGL point rendering is odd, in particular point sprites are rasterized
differently to points. Some hardware might support those different modes, but in
any case the different clamping values used for smooth/multisampled/sprite
enabled points might help a bit for hw which rasterizes points the same as point
sprites.
Also tweak mesa's ff to vertex shader translation so don't have to clamp twice in
case of point attenuation.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the texture priority field is 0.125 set the PROG_PARAM_BIT_CYL_WRAP
flag. The gallium state tracker will look for this flag.
This feature is only for testing purposes and may be remove at some
point. But if it's useful we could write a GL/Mesa extension to
expose it properly.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
GL_TRUE indicates that the driver accepts the program.
GL_FALSE indicates the program can't be compiled/translated by the
driver for some reason (too many resources used, etc).
Propogate this result up to the GL API: set GL_INVALID_OPERATION
error if glProgramString() was called. Set shader program link
status to GL_FALSE if glLinkProgram() was called.
At this point, drivers still don't do any program checking and
always return GL_TRUE.
|
| |
| |
| |
| | |
Further testing should reveal if any these assertions are hit...
|