The blend state is different and the resolve single-sample buffer must have
FMASK and CMASK enabled. I decided to have one CMASK and one FMASK
per context instead of per resource.
There are new FMASK and CMASK allocation helpers and a new buffer_create
helper for that.
The color resolve on r6xx needs PT_RECTLIST. Using conventional primitive
types (triangles and quads) produces an ugly line between two diagonally
opposite corners. I guess a rectangular point sprite would work too.
This partially reverts d638da23d2.
With gallium the meta code is not always built so the call to
_meta_in_progress() was unresolved. Simply special-case the
GL_MULTISAMPLE case in the meta code. There might be other special
cases in the future given all the differences between legacy GL,
core GL, GLES, etc.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=54234
and https://bugs.freedesktop.org/show_bug.cgi?id=54239
v2 (Paul Berry <stereotype441@gmail.com>): keep _meta_in_progress
function, since it's needed by the i965 driver, but don't call it from
core mesa.
Signed-off-by: Brian Paul <brianp@vmware.com>
Prior to commit 2f1869822, emit_fb_writes() looped from 0 to 3, writing
all four components of a vec4 color output. However, that broke for
smaller output types (float, vec2, or vec3). To fix that, I introduced
a new variable (output_components[]) containing the size of the output
type for each render target.
Unfortunately, I forgot to actually initialize it in the constructor,
which meant that unless a shader wrote to gl_FragColor, or the specific
output for each render target, output_components would contain a garbage
value, and we'd loop for a completely non-deterministic amount of time.
Not actually emitting any color writes seems like the right approach.
We may still need to emit a render target write (to terminate the
thread), but don't have to put in any sensible values (the shader didn't
write anything, after all).
Fixes a regression since 2f18698220.
NOTE: This is a candidate for stable release branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54193
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Tested-by: Ian Romanick <idr@freedesktop.org>
It is possible to force S3TC extensions to be enabled. This is
generally done to support applications that will only supply
pre-compressed textures. This accounts for the vast majority of
applications.
However, there is still the possibility of an application asking for
on-line compression. In that case, generate a warning and substitute a
generic compressed format. The driver will either pick an uncompressed
format or a compressed format that Mesa can handle on-line (e.g., FXT1).
This should only cause problems for applications that request on-line
compression and read the compressed texture back. This is likely an
infinitesimal subset of an already infinitesimal subset.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Fix API_OPENGL_CORE handling when TEXTURE_FLOAT_ENABLED is not
defined. Based on review feedback from Eric Anholt.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This is a purely software extension. The drivers don't need to do any
work to support it.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Page 407 (page 423 of the PDF) of the OpenGL 3.0 spec says (in the list
of deprecated functionality):
"Separate polygon draw mode - PolygonMode face values of FRONT and
BACK; polygons are always drawn in the same mode, no matter which
face is being rasterized."
Also modify meta to not use FRONT or BACK in a core context.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
We were calling through a dispatch table entry that was NULL, since the apple
variant is only on legacy desktop. Just call the function we mean instead of
indirecting through the dispatch.
v2: Use API_OPENGL_CORE.
v3: Only require desktop GL. If a driver can't support TexBOs in a non-core
context, it should not enable them.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Fix completely broken condition around ClearColorIiEXT and
ClearColorIuiEXT.
v3: Add special VertexAttrib handling for ES2.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
The comment in the code even says this is the right thing to do.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
All drivers in Mesa do. This allows a lot of extension checking code to be
gutted from the function.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Anuj Phogat
Marek Olšák
Brian Paul
Tapani Pälli
Christian König
Eric Anholt
Kenneth Graunke
Ian Romanick
Paul Berry