summaryrefslogtreecommitdiff
path: root/src/mesa
AgeCommit message (Collapse)AuthorFilesLines
2013-07-30driconf: enable app-specific workarounds for all driversMarek Olšák2-2/+6
They were only enabled for i965. Note that drirc must be installed in /etc. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2013-07-30st/dri: implement the driconf option force_s3tc_enable properlyMarek Olšák1-9/+1
Reviewed-by: Brian Paul <brianp@vmware.com>
2013-07-30driconf: remove the unused option allow_large_texturesMarek Olšák1-9/+0
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2013-07-30st/dri: support the driconf option disable_blend_func_extendedMarek Olšák1-1/+2
This is needed for Unigine. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Brian Paul <brianp@vmware.com>
2013-07-30mesa: default texture buffer format should be R8 in the core profileMarek Olšák1-2/+2
Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> v2: Since we don't expose the extension in the compatibility profile, the "if (API == CORE) .. else .." statement is removed.
2013-07-30mesa: default DEPTH_TEXTURE_MODE should be RED in the core profileMarek Olšák8-10/+12
Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-07-30st/mesa: expose EXT_framebuffer_multisample_blit_scaled if MSAA is supportedMarek Olšák1-0/+1
Surprisingly all drivers supporting MSAA can already do this (r300g and r600g for sure) and I think Christoph wanted to have this feature for his Nouveau drivers anyway.
2013-07-30st/mesa: fix sRGB renderbuffers without EXT_framebuffer_sRGB supportMarek Olšák2-0/+15
https://bugs.freedesktop.org/show_bug.cgi?id=59322 Cc: mesa-stable@lists.freedesktop.org
2013-07-30glsl: Remove redundant writes to prog->LinkStatusPaul Berry1-1/+0
The linker_error() function sets prog->LinkStatus to false. There's no reason for the caller of linker_error() to also do so. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2013-07-29mesa: Remove broken assertion about enabled texture targets.Kenneth Graunke1-4/+2
For GLSL programs, enabledTargets can have more than one bit set. For example, a shader that uses sampler2D and samplerCube uniforms will have both TEXTURE_2D_BIT and TEXTURE_CUBE_BIT set. The code that sets _ReallyEnabled already handles this, selecting the "highest priority" texture target. We should simply use that. Fixes new Piglit test incomplete-textures-of-multiple-types. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62698 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Brian Paul <brianp@vmware.com>
2013-07-29i965: Don't create a swrast context on ES2+.Kenneth Graunke1-1/+1
We already skip this for API_OPENGL_CORE; ES2+ is very similar. The primary user of the swrast context is GL_SELECT and GL_FEEDBACK, which have never existed in ES. This saves approximately 18MB of memory in GLBenchmark 2.7 Egypt (ES2). No regressions in es3conform on Ivybridge. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Chad Versace <chad.versace@linux.intel.com> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
2013-07-29mesa: Expose OES_surfaceless_context.Matt Turner1-0/+1
EGL_KHR_surfaceless_context extension allows contexts to be made current without a default winsys fbo. This extension specifies what ES 1.1 and 2.0 should do (the ES 3.0 spec already does). Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-07-29mesa: Return GL_FRAMEBUFFER_UNDEFINED if the winsys fbo is incomplete.Matt Turner1-2/+6
Specified by ARB_framebuffer_object, GL 3.0, and ES 3.0. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-07-26mesa: Disable GL_EXT_framebuffer_object in core profiles and OpenGL 3.1Ian Romanick1-1/+1
GL_EXT_framebuffer_object differs from GL_ARB_framebuffer_object in ways that we can't and don't implement in core profiles. Exposing it is a lie, so we shouldn't do that. It's possible the some other GL_EXT_framebuffer_* extensions should be disabled, but it's not quite so clear cut. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-07-27i965/vs: Fix flaky texture swizzlingChris Forbes1-1/+1
If any component used the ZERO or ONE swizzle, its corresponding member in the `swizzle` array would never be initialized. We *mostly* got away with this, except when that memory happened to contain a value that clobbered another channel when combined using BRW_SWIZZLE4(). NOTE: This is a candidate for stable branches. Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-07-25Revert "i965: Delete pre-DRI2.3 viewport hacks."Kenneth Graunke3-1/+25
This reverts commit c9db037dc999eadbcaa8816c814e6ec1776d1a40. Eric believes that the viewport hacks are still necessary for EGL; invalidate events aren't hooked up properly. This commit caused a regression where EFL applications wouldn't show anything other than window decorations; GLBenchmark also showed issues. The revert had conflicts due to the intel_context/brw_context merge. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66606 Cc: mesa-stable@lists.freedesktop.org
2013-07-25i965: Initialize inout_offset parameter to brw_search_cache().Paul Berry2-2/+2
Two callers of brw_search_cache() weren't initializing that function's inout_offset parameter: brw_blorp_const_color_params::get_wm_prog() and brw_blorp_const_color_params::get_wm_prog(). That's a benign problem, since the only effect of not initializing inout_offset prior to calling brw_search_cache() is that the bit corresponding to cache_id in brw->state.dirty.cache may not be set reliably. This is ok, since the cache_id's used by brw_blorp_const_color_params::get_wm_prog() and brw_blorp_blit_params::get_wm_prog() (BRW_BLORP_CONST_COLOR_PROG and BRW_BLORP_BLIT_PROG, respectively) correspond to dirty bits that are not used. However, failing to initialize this parameter causes valgrind to complain. So let's go ahead and fix it to reduce valgrind noise. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66779 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-07-24mesa: implement mipmap generation for compressed 2D array texturesBrian Paul1-16/+43
We weren't looping over all the slices in the array. The updated code should also correctly handle 3D compressed textures too, whenever we have that feature. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66850 NOTE: This is a candidate for the 9.x branches Cc: mesa-stable@lists.freedesktop.org Reviewed-by: José Fonseca <jfonseca@vmware.com>
2013-07-24meta: handle 2D texture arrays in decompress_texture_image()Brian Paul1-2/+21
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66850 NOTE: This is a candidate for the 9.x branches. Cc: mesa-stable@lists.freedesktop.org Reviewed-by: José Fonseca <jfonseca@vmware.com>
2013-07-24mesa: handle 2D texture arrays in get_tex_rgba_compressed()Brian Paul1-28/+24
If we call glGetTexImage() for a compressed 2D texture array we need to loop over all the slices. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66850 NOTE: This is a candidate for the 9.x branches. Cc: mesa-stable@lists.freedesktop.org Reviewed-by: José Fonseca <jfonseca@vmware.com>
2013-07-24mesa: fix rgtc snorm decodingRoland Scheidegger1-3/+3
The codeword must be unsigned (otherwise will shift in 1's from above when merging low/high parts so some texels decode wrong). This also affects gallium's util/u_format_rgtc. Reviewed-by: Jose Fonseca <jfonseca@vmware.com> Reviewed-by: Zack Rusin <zackr@vmware.com>
2013-07-22build: Add tests directories to SUBDIRSMatt Turner1-1/+1
Fixes a problem with distcheck.
2013-07-21scons: Don't use -z defs ld option on Mac.José Fonseca1-1/+2
Should fix fdo bug 67098.
2013-07-19scons: Disallow undefined symbols in Xlib libGL.so.José Fonseca1-0/+3
It's not the first time that, due to missing build dependencies or incomplete commits, we end up with a broken libGL.so that's missing symbols, causing all tests to fail catastrophically. Instead try to catch this sort of issues earlier.
2013-07-18mesa: Dispatch ARB_framebuffer_object and EXT_framebuffer_object differently9.2-branchpointTomasz Lis3-0/+24
Almost all of the functions between the ARB and the EXT share the same GLX protocol because the functionality is, essentially, identical. However, there are some differences between the extensions: - In the ARB extension, names must come from glGenBuffers. - In the ARB extension, framebuffer objects are not shared (but they are in the EXT). For these reasons, glBindFramebuffer and glBindRenderbuffer have different GLX protocol opcodes than their EXT counterparts. Currently these functions alias each other in the dispatch table. This makes it impossible to be truly spec conformant. This patch enables fixing the conformance issue by splitting glBindFramebuffer / glBindFramebufferEXT and glBindRenderbuffer / glBindRenderbufferEXT into separate dispatch table entries. Patches will be available shortly to: - Fix the conformance issue. - Stop advertising the EXT in OpenGL 3.1 (or core profiles). HOWEVER, this does represent a compatibility break between the loader (libGL or the Xserver GLX module) and the driver. Mesa drivers compiled without this change will request a single dispatch table entry for glBindFramebuffer and glBindFramebufferEXT. Since the updated loader has different entries for each, the request will fail, and the driver will die in a fire. Drivers built with the change should continue to load fine on loaders without the change. In this case, the driver will separately ask for entries for glBindFramebuffer and glBindFramebufferEXT, and the loader will tell it the same location. Since the loader in the server's GLX module is not (yet) updated, this should not be a problem. We also do not advertise the ARB extension from the server, so, again, this should not be a problem for the server. HOWEVER, this means that DRI1 drivers (remember mga_dri.so?) will no longer load with libGL build hereafter. That means this patch will need to be back ported to the 8.0 branch. v2 (idr): Added missing GLX protocol opcodes for the EXT functions and corrected the opcodes for the ARB functions. Updated GLX indirect_api unit test and dispatch sanity unit test. Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Bartosz Zawistowski <bartosz.l.zawistowski@intel.com> Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v1]
2013-07-18st/mesa: Enable the ARB_shading_language_420pack extension for 1.30+.Kenneth Graunke1-0/+1
Any driver that supports GLSL 1.30 should be able to handle this extension, as it's entirely implemented in the GLSL compiler. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Marek Olšák <maraeo@gmail.com>
2013-07-18i965: Enable the GL_ARB_shading_language_420pack extension on Gen6+.Kenneth Graunke1-0/+1
While all the work is in the shared GLSL compiler, this extension requires GLSL 1.30, which is currently only supported on Gen6+. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-07-18i965: Combine URB code emission into a single group.Kenneth Graunke1-10/+2
All four URB packets need to be programmed together in order for the GPU state to be valid. Putting them in separate BEGIN..ADVANCE blocks is risky: if we're nearing the end of a batch, the batch could be flushed inbetween two of the commands, causing the URB programming to be split into two batchbuffers. This -might- be okay with hardware contexts, but it offers no advantages over keeping them together, and has a potential for hangs. Putting them into a single BEGIN..ADVANCE block ensures they'll be kept in the same batch, which seems wise. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
2013-07-18i965/hsw: Change L3 MOCS for depth, hiz, and stencilChad Versace2-4/+9
Change from "not cacheable" to "cacheable" in L3. Do so for the draw upload path and blorp. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
2013-07-18i965/hsw: Change L3 MOCS of 3DSTATE_CONSTANT_VS/PSChad Versace3-3/+9
Change from "not cacheable" to "cacheable" in L3. Do so for the draw upload path and blorp. In blorp, change only the PS packet, because the VS packet is disabled. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
2013-07-18i965/hsw: Change L3 MOCS of SURFACE_STATChad Versace2-2/+8
Change from "not cacheable" to "cacheable" in L3. Do so for the draw upload path and blorp. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
2013-07-18i965/hsw: Change L3 MOCS of 3DSTATE_VERTEX_BUFFERSChad Versace2-0/+6
Change from "not cacheable" to "cacheable" in L3. Do so for the draw upload path and blorp. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
2013-07-18dri: Introduce new flags in __DRI_ATTRIB_RENDER_TYPETomasz Lis1-6/+0
Mark __DRI_ATTRIB_FLOAT_MODE as deprecated, and introduce new flags to __DRI_ATTRIB_RENDER_TYPE for float modes. Both signed float (fbconfig_float) and unsigned (packed_float) are introduced. The old attribute should be set for both float modes. v2 (idr): Require that the render mode from the DRI attributes matches the render mode of the config exactly. This is the behavior of the old code. Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2013-07-18glx: Validate the GLX_RENDER_TYPE valueTomasz Lis1-1/+4
Correctly handle the value of renderType in GLX context. In case of the value being incorrect, context creation fails. v2 (idr): indirect_create_context is just a memory allocator, so don't validate the GLX_RENDER_TYPE there. Fixes regressions in several GLX_ARB_create_context piglit tests. Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2013-07-18glx: Changes to visual configs initialization.Tomasz Lis1-1/+6
Correctly handle the value of renderType and drawableType in fbconfig. Modify glXInitializeVisualConfigFromTags to read the parameter value, or detect it if it's not there. v2 (idr): If there was no GLX_RENDER_TYPE property, set the type based purely on the rgbMode as the previous code did. It is impossible for floatMode to be set at this point, so we can't have a float config. The previous code regressed a large number of piglit GLX tests because those tests don't set GLX_RENDER_TYPE in the glXChooseConfig call. Restoring the old behavior for that case fixes those regressions. Also fix handling of GLX_DONT_CARE for GLX_RENDER_TYPE. Fixes a regression in glx-dont-care-mask. Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2013-07-18i965: Add #defines for Memory Object Control State fields on Gen7-7.5.Kenneth Graunke1-0/+26
The L3 controls are identical on all platforms, but LLC differs: - Ivybridge has a "cache in LLC" flag - Baytrail has no LLC, but instead has a snoop bit: "data accesses in this page must be snooped in the CPU caches." - Haswell has writeback/uncached flags for LLC and eLLC (eDRAM). Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
2013-07-18gen_matypes: fix cross-compiling with gccMike Frysinger3-6/+49
The current gen_matypes logic assumes that the host compiler will produce information that is useful for the target compiler. Unfortunately, this is not the case whenever cross-compiling. When we detect that we're cross-compiling and using GCC, use the target compiler to produce assembly from the gen_matypes.c source, then process it with a shell script to create a usable header. This is similar to how the linux kernel creates its asm-offsets.c file. Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2013-07-18i965: Add MOCS shift and mask for SURFACE_STATE entries.Kenneth Graunke1-0/+3
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
2013-07-17mesa: Remove commas at end of enumerator lists.Vinson Lee1-4/+4
Fixes these build errors on OpenBSD 5.3. In file included from ../../src/mesa/main/errors.h:47, from ../../src/mesa/main/imports.h:41, from ../../src/mesa/main/ff_fragment_shader.cpp:32: ../../src/mesa/main/mtypes.h:3286: error: comma at end of enumerator list ../../src/mesa/main/mtypes.h:3296: error: comma at end of enumerator list ../../src/mesa/main/mtypes.h:3303: error: comma at end of enumerator list ../../src/mesa/main/mtypes.h:3356: error: comma at end of enumerator list Signed-off-by: Vinson Lee <vlee@freedesktop.org>
2013-07-16osmesa: link against static libglapi library too to get the gl exportsMaarten Lankhorst1-3/+3
This should fix missing symbols in a osmesa built against shared glapi osmesa build. All opengl exports were missing that are defined in the static glapi, so link against both to fix this. This is a candidate for the stable series. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47824 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
2013-07-16i965/Gen4: Zero extra coordinates for ir_texChris Forbes1-0/+4
We always emit U,V,R coordinates for this message, but the sampler gets very angry if we pass garbage in the R coordinate for at least some texture formats. Fill the remaining coordinates with zero instead. Fixes broken rendering on GM45 in Source games, and in VDrift. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65236 NOTE: This is a candidate for stable branches. Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-07-15i965: Cite the Ivybridge PRM for 3DSTATE_CLEAR_PARAMS notes.Kenneth Graunke1-2/+2
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
2013-07-15i965: Refer people to brw_tex_layout.c rather than the BSpec.Kenneth Graunke1-2/+2
brw_tex_layout.c sets up the align_w/h fields, and has all the appropriate spec references already. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
2013-07-15i965: Remove old BSpec reference from BLORP's 3DSTATE_WM/PS packets.Kenneth Graunke2-5/+5
The Sandybridge code had a citation for the range of the "Maximum Number of Threads" field, and the Ivybridge code just mentioned the "BSpec" in general. That's documented in the obvious place, so people can find it without a spec reference. The real value of the comment is to say "we tried zero, and it exploded, so program it to a valid number even if pixel shading is off." Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
2013-07-15i965: Cite the Ivybridge PRM for 3DSTATE_URB_* programming.Kenneth Graunke1-2/+3
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
2013-07-15i965: Update workaround flush comments for Gen6 3DSTATE_VS.Kenneth Graunke2-2/+6
Unfortunately, the workaround text never made it into the Sandybridge PRM, so we still have to refer to the BSpec. It also wasn't obvious why we needed this workaround at all, since we don't currently do VS passthrough - but BLORP can turn off the VS. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
2013-07-15i965: Cite the Ivybridge PRM for VS PIPE_CONTROL workarounds.Kenneth Graunke1-2/+2
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
2013-07-15i965: Cite the Sandybridge PRM for Gen7 stencil pitch requirements.Kenneth Graunke1-9/+5
Sadly, the Ivybridge PRM can't be cited, as it is missing the relevant text for some reason. However, the Sandybridge PRM has the text Chad originally quoted, and the modern BSpec has the same text. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
2013-07-15i965: Cite the Ivybridge PRM for multisample surface format notes.Kenneth Graunke1-13/+9
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
2013-07-15i965: Delete "the data cache is the sampler cache" comments on Gen7+.Kenneth Graunke1-12/+0
I cut and pasted these comments from the Gen4 code during Ivybridge enabling, and didn't understand what they meant at the time. The data cache is NOT the same as the sampler cache on Ivybridge. The sampler cache has L1 and L2 caches in addition to the L3 cache, while data port messages to the "data cache" hit L3 directly. This means that the sampler domain is technically wrong, but we stopped caring about read/write domains quite a while ago. The kernel just flushes all the caches at the end of each batchbuffer, and our render to texture code flushes the sampler caches when necessary. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-22 00:36:50 +0000