Signed-off-by: Jonathan Gray j...@jsg.id.au
---
src/gallium/state_trackers/xvmc/tests/xvmc_bench.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git src/gallium/state_trackers/xvmc/tests/xvmc_bench.c
src/gallium/state_trackers/xvmc/tests/xvmc_bench.c
index
Am 26.06.2013 09:10, schrieb Jonathan Gray:
Signed-off-by: Jonathan Gray j...@jsg.id.au
Looks good on first glance, patch is:
Reviewed-by: Christian König christian.koe...@amd.com
---
src/gallium/state_trackers/xvmc/tests/xvmc_bench.c | 13 -
1 file changed, 8 insertions(+),
Am 26.06.2013 05:29, schrieb Ilia Mirkin:
On Mon, Jun 24, 2013 at 2:13 PM, Christian König
deathsim...@vodafone.de wrote:
Am 24.06.2013 18:39, schrieb Ilia Mirkin:
On Mon, Jun 24, 2013 at 4:48 AM, Christian König
deathsim...@vodafone.de wrote:
Am 23.06.2013 18:59, schrieb Ilia Mirkin:
On Wed, Jun 26, 2013 at 4:33 AM, Christian König
deathsim...@vodafone.de wrote:
Am 26.06.2013 05:29, schrieb Ilia Mirkin:
On Mon, Jun 24, 2013 at 2:13 PM, Christian König
deathsim...@vodafone.de wrote:
Am 24.06.2013 18:39, schrieb Ilia Mirkin:
On Mon, Jun 24, 2013 at 4:48 AM, Christian
- Original Message -
We weren't taking into account the size of element
that is to be fetched, which meant that it was possible
to overflow the buffer reads if the stride was very
close to the end of the buffer, e.g. stride = 3, buffer
size = 4, and the element to be read = 4. This
On Wed, Jun 26, 2013 at 2:11 AM, Jonathan Gray j...@jsg.id.au wrote:
program_invocation_short_name is glibc specific. Provide an
alternative using getprogname(), which can be found on *BSD and OS X.
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
src/gallium/drivers/r300/r300_chipset.c |
Hello,
On FreeBSD, the x86-64 arch is named amd64. This patch fixes its
detection in the configure script.
--
Jean-Sébastien Pédron
From 6393428a12f454f88157af9810a89161b0606769 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jean-S=C3=A9bastien=20P=C3=A9dron?= dumbb...@freebsd.org
Date: Wed, 5 Jun
Hello,
Without this change, the build would pick the system-wide libdrm, not
the one given to the configure script (through PKG_CONFIG_PATH for
instance).
--
Jean-Sébastien Pédron
From 08d12cdfd4d653cebaf30cec4a2b1e970ecef0d3 Mon Sep 17 00:00:00 2001
From:
Hello,
The subject should be explicit :)
--
Jean-Sébastien Pédron
From 0126159ee03f8c432129c5966cfa41462d5d2fa5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jean-S=C3=A9bastien=20P=C3=A9dron?= dumbb...@freebsd.org
Date: Wed, 5 Jun 2013 13:44:34 +0200
Subject: [PATCH 5/9] Fix typo in ETIMEOUT
Hello,
The patch uses the $* GNU make variable instead of shell parameter
expansion to find the language code.
--
Jean-Sébastien Pédron
From fed4ca6ef4134dfc34a6e25e5b8de3ef905d2efa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jean-S=C3=A9bastien=20P=C3=A9dron?= dumbb...@freebsd.org
Date: Wed, 5
Hello,
This is the equivalent to byteswap.h and bswap_32(x) on Linux.
--
Jean-Sébastien Pédron
From 48fd41784d4c39059c68ecfc4e01197555ec48dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jean-S=C3=A9bastien=20P=C3=A9dron?=
jean-sebast...@yakaz.com
Date: Fri, 14 Jun 2013 17:39:31 +0200
Subject:
Hello,
This fixes the build when the build directory is not the source directory.
--
Jean-Sébastien Pédron
From 15b05331ac969c9f86d8782da07dfd17c0c8a9ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jean-S=C3=A9bastien=20P=C3=A9dron?= dumbb...@freebsd.org
Date: Wed, 5 Jun 2013 13:35:01 +0200
On Wed, Jun 26, 2013 at 02:39:40PM +0200, Jean-Sébastien Pédron wrote:
On 26.06.2013 14:37, Jean-Sébastien Pédron wrote:
Makefiles were explicitly looking for a libraries suffixed with the full
libtool versioning, such as libglapi.so.0.0.0. However, on some
systems (at least FreeBSD and
On Wed, Jun 26, 2013 at 03:05:47PM +0200, Jean-Sébastien Pédron wrote:
Hello,
This is the equivalent to byteswap.h and bswap_32(x) on Linux.
this is already fixed in a cleaner way, see
ebd68dd02998a8595cb10844c37a6b02dc3078a8
___
mesa-dev mailing
On 26.06.2013 15:14, Jonathan Gray wrote:
this is already fixed in a cleaner way, see
ebd68dd02998a8595cb10844c37a6b02dc3078a8
You're right, thanks for pointing me to it!
--
Jean-Sébastien Pédron
signature.asc
Description: OpenPGP digital signature
On Wed, Jun 26, 2013 at 02:54:34PM +0200, Jean-Sébastien Pédron wrote:
Hello,
On FreeBSD, the x86-64 arch is named amd64. This patch fixes its
detection in the configure script.
Shouldn't config.guess/config.sub remap it?
from config.log here:
uname -m = amd64
uname -r = 5.3
uname -s =
- Original Message -
In glapi_priv.h we always need the typedef for the GLclampx type
since GL_OES_fixed_point is now defined in glext.h but the
GLclampx type is not. GLclampx is not used by anything in glext.h
but we need it for GL ES dispatch.
---
include/GL/glext.h
On 06/26/2013 07:48 AM, Jose Fonseca wrote:
- Original Message -
In glapi_priv.h we always need the typedef for the GLclampx type
since GL_OES_fixed_point is now defined in glext.h but the
GLclampx type is not. GLclampx is not used by anything in glext.h
but we need it for GL ES
Looks good to me.
Jose
- Original Message -
From: Roland Scheidegger srol...@vmware.com
trivial, copied from llvmpipe
---
src/gallium/drivers/softpipe/sp_surface.c | 42
+++--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git
On 26.06.2013 15:10, Jonathan Gray wrote:
This misses a few places see
http://marc.info/?l=mesa3d-devm=137179411405480w=2
namely
src/gbm/Makefile.am
src/mapi/es1api/Makefile.am
src/mapi/es2api/Makefile.am
src/mapi/vgapi/Makefile.am
I attached a new patch, fixing the Makefile.am's you
https://bugs.freedesktop.org/show_bug.cgi?id=64959
--- Comment #4 from Ross Burton r...@burtonini.com ---
For fun, current mesa master doesn't even compile without X11 headers:
| In file included from
/.../mesa/2_9.2.0~gitAUTOINC+9aebad618c-r9.0/git/include/EGL/egl.h:36:0,
|
On Wed, Jun 26, 2013 at 8:58 PM, Jean-Sébastien Pédron
jean-sebastien.ped...@dumbbell.fr wrote:
Hello,
The subject should be explicit :)
Applied, thanks.
--
Jean-Sébastien Pédron
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On 26.06.2013 15:35, Jonathan Gray wrote:
On Wed, Jun 26, 2013 at 02:54:34PM +0200, Jean-Sébastien Pédron wrote:
Hello,
On FreeBSD, the x86-64 arch is named amd64. This patch fixes its
detection in the configure script.
Shouldn't config.guess/config.sub remap it?
from config.log here:
On 26.06.2013 14:58, Jean-Sébastien Pédron wrote:
The patch uses the $* GNU make variable instead of shell parameter
expansion to find the language code.
Please disregard this patch.
The problem was fixed in 95e145aaee1c535aa4d55b1765c717968efdf18c,
between the day I made the patch (a few
On 06/25/2013 09:40 PM, Vinson Lee wrote:
Fixes Uninitialized scalar field defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
src/glsl/link_uniforms.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On 06/26/2013 01:11 AM, Jonathan Gray wrote:
program_invocation_short_name is glibc specific. Provide an
alternative using getprogname(), which can be found on *BSD and OS X.
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
src/gallium/drivers/r300/r300_chipset.c | 10 +-
1 file
Hi,
I'm routinely building Mesa and Weston in an environment without X11,
and currently both Mesa and Weston are failing to build for the same
reason: eglplatform.h is attempting to include X11/Xlib.h.
There was a patch last year that attempted to solve the Mesa part of this:
Hi Vincent,
Here is an updated version of patch #3.
-Tom
On Fri, Jun 14, 2013 at 08:35:03AM -0700, Vincent Lejeune wrote:
Hi,
Thank for your work on this !
Patch 2, 4 and 5 have my rb.
diff --git a/lib/Target/R600/R600InstrInfo.cpp
b/lib/Target/R600/R600InstrInfo.cpp
index
https://bugs.freedesktop.org/show_bug.cgi?id=66213
Priority: medium
Bug ID: 66213
Assignee: mesa-dev@lists.freedesktop.org
Summary: Certain Mesa Demos Rendering Inverted (vertically)
Severity: major
Classification: Unclassified
Vinson Lee v...@freedesktop.org writes:
Fixes Dereference before null check defect reported by Coverity.
The irb-mt check should be dropped, instead --
_mesa_source_buffer_exists() or _mesa_clip_copytexsubimage() should have
failed in that case, and we would never have reached this.
https://bugs.freedesktop.org/show_bug.cgi?id=66213
--- Comment #1 from Jesus Cortez jesus.corte...@gmail.com ---
Created attachment 81484
-- https://bugs.freedesktop.org/attachment.cgi?id=81484action=edit
demonstrates winpos inversion
--
You are receiving this mail because:
You are the
On 06/21/2013 10:09 PM, Kenneth Graunke wrote:
On 06/21/2013 11:29 AM, Eric Anholt wrote:
Long ago, when porting FBO and memory management support to i965, I
merged a bunch of code between the i915 and i965 drivers and put it in
the intel directory. I think it served us well for a long time,
https://bugs.freedesktop.org/show_bug.cgi?id=66213
Jesus Cortez jesus.corte...@gmail.com changed:
What|Removed |Added
Attachment #81483|0 |1
is
The new 20130624 version of glext.h removed the const qualifier on
the 'userParam' parameter.
---
src/mapi/glapi/gen/ARB_debug_output.xml |2 +-
src/mesa/main/errors.c |4 ++--
src/mesa/main/errors.h |2 +-
3 files changed, 4 insertions(+), 4
The 20130624 version of glext.h changed this to match the
glMultiDrawElements() function which already had the extra const
qualifier.
Fixes warnings/errors that seem to vary from one compiler to the next.
---
src/mapi/glapi/gen/gl_API.xml |2 +-
src/mesa/vbo/vbo_exec_array.c |2 +-
A couple of our automated builds failed with the new glext.h header.
But I didn't see any issues with my local builds. It seems some
compilers (or versions of compilers) are more sensitive to const
qualifiers on function parameters than others.
Hopefully the two patches I just posted will
Series looks good to me.
Jose
- Original Message -
The 20130624 version of glext.h changed this to match the
glMultiDrawElements() function which already had the extra const
qualifier.
Fixes warnings/errors that seem to vary from one compiler to the next.
---
https://bugs.freedesktop.org/show_bug.cgi?id=66213
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment
https://bugs.freedesktop.org/show_bug.cgi?id=66213
--- Comment #4 from Ian Romanick i...@freedesktop.org ---
Also, what driver are you using? The output of glxinfo | grep renderer
should provide the necessary information.
--
You are receiving this mail because:
You are the assignee for the
On 06/26/2013 07:13 AM, Brian Paul wrote:
On 06/26/2013 07:48 AM, Jose Fonseca wrote:
- Original Message -
In glapi_priv.h we always need the typedef for the GLclampx type
since GL_OES_fixed_point is now defined in glext.h but the
GLclampx type is not. GLclampx is not used by anything
Kenneth Graunke kenn...@whitecape.org writes:
brw_wm_surface_state.c has gotten rather large and unwieldy. At this
point, it consists of two separate portions:
1. Surface format code
This includes the giant table of surface formats and what features
they support on each generation,
---
src/mesa/program/register_allocate.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/program/register_allocate.c
b/src/mesa/program/register_allocate.c
index ea06a07..4eed0b5 100644
--- a/src/mesa/program/register_allocate.c
+++
---
src/glx/glxcmds.c | 15 +++
src/glx/single2.c |3 ++-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 5c79073..224e402 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -575,20 +575,19 @@ static Bool
Since it's an error with MSVC.
---
configure.ac |5 +
1 file changed, 5 insertions(+)
diff --git a/configure.ac b/configure.ac
index 6832b0d..16f11aa 100644
--- a/configure.ac
+++ b/configure.ac
@@ -209,6 +209,11 @@ if test x$GCC = xyes; then
#
Just to be consistent with the functions' Bool return type.
---
src/glx/glxcmds.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 224e402..019165a 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@
Several components are never expected to be built with MSVC (glx, most dri
drivers), so this would put (most likely undesired) burden on those maintainers.
I suspect we'll need to do this on a per directory basis...
Jose
- Original Message -
Since it's an error with MSVC.
---
https://bugs.freedesktop.org/show_bug.cgi?id=66213
--- Comment #5 from Jesus Cortez jesus.corte...@gmail.com ---
Created attachment 81511
-- https://bugs.freedesktop.org/attachment.cgi?id=81511action=edit
output of /usr/lib64/glinfo
--
You are receiving this mail because:
You are the assignee
The other patches look fine though.
Jose
- Original Message -
Several components are never expected to be built with MSVC (glx, most dri
drivers), so this would put (most likely undesired) burden on those
maintainers.
I suspect we'll need to do this on a per directory basis...
If allocation fails in intel_miptree_create_layout(), don't proceed to
dereference the miptree. Return an early NULL.
Fixes static analysis error reported by Klocwork.
Note: This is a candidate for the 9.1 branch.
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
https://bugs.freedesktop.org/show_bug.cgi?id=66213
Andy Furniss adf.li...@gmail.com changed:
What|Removed |Added
Attachment #81483|text/plain |image/png
https://bugs.freedesktop.org/show_bug.cgi?id=66213
--- Comment #6 from Jesus Cortez jesus.corte...@gmail.com ---
I am on Scientific Linux 6.3. How can I install the 9.1 version? I'm not able
to find that on the Add/Remove software, and trying to compile the source
results in errors such as
Patches 1 and 4 are
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
For patch 3, I share Jose's concern. I would very much like to see this
happen in directories containing code that will be built with MSVC.
For patch 2, I think this is unnecessary if patch 3 is re-done. Right?
On
On 06/26/2013 02:42 PM, Chad Versace wrote:
If allocation fails in intel_miptree_create_layout(), don't proceed to
dereference the miptree. Return an early NULL.
Fixes static analysis error reported by Klocwork.
Note: This is a candidate for the 9.1 branch.
Signed-off-by: Chad Versace
On Tue, Jun 25, 2013 at 10:27 AM, Paul Berry stereotype...@gmail.com wrote:
On 19 June 2013 19:45, Anuj Phogat anuj.pho...@gmail.com wrote:
Current implementation of ext_framebuffer_multisample_blit_scaled in
i965/blorp uses nearest filtering for multisample scaled blits. Using
nearest
On 06/26/2013 02:57 PM, Ian Romanick wrote:
On 06/26/2013 02:42 PM, Chad Versace wrote:
If allocation fails in intel_miptree_create_layout(), don't proceed to
dereference the miptree. Return an early NULL.
Fixes static analysis error reported by Klocwork.
Note: This is a candidate for the 9.1
On Wed, Jun 26, 2013 at 2:42 PM, Chad Versace
chad.vers...@linux.intel.com wrote:
If allocation fails in intel_miptree_create_layout(), don't proceed to
dereference the miptree. Return an early NULL.
Fixes static analysis error reported by Klocwork.
Note: This is a candidate for the 9.1
On 06/26/2013 03:56 PM, Ian Romanick wrote:
Patches 1 and 4 are
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
For patch 3, I share Jose's concern. I would very much like to see this
happen in directories containing code that will be built with MSVC.
Yeah, sounds good, but off-hand I
From: Roland Scheidegger srol...@vmware.com
If there are queries active the opaque optimization reseting the bin needs to
be disabled.
(Not really tested since the bug was discovered by code inspection not
an actual test failure.)
---
src/gallium/drivers/llvmpipe/lp_query.c |2 ++
Brian Paul bri...@vmware.com writes:
On 06/26/2013 03:56 PM, Ian Romanick wrote:
Patches 1 and 4 are
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
For patch 3, I share Jose's concern. I would very much like to see this
happen in directories containing code that will be built with
On 06/26/2013 04:33 PM, Eric Anholt wrote:
Brian Paul bri...@vmware.com writes:
On 06/26/2013 03:56 PM, Ian Romanick wrote:
Patches 1 and 4 are
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
For patch 3, I share Jose's concern. I would very much like to see this
happen in directories
On 26 June 2013 14:57, Anuj Phogat anuj.pho...@gmail.com wrote:
On Tue, Jun 25, 2013 at 10:27 AM, Paul Berry stereotype...@gmail.com
wrote:
This seems like a lot of work to accomplish what is effectively a lookup
table. If this winds up becoming a performance bottleneck, you might
want
From: Roland Scheidegger srol...@vmware.com
This was just ignored (unless for some reason like unfilled polys draw was
handling this).
I'm not convinced of that code, putting the float for the clamp in the key
isn't really a good idea. Then again the other floats for depth bias are
already in
On Tue, Jun 25, 2013 at 10:27 AM, Paul Berry stereotype...@gmail.com wrote:
On 19 June 2013 19:45, Anuj Phogat anuj.pho...@gmail.com wrote:
Current implementation of ext_framebuffer_multisample_blit_scaled in
i965/blorp uses nearest filtering for multisample scaled blits. Using
nearest
Current implementation of ext_framebuffer_multisample_blit_scaled in
i965/blorp uses nearest filtering for multisample scaled blits. Using
nearest filtering produces blocky artifacts and negates the benefits
of MSAA. That is the reason why extension was not enabled on i965.
This patch implements
64 matches
Mail list logo
