| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
| |
Tested-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
| |
|
|
|
| |
Tested-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the set of functions which exist in GLES1 or GLES2 is
determined by hardcoded lists of function names in gles_api.py. This
patch encodes that information into the XML files using new
attributes, es1 and es2.
The es1 attribute denotes the first version of GLES 1 in which the
function exists (e.g. es1="1.1" means the function exists in GLES 1.1
but not GLES 1.0). "none" (the default) means the function is not
available in any version of GLES 1.
The es2 attribute denotes the first version of GLES 2/3 in which the
function exists (e.g. es2="2.0" means the function exists in both GLES
2.0 and GLES 3.0). "none" (the default) means the function is not
available in any version of GLES 2 or GLES 3.
Note that since GLES 3 is a strict superset of GLES 2, there is no
need for a separate attribute for it; instead, 'es2="3.0"' should be
used to denote functions that are present in GLES 3 but not GLES 2.
This patch only adds information about GLES versions 1.0, 1.1, and
2.0.
Later patches will modify the python code generation scripts to use
this information rather than the hardcoded lists in gles_api.py.
Tested-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An unfortunate quirk of Python 2 is that there are two types of
classes: "classic" classes (which are backward compatible with some
unfortunate design decisions made early in Python's history), and
"new-style" classes. Classic classes have a number of limitations
(for example they don't support super()) and are unavailable in Python
3. There's really no reason to use classic classes, except in
unmaintained legacy code. For more information see
http://www.python.org/download/releases/2.2.3/descrintro/.
This patch upgrades the Python code in src/mapi/glapi/gen to use
exclusively new-style classes.
Tested-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that ARB programs and fixed function are routed through the new
backend, shader might be NULL. Don't do INTEL_DEBUG=perf support in
that case, since it relies on shader->compiled_once.
Since INTEL_DEBUG=perf wasn't previously supported, this maintains the
status quo. It might be nice to support it someday, however.
This could be moved to brw_shader_program instead of brw_shader, but
it appears even prog can be NULL in that case.
Reviewed-by: Eric Anholt <[email protected]>
Signed-off-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
MaxIfDepth of 0 means "flatten all the time", not "never flatten".
This is only desirable on hardware that can't support control flow;
software rasterization and most hardware drivers want this.
This alters behavior for swrast as well as i915. Tested on i915.
NOTE: This is a candidate for stable release branches.
Reviewed-by: Ian Romanick <[email protected]>
Signed-off-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
| |
More dead code. I'm not sure what it was for.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
|
| |
The previous patch removed the producer of things in this file.
Since there aren't any, we can remove it.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
| |
All flags are now gone, so we can stop storing and passing this around.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
Nobody ever set the flag, which makes this dead code.
v2: Leave the ureg_DECL_fs_input_cyl function in place, even though it's
unused, since VMWare uses it for their internal projects.
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
|
| |
GLSL doesn't use the program code anymore. Accordingly, there were no
consumers of these flags, so there's no need to define them.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
These were only part of NV_fragment_program, so we can kill them.
The fact that PROGRAM_NAMED_PARAM appears in r200_vertprog.c is rather
comedic, but also demonstrates that people just spam the various types
of parameters everywhere because they're confusing.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
|
| |
Without NV programs, there's no need for the compatible_program_targets
function. A simple (non-)equality check will do.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
Also remove a leftover remnant from NV_vertex_program.
v2: Update for Imre's get changes.
Reviewed-by: Brian Paul <[email protected]> [v1]
Reviewed-by: Eric Anholt <[email protected]> [v1]
|
| |
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
| |
It apparently was only used for NV programs.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
| |
Nobody uses it anymore.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
| |
These are all unused now.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, Mesa used nvprogram.c's _mesa_GetVertexAttribPointervNV()
function to implement this GL call. There was also a second
implementation in varray.c, _mesa_GetVertexAttribPointervARB(), which
was entirely unused.
The varray.c variant has an additional assertion and checks the index
against ctx->Const.VertexProgram.MaxAttribs rather than
MAX_VERTEX_GENERIC_ATTRIBS. However, that variable is defined to the
same value, so it should be fine.
This will allow us to kill the duplicate function.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
Also kill the resulting dead code for display list handling.
v2: Also kill dlist's OPCODE_REQUEST_RESIDENT_PROGRAMS_NV.
Reviewed-by: Brian Paul <[email protected]> [v1]
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The NamedParameter functions were introduced in NV_fragment_program, and
are not shared with any other extensions.
Although this patch appears to remove the LocalParameter functions, it
does not: the ARB_fragment_program section also set them up. Now we
simply initialize them a single time.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
|
| |
No hardware drivers support this, it's obsolete, and unlikely to be
useful without NV_vertex_program, which is gone now.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
| |
This segfault was caused by commit
369e46888904c6d379b8b477d9242cff1608e30e, however it is my fault for not
testing the patch while it was on the list.
|
| | |
|
| |
|
|
|
|
| |
This extension is functionally the same as GL_ARB_map_buffer_range.
Reviewed-by: Ian Romanick <[email protected]>
|
| |
|
|
| |
Signed-off-by: Kristian Høgsberg <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
dri2DrawableGetMSC(), dri2WaitForMSC() and dri2WaitForSBC() were
inadvertently changed to return 0 on success. This resulted in the callers
returning an error to the client.
Restore the previous behavior and also check that the reply pointers are
valid before accessing them.
Reviewed-by: Eric Anholt <[email protected]>
|
| | |
|
| |
|
|
|
|
|
|
| |
Note that _mesa_GetVertexAttribPointervNV() is actually
glGetVertexAttribPointerv(), which operates on the generic attributes. The
geometry shader initialization looks like arbitrary cruft to me.
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
|
|
|
| |
v2: Rebase on top of get.c changes.
Reviewed-by: Brian Paul <[email protected]> (v1)
|
| |
|
|
|
|
| |
v2: Rebase on top of get.c changes.
Reviewed-by: Brian Paul <[email protected]> (v1)
|
| |
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
|
|
|
|
|
| |
Note that the MAP2 getters were missing from the implementation. Neat.
v2: Rebase on top of get.c changes.
Reviewed-by: Brian Paul <[email protected]> (v1)
|
| |
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
|
|
|
|
| |
While nuking NV_vertex_program, I noticed that one of my opcodes was used in a
strange place.
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
|
|
|
| |
v2: Remove dead positive() function, caught by Matt.
Reviewed-by: Brian Paul <[email protected]> (v1)
|
| |
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
|
|
|
|
| |
It's not supported in any hardware drivers, and doesn't appear to be useful on
Linux.
Reviewed-by: Brian Paul <[email protected]>
|
