- Oct 03, 2015
-
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
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 <kbrenneman@nvidia.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit d35391cf)
-
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 <kbrenneman@nvidia.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 798f260a)
-
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 <kbrenneman@nvidia.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (cherry picked from commit a27f2d99)
-
- Sep 30, 2015
-
-
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 <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86281 Reviewed-by: Martin Peres <martin.peres@linux.intel.com> Reviewed-by: Chad Versace <chad.versace@intel.com> (cherry picked from commit 70e91d61) Nominated-by: Emil Velikov <emil.velikov@collabora.com>
-
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 <mesa-stable@lists.freedesktop.org> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> (cherry picked from commit cb758b89)
-
if app pass 0 as frame_rate_num, it should not be encoded to the VUI. Signed-off-by: Leo Liu <leo.liu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 1e97b418)
-
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" <mesa-stable@lists.freedesktop.org> Reviewed-by: Brian Paul <brianp@vmware.com> (cherry picked from commit 19604d30)
-
Broken by: d082c532 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92072 Cc: 10.6 11.0 <mesa-stable@lists.freedesktop.org> Tested-by: Ilia Mirkin <imirkin@alum.mit.edu> (cherry picked from commit f3a08195)
-
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" <mesa-stable@lists.freedesktop.org> Signed-off-by: Kristian Høgsberg Kristensen <krh@bitplanet.net> Reviewed-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit 2ea16966)
-
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 <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38109 Reviewed-by: Brian Paul <brianp@vmware.com> Cc: Marius Predut <marius.predut@intel.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 25543d8e)
-
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 <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38109 Reviewed-by: Brian Paul <brianp@vmware.com> Cc: Marius Predut <marius.predut@intel.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit c0b3b2f7)
-
No piglit regressions on i915 (G33) or radeon (Radeon 7500). Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 0d475ee2)
-
No piglit regressions on i915 (G33) or radeon (Radeon 7500). Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit fad8d54d)
-
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 <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> [v1] Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit d7bf7969)
-
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 <ian.d.romanick@intel.com> Cc: "10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit cf439951)
-
Emil Velikov authored
The nominated commit 7f8815bc (i965: fix textureGrad for cubemaps) addresses issue, raised post 10.6 branchpoint. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.gentoo.org/240956 Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 6dfc5e28)
-
Emil Velikov authored
The nominated commit afa1efdc (mesa: fix errors when reading depth with glReadPixels) addresses issue, raised post 10.6 branchpoint. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
- Sep 20, 2015
-
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
- Sep 17, 2015
-
-
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 <mattst88@gmail.com> (cherry picked from commit 4de86e13) Nominated-by: Christoph Brill <egore911@egore911.de>
-
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 <ulrich.weigand@de.ibm.com> Tested-by: Oded Gabbay <oded.gabbay@gmail.com> Cc: "10.6" "11.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Dave Airlie <airlied@gmail.com> (cherry picked from commit bd016a26)
-
This is what the hardware supports, there never was any sort of 64K limit. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 7a275fcd)
-
This fixes failures with the newly-submitted max-size texture buffer piglit test for GPUs exposing >= 128M max texels. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Glenn Kennard <glenn.kennard@gmail.com> (cherry picked from commit eb081681)
-
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" <mesa-stable@lists.freedesktop.org> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net> (cherry picked from commit 4bf151e6)
-
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" <mesa-stable@lists.freedesktop.org> Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> (cherry picked from commit 79f1a7ae)
-
Cc: "11.0 10.6" <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91719 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 1037e0a8)
-
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 <imirkin@alum.mit.edu> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 342e68dc)
-
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 <hdegoede@redhat.com> [imirkin: move env var lookup to screen so that it's only done once] Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 3e9df0e3) Signed-off-by: Emil Velikov <emil.velikov@collabora.co.uk> Conflicts: src/gallium/drivers/nouveau/nv30/nv30_screen.c
-
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 <imirkin@alum.mit.edu> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 39df725f)
-
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 <hdegoede@redhat.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 87073c69) Signed-off-by: Emil Velikov <emil.velikov@collabora.co.uk> Conflicts: src/gallium/drivers/nouveau/nv30/nv30_transfer.c
-
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 <imirkin@alum.mit.edu> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit e40f32d5)
-
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 <oded.gabbay@gmail.com> CC: "10.6 11.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Tom Stellard <thomas.stellard@amd.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> (cherry picked from commit 4f2290d1)
-
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" <mesa-stable@lists.freedesktop.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> (cherry picked from commit 3c6c4d4f)
-
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" <mesa-stable@lists.freedesktop.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> (cherry picked from commit 3329703e)
-
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 <ian.d.romanick@intel.com> Reviewed-by: Timothy Arceri <t_arceri@yahoo.com.au> Cc: Dave Airlie <airlied@redhat.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 7237c937)
-
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 <ian.d.romanick@intel.com> Reviewed-by: Timothy Arceri <t_arceri@yahoo.com.au> [v1] Cc: Dave Airlie <airlied@redhat.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit a6976f09)
-