- 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
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
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
>
- 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
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
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 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 +++
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
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
---
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 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/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.
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
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
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
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 ++
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 --
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
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
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 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
- 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:
> 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 -
> 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
- 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
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
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
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
> 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
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
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 |
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
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
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
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
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
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.
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
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
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
---
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
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 a
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)
https://bugs.freedesktop.org/show_bug.cgi?id=26663
ajax at nwnk dot net changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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
---
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 ++--
---
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_
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
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
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(-)
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
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
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
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.
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
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
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
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
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
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,
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(-)
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
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
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 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_
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
- 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
69 matches
Mail list logo
