- Aug 31, 2012
-
-
Ian Romanick authored
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com>
-
Ian Romanick authored
Now that OpenGL 3.1 is supported by at least one driver, follow tradition and bump the major version number. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com>
-
- Aug 30, 2012
-
-
Marek Olšák authored
There doesn't seem to be anything wrong with it.
-
Marek Olšák authored
Everything works except for blitting MSAA colorbuffers, which isn't so trivial on Cayman. It's a rarely-used feature anyway.
-
Anuj Phogat authored
This is required to get the program recompiled when SampleAlphaToCoverage is enabled. Reviewed-by: Paul Berry <stereotype441@gmail.com>
-
Marek Olšák authored
DRM 2.22.0 is required though. Also require the new DRM for r700, as there are some important fixes for that generation too.
-
Marek Olšák authored
-
Marek Olšák authored
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.
-
Marek Olšák authored
-
Marek Olšák authored
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.
-
Marek Olšák authored
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
-
Marek Olšák authored
This one actually makes more sense and gives the expected value for MSAA resolve. Reviewed-by: Jerome Glisse <jglisse@redhat.com>
-
Marek Olšák authored
-
This partially reverts d638da23. 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>
-
Brian Paul authored
Reviewed-by: Paul Berry <stereotype441@gmail.com>
-
fixes dlopen issue caused by 57c57df7 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54140 Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Signed-off-by: José Fonseca <jfonseca@vmware.com>
-
Christian König authored
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
-
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
-
- Aug 29, 2012
-
-
Kenneth Graunke authored
Prior to commit 2f186982, 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 2f186982. 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>
-
Ian Romanick authored
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>
-
Ian Romanick authored
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>
-
Ian Romanick authored
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
This and the previous three commits should probably be squashed together... Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
This is done by changing the API to API_OPENGL_CORE. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
Functionally the same as GL_ARB_vertex_array_object. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
-
Ian Romanick authored
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>
-
Ian Romanick authored
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
Also disallow the 1, 2, 3, and 4 formats. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
There is text in the OpenGL 3.x specs to explicitly allow this case. Weird. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
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>
-
Paul Berry authored
Signed-off-by: Paul Berry <stereotype441@gmail.com> Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Emma Anholt authored
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.
-