| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
Add features tested in the code but missing from mfeatures.h.
This also fixes some tests of features. They should be tested with
"#if", not "#ifdef".
|
|
|
|
|
|
| |
This must always be true now, so there is no reason to check it. Ever.
Signed-off-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
| |
Remove the rgbMode and indexBits parameters from _mesa_create_visual
and _mesa_initialize_visual. These values are now hardcoded to
GL_TRUE and 0.
Signed-off-by: Ian Romanick <[email protected]>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This object can be shared with another context, so we cannot just
delete it when the owning context is being destroyed.
Ensuring that buffer objects are properly refcounted guarantees
NullBufferObj is destroyed when all references to it are removed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were misinterpretting GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS previously.
It's the number of texture units for which we need to keep state; not
just the total number of texture units addressable by the vertex shader
plus fragment shader.
Since sw Mesa independently supports 16 texture units in vertex shaders
and 16 texture units in fragment shaders, the max combined units is 32.
Note that the docs for glActiveTexture() indicate the max legal unit is
MAX(GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS, MAX_TEXTURE_COORDS) - 1.
A new piglit test (texunits.c) tests the various texture unit limits.
I'm pretty sure I've got this all right now, but additional reviews
are welcome...
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
...rather than checking/validating before all the calls to
_mesa_valid_to_render() and valid_to_render().
The next patch will actually fix some bugs...
(cherry picked from commit 23eda89ec89e2bd5bc26077bd56e8d6b5d4040d4)
|
|
|
|
|
|
| |
Removed _glapi_noop_enable_warnings() and _glapi_set_warning_func().
Just check the DEBUG env vars and call fprintf(stderr) with a warning
message instead.
|
| |
|
|\
| |
| |
| |
| |
| | |
Conflicts:
src/gallium/state_trackers/xorg/xorg_xv.c
src/mesa/drivers/dri/intel/intel_span.c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The assertion is that the correct read type to be using is the native
type of the underlying read renderbuffer. For some fallback paths, this
may be worse than GL_RGBA/GL_UNSIGNED_BYTE for reads today, but it gets
all drivers the expected GL_BGRA/GL_UNSIGNED_BYTE for ARGB8888 or
GL_BGR//GL_UNSIGNED_SHORT_5_6_5_REV for rgb565 with no work.
This fixes the intel (and other) DRI drivers to report read formats that
should hit blit PBO readpixels paths.
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a GLbitfield64 type and several macros to operate on 64-bit
fields. The OutputsWritten field of gl_program is changed to use that
type. This results in a fair amount of fallout in drivers that use
programs.
No changes are strictly necessary at this point as all bits used are
below the 32-bit boundary. Fairly soon several bits will be added for
clip distances written by a vertex shader. This will cause several
bits used for varyings to be pushed above the 32-bit boundary. This
will affect any drivers that support GLSL.
At this point, only the i965 driver has been modified to support this
eventuality.
I did this as a "squash" merge. There were several places through the
outputswritten64 branch where things were broken. I foresee this
causing difficulties later for bisecting. The history is still
available in the branch.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm.h
|
|
|
|
| |
Signed-off-by: Chia-I Wu <[email protected]>
|
|
|
|
|
|
| |
Also remove the unused initialization and GLchan fetch functions.
Signed-off-by: Chia-I Wu <[email protected]>
|
|
|
|
|
|
|
|
| |
This is made possible by making glapioffsets.h and glapidispatch.h
internal headers of glapi. They should only be included indirectly
through dispatch.h by mesa.
Signed-off-by: Chia-I Wu <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This enables the remap table in core. driInitExtensions is adapted to
use the remap table. All uses of extension_helper.h are replaced by
remap_helper.h. The chicken-egg problem of the DRI drivers is also
solved.
It is now also possible to pass NULL extensions to driInitExtensions.
It will cause driInitExtensions to map all known functions. This
functionality is used by software drivers and EGL_i915.
Signed-off-by: Chia-I Wu <[email protected]>
|
|\ |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Fixes bug 24402.
|
| | |
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
src/gallium/auxiliary/util/u_cpu_detect.c
|
| | |
|
| |
| |
| |
| |
| | |
As shown in mfeatures.h, this allows users of dlist.h to work without
knowing if the feature is available.
|
| |
| |
| |
| |
| | |
As shown in mfeatures.h, this allows users of eval.h to work without
knowing if the feature is available.
|
| |
| |
| |
| |
| | |
It merges FEATURE_ARB_occlusion_query and FEATURE_EXT_timer_query, and
follows the feature conventions.
|
| |
| |
| |
| |
| | |
As shown in mfeatures.h, this allows users of feedback.h to work without
knowing if the feature is available.
|
| |
| |
| |
| |
| | |
It is separated from FEATURE_drawpix and made to follow the feature
conventions.
|
| |
| |
| |
| |
| | |
As shown in mfeatures.h, this allows users of histogram.h to work without
knowing if the feature is available.
|
| |
| |
| |
| |
| | |
As shown in mfeatures.h, this allows users of attrib.h to work without
knowing if the feature is available.
|
| |
| |
| |
| |
| | |
As shown in mfeatures.h, this allows users of accum.h to work without
knowing if the feature is available.
|
| |
| |
| |
| |
| | |
As shown in mfeatures.h, this allows users of colortab.h to work
without knowing if the feature is available.
|
| |
| |
| |
| |
| |
| | |
This reverts commit 651cffd626a82d9bf539437ca4bdf8ea4b396fab.
The commit inadvertantly introduced a new gallium dependency on the meta code.
|
|/ |
|
|
|
|
|
| |
This isn't quite right yet. The delete behavior and the context
clean-up needs some work.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several changes are made to program parameter limits. Several of the
non-NATIVE limits are set higher. All of the NATIVE limits are set to
zero in the core Mesa code. Each driver must set the actual value in
its context creation routine. If the NATIVE value remains zero, this
indicates that hardware shaders may not be supported.
Each of the preceeding changes matches the bahavior of Apple's shader
assembler, so it seems safe.
Finally, we limit the value of MaxEnvParams to be no greater than
MaxNativeAttribs. At least one case has been found where an
application does the wrong thing if MaxNativeAttribs < MaxEnvParams.
See also bugzilla #23490.
|
| |
|
|
|
|
|
| |
This info is essential to using/debugging a shader outside of its normal
application.
|
|
|
|
|
| |
Tests if the current shader/program is valid and that the framebuffer is
complete. To be called by glBegin, glDrawArrays, etc.
|
|\ |
|
| |
| |
| |
| |
| | |
The ARB version requires VAOs to be per-context while the Apple extension
was ambiguous.
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/drivers/dri/i915/i915_tex_layout.c
src/mesa/drivers/dri/i965/brw_wm_glsl.c
src/mesa/drivers/dri/intel/intel_buffer_objects.c
src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
src/mesa/drivers/dri/intel/intel_pixel_draw.c
src/mesa/main/enums.c
src/mesa/main/texstate.c
src/mesa/vbo/vbo_exec_array.c
|