summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* gles3: Update gl3.h to 2013-02-12.Matt Turner2013-07-291-4/+4
| | | | Reviewed-by: Jordan Justen <[email protected]>
* gles2: Update gl2ext.h to revision 22161.Matt Turner2013-07-291-114/+357
| | | | Reviewed-by: Jordan Justen <[email protected]>
* gles2: Update gl2.h to revision 20555.Matt Turner2013-07-291-3/+3
| | | | Reviewed-by: Jordan Justen <[email protected]>
* gles: Update glext.h to revision 20798.Matt Turner2013-07-291-3/+3
| | | | Reviewed-by: Jordan Justen <[email protected]>
* gallivm: (trivial) git rid of assertion in float->uint conversion codeRoland Scheidegger2013-07-291-2/+3
| | | | | | | Commit 8c3d3622d9ce2fd2a8f46084ab8153d708fa5b09 introduced a new assertion, but since it causes lp_test_conv failures remove it again and let's hope we don't really hit bugs caused by the potentially bogus code (it is possible the assert() caught some cases which work correctly too).
* nvc0: force use of correct firmware fileMaarten Lankhorst2013-07-281-1/+1
| | | | Signed-off-by: Maarten Lankhorst <[email protected]>
* glsl: Less const for glsl_type convenience accessorsIan Romanick2013-07-272-8/+8
| | | | | | | | | | | | | The second 'const' says that the pointer itself is constant. This in unenforcible in C++, so GCC emits a warning (see) below for each of these functions in every file that includes glsl_types.h. It's a lot of warning spam. ../../../src/glsl/glsl_types.h:176:58: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Cc: [email protected]
* glsl: Disallow auxiliary storage qualifiers on FS outputs.Kenneth Graunke2013-07-271-0/+14
| | | | | | | | | | | This has always been an error; we just forgot to check for it. Fixes Piglit's no-aux-qual-on-fs-output.frag. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67333 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Cc: [email protected]
* glsl: Classify "layout" like other identifiers.Kenneth Graunke2013-07-271-1/+1
| | | | | | | | | | | | | When "layout" isn't being lexed as LAYOUT_TOK, we should treat it like an ordinary identifier. This means we need to classify it to determine whether we should return IDENTIFIER, TYPE_IDENTIFIER, or NEW_IDENTIFIER. Fixes the WebGL conformance test "shader-with-non-reserved-words." Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64087 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Cc: [email protected]
* glsl: Be consistent about '\n', '.', and capitalization in errors/warnings.Paul Berry2013-07-278-122/+122
| | | | | | | | | | | | The majority of calls to _mesa_glsl_error(), _mesa_glsl_warning(), and _mesa_glsl_parse_state::check_version() use a message that begins with a lower case letter and ends without a period. This patch makes all messages follow that convention. Also, error/warning messages shouldn't end in '\n', since _mesa_glsl_msg() automatically adds '\n' at the end of the message. Reviewed-by: Matt Turner <[email protected]>
* gallivm: fix float->SNORM conversionRoland Scheidegger2013-07-272-11/+47
| | | | | | | | | | Just like the UNORM case we need to use round to nearest, not trunc. (There's also another problem, we're using the formula for SNORM->float which will produce a value below -1.0 for the most negative value which according to both OpenGL and d3d10 would need clamping. However, no actual failures have been observed due to that hence keep cheating on that.) Reviewed-by: Jose Fonseca <[email protected]>
* util: don't flush overflowing values to infinity in half-float conversionRoland Scheidegger2013-07-272-9/+17
| | | | | | | | | | | | | | | | | | I am not able to find _any_ rounding behavior specified for OpenGL for float to half-float conversions. However, it is specified for fp11/fp10 which suggests round to next finite value but round-to-zero would also be allowed, but finite values must not be flushed to infinity in either case. Hence I believe it makes sense to do the same for half-floats too. We could probably also use round-to-zero consistently, which is in fact required by d3d10 (but it doesn't seem to matter much). Does not match the mesa core function doing the same though (which is saying it was built to match intel gpus which I don't believe for a second as it would cause failures in d3d10, moreover the PRM (for ivy bridge, not listed in older manuals) while not specifying rounding behavior clearly states finite numbers are never flushed to infinity). Reviewed-by: Jose Fonseca <[email protected]>
* tgsi: handle texel swizzles correctly for d3d10-style sample opcodesRoland Scheidegger2013-07-271-5/+35
| | | | | | | Same as for gallivm (though these don't quite work correctly in softpipe, so untested). Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: handle texel swizzles correctly for d3d10-style sample opcodesRoland Scheidegger2013-07-272-0/+29
| | | | | | | | | | | unlike OpenGL, the texel swizzle is embedded in the instruction, so honor that. (Technically we now execute both the sampler_view swizzle and the per-instruction swizzle but this should be quite ok.) v2: add documentation note as it's not obvious. Reviewed-by: Jose Fonseca <[email protected]>
* docs: Mark ARB_vertex_attrib_binding as started.Kenneth Graunke2013-07-261-1/+1
| | | | Fredrik Höglund has a partial implementation in his git tree.
* mesa: Disable GL_EXT_framebuffer_object in core profiles and OpenGL 3.1Ian Romanick2013-07-261-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 <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* docs: Mark GL_ARB_shading_language_420pack as done.Matt Turner2013-07-261-0/+1
|
* docs: Mark off 420packChris Forbes2013-07-271-1/+1
| | | | Signed-off-by: Chris Forbes <[email protected]>
* glsl: disable ARB_texture_cube_map_array_enable keywords for glsl esTapani Pälli2013-07-261-24/+5
| | | | | | | | | | | | Patch fixes a crash with Webgl 'shader-with-non-reserved-words' conformance test by ignoring desktop extension keywords on GLSL ES. v2: fix reserved and allowed desktop glsl versions (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64087 Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vs: Fix flaky texture swizzlingChris Forbes2013-07-271-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 <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* st/clover: Allow double precision operationsNiels Ole Salscheider2013-07-251-0/+1
| | | | | | | Pass "cl_khr_fp64" preprocessor definition to clang Signed-off-by: Niels Ole Salscheider <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* gallium/vl: add prime supportDave Airlie2013-07-261-1/+19
| | | | | | | | | | | | | | | | This fixes the dri2 opening to check if DRI_PRIME is set, and picks the correct drm device path to open, this along with a change to libvdpau allows vdpauinfo to work at least, Martin Peres tested with nouveau, and there seems to be a further issue with final displaying, it only works sometimes, but this patch is at least necessary to help debug further. Signed-off-by: Dave Airlie <[email protected]> Cc: [email protected] Reviewed-by: Christian König <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67283 Tested-by: Armin K. <[email protected]>
* Revert "i965: Delete pre-DRI2.3 viewport hacks."Kenneth Graunke2013-07-253-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: [email protected]
* mesa: Bump version to 9.3.0-devel.Kenneth Graunke2013-07-253-3/+3
| | | | This should have been done when making the 9.2 branch, but was missed.
* docs: Remove <em> obfuscation on public mailing list addresses.Kenneth Graunke2013-07-251-3/+3
| | | | | | | | | | | | | | Wrapping every character of an email address in <em> looks bizarre, and makes it impossible to read the text. Apparently Brian did this in 2003 to try and obfuscate email addresses and avoid spam. Of course, mesa-*@lists.freedesktop.org are public mailing lists and trivial to find on the internet. So obfuscation buys us nothing (assuming the <em> technique even works at all, which I doubt). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]> LOLed-at-by: Matt Turner :)
* xa: bump major versionRob Clark2013-07-251-1/+1
| | | | | | | Bump major version, as the change to require explicit xa_context_flush(), the addition of the handle-type parameter to xa_surface_handle(), and change of surface to ref/unref will require a minor change in DDX.
* xa: move surface to ref/unref apiJerome Glisse2013-07-253-2/+18
| | | | | | | This make ddx life easier. Signed-off-by: Jerome Glisse <[email protected]> Signed-off-by: Rob Clark <[email protected]>
* xa: let ddx handle flushJerome Glisse2013-07-252-9/+2
| | | | Signed-off-by: Jerome Glisse <[email protected]>
* xa: export a common context flush functionJerome Glisse2013-07-254-7/+17
| | | | | | First step before moving flushing inside the ddx. Signed-off-by: Jerome Glisse <[email protected]>
* xa: add handle type parameter to get handleJerome Glisse2013-07-252-2/+18
| | | | | | Allow to retrieve non shared handle. Signed-off-by: Jerome Glisse <[email protected]>
* xa: add xa_surface_from_handle()Rob Clark2013-07-252-4/+46
| | | | | | | | | | | For freedreno DDX, we have to create the scanout GEM bo in a special way (until we have our own KMS/DRM kernel driver.. and even then for phones/tablets you probably need to use the android drivers if you don't want to port the lcd panel driver support). The easiest way to handle this is let the DDX create the scanout bo, and then create the xa surface from that. Signed-off-by: Rob Clark <[email protected]>
* gallivm: Remove NoFramePointerElimNonLeaf for LLVM >= 3.4.Vinson Lee2013-07-251-0/+2
| | | | | | | | TargetOptions::NoFramePointerElimNonLeaf was removed in LLVM 3.4 r187093. Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* glsl: Handle empty if statement encountered during loop analysis.Paul Berry2013-07-251-1/+2
| | | | | | | | | | | | | | | | | | | | | The is_loop_terminator() function was asserting that the following kind of if statement could never occur: if (...) { } else { } (presumably based on the assumption that such an if statement would be eliminated by previous optimization stages). But that isn't the case--it's possible that previous optimization stages might simplify more complex code down to this empty if statement, in which case it won't be eliminated until the next time through the optimization loop. So is_loop_terminator() needs to handle it. Fortunately it's easy to handle--it's not a loop terminator because it does nothing. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64330 CC: [email protected] Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Initialize inout_offset parameter to brw_search_cache().Paul Berry2013-07-252-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 <[email protected]>
* glsl: don't rename variables in interface block arrays.Paul Berry2013-07-251-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | The linker matches up variables in interface blocks according to their block name and variable name. When support for interface block arrays was added in commit d6863acb, we renamed variables appearing in interface blocks so that their name included the array size. For example, in a block like this: out foo { float bar } baz[3]; The variable "bar" would get renamed to "bar[3]". This is unnecessary, and leads to problems in supporting geometry shaders, since geometry shaders require vertex shader outputs which are non-arrays to be linked up to geometry shader inputs which are arrays. This patch makes the behaviour of interface block arrays the same as simple non-array interface blocks; in both cases, the variables contained within them are not renamed. Reviewed-by: Matt Turner <[email protected]>
* draw: fix vertex id computationZack Rusin2013-07-255-13/+37
| | | | | | | | | | | | | vertex id has to be unaffected by the start index (i.e. when calling draw arrays with start_index = 5, the first vertex_id has to still be 0, not 5) and it has to be equal to the index when performing indexed rendering (in which case it has to be unaffected by the index bias). This fixes our behavior. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* draw: cleanup and fix instance id computationZack Rusin2013-07-254-13/+8
| | | | | | | | | | | | | | The instance id system value always starts at 0, even if the specified start instance is larger than 0. Instead of implicitly setting instance id to instance id plus start instance and then having to subtract instance id when computing the buffer offsets lets just set instance id to the proper instance id. This fixes instance id computation and cleansup buffer offset computation. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Remove dead code in lp_build_compare_ext.Vinson Lee2013-07-241-6/+0
| | | | | | | | | | There are earlier returns for PIPE_FUNC_NEVER and PIPE_FUNC_ALWAYS. The switch value of 'func' cannot be either of those values. Fixes "Logically dead code" defects reported by Coverity. Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* mesa: implement mipmap generation for compressed 2D array texturesBrian Paul2013-07-241-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: [email protected] Reviewed-by: José Fonseca <[email protected]>
* meta: handle 2D texture arrays in decompress_texture_image()Brian Paul2013-07-241-2/+21
| | | | | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66850 NOTE: This is a candidate for the 9.x branches. Cc: [email protected] Reviewed-by: José Fonseca <[email protected]>
* mesa: handle 2D texture arrays in get_tex_rgba_compressed()Brian Paul2013-07-241-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: [email protected] Reviewed-by: José Fonseca <[email protected]>
* nv50,nvc0: s/uint16/uint32 for constant buffer offsetChristoph Bumiller2013-07-242-2/+2
| | | | | | | | Looks like a thinko, "Hey, constant buffers can be at most 64 KiB in size, offset can't be larger." But it can, of course. I think piglit lacks a test for UBO and BindBufferRange that tests if it actually works.
* draw: always call util_cpu_detect() in draw context creation.Roland Scheidegger2013-07-241-1/+4
| | | | | | | | | | | | | | | | | | | | Since disabling denorms in draw_vbo() we require the util_cpu_caps to be initialized there. Hence add another util_cpu_detect() call in draw_create_context() which should ensure this. (There is another call in draw_get_option_use_llvm() which only gets called with x86 (not x86_64) but calling it always there wouldn't help since it most likely wouldn't get called when compiling without llvm, so leave it alone there.) This fixes https://bugs.freedesktop.org/show_bug.cgi?id=66806. (Because util_cpu_caps wasn't initialized when first calling util_fpstate_get() hence it returning zero, but it would later get initialized by rtasm translate code hence when draw call returned it unmasked all exceptions by calling util_fpstate_set(). This was happening only with DRAW_USE_LLVM=0 or not compiling with llvm, otherwise the llvm init code was calling it on time too.) Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Zack Rusin <[email protected]> Tested-by: Vinson Lee <[email protected]>
* mesa: fix rgtc snorm decodingRoland Scheidegger2013-07-241-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 <[email protected]> Reviewed-by: Zack Rusin <[email protected]>
* gallium/util: Fix detection of AVX cpu capsAndre Heider2013-07-231-2/+25
| | | | | | | | | | | | | | | | | For AVX it's not sufficient to only rely on the cpuid flags. If the CPU supports these extensions, but the OS doesn't, issuing these insns will trigger an undefined opcode exception. In addition to the AVX cpuid bit we also need to: * test cpuid for OSXSAVE support * XGETBV to check if the OS saves/restores AVX regs on context switches See "Detecting Availability and Support" at http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions Signed-off-by: Andre Heider <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* docs: Add items for GL4.4Chris Forbes2013-07-231-0/+14
| | | | | Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* clover: Respect kernel argument alignment restrictions.Francisco Jerez2013-07-222-2/+19
| | | | | Cc: [email protected] Reviewed-by: Tom Stellard <[email protected]>
* clover: Extend kernel arguments for differing host and device data types.Francisco Jerez2013-07-222-4/+56
| | | | | | | Loosely based on a similar patch by Tom Stellard. Cc: [email protected] Reviewed-by: Tom Stellard <[email protected]>
* clover: Byte-swap kernel arguments when host and device endianness differ.Francisco Jerez2013-07-221-37/+65
| | | | | Cc: [email protected] Reviewed-by: Tom Stellard <[email protected]>
* clover: Add kernel argument fields to allow differing host/target data types.Francisco Jerez2013-07-221-2/+23
| | | | | | | Loosely based on a similar patch by Tom Stellard. Cc: [email protected] Reviewed-by: Tom Stellard <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 13:26:26 +0000