[Mesa-dev] [PATCH] ilo: Initialize read_back in transfer_map_sys.

Fixes "Uninitialized scalar variable" defect reported by Coverity. Signed-off-by: Vinson Lee --- src/gallium/drivers/ilo/ilo_resource.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/ilo/ilo_resource.c b/src/gallium/drivers/ilo/ilo_resource.c index c401d

Re: [Mesa-dev] [PATCH] mesa: Be less casual about texture formats in st_finalize_texture

That's not my commit. :) Anyway, I've sent a cleaner fix to mesa-dev. ("st/mesa: handle texture_from_pixmap and other surface-based textures correctly") Marek On Wed, May 8, 2013 at 3:18 AM, Dave Airlie wrote: > On Wed, May 8, 2013 at 11:14 AM, Marek Olšák wrote: >> Sorry, I'm not following. Wh

[Mesa-dev] [PATCH] st/mesa: handle texture_from_pixmap and other surface-based textures correctly

There were 2 issues with it: 1) The texture format which should be used for texturing was only set in gl_texture_image::TexFormat, which wasn't used for sampler views. 2) Textures are sometimes reallocated under some circumstances in st_finalize_texture, which is unacceptable if the texture c

[Mesa-dev] [PATCH 2/2] i965/hsw: Set MOCS for surfaces

The drivers was setting MOCS (Memory Object Control State) to 0 for all objects. This patch sets it as following: renderbuffer, depthbuffer => LLC uncacheable, L3 cacheable texture, stencil, hiz => LLC cacheable, L3 cacheable The goal here is to avoid blowing out the LLC with too-large buf

[Mesa-dev] [PATCH 1/2] i965/gen7: Add defines for Memory Object Control State

Tested-by: Matt Turner Signed-off-by: Chad Versace --- src/mesa/drivers/dri/i965/brw_defines.h | 20 1 file changed, 20 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_defines.h b/src/mesa/drivers/dri/i965/brw_defines.h index 6517f24..f574cb7 100644 --- a/src/mesa

Re: [Mesa-dev] [PATCH 2/2] r600g: cleanup MSAA texture support checking

On Thu, May 9, 2013 at 5:33 PM, Marek Olšák wrote: Reviewed-by: Alex Deucher > --- > src/gallium/drivers/r600/evergreen_state.c | 16 > src/gallium/drivers/r600/r600_asm.c|6 +++--- > src/gallium/drivers/r600/r600_asm.h|4 ++-- > src/gallium/drivers/r

Re: [Mesa-dev] [PATCH 1/2] r600g: rewrite FMASK allocation, fix FMASK texturing with 2 and 4 samples

On Thu, May 9, 2013 at 5:33 PM, Marek Olšák wrote: > This fixes and enables texturing with compressed MSAA colorbuffers > on Evergreen and Cayman. For the first time, multisample textures work > on Cayman. > > This requires the libdrm flag RADEON_SURF_FMASK. Maybe bump the libdrm requirement when

Re: [Mesa-dev] [PATCH] i965: Actually use the user timeout in glClientWaitSync.

Kenneth Graunke writes: > On 05/09/2013 02:16 PM, Eric Anholt wrote: >> Kenneth Graunke writes: >> >>> From: Ben Widawsky >>> >>> Use the new libdrm functionality to actually do timed waits on the sync >>> object. >> >> This was added at basically the same time as contexts, which we don't >> re

Re: [Mesa-dev] [PATCH] i965: Actually use the user timeout in glClientWaitSync.

On 05/09/2013 02:16 PM, Eric Anholt wrote: Kenneth Graunke writes: From: Ben Widawsky Use the new libdrm functionality to actually do timed waits on the sync object. This was added at basically the same time as contexts, which we don't rely on currently. It was in kernel 3.5, which is alm

[Mesa-dev] [PATCH 2/2] r600g: cleanup MSAA texture support checking

--- src/gallium/drivers/r600/evergreen_state.c | 16 src/gallium/drivers/r600/r600_asm.c|6 +++--- src/gallium/drivers/r600/r600_asm.h|4 ++-- src/gallium/drivers/r600/r600_blit.c | 22 ++ src/gallium/drivers/r600/r600_pipe.c

[Mesa-dev] [PATCH 1/2] r600g: rewrite FMASK allocation, fix FMASK texturing with 2 and 4 samples

This fixes and enables texturing with compressed MSAA colorbuffers on Evergreen and Cayman. For the first time, multisample textures work on Cayman. This requires the libdrm flag RADEON_SURF_FMASK. --- src/gallium/drivers/r600/evergreen_state.c | 17 +++- src/gallium/drivers/r600/evergr

