Re: [Mesa-dev] [PATCHv2 1/3] omx: query driver encode capatibility earlier
Am 16.02.2014 21:55, schrieb Emil Velikov: On 16/02/14 15:52, Christian König wrote: Am 16.02.2014 13:53, schrieb Emil Velikov: On 16/02/14 10:20, Christian König wrote: Am 15.02.2014 20:35, schrieb Emil Velikov: Query of the driver support AVC_HIGH encode before reporting the total number of supported components. v2: drop if (name_specific_length) check I considered this as well, but as far as I understand it that's not necessary correct. Hi Christian I'm not sure I see your concern. If you consider this an individual project one will not implement nor advertise an encoder (second component) if they know it is not going to work (would that be missing hardware capability or other reason). Same thing here - there is no point in saying we have two components only to die later after realising that is not the case. As far as I understood it the number of components and the name of them should be statically and never change without rebulding the component registry. Actually that we concatenate the component name and have dynamically specific names/roles is already quite questionable See for example the .omxregister file that the bellagio loader builds up while loading the library. Not sure if it was bellagios caching or that of gstreamer, but while working on the code I had to clear and rebuild them a couple of times to make it work. I suspect that this may even help with the following bug https://bugs.freedesktop.org/show_bug.cgi?id=74944 Actually to fix this bug we shouldn't check at all while being queried for available components, but rather fail while creating them. To be honest I don't have much experience with applications using this interface (except for gstreamer), so I can't really judge what's the right approach here. Anyway, the proper fix for this bug is probably to use the pipe loader instead. Have you checked the spec on how exactly we should do it? I have skimmed through the openmax IL 1.1.2 spec and it does not seem to cover this topic. Or perhaps I should be looking at the libomxil-bellagio documentation ? I couldn't find anything clear on this topic either. So to put things mildly - it's rather messy. We have do to either one of the following two - Shout I can do everything and fail a handful of times. Then hope that everyone can pick up the pieces. - Have to constantly redo the cache(re-register). And scratch our heads how do we control this, considering mesa changes, user switching between two codecs. Actually it's not so unorthodox what the bellagio loader does here. It needs to know which component can be found in which library (independent of weather or not the component is available), cause otherwise it would need to load every library and check what's support at the moment when an application request a component. Thinking this thought to the end it suddenly looks like option 1 makes allot of sense. BTW: I took a look at the loader implementation. omx_component_library_Setup is supposed to never fail! So we should never return OMX_ErrorInsufficientResources from it (the bellagio sample source code is probably not up to date any more). We could also cleanup/drop all the caching mess in bellagio ... I'd rather not. I will go with option 1 (+ pipe-fication of omx) some time this week and add some comments along the way about the (imho) unorthodox behaviour. Thx allot for this. I'm currently working on hammering out all the remaining bugs and missing features in the H264 decoder, so when you could do the cleanup and pipe-fication that would be great. Christian. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] targets/vdpau: Don't link unused libraries
libvdpau, libselinux and libexpat are not used. Signed-off-by: Kusanagi Kouichi sl...@ac.auone-net.jp --- configure.ac | 2 +- src/gallium/Automake.inc | 6 +- src/gallium/targets/r600/vdpau/Makefile.am | 1 - src/gallium/targets/radeonsi/vdpau/Makefile.am | 1 - src/gallium/targets/vdpau-nouveau/Makefile.am | 1 - 5 files changed, 6 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index 00a0eaa..17a51af 100644 --- a/configure.ac +++ b/configure.ac @@ -1320,7 +1320,7 @@ fi AM_CONDITIONAL(HAVE_ST_XVMC, test x$enable_xvmc = xyes) if test x$enable_vdpau = xyes; then -PKG_CHECK_MODULES([VDPAU], [vdpau = 0.4.1 x11-xcb xcb-dri2 = 1.8]) +PKG_CHECK_MODULES([VDPAU], [vdpau = 0.4.1 x11-xcb xcb-dri2 = 1.8], [VDPAU_LIBS=`$PKG_CONFIG --libs x11-xcb xcb-dri2`]) GALLIUM_STATE_TRACKERS_DIRS=$GALLIUM_STATE_TRACKERS_DIRS vdpau fi AM_CONDITIONAL(HAVE_ST_VDPAU, test x$enable_vdpau = xyes) diff --git a/src/gallium/Automake.inc b/src/gallium/Automake.inc index fec69cc..1acc99e 100644 --- a/src/gallium/Automake.inc +++ b/src/gallium/Automake.inc @@ -78,7 +78,11 @@ GALLIUM_VDPAU_LIB_DEPS = \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ $(top_builddir)/src/gallium/state_trackers/vdpau/libvdpautracker.la \ $(VDPAU_LIBS) \ - $(LIBDRM_LIBS) + $(LIBDRM_LIBS) \ + -lm \ + $(CLOCK_LIB) \ + $(PTHREAD_LIBS) \ + $(DLOPEN_LIBS) GALLIUM_XVMC_LIB_DEPS = \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ diff --git a/src/gallium/targets/r600/vdpau/Makefile.am b/src/gallium/targets/r600/vdpau/Makefile.am index 7f43fbb..c5103bd 100644 --- a/src/gallium/targets/r600/vdpau/Makefile.am +++ b/src/gallium/targets/r600/vdpau/Makefile.am @@ -41,7 +41,6 @@ libvdpau_r600_la_LIBADD = \ $(top_builddir)/src/gallium/drivers/r600/libr600.la \ $(top_builddir)/src/gallium/winsys/radeon/drm/libradeonwinsys.la \ $(GALLIUM_VDPAU_LIB_DEPS) \ - $(GALLIUM_DRI_LIB_DEPS) \ $(RADEON_LIBS) if HAVE_MESA_LLVM diff --git a/src/gallium/targets/radeonsi/vdpau/Makefile.am b/src/gallium/targets/radeonsi/vdpau/Makefile.am index 0292b2b..54d65b3 100644 --- a/src/gallium/targets/radeonsi/vdpau/Makefile.am +++ b/src/gallium/targets/radeonsi/vdpau/Makefile.am @@ -42,7 +42,6 @@ libvdpau_radeonsi_la_LIBADD = \ $(top_builddir)/src/gallium/drivers/radeonsi/libradeonsi.la \ $(top_builddir)/src/gallium/winsys/radeon/drm/libradeonwinsys.la \ $(GALLIUM_VDPAU_LIB_DEPS) \ - $(GALLIUM_DRI_LIB_DEPS) \ $(RADEON_LIBS) if HAVE_MESA_LLVM diff --git a/src/gallium/targets/vdpau-nouveau/Makefile.am b/src/gallium/targets/vdpau-nouveau/Makefile.am index fbaad03..3cdf103 100644 --- a/src/gallium/targets/vdpau-nouveau/Makefile.am +++ b/src/gallium/targets/vdpau-nouveau/Makefile.am @@ -42,7 +42,6 @@ libvdpau_nouveau_la_LIBADD = \ $(top_builddir)/src/gallium/winsys/nouveau/drm/libnouveaudrm.la \ $(top_builddir)/src/gallium/drivers/nouveau/libnouveau.la \ $(GALLIUM_VDPAU_LIB_DEPS) \ - $(GALLIUM_DRI_LIB_DEPS) \ $(NOUVEAU_LIBS) if HAVE_MESA_LLVM -- 1.9.0.rc3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 75083] New: [IVB/HSW bisected]padman and Smokin-Guns performance reduced ~10%
https://bugs.freedesktop.org/show_bug.cgi?id=75083 Priority: medium Bug ID: 75083 Assignee: mesa-dev@lists.freedesktop.org Summary: [IVB/HSW bisected]padman and Smokin-Guns performance reduced ~10% Severity: normal Classification: Unclassified OS: All Reporter: jinxianx@intel.com Hardware: Other Status: NEW Version: unspecified Component: Other Product: Mesa Created attachment 94200 -- https://bugs.freedesktop.org/attachment.cgi?id=94200action=edit xorg.0.log on commit d8c7740ddabeb456243e40dc3cf0e86c7fca09d0 Platform: IVB/HSW Mesa: (10.1)git-62a3588 Xserver: xorg-server-1.14.5 Xf86_video_intel: (master)2.99.910-3 git-5142d1c Cairo: (master)git-4144307 Kernel:(drm-intel-nightly) efb4a6a66f8de821515c8a2a5571d9ebc251dbd5 Bug detailed description: -- Padman and Smokin-Guns performance reduced ~10% on IVB/HSW. The problem exists on both Raw X and gnome-session. Please see the Xorg.0.log. The bug exist on Mesa 10.1 and master branch,not on Mesa 10.0 branch. It’s a Mesa regression, bisecting show that the first bad commit is: d8c7740ddabeb456243e40dc3cf0e86c7fca09d0 Author: Kenneth Graunke kenn...@whitecape.org Date: Wed Jan 15 10:08:38 2014 -0800 i965: Support 32 texture image units on Haswell+. Performance git- 5a51a26 git- d8c7740 padman263.33 239.1 Smokin-Guns189.97 175.1 Reproduce steps: - 1, xinit 2, vblank_mode=0 ./smokinguns.x86_64 +set r_fullscreen 1 +timedemo 1 +set demodone quit +set demoloop1 demo pts; set nextdemo vstr demodone +vstr demoloop1 +set r_customwidth 1920 +set r_customheight 1080 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Add locking to builtin_builder singleton
On Tue, Feb 11, 2014 at 4:27 PM, Kenneth Graunke kenn...@whitecape.org wrote:
On 02/07/2014 03:29 AM, Daniel Kurtz wrote:
Consider a multithreaded program with two contexts A and B, and the
following scenario:
1. Context A calls initialize(), which allocates mem_ctx and starts
building built-ins.
2. Context B calls initialize(), which sees mem_ctx != NULL and assumes
everything is already set up. It returns.
3. Context B calls find(), which fails to find the built-in since it
hasn't been created yet.
4. Context A finally finishes initializing the built-ins.
This will break at step 3. Adding a lock ensures that subsequent
callers of initialize() will wait until initialization is actually
complete.
Similarly, if any thread calls release while another thread is still
initializing, or calling find(), the mem_ctx/shader would get free'd while
from under it, leading to corruption or use-after-free crashes.
Fixes sporadic failures in Piglit's glx-multithread-shader-compile as
reported in:
https://bugs.freedesktop.org/69200
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Daniel Kurtz djku...@chromium.org
---
src/glsl/builtin_functions.cpp | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index aeb8e5d..2162baa 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -4100,6 +4100,7 @@ builtin_builder::_mid3(const glsl_type *type)
/* The singleton instance of builtin_builder. */
static builtin_builder builtins;
+_glthread_DECLARE_STATIC_MUTEX(builtins_lock);
/**
* External API (exposing the built-in module to the rest of the compiler):
@@ -4108,20 +4109,28 @@ static builtin_builder builtins;
void
_mesa_glsl_initialize_builtin_functions()
{
+ _glthread_LOCK_MUTEX(builtins_lock);
builtins.initialize();
+ _glthread_UNLOCK_MUTEX(builtins_lock);
}
void
_mesa_glsl_release_builtin_functions()
{
+ _glthread_LOCK_MUTEX(builtins_lock);
builtins.release();
+ _glthread_UNLOCK_MUTEX(builtins_lock);
}
ir_function_signature *
_mesa_glsl_find_builtin_function(_mesa_glsl_parse_state *state,
const char *name, exec_list
*actual_parameters)
{
- return builtins.find(state, name, actual_parameters);
+ ir_function_signature * s;
+ _glthread_LOCK_MUTEX(builtins_lock);
+ s = builtins.find(state, name, actual_parameters);
+ _glthread_UNLOCK_MUTEX(builtins_lock);
+ return s;
}
gl_shader *
This looks good to me.
Locking around initialize() and release() is definitely necessary to
prevent multiple threads from trying to create/tear down the data.
Locking around find() prevents a second thread from calling release()
and wrecking data that's in use.
We definitely do need more locking. I believe the hash table usage in
glsl_types.cpp for creating new array or record types needs a similar
treatment. Would you like to cook up a patch for that, Daniel?
In the meantime, I think we can push this. Even if it's not complete, I
believe everything here is necessary. Thanks for the patch!
Hi Ken,
Thanks for taking a look at this patch.
I don't have rights to push to mesa, though, so hope someone with
rights can push.
I don't think I'll get a chance to write the follow on patch anytime soon.
I did the first one to fix a crash while doing full testing piglit
runs on some test hardware.
It would take a bit of effort to context switch back and expand this.
-Dan
--Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 75083] [IVB/HSW bisected]padman and Smokin-Guns performance reduced ~10%
https://bugs.freedesktop.org/show_bug.cgi?id=75083 meng mengmeng.m...@intel.com changed: What|Removed |Added CC||mengmeng.m...@intel.com -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 75083] [IVB/HSW bisected]padman and Smokin-Guns performance reduced ~10%
https://bugs.freedesktop.org/show_bug.cgi?id=75083 meng mengmeng.m...@intel.com changed: What|Removed |Added CC||eero.t.tammi...@intel.com, ||jianx.z...@intel.com -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 75083] [IVB/HSW bisected]padman and Smokin-Guns performance reduced ~10%
https://bugs.freedesktop.org/show_bug.cgi?id=75083 meng mengmeng.m...@intel.com changed: What|Removed |Added Severity|normal |major Priority|medium |high -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 75083] [IVB/HSW bisected]padman and Smokin-Guns performance reduced ~10%
https://bugs.freedesktop.org/show_bug.cgi?id=75083 meng mengmeng.m...@intel.com changed: What|Removed |Added Hardware|Other |All OS|All |Linux (All) Assignee|mesa-dev@lists.freedesktop. |i...@freedesktop.org |org | QA Contact||intel-3d-bugs@lists.freedes ||ktop.org Version|unspecified |git Component|Other |Drivers/DRI/i965 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 75098] New: OpenGL ES2 with fbdev - link error
https://bugs.freedesktop.org/show_bug.cgi?id=75098 Priority: medium Bug ID: 75098 Assignee: mesa-dev@lists.freedesktop.org Summary: OpenGL ES2 with fbdev - link error Severity: normal Classification: Unclassified OS: All Reporter: christian.procha...@genode-labs.com Hardware: Other Status: NEW Version: 10.0 Component: EGL Product: Mesa I've built Mesa 10.0.3 for using OpenGL ES 2 on fbdev with the following configuration: ./configure --enable-gles2 --disable-dri --enable-gallium-egl --with-egl-platforms=fbdev --with-gallium-drivers=swrast When I tried to build the 'es2gears' example (from the mesa-demos archive) using the command gcc -o es2gears es2gears.c ../eglut/eglut_screen.c ../eglut/eglut.c -I../eglut -lGLESv2 -lEGL -lm the following link error occured: /usr/local/lib/libGLESv2.so: undefined reference to `_glapi_Dispatch' /usr/local/lib/libGLESv2.so: undefined reference to `_glapi_get_dispatch' collect2: error: ld returned 1 exit status I could finally get it to work by adding the '--enable-shared-glapi' configure option (which made libGLESv2.so link with libglapi.so.0, which contains the missing symbols), but only after editing the configure script to not make this option depend on DRI (Shared GLAPI is only useful for DRI, disabling). Is this the correct solution or is the real problem somewhere else? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 75098] OpenGL ES2 with fbdev - link error
https://bugs.freedesktop.org/show_bug.cgi?id=75098 --- Comment #1 from Emil Velikov emil.l.veli...@gmail.com --- Created attachment 94216 -- https://bugs.freedesktop.org/attachment.cgi?id=94216action=edit mapi/es2api: unconditionaly link against glapi/glapi.la Hi Christian, thanks for the report. I must admit that these are rather unusual configure flags, which are not tested too often. * Are you able to use the libGLESv2.so library, (eg. use a precompiled es2gears)? I'm assuming that is not the case. With that said, the attached patch should help, although I'm not sure if it's the correct solution as the api dispatch is out of my current scope :-) -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] targets/vdpau: Don't link unused libraries
On 17/02/14 08:29, Kusanagi Kouichi wrote: libvdpau, libselinux and libexpat are not used. Nice catch, I'm a bit unsure about libexpat but considering that you've tested the resulting libraries the patch is Reviewed-by: Emil Velikov emil.l.veli...@gmail.com I'll push this and any other pending patches of yours later on today. -Emil Signed-off-by: Kusanagi Kouichi sl...@ac.auone-net.jp --- configure.ac | 2 +- src/gallium/Automake.inc | 6 +- src/gallium/targets/r600/vdpau/Makefile.am | 1 - src/gallium/targets/radeonsi/vdpau/Makefile.am | 1 - src/gallium/targets/vdpau-nouveau/Makefile.am | 1 - 5 files changed, 6 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index 00a0eaa..17a51af 100644 --- a/configure.ac +++ b/configure.ac @@ -1320,7 +1320,7 @@ fi AM_CONDITIONAL(HAVE_ST_XVMC, test x$enable_xvmc = xyes) if test x$enable_vdpau = xyes; then -PKG_CHECK_MODULES([VDPAU], [vdpau = 0.4.1 x11-xcb xcb-dri2 = 1.8]) +PKG_CHECK_MODULES([VDPAU], [vdpau = 0.4.1 x11-xcb xcb-dri2 = 1.8], [VDPAU_LIBS=`$PKG_CONFIG --libs x11-xcb xcb-dri2`]) GALLIUM_STATE_TRACKERS_DIRS=$GALLIUM_STATE_TRACKERS_DIRS vdpau fi AM_CONDITIONAL(HAVE_ST_VDPAU, test x$enable_vdpau = xyes) diff --git a/src/gallium/Automake.inc b/src/gallium/Automake.inc index fec69cc..1acc99e 100644 --- a/src/gallium/Automake.inc +++ b/src/gallium/Automake.inc @@ -78,7 +78,11 @@ GALLIUM_VDPAU_LIB_DEPS = \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ $(top_builddir)/src/gallium/state_trackers/vdpau/libvdpautracker.la \ $(VDPAU_LIBS) \ - $(LIBDRM_LIBS) + $(LIBDRM_LIBS) \ + -lm \ + $(CLOCK_LIB) \ + $(PTHREAD_LIBS) \ + $(DLOPEN_LIBS) GALLIUM_XVMC_LIB_DEPS = \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ diff --git a/src/gallium/targets/r600/vdpau/Makefile.am b/src/gallium/targets/r600/vdpau/Makefile.am index 7f43fbb..c5103bd 100644 --- a/src/gallium/targets/r600/vdpau/Makefile.am +++ b/src/gallium/targets/r600/vdpau/Makefile.am @@ -41,7 +41,6 @@ libvdpau_r600_la_LIBADD = \ $(top_builddir)/src/gallium/drivers/r600/libr600.la \ $(top_builddir)/src/gallium/winsys/radeon/drm/libradeonwinsys.la \ $(GALLIUM_VDPAU_LIB_DEPS) \ - $(GALLIUM_DRI_LIB_DEPS) \ $(RADEON_LIBS) if HAVE_MESA_LLVM diff --git a/src/gallium/targets/radeonsi/vdpau/Makefile.am b/src/gallium/targets/radeonsi/vdpau/Makefile.am index 0292b2b..54d65b3 100644 --- a/src/gallium/targets/radeonsi/vdpau/Makefile.am +++ b/src/gallium/targets/radeonsi/vdpau/Makefile.am @@ -42,7 +42,6 @@ libvdpau_radeonsi_la_LIBADD = \ $(top_builddir)/src/gallium/drivers/radeonsi/libradeonsi.la \ $(top_builddir)/src/gallium/winsys/radeon/drm/libradeonwinsys.la \ $(GALLIUM_VDPAU_LIB_DEPS) \ - $(GALLIUM_DRI_LIB_DEPS) \ $(RADEON_LIBS) if HAVE_MESA_LLVM diff --git a/src/gallium/targets/vdpau-nouveau/Makefile.am b/src/gallium/targets/vdpau-nouveau/Makefile.am index fbaad03..3cdf103 100644 --- a/src/gallium/targets/vdpau-nouveau/Makefile.am +++ b/src/gallium/targets/vdpau-nouveau/Makefile.am @@ -42,7 +42,6 @@ libvdpau_nouveau_la_LIBADD = \ $(top_builddir)/src/gallium/winsys/nouveau/drm/libnouveaudrm.la \ $(top_builddir)/src/gallium/drivers/nouveau/libnouveau.la \ $(GALLIUM_VDPAU_LIB_DEPS) \ - $(GALLIUM_DRI_LIB_DEPS) \ $(NOUVEAU_LIBS) if HAVE_MESA_LLVM ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/10] Klocwork related pathes
Resend of the earlier glx patches with the issue pointed out by Petri fixed. Patch number five is a bit special. hash_table_insert() and hash_table_replace() don't really have a way to report errors and I did not want to go changing the api since these are called from so many places thus the case of null (c)allocation is handled just inside the functions and relied low memory situation is handled outside the function properly. Patch number eight is not from Klocwork. There was two nested for loops running against table eventually doing an assert in check_symbol_table(), this was included also for optimized builds. Now these loops will run only on debug builds where assert could matter. Juha-Pekka Heikkila (10): glx: Add extra null check in __glXClientInfo glx: add extra null check in getFBConfigs glx: add missing null check in SendMakeCurrentRequest egl: Unhide functionality in _eglInitSync() mesa: Add missing null checks into prog_hash_table.c mesa: Prevent negative indexing on noise2, noise3 and noise4 mesa: Add missing null check in _mesa_parse_arb_program() mesa: remove redundant running of check_symbol_table() mesa: add null checks for callocs in symbol_table.c mesa: add missing null checks in _tnl_register_fastpath() src/egl/main/eglsync.c | 3 ++- src/glx/glxcmds.c | 13 +++- src/glx/glxext.c | 3 ++- src/glx/indirect_glx.c | 2 +- src/mesa/program/prog_hash_table.c | 16 +-- src/mesa/program/prog_noise.c | 18 - src/mesa/program/program_parse.y | 5 + src/mesa/program/symbol_table.c| 28 ++ src/mesa/tnl/t_vertex.c| 41 ++ 9 files changed, 85 insertions(+), 44 deletions(-) -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/10] egl: Unhide functionality in _eglInitSync()
_eglInitResource() was used to memset entire _EGLSync by writing more than size of pointed target. This does work as long as Resource is the first element in _EGLSync, this patch fixes such dependency. Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com --- src/egl/main/eglsync.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/egl/main/eglsync.c b/src/egl/main/eglsync.c index 9d0067c..ba8a32f 100644 --- a/src/egl/main/eglsync.c +++ b/src/egl/main/eglsync.c @@ -75,7 +75,8 @@ _eglInitSync(_EGLSync *sync, _EGLDisplay *dpy, EGLenum type, !(type == EGL_SYNC_FENCE_KHR dpy-Extensions.KHR_fence_sync)) return _eglError(EGL_BAD_ATTRIBUTE, eglCreateSyncKHR); - _eglInitResource(sync-Resource, sizeof(*sync), dpy); + memset(sync, 0, sizeof(_EGLSync)); + _eglInitResource(sync-Resource, sizeof(_EGLResource), dpy); sync-Type = type; sync-SyncStatus = EGL_UNSIGNALED_KHR; sync-SyncCondition = EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR; -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/10] glx: Add extra null check in __glXClientInfo
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/glx/glxcmds.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 38a5262..4d8d0c2 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -1392,13 +1392,16 @@ void
__glXClientInfo(Display * dpy, int opcode)
{
char *ext_str = __glXGetClientGLExtensionString();
- int size = strlen(ext_str) + 1;
- xcb_connection_t *c = XGetXCBConnection(dpy);
- xcb_glx_client_info(c,
- GLX_MAJOR_VERSION, GLX_MINOR_VERSION, size, ext_str);
+ if (ext_str) {
+ int size = strlen(ext_str) + 1;
- free(ext_str);
+ xcb_connection_t *c = XGetXCBConnection(dpy);
+ xcb_glx_client_info(c, GLX_MAJOR_VERSION, GLX_MINOR_VERSION, size,
+ ext_str);
+
+ free(ext_str);
+ }
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/10] glx: add missing null check in SendMakeCurrentRequest
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/glx/indirect_glx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glx/indirect_glx.c b/src/glx/indirect_glx.c
index 28b8cd0..306bf5b 100644
--- a/src/glx/indirect_glx.c
+++ b/src/glx/indirect_glx.c
@@ -84,7 +84,7 @@ SendMakeCurrentRequest(Display * dpy, CARD8 opcode,
* not the SGI extension.
*/
- if ((priv-majorVersion 1) || (priv-minorVersion = 3)) {
+ if (priv ((priv-majorVersion 1) || (priv-minorVersion = 3))) {
xGLXMakeContextCurrentReq *req;
GetReq(GLXMakeContextCurrent, req);
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/10] mesa: Add missing null checks into prog_hash_table.c
Check calloc return values in hash_table_insert() and
hash_table_replace()
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/program/prog_hash_table.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/mesa/program/prog_hash_table.c
b/src/mesa/program/prog_hash_table.c
index f45ed46..e62ad6f 100644
--- a/src/mesa/program/prog_hash_table.c
+++ b/src/mesa/program/prog_hash_table.c
@@ -143,10 +143,12 @@ hash_table_insert(struct hash_table *ht, void *data,
const void *key)
node = calloc(1, sizeof(*node));
-node-data = data;
-node-key = key;
+if (node != NULL) {
+node-data = data;
+node-key = key;
-insert_at_head( ht-buckets[bucket], node-link);
+insert_at_head( ht-buckets[bucket], node-link);
+}
}
bool
@@ -168,10 +170,12 @@ hash_table_replace(struct hash_table *ht, void *data,
const void *key)
hn = calloc(1, sizeof(*hn));
-hn-data = data;
-hn-key = key;
+if (hn != NULL) {
+hn-data = data;
+hn-key = key;
-insert_at_head( ht-buckets[bucket], hn-link);
+insert_at_head( ht-buckets[bucket], hn-link);
+}
return false;
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/10] glx: add extra null check in getFBConfigs
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/glx/glxext.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/glx/glxext.c b/src/glx/glxext.c
index 4a195bd..837c5b0 100644
--- a/src/glx/glxext.c
+++ b/src/glx/glxext.c
@@ -686,7 +686,8 @@ static GLboolean
fb_req-glxCode = X_GLXGetFBConfigs;
fb_req-screen = screen;
}
- else if (strstr(psc-serverGLXexts, GLX_SGIX_fbconfig) != NULL) {
+ else if (psc-serverGLXexts != NULL
+strstr(psc-serverGLXexts, GLX_SGIX_fbconfig) != NULL) {
GetReqExtra(GLXVendorPrivateWithReply,
sz_xGLXGetFBConfigsSGIXReq -
sz_xGLXVendorPrivateWithReplyReq, vpreq);
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/10] mesa: add null checks for callocs in symbol_table.c
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/program/symbol_table.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/src/mesa/program/symbol_table.c b/src/mesa/program/symbol_table.c
index 64e24d8..df1ec5c 100644
--- a/src/mesa/program/symbol_table.c
+++ b/src/mesa/program/symbol_table.c
@@ -188,9 +188,11 @@ _mesa_symbol_table_push_scope(struct _mesa_symbol_table
*table)
{
struct scope_level *const scope = calloc(1, sizeof(*scope));
-scope-next = table-current_scope;
-table-current_scope = scope;
-table-depth++;
+if (scope) {
+scope-next = table-current_scope;
+table-current_scope = scope;
+table-depth++;
+}
}
@@ -338,6 +340,11 @@ _mesa_symbol_table_add_symbol(struct _mesa_symbol_table
*table,
if (hdr == NULL) {
hdr = calloc(1, sizeof(*hdr));
+
+ if (hdr == NULL) {
+ return -1;
+ }
+
hdr-name = strdup(name);
hash_table_insert(table-ht, hdr, hdr-name);
@@ -360,6 +367,11 @@ _mesa_symbol_table_add_symbol(struct _mesa_symbol_table
*table,
return -1;
sym = calloc(1, sizeof(*sym));
+
+if (sym == NULL) {
+return -1;
+}
+
sym-next_with_same_name = hdr-symbols;
sym-next_with_same_scope = table-current_scope-symbols;
sym-hdr = hdr;
@@ -395,6 +407,10 @@ _mesa_symbol_table_add_global_symbol(struct
_mesa_symbol_table *table,
if (hdr == NULL) {
hdr = calloc(1, sizeof(*hdr));
+if (hdr == NULL) {
+return -1;
+}
+
hdr-name = strdup(name);
hash_table_insert(table-ht, hdr, hdr-name);
@@ -424,6 +440,10 @@ _mesa_symbol_table_add_global_symbol(struct
_mesa_symbol_table *table,
}
sym = calloc(1, sizeof(*sym));
+if (sym == NULL) {
+return -1;
+}
+
sym-next_with_same_scope = top_scope-symbols;
sym-hdr = hdr;
sym-name_space = name_space;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/10] mesa: remove redundant running of check_symbol_table()
Nested for loops running through tables against which they
finally do an assert were ran also with optimized builds.
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/program/symbol_table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/program/symbol_table.c b/src/mesa/program/symbol_table.c
index 4f6f31f..64e24d8 100644
--- a/src/mesa/program/symbol_table.c
+++ b/src/mesa/program/symbol_table.c
@@ -133,7 +133,7 @@ struct _mesa_symbol_table_iterator {
static void
check_symbol_table(struct _mesa_symbol_table *table)
{
-#if 1
+#if !defined(NDEBUG)
struct scope_level *scope;
for (scope = table-current_scope; scope != NULL; scope = scope-next) {
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/10] mesa: add missing null checks in _tnl_register_fastpath()
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/tnl/t_vertex.c | 41 -
1 file changed, 24 insertions(+), 17 deletions(-)
diff --git a/src/mesa/tnl/t_vertex.c b/src/mesa/tnl/t_vertex.c
index b3deac0..a122334 100644
--- a/src/mesa/tnl/t_vertex.c
+++ b/src/mesa/tnl/t_vertex.c
@@ -81,24 +81,31 @@ void _tnl_register_fastpath( struct tnl_clipspace *vtx,
GLboolean match_strides )
{
struct tnl_clipspace_fastpath *fastpath =
CALLOC_STRUCT(tnl_clipspace_fastpath);
- GLuint i;
-
- fastpath-vertex_size = vtx-vertex_size;
- fastpath-attr_count = vtx-attr_count;
- fastpath-match_strides = match_strides;
- fastpath-func = vtx-emit;
- fastpath-attr =
- malloc(vtx-attr_count * sizeof(fastpath-attr[0]));
-
- for (i = 0; i vtx-attr_count; i++) {
- fastpath-attr[i].format = vtx-attr[i].format;
- fastpath-attr[i].stride = vtx-attr[i].inputstride;
- fastpath-attr[i].size = vtx-attr[i].inputsize;
- fastpath-attr[i].offset = vtx-attr[i].vertoffset;
- }
- fastpath-next = vtx-fastpath;
- vtx-fastpath = fastpath;
+ if (fastpath != NULL) {
+ GLuint i;
+
+ fastpath-vertex_size = vtx-vertex_size;
+ fastpath-attr_count = vtx-attr_count;
+ fastpath-match_strides = match_strides;
+ fastpath-func = vtx-emit;
+ fastpath-attr = malloc(vtx-attr_count * sizeof(fastpath-attr[0]));
+
+ if (fastpath-attr == NULL) {
+ FREE(fastpath);
+ return;
+ }
+
+ for (i = 0; i vtx-attr_count; i++) {
+ fastpath-attr[i].format = vtx-attr[i].format;
+ fastpath-attr[i].stride = vtx-attr[i].inputstride;
+ fastpath-attr[i].size = vtx-attr[i].inputsize;
+ fastpath-attr[i].offset = vtx-attr[i].vertoffset;
+ }
+
+ fastpath-next = vtx-fastpath;
+ vtx-fastpath = fastpath;
+ }
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/10] mesa: Add missing null check in _mesa_parse_arb_program()
Add missing null check in program_parse.tab.c through
program_parse.y
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/program/program_parse.y | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/program/program_parse.y b/src/mesa/program/program_parse.y
index 6dde69d..cfc2cfe 100644
--- a/src/mesa/program/program_parse.y
+++ b/src/mesa/program/program_parse.y
@@ -2749,6 +2749,11 @@ _mesa_parse_arb_program(struct gl_context *ctx, GLenum
target, const GLubyte *st
*/
state-prog-Instructions =
_mesa_alloc_instructions(state-prog-NumInstructions + 1);
+
+ if (state-prog-Instructions == NULL) {
+ goto error;
+ }
+
inst = state-inst_head;
for (i = 0; i state-prog-NumInstructions; i++) {
struct asm_instruction *const temp = inst-next;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/10] mesa: Prevent negative indexing on noise2, noise3 and noise4
% operator could return negative value which would cause indexing before perm table. Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com --- src/mesa/program/prog_noise.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/mesa/program/prog_noise.c b/src/mesa/program/prog_noise.c index c258c5e..12bb4d9 100644 --- a/src/mesa/program/prog_noise.c +++ b/src/mesa/program/prog_noise.c @@ -282,8 +282,8 @@ _mesa_noise2(GLfloat x, GLfloat y) y2 = y0 - 1.0f + 2.0f * G2; /* Wrap the integer indices at 256, to avoid indexing perm[] out of bounds */ - ii = i % 256; - jj = j % 256; + ii = abs(i % 256); + jj = abs(j % 256); /* Calculate the contribution from the three corners */ t0 = 0.5f - x0 * x0 - y0 * y0; @@ -423,9 +423,9 @@ _mesa_noise3(GLfloat x, GLfloat y, GLfloat z) z3 = z0 - 1.0f + 3.0f * G3; /* Wrap the integer indices at 256 to avoid indexing perm[] out of bounds */ - ii = i % 256; - jj = j % 256; - kk = k % 256; + ii = abs(i % 256); + jj = abs(j % 256); + kk = abs(k % 256); /* Calculate the contribution from the four corners */ t0 = 0.6f - x0 * x0 - y0 * y0 - z0 * z0; @@ -573,10 +573,10 @@ _mesa_noise4(GLfloat x, GLfloat y, GLfloat z, GLfloat w) w4 = w0 - 1.0f + 4.0f * G4; /* Wrap the integer indices at 256, to avoid indexing perm[] out of bounds */ - ii = i % 256; - jj = j % 256; - kk = k % 256; - ll = l % 256; + ii = abs(i % 256); + jj = abs(j % 256); + kk = abs(k % 256); + ll = abs(l % 256); /* Calculate the contribution from the five corners */ t0 = 0.6f - x0 * x0 - y0 * y0 - z0 * z0 - w0 * w0; -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 75098] OpenGL ES2 with fbdev - link error
https://bugs.freedesktop.org/show_bug.cgi?id=75098 --- Comment #2 from Christian Prochaska christian.procha...@genode-labs.com --- Hi Emil, (In reply to comment #1) Created attachment 94216 [details] [review] mapi/es2api: unconditionaly link against glapi/glapi.la Hi Christian, thanks for the report. I must admit that these are rather unusual configure flags, which are not tested too often. * Are you able to use the libGLESv2.so library, (eg. use a precompiled es2gears)? I'm assuming that is not the case. When I build es2gears with the 'working' (shared glapi) Mesa installed and then uninstall Mesa and install the non-shared glapi Mesa version and execute the previously built es2gears binary, this error occurs: ./es2gears: symbol lookup error: /usr/local/lib/libGLESv2.so.2: undefined symbol: _glapi_Dispatch With that said, the attached patch should help, although I'm not sure if it's the correct solution as the api dispatch is out of my current scope :-) Unfortunalely, it doesn't build: /bin/bash ../../../libtool --tag=CC --mode=link gcc -fvisibility=hidden -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -version-number 2 -no-undefined -o libGLESv2.la -rpath /usr/local/lib entry.lo -ldrm -lm -lpthread -ldl ../../../src/mapi/glapi/libglapi.la libtool: link: gcc -shared -fPIC -DPIC .libs/entry.o -Wl,--whole-archive ../../../src/mapi/glapi/.libs/libglapi.a -Wl,--no-whole-archive -ldrm -lm -lpthread -ldl -O2 -Wl,-soname -Wl,libGLESv2.so.2 -o .libs/libGLESv2.so.2.0.0 ../../../src/mapi/glapi/.libs/libglapi.a(glapi_x86.o): In function `glCullFace': /home/christian/projects/mesa/mesa/src/mapi/glapi/glapi_x86.S:305: multiple definition of `glCullFace' .libs/entry.o:entry.c:(.text+0x0): first defined here ../../../src/mapi/glapi/.libs/libglapi.a(glapi_x86.o): In function `glFrontFace': /home/christian/projects/mesa/mesa/src/mapi/glapi/glapi_x86.S:310: multiple definition of `glFrontFace' .libs/entry.o:entry.c:(.text+0x20): first defined here ../../../src/mapi/glapi/.libs/libglapi.a(glapi_x86.o): In function `glHint': .libs/entry.o:entry.c:(.text+0x40): first defined here ... -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71870] Metro: Last Light rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=71870 Thomas Rohloff v10la...@myway.de changed: What|Removed |Added Hardware|x86 (IA32) |All OS|Linux (All) |All Assignee|i...@freedesktop.org |mesa-dev@lists.freedesktop. ||org QA Contact|intel-3d-bugs@lists.freedes | |ktop.org| Component|Drivers/DRI/i965|Mesa core -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: add bounds checking to eliminate buffer overrun
Decompressing ETC2 textures was causing intermitent segfault
by copying resulting 4x4 texel block to the destination texture
regardless of the size of the destination texture. Issue found
via application crash in GLBenchmark 3.0's Manhattan test.
v2: add more detail comment. Compute limit outside inner loops.
---
src/mesa/main/texcompress_etc.c | 78 -
1 file changed, 54 insertions(+), 24 deletions(-)
diff --git a/src/mesa/main/texcompress_etc.c b/src/mesa/main/texcompress_etc.c
index e3862be..c0a4191 100644
--- a/src/mesa/main/texcompress_etc.c
+++ b/src/mesa/main/texcompress_etc.c
@@ -679,14 +679,25 @@ etc2_unpack_rgb8(uint8_t *dst_row,
for (y = 0; y height; y += bh) {
const uint8_t *src = src_row;
+ /*
+ * Destination texture may not be a multiple of four texels in
+ * height. Compute a safe height to avoid writing outside the texture.
+ */
+ const unsigned h = MIN2(bh, height - y);
for (x = 0; x width; x+= bw) {
etc2_rgb8_parse_block(block, src,
false /* punchthrough_alpha */);
- for (j = 0; j bh; j++) {
+ /*
+ * Destination texture may not be a multiple of four texels in
+ * width. Compute a safe width to avoid writing outside the texture.
+ */
+ const unsigned w = MIN2(bw, width - x);
+
+ for (j = 0; j h; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps;
-for (i = 0; i bw; i++) {
+for (i = 0; i w; i++) {
etc2_rgb8_fetch_texel(block, i, j, dst,
false /* punchthrough_alpha */);
dst[3] = 255;
@@ -716,14 +727,17 @@ etc2_unpack_srgb8(uint8_t *dst_row,
for (y = 0; y height; y += bh) {
const uint8_t *src = src_row;
+ const unsigned h = MIN2(bh, height - y);
for (x = 0; x width; x+= bw) {
+ const unsigned w = MIN2(bw, width - x);
etc2_rgb8_parse_block(block, src,
false /* punchthrough_alpha */);
- for (j = 0; j bh; j++) {
+
+ for (j = 0; j h; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps;
-for (i = 0; i bw; i++) {
+for (i = 0; i w; i++) {
etc2_rgb8_fetch_texel(block, i, j, dst,
false /* punchthrough_alpha */);
/* Convert to MESA_FORMAT_B8G8R8A8_SRGB */
@@ -760,13 +774,15 @@ etc2_unpack_rgba8(uint8_t *dst_row,
for (y = 0; y height; y += bh) {
const uint8_t *src = src_row;
+ const unsigned h = MIN2(bh, height - y);
for (x = 0; x width; x+= bw) {
+ const unsigned w = MIN2(bw, width - x);
etc2_rgba8_parse_block(block, src);
- for (j = 0; j bh; j++) {
+ for (j = 0; j h; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps;
-for (i = 0; i bw; i++) {
+for (i = 0; i w; i++) {
etc2_rgba8_fetch_texel(block, i, j, dst);
dst += comps;
}
@@ -796,14 +812,16 @@ etc2_unpack_srgb8_alpha8(uint8_t *dst_row,
uint8_t tmp;
for (y = 0; y height; y += bh) {
+ const unsigned h = MIN2(bh, height - y);
const uint8_t *src = src_row;
for (x = 0; x width; x+= bw) {
+ const unsigned w = MIN2(bw, width - x);
etc2_rgba8_parse_block(block, src);
- for (j = 0; j bh; j++) {
+ for (j = 0; j h; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps;
-for (i = 0; i bw; i++) {
+for (i = 0; i w; i++) {
etc2_rgba8_fetch_texel(block, i, j, dst);
/* Convert to MESA_FORMAT_B8G8R8A8_SRGB */
@@ -838,14 +856,16 @@ etc2_unpack_r11(uint8_t *dst_row,
unsigned x, y, i, j;
for (y = 0; y height; y += bh) {
+ const unsigned h = MIN2(bh, height - y);
const uint8_t *src = src_row;
for (x = 0; x width; x+= bw) {
+ const unsigned w = MIN2(bw, width - x);
etc2_r11_parse_block(block, src);
- for (j = 0; j bh; j++) {
+ for (j = 0; j h; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps *
comp_size;
-for (i = 0; i bw; i++) {
+for (i = 0; i w; i++) {
etc2_r11_fetch_texel(block, i, j, dst);
dst += comps * comp_size;
}
@@ -873,16 +893,18 @@ etc2_unpack_rg11(uint8_t *dst_row,
unsigned x, y, i, j;
for (y = 0; y height; y += bh) {
+ const unsigned h = MIN2(bh, height - y);
const uint8_t *src = src_row;
for (x = 0; x width; x+= bw) {
+ const unsigned w = MIN2(bw, width - x);
/* red component */
etc2_r11_parse_block(block, src);
- for (j = 0; j bh; j++) {
+ for (j = 0; j h; j++)
Re: [Mesa-dev] [PATCH] mesa: add bounds checking to eliminate buffer overrun
Thanks for the feedback.
I've updated the patch to integrate Ian's comments.
Courtney
On Fri, Feb 14, 2014 at 2:00 PM, Ian Romanick i...@freedesktop.org wrote:
On 02/14/2014 07:52 AM, Courtney Goeltzenleuchter wrote:
Decompressing ETC2 textures was causing intermitent segfault
by copying resulting 4x4 texel block to the destination texture
regardless of the size of the destination texture. Issue found
via application crash in GLBenchmark 3.0's Manhattan test.
So... the problem is that every ETC texture is (physically) a multiple
of 4 width, but we may have allocated a decompression buffer that was
the logical width of the texture. I think the code needs more of a
comment explaining that. Otherwise, when someone comes back to it in a
year (or uses it as a model for some other texture compression code),
they won't understand why the code is the way it is.
With that, this patch is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
One additional suggestion below that you can take or leave.
Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
Also add:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74988
Cc: 9.2 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/main/texcompress_etc.c | 49
+
1 file changed, 25 insertions(+), 24 deletions(-)
diff --git a/src/mesa/main/texcompress_etc.c
b/src/mesa/main/texcompress_etc.c
index e3862be..f9234b0 100644
--- a/src/mesa/main/texcompress_etc.c
+++ b/src/mesa/main/texcompress_etc.c
@@ -684,9 +684,10 @@ etc2_unpack_rgb8(uint8_t *dst_row,
etc2_rgb8_parse_block(block, src,
false /* punchthrough_alpha */);
Alternately, the code below could be:
const unsigned h = MIN2(bh, height - y);
const unsigned w = MIN2(bw, width - x);
...
for (j = 0; j h; j++) {
...
for (i = 0; i w; i++) {
- for (j = 0; j bh; j++) {
+ /* be sure to stay within the bounds of the texture */
+ for (j = 0; j bh (j+y) height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps;
-for (i = 0; i bw; i++) {
+for (i = 0; i bw (i+x) width; i++) {
etc2_rgb8_fetch_texel(block, i, j, dst,
false /* punchthrough_alpha */);
dst[3] = 255;
@@ -721,9 +722,9 @@ etc2_unpack_srgb8(uint8_t *dst_row,
etc2_rgb8_parse_block(block, src,
false /* punchthrough_alpha */);
- for (j = 0; j bh; j++) {
+ for (j = 0; j bh (j+y) height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps;
-for (i = 0; i bw; i++) {
+for (i = 0; i bw (i+x) width; i++) {
etc2_rgb8_fetch_texel(block, i, j, dst,
false /* punchthrough_alpha */);
/* Convert to MESA_FORMAT_B8G8R8A8_SRGB */
@@ -764,9 +765,9 @@ etc2_unpack_rgba8(uint8_t *dst_row,
for (x = 0; x width; x+= bw) {
etc2_rgba8_parse_block(block, src);
- for (j = 0; j bh; j++) {
+ for (j = 0; j bh (j+y) height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps;
-for (i = 0; i bw; i++) {
+for (i = 0; i bw (i+x) width; i++) {
etc2_rgba8_fetch_texel(block, i, j, dst);
dst += comps;
}
@@ -801,9 +802,9 @@ etc2_unpack_srgb8_alpha8(uint8_t *dst_row,
for (x = 0; x width; x+= bw) {
etc2_rgba8_parse_block(block, src);
- for (j = 0; j bh; j++) {
+ for (j = 0; j bh (j+y) height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps;
-for (i = 0; i bw; i++) {
+for (i = 0; i bw (i+x) width; i++) {
etc2_rgba8_fetch_texel(block, i, j, dst);
/* Convert to MESA_FORMAT_B8G8R8A8_SRGB */
@@ -843,9 +844,9 @@ etc2_unpack_r11(uint8_t *dst_row,
for (x = 0; x width; x+= bw) {
etc2_r11_parse_block(block, src);
- for (j = 0; j bh; j++) {
+ for (j = 0; j bh (j+y) height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps *
comp_size;
-for (i = 0; i bw; i++) {
+for (i = 0; i bw (i+x) width; i++) {
etc2_r11_fetch_texel(block, i, j, dst);
dst += comps * comp_size;
}
@@ -879,10 +880,10 @@ etc2_unpack_rg11(uint8_t *dst_row,
/* red component */
etc2_r11_parse_block(block, src);
- for (j = 0; j bh; j++) {
+ for (j = 0; j bh (j+y) height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride +
x *
Re: [Mesa-dev] [PATCH 16/18] mesa: Implement glBindImageTextures()
On Thursday 13 February 2014, Francisco Jerez wrote:
Fredrik Höglund fred...@kde.org writes:
---
src/mesa/main/shaderimage.c | 164
+++
1 file changed, 164 insertions(+)
diff --git a/src/mesa/main/shaderimage.c b/src/mesa/main/shaderimage.c
index ce63bee..27695a3 100644
--- a/src/mesa/main/shaderimage.c
+++ b/src/mesa/main/shaderimage.c
@@ -33,6 +33,7 @@
#include context.h
#include texobj.h
#include teximage.h
+#include enums.h
/*
* Define endian-invariant aliases for some mesa formats that are
@@ -481,6 +482,169 @@ _mesa_BindImageTexture(GLuint unit, GLuint texture,
GLint level,
void GLAPIENTRY
_mesa_BindImageTextures(GLuint first, GLsizei count, const GLuint
*textures)
{
+ GET_CURRENT_CONTEXT(ctx);
+ int i;
+
+ if (!ctx-Extensions.ARB_shader_image_load_store) {
+ _mesa_error(ctx, GL_INVALID_OPERATION, glBindImageTextures());
+ return;
+ }
+
+ if (first + count ctx-Const.MaxImageUnits) {
+ /* The ARB_multi_bind spec says:
+ *
+ *An INVALID_OPERATION error is generated if first + count
+ * is greater than the number of image units supported by
+ * the implementation.
+ */
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glBindImageTextures(first=%u + count=%u the value of
+ GL_MAX_IMAGE_UNITS=%u),
+ first, count, ctx-Const.MaxImageUnits);
+ return;
+ }
+
+ /* Assume that at least one binding will be changed */
+ FLUSH_VERTICES(ctx, 0);
+ ctx-NewDriverState |= ctx-DriverFlags.NewImageUnits;
+
+ if (!textures) {
+ /* The ARB_multi_bind spec says:
+ *
+ *If textures is NULL, each affected image unit from
+ * first through first+count-1 will be reset to have
+ * no bound texture object.
+ */
+ for (i = 0; i count; i++) {
+ struct gl_image_unit *u = ctx-ImageUnits[first + i];
+
+ u-Level = 0;
+ u-Layered = GL_FALSE;
+ u-Layer = 0;
+ u-Access = GL_READ_ONLY;
+ u-Format = GL_R8;
+ u-_ActualFormat = MESA_FORMAT_R8;
+ u-_Valid = GL_FALSE;
+ _mesa_reference_texobj(u-TexObj, NULL);
+
+ if (ctx-Driver.BindImageTexture)
+ctx-Driver.BindImageTexture(ctx, u, NULL, 0, GL_FALSE,
+ 0, GL_READ_ONLY, GL_R8);
+ }
+
+ return;
+ }
Can't you get rid of the whole block above by declaring 'const GLuint
texture = (textures ? textures[i] : 0);' in the loop below, and then
's/textures[i]/texture/'?
I could, but I thought it might be worth optimizing this case. Note that
the hash table mutex is not locked in this block. I don't know if it
actually makes a difference for any real applications though.
But the actual unbinding code could be moved into a helper function.
+
+ /* Note that the error semantics for multi-bind commands differ from
+* those of other GL commands.
+*
+* The Issues section in the ARB_multi_bind spec says:
+*
+*(11) Typically, OpenGL specifies that if an error is generated by
+* a command, that command has no effect. This is somewhat
+* unfortunate for multi-bind commands, because it would
require
+* a first pass to scan the entire list of bound objects for
+* errors and then a second pass to actually perform the
+* bindings. Should we have different error semantics?
+*
+* RESOLVED: Yes. In this specification, when the parameters for
+* one of the count binding points are invalid, that binding
+* point is not updated and an error will be generated. However,
+* other binding points in the same command will be updated if
+* their parameters are valid and no other error occurs.
+*/
+
+ _mesa_begin_texture_lookups(ctx);
+
+ for (i = 0; i count; i++) {
+ struct gl_image_unit *u = ctx-ImageUnits[first + i];
+
+ if (textures[i] != 0) {
+ struct gl_texture_object *texObj;
+ struct gl_texture_image *image;
+ gl_format actualFormat;
+
+ if (!u-TexObj || u-TexObj-Name != textures[i]) {
+texObj = _mesa_lookup_texture_without_locking(ctx,
textures[i]);
+if (!texObj) {
+ /* The ARB_multi_bind spec says:
+*
+*An INVALID_OPERATION error is generated if any value
+* in textures is not zero or the name of an existing
+* texture object (per binding).
+*/
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glBindImageTextures(textures[%u]=%u
+
[Mesa-dev] [Bug 71870] Metro: Last Light rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=71870 Sven Arvidsson s...@whiz.se changed: What|Removed |Added CC||s...@whiz.se -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 59304] Meta Bug for regressions caused by automake conversion
https://bugs.freedesktop.org/show_bug.cgi?id=59304 Andreas Boll andreas.boll@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71870] Metro: Last Light rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=71870 --- Comment #38 from José Suárez j.suarez.agap...@gmail.com --- I just wanted to give my my 2 cents on this topic. Be warned that I am no programmer nor do i have any knowledge of graphics drivers (so please, forgive me for any inaccuracy or incorrect technical point of view). I also know that the mesa policy is not to fix third programs bugs within mesa's code. I think that is the right choice, but maybe a compromise could be reached, especially in the light that both proprietary drivers seem to be more fault tolerant with this problem. If the __ macro names are reserved for _future_ use, I asume the reservation of certain __ macro names should be explicitly made in a particular GLSL spec version (or subsequent versions if more need to be added). I don't know if that has happened yet, but I presume that once that happens there should be a list (as well as a spec) of those macro names. I also suppose that if no especific __ macro names have been established yet, game programmers may not be too aware of this limitation even though the reservation has been established since long time ago, as Ian pointed out. Therefore, if a compromise is to be reached I think there could be two alternatives for adressing this problem: (i) Only enforce the __ macro reservation beginning from the first GLSL version that establishes any of those macro names. I.e, if program uses GLSL version equal or greater than X.Y (being X.Y the first GLSL version with a reservation for a particular __ macro), then disallow the use of those custom macros. Otherwise, allow the use. Mesa could output a warning instead of failing. (ii) Once the GLSL specs begin expressly reserving certain __ macro names, only disallow the use of them as custom macro names. I believe the second approach is less desirable. Of course not doing anything is also a possibility, but I believe trying to get a third party programmer to change a game's code is quite difficult. There are very collaborative game devs (such as, for instance, The Farm 51, who offered steam keys to mesa devs to sort out some bugs), but I'm sure there will be others who are not so friendly. And if this use of __ macro names comes from using some develoment apps or techniques, I supose they would not be willing to risk messing the code just for satisfying a very small fraction of users who are gaming on Linux with mesa -dont't get me wrong, I wish we were a majority of the gamers- or (if not construed by the game developer that altruisticly) achieving 100% spec compatible code. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73946] scanout broken on radeon SI (OLAND)
https://bugs.freedesktop.org/show_bug.cgi?id=73946 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #12 from Alex Deucher ag...@yahoo.com --- *** This bug has been marked as a duplicate of bug 71488 *** -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71870] Metro: Last Light rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=71870 Vladimir Ysikov granti...@gmail.com changed: What|Removed |Added CC||granti...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] glx: Add extra null check in __glXClientInfo
It looks like this function has been unused since commit 3f0e3a7, so we
should just delete the whole thing.
On 02/14/2014 05:23 AM, Juha-Pekka Heikkila wrote:
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/glx/glxcmds.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 38a5262..4d8d0c2 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -1392,13 +1392,16 @@ void
__glXClientInfo(Display * dpy, int opcode)
{
char *ext_str = __glXGetClientGLExtensionString();
- int size = strlen(ext_str) + 1;
- xcb_connection_t *c = XGetXCBConnection(dpy);
- xcb_glx_client_info(c,
- GLX_MAJOR_VERSION, GLX_MINOR_VERSION, size, ext_str);
+ if (ext_str) {
+ int size = strlen(ext_str) + 1;
- free(ext_str);
+ xcb_connection_t *c = XGetXCBConnection(dpy);
+ xcb_glx_client_info(c, GLX_MAJOR_VERSION, GLX_MINOR_VERSION, size,
+ ext_str);
+
+ free(ext_str);
+ }
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/5] glx: add extra null check in getFBConfigs
I think if __glXQueryServerString returns NULL, getFBConfigs should
return failure. It also looks like __glXQueryServerString could use
some NULL checks.
On 02/14/2014 05:23 AM, Juha-Pekka Heikkila wrote:
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/glx/glxext.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/glx/glxext.c b/src/glx/glxext.c
index 4a195bd..837c5b0 100644
--- a/src/glx/glxext.c
+++ b/src/glx/glxext.c
@@ -686,7 +686,8 @@ static GLboolean
fb_req-glxCode = X_GLXGetFBConfigs;
fb_req-screen = screen;
}
- else if (strstr(psc-serverGLXexts, GLX_SGIX_fbconfig) != NULL) {
+ else if (psc-serverGLXexts != NULL
+strstr(psc-serverGLXexts, GLX_SGIX_fbconfig) != NULL) {
GetReqExtra(GLXVendorPrivateWithReply,
sz_xGLXGetFBConfigsSGIXReq -
sz_xGLXVendorPrivateWithReplyReq, vpreq);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] glx: add missing null check in SendMakeCurrentRequest
NAK. At this point, priv cannot be NULL. All of the paths that lead
here have already called __glXSetupForCommand. In that function, there
is either already a context, or it calls __glXInitialize to create the
dpy private structure. If there is already a context, dpy must exist in
the table __glXInitialize uses, so it won't return NULL when called
again. If __glXSetupForCommand calls __glXInitialize, it will either
error out before getting to SendMakeCurrentRequest or the next call to
__glXInitialize will return the same pointer.
Not only that, but the point of the version check is to figure out which
protocol the server understands. If libGL can't figure out which
protocol to send, picking something at random is not the answer. It
should raise an error.
This is a Klocwork false-positive.
On 02/14/2014 05:23 AM, Juha-Pekka Heikkila wrote:
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/glx/indirect_glx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glx/indirect_glx.c b/src/glx/indirect_glx.c
index 28b8cd0..306bf5b 100644
--- a/src/glx/indirect_glx.c
+++ b/src/glx/indirect_glx.c
@@ -84,7 +84,7 @@ SendMakeCurrentRequest(Display * dpy, CARD8 opcode,
* not the SGI extension.
*/
- if ((priv-majorVersion 1) || (priv-minorVersion = 3)) {
+ if (priv ((priv-majorVersion 1) || (priv-minorVersion = 3))) {
xGLXMakeContextCurrentReq *req;
GetReq(GLXMakeContextCurrent, req);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/5] egl: Unhide functionality in _eglInitSync()
On 02/14/2014 05:23 AM, Juha-Pekka Heikkila wrote: _eglInitResource() was used to memset entire _EGLSync by writing more than size of pointed target. This does work as long as Resource is the first element in _EGLSync, this patch fixes such dependency. NAK. It's not a random dependency, it's inheritance. If _EGLResource isn't the first element of _EGLSync, this will be the least of the code that needs to change. Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com --- src/egl/main/eglsync.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/egl/main/eglsync.c b/src/egl/main/eglsync.c index 9d0067c..ba8a32f 100644 --- a/src/egl/main/eglsync.c +++ b/src/egl/main/eglsync.c @@ -75,7 +75,8 @@ _eglInitSync(_EGLSync *sync, _EGLDisplay *dpy, EGLenum type, !(type == EGL_SYNC_FENCE_KHR dpy-Extensions.KHR_fence_sync)) return _eglError(EGL_BAD_ATTRIBUTE, eglCreateSyncKHR); - _eglInitResource(sync-Resource, sizeof(*sync), dpy); + memset(sync, 0, sizeof(_EGLSync)); + _eglInitResource(sync-Resource, sizeof(_EGLResource), dpy); sync-Type = type; sync-SyncStatus = EGL_UNSIGNALED_KHR; sync-SyncCondition = EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 07/10] mesa: Add missing null check in _mesa_parse_arb_program()
On 02/17/2014 08:21 AM, Juha-Pekka Heikkila wrote:
Add missing null check in program_parse.tab.c through
program_parse.y
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/program/program_parse.y | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/program/program_parse.y
b/src/mesa/program/program_parse.y
index 6dde69d..cfc2cfe 100644
--- a/src/mesa/program/program_parse.y
+++ b/src/mesa/program/program_parse.y
@@ -2749,6 +2749,11 @@ _mesa_parse_arb_program(struct gl_context *ctx, GLenum
target, const GLubyte *st
*/
state-prog-Instructions =
_mesa_alloc_instructions(state-prog-NumInstructions + 1);
+
+ if (state-prog-Instructions == NULL) {
+ goto error;
+ }
+
inst = state-inst_head;
for (i = 0; i state-prog-NumInstructions; i++) {
struct asm_instruction *const temp = inst-next;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/10] mesa: remove redundant running of check_symbol_table()
On 02/17/2014 08:21 AM, Juha-Pekka Heikkila wrote:
Nested for loops running through tables against which they
finally do an assert were ran also with optimized builds.
If you add a
#else
(void) table;
#endif /* !defined(NDEBUG) */
then
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
Otherwise it will add an unused parameter warning to my builds. :)
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/program/symbol_table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/program/symbol_table.c b/src/mesa/program/symbol_table.c
index 4f6f31f..64e24d8 100644
--- a/src/mesa/program/symbol_table.c
+++ b/src/mesa/program/symbol_table.c
@@ -133,7 +133,7 @@ struct _mesa_symbol_table_iterator {
static void
check_symbol_table(struct _mesa_symbol_table *table)
{
-#if 1
+#if !defined(NDEBUG)
struct scope_level *scope;
for (scope = table-current_scope; scope != NULL; scope = scope-next) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/10] mesa: add missing null checks in _tnl_register_fastpath()
On 02/17/2014 08:21 AM, Juha-Pekka Heikkila wrote:
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/tnl/t_vertex.c | 41 -
1 file changed, 24 insertions(+), 17 deletions(-)
diff --git a/src/mesa/tnl/t_vertex.c b/src/mesa/tnl/t_vertex.c
index b3deac0..a122334 100644
--- a/src/mesa/tnl/t_vertex.c
+++ b/src/mesa/tnl/t_vertex.c
@@ -81,24 +81,31 @@ void _tnl_register_fastpath( struct tnl_clipspace *vtx,
GLboolean match_strides )
{
struct tnl_clipspace_fastpath *fastpath =
CALLOC_STRUCT(tnl_clipspace_fastpath);
- GLuint i;
-
- fastpath-vertex_size = vtx-vertex_size;
- fastpath-attr_count = vtx-attr_count;
- fastpath-match_strides = match_strides;
- fastpath-func = vtx-emit;
- fastpath-attr =
- malloc(vtx-attr_count * sizeof(fastpath-attr[0]));
-
- for (i = 0; i vtx-attr_count; i++) {
- fastpath-attr[i].format = vtx-attr[i].format;
- fastpath-attr[i].stride = vtx-attr[i].inputstride;
- fastpath-attr[i].size = vtx-attr[i].inputsize;
- fastpath-attr[i].offset = vtx-attr[i].vertoffset;
- }
- fastpath-next = vtx-fastpath;
- vtx-fastpath = fastpath;
+ if (fastpath != NULL) {
I'd prefer this as
if (fastpath == NULL)
return;
It's a lot less code churn.
With that change,
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
+ GLuint i;
+
+ fastpath-vertex_size = vtx-vertex_size;
+ fastpath-attr_count = vtx-attr_count;
+ fastpath-match_strides = match_strides;
+ fastpath-func = vtx-emit;
+ fastpath-attr = malloc(vtx-attr_count * sizeof(fastpath-attr[0]));
+
+ if (fastpath-attr == NULL) {
+ FREE(fastpath);
+ return;
+ }
+
+ for (i = 0; i vtx-attr_count; i++) {
+ fastpath-attr[i].format = vtx-attr[i].format;
+ fastpath-attr[i].stride = vtx-attr[i].inputstride;
+ fastpath-attr[i].size = vtx-attr[i].inputsize;
+ fastpath-attr[i].offset = vtx-attr[i].vertoffset;
+ }
+
+ fastpath-next = vtx-fastpath;
+ vtx-fastpath = fastpath;
+ }
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/10] Klocwork related pathes
On 02/17/2014 08:21 AM, Juha-Pekka Heikkila wrote:
Resend of the earlier glx patches with the issue pointed out by Petri fixed.
Patch number five is a bit special. hash_table_insert() and
hash_table_replace() don't really have a way to report errors and I did not
want to go changing the api since these are called from so many places thus
the case of null (c)allocation is handled just inside the functions and
relied low memory situation is handled outside the function properly.
Right. I'm a bit skeptical about patches 5 and 9 for that reason. I
think if we add a function _mesa_error_no_memory(void) to
src/mesa/errors.c that can at least set GL_OUT_OF_MEMORY in the context,
I'd be a bit more happy. The GL spec allows us to leave things in an
indeterminate state when we're out of memory. We really do need to let
the application know what happend, though.
Something like...
void
_mesa_error_no_memory(void)
{
GET_CURRENT_CONTEXT(ctx);
_mesa_error(ctx, GL_OUT_OF_MEMORY, out of memory);
}
ought to be enough. We do need to audit the various paths through
_mesa_error to make sure they can handle no memory situations.
Patch number eight is not from Klocwork. There was two nested for loops
running against table eventually doing an assert in check_symbol_table(),
this was included also for optimized builds. Now these loops will run only
on debug builds where assert could matter.
Juha-Pekka Heikkila (10):
glx: Add extra null check in __glXClientInfo
glx: add extra null check in getFBConfigs
glx: add missing null check in SendMakeCurrentRequest
egl: Unhide functionality in _eglInitSync()
mesa: Add missing null checks into prog_hash_table.c
mesa: Prevent negative indexing on noise2, noise3 and noise4
mesa: Add missing null check in _mesa_parse_arb_program()
mesa: remove redundant running of check_symbol_table()
mesa: add null checks for callocs in symbol_table.c
mesa: add missing null checks in _tnl_register_fastpath()
src/egl/main/eglsync.c | 3 ++-
src/glx/glxcmds.c | 13 +++-
src/glx/glxext.c | 3 ++-
src/glx/indirect_glx.c | 2 +-
src/mesa/program/prog_hash_table.c | 16 +--
src/mesa/program/prog_noise.c | 18 -
src/mesa/program/program_parse.y | 5 +
src/mesa/program/symbol_table.c| 28 ++
src/mesa/tnl/t_vertex.c| 41
++
9 files changed, 85 insertions(+), 44 deletions(-)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/10] mesa: Prevent negative indexing on noise2, noise3 and noise4
On 02/17/2014 08:21 AM, Juha-Pekka Heikkila wrote: % operator could return negative value which would cause indexing before perm table. Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com --- src/mesa/program/prog_noise.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/mesa/program/prog_noise.c b/src/mesa/program/prog_noise.c index c258c5e..12bb4d9 100644 --- a/src/mesa/program/prog_noise.c +++ b/src/mesa/program/prog_noise.c @@ -282,8 +282,8 @@ _mesa_noise2(GLfloat x, GLfloat y) y2 = y0 - 1.0f + 2.0f * G2; /* Wrap the integer indices at 256, to avoid indexing perm[] out of bounds */ - ii = i % 256; - jj = j % 256; + ii = abs(i % 256); + jj = abs(j % 256); It seems like ii = i 0x0ff; is a better way to do this. Perhaps add a comment about 'int % int' possibly returning NULL so that someone doesn't come a long and change it back. :) At that point, ii, jj, i1, and j1 should probably be unsigned. I think only i and j need to be int. /* Calculate the contribution from the three corners */ t0 = 0.5f - x0 * x0 - y0 * y0; @@ -423,9 +423,9 @@ _mesa_noise3(GLfloat x, GLfloat y, GLfloat z) z3 = z0 - 1.0f + 3.0f * G3; /* Wrap the integer indices at 256 to avoid indexing perm[] out of bounds */ - ii = i % 256; - jj = j % 256; - kk = k % 256; + ii = abs(i % 256); + jj = abs(j % 256); + kk = abs(k % 256); /* Calculate the contribution from the four corners */ t0 = 0.6f - x0 * x0 - y0 * y0 - z0 * z0; @@ -573,10 +573,10 @@ _mesa_noise4(GLfloat x, GLfloat y, GLfloat z, GLfloat w) w4 = w0 - 1.0f + 4.0f * G4; /* Wrap the integer indices at 256, to avoid indexing perm[] out of bounds */ - ii = i % 256; - jj = j % 256; - kk = k % 256; - ll = l % 256; + ii = abs(i % 256); + jj = abs(j % 256); + kk = abs(k % 256); + ll = abs(l % 256); /* Calculate the contribution from the five corners */ t0 = 0.6f - x0 * x0 - y0 * y0 - z0 * z0 - w0 * w0; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] targets/vdpau: Don't link unused libraries
On 17/02/14 15:42, Emil Velikov wrote: On 17/02/14 08:29, Kusanagi Kouichi wrote: libvdpau, libselinux and libexpat are not used. Nice catch, I'm a bit unsure about libexpat but considering that you've tested the resulting libraries the patch is expat is used only for the driconfig (read /etc/drirc) handling, within the dri state-tracker/classic dri drivers. Tested vdpau-nouveau works like a charm. Reviewed-by: Emil Velikov emil.l.veli...@gmail.com I'll push this and any other pending patches of yours later on today. Committed this and the other two patches, squashing use SELINUX_CFLAGS. Thanks again for the patches Kusanagi Kouichi. -Emil -Emil Signed-off-by: Kusanagi Kouichi sl...@ac.auone-net.jp --- configure.ac | 2 +- src/gallium/Automake.inc | 6 +- src/gallium/targets/r600/vdpau/Makefile.am | 1 - src/gallium/targets/radeonsi/vdpau/Makefile.am | 1 - src/gallium/targets/vdpau-nouveau/Makefile.am | 1 - 5 files changed, 6 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index 00a0eaa..17a51af 100644 --- a/configure.ac +++ b/configure.ac @@ -1320,7 +1320,7 @@ fi AM_CONDITIONAL(HAVE_ST_XVMC, test x$enable_xvmc = xyes) if test x$enable_vdpau = xyes; then -PKG_CHECK_MODULES([VDPAU], [vdpau = 0.4.1 x11-xcb xcb-dri2 = 1.8]) +PKG_CHECK_MODULES([VDPAU], [vdpau = 0.4.1 x11-xcb xcb-dri2 = 1.8], [VDPAU_LIBS=`$PKG_CONFIG --libs x11-xcb xcb-dri2`]) GALLIUM_STATE_TRACKERS_DIRS=$GALLIUM_STATE_TRACKERS_DIRS vdpau fi AM_CONDITIONAL(HAVE_ST_VDPAU, test x$enable_vdpau = xyes) diff --git a/src/gallium/Automake.inc b/src/gallium/Automake.inc index fec69cc..1acc99e 100644 --- a/src/gallium/Automake.inc +++ b/src/gallium/Automake.inc @@ -78,7 +78,11 @@ GALLIUM_VDPAU_LIB_DEPS = \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ $(top_builddir)/src/gallium/state_trackers/vdpau/libvdpautracker.la \ $(VDPAU_LIBS) \ -$(LIBDRM_LIBS) +$(LIBDRM_LIBS) \ +-lm \ +$(CLOCK_LIB) \ +$(PTHREAD_LIBS) \ +$(DLOPEN_LIBS) GALLIUM_XVMC_LIB_DEPS = \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ diff --git a/src/gallium/targets/r600/vdpau/Makefile.am b/src/gallium/targets/r600/vdpau/Makefile.am index 7f43fbb..c5103bd 100644 --- a/src/gallium/targets/r600/vdpau/Makefile.am +++ b/src/gallium/targets/r600/vdpau/Makefile.am @@ -41,7 +41,6 @@ libvdpau_r600_la_LIBADD = \ $(top_builddir)/src/gallium/drivers/r600/libr600.la \ $(top_builddir)/src/gallium/winsys/radeon/drm/libradeonwinsys.la \ $(GALLIUM_VDPAU_LIB_DEPS) \ -$(GALLIUM_DRI_LIB_DEPS) \ $(RADEON_LIBS) if HAVE_MESA_LLVM diff --git a/src/gallium/targets/radeonsi/vdpau/Makefile.am b/src/gallium/targets/radeonsi/vdpau/Makefile.am index 0292b2b..54d65b3 100644 --- a/src/gallium/targets/radeonsi/vdpau/Makefile.am +++ b/src/gallium/targets/radeonsi/vdpau/Makefile.am @@ -42,7 +42,6 @@ libvdpau_radeonsi_la_LIBADD = \ $(top_builddir)/src/gallium/drivers/radeonsi/libradeonsi.la \ $(top_builddir)/src/gallium/winsys/radeon/drm/libradeonwinsys.la \ $(GALLIUM_VDPAU_LIB_DEPS) \ -$(GALLIUM_DRI_LIB_DEPS) \ $(RADEON_LIBS) if HAVE_MESA_LLVM diff --git a/src/gallium/targets/vdpau-nouveau/Makefile.am b/src/gallium/targets/vdpau-nouveau/Makefile.am index fbaad03..3cdf103 100644 --- a/src/gallium/targets/vdpau-nouveau/Makefile.am +++ b/src/gallium/targets/vdpau-nouveau/Makefile.am @@ -42,7 +42,6 @@ libvdpau_nouveau_la_LIBADD = \ $(top_builddir)/src/gallium/winsys/nouveau/drm/libnouveaudrm.la \ $(top_builddir)/src/gallium/drivers/nouveau/libnouveau.la \ $(GALLIUM_VDPAU_LIB_DEPS) \ -$(GALLIUM_DRI_LIB_DEPS) \ $(NOUVEAU_LIBS) if HAVE_MESA_LLVM ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx/dri2: Respect --enable/disable-driglx-direct
On 17/02/14 06:49, Jeremy Huddleston Sequoia wrote: On Feb 16, 2014, at 17:15, Emil Velikov emil.l.veli...@gmail.com wrote: On 16/02/14 02:00, Jeremy Huddleston Sequoia wrote: Mesa master hasn't built for OSX for over a year now, unfortunately, but I agree excluding in Makefile.am is preferable to cpp-guards. Hopefully someone will have the time and patience to get it working again in the near future. Hi Jeremy A while back, I was pondering on converting the apple glx to automake, but the biggest obstacle was the complete lack of testing (compile or runtime). iirc you have a tinderbox at x.org but it does not build mesa. Do you mind updating it ? It does build mesa (and has for quite some time now), but it builds it for DRI (not Apple-DRI). If you want me to add another target (mesa-apple or similar), let me know what configure options you want me to pass it to trigger your new way. Hmm perhaps I'm looking at the wrong location. This [1] is what I had in mind, but afaics it never even goes through the configure stage, let alone build it. Am I missing something ? Whereas for build options - those depend on your requirements. I would start with what should should work atm, and then work on the merge codebases part. FWIW, the end goal was to eventually merge the codebases together so we could support both indirect GLX and Apple-DRI in the same libGL, but that never happened. Interesting, is this Apple-DRI backed by actual hw (classic/gallium) drivers or are we talking about swrast only ? AFAICS all hw dri drivers are quite linux specific. -Emil [1] http://tinderbox.x.org/builds/machines/jeremyhu-yuffie/ I might get back to that over the next few weeks, so keep an eye open. Awesome. Thanks. --Jeremy ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/18] mesa: Implement glBindImageTextures()
Fredrik Höglund fred...@kde.org writes: On Thursday 13 February 2014, Francisco Jerez wrote: Fredrik Höglund fred...@kde.org writes: [...] Can't you get rid of the whole block above by declaring 'const GLuint texture = (textures ? textures[i] : 0);' in the loop below, and then 's/textures[i]/texture/'? I could, but I thought it might be worth optimizing this case. Note that the hash table mutex is not locked in this block. I don't know if it actually makes a difference for any real applications though. Sounds like a premature optimization to me. But the actual unbinding code could be moved into a helper function. Right, I guess that would make the code somewhat easier to follow. [...] You can just unref 'u-TexObj' and set 'u-_Valid' to GL_FALSE here. Unfortunately the specification says that all parameters are reset to their default values when a texture is unbound. Oh, right, I had missed that paragraph from the spec. Thanks. pgp6VIHbcCSZ9.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glx: Fix the default values for GLXFBConfig attributes
The default values for GLX_DRAWABLE_TYPE and GLX_RENDER_TYPE are
GLX_WINDOW_BIT and GLX_RGBA_BIT respectively, as specified in
the GLX 1.4 specification.
This fixes the glx-choosefbconfig-defaults piglit test.
Cc: 9.2 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/glx/glxcmds.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 38a5262..43c473b 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -925,13 +925,10 @@ init_fbconfig_for_chooser(struct glx_config * config,
if (fbconfig_style_tags) {
config-rgbMode = GL_TRUE;
config-doubleBufferMode = GLX_DONT_CARE;
- /* allow any kind of drawable, including those for off-screen buffers */
- config-drawableType = 0;
- } else {
- /* allow configs which support on-screen drawing */
- config-drawableType = GLX_WINDOW_BIT;
+ config-renderType = GLX_RGBA_BIT;
}
+ config-drawableType = GLX_WINDOW_BIT;
config-visualRating = GLX_DONT_CARE;
config-transparentPixel = GLX_NONE;
config-transparentRed = GLX_DONT_CARE;
@@ -940,8 +937,6 @@ init_fbconfig_for_chooser(struct glx_config * config,
config-transparentAlpha = GLX_DONT_CARE;
config-transparentIndex = GLX_DONT_CARE;
- /* Set GLX_RENDER_TYPE property to not expect any flags by default. */
- config-renderType = 0;
config-xRenderable = GLX_DONT_CARE;
config-fbconfigID = (GLXFBConfigID) (GLX_DONT_CARE);
--
1.8.5.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glx: Fix the GLXFBConfig attrib sort priorities
The sort priorites for GLX_SAMPLES and GLX_SAMPLE_BUFFERS are
not defined in GL_ARB_multisample, but they are defined in
the GLX 1.4 specification.
Cc: 9.2 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/glx/glxcmds.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 43c473b..837d8a2 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -1105,7 +1105,7 @@ static int
fbconfig_compare(struct glx_config **a, struct glx_config **b)
{
/* The order of these comparisons must NOT change. It is defined by
-* the GLX 1.3 spec and ARB_multisample.
+* the GLX 1.4 specification.
*/
PREFER_SMALLER(visualSelectGroup);
@@ -1134,6 +1134,9 @@ fbconfig_compare(struct glx_config **a, struct glx_config
**b)
PREFER_SMALLER(numAuxBuffers);
+ PREFER_SMALLER(sampleBuffers);
+ PREFER_SMALLER(samples);
+
PREFER_LARGER_OR_ZERO(depthBits);
PREFER_SMALLER(stencilBits);
@@ -1147,12 +1150,6 @@ fbconfig_compare(struct glx_config **a, struct
glx_config **b)
PREFER_SMALLER(visualType);
- /* None of the multisample specs say where this comparison should happen,
-* so I put it near the end.
-*/
- PREFER_SMALLER(sampleBuffers);
- PREFER_SMALLER(samples);
-
/* None of the pbuffer or fbconfig specs say that this comparison needs
* to happen at all, but it seems like it should.
*/
--
1.8.5.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71870] Metro: Last Light rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=71870 --- Comment #39 from Darius Spitznagel d.spitzna...@goodbytez.de --- @Ian: I'm very impressed by the fact, that you contact(ed) the vendor to report on this. It's always a bad idea breaking or ignoring specs or rules, i know that. But at the end, this will only fix the problem for Metro LL. What about all the other games using the faulty FXAA shaders from nvidia? Or other game developers simply misunderstanding GLSL specs? Some of us mesa users here like Jose, Thomas and Mike have good ideas. We all waited so long seeing Linux getting more and more attention on the desktop, so give us a hand. Life is too short and world is far from being perfect. I have 2 other ideas to solve this. 1. There are already environment variables like MESA_GLSL_VERSION_OVERRIDE=XXX inside mesa. How about implement another one like MESA_GLSL_ALLOW_DOUBLE_UNDERSCORES=XXX. Default is of course no, override is yes. We could then write our own bash script or enter it in the launch options in steam. I think, this is a good option. 2. Look for a file like .glslrc (inspired by comment 34) in the games directory or where the games executable lie. If it contains a string like ALLOW_DOUBLE_UNDERSOURCES=yes then override. This seams simpler to code but may break when the vendor is doing some kind on nasty check against foreign files. So I think with both examples you don't break your rules and we are happy. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71870] Metro: Last Light rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=71870 --- Comment #40 from almos aaalmo...@gmail.com --- I'm not an expert on GLSL, but forbidding identifiers that contain '__' *anywhere* seems stupid to me. I'm not aware of any other programming language that imposes such a limitation on identifiers. What's the reason for this? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/38] drivers/dri: set the implemented version of __DRItexBufferExtension
On 13/02/14 03:03, Ilia Mirkin wrote: On Wed, Feb 12, 2014 at 9:56 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 13/02/14 02:47, Emil Velikov wrote: On 13/02/14 02:34, Ilia Mirkin wrote: On Wed, Feb 12, 2014 at 8:17 PM, Emil Velikov emil.l.veli...@gmail.com wrote: ... over the version number provided by the headers. Explicitly set extension members to improve clarity. So... the current value is 2, but I see code that does src/egl/drivers/dri2/egl_dri2.c:#if __DRI_TEX_BUFFER_VERSION = 3 src/glx/dri2_glx.c:#if __DRI_TEX_BUFFER_VERSION = 3 src/glx/drisw_glx.c:#if __DRI_TEX_BUFFER_VERSION = 3 What's that all about? Chaos wrt documentation and keeping up with it. Until git log churns this is the only reasonable thing that I can think of: - releaseTexBuffer was added with version 3 in mind. - no driver implemented the function - the version was never bumped or reverted. Looks like cvs (or whatever was used back in 2009) failure :\ Eric introduced v2 with commit 66175aac760, bumping the version 12 Ian made an update with commit 82634ee8df7, bumping the version 12 Meh, that's a merge-fail from a long time ago. I'll update the header but I'll keep version 2 everywhere (dropping the null member). releaseTexBuffer was actually introduced with e59fa4c46c8 (dri2: release texture image.), which also added 2 of the #if's. I'm guessing the third got copy/pasted in. Good catch, while the commit effectively adds a new revision of the extension if avoids bumping the version number. At the same time it adds a glx/egl dri2 implementations wrapped in if __DRI_TEX_BUFFER_VERSION =3. Bumping the version in the header, will result in broken build (2) due to missing _eglReleaseTexImage and possibly others. With the build issues resolved, the function have some runtime cost, despite that no driver implements __DRItexBufferExtensionRec::releaseTexBuffer. Juan Zhao Can you provide some clarity on the case ? Namely with e59fa4c46c8 (dri2: release texture image.) you've updated the __DRItexBufferExtensionRec but the code you've added seems untested. - Did you deliberately omitted bumping the __DRI_TEX_BUFFER_VERSION, what is the idea behind it. - Is there any plans on implementing _eglReleaseTexImage that is required in order to get egl_dri2 building/working ? IMHO we can safely bump the version in the header, and comment out/drop the broken code if no-one is going to step up and clean it. Thanks -Emil -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71870] Metro: Last Light rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=71870 --- Comment #41 from Thomas Rohloff v10la...@myway.de --- (In reply to comment #40) I'm not an expert on GLSL, but forbidding identifiers that contain '__' *anywhere* seems stupid to me. I'm not aware of any other programming language that imposes such a limitation on identifiers. What's the reason for this? All macro names containing two consecutive underscores ( __ ) are reserved for future use as predefined macro names. All macro names prefixed with “GL_” (“GL” followed by a single underscore) are also reserved. (source: Comment 33) In other words: When you have a macro called MY__SUPER_COOL_MACRO Khronos could step up telling MY__SUPER_COOL_MACRO is now a predefined macro and as such your program is incompatible. I just fail to see why this is needed for already finished specifications. Anyway in that example Mesa could just disallow MY__SUPER_COOL_MACRO (expose the internal macro instead) and not everything. Also I don't think the specification says you're not allowed to use MY__SUPER_COOL_MACRO, it just tells you that it's a bad idea, so mesa is overstrict here. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix valgrind uninitialized variable warning
I've updated the patch to set the flipped flag as well. I verified that all the flags were being set. As for the data in the rest of the structure that is filled in from the compressed data using whatever technique was coded in the compressed data. I don't think it's necessary to zero out the full structure, just the flags. Courtney On Fri, Feb 14, 2014 at 1:51 PM, Ian Romanick i...@freedesktop.org wrote: On 02/14/2014 08:05 AM, Courtney Goeltzenleuchter wrote: Initialize field to eliminate valgrind warning. There are a couple other fields that aren't set it all paths (e.g., flipped). I want to suggest just memseting the whole structure, but it's not obvious to me how it's used throughout the code. I suspect the code was more clear before ETC2 support was added... Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com --- src/mesa/main/texcompress_etc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/main/texcompress_etc.c b/src/mesa/main/texcompress_etc.c index f9234b0..97adc86 100644 --- a/src/mesa/main/texcompress_etc.c +++ b/src/mesa/main/texcompress_etc.c @@ -350,6 +350,7 @@ etc2_rgb8_parse_block(struct etc2_block *block, block-is_t_mode = false; block-is_h_mode = false; block-is_planar_mode = false; + block-opaque = false; if (punchthrough_alpha) block-opaque = src[3] 0x2; -- Courtney Goeltzenleuchter LunarG ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 75126] New: configure: error: classic DRI driver 'yes' does not exist
https://bugs.freedesktop.org/show_bug.cgi?id=75126 Priority: medium Bug ID: 75126 Keywords: regression CC: emil.l.veli...@gmail.com, matts...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: configure: error: classic DRI driver 'yes' does not exist Severity: blocker Classification: Unclassified OS: All Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa mesa: adad8fb2e947e3ea9e9d84cb3722e46de91346e4 (master) $ ./autogen.sh --disable-dri --with-gallium-drivers=swrast [...] checking for LIBDRM... yes checking for LIBUDEV... yes configure: error: classic DRI driver 'yes' does not exist ee55500c22a000d95ef4e5855b150f35ea0b5bba is the first bad commit commit ee55500c22a000d95ef4e5855b150f35ea0b5bba Author: Emil Velikov emil.l.veli...@gmail.com Date: Tue Feb 4 17:26:38 2014 + configure: cleanup classic dri drivers handling * Make sure that only drivers that are handled by configure.ac are included in DRI_DIRS. * Change with_dri_drivers default value to auto, and set enable autodetection, when enable_opengl is on. v2: Move test to the correct location. v3: Squash DRI_DIRS handling before the switch statement. Suggested by Ilia Mirkin Signed-off-by: Emil Velikov emil.l.veli...@gmail.com Reviewed-by: Matt Turner matts...@gmail.com :100644 100644 ee6d253664b9e1341521fcc58167bffa9a991033 0c9044b5e506f2d01d73fd8faf57f7d323274fe9 Mconfigure.ac bisect run success -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 75126] configure: error: classic DRI driver 'yes' does not exist
https://bugs.freedesktop.org/show_bug.cgi?id=75126 --- Comment #1 from Emil Velikov emil.l.veli...@gmail.com --- Created attachment 94247 -- https://bugs.freedesktop.org/attachment.cgi?id=94247action=edit configure: use default dri drivers whenever opengl and dri are enabled Easily reproduced and fixed with the above patch. Vinson can we have a list of the configurations that you're building ? It would be rather useful. -Emil -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure: use default dri drivers whenever opengl and dri are enabled
Commit ee55500c22a(configure: cleanup classic dri drivers handling) cleaned up the logic handling autodetection of dri drivers, but missed the case when one can explicitly disable dri, and still request opengl. Fixes build issues for the following ./autogen.sh --disable-dri --with-gallium-drivers=swrast While we're here, explicitly clear with_dri_drivers whenever building without such drivers to prevent choking later on. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75126 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- configure.ac | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index fc5e028..0c45f63 100644 --- a/configure.ac +++ b/configure.ac @@ -951,11 +951,15 @@ AC_ARG_WITH([dri-drivers], [with_dri_drivers=auto]) case $with_dri_drivers in -no) ;; +no) +with_dri_drivers= +;; auto) # classic DRI drivers -if test x$enable_opengl = xyes; then +if test x$enable_opengl = xyes -a x$enable_dri = xyes; then with_dri_drivers=yes +else +with_dri_drivers= fi ;; esac -- 1.9.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx/dri2: Respect --enable/disable-driglx-direct
On Feb 17, 2014, at 13:29, Emil Velikov emil.l.veli...@gmail.com wrote: On 17/02/14 06:49, Jeremy Huddleston Sequoia wrote: On Feb 16, 2014, at 17:15, Emil Velikov emil.l.veli...@gmail.com wrote: On 16/02/14 02:00, Jeremy Huddleston Sequoia wrote: Mesa master hasn't built for OSX for over a year now, unfortunately, but I agree excluding in Makefile.am is preferable to cpp-guards. Hopefully someone will have the time and patience to get it working again in the near future. Hi Jeremy A while back, I was pondering on converting the apple glx to automake, but the biggest obstacle was the complete lack of testing (compile or runtime). iirc you have a tinderbox at x.org but it does not build mesa. Do you mind updating it ? It does build mesa (and has for quite some time now), but it builds it for DRI (not Apple-DRI). If you want me to add another target (mesa-apple or similar), let me know what configure options you want me to pass it to trigger your new way. Hmm perhaps I'm looking at the wrong location. This [1] is what I had in mind, but afaics it never even goes through the configure stage, let alone build it. Am I missing something ? No, I was. I saw 'Mesa 3D Graphics' but that is just the meta-module. mesa-mesa was in skip. I've removed it and kicked of a build (http://tinderbox.x.org/builds/2014-02-18-). Whereas for build options - those depend on your requirements. I would start with what should should work atm, and then work on the merge codebases part. There are no configure flags to enable Apple-DRI right now, so it's just using the default configure flags. Let me know what you want me to change it to. I can also update it to checkout a different branch or repo if you prefer to work somewhere other than master. FWIW, the end goal was to eventually merge the codebases together so we could support both indirect GLX and Apple-DRI in the same libGL, but that never happened. Interesting, is this Apple-DRI backed by actual hw (classic/gallium) drivers or are we talking about swrast only ? AFAICS all hw dri drivers are quite linux specific. Apple-DRI is something completely different. It uses OpenGL.framework and is not backed by gallium or swrast. It was done over a decade ago as a branch of XFree86 that was never accepted and merged back in. Code diverged and about 7 years ago, we started trying to get XQuartz' merged into freedesktop.org. That process was pretty much fully completed by about 4 years ago except for mesa. Mesa only supports AppleDRI in a separate build configuration which makes it impossible to have a libGL that supports indirect GLX when the server is remote and Apple-DRI when it is local. --Jeremy smime.p7s Description: S/MIME cryptographic signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71870] Metro: Last Light rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=71870 --- Comment #42 from Krzysztof A. Sobiecki sob...@gmail.com --- I do not believe that requiring users to make any changes in theirs Mesa configuration to run some applications is a good idea. Mesa should be working out of the box, not some assembly needed. Especially when application authors have one simple answer: use vendor supplied drivers. As I know nothing about GLSL I will now yell at some clouds: *Do as big vendors(AMD, Nvidia) do. It's nice to follow specs, but when everyone that matters breaks(or interpret differently) them, then the spec is wrong. Imitate actual implementations. It's highly unlikely that Mesa will budge vendors and app authors in more desirable direction. *Enforce __ restrictions only in GLSL versions that actually use __ stuff. *Whitelisting of problematic apps brining more complexity(update that list without updating Mesa, otherwise why bother?) than it's worth. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g, radeonsi: Consolidate logic for short-circuiting flushes
From: Michel Daenzer michel.daen...@amd.com
Fixes radeonsi emitting command streams to the kernel even when there
have been no draw calls before a flush, potentially powering up the GPU
needlessly.
Incidentally, this also cuts the runtime of piglit gpu.py in about half
on my Kaveri system, probably because an X11 client going away no longer
always results in a command stream being submitted to the kernel via
glamor.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=65761
Cc: 10.1 mesa-sta...@lists.freedesktop.org
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/r600/r600_hw_context.c | 2 +-
src/gallium/drivers/r600/r600_pipe.c| 4 ++--
src/gallium/drivers/r600/r600_pipe.h| 1 -
src/gallium/drivers/radeon/r600_buffer_common.c | 2 +-
src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
src/gallium/drivers/radeonsi/si_hw_context.c| 6 +++---
6 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index dc3c221..ef077b2 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -355,7 +355,7 @@ void r600_begin_new_cs(struct r600_context *ctx)
ctx-last_primitive_type = -1;
ctx-last_start_instance = -1;
- ctx-initial_gfx_cs_size = ctx-b.rings.gfx.cs-cdw;
+ ctx-b.initial_gfx_cs_size = ctx-b.rings.gfx.cs-cdw;
}
/* The max number of bytes to copy per packet. */
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 8ea192a..0f75a53 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -74,7 +74,7 @@ static void r600_flush(struct pipe_context *ctx, unsigned
flags)
unsigned render_cond_mode = 0;
boolean render_cond_cond = FALSE;
- if (rctx-b.rings.gfx.cs-cdw == rctx-initial_gfx_cs_size)
+ if (rctx-b.rings.gfx.cs-cdw == rctx-b.initial_gfx_cs_size)
return;
rctx-b.rings.gfx.flushing = true;
@@ -95,7 +95,7 @@ static void r600_flush(struct pipe_context *ctx, unsigned
flags)
ctx-render_condition(ctx, render_cond, render_cond_cond,
render_cond_mode);
}
- rctx-initial_gfx_cs_size = rctx-b.rings.gfx.cs-cdw;
+ rctx-b.initial_gfx_cs_size = rctx-b.rings.gfx.cs-cdw;
}
static void r600_flush_from_st(struct pipe_context *ctx,
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r600/r600_pipe.h
index 15052da..83b0e4f 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -377,7 +377,6 @@ struct r600_context {
struct r600_screen *screen;
struct blitter_context *blitter;
struct u_suballocator *allocator_fetch_shader;
- unsignedinitial_gfx_cs_size;
/* Hardware info. */
boolean has_vertex_cache;
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r600_buffer_common.c
index 068141c..e75b337 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -60,7 +60,7 @@ void *r600_buffer_map_sync_with_rings(struct
r600_common_context *ctx,
rusage = RADEON_USAGE_WRITE;
}
- if (ctx-rings.gfx.cs-cdw
+ if (ctx-rings.gfx.cs-cdw != ctx-initial_gfx_cs_size
ctx-ws-cs_is_buffer_referenced(ctx-rings.gfx.cs,
resource-cs_buf, rusage)) {
if (usage PIPE_TRANSFER_DONTBLOCK) {
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 2fbc6a3..d604f65 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -241,6 +241,7 @@ struct r600_common_context {
enum radeon_family family;
enum chip_class chip_class;
struct r600_rings rings;
+ unsignedinitial_gfx_cs_size;
struct u_upload_mgr *uploader;
struct u_suballocator *allocator_so_filled_size;
diff --git a/src/gallium/drivers/radeonsi/si_hw_context.c
b/src/gallium/drivers/radeonsi/si_hw_context.c
index 7e40255..639659c 100644
--- a/src/gallium/drivers/radeonsi/si_hw_context.c
+++ b/src/gallium/drivers/radeonsi/si_hw_context.c
@@ -79,9 +79,7 @@ void si_need_cs_space(struct si_context *ctx, unsigned num_dw,
void si_context_flush(struct si_context *ctx, unsigned flags)
{
- struct radeon_winsys_cs *cs = ctx-b.rings.gfx.cs;
-
- if (!cs-cdw)
+ if (ctx-b.rings.gfx.cs-cdw == ctx-b.initial_gfx_cs_size)
return;
/* suspend queries */
@@ -177,6 +175,8 @@ void si_begin_new_cs(struct si_context *ctx)
}
Re: [Mesa-dev] [PATCH V2] i965: Fix the region's pitch condition to use blitter
On 01/07/2014 05:46 PM, Anuj Phogat wrote:
intelEmitCopyBlit uses a signed 16-bit integer to represent
buffer pitch, so it can only handle buffer pitches 32k.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
Dropping few changes made in earlier patch. If region-bo-size =
max_gtt_map_object_size, we can't fall back to intel_miptree_map_gtt().
src/mesa/drivers/dri/i965/intel_blit.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_blit.c
b/src/mesa/drivers/dri/i965/intel_blit.c
index 7bc289f..32431b9 100644
--- a/src/mesa/drivers/dri/i965/intel_blit.c
+++ b/src/mesa/drivers/dri/i965/intel_blit.c
@@ -199,9 +199,9 @@ intel_miptree_blit(struct brw_context *brw,
* As a result of these two limitations, we can only use the blitter to do
* this copy when the region's pitch is less than 32k.
*/
- if (src_mt-region-pitch 32768 ||
- dst_mt-region-pitch 32768) {
- perf_debug(Falling back due to 32k pitch\n);
+ if (src_mt-region-pitch = 32768 ||
+ dst_mt-region-pitch = 32768) {
+ perf_debug(Falling back due to =32k pitch\n);
return false;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/12] glsl/gsraytrace: Switch to core profile.
On 02/13/2014 02:18 PM, Fabian Bieler wrote:
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/gsraytrace.cpp | 40 +---
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index 6df6543..3eec835 100644
--- a/src/glsl/gsraytrace.cpp
+++ b/src/glsl/gsraytrace.cpp
@@ -70,7 +70,7 @@ float rot[9] = {1,0,0, 0,1,0, 0,0,1};
static const char* vsSource =
\n
-#version 150 \n
+#version 150 core \n
I don't think this is strictly necessary. I'm pretty sure core is the
default if the context is core profile.
#line S__LINE__ \n
#define SHADOWS \n
#define RECURSION \n
@@ -253,7 +253,7 @@ static const char* vsSource =
static const char* gsSource =
-#version 150 \n
+#version 150 core\n
#line S__LINE__ \n
layout(points) in; \n
layout(points, max_vertices = 3) out;\n
@@ -393,7 +393,7 @@ static const char* gsSource =
}\n;
static const char* fsSource =
-#version 150 \n
+#version 150 core\n
#line S__LINE__ \n
\n
#define SHADOWS \n
@@ -408,6 +408,7 @@ static const char* fsSource =
uniform vec4 backgroundColor;\n
uniform int emitNoMore; \n
\n
+out vec4 frag_color; \n
\n
//---\n
\n
@@ -493,7 +494,7 @@ static const char* fsSource =
Isec eyeHit = isec;\n
if (eyeHit.idx == -1)\n
{\n
- gl_FragColor = vec4(backgroundColor.rgb, 0.0);\n
+ frag_color = vec4(backgroundColor.rgb, 0.0);\n
return;\n
}\n
vec3 eyeHitPosition = eyeRay.orig + eyeRay.dir * eyeHit.t;\n
@@ -503,7 +504,7 @@ static const char* fsSource =
vec3 L = normalize(lightVec);
\n
float NdotL = max(dot(N, L), 0.0);
\n
vec3 diffuse = idx2color(eyeHit.idx); // material color of the visible
point\n
-gl_FragColor = vec4(diffuse * NdotL, 1.0);
\n
+frag_color = vec4(diffuse * NdotL, 1.0);
\n
return;
\n
}
\n
#ifdef SHADOWS
\n
@@ -514,7 +515,7 @@ static const char* fsSource =
{ \n
discard;\n
} \n
-gl_FragColor = vec4(-1,-1,-1, 0.0); \n
+frag_color = vec4(-1,-1,-1, 0.0); \n
return; \n
} \n
#endif\n
@@ -534,7 +535,7 @@ static const char* fsSource =
vec3 L = normalize(lightVec); \n
float NdotL = max(dot(N, L), 0.0); \n
vec3 diffuse = idx2color(reflHit.idx);\n
-gl_FragColor = vec4(diffuse * NdotL * 0.25, 1.0); // material color of
the visible point\n
+frag_color = vec4(diffuse * NdotL * 0.25, 1.0); // material color of
the visible point\n
return; \n
} \n
#endif\n
@@ -608,6 +609,8 @@ Draw(void)
dir_idxAttribLoc = glGetAttribLocation(program, dir_idx);
uv_stateAttribLoc = glGetAttribLocation(program, uv_state);
+ glBindFragDataLocation(program, 0, frag_color);
+
Re: [Mesa-dev] [PATCH 00/12] DEMOS Use core profile in two GS demos (v2).
Series is Reviewed-by: Ian Romanick ian.d.roman...@intel.com On 02/13/2014 02:18 PM, Fabian Bieler wrote: Hello! As mesa only supports geometry shaders in core profile contexts this patchset adjusts the gsraytrace and the geom-outlining-150 demos to use the core profile. This is v2 with the comment by Ian Romanick regarding incorrect usage of the GLSL preprocessor #line directive adressed. As I don't have git access, I'd appreciate it if someone could commit these patches (assuming there are no further issues, of course). Thanks, Fabian Fabian Bieler (12): configure.ac: Check for freeglut. glut_wrapper: Include freeglut.h if available. glsl/gsraytrace: Use __LINE__ macro to set line numbers in GLSL source strings. glsl/gsraytrace: Don't create new Buffer objects everytime the window is resized. glsl/gsraytrace: Bind transform feedback buffer. glsl/gsraytrace: Use core GL3.0 transform feedback glsl/gsraytrace: Use GLSL 1.5 instead of 1.2. glsl/gsraytrace: Use core geometry shaders. glsl/gsraytrace: Switch to core profile. geom-outlining-150: Use a vbo. geom-outlining-150: Use core geometry shaders. geom-outlining-150: Switch to core profile. configure.ac | 6 ++ src/glsl/geom-outlining-150.c | 64 +-- src/glsl/gsraytrace.cpp | 185 ++ src/util/glut_wrap.h | 4 +- 4 files changed, 147 insertions(+), 112 deletions(-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 59941] glxinfo segfault with GL_ARB_uniform_buffer_object
https://bugs.freedesktop.org/show_bug.cgi?id=59941 --- Comment #2 from Ian Romanick i...@freedesktop.org --- Does this bug still occur? I'm not able to reproduce it. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: propogate FragDepthLayout to gl_program
From: Chia-I Wu o...@lunarg.com
The information was lost during linking, causing the layout to be treated as
FRAG_DEPTH_LAYOUT_NONE.
Signed-off-by: Chia-I Wu o...@lunarg.com
---
src/mesa/main/shaderapi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 44b4c3a..be7b27b 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -1865,6 +1865,11 @@ _mesa_copy_linked_program_data(gl_shader_stage type,
dst_gp-UsesEndPrimitive = src-Geom.UsesEndPrimitive;
}
break;
+ case MESA_SHADER_FRAGMENT: {
+ struct gl_fragment_program *dst_fp = (struct gl_fragment_program *) dst;
+ dst_fp-FragDepthLayout = src-FragDepthLayout;
+ }
+ break;
case MESA_SHADER_COMPUTE: {
struct gl_compute_program *dst_cp = (struct gl_compute_program *) dst;
int i;
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71870] Metro: Last Light rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=71870 --- Comment #43 from Krzysztof A. Sobiecki sob...@gmail.com --- Created attachment 94257 -- https://bugs.freedesktop.org/attachment.cgi?id=94257action=edit ast_to_hir.cpp also needs a patch? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71870] Metro: Last Light rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=71870 meng mengmeng.m...@intel.com changed: What|Removed |Added CC||mengmeng.m...@intel.com -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/10] egl: Unhide functionality in _eglInitSync()
On Tue, Feb 18, 2014 at 12:21 AM, Juha-Pekka Heikkila juhapekka.heikk...@gmail.com wrote: _eglInitResource() was used to memset entire _EGLSync by writing more than size of pointed target. This does work as long as Resource is the first element in _EGLSync, this patch fixes such dependency. _EGLSync is a subclass of _EGLResource so the dependency always holds. _eglInitResource is made to be able to initialize any class derived from _EGLResource, by requiring the size of the derived class to be specified. Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com --- src/egl/main/eglsync.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/egl/main/eglsync.c b/src/egl/main/eglsync.c index 9d0067c..ba8a32f 100644 --- a/src/egl/main/eglsync.c +++ b/src/egl/main/eglsync.c @@ -75,7 +75,8 @@ _eglInitSync(_EGLSync *sync, _EGLDisplay *dpy, EGLenum type, !(type == EGL_SYNC_FENCE_KHR dpy-Extensions.KHR_fence_sync)) return _eglError(EGL_BAD_ATTRIBUTE, eglCreateSyncKHR); - _eglInitResource(sync-Resource, sizeof(*sync), dpy); + memset(sync, 0, sizeof(_EGLSync)); + _eglInitResource(sync-Resource, sizeof(_EGLResource), dpy); sync-Type = type; sync-SyncStatus = EGL_UNSIGNALED_KHR; sync-SyncCondition = EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR; -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- o...@lunarg.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
