| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Many of the EXT_ extensions in the subset have significant code
overhead with no users. It is not a required part of GL -- though
text describing the extension is part of the core spec since 1.2, it
is always conditional on the ARB_imaging extension.
|
| |
|
|
| |
looks like mesa st didn't get updated.
|
| |
|
|
|
| |
We will typically have a current context when we need to lookup the image,
but the lookup implementation don't need it so drop it.
|
| | |
|
| |
|
|
|
|
| |
Fixes:
glsl1-precision exp2
glsl1-precision log2
|
| |
|
|
|
|
|
|
| |
The new checks for sanity in ir_assignment creation got angry about
this write_mask == 0. Fixes:
glsl-fs-dot-vec2.
glsl-fs-atan-2
glsl-fs-dot-vec2
|
| |
|
|
| |
+113 piglits.
|
| |
|
|
| |
Fixes: glsl-mat-from-int-ctor-03
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that most people new to this IR are surprised when an
assignment to (say) 3 components on the LHS takes 4 components on the
RHS. It also makes for quite strange IR output:
(assign (constant bool (1)) (x) (var_ref color) (swiz x (var_ref v) ))
(assign (constant bool (1)) (y) (var_ref color) (swiz yy (var_ref v) ))
(assign (constant bool (1)) (z) (var_ref color) (swiz zzz (var_ref v) ))
But even worse, even we get it wrong, as shown by this line of our
current step(float, vec4):
(assign (constant bool (1)) (w)
(var_ref t)
(expression float b2f (expression bool >=
(swiz w (var_ref x))(var_ref edge))))
where we try to assign a float to the writemasked-out x channel and
don't supply anything for the actual w channel we're writing. Drivers
right now just get lucky since ir_to_mesa spams the float value across
all the source channels of a vec4.
Instead, the RHS will now have a number of components equal to the
number of components actually being written. Hopefully this confuses
everyone less, and it also makes codegen for a scalar target simpler.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
| |
|
|
|
|
|
| |
We can't expect to have a context when this is called, and we don't need one
so just require a __DRIscreen instead.
Reported by Yu Dai <[email protected]>
|
| |
|
|
|
|
|
| |
Fix commit e7087175f8a04f777403366fb34b58edd00f4d60. Move the reference to
GL_VERSION_2_1_functions to intel_extensions.c where it's available,
don't try to enable a non-existing extension and advertise 1.20 for all
intel chipsets, not just GEN4 and up.
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of using the invalid GL_ARB_shading_language_120 extension to
determine the GLSL version, use a new ctx->Const.GLSLVersion field.
Updated the intel and r600 drivers, but untested.
See fd.o bug 29910
NOTE: This is a candidate for the 7.9 branch (but let's wait and see if
there's any regressions).
|
| |
|
|
|
|
|
|
| |
Looks like the problem was we weren't passing the depth to the render
target as expected, so the chip would wedge. Fixes GPU hang in
occlusion-query-discard.
Bug #30097
|
| |
|
|
| |
This is required by the spec, so respect that.
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Implement the pipe_rasterizer_state::sprite_coord_enable field
in the draw module (and softpipe) according to what's specified
in the documentation.
The draw module can now add any number of extra vertex attributes
to a post-transformed vertex and generate texcoords for those
attributes per sprite_coord_enable. Auto-generated texcoords
for sprites only worked for one texcoord unit before.
The frag shader gl_PointCoord input is now implemented like any
other generic/texcoord attribute.
The draw module now needs to be informed about fragment shaders
since we need to look at the fragment shader's inputs to know
which ones need auto-generated texcoords.
Only softpipe has been updated so far.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Use rc_pair_ prefix for all pair instruction structs
Create a named struct for pair instruction args
Replace structs radeon_pair_instruction_{rgb,alpha} with struct
radeon_pair_sub_instruction. These two structs were nearly identical
and were creating a lot of cut and paste code. These changes are the
first step towards removing some of that code.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Bug #30208.
|
| | |
| |
| |
| |
| |
| | |
Can be reproduced with mesa/demos/src/tests/blitfb.
NOTE: This is a candidate for the 7.9 branch.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit c32bac57ed445e48856d74113364287ed6e5cdd4
and silences the warning differently.
The _mesa_reference_texobj() function is called quite a bit and
we don't want to call valid_texture_object() all the time in non-
debug builds.
|
| | |
| |
| |
| |
| | |
Silences the following GCC warning on Mac OS X.
x86/common_x86.c:58: warning: 'detection_debug' defined but not used
|
| | | |
|
| | |
| |
| |
| |
| | |
Fixes this GCC warning.
warning: missing initializer for member 'statevar_element::array_indexed'
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This function is executed outside _mesa_meta_begin/end(), that means
that e.g. _mesa_meta_Bitmap() clobbers the texturing state because it
changes the currently active texture object.
There's no need to bind the new texture when it's created, it's done
again later anyway (from setup_drawpix/copypix_texture()).
Signed-off-by: Brian Paul <[email protected]>
|
| |
|
|
|
| |
Otherwise, FEATURE_EXT_texture_sRGB was undefined.
This is (part of?) the fix for fd.o bug 30177.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Signed-off-by: Francisco Jerez <[email protected]>
|
| |
|
|
| |
Signed-off-by: Francisco Jerez <[email protected]>
|
| |
|
|
|
|
| |
Enable some extensions now that the needed tokens are defined in
GLES/glext.h and GLES2/glext.h. Update the prototype of MultiDrawArrays
now that the prototype of _mesa_MultiDrawArraysEXT has been updated.
|
| | |
|
