On 03/04/2014 02:17 PM, Eric Anholt wrote:
> ---
> src/mesa/drivers/common/meta.h | 8
> src/mesa/drivers/common/meta_blit.c | 23 +++
> 2 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/common/meta.h b/src/mesa/drivers/common/m
On 03/04/2014 02:17 PM, Eric Anholt wrote:
> The meta patch supports all the same, except for the stencil case being
> unaccelerated.
> ---
> src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 105
> ---
> src/mesa/drivers/dri/i965/brw_context.h | 9 ---
> src/mesa/driv
On 03/04/2014 02:17 PM, Eric Anholt wrote:
> This gets us equivalent code paths on BDW and pre-BDW, except for stencil
> (where we don't have MSAA stencil resolve code yet)
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 111
> --
> 1 file changed, 103 insertions(+
On 03/04/2014 02:17 PM, Eric Anholt wrote:
> The flag wasn't getting updated correctly when the ctx->DrawBuffer or
> ctx->ReadBuffer changed. It usually ended up working out because most
> apps only have one window system framebuffer, or if they have more than
> one and they have any front read/dr
Reviewed-by: Marek Olšák
Marek
On Mon, Mar 10, 2014 at 4:36 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Fixes double-free with some piglit tests using geometry shaders.
>
> Signed-off-by: Michel Dänzer
> ---
> src/gallium/drivers/radeonsi/si_state.c | 2 ++
> 1 file changed, 2 inserti
From: Michel Dänzer
Fixes double-free with some piglit tests using geometry shaders.
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeonsi/si_state.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
On 03/04/2014 02:17 PM, Eric Anholt wrote:
> Now that BindRenderbufferTexImage() is a thing that drivers can do, winsys
> FBOs *can* have NeedsFinishRenderTexture set. The early exit here
> predated the NFRT flag, so it did make sense at the time.
> ---
> src/mesa/main/fbobject.c | 3 ---
> 1 fil
On Sam, 2014-03-08 at 01:34 +0100, Christian Zigotzky wrote:
> Hi All,
>
> I have figured out that the following definitions are not necessary for
> big-endian systems in the file "src/gallium/include/pipe/p_format.h":
>
> #if defined(PIPE_ARCH_LITTLE_ENDIAN)
> #define PIPE_FORMAT_RGBA_UNORM
https://bugs.freedesktop.org/show_bug.cgi?id=75797
Jasper St. Pierre changed:
What|Removed |Added
CC||jstpie...@mecheye.net
--
You are re
On Sam, 2014-03-08 at 18:28 -0700, Brian Paul wrote:
> This patch series:
> 1. removes an unnecessary section of comments.
> 2. Reorders the MESA_FORMAT_x enums to be more logical.
> 3. Renames MESA_FORMAT_X8Z24_UNORM
>
>
> Since it's hard to read from the diff, here's how the relevant part of
>
Hello Sir ,
I am Anuj Sharma from India. I am pursuing my M.Tech Degree at Indian
Institute of Technology, Kanpur, India.
Sir Where Can i get the more detail on what should we need to implement for
the "OpenCL Image Support".
Thanks & regards
Anuj Sharma
_
From: Marek Olšák
I think these are all equivalent to vertex buffer fetches which should be
dword-aligned. Scalar loads are also dword-aligned.
---
src/gallium/drivers/radeonsi/si_pipe.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe
From: Marek Olšák
Buffers are disabled by VGT_STRMOUT_BUFFER_CONFIG, but the query only works
if VGT_STRMOUT_CONFIG.STREAMOUT_0_EN is enabled.
This moves VGT_STRMOUT_CONFIG to its own state. The register is set to 1
if either streamout or the primitives-generated query is enabled.
However, the
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_pipe.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 0850269..827e9fe 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b
From: Marek Olšák
CB_COLORi_VIEW.SLICE_MAX can be at most 2047.
This fixes the maxlayers piglit test.
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/r600/r600_pipe.c | 8 +---
src/gallium/drivers/radeonsi/si_pipe.c | 9 ++---
2 files changed, 11 insertions(+), 6 deleti
From: Marek Olšák
It's already added in need_cs_space.
Also don't calculate anything if there are no buffers.
---
src/gallium/drivers/radeon/r600_streamout.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_streamout.c
b/src/gallium/driv
From: Marek Olšák
The GL 4.4 spec says it's not color-renderable and not accepted
by RenderBufferStorage. The EXT_texture_shared_exponent spec says
it's not color-renderable but it's accepted by RenderBufferStorageEXT.
This seems to be a bug in the extension spec.
Let's do what GL 4.4 says.
Cc:
https://bugs.freedesktop.org/show_bug.cgi?id=75919
--- Comment #4 from Krzysztof A. Sobiecki ---
It should be fixed soon.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=75919
Krzysztof A. Sobiecki changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 09/03/14 01:10, Brian Paul wrote:
> For example, we now we have separate dispatch functions for
> glCompileShader(GLuint) and glCompileShaderARB(GLhandleARB).
>
> With this change and the previous ones we should be able to build/run
> on MacOS again (where GLhandleARB is a void pointer, not a G
You are right, r600-r700 require dword alignment while linear copies can be
byte aligned on EG+.
Apart from that, patch 1 and 2 look good to me...
Ole
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
Do you have any opinion on this patch, anyone?
Marek
On Tue, Mar 4, 2014 at 12:32 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> There is no API for returning the number of luminance and intensity bits and
> the 3.3 spec doesn't seem to specify any behavior for the queries if the
> format
> is
Reviewed-by: Marek Olšák
Marek
On Fri, Mar 7, 2014 at 4:09 AM, Zack Rusin wrote:
> (This version includes comments from Roland.)
>
> D3D10 allows setting of the internal offset of a buffer, which is
> in general only incremented via actual stream output writes. By
> allowing setting of the inte
https://bugs.freedesktop.org/show_bug.cgi?id=75919
--- Comment #2 from Tom Stellard ---
(In reply to comment #0)
> Created attachment 95368 [details]
> Is there even a point?
>
> llvm-config-3.5 --version now prints 3.5.0 instead of 3.5.
> config is unable to find a shared llvm library if there
https://bugs.freedesktop.org/show_bug.cgi?id=75919
--- Comment #1 from Dave Witbrodt ---
(In reply to comment #0)
> Created attachment 95368 [details]
> Is there even a point?
>
> llvm-config-3.5 --version now prints 3.5.0 instead of 3.5.
> config is unable to find a shared llvm library if there
This series fixes some of the opencv opencl-related tests for me.
Thanks!
On Sun, 2014-03-09 at 02:24 +0100, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/gallium/drivers/r600/evergreen_state.c | 37 +---
> src/gallium/drivers/r600/r600_state.c | 41 ++
The primary users of these are linux developers, although
it can be extended for *BSD and others if needed.
Fixes make install for Cygwin and OpenBSD at least.
v2:
- Wrap vdpau targets as well.
v3:
- Fold HAVE_COMPAT_SYMLINKS checks within install*links.mk
Bugzilla: https://bugs.freedesktop.or
The buffer upload code required dword alignment. I don't know why. It
might have been for R600-R700.
Marek
On Sun, Mar 9, 2014 at 11:59 AM, Niels Ole Salscheider
wrote:
> On Sunday 09 March 2014, 02:24:51, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> ---
>> src/gallium/drivers/r600/evergreen_
On Sunday 09 March 2014, 02:24:51, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/gallium/drivers/r600/evergreen_state.c | 37 +---
> src/gallium/drivers/r600/r600_state.c | 41 ++---
> src/gallium/drivers/radeon/r600_buffer_common.c | 58
> ++
Am 08.03.2014 21:33, schrieb Emil Velikov:
The primary users of these are linux developers, although
it can be extended for *BSD and others if needed.
Fixes make install for Cygwin and OpenBSD at least.
v2:
- Wrap vdpau targets as well.
Can't we have the check inside install-lib-links.mk in
Am 08.03.2014 21:31, schrieb Emil Velikov:
All three (xvmc and omx) do not have an alternative loading
similar to the dri modules. Thus one needs to explicitly install
them in order to use/test them.
Double checking that (again) there actually there is a
BELLAGIO_SEARCH_PATH environment variab
Am 08.03.2014 21:30, schrieb Emil Velikov:
Drop the duplication across all vdpau targets.
Signed-off-by: Emil Velikov
Reviewed-by: Christian König
---
src/gallium/targets/r600/vdpau/Makefile.am | 6 +-
src/gallium/targets/radeonsi/vdpau/Makefile.am | 6 +-
src/gallium/targe
32 matches
Mail list logo
