aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* docs: add release notes for 10.6.9mesa-10.6.9Emil Velikov2015-10-031-0/+129
| | | | Signed-off-by: Emil Velikov <[email protected]>
* Update version to 10.6.9Emil Velikov2015-10-031-1/+1
| | | | Signed-off-by: Emil Velikov <[email protected]>
* glx: Don't hard-code the name "libGL.so.1" in driOpenDriver (v3)Kyle Brenneman2015-10-032-1/+6
| | | | | | | | | | | | | | | | | Add a macro GL_LIB_NAME to hold the filename that configure comes up with based on the --with-gl-lib-name and --enable-mangling options. In driOpenDriver, use the GL_LIB_NAME macro instead of hard-coding "libGL.so.1". v2: Add an #ifndef/#define for GL_LIB_NAME so that non-autoconf builds will work. v3: Fix the library filename in the Makefile. Signed-off-by: Kyle Brenneman <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit d35391cfda13afdb19a47003af260e258575ef45)
* mapi: Make _glapi_get_stub work with "gl" or "mgl" prefix.Kyle Brenneman2015-10-031-1/+1
| | | | | | | | | | | | | | | | When USE_MGL_NAMESPACE is defined, _glapi_get_stub will check for the "m" prefix before trying to skip it, so that "glFoo" and "mglFoo" are equivalent. This should let it work with all the places where something calls _glapi_get_proc_offset with a hard-coded name that starts with the normal "gl" prefix. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55552 Signed-off-by: Kyle Brenneman <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit 798f260a2f553e339d7f5fc5120bb627893dc740)
* glx: Fix build errors with --enable-mangling (v2)Kyle Brenneman2015-10-032-2/+12
| | | | | | | | | | | | | | | | Rearranged the GLX_ALIAS macro in glextensions.h so that it will pick up the renames from glx_mangle.h. Fixed the alias attribute for glXGetProcAddress when USE_MGL_NAMESPACE is defined. v2: Add a comment clarifying why GLX_ALIAS needs two macros. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55552 Signed-off-by: Kyle Brenneman <[email protected]> Cc: "10.6 11.0" <[email protected]> Reviewed-by: Emil Velikov <[email protected]> (cherry picked from commit a27f2d991b1723c3349623401ce3c8f26dcdb28b)
* i965: Remove early release of DRI2 miptreeChris Wilson2015-09-301-1/+0
| | | | | | | | | | | | | | | | | intel_update_winsys_renderbuffer_miptree() will release the existing miptree when wrapping a new DRI2 buffer, so we can remove the early release and so prevent a NULL mt dereference should importing the new DRI2 name fail for any reason. (Reusing the old DRI2 name will result in the rendering going astray, to a stale buffer, and not shown on the screen, but it allows us to issue a warning and not crash much later in innocent code.) Signed-off-by: Chris Wilson <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86281 Reviewed-by: Martin Peres <[email protected]> Reviewed-by: Chad Versace <[email protected]> (cherry picked from commit 70e91d61fde239e8ae58148cacd4ff891126e2aa) Nominated-by: Emil Velikov <[email protected]>
* st/mesa: try PIPE_BIND_RENDER_TARGET when choosing float texture formatsBrian Paul2015-09-301-1/+5
| | | | | | | | | | | | | | For 8-bit RGB(A) texture formats we set the PIPE_BIND_RENDER_TARGET flag to try to get a hardware format which also supports rendering (for FBO textures). Do the same thing for floating point formats. This allows the Redway3D Flat demo to run. Cc: 10.6 11.0 <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> (cherry picked from commit cb758b892a7e62ff1f6187f2ca9ac543ff70a096)
* radeon/vce: fix vui time_scale zero errorLeo Liu2015-09-301-0/+3
| | | | | | | | | | if app pass 0 as frame_rate_num, it should not be encoded to the VUI. Signed-off-by: Leo Liu <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Christian König <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit 1e97b41893a4f53a71ee141a5e8a046fed7b49cd)
* mesa: fix mipmap generation for immutable, compressed texturesRoland Scheidegger2015-09-301-21/+15
| | | | | | | | | | | | | | | | | | | | | | If the immutable compressed texture didn't have the full mip pyramid, this didn't work, because it tried to generate mip levels for non-existing levels. _mesa_prepare_mipmap_level() would correctly handle this by returning FALSE if the mip level didn't exist, however we actually created the non-existing mip level right before that because we used _mesa_get_tex_image() before calling _mesa_prepare_mipmap_level(). It would then proceed to crash (we allocated the mip level, which is a bad idea on an immutable texture, but didn't initialize the values, leading to assertion failures or segfaults). Fix this by using _mesa_select_tex_image() instead and call it after _mesa_prepare_mipmap_level(), as that function will allocate missing mip levels for non-immutable textures already. This fixes a (2 year old) crash with astromenace which was hack-fixed in ubuntu packages instead: http://bugs.debian.org/718680 (I guess most apps do full mip chains - I believe this app not doing it is actually unintentional, always one level less than full mip chain...). Cc: "10.6 11.0" <[email protected]> Reviewed-by: Brian Paul <[email protected]> (cherry picked from commit 19604d30e1351868f7f54847c91ffec7b3fcd27e)
* st/mesa: fix front buffer regression after dropping st_validate_state in BlitMarek Olšák2015-09-301-0/+2
| | | | | | | | | Broken by: d082c5324914212f76e45be497229c7a0681f706 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92072 Cc: 10.6 11.0 <[email protected]> Tested-by: Ilia Mirkin <[email protected]> (cherry picked from commit f3a081953393c7d40bd8df9ec22a2551d01098f5)
* i965: Respect stride and subreg_offset for ATTR registersKristian Høgsberg Kristensen2015-09-301-1/+4
| | | | | | | | | | | | | When we assign hw regs to attributes, we don't incorporate the stride and subreg_offset from the fs_reg. It's rarely used, but the integer multiplication lowering uses unusual stride and subreg_offset combination breaks when one source is an attribute. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91970 Cc: "10.6 11.0" <[email protected]> Signed-off-by: Kristian Høgsberg Kristensen <[email protected]> Reviewed-by: Matt Turner <[email protected]> (cherry picked from commit 2ea16966ae66d4dd5c5dcb996d7996d9c734bbee)
* t_dd_dmatmp: Use addition instead of subtraction in loop boundsIan Romanick2015-09-301-1/+1
| | | | | | | | | | | | | | This is used everywhere else in this file because it avoids problems when count is zero (due to trimming). No piglit regressions on i915 (G33) or radeon (Radeon 7500). Signed-off-by: Ian Romanick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38109 Reviewed-by: Brian Paul <[email protected]> Cc: Marius Predut <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit 25543d8ec506ef32599af6f5e0dd735e01b39909)
* t_dd_dmatmp: Pull out common 'count -= count & 3' codeIan Romanick2015-09-301-9/+6
| | | | | | | | | | | | | | This was missing in the HAVE_TRIANGLES path, and that could cause incorrect rendering. No piglit regressions on i915 (G33) or radeon (Radeon 7500). Signed-off-by: Ian Romanick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38109 Reviewed-by: Brian Paul <[email protected]> Cc: Marius Predut <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit c0b3b2f7603eab210acdb2e654e5411fe912ca34)
* t_dd_dmatmp: Use '& 3' instead of '% 4' everywhereIan Romanick2015-09-301-2/+2
| | | | | | | | | No piglit regressions on i915 (G33) or radeon (Radeon 7500). Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit 0d475ee2b989ac1697720ca391913e9158156bdc)
* t_dd_dmatmp: Clean up improper code formatting from previous patchIan Romanick2015-09-301-12/+6
| | | | | | | | | No piglit regressions on i915 (G33) or radeon (Radeon 7500). Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit fad8d54de7e7f908cb0d06f0b54af8440e689928)
* t_dd_dmatmp: Make "count" actually be the countIan Romanick2015-09-303-75/+75
| | | | | | | | | | | | | | | | | | | | | | | The value passed in count previously was "vertex after the last vertex to be processed." Calling that "count" was misleading and kind of mean. Looking at the code, many functions immediately do "count-start" to get back the true count. That's just silly. If it is better for the loops to be 'for (j = start; j < (start + count); j++)', GCC will do that transformation. NOTE: There is some strange formatting left by this patch. That was done to make it more obvious that the before and after code is equivalent. These will be fixed in the next patch. No piglit regressions on i915 (G33) or radeon (Radeon 7500). v2: Fix a remaining (count-start) in render_quad_strip_verts. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> [v1] Cc: "10.6 11.0" <[email protected]> (cherry picked from commit d7bf7969b90f66ee614f2d2225f3a821d5396a89)
* mesa: Fix GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE for default framebuffer.Iago Toral Quiroga2015-09-301-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | From section 9.2. Binding and Managing Framebuffer Objects: "Upon successful return from Get*FramebufferAttachmentParameteriv, if pname is FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, then params will contain one of NONE, FRAMEBUFFER_DEFAULT, TEXTURE, or RENDERBUFFER, identifying the type of object which contains the attached image." And then it clarifies further: "If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is NONE, then either no framebuffer is bound to target; or the default framebuffer is bound, attachment is DEPTH or STENCIL, and the number of depth or stencil bits, respectively, is zero" Currently, if the default framebuffer is bound, we always return GL_FRAMEBUFFER_DEFAULT for FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, but according to the spec, when GL_DEPTH or GL_STENCIL attachments are the ones being queried, we should return GL_NONE if they don't exist. Fixes the following dEQP test: dEQP-GLES3.functional.state_query.fbo.framebuffer_attachment_x_size_initial Reviewed-by: Ian Romanick <[email protected]> Cc: "10.6" <[email protected]> (cherry picked from commit cf439951b791827677e96d29e209b5fc08d07a2e)
* cherry-ignore: add commit non applicable for 10.6Emil Velikov2015-09-301-0/+3
| | | | | | | The nominated commit 7f8815bcb9af9b4b374ad7bd6e7cfa7529a6c980 (i965: fix textureGrad for cubemaps) addresses issue, raised post 10.6 branchpoint. Signed-off-by: Emil Velikov <[email protected]>
* configure.ac: Add support to enable read-only text segment on x86.Jeremy Huddleston2015-09-301-0/+10
| | | | | | | Cc: "10.6 11.0" <[email protected]> Bugzilla: https://bugs.gentoo.org/240956 Reviewed-by: Ian Romanick <[email protected]> (cherry picked from commit 6dfc5e28f7d08094210d8cecd3ed4a5b393dafe9)
* cherry-ignore: add commit non applicable for 10.6Emil Velikov2015-09-301-0/+3
| | | | | | | | The nominated commit afa1efdc8522d987e3af7c7a6272021caa33eb82 (mesa: fix errors when reading depth with glReadPixels) addresses issue, raised post 10.6 branchpoint. Signed-off-by: Emil Velikov <[email protected]>
* docs: add sha256 checksums for 10.6.8Emil Velikov2015-09-201-1/+2
| | | | Signed-off-by: Emil Velikov <[email protected]>
* docs: add release notes for 10.6.8mesa-10.6.8Emil Velikov2015-09-201-0/+135
| | | | Signed-off-by: Emil Velikov <[email protected]>
* Update version to 10.6.8Emil Velikov2015-09-201-1/+1
| | | | Signed-off-by: Emil Velikov <[email protected]>
* i965/vec4: fill src_reg type using the constructor type parameterAlejandro Piñeiro2015-09-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | The src_reg constructor that received the glsl_type was using it only to build the swizzle, but not to fill this->type as dst_reg is doing. This caused some type mismatch between movs and alu operations on the NIR path, so copy propagation optimization was not applied to remove unneeded movs if negate modifier was involved. This was first detected on minus (negate+add) operations. Shader DB results (taking into account only vec4): total instructions in shared programs: 20019 -> 19934 (-0.42%) instructions in affected programs: 2918 -> 2833 (-2.91%) helped: 79 HURT: 0 GAINED: 0 LOST: 0 Reviewed-by: Matt Turner <[email protected]> (cherry picked from commit 4de86e1371b0d59a5b9a787b726be3d373024647) Nominated-by: Christoph Brill <[email protected]>
* mesa: Fix texture compression on big-endian systemsUlrich Weigand2015-09-174-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | Various pieces of code to create compressed textures will first generate an uncompressed RGBA texture into a temporary buffer, and then read from that buffer while creating the final compressed texture in the requested format. The code reading from the temporary buffer assumes the buffer is formatted as an array of bytes in RGBA order. However, the buffer is filled using a _mesa_texstore call with MESA_FORMAT_R8G8B8A8_UNORM format -- this is defined as an array of *integers* holding the RGBA values in packed format (least-significant to most-significant). This means incorrect bytes are accessed on big-endian systems. This patch fixes this by using the MESA_FORMAT_A8B8G8R8_UNORM format instead on big-endian systems when filling the buffer. This fixes about 100 piglit test case failures on s390x for me. Signed-off-by: Ulrich Weigand <[email protected]> Tested-by: Oded Gabbay <[email protected]> Cc: "10.6" "11.0" <[email protected]> Signed-off-by: Dave Airlie <[email protected]> (cherry picked from commit bd016a2601a741799bc76734deae0cb9ebcb2b8f)
* nv50, nvc0: fix max texture buffer size to 128M elementsIlia Mirkin2015-09-172-2/+2
| | | | | | | | | This is what the hardware supports, there never was any sort of 64K limit. Signed-off-by: Ilia Mirkin <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit 7a275fcda8ffa3d69b7be6f356469f4af272a6ad)
* st/mesa: avoid integer overflows with buffers >= 512MBIlia Mirkin2015-09-171-2/+2
| | | | | | | | | | This fixes failures with the newly-submitted max-size texture buffer piglit test for GPUs exposing >= 128M max texels. Signed-off-by: Ilia Mirkin <[email protected]> Cc: "10.6 11.0" <[email protected]> Reviewed-by: Glenn Kennard <[email protected]> (cherry picked from commit eb081681df248750727a8a76436760d617b4a6a9)
* gbm: convert gbm bo format to fourcc format on dma-buf importRay Strode2015-09-171-1/+17
| | | | | | | | | | | | | | | | | | | | | | At the moment if a gbm buffer is imported and the gbm buffer has an old-style GBM_BO_FORMAT format, the import will crash, since it's passed directly to DRI functions that expect a fourcc format (as provided by the newer GBM_FORMAT definitions) This commit addresses the problem in two ways: 1) it prevents invalid formats from leading to a crash by returning EINVAL if the image couldn't be created 2) it translates GBM_BO_FORMAT formats into the comparable GBM_FORMAT formats. Reference: https://bugzilla.gnome.org/show_bug.cgi?id=753531 CC: "10.6 11.0" <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> (cherry picked from commit 4bf151e66279da00655cec02aadb52c9c6583213)
* i965/vec4: Fix saturation errors when coalescing registersAntia Puentes2015-09-171-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the register types do not match and the instruction that contains the final destination is saturated, register coalescing generated non-equivalent code. This did not happen when using IR because types usually matched, but it is visible in nir-vec4. For example, mov vgrf7:D vgrf2:D mov.sat m4:F vgrf7:F is coalesced to: mov.sat m4:D vgrf2:D The patch prevents coalescing in such scenario, unless the instruction we want to coalesce into is a MOV (without type conversion implied). In that case, the patch sets the register types to the type of the final destination. Shader-db results in HSW (only vec4 instructions shown): total instructions in shared programs: 1754415 -> 1754416 (0.00%) instructions in affected programs: 74 -> 75 (1.35%) helped: 0 HURT: 1 GAINED: 0 LOST: 0 Only one extra instruction in one of the shaders, that comes from eliminating a saturation error by preventing register coalesce. Cc: "10.6 11.0" <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> (cherry picked from commit 79f1a7ae28c37f77e08e550cd077959a2a1f8341)
* i965/vec4: Don't reswizzle hardware registersJason Ekstrand2015-09-171-0/+8
| | | | | | | Cc: "11.0 10.6" <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91719 Reviewed-by: Kenneth Graunke <[email protected]> (cherry picked from commit 1037e0a84f61f4b1815093bcfd548d4b58ca106f)
* nvc0: remove BGRA4 format supportIlia Mirkin2015-09-171-0/+2
| | | | | | | | | | | | Something is wrong with the support somewhere. I couldn't get the blob driver to use it either, although it happily used RGB5_A1. teximage-colors works, but WoW seems to fail in the menus for drawing text. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91526 Signed-off-by: Ilia Mirkin <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit 342e68dc60eebb20ac1be9f47800ee9e604354f0)
* nv30: Disable msaa unless requested from the env by NV30_MAX_MSAAHans de Goede2015-09-172-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | Some modern apps try to use msaa without keeping in mind the restrictions on videomem of older cards. Resulting in dmesg saying: [ 1197.850642] nouveau E[soffice.bin[3785]] fail ttm_validate [ 1197.850648] nouveau E[soffice.bin[3785]] validating bo list [ 1197.850654] nouveau E[soffice.bin[3785]] validate: -12 Because we are running out of video memory, after which the program using the msaa visual freezes, and eventually the entire system freezes. To work around this we do not allow msaa visauls by default and allow the user to override this via NV30_MAX_MSAA. Signed-off-by: Hans de Goede <[email protected]> [imirkin: move env var lookup to screen so that it's only done once] Signed-off-by: Ilia Mirkin <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit 3e9df0e3af7a8a84147ae48f588e9c435bf65b98) Signed-off-by: Emil Velikov <[email protected]> Conflicts: src/gallium/drivers/nouveau/nv30/nv30_screen.c
* nvc0: always emit a full shader colormaskIlia Mirkin2015-09-171-1/+1
| | | | | | | | | | | | | | | Indications are that if the colormask indicates a single bit set on fermi, that value will always be read from $r0 instead of a potentially higher register (if e.g. green is set). Not to upset the counting logic, always set the header up with a full color mask for each RT. Such a situation can basically only ever happen with generated blit shaders. Fixes the following piglit on Fermi (Kepler is unaffected): fbo-stencil blit GL_DEPTH32F_STENCIL8 Signed-off-by: Ilia Mirkin <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit 39df725f731f75f488c75a4910169beb352213fb)
* nv30: Fix max width / height checks in nv30 sifm codeHans de Goede2015-09-171-2/+2
| | | | | | | | | | | | | | | | | | The sifm object has a limit of 1024x1024 for its input size and 2048x2048 for its output. The code checking this was trying to be clever resulting in it seeing a surface of e.g 1024x256 being outside of the input size limit. This commit fixes this. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit 87073c69f3e253044bc235f34917aaa89041a63c) Signed-off-by: Emil Velikov <[email protected]> Conflicts: src/gallium/drivers/nouveau/nv30/nv30_transfer.c
* st/mesa: don't fall back to 16F when 32F is requestedIlia Mirkin2015-09-171-14/+8
| | | | | | | | | | | | Nothing in the spec allows for the reduced precision, and this also fixes st_QuerySamplesForFormat for nv50, which does not allow MS8 on RGBA32F. Now this will be respected instead of reporting MS8 as supported with an assumption that the format used will be RGBA16F. Signed-off-by: Ilia Mirkin <[email protected]> Cc: "10.6 11.0" <[email protected]> Reviewed-by: Marek Olšák <[email protected]> (cherry picked from commit e40f32d5626c87d9e77bbc261df3648cd54bd066)
* llvmpipe: convert double to long long instead of unsigned long longOded Gabbay2015-09-171-1/+1
| | | | | | | | | | | | | | | | | | round(val*dscale) produces a double result, as val and dscale are double. However, LLVMConstInt receives unsigned long long, so there is an implicit conversion from double to unsigned long long. This is an undefined behavior. Therefore, we need to first explicitly convert the round result to long long, and then let the compiler handle conversion from that to unsigned long long. This bug manifests itself in POWER, where all IMM values of -1 are being converted to 0 implicitly, causing a wrong LLVM IR output. Signed-off-by: Oded Gabbay <[email protected]> CC: "10.6 11.0" <[email protected]> Reviewed-by: Tom Stellard <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> (cherry picked from commit 4f2290d1612569686284609059d29a85c9de67cf)
* nv30: Implement color resolve for msaaHans de Goede2015-09-172-14/+8
| | | | | | | | | | | | Note this is not ideal. Since the sifm can only do source sizes upto 1024x1024 we end up using the blitter on nv4x, which is not that fast. And on nv3x we end up using the cpu which is really slow. Cc: "10.6 11.0" <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> (cherry picked from commit 3c6c4d4f298ec81fe57992790a68aaab2e573519)
* nv30: Fix creation of scanout buffersHans de Goede2015-09-171-0/+10
| | | | | | | | | | | | | | | | | | | | | | Scanout buffers on nv30 must always be non-swizzled and have special width alignment constraints. These constrains have been taken from the xf86-video-nouveau src/nv_accel_common.c: nouveau_allocate_surface() function. nouveau_allocate_surface() applies these width constraints only when a tiled attribute is set, which it sets for all surfaces allocated via dri, and this "tiling" is not the same as swizzling, scanout surfaces must be linear / have a uniform_pitch or only complete garbage is shown. This commit fixes dri3 on nv30 showing a garbled display, with dri3 the scanout buffers are allocated by mesa, rather then by the ddx, and the wrong stride of these buffers was causing the garbled display. Cc: "10.6 11.0" <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> (cherry picked from commit 3329703eb116a7ad73bc694356b43e014532240b)
* mesa: Don't allow wrong type setters for matrix uniformsIan Romanick2015-09-171-0/+25
| | | | | | | | | | | | | | Previously we would allow glUniformMatrix4fv on a dmat4 and glUniformMatrix4dv on a mat4. Both are illegal. That later also overwrites the storage for the mat4 and causes bad things to happen. Should fix the (new) arb_gpu_shader_fp64-wrong-type-setter piglit test. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Timothy Arceri <[email protected]> Cc: Dave Airlie <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit 7237c937af3b495191bee2f7240901e3a9daf1fb)
* mesa: Pass the type to _mesa_uniform_matrix as a glsl_base_typeIan Romanick2015-09-173-42/+42
| | | | | | | | | | | | | This matches _mesa_uniform, and it enables the bug fix in the next patch. v2: s/type/basicType/ in the assert in _mesa_uniform_matrix. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Timothy Arceri <[email protected]> [v1] Cc: Dave Airlie <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit a6976f09727014730f45ec27c714c6a8140e074a)
* cherry-ignore: add commit non applicable for 10.6Emil Velikov2015-09-171-0/+2
| | | | Signed-off-by: Emil Velikov <[email protected]>
* gallivm: Workaround LLVM PR23628.Jose Fonseca2015-09-171-0/+11
| | | | | | | | | | | | | Temporarily undefine DEBUG macro while including LLVM C++ headers, leveraging the push/pop_macro pragmas, which are supported both by GCC and MSVC. https://bugs.freedesktop.org/show_bug.cgi?id=90621 Trivial. (cherry picked from commit 09d6243aed016eed4518435c9885275dbb6d2aa9) Nominated-by: Sedat Dilek <[email protected]>
* gallivm: Do not use NoFramePointerElim with LLVM 3.7.Vinson Lee2015-09-172-0/+4
| | | | | | | | | | | TargetOptions::NoFramePointerElim was removed in llvm-3.7.0svn r238244 "Remove NoFramePointerElim and NoFramePointerElimOverride from TargetOptions and remove ExecutionEngine's dependence on CodeGen. NFC." Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Tom Stellard <[email protected]> (cherry picked from commit 147ffd48166d851341cadd12de98895f32ec25a2) Nominated-by: Sedat Dilek <[email protected]>
* i965: Momentarily pretend to support ARB_texture_stencil8 for blits.Kenneth Graunke2015-09-171-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Broadwell's stencil blitting code attempts to bind a renderbuffer as a texture, using dd->BindRenderbufferTexImage(). This calls _mesa_init_teximage_fields(), which then attempts to set img->_BaseFormat = _mesa_base_tex_format(ctx, internalFormat), which assert fails if internalFormat is GL_STENCIL_INDEX8 but ARB_texture_stencil8 is unsupported. To work around this, just pretend to support the extension momentarily, during the blit. Meta has already munged a variety of other things in the context (including the API!), so it's not that much worse than what we're already doing. Fixes regressions since commit f7aad9da20b13c98f77d6a690b327716f39c0a47 (mesa/teximage: use correct extension for accept stencil texture.). v2: Add an XXX comment explaining the situation (requested by Jason Ekstrand and Martin Peres), and an assert that we don't support the extension so we remember to remove this hack (requested by Neil Roberts). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> (cherry picked from commit f83b9e58f6e8a748def367c7d523eb7285b1aeb7) Nominated-by: Emil Velikov <[email protected]>
* docs: add sha256 checksums for 10.6.7Emil Velikov2015-09-101-1/+2
| | | | Signed-off-by: Emil Velikov <[email protected]>
* docs: add release notes for 10.6.7mesa-10.6.7Emil Velikov2015-09-101-0/+74
| | | | Signed-off-by: Emil Velikov <[email protected]>
* Update version to 10.6.7Emil Velikov2015-09-101-1/+1
| | | | Signed-off-by: Emil Velikov <[email protected]>
* glsl: Handle attribute aliasing in attribute storage limit check.Kenneth Graunke2015-09-101-28/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | In various versions of OpenGL and GLSL, it's possible to declare multiple VS input variables with aliasing attribute locations. So, when computing the storage requirements for vertex attributes, we can't simply add up the sizes. Instead, we need to look at the enabled slots. This patch begins tracking which attributes are double types that are larger than 128-bits (i.e. take up two vec4 slots). We then count normal attributes once, and count the double-size attributes a second time. Fixes deQP functional.attribute_location.bind_aliasing.max_cond_* tests on i965, which regressed with commit ad208d975a6d3aebe14f7c2c16039ee20. No Piglit changes on llvmpipe (which actually supports dvecs). Cc: "10.6 11.0" <[email protected]> Tested-by: Mark Janes <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Dave Airlie <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> (cherry picked from commit c3294ca5a13cf3f0eb3d9907a46ff8ce4bc2963b)
* mesa/teximage: use correct extension for accept stencil texture.Dave Airlie2015-09-101-1/+1
| | | | | | | | | | | | | | | This was using the wrong extension, ARB_stencil_texturing doesn't mention any changes in this area. Fixes "dEQP-GLES3.functional.fbo.completeness.renderable.texture. stencil.stencil_index8." Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90751 Signed-off-by: Dave Airlie <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> (cherry picked from commit f7aad9da20b13c98f77d6a690b327716f39c0a47) Nominated-by: Mark Janes <[email protected]>
* Revert "i965: Momentarily pretend to support ARB_texture_stencil8 for blits."Emil Velikov2015-09-101-7/+0
| | | | | | This reverts commit 6811df8d3510c35899e992bae82c063e20e62cc8. Erroneous nomination. See mailing list for details.
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-29 01:49:20 +0000