Hi List,
There are any problems with false colors since Mesa 9.2 on big-endian
(PowerPC) systems (Screenshot:
https://bugs.freedesktop.org/attachment.cgi?id=91566). I've created the
bug report 72877 (https://bugs.freedesktop.org/show_bug.cgi?id=72877).
I've figured out that the following
I've added resetting the rotate in clear_layers, fixed calc_drawn_area
and then committed the result.
Thx for the help,
Christian.
Am 07.03.2014 03:07, schrieb Kusanagi Kouichi:
Signed-off-by: Kusanagi Kouichi sl...@ac.auone-net.jp
---
src/gallium/auxiliary/vl/vl_compositor.c | 64
On Fre, 2014-03-07 at 08:54 +0100, Christian Zigotzky wrote:
Hi List,
There are any problems with false colors since Mesa 9.2 on big-endian
(PowerPC) systems (Screenshot:
https://bugs.freedesktop.org/attachment.cgi?id=91566). I've created the
bug report 72877
On 03/06/2014 12:47 PM, Kenneth Graunke wrote:
This is largely a matter of looping over the number of slices/layers,
and not minifying depth (presumably that code exists for the unfinished
3D texture support).
Normally, I would have made the loop over array slices the outermost
loop. I
This patch is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 03/04/2014 11:12 PM, Emil Velikov wrote:
From: Jon TURNEY jon.tur...@dronecode.org.uk
Recent commit fixed build issues in dri2_query_renderer.c by
wrapping in defined(direct_rendering) !defined(applegl)
This patch
This patch is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 03/04/2014 11:12 PM, Emil Velikov wrote:
- xf86dri.h is the old dri1 header, not required by dri2 nor dri3
- fold xf86drm.h inclusiong inside dri2.h
- dri3_glx does not have any drm specific dependencies
- glapi.h is not
Hello Michel,
I'm sorry. I'll send your answer in another mail.
Rgds,
Christian
On 07.03.2014, you wrote:
On Fre, 2014-03-07 at 08:54 +0100, Christian Zigotzky wrote:
Hi List,
There are any problems with false colors since Mesa 9.2 on big-endian
(PowerPC) systems (Screenshot:
On Don, 2014-03-06 at 20:06 +0100, Christian Zigotzky wrote:
Hi Thomas,
Hi Michel,
There are any problems with false colors since Mesa 9.2 on big-endian
(PowerPC) systems. I've figured out that the following line in
src/gallium/drivers/r600/evergreen_state.c the problem is.
case
Patch adds a remap table for uniforms that is used to provide a mapping
from application specified uniform location to actual location in the
UniformStorage. Existing UniformLocationBaseScale usage is removed as
table can be used to set sequential values for array uniform elements.
This mapping
Remove GL_OES_EGL_image_external usage, this would work with current
Mesa only if image was created with EGL_EXT_image_dma_buf_import, this
makes test work again also if GL_OES_EGL_image_external is present.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
I can't find that these functions were ever used.
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 02/27/2014 10:15 AM, Tapani Pälli wrote:
Nothing uses this structure, removal fixes Klocwork error about
the possible oom condition in _mesa_symbol_table_iterator_ctor.
Signed-off-by:
https://bugs.freedesktop.org/show_bug.cgi?id=66346
--- Comment #4 from Ian Romanick i...@freedesktop.org ---
This is in glext.h:
#ifdef __APPLE__
typedef void *GLhandleARB;
#else
typedef unsigned int GLhandleARB;
#endif
Thanks, Apple!
I think Mesa is just broken on Apple, probably forever,
On 03/06/2014 05:38 AM, Ilia Mirkin wrote:
sizeof(scissor) returns the size of the full array rather than a single
element. Fix it to consider just the one element.
Fixes: 0705fa35cdaf15ec969c28dc85e88b8be1149a3b
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Yeah, this looks right.
On 03/06/2014 12:47 PM, Kenneth Graunke wrote:
I recently started looking at a suite of microbenchmarks, and discovered
that one of the tests called GenerateMipmaps repeatedly (sadly, probably
not intentionally). Naturally, it used a 2DArray texture, which we didn't
support, so we hit the
On 03/07/2014 12:55 PM, Tapani Pälli wrote:
Patch adds a remap table for uniforms that is used to provide a mapping
from application specified uniform location to actual location in the
UniformStorage. Existing UniformLocationBaseScale usage is removed as
table can be used to set sequential
On 06/03/14 04:01, Ilia Mirkin wrote:
nouveau_fence_wait has the expectation that an external entity is
holding onto the fence being waited on, not that it is merely held onto
by the current pointer. Fixes a use-after-free in nouveau_fence_wait
when used on the screen's current fence.
IMHO
On Mon, Mar 03, 2014 at 01:19:48PM +1000, Dave Airlie wrote:
There is a comment and two checks in the i965 dma-buf importer,
* Images originating via EGL_EXT_image_dma_buf_import can be used only
* with GL_OES_EGL_image_external only.
however I can't find any reference to this in the spec
Tom Stellard t...@stellard.net writes:
On Thu, Mar 06, 2014 at 01:45:36PM +0100, Francisco Jerez wrote:
Tom Stellard thomas.stell...@amd.com writes:
---
src/gallium/drivers/radeon/radeon_llvm_util.c | 35 --
.../state_trackers/clover/core/compiler.hpp| 3 +-
https://bugs.freedesktop.org/show_bug.cgi?id=66346
--- Comment #5 from Brian Paul bri...@vmware.com ---
Looks like there's about 20 functions which would have be split into ARB
(GLhandleARB) and non-ARB (GLuint) flavors.
I might take a crack at it someday...
I'd like to see Mesa compile on
On 06/03/14 14:19, Jon TURNEY wrote:
On 04/03/2014 21:12, Emil Velikov wrote:
From: Jon TURNEY jon.tur...@dronecode.org.uk
v2: (Emil)
- Do not link agaist libglapi.
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
This is the updated version of this patch series:
http://lists.freedesktop.org/archives/mesa-dev/2014-January/050817.html
Here are some explanations about what the patches introduce:
GPU offloading:
First step is to indicate which GPU to use.
For that the patches introduces two ways:
. using
It allows to blit two __DRIimages.
Signed-off-by: Axel Davy axel.d...@ens.fr
---
include/GL/internal/dri_interface.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index d028d05..91f2fe3
Add to drirc a new parameter: wanted_device_id_path_tag
to indicate the gpu we would like to use.
The EGL Wayland platform checks this parameter under
the driver name init. It should be possible to get GLX
to check this parameter too, and use it for DRI3
GPU offloading.
Signed-off-by: Axel Davy
What we want is disabling the path using primes fds if
the client can't create primes fds.
Signed-off-by: Axel Davy axel.d...@ens.fr
Signed-off-by: Neil Roberts n...@linux.intel.com
---
Neil and me did the same correction independantly.
src/egl/drivers/dri2/platform_wayland.c | 2 +-
1 file
Signed-off-by: Axel Davy axel.d...@ens.fr
---
src/mesa/drivers/dri/common/xmlconfig.c | 29 +
src/mesa/drivers/dri/common/xmlconfig.h | 7 ++-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/common/xmlconfig.c
When the client use a different graphic device than the server,
we want for better performance to render to a tiled buffer,
and copy to a linear buffer which we share with the server.
Signed-off-by: Axel Davy axel.d...@ens.fr
---
src/egl/drivers/dri2/egl_dri2.h | 2 +
Signed-off-by: Axel Davy axel.d...@ens.fr
---
src/gallium/state_trackers/dri/drm/dri2.c | 44 ---
1 file changed, 41 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
b/src/gallium/state_trackers/dri/drm/dri2.c
index
I should have added that I choosed to be consistent with the code style
in the file
and then used GLuint as everywhere in the file.
Another patch should probably remove all occurences of GLuint in the
file to replace it with unsigned.
Axel Davy
Signed-off-by: Axel Davy axel.d...@ens.fr
---
On 06/03/14 09:56, Maarten Lankhorst wrote:
Explicitly add radeon_drm_winsys_create and nouveau_drm_screen_create to
the dynamic list. This will ensure vdpau interop still works even when
the user links with -Bsymbolic-functions in hardened builds.
With the only reason why we've nuked
Am 07.03.2014 05:47, schrieb Chia-I Wu:
On Fri, Mar 7, 2014 at 11:56 AM, Chia-I Wu olva...@gmail.com wrote:
On Fri, Mar 7, 2014 at 2:04 AM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
Am 06.03.2014 18:32, schrieb Jose Fonseca:
- Original Message -
-
I forgot to precise (for those who want to test) that to offload
on a gallium card, it needs the DRIimage driver extension support
in gallium. This is implemented in this branch:
http://cgit.freedesktop.org/~keithp/mesa/log/?h=dri3%2Bgallium
On Fri, Mar 7, 2014 at 9:11 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 06/03/14 04:01, Ilia Mirkin wrote:
nouveau_fence_wait has the expectation that an external entity is
holding onto the fence being waited on, not that it is merely held onto
by the current pointer. Fixes a
On 03/07/2014 09:45 AM, Roland Scheidegger wrote:
Am 07.03.2014 05:47, schrieb Chia-I Wu:
On Fri, Mar 7, 2014 at 11:56 AM, Chia-I Wu olva...@gmail.com wrote:
On Fri, Mar 7, 2014 at 2:04 AM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
Am 06.03.2014 18:32, schrieb
---
src/mesa/state_tracker/st_manager.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_manager.c
b/src/mesa/state_tracker/st_manager.c
index 68cb5de..314d342 100644
--- a/src/mesa/state_tracker/st_manager.c
+++
On Fri, Mar 7, 2014 at 8:01 AM, Ian Romanick i...@freedesktop.org wrote:
On 03/06/2014 05:38 AM, Ilia Mirkin wrote:
sizeof(scissor) returns the size of the full array rather than a single
element. Fix it to consider just the one element.
Fixes: 0705fa35cdaf15ec969c28dc85e88b8be1149a3b
In eglCreateContext there is a check for whether the config parameter is zero
and in this case it will avoid reporting an error if the
EGL_KHR_surfacless_context extension is supported. However there is nothing in
that extension which says you can create a context without a config and Mesa
breaks
This tests creating an EGLContext without an EGLConfig and then
creates three surfaces with different configs and tries rendering to
them. The test is skipped if the extension is not available.
---
tests/all.py | 4 +
tests/egl/CMakeLists.gl.txt| 1 +
This extension provides a way for an application to render to multiple
surfaces with different buffer formats without having to use multiple
contexts. An EGLContext can be created without an EGLConfig by passing
EGL_NO_CONFIG_MESA. In that case there are no restrictions on the surfaces
that can be
Here is a series of patches to add an extension which makes it
possible to create an EGL context without specifying a config. A
context created in this way can be bound with any surface using the
same EGLDisplay rather than being restricted to those using the same
config. The main use case is that
Part of the gl_renderer_setup function only deals with checking EGL
extensions and doesn't need to have a current context. This patch
moves these checks so that they are done during gl_renderer_create
instead of waiting until we have an output. We will need this in a
later patch because some of
The gbm-format configuration option can now be specified per-output as
well as in the core config section. If it is not specified it will
default to the format specified in the core section. The
EGL_MESA_configless_context extension is required for this to work. If
this extension is available it
In GLES 3 it is not possible to select rendering to the front buffer and
instead selecting GL_BACK has the magic interpretation that it is either the
front buffer on single-buffered configs or the back buffer on double-buffered.
GLES 1 and 2 have no way of selecting the draw buffer at all. In that
Under GLES 3 it is not valid to pass GL_FRONT to glDrawBuffers. Instead,
GL_BACK has a magic interpretation which means it will render to the front
buffer on single-buffered contexts and the back buffer on double-buffered. We
were incorrectly setting the initial value to GL_FRONT for
Kenneth Graunke kenn...@whitecape.org writes:
Almost the exact same code appeared twice, and it needs to expand to
handle additional texture targets. Refactor it to tidy up the code and
avoid duplicating more work in the future.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
I had a
https://bugs.freedesktop.org/show_bug.cgi?id=66346
--- Comment #6 from Eric Anholt e...@anholt.net ---
I ran into this with epoxy, and in the process of trying to come up with a fix
noted that all the GLhandleARBs are in the first 6 args of the functions, so
they'll be stored in registers in
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/drivers/radeonsi/si_blit.c | 4 +--
src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
src/gallium/drivers/radeonsi/si_pipe.h | 14 ++
src/gallium/drivers/radeonsi/si_state.c | 40 +---
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/drivers/r600/r600_blit.c | 82 +-
src/gallium/drivers/radeon/r600_pipe_common.h | 7 ++-
src/gallium/drivers/radeon/r600_texture.c | 83 ++-
3 files changed, 88 insertions(+), 84
From: Marek Olšák marek.ol...@amd.com
This works for both multi-sample and single-sample color buffers.
---
src/gallium/drivers/radeon/r600_texture.c | 6 -
src/gallium/drivers/radeonsi/si_blit.c| 38 +--
src/gallium/drivers/radeonsi/si_pipe.c| 1 +
From: Marek Olšák marek.ol...@amd.com
I will use this in radeonsi.
---
src/gallium/drivers/r600/evergreen_state.c| 219 ++
src/gallium/drivers/r600/r600_state.c | 7 -
src/gallium/drivers/radeon/Makefile.sources | 1 +
From: Marek Olšák marek.ol...@amd.com
When doing fast clear for single-sample color buffers for the first time,
a CMASK buffer has to be allocated and the CMASK state in all pipe_surfaces
referencing the color buffer must be updated. Updating all surfaces is kinda
silly, so let's move the values
From: Marek Olšák marek.ol...@amd.com
This looks like r600g. The shared Cayman MSAA code is used here.
The real motivation for this is that I need the ability to change values
of color registers after the framebuffer state is set. The PM4 state cannot
be modified easily after it's generated.
From: Marek Olšák marek.ol...@amd.com
This fixes piglit/fbo-sys-blit with fast clear on radeonsi.
---
src/gallium/state_trackers/dri/drm/dri2.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
b/src/gallium/state_trackers/dri/drm/dri2.c
index
Tapani Pälli tapani.pa...@intel.com writes:
Patch adds a remap table for uniforms that is used to provide a mapping
from application specified uniform location to actual location in the
UniformStorage. Existing UniformLocationBaseScale usage is removed as
table can be used to set sequential
Kenneth Graunke kenn...@whitecape.org writes:
From: Eric Anholt e...@anholt.net
This keeps us from needing to reemit all the other stage state just
because a surface changed.
Improves unoptimized glamor x11perf -f8text by 1.10201% +/- 0.489869%
(n=296). [v1]
v2: (by Kenneth Graunke)
-
- Original Message -
On 03/07/2014 09:45 AM, Roland Scheidegger wrote:
Am 07.03.2014 05:47, schrieb Chia-I Wu:
On Fri, Mar 7, 2014 at 11:56 AM, Chia-I Wu olva...@gmail.com wrote:
On Fri, Mar 7, 2014 at 2:04 AM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message
https://bugs.freedesktop.org/show_bug.cgi?id=66346
--- Comment #7 from José Fonseca jfons...@vmware.com ---
(In reply to comment #4)
This is in glext.h:
#ifdef __APPLE__
typedef void *GLhandleARB;
#else
typedef unsigned int GLhandleARB;
#endif
Thanks, Apple!
I think Mesa is just
https://bugs.freedesktop.org/show_bug.cgi?id=66346
--- Comment #8 from José Fonseca jfons...@vmware.com ---
(In reply to comment #7)
Furthermore what Apple does is irrelevant, as Mesa is free to do what it
wants (ie, it's free to assume using GLhandleARB are always 32bits).
To be perfectly
Looks good to me.
Jose
- Original Message -
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 internal offset draw_auto is capable
of rendering from buffers which have not been
(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 internal offset draw_auto is capable
of rendering from buffers which have not been actually
Reviewed-by: Roland Scheidegger srol...@vmware.com
Am 07.03.2014 04:09, schrieb Zack Rusin:
(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
This fixes the a build breakage caused by
6974eb907600b9d0176d3158ff0fd30ac3e56a55 on build configurations where
all the following are true:
1. radeonsi is not being built
2. r600g is being built
3. opencl is disabled
4. --enable-r600-llvm-compiler is not being used
5. libelf is not installed
---
This fixes the a build breakage caused by
6974eb907600b9d0176d3158ff0fd30ac3e56a55 on build configurations where
all the following are true:
1. radeonsi is not being built
2. r600g is being built
3. opencl is disabled
4. --enable-r600-llvm-compiler is not being used
5. libelf is not installed
Am 07.03.2014 18:55, schrieb Brian Paul:
---
src/mesa/state_tracker/st_manager.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_manager.c
b/src/mesa/state_tracker/st_manager.c
index 68cb5de..314d342 100644
---
- Original Message -
---
src/mesa/state_tracker/st_manager.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_manager.c
b/src/mesa/state_tracker/st_manager.c
index 68cb5de..314d342 100644
---
https://bugs.freedesktop.org/show_bug.cgi?id=66346
--- Comment #9 from José Fonseca jfons...@vmware.com ---
(In reply to comment #4)
We
assume *everywhere* that GLhandleARB == GLuint... to the point that
glGetActiveAttrib and glGetActiveAttribARB (and many, many others) are the
same function.
https://bugs.freedesktop.org/show_bug.cgi?id=66346
--- Comment #10 from Brian Paul bri...@vmware.com ---
(In reply to comment #9)
(In reply to comment #4)
We
assume *everywhere* that GLhandleARB == GLuint... to the point that
glGetActiveAttrib and glGetActiveAttribARB (and many, many
Does this patch fix the build:
http://lists.freedesktop.org/archives/mesa-dev/2014-March/055571.html
-Tom
From: Stellard, Thomas
Sent: Friday, March 07, 2014 5:00 PM
To: mesa-dev@lists.freedesktop.org
Cc: Brian Paul; Stellard, Thomas
Subject: [PATCH]
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 PIPE_FORMAT_R8G8B8A8_UNORM
#define PIPE_FORMAT_RGBX_UNORM
If get_buffers() hadn't been called yet, we would return the age of the
last back, rather than the one that's actually going to be used for this
frame.
Note that get_buffers() can sometimes reallocate. We're covered on that
front, though -- it does a copy_area() when it reallocates, which
---
Here's my series of cleanups and fixes for your EXT_buffer_age patch.
I've run it through piglit, and run gnome-shell with it now.
I'm proposing moving patch 3 before your patch, then squashing 1, 2,
and 4 in with yours. Does this sound good?
src/glx/dri3_glx.c | 12 ++--
1 file
With the buffer_age code, I need to be able to potentially call this more
than once per frame, and it would be bad if a new special event showing up
meant I chose a different back mid-frame. Now, once we've chosen a back
for the frame, another find_back will choose it again since we know that
it
---
src/glx/dri3_glx.c | 6 ++
src/glx/dri3_priv.h | 3 +--
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 4388b74..72ec8ec 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -1346,7 +1346,7 @@
72 matches
Mail list logo