Re: [Mesa-dev] [PATCH] i965: Actually use the user timeout in glClientWaitSync.

Kenneth Graunke writes: > From: Ben Widawsky > > Use the new libdrm functionality to actually do timed waits on the sync > object. This was added at basically the same time as contexts, which we don't rely on currently. It was in kernel 3.5, which is almost a year ago now, and will have been a

Re: [Mesa-dev] [PATCH] draw: don't crash on vertex buffer overflow

I somehow thought that GL_ARB_robustness that had something for this, but apparently it was just my imagination. Anyway, if we particularly cared for robustness of user pointers, we could query the OS for the virtual address range that contains a pointer. Windows/Mac have nice APIs for that. Li

Re: [Mesa-dev] [PATCH] draw: don't crash on vertex buffer overflow

Yes, we are not getting the user buffer sizes, because OpenGL lacks API to set them. The pointer is all you will ever have, just as it was received from a gl*Pointer call. Marek On Thu, May 9, 2013 at 8:29 PM, Zack Rusin wrote: > We would crash when stride was bigger than the size of the buffer.

[Mesa-dev] [PATCH] draw: don't crash on vertex buffer overflow

We would crash when stride was bigger than the size of the buffer. The correct behavior is to just fetch zero's in this case. Unfortunatly with user_buffer's there's no way to validate the size because currently we're just not getting it. Adjust the draw interface to pass the size along the mapped

Re: [Mesa-dev] [PATCH] intel: Fix render-to-texture in non-FinishRenderTexture cases.

On 05/07/2013 03:53 PM, Eric Anholt wrote: With EGL_KHR_gl_renderbuffer_iamge, we have the ability to render to renderbuffers that are also textures, so the core Mesa FinishRenderTexture hook doesn't get called. That hook also wasn't called in various cases within the driver where we'd update te

Re: [Mesa-dev] [PATCH 2/3] intel: Add multisample scaled blitting in blorp engine

On Tue, May 7, 2013 at 10:40 AM, Paul Berry wrote: > On 1 May 2013 14:10, Anuj Phogat wrote: >> >> In traditional multisampled framebuffer rendering, color samples must be >> explicitly >> resolved via BlitFramebuffer before doing the scaled blitting of the >> framebuffer. >> So, scaled blitting

[Mesa-dev] [Bug 64392] Missing WAYLAND_CFLAGS in Gallium GBM state-tracker

https://bugs.freedesktop.org/show_bug.cgi?id=64392 Bartosz Szczepanski changed: What|Removed |Added Version|unspecified |git -- You are receiving this mai

Re: [Mesa-dev] [PATCH] R600/SI: Add lit test coverage for the remaining patterns added recently

Am 08.05.2013 18:44, schrieb Michel Dänzer: From: Michel Dänzer Signed-off-by: Michel Dänzer Reviewed-by: Christian König --- test/CodeGen/R600/llvm.AMDGPU.imax.ll | 21 + test/CodeGen/R600/llvm.AMDGPU.imin.ll | 21 + test/CodeGen/R600/llvm.AM

[Mesa-dev] [Bug 64392] New: Missing WAYLAND_CFLAGS in Gallium GBM state-tracker

https://bugs.freedesktop.org/show_bug.cgi?id=64392 Priority: medium Bug ID: 64392 Assignee: mesa-dev@lists.freedesktop.org Summary: Missing WAYLAND_CFLAGS in Gallium GBM state-tracker Severity: trivial Classification: Unclassified

Re: [Mesa-dev] [Xcb] [PATCH] fix deadlock with libX11

Hi Uli, why is mesa-dev CC'd to this mail? I guess that mesa run into this problem and there is a thread on mesa-dev which could be provided in the commit message as an extra reference? (This also means that this mail will end up in mesa-dev's moderation queue...) I was working on the vdpau me

Re: [Mesa-dev] [PATCH] st/mesa: fix weird UCMP opcode use for bool ubo load

Reviewed-by: Marek Olšák Marek On Thu, May 9, 2013 at 12:58 AM, wrote: > From: Roland Scheidegger > > I don't know what this code was trying to do but whatever it was it couldn't > have worked since negation of integer boolean inputs while not specified as > outright illegal (not yet at least

[Mesa-dev] [Bug 44618] Cross-compilation broken by glsl builtin_compiler

https://bugs.freedesktop.org/show_bug.cgi?id=44618 Daniel Scharrer changed: What|Removed |Added CC||dan...@constexpr.org -- You are recei