- Original Message -
> Building on RHEL6 tinderbox, we get -std=c99, and the radeon uvd code
> uses anonymous unions which this disables.
>
> It doesn't look too difficult to fix, just wondering if there was a
> reason for using anon unions in the first place?
FWIW, anonymous unions are
Building on RHEL6 tinderbox, we get -std=c99, and the radeon uvd code
uses anonymous unions which this disables.
It doesn't look too difficult to fix, just wondering if there was a
reason for using anon unions in the first place?
Dave.
___
mesa-dev mail
On Thu, Apr 25, 2013 at 9:06 PM, Eric Anholt wrote:
> Improves GLB2.7 performance on my HSW by 0.671455% +/- 0.225037% (n=62).
> ---
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_
Improves GLB2.7 performance on my HSW by 0.671455% +/- 0.225037% (n=62).
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
i
On 04/25/2013 04:44 PM, Fredrik Höglund wrote:
The error code was changed from INVALID_VALUE to INVALID_OPERATION
in OpenGL 3.3. We should also generate an error when size is BGRA
and normalized is FALSE.
---
Note that this makes glean/tvertarraybgra fail because it expects
the error to be INVAL
The error code was changed from INVALID_VALUE to INVALID_OPERATION
in OpenGL 3.3. We should also generate an error when size is BGRA
and normalized is FALSE.
---
Note that this makes glean/tvertarraybgra fail because it expects
the error to be INVALID_VALUE. I'll send a patch for that to
the pigl
Improves GLB2.7 trex performance 1.01985% +/- 0.721366% on my IVB (n=10)
and by 3.38771% +/- 0.584241% (n=15) on my HSW, due to a 32x32 ARGB
cubemap going from untiled to tiled.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
I've updated this patch to handle the case where 0 rectangles have been given
and updated the eglSwapBuffers shim to rely on that. Thanks to Eric for
noticing this.
-- >8 --
Reviewed-by: Eric Anholt
---
src/egl/drivers/dri2/platform_wayland.c | 29 ++---
1 file changed,
Ian Romanick writes:
> On 04/25/2013 02:32 AM, Brian Paul wrote:
>> If we're in GL_COMPILE_AND_EXECUTE mode and inside glBegin, calling
>> glEndList() should generate an error.
>
> I wasn't aware that was an error. Is there some spec language that
> could be quoted in the code for that?
From t
We already hold the variable, just weren't providing access
to it.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c |9 +
src/gallium/auxiliary/tgsi/tgsi_ureg.h |6 ++
2 files changed, 15 insertions(+)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
On Thu, Apr 25, 2013 at 12:02:05PM -0700, Matt Turner wrote:
> Added in e1364530 but never used.
For the series:
Tested-by: Tom Stellard
> ---
> configure.ac |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 50e60f6..55ea13d 1006
Robert Bragg writes:
> @@ -491,8 +495,13 @@ dri2_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp,
> _EGLSurface *draw)
> dri2_surf->dx = 0;
> dri2_surf->dy = 0;
>
> - wl_surface_damage(dri2_surf->wl_win->surface, 0, 0,
> - dri2_surf->base.Width, dri2_surf->base.Hei
Both patches are
Reviewed-by: Chris Forbes
On Fri, Apr 26, 2013 at 6:51 AM, Matt Turner wrote:
> Three-source instructions have a vertical stride overloaded to 4, which
> prevents directly using vec4 uniforms as arguments. Instead we need to
> insert a MOV instruction to do the replication for
I seem to recall adding a bunch of null pointer checks to the
st_cb_bufferobjects.c code in the past to avoid crashing in some
out-of-memory situations. I think we should check for null pointers
wherever possible.
-Brian
On 04/25/2013 02:48 PM, Jose Fonseca wrote:
Looks good to me. Thanks.
Looks good to me. Thanks.
Jose
- Original Message -
> If the size is 0, there is nothing to do and st_obj->buffer can be NULL.
> st_obj->buffer should not be NULL in any other case.
>
> This fixes a segfault in Topogun. Reported by Jose Fonseca.
> ---
> src/mesa/state_tracker/st_cb_buff
On Thu, Apr 25, 2013 at 9:59 PM, Andy Ritger wrote:
> On Thu, Apr 25, 2013 at 05:34:11AM -0700, Ian Romanick wrote:
> > On 04/25/2013 11:12 AM, Andy Ritger wrote:
> > > Hi all,
> > >
> > > Last fall, I put together a proposal for an updated Linux OpenGL ABI
> > > specification:
> > >
> > >
> http
Matt Turner writes:
> Three-source instructions have a vertical stride overloaded to 4, which
> prevents directly using vec4 uniforms as arguments. Instead we need to
> insert a MOV instruction to do the replication for the three-source
> instruction.
>
> With this in place, we can use three-sour
If the size is 0, there is nothing to do and st_obj->buffer can be NULL.
st_obj->buffer should not be NULL in any other case.
This fixes a segfault in Topogun. Reported by Jose Fonseca.
---
src/mesa/state_tracker/st_cb_bufferobjects.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Paul Berry writes:
> The number of samples is already available in the miptree data
> structure, so there's no need to pass it in.
>
> I suspect this may fix a subtle bug because in one case
> (intel_renderbuffer_update_wrapper) we were always passing zero for
> num_samples, even though the buffe
Of the 3 controls in the extension, one was kept in GL core and the other
two were explicitly deprecated and the reasonable default behavior was
encoded in the spec. By not exposing the extension, we avoid shader
recompiles when switching between float and unorm color buffers.
---
src/mesa/driver
---
src/mesa/drivers/dri/intel/intel_fbo.c | 56 +++-
1 file changed, 34 insertions(+), 22 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 9fcee14..15d3918 100644
--- a/src/mesa/drivers/dri/intel/intel_
---
src/mesa/drivers/dri/i915/Makefile.sources |1 -
src/mesa/drivers/dri/i915/intel_tex_format.c |1 -
src/mesa/drivers/dri/i965/Makefile.sources |1 -
src/mesa/drivers/dri/i965/intel_tex_format.c |1 -
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 16 ++--
It appears that Z16 on Intel hardware is in fact slower than Z24, so
people are getting surprisingly hurt when trying to use Z16 as a
performance-versus-precision tradeoff, or when they're targeting GLES2 and
that's all you get.
GL 3.0+ have Z16 on the list of required exact format sizes, but GLES
On Thu, Apr 25, 2013 at 05:34:11AM -0700, Ian Romanick wrote:
> On 04/25/2013 11:12 AM, Andy Ritger wrote:
> > Hi all,
> >
> > Last fall, I put together a proposal for an updated Linux OpenGL ABI
> > specification:
> >
> >
> > https://github.com/aritger/linux-opengl-abi-proposal/blob/master/l
https://bugs.freedesktop.org/show_bug.cgi?id=26663
ajax at nwnk dot net changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
The three users of GALLIUM_PIPE_LOADER_LIBS (OpenCL, gallium-gbm,
gallium tests) don't appear to need libws_xlib.la.
---
Seems weird that this wasn't actually needed, but I tested by adding
-Wl,--no-undefined
to each Makefile.am that uses GALLIUM_PIPE_LOADER_LIBS (opencl, tests,
and gallium-gbm)
---
configure.ac |1 -
src/gallium/targets/gbm/Makefile.am|1 +
src/gallium/targets/opencl/Makefile.am |1 +
src/gallium/tests/trivial/Makefile.am |1 +
4 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index a
It guarded the function prototype of pipe_loader_sw_probe, whose use (in
pipe_loader.c) and definition (in pipe_loader_sw.c) were not guarded.
Both are built into libpipe_loader.la if HAVE_LOADER_GALLIUM, which is
enable_gallium_loader in configure.ac.
---
configure.ac
---
configure.ac |1 -
src/gallium/targets/gbm/Makefile.am|1 +
src/gallium/targets/opencl/Makefile.am |1 +
src/gallium/tests/trivial/Makefile.am |1 +
4 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 2
For consistency, since we already have HAVE_PIPE_LOADER_{SW,DRM}.
---
configure.ac |2 +-
.../auxiliary/pipe-loader/pipe_loader_drm.c|4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index 55ea1
Added in e1364530 but never used.
---
configure.ac |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 50e60f6..55ea13d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1899,7 +1899,6 @@ if test "x$enable_gallium_loader" = xyes; then
GALL
On Tue, Apr 23, 2013 at 3:42 AM, Chris Forbes wrote:
> Would it make more sense to move this patch just before or after patch
> 11, so the disassembly is correct from the moment you start emitting
> these?
Yes, good idea. I've moved it immediately after patch 11, i965/gen7:
Set src/dst types for
Only 13 affected programs in shader-db, but they were all helped.
total instructions in shared programs: 368877 -> 368851 (-0.01%)
instructions in affected programs: 1576 -> 1550 (-1.65%)
---
src/mesa/drivers/dri/i965/brw_shader.cpp| 3 +--
src/mesa/drivers/dri/i965/brw_vec4.
Three-source instructions have a vertical stride overloaded to 4, which
prevents directly using vec4 uniforms as arguments. Instead we need to
insert a MOV instruction to do the replication for the three-source
instruction.
With this in place, we can use three-source instructions in the vertex
sha
On 25.04.2013 19:22, Roland Scheidegger wrote:
> Am 24.04.2013 00:58, schrieb Zack Rusin:
>> There can be more stream output decls than shader outputs because
>> individual components from them can be split and distributed
>> among different so buffers.
>>
>> Signed-off-by: Zack Rusin
>> ---
>> s
Am 25.04.2013 19:44, schrieb Zack Rusin:
> - Original Message -
>> Am 24.04.2013 00:58, schrieb Zack Rusin:
>>> This was a very serious bug. We were always doing the viewport
>>> transformations on the first output of the vertex shader. That means
>>> that every application that was storing
Am 25.04.2013 19:44, schrieb Zack Rusin:
> - Original Message -
>> Am 24.04.2013 00:58, schrieb Zack Rusin:
>>> There can be more stream output decls than shader outputs because
>>> individual components from them can be split and distributed
>>> among different so buffers.
>>>
>>> Signed-o
The number of samples is already available in the miptree data
structure, so there's no need to pass it in.
I suspect this may fix a subtle bug because in one case
(intel_renderbuffer_update_wrapper) we were always passing zero for
num_samples, even though the buffer in question was not guaranteed
On Thu, Apr 25, 2013 at 7:45 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> v2:
> - Fix usage of set_constant_buffer()
> - Fix typo in comment
> ---
> src/gallium/drivers/r600/evergreen_compute.c | 46
> +++---
> .../drivers/r600/evergreen_compute_internal.h |
Reviewed-by: Marek Olšák
Marek
On Thu, Apr 25, 2013 at 7:46 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> v2:
> - Bump R600_NUM_ATOMS
> ---
> src/gallium/drivers/r600/evergreen_state.c | 34
> +-
> src/gallium/drivers/r600/evergreend.h | 2 ++
> src/gal
> You can already express holes with the current interface by setting
> dst_offset of two outputs such that there is a hole between them (e.g.
> dst_offset0 = 0, dst_offset1 = 8). I don't think inserting a dummy
> output for the hole is needed.
>
> Also, the commit summary doesn't say that the gal
You can already express holes with the current interface by setting
dst_offset of two outputs such that there is a hole between them (e.g.
dst_offset0 = 0, dst_offset1 = 8). I don't think inserting a dummy
output for the hole is needed.
Also, the commit summary doesn't say that the gallium interfa
From: Tom Stellard
v2:
- Bump R600_NUM_ATOMS
---
src/gallium/drivers/r600/evergreen_state.c | 34 +-
src/gallium/drivers/r600/evergreend.h | 2 ++
src/gallium/drivers/r600/r600_pipe.h | 11 +-
3 files changed, 36 insertions(+), 11 deletions(-)
d
From: Tom Stellard
v2:
- Fix usage of set_constant_buffer()
- Fix typo in comment
---
src/gallium/drivers/r600/evergreen_compute.c | 46 +++---
.../drivers/r600/evergreen_compute_internal.h | 2 +-
2 files changed, 32 insertions(+), 16 deletions(-)
diff --git a/s
- Original Message -
> Am 24.04.2013 00:58, schrieb Zack Rusin:
> > This was a very serious bug. We were always doing the viewport
> > transformations on the first output of the vertex shader. That means
> > that every application that was storing position in anything but
> > OUT[0] was out
- Original Message -
> Am 24.04.2013 00:58, schrieb Zack Rusin:
> > There can be more stream output decls than shader outputs because
> > individual components from them can be split and distributed
> > among different so buffers.
> >
> > Signed-off-by: Zack Rusin
> > ---
> > src/gallium
Am 24.04.2013 00:58, schrieb Zack Rusin:
> We weren't taking the buffer offset, destination offset or the
> stride into consideration so we were frequently writing into
> an overflown buffer.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/auxiliary/draw/draw_pt_so_emit.c | 11 ---
>
- Original Message -
> On Wed, Apr 24, 2013 at 09:54:02PM -0700, Jose Fonseca wrote:
> > - Original Message -
> > > On Wed, Apr 24, 2013 at 09:40:44PM +0200, Mathias Fröhlich wrote:
> > > >
> > > > Hi Tom,
> > > >
> > > > On Tuesday, April 23, 2013 20:47:24 Tom Stellard wrote:
>
Am 24.04.2013 00:58, schrieb Zack Rusin:
> This was a very serious bug. We were always doing the viewport
> transformations on the first output of the vertex shader. That means
> that every application that was storing position in anything but
> OUT[0] was outputing untransformed vertices and had b
Am 24.04.2013 00:58, schrieb Zack Rusin:
> There can be more stream output decls than shader outputs because
> individual components from them can be split and distributed
> among different so buffers.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/include/pipe/p_state.h |3 ++-
> 1 file
Am 25.04.2013 19:08, schrieb Tom Stellard:
[SNIP]
I think this is a good approach, however before we make big changes to
Mesa I want to make sure we know what problems we are trying to solve
with these changes. As far as I understand it, the current problems
are:
1. If an application is using
On Wed, Apr 24, 2013 at 09:54:02PM -0700, Jose Fonseca wrote:
> - Original Message -
> > On Wed, Apr 24, 2013 at 09:40:44PM +0200, Mathias Fröhlich wrote:
> > >
> > > Hi Tom,
> > >
> > > On Tuesday, April 23, 2013 20:47:24 Tom Stellard wrote:
> > > > First of all, thanks for investigating
We weren't taking the buffer offset, destination offset or the
stride into consideration so we were frequently writing into
an overflown buffer.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_pt_so_emit.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --
The spec says that the stream output can have holes if the register
index is the maximum possible value, in which case writes to the
buffer should be skipped but everything else should be processed
as usual.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_pt_so_emit.c | 15 ++
This was a very serious bug. We were always doing the viewport
transformations on the first output of the vertex shader. That means
that every application that was storing position in anything but
OUT[0] was outputing untransformed vertices and had broken output
for whatever it was storing at OUT[0
There can be more stream output decls than shader outputs because
individual components from them can be split and distributed
among different so buffers.
Signed-off-by: Zack Rusin
---
src/gallium/include/pipe/p_state.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src
Signed-off-by: Zack Rusin
---
src/gallium/drivers/llvmpipe/lp_query.c | 12
src/gallium/drivers/llvmpipe/lp_query.h |1 +
src/gallium/drivers/llvmpipe/lp_rast.c |2 ++
3 files changed, 15 insertions(+)
diff --git a/src/gallium/drivers/llvmpipe/lp_query.c
b/src/gallium/d
---
src/egl/drivers/dri2/platform_wayland.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/src/egl/drivers/dri2/platform_wayland.c
b/src/egl/drivers/dri2/platform_wayland.c
index e9a66af..8c12dd8 100644
--- a/src/egl/drivers/dri2/platform_wayland.
This pulls in EGL_EXT_swap_buffers_with_damage.
---
include/EGL/eglext.h | 45 ++---
1 file changed, 42 insertions(+), 3 deletions(-)
diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h
index b2b5a80..1d68178 100644
--- a/include/EGL/eglext.h
+++ b/inc
---
src/egl/main/eglapi.c | 32
src/egl/main/eglapi.h | 7 +++
src/egl/main/egldisplay.h | 1 +
src/egl/main/eglmisc.c| 1 +
4 files changed, 41 insertions(+)
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index bcc5465..30d4ee2 1006
This series adds support for the EGL_EXT_swap_buffers_with_damage[1] extension
for the egl wayland platform.
This extension is a natural counterpart to the EGL_EXT_buffer_age extension
that allows applications to inform the compositor what sub-regions of a buffer
have really changed with respect t
On 04/25/2013 12:45 AM, Ian Romanick wrote:
On 04/25/2013 02:32 AM, Brian Paul wrote:
If we're in GL_COMPILE_AND_EXECUTE mode and inside glBegin, calling
glEndList() should generate an error.
I wasn't aware that was an error. Is there some spec language that
could be quoted in the code for tha
On 04/25/2013 12:42 AM, Ian Romanick wrote:
On 04/25/2013 02:32 AM, Brian Paul wrote:
...in terms of new _mesa_is_valid_prim_mode(). We need a mode validater
function that doesn't depend on current state for the display list
code.
---
src/mesa/main/api_validate.c | 31 +++
Reviewed-by: Marek Olšák
Marek
On Thu, Apr 25, 2013 at 1:18 AM, wrote:
> From: Jerome Glisse
>
> This move the tracing timeout and printing into winsys and add
> an debug environement variable for it (R600_DEBUG=trace_cs).
>
> Lot of file touched because of winsys API changes.
>
> v2: Do not
On 04/25/2013 11:12 AM, Andy Ritger wrote:
Hi all,
Last fall, I put together a proposal for an updated Linux OpenGL ABI
specification:
https://github.com/aritger/linux-opengl-abi-proposal/blob/master/linux-opengl-abi-proposal.txt
but then got distracted. I'd like to try to resurrect the
- Original Message -
>
> Jose,
>
> On Thursday, April 25, 2013 01:38:46 Jose Fonseca wrote:
> > What I'm suggesting doesn't require huge effort.
> >
> > In detail, I'm suggesting:
> >
> > (1) have a custom build of LLVM libraries with -fvisibility=hidden
> >
> > (2) have a src/mesall
Jose,
On Thursday, April 25, 2013 01:38:46 Jose Fonseca wrote:
> What I'm suggesting doesn't require huge effort.
>
> In detail, I'm suggesting:
>
> (1) have a custom build of LLVM libraries with -fvisibility=hidden
>
> (2) have a src/mesallvm/mesallvm.c containing wrappers
>
> #include
>
Hi all,
Last fall, I put together a proposal for an updated Linux OpenGL ABI
specification:
https://github.com/aritger/linux-opengl-abi-proposal/blob/master/linux-opengl-abi-proposal.txt
but then got distracted. I'd like to try to resurrect the discussion.
>From the earlier email thread a
- Original Message -
>
> Hi,
>
> On Wednesday, April 24, 2013 21:54:02 Jose Fonseca wrote:
> > I don't see how this would work -- llvmpipe/draw has LLVMBuildXxxx calls
> > too. So to prevent symbol collision with apps that use them, we'd need to
> > expose all LLVM calls we need under
69 matches
Mail list logo
