[Mesa-dev] [Bug 90162] glGetFramebufferAttachmentParameteriv failing if certain FB attributes are zero
https://bugs.freedesktop.org/show_bug.cgi?id=90162 --- Comment #8 from Tapani Pälli lem...@gmail.com --- (In reply to Martina Kollarova from comment #7) glGetFramebufferAttachmentParameteriv(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, type); This query generated a GL_INVALID_ENUM for me. Yep, like stated in comment #6, that seems to be broken. I'm attaching here a patch to make it work in case you have Mesa from git repository to try. I will send this patch later to mesa-dev after some careful spec investigation and testing. -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90397] ARB_program_interface_query: glGetProgramResourceiv() returns wrong value for GL_REFERENCED_BY_*_SHADER prop for GL_UNIFORM for members of an interface block with an instance na
https://bugs.freedesktop.org/show_bug.cgi?id=90397
--- Comment #4 from Samuel Iglesias sigles...@igalia.com ---
Created attachment 115737
-- https://bugs.freedesktop.org/attachment.cgi?id=115737action=edit
patch to GetProgramResourceIndex() to fix arrays of UBOs behavior
I found another issue when modifying
arb_program_interface_query-getprogramresourceiv to test an uniform inside an
array of UBOs.
I modified a shader which is defined inside common.h. Because of that, I
updated other tests' code to work with that change. In particular,
resource-query.c.
Shader code:
#version 150
uniform fs_uniform_block {
vec4 fs_color;
float fs_array[4];
};
uniform fs_array_uniform_block {
vec4 fs_color;
float fs_array[4];
} ubo[4];
in vec4 fs_input1;
out vec4 fs_output0;
out vec4 fs_output1;
void main() {
fs_output0 = fs_color * fs_input1 * fs_array[2] *
ubo[0].fs_array[2] * ubo[2].fs_array[2];
fs_output1 = fs_color * fs_input1 * fs_array[3] *
ubo[1].fs_array[3] * ubo[3].fs_array[3];
}
I found that glGetProgramResourceName() is returning the name
fs_array_uniform_block[0], fs_array_uniform_block[1],
fs_array_uniform_block[2], and fs_array_uniform_block[3] when asked with
the corresponding block index as those blocks are active resources in the
shader.
resource-query test checks again that those names corresponds to active
resources by comparing the former index against the one returned by
glGetProgramResourceIndex(name).
Unfortunately, Mesa is returning GL_INVALID_INDEX to
fs_array_uniform_block[{1,2,3}] (other than zero), while NVIDIA passes the
test for that case.
Reading GL_ARB_program_interface_query, I found the following:
Note that if an
interface enumerates a single active resource list entry for an array
variable (e.g., a[0]), a name identifying any array element other than
the first (e.g., a[1]) is not considered to match.
I understand that this is referring to uniform/buffer variables but not
uniform/shader-storage blocks, but I might be wrong.
I would like to have your opinion regarding if it is valid or not spec-wise.
What do you think?
P.S: Attached to this, it's the patch that fixes this case.
--
You are receiving this mail because:
You are the QA Contact 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/2] gallium/drivers: Add threadsafe wrappers for pipe_context and pipe_screen
Hi Tom,
pipe_screen doesn't need any locking. It should already be thread-safe
(if it's not, it's a driver bug). It's implied by the fact that
pipe_screen is shared by all OpenGL contexts. I'm sure the radeon
pipe_screen is thread-safe.
Marek
On Tue, May 12, 2015 at 8:07 PM, Tom Stellard thomas.stell...@amd.com wrote:
These wrappers can be used by state trackers to ensure threadsafe access
to pipe_context and pipe_screen objects.
CC: 10.5 mesa-sta...@lists.freedesktop.org
---
src/gallium/SConscript | 1 +
src/gallium/drivers/threadsafe/Makefile.am | 11 +
src/gallium/drivers/threadsafe/Makefile.sources| 4 +
src/gallium/drivers/threadsafe/SConscript | 13 +
src/gallium/drivers/threadsafe/threadsafe.h| 39 +++
.../drivers/threadsafe/threadsafe_context.c| 275
+
src/gallium/drivers/threadsafe/threadsafe_screen.c | 190 ++
7 files changed, 533 insertions(+)
create mode 100644 src/gallium/drivers/threadsafe/Makefile.am
create mode 100644 src/gallium/drivers/threadsafe/Makefile.sources
create mode 100644 src/gallium/drivers/threadsafe/SConscript
create mode 100644 src/gallium/drivers/threadsafe/threadsafe.h
create mode 100644 src/gallium/drivers/threadsafe/threadsafe_context.c
create mode 100644 src/gallium/drivers/threadsafe/threadsafe_screen.c
diff --git a/src/gallium/SConscript b/src/gallium/SConscript
index eeb1c78..e6070b6 100644
--- a/src/gallium/SConscript
+++ b/src/gallium/SConscript
@@ -17,6 +17,7 @@ SConscript([
'drivers/softpipe/SConscript',
'drivers/svga/SConscript',
'drivers/trace/SConscript',
+'drivers/threadsafe/SConscript',
])
#
diff --git a/src/gallium/drivers/threadsafe/Makefile.am
b/src/gallium/drivers/threadsafe/Makefile.am
new file mode 100644
index 000..bab64bf
--- /dev/null
+++ b/src/gallium/drivers/threadsafe/Makefile.am
@@ -0,0 +1,11 @@
+include Makefile.sources
+include $(top_srcdir)/src/gallium/Automake.inc
+
+AM_CFLAGS = \
+ $(GALLIUM_DRIVER_CFLAGS)
+
+noinst_LTLIBRARIES = libthreadsafe.la
+
+libthreadsafe_la_SOURCES = $(C_SOURCES)
+
+EXTRA_DIST = SConscript
diff --git a/src/gallium/drivers/threadsafe/Makefile.sources
b/src/gallium/drivers/threadsafe/Makefile.sources
new file mode 100644
index 000..694d754
--- /dev/null
+++ b/src/gallium/drivers/threadsafe/Makefile.sources
@@ -0,0 +1,4 @@
+C_SOURCES := \
+ threadsafe.h \
+ threadsafe_context.c \
+ threadsafe_screen.c
diff --git a/src/gallium/drivers/threadsafe/SConscript
b/src/gallium/drivers/threadsafe/SConscript
new file mode 100644
index 000..bce
--- /dev/null
+++ b/src/gallium/drivers/threadsafe/SConscript
@@ -0,0 +1,13 @@
+###
+# SConscript for noop convenience library
+
+Import('*')
+
+env = env.Clone()
+
+threadsafe = env.ConvenienceLibrary(
+ target = 'threadsafe',
+ source = env.ParseSourceList('Makefile.sources', 'C_SOURCES')
+ ) + extra
+
+Export('threadsafe')
diff --git a/src/gallium/drivers/threadsafe/threadsafe.h
b/src/gallium/drivers/threadsafe/threadsafe.h
new file mode 100644
index 000..f49ff8c
--- /dev/null
+++ b/src/gallium/drivers/threadsafe/threadsafe.h
@@ -0,0 +1,39 @@
+/*
+ * Copyright 2015 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ *
+ * Authors: Tom Stellard thomas.stell...@amd.com
+ *
+ */
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+struct pipe_context;
+struct pipe_screen;
+
+struct pipe_context *pipe_threadsafe_context(struct pipe_context *ctx);
+struct pipe_screen *pipe_threadsafe_screen(struct pipe_screen *screen);
+
+#ifdef __cplusplus
+}
+#endif
diff --git a/src/gallium/drivers/threadsafe/threadsafe_context.c
Re: [Mesa-dev] [PATCH 1/3] gallium/util: fix blitter sampler view target initialization
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Wed, May 13, 2015 at 4:36 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
This was missing, and drivers relying on the target in the view could get
into quite some trouble.
---
src/gallium/auxiliary/util/u_blitter.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/auxiliary/util/u_blitter.c
b/src/gallium/auxiliary/util/u_blitter.c
index 9d087fe..24a5b93 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -1306,6 +1306,7 @@ void util_blitter_default_src_texture(struct
pipe_sampler_view *src_templ,
unsigned srclevel)
{
memset(src_templ, 0, sizeof(*src_templ));
+src_templ-target = src-target;
src_templ-format = util_format_linear(src-format);
src_templ-u.tex.first_level = srclevel;
src_templ-u.tex.last_level = srclevel;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Possible ideas for optimisations in Mesa
On Tue, 2015-05-12 at 23:09 -0700, Ian Romanick wrote:
On 05/12/2015 03:12 PM, Timothy Arceri wrote:
On Sat, 2015-04-18 at 12:26 +0200, Marek Olšák wrote:
On Fri, Apr 17, 2015 at 1:21 PM, Timothy Arceri t_arc...@yahoo.com.au
wrote:
Hi all,
Last year I spent a whole bunch of time profiling Mesa looking for areas
where improvements could be made. Anyway I thought I'd point out a
couple of things, and see if anyone thinks these are worthwhile
following up.
1. While the hash table has been getting a lot of attention lately,
after running the TF2 benchmark one place that showed up as using more
cpu than the hash table was the glsl parser. I guess this can be mostly
solved once mesa has a disk cache for shaders.
But something I came across at the time was this paper describing
modifying (with apparently little effort) bison to generate a hardcoded
parser that 2.5-6.5 times faster will generating a slightly bigger
binary [1].
The resulting project has been lost in the sands of time unfortunately
so I couldn't try it out.
2. On most of the old quake engine benchmarks the Intel driver spends
between 3-4.5% of its time or 400 million calls to glib since this code
can't be inlined in this bit of code from copy_array_to_vbo_array():
while (count--) {
memcpy(dst, src, dst_stride);
src += src_stride;
dst += dst_stride;
}
I looked in other drivers but I couldn't see them doing this kind of
thing. I'd imaging because of its nature this code could be a bottle
neck. Is there any easy ways to avoid doing this type of copy? Or would
the only thing possible be to write a complex optimisation?
Yeah, other drivers don't do this. In Gallium, we don't change the
stride when uploading buffers, so in our case src_stride ==
dst_stride.
Thanks Marek. Looking at the history of the Intel code in git it seems
when the code was first written memcpy() wasn't used and the data was
just copied 8-bits at a time. In this case you can see the advantage of
doing the copy this way, however with the use of memcpy() there doesn't
seem to be much of a difference between the code paths.
Out of interest I implemented my own version of memcpy() that can do the
copy's with mismatched strides. I did this by aligning the memory to the
8-bytes, doing some shifts in temporaries if needed and then doing 64bit
copy's.
It was made simpler for my test case because the strides were always
12-bytes = dst, 16-bytes = src.
In the end my memcpy() used slightly less cpu and could give a
measurable boost in frame rate in the UrbanTerror benchmark, although
the boost isn't always measurable and is mostly about the same. I
suspect the boost only happens when memory isn't aligned to 8-bytes.
On average there seems to be around 150 to 200 of these copy's done each
this this loop is hit in UrbanTerror so in theory my memcpy() may be
able to be made even faster with SSE using load/store and some
shuffling. I did attempt this but haven't got it work yet.
What kind of system were you measuring on? You might measure a bigger
delta on a Bay Trail system, for example. You might also try locking
the CPU clock low.
I'm using an Ivy Bridge laptop, to be exact:
Processor: Intel Core i5-3317U @ 2.60GHz (4 Cores)
Graphics: Intel HD 4000 (1050MHz)
I'll try locking the CPU to a lower clock and see what happens.
I know Eero has some tips for measuring small changes in CPU usage. It
can be... annoying. :)
In the end I'm not sure if implementing a custom memcpy() is worth all
the effort but thought I'd post my findings. My memcpy() code is a bit
of a mess at the moment but if anyone is interested I can clean it up
and push it to my github repo, just let me know.
Tim
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] include: Add helper header to help trap includes inside extern C.
On 2014-12-11 16:14, Jose Fonseca wrote: From: José Fonseca jfons...@vmware.com This is just to help repro and fixing these issues with any C++ compiler -- commiting this will of course wait until all issues are addressed. $ scons src/glsl/ scons: Reading SConscript files ... Checking for GCC ... yes Checking for Clang ... no Checking for X11 (x11 xext xdamage xfixes glproto = 1.4.13)... yes Checking for XCB (x11-xcb xcb-glx = 1.8.1 xcb-dri2 = 1.8)... yes Checking for XF86VIDMODE (xxf86vm)... yes Checking for DRM (libdrm = 2.4.38)... yes Checking for UDEV (libudev = 151)... yes warning: LLVM disabled: not building llvmpipe scons: done reading SConscript files. scons: Building targets ... scons: building associated VariantDir targets: build/linux-x86_64-debug/glsl Compiling src/glsl/ast_array_index.cpp ... Compiling src/glsl/ast_expr.cpp ... Compiling src/glsl/ast_function.cpp ... Compiling src/glsl/ast_to_hir.cpp ... Compiling src/glsl/ast_type.cpp ... Compiling src/glsl/builtin_functions.cpp ... In file included from include/c99_compat.h:28:0, from src/mapi/u_compiler.h:4, from src/mapi/u_thread.h:47, from src/mapi/glapi/glapi.h:47, from src/mesa/main/mtypes.h:42, from src/mesa/main/errors.h:47, from src/mesa/main/imports.h:41, from src/mesa/main/core.h:44, from src/glsl/builtin_functions.cpp:58: include/no_extern_c.h:48:1: error: template with C linkage templateclass T class _IncludeInsideExternCNotPortable; ^ Good morning, This change breaks all of the Haiku code as we use a *lot* of C++ code inside of Mesa (well, all the OS interfaces are C++ that wrap the Mesa C) /Builds/mesa find . -name *.cpp | grep haiku ./src/egl/drivers/haiku/egl_haiku.cpp ./src/gallium/targets/haiku-softpipe/GalliumContext.cpp ./src/gallium/targets/haiku-softpipe/SoftwareRenderer.cpp ./src/mesa/drivers/haiku/swrast/SoftwareRast.cpp Example: Compiling src/util/u_atomic_test.c ... In file included from include/c99_compat.h:28:0, from include/c11/threads.h:38, from src/mesa/main/mtypes.h:39, from src/mesa/main/errors.h:42, from src/mesa/main/imports.h:44, from src/mesa/main/context.h:52, from src/mesa/drivers/haiku/swrast/SoftwareRast.h:20, from src/mesa/drivers/haiku/swrast/SoftwareRast.cpp:14: include/no_extern_c.h:47:1: error: template with C linkage templateclass T class _IncludeInsideExternCNotPortable; ^ In file included from include/c99_compat.h:28:0, from src/gallium/include/pipe/p_compiler.h:32, from src/gallium/auxiliary/util/u_math.h:42, from src/mesa/main/macros.h:35, from src/mesa/main/colormac.h:37, from src/mesa/drivers/haiku/swrast/SoftwareRast.cpp:28: include/no_extern_c.h:47:1: error: template with C linkage templateclass T class _IncludeInsideExternCNotPortable; Any alternative fix ideas besides me adding a if !defined(__HAIKU__) to include/no_extern_c.h? -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] llvmpipe: enable ARB_texture_view
On 05/12/2015 08:36 PM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
All the functionality was pretty much there, just not tested.
Trivially fix up the missing pieces (take target info from view not
resource), and add some missing bits for cubes.
Also add some minimal debug validation to detect uninitialized target values
in the view...
49 new piglits, 47 pass, 2 fail (both related to fake multisampling,
not texture_view itself). No other piglit changes.
---
src/gallium/auxiliary/gallivm/lp_bld_sample.c | 2 +-
src/gallium/drivers/llvmpipe/lp_screen.c| 3 ++-
src/gallium/drivers/llvmpipe/lp_setup.c | 36 ++---
src/gallium/drivers/llvmpipe/lp_state_sampler.c | 36 ++---
4 files changed, 67 insertions(+), 10 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample.c
b/src/gallium/auxiliary/gallivm/lp_bld_sample.c
index 5b22045..4befb3a 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_sample.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_sample.c
@@ -113,7 +113,7 @@ lp_sampler_static_texture_state(struct
lp_static_texture_state *state,
state-swizzle_b = view-swizzle_b;
state-swizzle_a = view-swizzle_a;
- state-target= texture-target;
+ state-target= view-target;
state-pot_width = util_is_power_of_two(texture-width0);
state-pot_height= util_is_power_of_two(texture-height0);
state-pot_depth = util_is_power_of_two(texture-depth0);
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
index f4ba596..e001e53 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -258,8 +258,9 @@ llvmpipe_get_param(struct pipe_screen *screen, enum
pipe_cap param)
case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION:
return 1;
case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE:
- case PIPE_CAP_SAMPLER_VIEW_TARGET:
return 0;
+ case PIPE_CAP_SAMPLER_VIEW_TARGET:
+ return 1;
case PIPE_CAP_FAKE_SW_MSAA:
return 1;
case PIPE_CAP_CONDITIONAL_RENDER_INVERTED:
diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c
b/src/gallium/drivers/llvmpipe/lp_setup.c
index 96cc77c..4c57fab 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup.c
@@ -811,6 +811,32 @@ lp_setup_set_fragment_sampler_views(struct
lp_setup_context *setup,
*/
pipe_resource_reference(setup-fs.current_tex[i], res);
+#ifdef DEBUG
+/* this is possibly too lenient */
+ if (view-target != res-target) {
+if (view-target == PIPE_TEXTURE_1D)
+ assert(res-target == PIPE_TEXTURE_1D_ARRAY);
+else if (view-target == PIPE_TEXTURE_1D_ARRAY)
+ assert(res-target == PIPE_TEXTURE_1D);
+else if (view-target == PIPE_TEXTURE_2D)
+ assert(res-target == PIPE_TEXTURE_2D_ARRAY ||
+ res-target == PIPE_TEXTURE_CUBE ||
+ res-target == PIPE_TEXTURE_CUBE_ARRAY);
+else if (view-target == PIPE_TEXTURE_2D_ARRAY)
+ assert(res-target == PIPE_TEXTURE_2D ||
+ res-target == PIPE_TEXTURE_CUBE ||
+ res-target == PIPE_TEXTURE_CUBE_ARRAY);
+else if (view-target == PIPE_TEXTURE_CUBE)
+ assert(res-target == PIPE_TEXTURE_CUBE_ARRAY ||
+ res-target == PIPE_TEXTURE_2D_ARRAY);
+else if (view-target == PIPE_TEXTURE_CUBE_ARRAY)
+ assert(res-target == PIPE_TEXTURE_CUBE ||
+ res-target == PIPE_TEXTURE_2D_ARRAY);
+else
+ assert(0);
+ }
+#endif
+
if (!lp_tex-dt) {
/* regular texture - setup array of mipmap level offsets */
int j;
@@ -854,9 +880,10 @@ lp_setup_set_fragment_sampler_views(struct
lp_setup_context *setup,
jit_tex-img_stride[j] = lp_tex-img_stride[j];
}
- if (res-target == PIPE_TEXTURE_1D_ARRAY ||
- res-target == PIPE_TEXTURE_2D_ARRAY ||
- res-target == PIPE_TEXTURE_CUBE_ARRAY) {
+ if (view-target == PIPE_TEXTURE_1D_ARRAY ||
+ view-target == PIPE_TEXTURE_2D_ARRAY ||
+ view-target == PIPE_TEXTURE_CUBE ||
+ view-target == PIPE_TEXTURE_CUBE_ARRAY) {
/*
* For array textures, we don't have first_layer, instead
* adjust last_layer (stored as depth) plus the mip
level offsets
@@ -868,7 +895,8 @@ lp_setup_set_fragment_sampler_views(struct lp_setup_context
*setup,
jit_tex-mip_offsets[j] += view-u.tex.first_layer *
lp_tex-img_stride[j];
[Mesa-dev] [PATCH 1/2] glapi: Add extern C to glapi_priv.h
* The Haiku glapi has a C++ wrapper around
the dispatch code.
---
src/mapi/glapi/glapi_priv.h |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/mapi/glapi/glapi_priv.h b/src/mapi/glapi/glapi_priv.h
index 50f710e..337913a 100644
--- a/src/mapi/glapi/glapi_priv.h
+++ b/src/mapi/glapi/glapi_priv.h
@@ -49,6 +49,10 @@ typedef void *GLeglImageOES;
#include glapi/glapi.h
+#ifdef __cplusplus
+extern C {
+#endif
+
/* getproc */
extern void
@@ -106,4 +110,8 @@ get_entrypoint_address(unsigned int functionOffset);
#define MAX_EXTENSION_FUNCS 256
+#ifdef __cplusplus
+}
+#endif
+
#endif
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/7] mesa/es3.1: enable DRAW_INDIRECT_BUFFER_BINDING for gles3.1
On 05/06/2015 03:19 AM, Tapani Pälli wrote:
I've just noticed that this is wrong, sorry :/ We should to make a new
section for some of the enums that are only in GL core and ES31,
DRAW_INDIRECT_BUFFER_BINDING is one of these cases .. so this patch is
broken. Same may apply for some of your patches, there should not be
duplicates but only one entry per enum in the correct API section.
Hm... as far as I can tell, the primary benefit of that would be faster
rejection of GLES 3.1 enums in GLES 3.0 contexts. Maybe it will also
reduce hash collisions? It doesn't look like there are any extensions
part of 3.1 that we will exposed in 3.0 or earlier, so adding a new API
section shouldn't cause more churn later.
Maybe Kristian can comment, since the get-hash is his creation.
(Otherwise, enabling these getters for ES3.1 is correct thing todo.)
On 05/06/2015 11:53 AM, Marta Lofstedt wrote:
From: Tapani Pälli tapani.pa...@intel.com
(increases ES31-CTS.draw_indirect.basic.* passing tests)
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/get.c | 12
src/mesa/main/get_hash_params.py | 2 ++
2 files changed, 14 insertions(+)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index a881bc5..9898197 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -138,6 +138,7 @@ enum value_extra {
EXTRA_API_GL_CORE,
EXTRA_API_ES2,
EXTRA_API_ES3,
+ EXTRA_API_ES31,
EXTRA_NEW_BUFFERS,
EXTRA_NEW_FRAG_CLAMP,
EXTRA_VALID_DRAW_BUFFER,
@@ -348,6 +349,12 @@ static const int
extra_ARB_shader_image_load_store_and_geometry_shader[] = {
EXTRA_END
};
+static const int extra_ARB_draw_indirect_es31[] = {
+ EXT(ARB_draw_indirect),
+ EXTRA_API_ES31,
+ EXTRA_END
+};
+
EXTRA_EXT(ARB_texture_cube_map);
EXTRA_EXT(EXT_texture_array);
EXTRA_EXT(NV_fog_distance);
@@ -1078,6 +1085,11 @@ check_extra(struct gl_context *ctx, const char
*func, const struct value_desc *d
if (_mesa_is_gles3(ctx))
api_found = GL_TRUE;
break;
+ case EXTRA_API_ES31:
+ api_check = GL_TRUE;
+ if (_mesa_is_gles31(ctx))
+api_found = GL_TRUE;
+ break;
case EXTRA_API_GL:
api_check = GL_TRUE;
if (_mesa_is_desktop_gl(ctx))
diff --git a/src/mesa/main/get_hash_params.py
b/src/mesa/main/get_hash_params.py
index 41cb2c1..998efe8 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -407,6 +407,8 @@ descriptor=[
{ apis: [GL, GL_CORE, GLES3], params: [
# GL_ARB_sampler_objects / GL 3.3 / GLES 3.0
[ SAMPLER_BINDING, LOC_CUSTOM, TYPE_INT, GL_SAMPLER_BINDING,
NO_EXTRA ],
+# GL_ARB_draw_indirect / GLES 3.1
+ [ DRAW_INDIRECT_BUFFER_BINDING, LOC_CUSTOM, TYPE_INT, 0,
extra_ARB_draw_indirect_es31 ],
]},
# Remaining enums are only in OpenGL
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 07/25] i965/fs: Import array utils for the surface message builder.
On Wed, May 13, 2015 at 12:07 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
On Tue, May 5, 2015 at 2:48 PM, Francisco Jerez curroje...@riseup.net wrote:
Define a few transformations on register arrays which will be used
frequently during the construction of typed and untyped surface
message payloads. Their purpose is simple but the implementation is
rather messy, so it makes a lot of sense to factor them out as
separate functions.
v2: Drop VEC4 suport.
---
src/mesa/drivers/dri/i965/Makefile.sources | 2 +
.../drivers/dri/i965/brw_fs_surface_builder.cpp| 218
+
src/mesa/drivers/dri/i965/brw_fs_surface_builder.h | 31 +++
3 files changed, 251 insertions(+)
create mode 100644 src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
create mode 100644 src/mesa/drivers/dri/i965/brw_fs_surface_builder.h
diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
b/src/mesa/drivers/dri/i965/Makefile.sources
index 260e448..f299913 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -59,6 +59,8 @@ i965_FILES = \
brw_fs_register_coalesce.cpp \
brw_fs_saturate_propagation.cpp \
brw_fs_sel_peephole.cpp \
+ brw_fs_surface_builder.cpp \
+ brw_fs_surface_builder.h \
brw_fs_vector_splitting.cpp \
brw_fs_visitor.cpp \
brw_gs.c \
diff --git a/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
b/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
new file mode 100644
index 000..007d5f4
--- /dev/null
+++ b/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
@@ -0,0 +1,218 @@
+/*
+ * Copyright © 2013-2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include brw_fs_surface_builder.h
+
+using namespace brw;
+
+namespace {
+ namespace array_utils {
+ /**
+ * A plain contiguous region of memory in your register file,
+ * with well-defined size and no fancy addressing modes,
+ * swizzling or striding.
+ */
+ struct array_reg : public backend_reg {
+ array_reg() : backend_reg(), size(0)
+ {
+ }
+
+ explicit
+ array_reg(const backend_reg reg, unsigned size = 1) :
+backend_reg(reg), size(size)
+ {
+ }
+
+ /** Size of the region in 32B registers. */
+ unsigned size;
+ };
+
+ /**
+ * Increase the register base offset by the specified amount
+ * given in 32B registers.
+ */
+ array_reg
+ offset(array_reg reg, unsigned delta)
+ {
+ assert(delta == 0 || (reg.file != HW_REG reg.file != IMM));
+ reg.reg_offset += delta;
+ return reg;
+ }
+
+ /**
+ * Create a register of natural vector size and SIMD width
+ * using array \p reg as storage.
+ */
+ fs_reg
+ natural_reg(const fs_builder bld, const array_reg reg)
+ {
+ return fs_reg(reg, bld.dispatch_width());
+ }
+
+ /**
+ * Allocate a raw chunk of memory from the virtual GRF file
+ * with no special vector size or SIMD width. \p n is given
+ * in units of 32B registers.
+ */
+ array_reg
+ alloc_array_reg(const fs_builder bld, enum brw_reg_type type,
unsigned n)
+ {
+ return array_reg(
+bld.vgrf(type,
+ DIV_ROUND_UP(n * REG_SIZE,
+ type_sz(type) * bld.dispatch_width())),
+n);
+ }
+
+ /**
+ * Fetch the i-th logical component of an array of registers and
return
+ * it as a natural-width register according to the current SIMD mode.
+ *
+ * Each logical component may be in fact a vector with a number of
+ *
[Mesa-dev] [PATCH 01/20] glapi: Mark a couple functions ignore for GLX
From: Ian Romanick ian.d.roman...@intel.com Without this the next patch will try to put these functions in the dispatch table in indirect_init.c. Signed-off-by: Ian Romanick ian.d.roman...@intel.com --- src/mapi/glapi/gen/gl_API.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml index d156598..4c23bd9 100644 --- a/src/mapi/glapi/gen/gl_API.xml +++ b/src/mapi/glapi/gen/gl_API.xml @@ -6672,7 +6672,7 @@ param name=type type=GLenum/ param name=stride type=GLsizei/ param name=pointer type=const GLvoid */ -glx handcode=true/ +glx ignore=true handcode=true/ /function function name=VertexBlendARB exec=skip @@ -6738,7 +6738,7 @@ param name=type type=GLenum/ param name=stride type=GLsizei/ param name=pointer type=const GLvoid */ -glx handcode=true/ +glx ignore=true handcode=true/ /function /category -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/20] glapi: Remove static dispatch for functions that didn't exist in fglrx
From: Ian Romanick ian.d.roman...@intel.com
Comparing the output of
nm -D arch/x86_64/usr/X11R6/lib64/fglrx/fglrx-libGL.so.1.2 |\
grep ' T gl[^X]' | sed 's/.* T //'
between Catalyst 14.6 Beta and this commit, the only change is a bunch
of functions that AMD exports that Mesa does not and some OpenGL ES
1.1 functions.
The OpenGL ES 1.1 functions (e.g., glAlphaFuncx) are added by extensions
in desktop. Our infrastructure doesn't allow us to statically export a
function in one lib and not in another. The GLES1 conformance tests
expect to be able to link with these functions, so we have to export
them.
If a function is not statically exported by either of the major binary
drivers on Linux, there is almost zero chance that any application
statically links with it.
As a side note... I find it odd that AMD exports glTextureBarrierNV but
not glTextureBarrier.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mapi/glapi/gen/static_data.py | 121 --
1 file changed, 121 deletions(-)
diff --git a/src/mapi/glapi/gen/static_data.py
b/src/mapi/glapi/gen/static_data.py
index ab9c605..8489d0e 100644
--- a/src/mapi/glapi/gen/static_data.py
+++ b/src/mapi/glapi/gen/static_data.py
@@ -437,7 +437,6 @@ offsets = {
functions = [
Accum,
- ActiveProgramEXT,
ActiveTexture,
ActiveTextureARB,
AlphaFragmentOp1ATI,
@@ -445,7 +444,6 @@ functions = [
AlphaFragmentOp3ATI,
AlphaFunc,
AlphaFuncx,
- AreProgramsResidentNV,
AreTexturesResident,
AreTexturesResidentEXT,
ArrayElement,
@@ -482,7 +480,6 @@ functions = [
BindImageTexture,
BindImageTextures,
BindProgramARB,
- BindProgramNV,
BindRenderbuffer,
BindRenderbufferEXT,
BindSampler,
@@ -596,7 +593,6 @@ functions = [
ColorPointerEXT,
ColorSubTable,
ColorTable,
- ColorTableEXT,
ColorTableParameterfv,
ColorTableParameteriv,
CompileShader,
@@ -640,7 +636,6 @@ functions = [
CreateProgramObjectARB,
CreateShader,
CreateShaderObjectARB,
- CreateShaderProgramEXT,
CullFace,
DebugMessageCallback,
DebugMessageCallbackARB,
@@ -658,7 +653,6 @@ functions = [
DeletePerfMonitorsAMD,
DeleteProgram,
DeleteProgramsARB,
- DeleteProgramsNV,
DeleteQueries,
DeleteQueriesARB,
DeleteRenderbuffers,
@@ -719,8 +713,6 @@ functions = [
EdgeFlagPointer,
EdgeFlagPointerEXT,
EdgeFlagv,
- EGLImageTargetRenderbufferStorageOES,
- EGLImageTargetTexture2DOES,
Enable,
EnableClientState,
Enablei,
@@ -750,7 +742,6 @@ functions = [
EvalMesh2,
EvalPoint1,
EvalPoint2,
- ExecuteProgramNV,
FeedbackBuffer,
FenceSync,
Finish,
@@ -799,7 +790,6 @@ functions = [
GenLists,
GenPerfMonitorsAMD,
GenProgramsARB,
- GenProgramsNV,
GenQueries,
GenQueriesARB,
GenRenderbuffers,
@@ -836,11 +826,8 @@ functions = [
GetClipPlanef,
GetClipPlanex,
GetColorTable,
- GetColorTableEXT,
GetColorTableParameterfv,
- GetColorTableParameterfvEXT,
GetColorTableParameteriv,
- GetColorTableParameterivEXT,
GetCompressedTexImage,
GetCompressedTexImageARB,
GetConvolutionFilter,
@@ -903,7 +890,6 @@ functions = [
GetnUniformuivARB,
GetObjectLabel,
GetObjectParameterfvARB,
- GetObjectParameterivAPPLE,
GetObjectParameterivARB,
GetObjectPtrLabel,
GetPerfMonitorCounterDataAMD,
@@ -924,15 +910,9 @@ functions = [
GetProgramInfoLog,
GetProgramiv,
GetProgramivARB,
- GetProgramivNV,
GetProgramLocalParameterdvARB,
GetProgramLocalParameterfvARB,
- GetProgramNamedParameterdvNV,
- GetProgramNamedParameterfvNV,
- GetProgramParameterdvNV,
- GetProgramParameterfvNV,
GetProgramStringARB,
- GetProgramStringNV,
GetQueryIndexediv,
GetQueryiv,
GetQueryivARB,
@@ -973,7 +953,6 @@ functions = [
GetTexParameterIuivEXT,
GetTexParameteriv,
GetTexParameterxv,
- GetTrackMatrixivNV,
GetTransformFeedbackVarying,
GetTransformFeedbackVaryingEXT,
GetUniformBlockIndex,
@@ -988,20 +967,16 @@ functions = [
GetUniformuivEXT,
GetVertexAttribdv,
GetVertexAttribdvARB,
- GetVertexAttribdvNV,
GetVertexAttribfv,
GetVertexAttribfvARB,
- GetVertexAttribfvNV,
GetVertexAttribIiv,
GetVertexAttribIivEXT,
GetVertexAttribIuiv,
GetVertexAttribIuivEXT,
GetVertexAttribiv,
GetVertexAttribivARB,
- GetVertexAttribivNV,
GetVertexAttribPointerv,
GetVertexAttribPointervARB,
- GetVertexAttribPointervNV,
Hint,
Histogram,
Indexd,
@@ -1035,7 +1010,6 @@ functions = [
IsList,
IsProgram,
IsProgramARB,
- IsProgramNV,
IsQuery,
IsQueryARB,
IsRenderbuffer,
@@ -1070,7 +1044,6 @@ functions = [
LoadMatrixf,
LoadMatrixx,
LoadName,
- LoadProgramNV,
LoadTransposeMatrixd,
LoadTransposeMatrixdARB,
LoadTransposeMatrixf,
@@ -1204,8 +1177,6 @@ functions = [
NormalPointerEXT,
ObjectLabel,
[Mesa-dev] [PATCH 13/20] glapi: Add a list of functions that are not used but still need dispatch slots
From: Ian Romanick ian.d.roman...@intel.com Signed-off-by: Ian Romanick ian.d.roman...@intel.com --- src/mapi/glapi/gen/static_data.py | 56 +++ 1 file changed, 56 insertions(+) diff --git a/src/mapi/glapi/gen/static_data.py b/src/mapi/glapi/gen/static_data.py index cf909fc..142c503 100644 --- a/src/mapi/glapi/gen/static_data.py +++ b/src/mapi/glapi/gen/static_data.py @@ -1671,3 +1671,59 @@ functions = [ WindowPos3sv, WindowPos3svARB, ] + +Functions that need dispatch slots but are not used + +Some of these functions may have GLX protocol support (for +indirect-rendering). Other were used in previous versions of Mesa. They keep +slots in the dispatch table so that newer versions of libGL can still be used +with older drivers. +unused_functions = [ +# SGIS_multisample +SampleMaskSGIS, +SamplePatternSGIS, + +# NV_vertex_program +AreProgramsResidentNV, +ExecuteProgramNV, +GetProgramParameterdvNV, +GetProgramParameterfvNV, +GetProgramivNV, +GetProgramStringNV, +GetTrackMatrixivNV, +GetVertexAttribdvNV, +GetVertexAttribfvNV, +GetVertexAttribivNV, +LoadProgramNV, +ProgramParameters4dvNV, +ProgramParameters4fvNV, +RequestResidentProgramsNV, +TrackMatrixNV, +VertexAttribPointerNV, + +# MESA_resize_buffers +ResizeBuffersMESA, + +# ATI_envmap_bumpmap +TexBumpParameterfvATI, +TexBumpParameterivATI, +GetTexBumpParameterfvATI, +GetTexBumpParameterivATI, + +# NV_fragment_program +ProgramNamedParameter4fNV, +ProgramNamedParameter4dNV, +ProgramNamedParameter4fvNV, +ProgramNamedParameter4dvNV, +GetProgramNamedParameterfvNV, +GetProgramNamedParameterdvNV, + +# APPLE_flush_buffer_range +BufferParameteriAPPLE, +FlushMappedBufferRangeAPPLE, + +# EXT_separate_shader_objects +UseShaderProgramEXT, +ActiveProgramEXT, +CreateShaderProgramEXT, +] -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 19/20] mesa/es3.1: Enable ES 3.1 API and shading language version
From: Ian Romanick ian.d.roman...@intel.com
This is a bit of a hack for now. Several of the extensions required for
OpenGL ES 3.1 have no support, at all, in Mesa. However, with this
patch and a patch to allow MESA_GL_VERSION_OVERRIDE to work with ES
contexts, people can begin testing the ES version of the functionality
that is supported.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/main/getstring.c | 16
src/mesa/main/version.c | 18 +-
2 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/getstring.c b/src/mesa/main/getstring.c
index 1b2c7f0..72d99ca 100644
--- a/src/mesa/main/getstring.c
+++ b/src/mesa/main/getstring.c
@@ -72,10 +72,18 @@ shading_language_version(struct gl_context *ctx)
break;
case API_OPENGLES2:
- return (ctx-Version 30)
- ? (const GLubyte *) OpenGL ES GLSL ES 1.0.16
- : (const GLubyte *) OpenGL ES GLSL ES 3.00;
-
+ switch (ctx-Version) {
+ case 20:
+ return (const GLubyte *) OpenGL ES GLSL ES 1.0.16;
+ case 30:
+ return (const GLubyte *) OpenGL ES GLSL ES 3.00;
+ case 31:
+ return (const GLubyte *) OpenGL ES GLSL ES 3.10;
+ default:
+ _mesa_problem(ctx,
+ Invalid OpenGL ES version in
shading_language_version());
+ return (const GLubyte *) 0;
+ }
case API_OPENGLES:
/* fall-through */
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 699a0de..e817e2d 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -433,7 +433,23 @@ compute_version_es2(const struct gl_extensions *extensions)
extensions-EXT_texture_snorm
extensions-NV_primitive_restart
extensions-OES_depth_texture_cube_map);
- if (ver_3_0) {
+ const bool ver_3_1 = (ver_3_0
+ extensions-ARB_arrays_of_arrays
+ extensions-ARB_compute_shader
+ extensions-ARB_draw_indirect
+ false /*extensions-ARB_framebuffer_no_attachments*/
+ extensions-ARB_shader_atomic_counters
+ extensions-ARB_shader_image_load_store
+ false /*extensions-ARB_shader_image_size*/
+ false
/*extensions-ARB_shader_storage_buffer_object*/
+ extensions-ARB_shading_language_packing
+ extensions-ARB_stencil_texturing
+ extensions-ARB_gpu_shader5
+ extensions-EXT_shader_integer_mix);
+
+ if (ver_3_1) {
+ return 31;
+ } else if (ver_3_0) {
return 30;
} else if (ver_2_0) {
return 20;
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 18/20] gles/es3.1: Enable dispatch of almost all new GLES 3.1 functions
From: Ian Romanick ian.d.roman...@intel.com
A couple functions are missing because there are no implementations of
them yet. These are:
glFramebufferParameteri (from GL_ARB_framebuffer_no_attachments)
glGetFramebufferParameteriv (from GL_ARB_framebuffer_no_attachments)
glMemoryBarrierByRegion
v2: Rebase on updated dispatch_sanity.cpp test.
v3: Add support for glDraw{Arrays,Elements}Indirect in vbo_exec_array.c.
The updated dispatch_sanity.cpp test discovered this omission.
v4: Rebase on glapi changes.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mapi/glapi/gen/ARB_compute_shader.xml | 4 +-
src/mapi/glapi/gen/ARB_draw_indirect.xml | 4 +-
src/mapi/glapi/gen/ARB_program_interface_query.xml | 10 +--
src/mapi/glapi/gen/ARB_separate_shader_objects.xml | 86 ++--
src/mapi/glapi/gen/ARB_shader_image_load_store.xml | 4 +-
src/mapi/glapi/gen/ARB_texture_multisample.xml | 4 +-
.../glapi/gen/ARB_texture_storage_multisample.xml | 2 +-
src/mapi/glapi/gen/ARB_vertex_attrib_binding.xml | 10 +--
src/mapi/glapi/gen/GL3x.xml| 2 +-
src/mapi/glapi/gen/gl_API.xml | 4 +-
src/mesa/main/tests/dispatch_sanity.cpp| 95 ++
src/mesa/vbo/vbo_exec_array.c | 5 +-
12 files changed, 164 insertions(+), 66 deletions(-)
diff --git a/src/mapi/glapi/gen/ARB_compute_shader.xml
b/src/mapi/glapi/gen/ARB_compute_shader.xml
index 78d352f..c2ec842 100644
--- a/src/mapi/glapi/gen/ARB_compute_shader.xml
+++ b/src/mapi/glapi/gen/ARB_compute_shader.xml
@@ -26,13 +26,13 @@
enum name=DISPATCH_INDIRECT_BUFFER_BINDINGvalue=0x90EF/
enum name=COMPUTE_SHADER_BIT
value=0x0020/
- function name=DispatchCompute
+ function name=DispatchCompute es2=3.1
param name=num_groups_x type=GLuint/
param name=num_groups_y type=GLuint/
param name=num_groups_z type=GLuint/
/function
- function name=DispatchComputeIndirect
+ function name=DispatchComputeIndirect es2=3.1
param name=indirect type=GLintptr/
/function
/category
diff --git a/src/mapi/glapi/gen/ARB_draw_indirect.xml
b/src/mapi/glapi/gen/ARB_draw_indirect.xml
index 2001eb0..3b29d6b 100644
--- a/src/mapi/glapi/gen/ARB_draw_indirect.xml
+++ b/src/mapi/glapi/gen/ARB_draw_indirect.xml
@@ -8,12 +8,12 @@
enum name=DRAW_INDIRECT_BUFFER value=0x8F3F/
enum name=DRAW_INDIRECT_BUFFER_BINDING value=0x8F43/
-function name=DrawArraysIndirect exec=dynamic
+function name=DrawArraysIndirect exec=dynamic es2=3.1
param name=mode type=GLenum/
param name=indirect type=const GLvoid */
/function
-function name=DrawElementsIndirect exec=dynamic
+function name=DrawElementsIndirect exec=dynamic es2=3.1
param name=mode type=GLenum/
param name=type type=GLenum/
param name=indirect type=const GLvoid */
diff --git a/src/mapi/glapi/gen/ARB_program_interface_query.xml
b/src/mapi/glapi/gen/ARB_program_interface_query.xml
index 5b6d5cc..c3162f5 100644
--- a/src/mapi/glapi/gen/ARB_program_interface_query.xml
+++ b/src/mapi/glapi/gen/ARB_program_interface_query.xml
@@ -56,21 +56,21 @@
enum name=NUM_COMPATIBLE_SUBROUTINES
value=0x8E4A/
enum name=COMPATIBLE_SUBROUTINES
value=0x8E4B/
-function name=GetProgramInterfaceiv
+function name=GetProgramInterfaceiv es2=3.1
param name=program type=GLuint/
param name=programInterface type=GLenum/
param name=pname type=GLenum/
param name=params type=GLint * output=true/
/function
-function name=GetProgramResourceIndex
+function name=GetProgramResourceIndex es2=3.1
param name=program type=GLuint/
param name=programInterface type=GLenum/
param name=name type=const GLchar */
return type=GLuint/
/function
-function name=GetProgramResourceName
+function name=GetProgramResourceName es2=3.1
param name=program type=GLuint/
param name=programInterface type=GLenum/
param name=index type=GLuint/
@@ -79,7 +79,7 @@
param name=name type=GLchar * output=true/
/function
-function name=GetProgramResourceiv
+function name=GetProgramResourceiv es2=3.1
param name=program type=GLuint/
param name=programInterface type=GLenum/
param name=index type=GLuint/
@@ -90,7 +90,7 @@
param name=params type=GLint * output=true/
/function
-function name=GetProgramResourceLocation
+function name=GetProgramResourceLocation es2=3.1
param name=program type=GLuint/
param name=programInterface type=GLenum/
param name=name type=const GLchar */
diff --git a/src/mapi/glapi/gen/ARB_separate_shader_objects.xml
b/src/mapi/glapi/gen/ARB_separate_shader_objects.xml
index
[Mesa-dev] [PATCH 20/20] mesa: Allow MESA_GL_VERSION_OVERRIDE with ES contexts
From: Ian Romanick ian.d.roman...@intel.com
The bulk of the change is to prevent overriding the context to
API_OPENGL_CORE based on the requested version. If the context is
API_OPENGL_ES2, don't change it.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/drivers/dri/common/dri_util.c | 4
src/mesa/main/context.c| 4 +---
src/mesa/main/version.c| 16 +---
src/mesa/state_tracker/st_manager.c| 3 +--
4 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index d6e875f..680a907 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -163,6 +163,10 @@ driCreateNewScreen2(int scrn, int fd,
}
int gl_version_override = _mesa_get_gl_version_override();
+if (gl_version_override = 20) {
+ psp-max_gl_es2_version = MAX2(psp-max_gl_es2_version,
+ gl_version_override);
+}
if (gl_version_override = 31) {
psp-max_gl_core_version = MAX2(psp-max_gl_core_version,
gl_version_override);
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 0a192de..44a1505 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -,9 +,7 @@ _mesa_initialize_context(struct gl_context *ctx,
ctx-HasConfig = GL_FALSE;
}
- if (_mesa_is_desktop_gl(ctx)) {
- _mesa_override_gl_version(ctx);
- }
+ _mesa_override_gl_version(ctx);
/* misc one-time initializations */
one_time_init(ctx);
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index e817e2d..212b33b 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -134,13 +134,15 @@ _mesa_override_gl_version_contextless(struct gl_constants
*consts,
if (version 0) {
*versionOut = version;
- if (version = 30 fwd_context) {
- *apiOut = API_OPENGL_CORE;
- consts-ContextFlags |= GL_CONTEXT_FLAG_FORWARD_COMPATIBLE_BIT;
- } else if (version = 31 !compat_context) {
- *apiOut = API_OPENGL_CORE;
- } else {
- *apiOut = API_OPENGL_COMPAT;
+ if (*apiOut == API_OPENGL_CORE || *apiOut == API_OPENGL_COMPAT) {
+ if (version = 30 fwd_context) {
+*apiOut = API_OPENGL_CORE;
+consts-ContextFlags |= GL_CONTEXT_FLAG_FORWARD_COMPATIBLE_BIT;
+ } else if (version = 31 !compat_context) {
+*apiOut = API_OPENGL_CORE;
+ } else {
+*apiOut = API_OPENGL_COMPAT;
+ }
}
return true;
}
diff --git a/src/mesa/state_tracker/st_manager.c
b/src/mesa/state_tracker/st_manager.c
index 0376954..a2dee62 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -924,8 +924,7 @@ static unsigned get_version(struct pipe_screen *screen,
struct gl_extensions extensions = {0};
GLuint version;
- if ((api == API_OPENGL_COMPAT || api == API_OPENGL_CORE)
- _mesa_override_gl_version_contextless(consts, api, version)) {
+ if (_mesa_override_gl_version_contextless(consts, api, version)) {
return version;
}
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 16/20] glapi: Whitespace clean up after the previous commit
From: Ian Romanick ian.d.roman...@intel.com Signed-off-by: Ian Romanick ian.d.roman...@intel.com --- src/mapi/glapi/gen/ARB_base_instance.xml | 9 +- .../glapi/gen/ARB_draw_elements_base_vertex.xml| 9 +- src/mapi/glapi/gen/ARB_framebuffer_object.xml | 18 +- .../glapi/gen/ARB_vertex_type_2_10_10_10_rev.xml | 90 ++-- src/mapi/glapi/gen/NV_primitive_restart.xml| 4 +- src/mapi/glapi/gen/NV_texture_barrier.xml | 2 +- src/mapi/glapi/gen/NV_vdpau_interop.xml| 2 +- src/mapi/glapi/gen/OES_EGL_image.xml | 6 +- src/mapi/glapi/gen/OES_fixed_point.xml | 3 +- src/mapi/glapi/gen/es_EXT.xml | 6 +- src/mapi/glapi/gen/gl_API.xml | 517 +++-- 11 files changed, 223 insertions(+), 443 deletions(-) diff --git a/src/mapi/glapi/gen/ARB_base_instance.xml b/src/mapi/glapi/gen/ARB_base_instance.xml index 571e0a4..56de639 100644 --- a/src/mapi/glapi/gen/ARB_base_instance.xml +++ b/src/mapi/glapi/gen/ARB_base_instance.xml @@ -8,8 +8,7 @@ category name=GL_ARB_base_instance number=107 - function name=DrawArraysInstancedBaseInstance -exec=dynamic + function name=DrawArraysInstancedBaseInstance exec=dynamic param name=mode type=GLenum/ param name=first type=GLint/ param name=count type=GLsizei/ @@ -17,8 +16,7 @@ param name=baseinstance type=GLuint/ /function - function name=DrawElementsInstancedBaseInstance -exec=dynamic + function name=DrawElementsInstancedBaseInstance exec=dynamic param name=mode type=GLenum/ param name=count type=GLsizei/ param name=type type=GLenum/ @@ -27,8 +25,7 @@ param name=baseinstance type=GLuint/ /function - function name=DrawElementsInstancedBaseVertexBaseInstance -exec=dynamic + function name=DrawElementsInstancedBaseVertexBaseInstance exec=dynamic param name=mode type=GLenum/ param name=count type=GLsizei/ param name=type type=GLenum/ diff --git a/src/mapi/glapi/gen/ARB_draw_elements_base_vertex.xml b/src/mapi/glapi/gen/ARB_draw_elements_base_vertex.xml index 207ead3..120bda1 100644 --- a/src/mapi/glapi/gen/ARB_draw_elements_base_vertex.xml +++ b/src/mapi/glapi/gen/ARB_draw_elements_base_vertex.xml @@ -16,8 +16,7 @@ param name=basevertex type=GLint/ /function -function name=DrawRangeElementsBaseVertex - exec=dynamic +function name=DrawRangeElementsBaseVertex exec=dynamic param name=mode type=GLenum/ param name=start type=GLuint/ param name=end type=GLuint/ @@ -27,8 +26,7 @@ param name=basevertex type=GLint/ /function -function name=MultiDrawElementsBaseVertex - exec=dynamic +function name=MultiDrawElementsBaseVertex exec=dynamic param name=mode type=GLenum/ param name=count type=const GLsizei */ param name=type type=GLenum/ @@ -37,8 +35,7 @@ param name=basevertex type=const GLint */ /function -function name=DrawElementsInstancedBaseVertex - exec=dynamic +function name=DrawElementsInstancedBaseVertex exec=dynamic param name=mode type=GLenum/ param name=count type=GLsizei/ param name=type type=GLenum/ diff --git a/src/mapi/glapi/gen/ARB_framebuffer_object.xml b/src/mapi/glapi/gen/ARB_framebuffer_object.xml index 59416e6..a63e9b4 100644 --- a/src/mapi/glapi/gen/ARB_framebuffer_object.xml +++ b/src/mapi/glapi/gen/ARB_framebuffer_object.xml @@ -152,8 +152,7 @@ glx rop=235/ /function -function name=DeleteRenderbuffers - es2=2.0 +function name=DeleteRenderbuffers es2=2.0 param name=n type=GLsizei counter=true/ param name=renderbuffers type=const GLuint * count=n/ glx rop=4317/ @@ -165,8 +164,7 @@ glx vendorpriv=1423 always_array=true/ /function -function name=RenderbufferStorage - es2=2.0 +function name=RenderbufferStorage es2=2.0 param name=target type=GLenum/ param name=internalformat type=GLenum/ param name=width type=GLsizei/ @@ -202,8 +200,7 @@ glx rop=236/ /function -function name=DeleteFramebuffers - es2=2.0 +function name=DeleteFramebuffers es2=2.0 param name=n type=GLsizei counter=true/ param name=framebuffers type=const GLuint * count=n/ glx rop=4320/ @@ -215,8 +212,7 @@ glx vendorpriv=1426 always_array=true/ /function -function name=CheckFramebufferStatus - es2=2.0 +function name=CheckFramebufferStatus es2=2.0 param name=target type=GLenum/ return type=GLenum/ glx vendorpriv=1427/ @@ -231,8 +227,7 @@ glx rop=4321/ /function -function name=FramebufferTexture2D - es2=2.0 +function name=FramebufferTexture2D es2=2.0 param name=target type=GLenum/
[Mesa-dev] [PATCH 17/20] glapi: Remove offset from the DTD
From: Ian Romanick ian.d.roman...@intel.com Signed-off-by: Ian Romanick ian.d.roman...@intel.com --- src/mapi/glapi/gen/gl_API.dtd | 1 - 1 file changed, 1 deletion(-) diff --git a/src/mapi/glapi/gen/gl_API.dtd b/src/mapi/glapi/gen/gl_API.dtd index 298ba3c..bdc62f1 100644 --- a/src/mapi/glapi/gen/gl_API.dtd +++ b/src/mapi/glapi/gen/gl_API.dtd @@ -33,7 +33,6 @@ value NMTOKEN #REQUIRED !ATTLIST function nameNMTOKEN #REQUIRED alias NMTOKEN #IMPLIED - offset CDATA #IMPLIED vectorequiv NMTOKEN #IMPLIED es1 CDATA none es2 CDATA none -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 15/20] glapi: Remove all offset tags from the XML
From: Ian Romanick ian.d.roman...@intel.com Changes generated by: cd src/mapi/glapi/gen for i in *.xml; do cat $i |\ sed 's/[[:space:]]*offset=[^]*//' |\ sed 's/[[:space:]]*offset=[^]*[[:space:]]*$//' |\ sed 's/[[:space:]]*offset=[^]*[[:space:]]*/ /' x mv x $i done Signed-off-by: Ian Romanick ian.d.roman...@intel.com --- I cut out most of this patch for the mailing list. It was 394075 bytes, and the list server would have rejected it. The full patch is in my fd.o repo. src/mapi/glapi/gen/AMD_performance_monitor.xml | 22 +- src/mapi/glapi/gen/APPLE_object_purgeable.xml |6 +- src/mapi/glapi/gen/APPLE_vertex_array_object.xml |4 +- src/mapi/glapi/gen/ARB_ES2_compatibility.xml | 10 +- src/mapi/glapi/gen/ARB_base_instance.xml |6 +- src/mapi/glapi/gen/ARB_blend_func_extended.xml |4 +- src/mapi/glapi/gen/ARB_clear_buffer_object.xml |8 +- src/mapi/glapi/gen/ARB_clear_texture.xml |4 +- src/mapi/glapi/gen/ARB_clip_control.xml|2 +- src/mapi/glapi/gen/ARB_compute_shader.xml |4 +- src/mapi/glapi/gen/ARB_copy_buffer.xml |2 +- src/mapi/glapi/gen/ARB_copy_image.xml |2 +- src/mapi/glapi/gen/ARB_direct_state_access.xml | 158 +-- src/mapi/glapi/gen/ARB_draw_buffers_blend.xml |8 +- .../glapi/gen/ARB_draw_elements_base_vertex.xml|8 +- src/mapi/glapi/gen/ARB_draw_indirect.xml |8 +- src/mapi/glapi/gen/ARB_draw_instanced.xml |4 +- src/mapi/glapi/gen/ARB_framebuffer_object.xml | 40 +- src/mapi/glapi/gen/ARB_get_program_binary.xml |6 +- src/mapi/glapi/gen/ARB_gpu_shader_fp64.xml | 36 +- src/mapi/glapi/gen/ARB_internalformat_query.xml|2 +- src/mapi/glapi/gen/ARB_invalidate_subdata.xml | 12 +- src/mapi/glapi/gen/ARB_map_buffer_range.xml|4 +- src/mapi/glapi/gen/ARB_multi_bind.xml | 12 +- src/mapi/glapi/gen/ARB_program_interface_query.xml | 12 +- src/mapi/glapi/gen/ARB_robustness.xml | 40 +- src/mapi/glapi/gen/ARB_sampler_objects.xml | 28 +- src/mapi/glapi/gen/ARB_separate_shader_objects.xml | 122 +- src/mapi/glapi/gen/ARB_shader_atomic_counters.xml |2 +- src/mapi/glapi/gen/ARB_shader_image_load_store.xml |4 +- src/mapi/glapi/gen/ARB_sync.xml| 14 +- src/mapi/glapi/gen/ARB_texture_buffer_range.xml|2 +- src/mapi/glapi/gen/ARB_texture_multisample.xml |8 +- src/mapi/glapi/gen/ARB_texture_storage.xml | 12 +- .../glapi/gen/ARB_texture_storage_multisample.xml |4 +- src/mapi/glapi/gen/ARB_texture_view.xml|2 +- src/mapi/glapi/gen/ARB_uniform_buffer_object.xml | 14 +- src/mapi/glapi/gen/ARB_vertex_array_object.xml |8 +- src/mapi/glapi/gen/ARB_vertex_attrib_64bit.xml | 20 +- src/mapi/glapi/gen/ARB_vertex_attrib_binding.xml | 12 +- .../glapi/gen/ARB_vertex_type_2_10_10_10_rev.xml | 76 +- src/mapi/glapi/gen/ARB_viewport_array.xml | 20 +- src/mapi/glapi/gen/EXT_framebuffer_object.xml |4 +- src/mapi/glapi/gen/EXT_gpu_shader4.xml | 28 +- src/mapi/glapi/gen/EXT_provoking_vertex.xml|2 +- src/mapi/glapi/gen/EXT_separate_shader_objects.xml |6 +- src/mapi/glapi/gen/EXT_texture_integer.xml |4 +- src/mapi/glapi/gen/EXT_transform_feedback.xml | 16 +- src/mapi/glapi/gen/GL3x.xml| 100 +- src/mapi/glapi/gen/GL4x.xml|2 +- src/mapi/glapi/gen/INTEL_performance_query.xml | 20 +- src/mapi/glapi/gen/KHR_debug.xml | 20 +- src/mapi/glapi/gen/NV_primitive_restart.xml|2 +- src/mapi/glapi/gen/NV_texture_barrier.xml |2 +- src/mapi/glapi/gen/NV_vdpau_interop.xml| 20 +- src/mapi/glapi/gen/OES_EGL_image.xml |4 +- src/mapi/glapi/gen/OES_fixed_point.xml |6 +- src/mapi/glapi/gen/es_EXT.xml | 22 +- src/mapi/glapi/gen/gl_API.xml | 1462 ++-- src/mapi/glapi/gen/gl_and_es_API.xml | 86 +- 60 files changed, 1289 insertions(+), 1289 deletions(-) diff --git a/src/mapi/glapi/gen/AMD_performance_monitor.xml b/src/mapi/glapi/gen/AMD_performance_monitor.xml index b96b263..41b5208 100644 --- a/src/mapi/glapi/gen/AMD_performance_monitor.xml +++ b/src/mapi/glapi/gen/AMD_performance_monitor.xml @@ -5,13 +5,13 @@ category name=GL_AMD_performance_monitor number=360 -function name=GetPerfMonitorGroupsAMD offset=assign +function name=GetPerfMonitorGroupsAMD param name=numGroups type=GLint */ param name=groupsSize type=GLsizei/ param name=groups type=GLuint */ /function -function name=GetPerfMonitorCountersAMD offset=assign +function
[Mesa-dev] [PATCH 12/20] glapi: Remove static dispatch for functions that didn't exist in NVIDIA
From: Ian Romanick ian.d.roman...@intel.com Comparing the output of nm -D libGL.so.349.16 | grep ' T gl[^X]' | sed 's/.* T //' between Catalyst NVIDIA 349.16 and this commit, the only change is a bunch of functions that NVIDIA exports that Mesa does not. If a function is not statically exported by either of the major binary drivers on Linux, there is almost zero chance that any application statically links with it. Signed-off-by: Ian Romanick ian.d.roman...@intel.com --- src/mapi/glapi/gen/static_data.py | 46 --- 1 file changed, 46 deletions(-) diff --git a/src/mapi/glapi/gen/static_data.py b/src/mapi/glapi/gen/static_data.py index 8489d0e..cf909fc 100644 --- a/src/mapi/glapi/gen/static_data.py +++ b/src/mapi/glapi/gen/static_data.py @@ -439,9 +439,6 @@ functions = [ Accum, ActiveTexture, ActiveTextureARB, - AlphaFragmentOp1ATI, - AlphaFragmentOp2ATI, - AlphaFragmentOp3ATI, AlphaFunc, AlphaFuncx, AreTexturesResident, @@ -453,28 +450,21 @@ functions = [ Begin, BeginConditionalRender, BeginConditionalRenderNV, - BeginFragmentShaderATI, - BeginPerfMonitorAMD, BeginQuery, BeginQueryARB, BeginQueryIndexed, BeginTransformFeedback, - BeginTransformFeedbackEXT, BindAttribLocation, BindAttribLocationARB, BindBuffer, BindBufferARB, BindBufferBase, - BindBufferBaseEXT, - BindBufferOffsetEXT, BindBufferRange, - BindBufferRangeEXT, BindBuffersBase, BindBuffersRange, BindFragDataLocation, BindFragDataLocationEXT, BindFragDataLocationIndexed, - BindFragmentShaderATI, BindFramebuffer, BindFramebufferEXT, BindImageTexture, @@ -497,17 +487,13 @@ functions = [ BlendEquation, BlendEquationEXT, BlendEquationiARB, - BlendEquationIndexedAMD, BlendEquationSeparate, BlendEquationSeparateiARB, - BlendEquationSeparateIndexedAMD, BlendFunc, BlendFunciARB, - BlendFuncIndexedAMD, BlendFuncSeparate, BlendFuncSeparateEXT, BlendFuncSeparateiARB, - BlendFuncSeparateIndexedAMD, BlitFramebuffer, BufferData, BufferDataARB, @@ -578,9 +564,6 @@ functions = [ Color4us, Color4usv, Color4x, - ColorFragmentOp1ATI, - ColorFragmentOp2ATI, - ColorFragmentOp3ATI, ColorMask, ColorMaski, ColorMaskIndexedEXT, @@ -623,13 +606,9 @@ functions = [ CopyImageSubData, CopyPixels, CopyTexImage1D, - CopyTexImage1DEXT, CopyTexImage2D, - CopyTexImage2DEXT, CopyTexSubImage1D, - CopyTexSubImage1DEXT, CopyTexSubImage2D, - CopyTexSubImage2DEXT, CopyTexSubImage3D, CopyTexSubImage3DEXT, CreateProgram, @@ -645,12 +624,10 @@ functions = [ DebugMessageInsertARB, DeleteBuffers, DeleteBuffersARB, - DeleteFragmentShaderATI, DeleteFramebuffers, DeleteFramebuffersEXT, DeleteLists, DeleteObjectARB, - DeletePerfMonitorsAMD, DeleteProgram, DeleteProgramsARB, DeleteQueries, @@ -722,14 +699,11 @@ functions = [ End, EndConditionalRender, EndConditionalRenderNV, - EndFragmentShaderATI, EndList, - EndPerfMonitorAMD, EndQuery, EndQueryARB, EndQueryIndexed, EndTransformFeedback, - EndTransformFeedbackEXT, EvalCoord1d, EvalCoord1dv, EvalCoord1f, @@ -784,11 +758,9 @@ functions = [ GenBuffersARB, GenerateMipmap, GenerateMipmapEXT, - GenFragmentShadersATI, GenFramebuffers, GenFramebuffersEXT, GenLists, - GenPerfMonitorsAMD, GenProgramsARB, GenQueries, GenQueriesARB, @@ -892,12 +864,6 @@ functions = [ GetObjectParameterfvARB, GetObjectParameterivARB, GetObjectPtrLabel, - GetPerfMonitorCounterDataAMD, - GetPerfMonitorCounterInfoAMD, - GetPerfMonitorCountersAMD, - GetPerfMonitorCounterStringAMD, - GetPerfMonitorGroupsAMD, - GetPerfMonitorGroupStringAMD, GetPixelMapfv, GetPixelMapuiv, GetPixelMapusv, @@ -935,8 +901,6 @@ functions = [ GetString, GetStringi, GetSynciv, - GetTexBumpParameterfvATI, - GetTexBumpParameterivATI, GetTexEnvfv, GetTexEnviv, GetTexEnvxv, @@ -954,7 +918,6 @@ functions = [ GetTexParameteriv, GetTexParameterxv, GetTransformFeedbackVarying, - GetTransformFeedbackVaryingEXT, GetUniformBlockIndex, GetUniformfv, GetUniformfvARB, @@ -1180,7 +1143,6 @@ functions = [ Ortho, Orthof, Orthox, - PassTexCoordATI, PassThrough, PauseTransformFeedback, PixelMapfv, @@ -1287,7 +1249,6 @@ functions = [ SampleCoverage, SampleCoverageARB, SampleCoveragex, - SampleMapATI, SampleMaski, SamplerParameterf, SamplerParameterfv, @@ -1339,9 +1300,7 @@ functions = [ SecondaryColorPointer, SecondaryColorPointerEXT, SelectBuffer, - SelectPerfMonitorCountersAMD, SeparableFilter2D, - SetFragmentShaderConstantATI, ShadeModel, ShaderBinary, ShaderSource, @@ -1355,8 +1314,6 @@ functions = [ TexBuffer,
Re: [Mesa-dev] [PATCH 07/25] i965/fs: Import array utils for the surface message builder.
On Tue, May 5, 2015 at 2:48 PM, Francisco Jerez curroje...@riseup.net wrote:
Define a few transformations on register arrays which will be used
frequently during the construction of typed and untyped surface
message payloads. Their purpose is simple but the implementation is
rather messy, so it makes a lot of sense to factor them out as
separate functions.
v2: Drop VEC4 suport.
---
src/mesa/drivers/dri/i965/Makefile.sources | 2 +
.../drivers/dri/i965/brw_fs_surface_builder.cpp| 218
+
src/mesa/drivers/dri/i965/brw_fs_surface_builder.h | 31 +++
3 files changed, 251 insertions(+)
create mode 100644 src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
create mode 100644 src/mesa/drivers/dri/i965/brw_fs_surface_builder.h
diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
b/src/mesa/drivers/dri/i965/Makefile.sources
index 260e448..f299913 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -59,6 +59,8 @@ i965_FILES = \
brw_fs_register_coalesce.cpp \
brw_fs_saturate_propagation.cpp \
brw_fs_sel_peephole.cpp \
+ brw_fs_surface_builder.cpp \
+ brw_fs_surface_builder.h \
brw_fs_vector_splitting.cpp \
brw_fs_visitor.cpp \
brw_gs.c \
diff --git a/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
b/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
new file mode 100644
index 000..007d5f4
--- /dev/null
+++ b/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
@@ -0,0 +1,218 @@
+/*
+ * Copyright © 2013-2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include brw_fs_surface_builder.h
+
+using namespace brw;
+
+namespace {
+ namespace array_utils {
+ /**
+ * A plain contiguous region of memory in your register file,
+ * with well-defined size and no fancy addressing modes,
+ * swizzling or striding.
+ */
+ struct array_reg : public backend_reg {
+ array_reg() : backend_reg(), size(0)
+ {
+ }
+
+ explicit
+ array_reg(const backend_reg reg, unsigned size = 1) :
+backend_reg(reg), size(size)
+ {
+ }
+
+ /** Size of the region in 32B registers. */
+ unsigned size;
+ };
+
+ /**
+ * Increase the register base offset by the specified amount
+ * given in 32B registers.
+ */
+ array_reg
+ offset(array_reg reg, unsigned delta)
+ {
+ assert(delta == 0 || (reg.file != HW_REG reg.file != IMM));
+ reg.reg_offset += delta;
+ return reg;
+ }
+
+ /**
+ * Create a register of natural vector size and SIMD width
+ * using array \p reg as storage.
+ */
+ fs_reg
+ natural_reg(const fs_builder bld, const array_reg reg)
+ {
+ return fs_reg(reg, bld.dispatch_width());
+ }
+
+ /**
+ * Allocate a raw chunk of memory from the virtual GRF file
+ * with no special vector size or SIMD width. \p n is given
+ * in units of 32B registers.
+ */
+ array_reg
+ alloc_array_reg(const fs_builder bld, enum brw_reg_type type,
unsigned n)
+ {
+ return array_reg(
+bld.vgrf(type,
+ DIV_ROUND_UP(n * REG_SIZE,
+ type_sz(type) * bld.dispatch_width())),
+n);
+ }
+
+ /**
+ * Fetch the i-th logical component of an array of registers and return
+ * it as a natural-width register according to the current SIMD mode.
+ *
+ * Each logical component may be in fact a vector with a number of
+ * per-channel values depending on the dispatch width and SIMD mode.
+ * E.g. a single
Re: [Mesa-dev] i965 implementation of the ARB_shader_image_load_store built-ins. (v3)
I haven't said much about this series up until now. I've mostly sat and watched and focused my time on other things. As I said in the meeting today, I think that part of the problem here is that there are at least 3 refactors in here besides the new feature. By refactors, I mean new ways of solving problem X. Part of the problem with the discussion is that all of this has been conflated and we aren't actually talking about how to solve each of those problems. I'm going to try and break it out here to try and aid in the discussion. 1) The builder. I think *everyone* likes the builder. The argument here is not over whether or not we want it. People have expressed concern that adding the builder now without actually doing the refactor will result in duplicated code that will get out-of-sync. I think the best solution here is to go ahead and do the builder stuff immediately after the branch point. 2) SIMD8 instruction splitting. As I said in the call, we've done this a variety of ways in the past usually by emitting the split instructions in the visitor and manually using half() and inst-force_sechalf. We also have a few places that I think still split the code in the generator. What you're doing is a somewhat more elegant version of the emit it in the visitor stuff that we've done in the past. You've got your zip/unzip functions etc. to handle splitting and combining and then you have a loop to actually emit the sends. Really, it's fairly nice and concise. The question is whether or not it's really what we want to do (more on this in a bit). 3) Array reg. This is something of a helper to (2). I agree that it's nice to be able to have access to the size of a register without having to look at the allocator. The problem here (and why we don't have a size in fs_reg) is that we copy the reigster around. Every register does have some sort of underlying storage that it shares with other registers with the same number. But that storage is represented by the size in the allocator and nothing else. Is that bad? Maybe. Should we have a way of passing the size around with it? Maybe. In any case, I think it's best to table this discussion until we've talked a bit about (2) because I think the resolution there will make (3) more clear. One note on 3 before we table it. People have been pulling emit_collect out as a straw-man and beating on it but I really do like it in principle. There are piles of times where you want a payload and you have to allocate an array, do stuff, and then put it into the payload and it's really annoying. It would be much easier if we had a helper that just did it all in one function and that's what emit_collect tries to do. *Thank you* for finally trying to solve that problem and make payloads less painful! However, I do wish it were implemented a bit differently but I'll make those comments on the patch itself. ### SIMD16 Instruction Splitting ### SIMD16 instruction splitting is an unfortunate fact of our hardware. There are a variety of times we have to do it including dual-source FB writes, some texturing, math ops on older gens and maybe another place or two. Classically, this has been done in one of two places: The visitor as we emit the code, or the generator. The problem with doing it in the generator is that we can't schedule it and, if it involves a payload, it's not really possible. The result is that we usually do it in the visitor these days. Unfortunately, even in the visitor, it's gen-specific and annoying. It gets even worse when you're working with something such as the untyped surface read/write messages that work with multi-component values that have to be zipped/unzipped to use Curro's terminology. Curro came up with some helper functions to make it substantially less annoying but it still involves nasty looping. At some point in the past I proposed a completely different and more solution to this problem. Unfortunately, while I've talked to Matt Ken about it, it's never really been discussed all that publicly so Curro may not be aware of it. I'm going to lay it out here for Curro's sake as well as the sake of public record. The solution involves first changing the way we handle sends into a two step process. First, we emit a logical instruction that contains all of the data needed for the actual instruction. Then, we convert from the logical to the actual in a lowering pass. Take, for example, FB writes with which I am fairly familiar. We would first emit a logical FS_FB_WRITE_# instruction that has separate sources for color, depth, replicated alpha, etc. Then, in the lower_fb_writes pass (which we would have to implement), we would construct the payload from the sources provided on the logical instruction and emit the actual LOAD_PAYLOAD and FB_WRITE instructions. This lower_fb_writes function would then get called before the optimization loop so that the rest of the optimization could would never see it. Second, we add a
Re: [Mesa-dev] [PATCH] util/u_atomic: use STATIC_ASSERT() when selecting the appropriate function
On 13/05/15 16:43, Matt Turner wrote: On Wed, May 13, 2015 at 10:37 AM, Emil Velikov emil.l.veli...@gmail.com wrote: As we evaluate sizeof() at compile time, having the run-time assert() does not provide any benefits. Move to the compile-time version STATIC_ASSERT() which will kindly prompt us when this go wrong. Cc: Matt Turner matts...@gmail.com Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- Oh, good idea. Presumably you confirmed that the STATIC_ASSERT triggers at compile-time when you pass an unsupported type to the macro? If so, With some hacking[1] it did trigger. Just in case, Vinson - can you try this patch [2] on a Windows/SolarisOS VM please ? Reviewed-by: Matt Turner matts...@gmail.com Thanks ! -Emil [1] The asserts are only for the Windows/Solaris code, so I copied the logic to the Linux/GCC build, and dropped on the sizeof(*v) == sizeof(uint64_t) case. [2] http://patchwork.freedesktop.org/patch/49235/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glapi: Add extern C to glapi_priv.h
On 05/13/2015 12:25 PM, Alexander von Gluck IV wrote:
* The Haiku glapi has a C++ wrapper around
the dispatch code.
I think you can drop the * and put the comment on one line.
Otherwise, for both,
Reviewed-by: Brian Paul bri...@vmware.com
---
src/mapi/glapi/glapi_priv.h |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/mapi/glapi/glapi_priv.h b/src/mapi/glapi/glapi_priv.h
index 50f710e..337913a 100644
--- a/src/mapi/glapi/glapi_priv.h
+++ b/src/mapi/glapi/glapi_priv.h
@@ -49,6 +49,10 @@ typedef void *GLeglImageOES;
#include glapi/glapi.h
+#ifdef __cplusplus
+extern C {
+#endif
+
/* getproc */
extern void
@@ -106,4 +110,8 @@ get_entrypoint_address(unsigned int functionOffset);
#define MAX_EXTENSION_FUNCS 256
+#ifdef __cplusplus
+}
+#endif
+
#endif
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/20] mesa: Remove all vestiges of glFramebufferTextureFaceARB
From: Ian Romanick ian.d.roman...@intel.com
Mesa does not (and probably never will) support GL_ARB_geometry_shader4,
so this function will never exist. Having a function that is
exec=skip and offset=assign is just weird.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mapi/glapi/gen/ARB_geometry_shader4.xml | 2 +-
src/mapi/glapi/tests/check_table.cpp| 1 -
src/mesa/main/dlist.c | 30 +
src/mesa/main/tests/dispatch_sanity.cpp | 9 +++--
4 files changed, 5 insertions(+), 37 deletions(-)
diff --git a/src/mapi/glapi/gen/ARB_geometry_shader4.xml
b/src/mapi/glapi/gen/ARB_geometry_shader4.xml
index e62047c..280e7a0 100644
--- a/src/mapi/glapi/gen/ARB_geometry_shader4.xml
+++ b/src/mapi/glapi/gen/ARB_geometry_shader4.xml
@@ -45,7 +45,7 @@
param name=level type=GLint/
param name=layer type=GLint/
/function
-function name=FramebufferTextureFaceARB exec=skip offset=assign
+function name=FramebufferTextureFaceARB exec=skip
param name=target type=GLenum/
param name=attachment type=GLenum/
param name=texture type=GLuint/
diff --git a/src/mapi/glapi/tests/check_table.cpp
b/src/mapi/glapi/tests/check_table.cpp
index 5d759df..09bf4f3 100644
--- a/src/mapi/glapi/tests/check_table.cpp
+++ b/src/mapi/glapi/tests/check_table.cpp
@@ -1137,7 +1137,6 @@ const struct name_offset known_dispatch[] = {
{ glDrawElementsInstancedARB, _O(DrawElementsInstancedARB) },
{ glRenderbufferStorageMultisample, _O(RenderbufferStorageMultisample) },
{ glFramebufferTexture, _O(FramebufferTexture) },
- { glFramebufferTextureFaceARB, _O(FramebufferTextureFaceARB) },
{ glProgramParameteri, _O(ProgramParameteri) },
{ glVertexAttribDivisor, _O(VertexAttribDivisor) },
{ glFlushMappedBufferRange, _O(FlushMappedBufferRange) },
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index 431c4b4..aafe486 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -7592,28 +7592,6 @@ save_FramebufferTexture(GLenum target, GLenum attachment,
}
}
-static void GLAPIENTRY
-save_FramebufferTextureFace(GLenum target, GLenum attachment,
-GLuint texture, GLint level, GLenum face)
-{
- Node *n;
- GET_CURRENT_CONTEXT(ctx);
- ASSERT_OUTSIDE_SAVE_BEGIN_END_AND_FLUSH(ctx);
- n = alloc_instruction(ctx, OPCODE_FRAMEBUFFER_TEXTURE_FACE, 5);
- if (n) {
- n[1].e = target;
- n[2].e = attachment;
- n[3].ui = texture;
- n[4].i = level;
- n[5].e = face;
- }
- if (ctx-ExecuteFlag) {
- CALL_FramebufferTextureFaceARB(ctx-Exec, (target, attachment, texture,
- level, face));
- }
-}
-
-
static void GLAPIENTRY
save_WaitSync(GLsync sync, GLbitfield flags, GLuint64 timeout)
@@ -8873,11 +8851,6 @@ execute_list(struct gl_context *ctx, GLuint list)
CALL_FramebufferTexture(ctx-Exec, (n[1].e, n[2].e,
n[3].ui, n[4].i));
break;
- case OPCODE_FRAMEBUFFER_TEXTURE_FACE:
-CALL_FramebufferTextureFaceARB(ctx-Exec, (n[1].e, n[2].e,
- n[3].ui, n[4].i,
n[5].e));
-break;
-
/* GL_ARB_sync */
case OPCODE_WAIT_SYNC:
{
@@ -9644,10 +9617,9 @@ _mesa_initialize_save_table(const struct gl_context *ctx)
SET_BlendEquationiARB(table, save_BlendEquationi);
SET_BlendEquationSeparateiARB(table, save_BlendEquationSeparatei);
- /* GL_ARB_geometry_shader4 */
+ /* OpenGL 3.2 */
SET_ProgramParameteri(table, save_ProgramParameteri);
SET_FramebufferTexture(table, save_FramebufferTexture);
- SET_FramebufferTextureFaceARB(table, save_FramebufferTextureFace);
/* GL_NV_conditional_render */
SET_BeginConditionalRender(table, save_BeginConditionalRender);
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index ccd0124..eb70a0d 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -535,12 +535,9 @@ const struct function gl_core_functions_possible[] = {
{ glGetInteger64i_v, 32, -1 },
{ glGetBufferParameteri64v, 32, -1 },
{ glFramebufferTexture, 32, -1 },
-
- /* GL_ARB_geometry_shader4 */
- { glProgramParameteriARB, 32, -1 },
- { glFramebufferTextureARB, 32, -1 },
- { glFramebufferTextureLayerARB, 32, -1 },
- { glFramebufferTextureFaceARB, 32, -1 },
+ { glProgramParameteri, 32, -1 },
+ { glFramebufferTexture, 32, -1 },
+ { glFramebufferTextureLayer, 32, -1 },
/* GL 3.3 */
{ glVertexAttribDivisor, 33, -1 },
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/20] glapi: Remove static dispatch for functions that didn't exist in 10.5
From: Ian Romanick ian.d.roman...@intel.com Comparing the output of nm libGL.so | grep ' T gl[^X]' | sed 's/.* T //' between 10.5.5 and this commit, the only change is the removal of glFramebufferTextureFaceARB. This function was removed a couple commits previously. None of these functions are particuarly new. If applications were not statically linking them with 10.5.5, there's approximately zero chance they will for 10.6. Signed-off-by: Ian Romanick ian.d.roman...@intel.com --- src/mapi/glapi/gen/static_data.py | 81 --- 1 file changed, 81 deletions(-) diff --git a/src/mapi/glapi/gen/static_data.py b/src/mapi/glapi/gen/static_data.py index a1983ff..b3cddc2 100644 --- a/src/mapi/glapi/gen/static_data.py +++ b/src/mapi/glapi/gen/static_data.py @@ -540,8 +540,6 @@ functions = [ ClearDepthf, ClearDepthx, ClearIndex, - ClearNamedBufferData, - ClearNamedBufferSubData, ClearStencil, ClearTexImage, ClearTexSubImage, @@ -632,7 +630,6 @@ functions = [ CopyConvolutionFilter1D, CopyConvolutionFilter2D, CopyImageSubData, - CopyNamedBufferSubData, CopyPixels, CopyTexImage1D, CopyTexImage1DEXT, @@ -647,19 +644,12 @@ functions = [ CopyTextureSubImage1D, CopyTextureSubImage2D, CopyTextureSubImage3D, - CreateBuffers, CreateProgram, CreateProgramObjectARB, - CreateProgramPipelines, - CreateQueries, - CreateRenderbuffers, - CreateSamplers, CreateShader, CreateShaderObjectARB, CreateShaderProgramEXT, CreateTextures, - CreateTransformFeedbacks, - CreateVertexArrays, CullFace, DebugMessageCallback, DebugMessageCallbackARB, @@ -702,7 +692,6 @@ functions = [ DisableClientState, Disablei, DisableIndexedEXT, - DisableVertexArrayAttrib, DisableVertexAttribArray, DisableVertexAttribArrayARB, DispatchCompute, @@ -745,7 +734,6 @@ functions = [ EnableClientState, Enablei, EnableIndexedEXT, - EnableVertexArrayAttrib, EnableVertexAttribArray, EnableVertexAttribArrayARB, End, @@ -777,7 +765,6 @@ functions = [ Finish, Flush, FlushMappedBufferRange, - FlushMappedNamedBufferRange, FogCoordd, FogCoorddEXT, FogCoorddv, @@ -907,11 +894,6 @@ functions = [ GetMinmaxParameterfv, GetMinmaxParameteriv, GetMultisamplefv, - GetNamedBufferParameteri64v, - GetNamedBufferParameteriv, - GetNamedBufferPointerv, - GetNamedBufferSubData, - GetNamedRenderbufferParameteriv, GetnColorTableARB, GetnCompressedTexImageARB, GetnConvolutionFilterARB, @@ -951,7 +933,6 @@ functions = [ GetProgramEnvParameterdvARB, GetProgramEnvParameterfvARB, GetProgramInfoLog, - GetProgramInterfaceiv, GetProgramiv, GetProgramivARB, GetProgramivNV, @@ -961,17 +942,8 @@ functions = [ GetProgramNamedParameterfvNV, GetProgramParameterdvNV, GetProgramParameterfvNV, - GetProgramResourceIndex, - GetProgramResourceiv, - GetProgramResourceLocation, - GetProgramResourceLocationIndex, - GetProgramResourceName, GetProgramStringARB, GetProgramStringNV, - GetQueryBufferObjecti64v, - GetQueryBufferObjectiv, - GetQueryBufferObjectui64v, - GetQueryBufferObjectuiv, GetQueryIndexediv, GetQueryiv, GetQueryivARB, @@ -1020,13 +992,9 @@ functions = [ GetTextureParameterIuiv, GetTextureParameteriv, GetTrackMatrixivNV, - GetTransformFeedbacki64_v, - GetTransformFeedbackiv, - GetTransformFeedbacki_v, GetTransformFeedbackVarying, GetTransformFeedbackVaryingEXT, GetUniformBlockIndex, - GetUniformdv, GetUniformfv, GetUniformfvARB, GetUniformIndices, @@ -1036,9 +1004,6 @@ functions = [ GetUniformLocationARB, GetUniformuiv, GetUniformuivEXT, - GetVertexArrayIndexed64iv, - GetVertexArrayIndexediv, - GetVertexArrayiv, GetVertexAttribdv, GetVertexAttribdvARB, GetVertexAttribdvNV, @@ -1052,7 +1017,6 @@ functions = [ GetVertexAttribiv, GetVertexAttribivARB, GetVertexAttribivNV, - GetVertexAttribLdv, GetVertexAttribPointerv, GetVertexAttribPointervARB, GetVertexAttribPointervNV, @@ -1142,8 +1106,6 @@ functions = [ MapGrid1f, MapGrid2d, MapGrid2f, - MapNamedBuffer, - MapNamedBufferRange, Materialf, Materialfv, Materiali, @@ -1242,11 +1204,6 @@ functions = [ MultTransposeMatrixdARB, MultTransposeMatrixf, MultTransposeMatrixfARB, - NamedBufferData, - NamedBufferStorage, - NamedBufferSubData, - NamedRenderbufferStorage, - NamedRenderbufferStorageMultisample, NewList, Normal3b, Normal3bv, @@ -1547,7 +1504,6 @@ functions = [ TextureBarrier, TextureBarrierNV, TextureBuffer, - TextureBufferRange, TextureParameterf, TextureParameterfv, TextureParameteri, @@ -1567,15 +1523,11 @@ functions = [ TextureSubImage3D, TextureView, TrackMatrixNV, - TransformFeedbackBufferBase, -
[Mesa-dev] [PATCH 00/20] glapi yak shaving and GLES 3.1 enabling
We've known for a long time that having all those tags in the function entries in the XML is bad. For example, people cut-and-paste for everything, and, as a result, we export a bunch of functions that we should not. We also really want to just use the Khronos XML. This series takes a couple small steps towards that. Patches 1 and 2 are just a couple of clean-ups to prevent regressions in later patches. Patches 3, 13, 14, 15, 16, and 17 remove the offset= tags from the XML. Patch 15 was quite large, so it was trimmed. Patches 4, 5, and 6 remove the static_dispatch= tags from the XML. Patch 5 was quite large, so it was trimmed. Patches 7 through 12 un-export a bunch of static dispatch functions. At the end, we only export the functions that Mesa 10.3 and NVIDIA and AMD export (with a couple minor exceptions noted in patches 8 and 11. The last 3 patches are just rebased resends of earlier patches. The whole series is availble in the gles3.1-enabling branch of my fd.o tree at git://people.freedesktop.org/~idr/mesa. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/20] glapi: Whitespace clean up after the previous commit
From: Ian Romanick ian.d.roman...@intel.com Signed-off-by: Ian Romanick ian.d.roman...@intel.com --- src/mapi/glapi/gen/APPLE_vertex_array_object.xml | 6 +- src/mapi/glapi/gen/ARB_internalformat_query.xml | 3 +- src/mapi/glapi/gen/OES_fixed_point.xml | 114 ++-- src/mapi/glapi/gen/OES_single_precision.xml | 15 +-- src/mapi/glapi/gen/es_EXT.xml| 162 --- src/mapi/glapi/gen/gl_API.xml| 22 ++- 6 files changed, 112 insertions(+), 210 deletions(-) diff --git a/src/mapi/glapi/gen/APPLE_vertex_array_object.xml b/src/mapi/glapi/gen/APPLE_vertex_array_object.xml index 08c1b86..9410e4e 100644 --- a/src/mapi/glapi/gen/APPLE_vertex_array_object.xml +++ b/src/mapi/glapi/gen/APPLE_vertex_array_object.xml @@ -5,8 +5,7 @@ category name=GL_APPLE_vertex_array_object number=273 enum name=VERTEX_ARRAY_BINDING_APPLE value=0x85B5/ -function name=BindVertexArrayAPPLE offset=assign - deprecated=3.1 +function name=BindVertexArrayAPPLE offset=assign deprecated=3.1 param name=array type=GLuint/ /function @@ -15,8 +14,7 @@ param name=arrays type=const GLuint */ /function -function name=GenVertexArraysAPPLE offset=assign - deprecated=3.1 +function name=GenVertexArraysAPPLE offset=assign deprecated=3.1 param name=n type=GLsizei/ param name=arrays type=GLuint * count=n output=true/ /function diff --git a/src/mapi/glapi/gen/ARB_internalformat_query.xml b/src/mapi/glapi/gen/ARB_internalformat_query.xml index 9c3154f..48e3a16 100644 --- a/src/mapi/glapi/gen/ARB_internalformat_query.xml +++ b/src/mapi/glapi/gen/ARB_internalformat_query.xml @@ -8,8 +8,7 @@ enum name=NUM_SAMPLE_COUNTSvalue=0x9380/ -function name=GetInternalformativ offset=assign - es2=3.0 +function name=GetInternalformativ offset=assign es2=3.0 param name=target type=GLenum/ param name=internalformat type=GLenum/ param name=pname type=GLenum/ diff --git a/src/mapi/glapi/gen/OES_fixed_point.xml b/src/mapi/glapi/gen/OES_fixed_point.xml index 7f0b95d..8f3bfd0 100644 --- a/src/mapi/glapi/gen/OES_fixed_point.xml +++ b/src/mapi/glapi/gen/OES_fixed_point.xml @@ -19,29 +19,25 @@ param name=ref type=GLclampx/ /function -function name=ClearColorxOES - es1=1.0 alias=ClearColorx +function name=ClearColorxOES es1=1.0 alias=ClearColorx param name=red type=GLclampx/ param name=green type=GLclampx/ param name=blue type=GLclampx/ param name=alpha type=GLclampx/ /function -function name=ClearDepthxOES - es1=1.0 alias=ClearDepthx +function name=ClearDepthxOES es1=1.0 alias=ClearDepthx param name=depth type=GLclampx/ /function -function name=Color4xOES - es1=1.0 alias=Color4x +function name=Color4xOES es1=1.0 alias=Color4x param name=red type=GLfixed/ param name=green type=GLfixed/ param name=blue type=GLfixed/ param name=alpha type=GLfixed/ /function -function name=DepthRangexOES - es1=1.0 alias=DepthRangex +function name=DepthRangexOES es1=1.0 alias=DepthRangex param name=zNear type=GLclampx/ param name=zFar type=GLclampx/ /function @@ -51,14 +47,12 @@ param name=param type=GLfixed/ /function -function name=FogxvOES - es1=1.0 alias=Fogxv +function name=FogxvOES es1=1.0 alias=Fogxv param name=pname type=GLenum/ param name=params type=const GLfixed */ /function -function name=FrustumxOES - es1=1.0 alias=Frustumx +function name=FrustumxOES es1=1.0 alias=Frustumx param name=left type=GLfixed/ param name=right type=GLfixed/ param name=bottom type=GLfixed/ @@ -67,63 +61,53 @@ param name=zFar type=GLfixed/ /function -function name=LightModelxOES - es1=1.0 alias=LightModelx +function name=LightModelxOES es1=1.0 alias=LightModelx param name=pname type=GLenum/ param name=param type=GLfixed/ /function -function name=LightModelxvOES - es1=1.0 alias=LightModelxv +function name=LightModelxvOES es1=1.0 alias=LightModelxv param name=pname type=GLenum/ param name=params type=const GLfixed */ /function -function name=LightxOES - es1=1.0 alias=Lightx +function name=LightxOES es1=1.0 alias=Lightx param name=light type=GLenum/ param name=pname type=GLenum/ param name=param type=GLfixed/ /function -function name=LightxvOES - es1=1.0 alias=Lightxv +function name=LightxvOES es1=1.0 alias=Lightxv param name=light type=GLenum/ param name=pname type=GLenum/ param name=params type=const GLfixed */ /function
[Mesa-dev] [PATCH 03/20] glapi: Store static dispatch offsets in a separate table
From: Ian Romanick ian.d.roman...@intel.com
Since the set of functions with static will never change, there is no
reason to store it in the XML. It's just one of those fields that
confuses people adding new functions.
This is split out from the rest of the series so that in-code assertions
can be used to verify that the data in the Python code matches the XML.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Dylan Baker baker.dyla...@gmail.com
---
src/mapi/glapi/gen/Makefile.am| 2 +
src/mapi/glapi/gen/gl_XML.py | 8 +
src/mapi/glapi/gen/static_data.py | 436 ++
3 files changed, 446 insertions(+)
create mode 100644 src/mapi/glapi/gen/static_data.py
diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
index c8d4174..4d23f82 100644
--- a/src/mapi/glapi/gen/Makefile.am
+++ b/src/mapi/glapi/gen/Makefile.am
@@ -75,6 +75,7 @@ EXTRA_DIST= \
glX_proto_size.py \
glX_server_table.py \
remap_helper.py \
+ static_data.py \
SConscript \
gl_API.dtd
@@ -197,6 +198,7 @@ COMMON = $(API_XML) \
gl_XML.py \
glX_XML.py \
license.py \
+ static_data.py \
typeexpr.py
COMMON_GLX = $(COMMON) glX_API.xml glX_XML.py glX_proto_common.py
diff --git a/src/mapi/glapi/gen/gl_XML.py b/src/mapi/glapi/gen/gl_XML.py
index 1a2bc2b..0695f84 100644
--- a/src/mapi/glapi/gen/gl_XML.py
+++ b/src/mapi/glapi/gen/gl_XML.py
@@ -30,6 +30,7 @@ import xml.etree.ElementTree as ET
import re, sys, string
import os.path
import typeexpr
+import static_data
def parse_GL_API( file_name, factory = None ):
@@ -694,6 +695,13 @@ class gl_function( gl_item ):
if offset == assign:
self.assign_offset = 1
+if self.offset == -1:
+assert name not in static_data.offsets
+else:
+assert static_data.offsets[name] == self.offset
+else:
+assert name not in static_data.offsets
+
if not self.name:
self.name = true_name
diff --git a/src/mapi/glapi/gen/static_data.py
b/src/mapi/glapi/gen/static_data.py
new file mode 100644
index 000..2ce093c
--- /dev/null
+++ b/src/mapi/glapi/gen/static_data.py
@@ -0,0 +1,436 @@
+#!/usr/bin/env python
+
+# Copyright (C) 2015 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the Software),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+# IN THE SOFTWARE.
+
+Table of functions that have ABI-mandated offsets in the dispatch table.
+
+This list will never change.
+offsets = {
+NewList: 0,
+EndList: 1,
+CallList: 2,
+CallLists: 3,
+DeleteLists: 4,
+GenLists: 5,
+ListBase: 6,
+Begin: 7,
+Bitmap: 8,
+Color3b: 9,
+Color3bv: 10,
+Color3d: 11,
+Color3dv: 12,
+Color3f: 13,
+Color3fv: 14,
+Color3i: 15,
+Color3iv: 16,
+Color3s: 17,
+Color3sv: 18,
+Color3ub: 19,
+Color3ubv: 20,
+Color3ui: 21,
+Color3uiv: 22,
+Color3us: 23,
+Color3usv: 24,
+Color4b: 25,
+Color4bv: 26,
+Color4d: 27,
+Color4dv: 28,
+Color4f: 29,
+Color4fv: 30,
+Color4i: 31,
+Color4iv: 32,
+Color4s: 33,
+Color4sv: 34,
+Color4ub: 35,
+Color4ubv: 36,
+Color4ui: 37,
+Color4uiv: 38,
+Color4us: 39,
+Color4usv: 40,
+EdgeFlag: 41,
+EdgeFlagv: 42,
+End: 43,
+Indexd: 44,
+Indexdv: 45,
+Indexf: 46,
+Indexfv: 47,
+Indexi: 48,
+Indexiv: 49,
+Indexs: 50,
+Indexsv: 51,
+Normal3b: 52,
+Normal3bv: 53,
+Normal3d: 54,
+Normal3dv: 55,
+Normal3f: 56,
+Normal3fv: 57,
+Normal3i: 58,
+Normal3iv: 59,
+Normal3s: 60,
+Normal3sv: 61,
+RasterPos2d: 62,
+RasterPos2dv: 63,
+RasterPos2f: 64,
+RasterPos2fv: 65,
+RasterPos2i: 66,
+RasterPos2iv: 67,
+RasterPos2s: 68,
+RasterPos2sv: 69,
+RasterPos3d: 70,
+RasterPos3dv:
[Mesa-dev] [PATCH 14/20] glapi: Use the offsets from static_data.py instead of from the XML
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Dylan Baker baker.dyla...@gmail.com
---
src/mapi/glapi/gen/gl_XML.py | 22 +-
1 file changed, 5 insertions(+), 17 deletions(-)
diff --git a/src/mapi/glapi/gen/gl_XML.py b/src/mapi/glapi/gen/gl_XML.py
index 89b09f2..67aba81 100644
--- a/src/mapi/glapi/gen/gl_XML.py
+++ b/src/mapi/glapi/gen/gl_XML.py
@@ -626,7 +626,7 @@ class gl_function( gl_item ):
# Decimal('1.1') }.
self.api_map = {}
-self.assign_offset = 0
+self.assign_offset = False
self.static_entry_points = []
@@ -685,23 +685,11 @@ class gl_function( gl_item ):
# Only try to set the offset when a non-alias entry-point
# is being processed.
-offset = element.get( offset )
-if offset:
-try:
-o = int( offset )
-self.offset = o
-except Exception, e:
-self.offset = -1
-if offset == assign:
-self.assign_offset = 1
-
-if self.offset == -1:
-assert name not in static_data.offsets
-else:
-assert static_data.offsets[name] == self.offset
+if name in static_data.offsets:
+self.offset = static_data.offsets[name]
else:
-assert name not in static_data.offsets
-
+self.offset = -1
+self.assign_offset = self.exec_flavor != skip or name in
static_data.unused_functions
if not self.name:
self.name = true_name
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/20] glapi: Remove static_dispatch from the DTD
From: Ian Romanick ian.d.roman...@intel.com Signed-off-by: Ian Romanick ian.d.roman...@intel.com --- src/mapi/glapi/gen/gl_API.dtd | 1 - 1 file changed, 1 deletion(-) diff --git a/src/mapi/glapi/gen/gl_API.dtd b/src/mapi/glapi/gen/gl_API.dtd index ab321fa..298ba3c 100644 --- a/src/mapi/glapi/gen/gl_API.dtd +++ b/src/mapi/glapi/gen/gl_API.dtd @@ -34,7 +34,6 @@ !ATTLIST function nameNMTOKEN #REQUIRED alias NMTOKEN #IMPLIED offset CDATA #IMPLIED - static_dispatch (true | false) true vectorequiv NMTOKEN #IMPLIED es1 CDATA none es2 CDATA none -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util/u_atomic: use STATIC_ASSERT() when selecting the appropriate function
On 05/13/2015 01:18 PM, Francisco Jerez wrote: Emil Velikov emil.l.veli...@gmail.com writes: As we evaluate sizeof() at compile time, having the run-time assert() does not provide any benefits. Move to the compile-time version STATIC_ASSERT() which will kindly prompt us when this go wrong. This doesn't look right. AFAIK STATIC_ASSERT() is implemented by expanding to an array type-id of negative size, which is an error regardless of whether the sizeof expression is evaluated or not: i.e. 0 ? sizeof(invalid) : ... is still an error for the same reason that 0 * sizeof(invalid) or (void)sizeof(invalid) is an error. That and also that the whole thing is wrapped in a do-while loop you cannot use as operand of the ternary operator... Yeah, this does not build with MSVC: C:\Users\Brian\projects\mesa\src\gallium\auxiliary\util/u_inlines.h(83) : error C2059: syntax error : 'do' C:\Users\Brian\projects\mesa\src\gallium\auxiliary\util/u_inlines.h(83) : error C2143: syntax error : missing ';' before ',' C:\Users\Brian\projects\mesa\src\gallium\auxiliary\util/u_inlines.h(83) : error C2059: syntax error : ')' C:\Users\Brian\projects\mesa\src\gallium\auxiliary\util/u_inlines.h(89) : error C2059: syntax error : 'do' [...] -Brian Cc: Matt Turner matts...@gmail.com Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/util/u_atomic.h | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/src/util/u_atomic.h b/src/util/u_atomic.h index e38395a..10c0cca 100644 --- a/src/util/u_atomic.h +++ b/src/util/u_atomic.h @@ -86,7 +86,7 @@ #endif #include windows.h #include intrin.h -#include assert.h +#include util/macros.h #if _MSC_VER 1600 @@ -166,7 +166,7 @@ _InterlockedExchangeAdd8(char volatile *addend, char value) sizeof *(_v) == sizeof(short) ? _InterlockedIncrement16((short *) (_v)) : \ sizeof *(_v) == sizeof(long)? _InterlockedIncrement ((long *) (_v)) : \ sizeof *(_v) == sizeof(__int64) ? InterlockedIncrement64 ((__int64 *)(_v)) : \ - (assert(!should not get here), 0)) + (STATIC_ASSERT(!should not get here), 0)) #define p_atomic_dec(_v) \ ((void) p_atomic_dec_return(_v)) @@ -175,21 +175,21 @@ _InterlockedExchangeAdd8(char volatile *addend, char value) sizeof *(_v) == sizeof(short) ? _InterlockedDecrement16((short *) (_v)) : \ sizeof *(_v) == sizeof(long)? _InterlockedDecrement ((long *) (_v)) : \ sizeof *(_v) == sizeof(__int64) ? InterlockedDecrement64 ((__int64 *)(_v)) : \ - (assert(!should not get here), 0)) + (STATIC_ASSERT(!should not get here), 0)) #define p_atomic_add(_v, _i) (\ sizeof *(_v) == sizeof(char)? _InterlockedExchangeAdd8 ((char *) (_v), (_i)) : \ sizeof *(_v) == sizeof(short) ? _InterlockedExchangeAdd16((short *) (_v), (_i)) : \ sizeof *(_v) == sizeof(long)? _InterlockedExchangeAdd ((long *) (_v), (_i)) : \ sizeof *(_v) == sizeof(__int64) ? InterlockedExchangeAdd64((__int64 *)(_v), (_i)) : \ - (assert(!should not get here), 0)) + (STATIC_ASSERT(!should not get here), 0)) #define p_atomic_cmpxchg(_v, _old, _new) (\ sizeof *(_v) == sizeof(char)? _InterlockedCompareExchange8 ((char *) (_v), (char) (_new), (char) (_old)) : \ sizeof *(_v) == sizeof(short) ? _InterlockedCompareExchange16((short *) (_v), (short) (_new), (short) (_old)) : \ sizeof *(_v) == sizeof(long)? _InterlockedCompareExchange ((long *) (_v), (long) (_new), (long) (_old)) : \ sizeof *(_v) == sizeof(__int64) ? InterlockedCompareExchange64 ((__int64 *)(_v), (__int64)(_new), (__int64)(_old)) : \ - (assert(!should not get here), 0)) + (STATIC_ASSERT(!should not get here), 0)) #endif @@ -198,7 +198,7 @@ _InterlockedExchangeAdd8(char volatile *addend, char value) #define PIPE_ATOMIC Solaris OS atomic functions #include atomic.h -#include assert.h +#include util/macros.h #define p_atomic_set(_v, _i) (*(_v) = (_i)) #define p_atomic_read(_v) (*(_v)) @@ -208,49 +208,49 @@ _InterlockedExchangeAdd8(char volatile *addend, char value) sizeof(*v) == sizeof(uint16_t) ? atomic_dec_16_nv((uint16_t *)(v)) == 0 : \ sizeof(*v) == sizeof(uint32_t) ? atomic_dec_32_nv((uint32_t *)(v)) == 0 : \ sizeof(*v) == sizeof(uint64_t) ? atomic_dec_64_nv((uint64_t *)(v)) == 0 : \ -(assert(!should not get here), 0)) +(STATIC_ASSERT(!should not get here), 0)) #define p_atomic_inc(v) (void) (\ sizeof(*v) == sizeof(uint8_t) ? atomic_inc_8 ((uint8_t *)(v)) : \ sizeof(*v) == sizeof(uint16_t) ? atomic_inc_16((uint16_t *)(v)) : \ sizeof(*v)
Re: [Mesa-dev] [PATCH 00/20] glapi yak shaving and GLES 3.1 enabling
On 05/13/2015 12:44 PM, Ian Romanick wrote: We've known for a long time that having all those tags in the function entries in the XML is bad. For example, people cut-and-paste for everything, and, as a result, we export a bunch of functions that we should not. We also really want to just use the Khronos XML. This series takes a couple small steps towards that. Patches 1 and 2 are just a couple of clean-ups to prevent regressions in later patches. Patches 3, 13, 14, 15, 16, and 17 remove the offset= tags from the XML. Patch 15 was quite large, so it was trimmed. Patches 4, 5, and 6 remove the static_dispatch= tags from the XML. Patch 5 was quite large, so it was trimmed. Patches 7 through 12 un-export a bunch of static dispatch functions. At the end, we only export the functions that Mesa 10.3 and NVIDIA and AMD export (with a couple minor exceptions noted in patches 8 and 11. The last 3 patches are just rebased resends of earlier patches. The whole series is availble in the gles3.1-enabling branch of my fd.o tree at git://people.freedesktop.org/~idr/mesa. I should have also noted that - I piglit tested this on our Jenkins server. - I verified several combinations of libGL and driver libGL from master, driver from branch libGL from branch, driver from master libGL from branch, driver from 10.3 A driver from the branch will not work with a libGL from 10.3 due to http://lists.freedesktop.org/archives/mesa-dev/2015-April/083116.html. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90438] glxinfo should have a quiet mode
https://bugs.freedesktop.org/show_bug.cgi?id=90438 --- Comment #2 from Bryan Quigley gquigs+b...@gmail.com --- Created attachment 115750 -- https://bugs.freedesktop.org/attachment.cgi?id=115750action=edit adds quiet option Adds -q quiet option to glxinfo. Just changes what is printed, not what is collected. Example output: name of display: :0.0 display: :0 screen: 0 direct rendering: Yes OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 750 Ti/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA 346.59 OpenGL core profile shading language version string: 4.50 NVIDIA OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL version string: 4.5.0 NVIDIA 346.59 OpenGL shading language version string: 4.50 NVIDIA OpenGL context flags: (none) OpenGL profile mask: (none) OpenGL ES profile version string: OpenGL ES 3.1 NVIDIA 346.59 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10 -- You are receiving this mail because: You are the QA Contact for the bug. 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] util/u_atomic: use STATIC_ASSERT() when selecting the appropriate function
On 13 May 2015 at 21:01, Brian Paul bri...@vmware.com wrote: On 05/13/2015 01:18 PM, Francisco Jerez wrote: Emil Velikov emil.l.veli...@gmail.com writes: As we evaluate sizeof() at compile time, having the run-time assert() does not provide any benefits. Move to the compile-time version STATIC_ASSERT() which will kindly prompt us when this go wrong. This doesn't look right. AFAIK STATIC_ASSERT() is implemented by expanding to an array type-id of negative size, which is an error regardless of whether the sizeof expression is evaluated or not: i.e. 0 ? sizeof(invalid) : ... is still an error for the same reason that 0 * sizeof(invalid) or (void)sizeof(invalid) is an error. That and also that the whole thing is wrapped in a do-while loop you cannot use as operand of the ternary operator... Yeah, this does not build with MSVC: C:\Users\Brian\projects\mesa\src\gallium\auxiliary\util/u_inlines.h(83) : error C2059: syntax error : 'do' C:\Users\Brian\projects\mesa\src\gallium\auxiliary\util/u_inlines.h(83) : error C2143: syntax error : missing ';' before ',' C:\Users\Brian\projects\mesa\src\gallium\auxiliary\util/u_inlines.h(83) : error C2059: syntax error : ')' C:\Users\Brian\projects\mesa\src\gallium\auxiliary\util/u_inlines.h(89) : error C2059: syntax error : 'do' [...] This one goes straight into the bitbin. Thanks for the explanation Francisco and test Brian. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Stable libEGL ABI ?
On 05/13/2015 04:14 PM, Emil Velikov wrote: On 13 May 2015 at 17:46, Chad Versace chad.vers...@intel.com wrote: On Fri 08 May 2015, Emil Velikov wrote: Hi all, Just had a quick look at Debian's repo and noticed something rather worrying - the ABI of our libEGL is not stable. Stable in the sense of - we provide a growing list of static symbols for each new function an EGL extension adds. This comes as we set EGL_EGLEXT_PROTOTYPES, prior to including eglext.h. Which in turn exposes the the function prototypes which are explicitly annotated with default visibility. This change was introduced with commit 1ed1027e886980b9b0f48fa6bfcf3d6e209c7787 Author: Brian Paul brian.p...@tungstengraphics.com Date: Tue May 27 13:45:41 2008 -0600 assorted changes to compile with new EGL 1.4 headers (untested) From going through the EGL 1.3 to 1.5 spec, I cannot see any mention that one should export EGL extension functions from their implementation. On the contrary, it is explicitly mentioned that some implementations may do so, but relying on it in your program is not portable. Quick look at the Nvidia official driver shows only core EGL functions, which aligns with various undefined symbol eglCreateImageKHR issues that I've seen not too long ago - mir, gstreamer, piglit. So the question here is: Can we break the already non-portable ABI, and hide everything that is not core EGL, or alternatively how can we rework things so that as we add new entry points, required by extensions, they are available only dynamically ? Personally I would opt for the former and address any issues in piglit/waffle/foo accordingly. I would suspect that libepoxy is OK, although I've never looked too closely at the code. I would love to get this in some shape or form for 10.6, and avoid exporting the two new functions from EGL_MESA_image_dma_buf_export :-\ Me too. As I explained in a previous message [1], I think we should scrub the non-portable ABI sooner rather than later. I don't consider this a break, because it was non-portable all along. Thanks for the review and confirmation Chad. That's precisely why I placed quotes around the word :-) Brian, I'm planning to push the series that resolves tomorrow evening(ish). Can you let me know if you have any objections/conserns prior to that. I haven't touched EGL in years so whatever you guys think is best is fine with me. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Stable libEGL ABI ?
On 13 May 2015 at 17:46, Chad Versace chad.vers...@intel.com wrote: On Fri 08 May 2015, Emil Velikov wrote: Hi all, Just had a quick look at Debian's repo and noticed something rather worrying - the ABI of our libEGL is not stable. Stable in the sense of - we provide a growing list of static symbols for each new function an EGL extension adds. This comes as we set EGL_EGLEXT_PROTOTYPES, prior to including eglext.h. Which in turn exposes the the function prototypes which are explicitly annotated with default visibility. This change was introduced with commit 1ed1027e886980b9b0f48fa6bfcf3d6e209c7787 Author: Brian Paul brian.p...@tungstengraphics.com Date: Tue May 27 13:45:41 2008 -0600 assorted changes to compile with new EGL 1.4 headers (untested) From going through the EGL 1.3 to 1.5 spec, I cannot see any mention that one should export EGL extension functions from their implementation. On the contrary, it is explicitly mentioned that some implementations may do so, but relying on it in your program is not portable. Quick look at the Nvidia official driver shows only core EGL functions, which aligns with various undefined symbol eglCreateImageKHR issues that I've seen not too long ago - mir, gstreamer, piglit. So the question here is: Can we break the already non-portable ABI, and hide everything that is not core EGL, or alternatively how can we rework things so that as we add new entry points, required by extensions, they are available only dynamically ? Personally I would opt for the former and address any issues in piglit/waffle/foo accordingly. I would suspect that libepoxy is OK, although I've never looked too closely at the code. I would love to get this in some shape or form for 10.6, and avoid exporting the two new functions from EGL_MESA_image_dma_buf_export :-\ Me too. As I explained in a previous message [1], I think we should scrub the non-portable ABI sooner rather than later. I don't consider this a break, because it was non-portable all along. Thanks for the review and confirmation Chad. That's precisely why I placed quotes around the word :-) Brian, I'm planning to push the series that resolves tomorrow evening(ish). Can you let me know if you have any objections/conserns prior to that. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] include: Add helper header to help trap includes inside extern C.
On May 13, 2015 8:01 AM, kallisti5 kallis...@unixzen.com wrote: On 2014-12-11 16:14, Jose Fonseca wrote: From: José Fonseca jfons...@vmware.com This is just to help repro and fixing these issues with any C++ compiler -- commiting this will of course wait until all issues are addressed. $ scons src/glsl/ scons: Reading SConscript files ... Checking for GCC ... yes Checking for Clang ... no Checking for X11 (x11 xext xdamage xfixes glproto = 1.4.13)... yes Checking for XCB (x11-xcb xcb-glx = 1.8.1 xcb-dri2 = 1.8)... yes Checking for XF86VIDMODE (xxf86vm)... yes Checking for DRM (libdrm = 2.4.38)... yes Checking for UDEV (libudev = 151)... yes warning: LLVM disabled: not building llvmpipe scons: done reading SConscript files. scons: Building targets ... scons: building associated VariantDir targets: build/linux-x86_64-debug/glsl Compiling src/glsl/ast_array_index.cpp ... Compiling src/glsl/ast_expr.cpp ... Compiling src/glsl/ast_function.cpp ... Compiling src/glsl/ast_to_hir.cpp ... Compiling src/glsl/ast_type.cpp ... Compiling src/glsl/builtin_functions.cpp ... In file included from include/c99_compat.h:28:0, from src/mapi/u_compiler.h:4, from src/mapi/u_thread.h:47, from src/mapi/glapi/glapi.h:47, from src/mesa/main/mtypes.h:42, from src/mesa/main/errors.h:47, from src/mesa/main/imports.h:41, from src/mesa/main/core.h:44, from src/glsl/builtin_functions.cpp:58: include/no_extern_c.h:48:1: error: template with C linkage templateclass T class _IncludeInsideExternCNotPortable; ^ Good morning, This change breaks all of the Haiku code as we use a *lot* of C++ code inside of Mesa (well, all the OS interfaces are C++ that wrap the Mesa C) /Builds/mesa find . -name *.cpp | grep haiku ./src/egl/drivers/haiku/egl_haiku.cpp ./src/gallium/targets/haiku-softpipe/GalliumContext.cpp ./src/gallium/targets/haiku-softpipe/SoftwareRenderer.cpp ./src/mesa/drivers/haiku/swrast/SoftwareRast.cpp Example: Compiling src/util/u_atomic_test.c ... In file included from include/c99_compat.h:28:0, from include/c11/threads.h:38, from src/mesa/main/mtypes.h:39, from src/mesa/main/errors.h:42, from src/mesa/main/imports.h:44, from src/mesa/main/context.h:52, from src/mesa/drivers/haiku/swrast/SoftwareRast.h:20, from src/mesa/drivers/haiku/swrast/SoftwareRast.cpp:14: include/no_extern_c.h:47:1: error: template with C linkage templateclass T class _IncludeInsideExternCNotPortable; ^ In file included from include/c99_compat.h:28:0, from src/gallium/include/pipe/p_compiler.h:32, from src/gallium/auxiliary/util/u_math.h:42, from src/mesa/main/macros.h:35, from src/mesa/main/colormac.h:37, from src/mesa/drivers/haiku/swrast/SoftwareRast.cpp:28: include/no_extern_c.h:47:1: error: template with C linkage templateclass T class _IncludeInsideExternCNotPortable; Any alternative fix ideas besides me adding a if !defined(__HAIKU__) to include/no_extern_c.h? Please do not do that! The whole point of this patch is to catch places where headers are included inside an extern C block. This patch makes them a compile error instead of being silently wrong. The correct solution is to fix the haiku platform integration so it doesn't do this. --Jason -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl: more define fixes for EGL_MESA_image_dma_buf_export
On Mon 11 May 2015, Emil Velikov wrote:
On 11 May 2015 at 20:07, Emil Velikov emil.l.veli...@gmail.com wrote:
On 11 May 2015 at 14:23, Marc-André Lureau marcandre.lur...@gmail.com
wrote:
s/EGL_MESA_dma_buf_image_export/EGL_MESA_image_dma_buf_export as defined
by the spec
---
src/egl/main/eglapi.c | 2 +-
src/egl/main/eglfallbacks.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index ba1d0dd..6d2b51d 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
@@ -1245,7 +1245,7 @@ eglGetProcAddress(const char *procname)
{ eglCreatePlatformWindowSurfaceEXT, (_EGLProc)
eglCreatePlatformWindowSurfaceEXT },
{ eglCreatePlatformPixmapSurfaceEXT, (_EGLProc)
eglCreatePlatformPixmapSurfaceEXT },
{ eglGetSyncValuesCHROMIUM, (_EGLProc) eglGetSyncValuesCHROMIUM },
-#ifdef EGL_MESA_dma_buf_image_export
+#ifdef EGL_MESA_image_dma_buf_export
{ eglExportDMABUFImageQueryMESA, (_EGLProc)
eglExportDMABUFImageQueryMESA },
{ eglExportDMABUFImageMESA, (_EGLProc) eglExportDMABUFImageMESA },
#endif
diff --git a/src/egl/main/eglfallbacks.c b/src/egl/main/eglfallbacks.c
index 83d7756..ef65d2c 100644
--- a/src/egl/main/eglfallbacks.c
+++ b/src/egl/main/eglfallbacks.c
@@ -120,7 +120,7 @@ _eglInitDriverFallbacks(_EGLDriver *drv)
drv-API.SwapBuffersRegionNOK = NULL;
#endif
-#ifdef EGL_MESA_dma_buf_image_export
+#ifdef EGL_MESA_image_dma_buf_export
drv-API.ExportDMABUFImageQueryMESA = NULL;
drv-API.ExportDMABUFImageMESA = NULL;
#endif
Considering how these can go (have been) subtly broken without many
people realising can we just nuke the #ifdef spaghetti ? I'm
suspecting that they are present in order to prevent build issues,
when the compiler picks up the non-mesa headers - egl{,ext}.h.
Wouldn't it be better to coerce the compiler to prioritise the mesa
headers over the rest ? GCC's -isystem and automake's nostdinc comes
to mind, but I never had the pleasure to work with either one.
^^ is not meant as an objection against the patch (if it ever come
across as such).
This little patch fixes the extension, so
Reviewed-by: Chad Versace chad.vers...@intel.com
As Emil, I want to nuke the #ifdef spaghetti too. It's always bothered
me, and I've never understood why it's there. The #ifdefs occasionally
breaks things, and I've never seem them used for any benefit.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] i965 implementation of the ARB_shader_image_load_store built-ins. (v2)
Matt Turner matts...@gmail.com writes: On Tue, May 5, 2015 at 2:17 PM, Francisco Jerez curroje...@riseup.net wrote: Kenneth Graunke kenn...@whitecape.org writes: I like the idea of the builder refactor - having a mechanism for emitting code at arbitrary points makes a ton of sense. But I'm uncomfortable with how much code is added - and duplicated from the existing visitor code - given that fs_visitor is refactored to use it. I agree with Jason that we should discuss our goal - what things should look like - but frankly, I think we should hold off on large scale refactoring until after we delete the GLSL IR backend. There will be much less code to reorganize. I agree, I wasn't planning on migrating the rest of the compiler back-end to the builder framework until that happens. We talked about this on IRC yesterday -- I find it difficult to review some of these patches adding large amounts of new infrastructure that's only used in other in this series. Basically, the problem is that you're adding (1) a large amount of new infrastructure, and (2) a large amount of tiling calculation/format conversion code and neither can be independently evaluated. If the new infrastructure was proposed and we could see how it was useful in the existing compiler, we could evaluate it. If the new tiling calculation/format conversion code used existing compiler infrastructure, we could evaluate it. Combining the two in the same series though makes it difficult. Matt, I know that a 3k LOC series might be intimidating at first glance, but: - The additional infrastructure is badly needed. If you've bothered to read the commit message [maybe longest in (our git tree's) history] or skimmed through the body of the fs_builder patch, read the 6-screenful e-mail I sent you last October including a detailed explanation of the builder, or any of the working sample code (including a port of large parts of existing compiler code) I sent you back then, you surely already know that I'm not doing this on a whim. The infrastructure equivalent to the builder should have *never* been part of the GLSL IR visitor, and the more new functionality we throw at the compiler relying on the old infrastructure the more difficult the migration will get. - Nothing prevents you from evaluating the builder framework independent from the tiling and format conversion code. You have more than enough information to assess whether the change is reasonable on its own. You have the lengthy explanation from last October. You have sample code from last October showing how it's useful in the existing compiler -- And for the case that doesn't seem convincing enough I'm attaching a partial port of brw_fs_visitor.cpp to the builder framework based on a current tree [but note that it's just an example and not meant to be upstreamed]. You have enough knowledge of the existing infrastructure that hardly anything about the new infrastructure will come as a surprise for you -- It largely mimics the existing IR-building methods, their semantics and implementation, and the transition from one to the other usually amounts to replacing emit(FOO(...)) with bld.FOO(...). You have enough documentation in the code itself -- I've spent a great deal of time documenting the builder framework and the image load/store implementation [to a much greater extent than is usual in the rest of the back-end code, a quickly written bash script gives a comment-to-code ratio of 31% vs. the average of 19% in the rest of the FS back-end]. Lastly you have me to answer any questions that could come up during review -- And the fact that you haven't asked any specific technical questions so far other than about codestyle and logistics makes me think that you haven't really attempted to understand the code in detail yet, and the supposed difficulty you talk about may be based on a presumption rather than on your actual experience. - Even if I turn out to be wrong, your evaluation is inconclusive for some strange reason, and the new infrastructure is merged with some hidden architectural flaw, the risk is close to non-existent. The worst thing that could happen is we have to flip the switch to disable ARB_shader_image_load_store again until the problem is fixed. No critical functionality is affected because the new infrastructure is completely self-contained. It seems like we'd be buying into a transition to the new builder without having seen what the transition looks like ([switching to the new infrastructure] will be undertaken by a separate series, as it involves major back-end surgery). That's not nearly what I meant. Of course whether and how we carry out the transition will still be open for discussion, that statement you quote was intended to show that I'm willing to do the hard work and not going to abandon the new
[Mesa-dev] [PATCH] i965/fs: Import image format metadata queries.
Define some utility functions to query the bitfield layout of a given
image format and whether it satisfies a number of more or less
hardware-specific properties.
v2: Drop VEC4 suport.
v3: Add SKL support.
---
src/mesa/drivers/dri/i965/brw_fs_surface_builder.h | 148 +
1 file changed, 148 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_surface_builder.h
b/src/mesa/drivers/dri/i965/brw_fs_surface_builder.h
index 264314b..5424be6 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_surface_builder.h
+++ b/src/mesa/drivers/dri/i965/brw_fs_surface_builder.h
@@ -65,5 +65,153 @@ namespace brw {
unsigned dims, unsigned rsize, unsigned op,
brw_predicate pred = BRW_PREDICATE_NONE);
}
+
+ namespace image_format_info {
+ /**
+ * Simple 4-tuple of scalars used to pass around per-color component
+ * values.
+ */
+ struct color_u {
+ color_u(unsigned x = 0) : r(x), g(x), b(x), a(x)
+ {
+ }
+
+ color_u(unsigned r, unsigned g, unsigned b, unsigned a) :
+r(r), g(g), b(b), a(a)
+ {
+ }
+
+ unsigned
+ operator[](unsigned i) const
+ {
+const unsigned xs[] = { r, g, b, a };
+return xs[i];
+ }
+
+ unsigned r, g, b, a;
+ };
+
+ /**
+ * Return the per-channel bitfield widths for a given image format.
+ */
+ inline color_u
+ get_bit_widths(mesa_format format)
+ {
+ return color_u(_mesa_get_format_bits(format, GL_RED_BITS),
+_mesa_get_format_bits(format, GL_GREEN_BITS),
+_mesa_get_format_bits(format, GL_BLUE_BITS),
+_mesa_get_format_bits(format, GL_ALPHA_BITS));
+ }
+
+ /**
+ * Return the per-channel bitfield shifts for a given image format.
+ */
+ inline color_u
+ get_bit_shifts(mesa_format format)
+ {
+ const color_u widths = get_bit_widths(format);
+ return color_u(0, widths.r, widths.r + widths.g,
+widths.r + widths.g + widths.b);
+ }
+
+ /**
+ * Return true if all present components have the same bit width.
+ */
+ inline bool
+ is_homogeneous(mesa_format format)
+ {
+ const color_u widths = get_bit_widths(format);
+ return ((widths.g == 0 || widths.g == widths.r)
+ (widths.b == 0 || widths.b == widths.r)
+ (widths.a == 0 || widths.a == widths.r));
+ }
+
+ /**
+ * Return true if the format conversion boils down to a trivial copy.
+ */
+ inline bool
+ is_conversion_trivial(const brw_device_info *devinfo, mesa_format format)
+ {
+ return (get_bit_widths(format).r == 32 is_homogeneous(format)) ||
+ format == brw_lower_mesa_image_format(devinfo, format);
+ }
+
+ /**
+ * Return true if the hardware natively supports some format with
+ * compatible bitfield layout, but possibly different data types.
+ */
+ inline bool
+ has_supported_bit_layout(const brw_device_info *devinfo,
+ mesa_format format)
+ {
+ const color_u widths = get_bit_widths(format);
+ const color_u lower_widths = get_bit_widths(
+brw_lower_mesa_image_format(devinfo, format));
+
+ return (widths.r == lower_widths.r
+ widths.g == lower_widths.g
+ widths.b == lower_widths.b
+ widths.a == lower_widths.a);
+ }
+
+ /**
+ * Return true if we are required to spread individual components over
+ * several components of the format used by the hardware (RG32 and
+ * friends implemented as RGBA16UI).
+ */
+ inline bool
+ has_split_bit_layout(const brw_device_info *devinfo, mesa_format format)
+ {
+ const mesa_format lower_format =
+brw_lower_mesa_image_format(devinfo, format);
+
+ return (_mesa_format_num_components(format)
+ _mesa_format_num_components(lower_format));
+ }
+
+ /**
+ * Return true unless we have to fall back to untyped surface access.
+ * Fail!
+ */
+ inline bool
+ has_matching_typed_format(const brw_device_info *devinfo,
+mesa_format format)
+ {
+ return (_mesa_get_format_bytes(format) = 4 ||
+ (_mesa_get_format_bytes(format) = 8
+ (devinfo-gen = 8 || devinfo-is_haswell)) ||
+ devinfo-gen = 9);
+ }
+
+ /**
+ * Return true if the hardware returns garbage in the unused high bits
+ * of each component. This may happen on IVB because we rely on the
+ * undocumented behavior that typed reads from surfaces of the
+ * unsupported R8 and R16 formats return useful data in their least
+
Re: [Mesa-dev] i965 implementation of the ARB_shader_image_load_store built-ins. (v2)
On Wednesday, May 13, 2015 07:33:22 PM Francisco Jerez wrote: - Nothing prevents you from evaluating the builder framework independent from the tiling and format conversion code. [snip] I think you misunderstand - we all largely agree that the fs_builder infrastructure is a good idea. I think we've mostly evaluated it and concluded that it's worth doing. But the array_utils stuff - a new subclass of backend_reg - emit_collect, emit_extract, emit_zip, emit_send, all of that is a bunch of new infrastructure that's only used in your new code, and is hard to evaluate. That's not nearly what I meant. Of course whether and how we carry out the transition will still be open for discussion, that statement you quote was intended to show that I'm willing to do the hard work and not going to abandon the new infrastructure while the transition is half-way done (as Ken rudely insinuated on IRC). That's good news. In the past, many instances of we'll fix it later have turned into we never got around to it - not from you, but from other developers. We've also been fixing bugs with subreg_offset for about a year now...which was added for ARB_image_load_store (IIRC)... and not accounted for in a lot of places (i.e. dead code elimination thought writing g7.2 kills a previous write to any of g7). So it's a real concern, no matter who's writing the code. signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/57] Finish enabling ARB_direct_state_access
On Mon, 2015-05-11 at 19:27 +0200, Fredrik Höglund wrote: This is a respin of Laura's FBO patches. I've rebased them, fixed the issues I found, and added my R-b tags. Note that there is a total of 57 patches, so I'm only posting the ones that don't already have R-b tags, and the ones that are candidates for the stable branches. #55 could use a comment (either in the code or the commit message) explaining that you're using ARB_npot as a proxy for GL 2.0; similarly #57 makes it sound like ARB_dsa would work on r200 or i830, which surely is not the case. In any event, looks good to me. With or without the above addressed, these 20 are: Reviewed-by: Adam Jackson a...@redhat.com - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] util/u_atomic: use STATIC_ASSERT() when selecting the appropriate function
As we evaluate sizeof() at compile time, having the run-time assert() does not provide any benefits. Move to the compile-time version STATIC_ASSERT() which will kindly prompt us when this go wrong. Cc: Matt Turner matts...@gmail.com Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/util/u_atomic.h | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/src/util/u_atomic.h b/src/util/u_atomic.h index e38395a..10c0cca 100644 --- a/src/util/u_atomic.h +++ b/src/util/u_atomic.h @@ -86,7 +86,7 @@ #endif #include windows.h #include intrin.h -#include assert.h +#include util/macros.h #if _MSC_VER 1600 @@ -166,7 +166,7 @@ _InterlockedExchangeAdd8(char volatile *addend, char value) sizeof *(_v) == sizeof(short) ? _InterlockedIncrement16((short *) (_v)) : \ sizeof *(_v) == sizeof(long)? _InterlockedIncrement ((long *) (_v)) : \ sizeof *(_v) == sizeof(__int64) ? InterlockedIncrement64 ((__int64 *)(_v)) : \ - (assert(!should not get here), 0)) + (STATIC_ASSERT(!should not get here), 0)) #define p_atomic_dec(_v) \ ((void) p_atomic_dec_return(_v)) @@ -175,21 +175,21 @@ _InterlockedExchangeAdd8(char volatile *addend, char value) sizeof *(_v) == sizeof(short) ? _InterlockedDecrement16((short *) (_v)) : \ sizeof *(_v) == sizeof(long)? _InterlockedDecrement ((long *) (_v)) : \ sizeof *(_v) == sizeof(__int64) ? InterlockedDecrement64 ((__int64 *)(_v)) : \ - (assert(!should not get here), 0)) + (STATIC_ASSERT(!should not get here), 0)) #define p_atomic_add(_v, _i) (\ sizeof *(_v) == sizeof(char)? _InterlockedExchangeAdd8 ((char *) (_v), (_i)) : \ sizeof *(_v) == sizeof(short) ? _InterlockedExchangeAdd16((short *) (_v), (_i)) : \ sizeof *(_v) == sizeof(long)? _InterlockedExchangeAdd ((long *) (_v), (_i)) : \ sizeof *(_v) == sizeof(__int64) ? InterlockedExchangeAdd64((__int64 *)(_v), (_i)) : \ - (assert(!should not get here), 0)) + (STATIC_ASSERT(!should not get here), 0)) #define p_atomic_cmpxchg(_v, _old, _new) (\ sizeof *(_v) == sizeof(char)? _InterlockedCompareExchange8 ((char *) (_v), (char) (_new), (char) (_old)) : \ sizeof *(_v) == sizeof(short) ? _InterlockedCompareExchange16((short *) (_v), (short) (_new), (short) (_old)) : \ sizeof *(_v) == sizeof(long)? _InterlockedCompareExchange ((long *) (_v), (long) (_new), (long) (_old)) : \ sizeof *(_v) == sizeof(__int64) ? InterlockedCompareExchange64 ((__int64 *)(_v), (__int64)(_new), (__int64)(_old)) : \ - (assert(!should not get here), 0)) + (STATIC_ASSERT(!should not get here), 0)) #endif @@ -198,7 +198,7 @@ _InterlockedExchangeAdd8(char volatile *addend, char value) #define PIPE_ATOMIC Solaris OS atomic functions #include atomic.h -#include assert.h +#include util/macros.h #define p_atomic_set(_v, _i) (*(_v) = (_i)) #define p_atomic_read(_v) (*(_v)) @@ -208,49 +208,49 @@ _InterlockedExchangeAdd8(char volatile *addend, char value) sizeof(*v) == sizeof(uint16_t) ? atomic_dec_16_nv((uint16_t *)(v)) == 0 : \ sizeof(*v) == sizeof(uint32_t) ? atomic_dec_32_nv((uint32_t *)(v)) == 0 : \ sizeof(*v) == sizeof(uint64_t) ? atomic_dec_64_nv((uint64_t *)(v)) == 0 : \ -(assert(!should not get here), 0)) +(STATIC_ASSERT(!should not get here), 0)) #define p_atomic_inc(v) (void) (\ sizeof(*v) == sizeof(uint8_t) ? atomic_inc_8 ((uint8_t *)(v)) : \ sizeof(*v) == sizeof(uint16_t) ? atomic_inc_16((uint16_t *)(v)) : \ sizeof(*v) == sizeof(uint32_t) ? atomic_inc_32((uint32_t *)(v)) : \ sizeof(*v) == sizeof(uint64_t) ? atomic_inc_64((uint64_t *)(v)) : \ -(assert(!should not get here), 0)) +(STATIC_ASSERT(!should not get here), 0)) #define p_atomic_inc_return(v) ((__typeof(*v)) \ sizeof(*v) == sizeof(uint8_t) ? atomic_inc_8_nv ((uint8_t *)(v)) : \ sizeof(*v) == sizeof(uint16_t) ? atomic_inc_16_nv((uint16_t *)(v)) : \ sizeof(*v) == sizeof(uint32_t) ? atomic_inc_32_nv((uint32_t *)(v)) : \ sizeof(*v) == sizeof(uint64_t) ? atomic_inc_64_nv((uint64_t *)(v)) : \ -(assert(!should not get here), 0)) +(STATIC_ASSERT(!should not get here), 0)) #define p_atomic_dec(v) ((void) \ sizeof(*v) == sizeof(uint8_t) ? atomic_dec_8 ((uint8_t *)(v)) : \ sizeof(*v) == sizeof(uint16_t) ? atomic_dec_16((uint16_t *)(v)) : \ sizeof(*v) == sizeof(uint32_t) ? atomic_dec_32((uint32_t *)(v)) : \ sizeof(*v) == sizeof(uint64_t) ?
[Mesa-dev] [PATCH 2/2] i965: Fix brw_memory_barrier() for SKL.
This works as-is on SKL, only the assertion needs to be relaxed. --- src/mesa/drivers/dri/i965/brw_program.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/brw_program.c b/src/mesa/drivers/dri/i965/brw_program.c index e5c0d3c..aea26e2 100644 --- a/src/mesa/drivers/dri/i965/brw_program.c +++ b/src/mesa/drivers/dri/i965/brw_program.c @@ -196,7 +196,7 @@ brw_memory_barrier(struct gl_context *ctx, GLbitfield barriers) unsigned bits = (PIPE_CONTROL_DATA_CACHE_INVALIDATE | PIPE_CONTROL_NO_WRITE | PIPE_CONTROL_CS_STALL); - assert(brw-gen = 7 brw-gen = 8); + assert(brw-gen = 7 brw-gen = 9); if (barriers (GL_VERTEX_ATTRIB_ARRAY_BARRIER_BIT | GL_ELEMENT_ARRAY_BARRIER_BIT | -- 2.3.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965: Add SKL support to brw_miptree_get_horizontal_slice_pitch().
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
b/src/mesa/drivers/dri/i965/brw_tex_layout.c
index 72b02a2..6c6dc5c 100644
--- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
+++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
@@ -281,9 +281,7 @@ brw_miptree_get_horizontal_slice_pitch(const struct
brw_context *brw,
const struct intel_mipmap_tree *mt,
unsigned level)
{
- assert(brw-gen 9);
-
- if (mt-target == GL_TEXTURE_3D ||
+ if ((brw-gen 9 mt-target == GL_TEXTURE_3D) ||
(brw-gen == 4 mt-target == GL_TEXTURE_CUBE_MAP)) {
return ALIGN(minify(mt-physical_width0, level), mt-align_w);
} else {
--
2.3.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90438] glxinfo should have a quiet mode
https://bugs.freedesktop.org/show_bug.cgi?id=90438 --- Comment #1 from Brian Paul bri...@vmware.com --- That would be useful. Personally, I use a shell script that wraps glxinfo and greps for version\|vendor\|renderer. If you want to take a crack at this feature, feel free to submit a patch. -- You are receiving this mail because: You are the QA Contact for the bug. 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] include: Add helper header to help trap includes inside extern C.
On 2015-05-13 10:42, Jason Ekstrand wrote: On May 13, 2015 8:01 AM, kallisti5 kallis...@unixzen.com wrote: src/mesa/drivers/haiku/swrast/SoftwareRast.cpp:28: include/no_extern_c.h:47:1: error: template with C linkage templateclass T class _IncludeInsideExternCNotPortable; Any alternative fix ideas besides me adding a if !defined(__HAIKU__) to include/no_extern_c.h? Please do not do that! The whole point of this patch is to catch places where headers are included inside an extern C block. This patch makes them a compile error instead of being silently wrong. The correct solution is to fix the haiku platform integration so it doesn't do this. --Jason Yeah, I had a chat in IRC and determined that I need to add extern C a few places within Mesa instead of doing a bulk extern C to the mesa C headers. One example is glapi_priv lacks any extern C (ifdef C++ wrapped) I'll begin submitting patches to the ML over the next few days. Thanks! -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glapi/hgl: Drop extern C as it was added to glapi
---
src/hgl/GLDispatcher.cpp |5 +++--
src/hgl/GLDispatcher.h |4 +---
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/hgl/GLDispatcher.cpp b/src/hgl/GLDispatcher.cpp
index 46b91d5..a1e9053 100644
--- a/src/hgl/GLDispatcher.cpp
+++ b/src/hgl/GLDispatcher.cpp
@@ -1,6 +1,6 @@
/*
* Copyright 1998-1999 Precision Insight, Inc., Cedar Park, Texas.
- * Copyright 2000-2012 Haiku, Inc. All Rights Reserved.
+ * Copyright 2000-2015 Haiku, Inc. All Rights Reserved.
* Distributed under the terms of the MIT License.
*
* Authors:
@@ -10,10 +10,11 @@
*/
-extern C {
#include glapi/glapi.h
#include glapi/glapi_priv.h
+
+extern C {
/*
* NOTE: this file portion implements C-based dispatch of the OpenGL
entrypoints
* (glAccum, glBegin, etc).
diff --git a/src/hgl/GLDispatcher.h b/src/hgl/GLDispatcher.h
index 44bca8c..7ee095d 100644
--- a/src/hgl/GLDispatcher.h
+++ b/src/hgl/GLDispatcher.h
@@ -1,6 +1,6 @@
/*
* Copyright 1998-1999 Precision Insight, Inc., Cedar Park, Texas.
- * Copyright 2000-2012 Haiku, Inc. All Rights Reserved.
+ * Copyright 2000-2015 Haiku, Inc. All Rights Reserved.
* Distributed under the terms of the MIT License.
*
* Authors:
@@ -17,9 +17,7 @@
#include glheader.h
-extern C {
#include glapi/glapi.h
-}
class BGLDispatcher
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] llvmpipe: enable ARB_texture_view
Am 13.05.2015 um 16:32 schrieb Brian Paul:
On 05/12/2015 08:36 PM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
All the functionality was pretty much there, just not tested.
Trivially fix up the missing pieces (take target info from view not
resource), and add some missing bits for cubes.
Also add some minimal debug validation to detect uninitialized target
values
in the view...
49 new piglits, 47 pass, 2 fail (both related to fake multisampling,
not texture_view itself). No other piglit changes.
---
src/gallium/auxiliary/gallivm/lp_bld_sample.c | 2 +-
src/gallium/drivers/llvmpipe/lp_screen.c| 3 ++-
src/gallium/drivers/llvmpipe/lp_setup.c | 36
++---
src/gallium/drivers/llvmpipe/lp_state_sampler.c | 36
++---
4 files changed, 67 insertions(+), 10 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample.c
b/src/gallium/auxiliary/gallivm/lp_bld_sample.c
index 5b22045..4befb3a 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_sample.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_sample.c
@@ -113,7 +113,7 @@ lp_sampler_static_texture_state(struct
lp_static_texture_state *state,
state-swizzle_b = view-swizzle_b;
state-swizzle_a = view-swizzle_a;
- state-target= texture-target;
+ state-target= view-target;
state-pot_width = util_is_power_of_two(texture-width0);
state-pot_height= util_is_power_of_two(texture-height0);
state-pot_depth = util_is_power_of_two(texture-depth0);
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
index f4ba596..e001e53 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -258,8 +258,9 @@ llvmpipe_get_param(struct pipe_screen *screen,
enum pipe_cap param)
case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION:
return 1;
case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE:
- case PIPE_CAP_SAMPLER_VIEW_TARGET:
return 0;
+ case PIPE_CAP_SAMPLER_VIEW_TARGET:
+ return 1;
case PIPE_CAP_FAKE_SW_MSAA:
return 1;
case PIPE_CAP_CONDITIONAL_RENDER_INVERTED:
diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c
b/src/gallium/drivers/llvmpipe/lp_setup.c
index 96cc77c..4c57fab 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup.c
@@ -811,6 +811,32 @@ lp_setup_set_fragment_sampler_views(struct
lp_setup_context *setup,
*/
pipe_resource_reference(setup-fs.current_tex[i], res);
+#ifdef DEBUG
+/* this is possibly too lenient */
+ if (view-target != res-target) {
+if (view-target == PIPE_TEXTURE_1D)
+ assert(res-target == PIPE_TEXTURE_1D_ARRAY);
+else if (view-target == PIPE_TEXTURE_1D_ARRAY)
+ assert(res-target == PIPE_TEXTURE_1D);
+else if (view-target == PIPE_TEXTURE_2D)
+ assert(res-target == PIPE_TEXTURE_2D_ARRAY ||
+ res-target == PIPE_TEXTURE_CUBE ||
+ res-target == PIPE_TEXTURE_CUBE_ARRAY);
+else if (view-target == PIPE_TEXTURE_2D_ARRAY)
+ assert(res-target == PIPE_TEXTURE_2D ||
+ res-target == PIPE_TEXTURE_CUBE ||
+ res-target == PIPE_TEXTURE_CUBE_ARRAY);
+else if (view-target == PIPE_TEXTURE_CUBE)
+ assert(res-target == PIPE_TEXTURE_CUBE_ARRAY ||
+ res-target == PIPE_TEXTURE_2D_ARRAY);
+else if (view-target == PIPE_TEXTURE_CUBE_ARRAY)
+ assert(res-target == PIPE_TEXTURE_CUBE ||
+ res-target == PIPE_TEXTURE_2D_ARRAY);
+else
+ assert(0);
+ }
+#endif
+
if (!lp_tex-dt) {
/* regular texture - setup array of mipmap level offsets */
int j;
@@ -854,9 +880,10 @@ lp_setup_set_fragment_sampler_views(struct
lp_setup_context *setup,
jit_tex-img_stride[j] = lp_tex-img_stride[j];
}
- if (res-target == PIPE_TEXTURE_1D_ARRAY ||
- res-target == PIPE_TEXTURE_2D_ARRAY ||
- res-target == PIPE_TEXTURE_CUBE_ARRAY) {
+ if (view-target == PIPE_TEXTURE_1D_ARRAY ||
+ view-target == PIPE_TEXTURE_2D_ARRAY ||
+ view-target == PIPE_TEXTURE_CUBE ||
+ view-target == PIPE_TEXTURE_CUBE_ARRAY) {
/*
* For array textures, we don't have
first_layer, instead
* adjust last_layer (stored as depth) plus the
mip level offsets
@@ -868,7 +895,8 @@ lp_setup_set_fragment_sampler_views(struct
lp_setup_context *setup,
[Mesa-dev] [Bug 90162] glGetFramebufferAttachmentParameteriv failing if certain FB attributes are zero
https://bugs.freedesktop.org/show_bug.cgi?id=90162 --- Comment #5 from Tapani Pälli lem...@gmail.com --- These errors are according to the spec and happen because of following reason. 8 OpenGL 4.0 Compatibility, page 449: If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is NONE, no framebuffer is bound to target. In this case querying pname FRAMEBUFFER_- ATTACHMENT_OBJECT_NAME will return zero, and all other queries will generate an INVALID_OPERATION error. 8 In the application before all other queries, you'll need to query for attachment object type: glGetFramebufferAttachmentParameteriv(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, type); If type is GL_NONE, then other queries should not be made. Please resolve as NOTABUG if you agree with this. -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Possible ideas for optimisations in Mesa
On 05/12/2015 03:12 PM, Timothy Arceri wrote:
On Sat, 2015-04-18 at 12:26 +0200, Marek Olšák wrote:
On Fri, Apr 17, 2015 at 1:21 PM, Timothy Arceri t_arc...@yahoo.com.au
wrote:
Hi all,
Last year I spent a whole bunch of time profiling Mesa looking for areas
where improvements could be made. Anyway I thought I'd point out a
couple of things, and see if anyone thinks these are worthwhile
following up.
1. While the hash table has been getting a lot of attention lately,
after running the TF2 benchmark one place that showed up as using more
cpu than the hash table was the glsl parser. I guess this can be mostly
solved once mesa has a disk cache for shaders.
But something I came across at the time was this paper describing
modifying (with apparently little effort) bison to generate a hardcoded
parser that 2.5-6.5 times faster will generating a slightly bigger
binary [1].
The resulting project has been lost in the sands of time unfortunately
so I couldn't try it out.
2. On most of the old quake engine benchmarks the Intel driver spends
between 3-4.5% of its time or 400 million calls to glib since this code
can't be inlined in this bit of code from copy_array_to_vbo_array():
while (count--) {
memcpy(dst, src, dst_stride);
src += src_stride;
dst += dst_stride;
}
I looked in other drivers but I couldn't see them doing this kind of
thing. I'd imaging because of its nature this code could be a bottle
neck. Is there any easy ways to avoid doing this type of copy? Or would
the only thing possible be to write a complex optimisation?
Yeah, other drivers don't do this. In Gallium, we don't change the
stride when uploading buffers, so in our case src_stride ==
dst_stride.
Thanks Marek. Looking at the history of the Intel code in git it seems
when the code was first written memcpy() wasn't used and the data was
just copied 8-bits at a time. In this case you can see the advantage of
doing the copy this way, however with the use of memcpy() there doesn't
seem to be much of a difference between the code paths.
Out of interest I implemented my own version of memcpy() that can do the
copy's with mismatched strides. I did this by aligning the memory to the
8-bytes, doing some shifts in temporaries if needed and then doing 64bit
copy's.
It was made simpler for my test case because the strides were always
12-bytes = dst, 16-bytes = src.
In the end my memcpy() used slightly less cpu and could give a
measurable boost in frame rate in the UrbanTerror benchmark, although
the boost isn't always measurable and is mostly about the same. I
suspect the boost only happens when memory isn't aligned to 8-bytes.
On average there seems to be around 150 to 200 of these copy's done each
this this loop is hit in UrbanTerror so in theory my memcpy() may be
able to be made even faster with SSE using load/store and some
shuffling. I did attempt this but haven't got it work yet.
What kind of system were you measuring on? You might measure a bigger
delta on a Bay Trail system, for example. You might also try locking
the CPU clock low.
I know Eero has some tips for measuring small changes in CPU usage. It
can be... annoying. :)
In the end I'm not sure if implementing a custom memcpy() is worth all
the effort but thought I'd post my findings. My memcpy() code is a bit
of a mess at the moment but if anyone is interested I can clean it up
and push it to my github repo, just let me know.
Tim
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 86701] [regression] weston-simple-egl not running anymore inside qemu
https://bugs.freedesktop.org/show_bug.cgi?id=86701 --- Comment #20 from Pekka Paalanen ppaala...@gmail.com --- (In reply to nerdopolis1 from comment #18) Hi. I realized that the hang happens when I hover over an icon on the desktop shell, and it tries to show a tooltip Output of weston running with WAYLAND_DEBUG=server http://pastebin.com/0aQGBLFH Please don't put pastebin links here, they tend go bad over time. Much better to attach a file. Only weston-desktop-shell hangs. If I get another client to run before weston-desktop-shell hangs, that client stays running. *sigh* I wish we had a way to differentiate between clients in WAYLAND_DEBUG=server output... (there are several different clients interleaved in the trace, but I expected that) Ok, I see what happens. The tooltip is a sub-surface (due to migration to xdg-shell). Sub-surfaces start in synchronized mode, and the mode is never changed here. That means the frame callback cannot trigger, until the parent wl_surface is committed. Toytoolkit or weston-desktop-shell does not commit the parent before EGL starts waiting for the sub-surface's frame callback, which causes the hang. The immediate thing to investigate is whether EGL even gives the app a chance to commit the parent wl_surface (which also is a EGLSurface when you use cairo-egl). If the answer is yes, there is nothing wrong in Mesa, and the bug is in toytoolkit. Whether the answer is yes or no, this issue needs to be filed as a separate bug against Weston's toytoolkit. As fixing the toytoolkit is very low priority (and I would assume hardware accelerated GL to be broken the same way), the solution for end users is: do not configure Weston using --with-cairo=gl nor --with-cairo=glesv2; use the default --with-cairo=image. A quick'n'dirty fix would be to set the tooltip sub-surface to desync mode when it's created. That should avoid the hang, but it may be arguably a wrong solution. One must be able to use the synchronized mode even with EGL surfaces, so making sure it can work is essential. When filing a new bug, please copy my explanation and attach again the same protocol dump. -- 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 62142] Mesa/demo mipmap_limits upside down with running by SOFTWARE
https://bugs.freedesktop.org/show_bug.cgi?id=62142 ye.tian yex.t...@intel.com changed: What|Removed |Added Status|VERIFIED|CLOSED -- 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 stage references for UBO uniforms
On 13/05/15 07:28, Tapani Pälli wrote:
On 05/13/2015 08:02 AM, Samuel Iglesias Gonsálvez wrote:
Thanks Tapani!
Reviewed-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
Can you add a test to piglit to check this case?
I was hoping you had some test that hit this? :) I'll take a look if
existing tests can be modified easily to cover this case.
I have one test for SSBOs which also hit this. If you are busy, just let
me know and I will modify an existing test.
Thanks,
Sam
Sam
On 11/05/15 12:24, Tapani Pälli wrote:
Patch marks uniforms inside UBO properly referenced by stages.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90397
---
src/glsl/linker.cpp | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index ea73c6f..ecdc025 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2700,6 +2700,16 @@ build_program_resource_list(struct gl_context
*ctx,
uint8_t stageref =
build_stageref(shProg, shProg-UniformStorage[i].name);
+
+ /* Add stagereferences for uniforms in a uniform block. */
+ int block_index = shProg-UniformStorage[i].block_index;
+ if (block_index != -1) {
+ for (unsigned j = 0; j MESA_SHADER_STAGES; j++) {
+ if (shProg-UniformBlockStageIndex[j][block_index] != -1)
+stageref |= (1 j);
+ }
+ }
+
if (!add_program_resource(shProg, GL_UNIFORM,
shProg-UniformStorage[i], stageref))
return;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3] glsl: set the binding value regardless explicit_binding
On 12/05/15 23:17, Timothy Arceri wrote: On Mon, 2015-05-11 at 12:37 +0200, Alejandro Piñeiro wrote: Since commit c0cd5b var-data.binding was set only when explicit_binding was false, thas was wrong, should be a test to true. This prevented to use any binding point different to 0. In any case, that if statement is not needed. Right now mesa requires all atomic counters to have an explicit binding point. This would match the original implementation. Cc: 10.4, 10.5 mesa-sta...@lists.freedesktop.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90175 --- New version based on Timothy Arceri suggestion at the list. Also gentle ping for a formal review of the patch. src/glsl/link_atomics.cpp | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/glsl/link_atomics.cpp b/src/glsl/link_atomics.cpp index 603873a..2cede91 100644 --- a/src/glsl/link_atomics.cpp +++ b/src/glsl/link_atomics.cpp @@ -201,8 +201,7 @@ link_assign_atomic_counter_resources(struct gl_context *ctx, gl_uniform_storage *const storage = prog-UniformStorage[id]; mab.Uniforms[j] = id; - if (!var-data.explicit_binding) -var-data.binding = i; + var-data.binding = i; storage-atomic_buffer_index = i; storage-offset = var-data.atomic.offset; Reviewed-by: Timothy Arceri t_arc...@yahoo.com.au Thanks for the review. Although you may want to cc Ian in on this in case he hasn't seen it, as he was the one who made the change and may have a reason for doing this that I don't see. CCed. Ian do you have any comments? BR -- Alejandro Piñeiro (apinhe...@igalia.com) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90162] glGetFramebufferAttachmentParameteriv failing if certain FB attributes are zero
https://bugs.freedesktop.org/show_bug.cgi?id=90162 --- Comment #6 from Tapani Pälli lem...@gmail.com --- Having said that, I noticed that glGetFramebufferAttachmentParameteriv is broken if you try to query type or name of non-existing attachment point (for desktop GL). But that should be another bug. -- You are receiving this mail because: You are the QA Contact 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 stage references for UBO uniforms
On 05/13/2015 10:35 AM, Samuel Iglesias Gonsálvez wrote:
On 13/05/15 07:28, Tapani Pälli wrote:
On 05/13/2015 08:02 AM, Samuel Iglesias Gonsálvez wrote:
Thanks Tapani!
Reviewed-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
Can you add a test to piglit to check this case?
I was hoping you had some test that hit this? :) I'll take a look if
existing tests can be modified easily to cover this case.
I have one test for SSBOs which also hit this. If you are busy, just let
me know and I will modify an existing test.
Check if following test could be extended to cover the case:
arb_program_interface_query-getprogramresourceiv
I believe you might need to touch other cases as they all use the same
shaders. Or maybe additionally add a new shader with case that hits this
path.
Thanks,
Sam
Sam
On 11/05/15 12:24, Tapani Pälli wrote:
Patch marks uniforms inside UBO properly referenced by stages.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90397
---
src/glsl/linker.cpp | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index ea73c6f..ecdc025 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2700,6 +2700,16 @@ build_program_resource_list(struct gl_context
*ctx,
uint8_t stageref =
build_stageref(shProg, shProg-UniformStorage[i].name);
+
+ /* Add stagereferences for uniforms in a uniform block. */
+ int block_index = shProg-UniformStorage[i].block_index;
+ if (block_index != -1) {
+ for (unsigned j = 0; j MESA_SHADER_STAGES; j++) {
+ if (shProg-UniformBlockStageIndex[j][block_index] != -1)
+stageref |= (1 j);
+ }
+ }
+
if (!add_program_resource(shProg, GL_UNIFORM,
shProg-UniformStorage[i], stageref))
return;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90162] glGetFramebufferAttachmentParameteriv failing if certain FB attributes are zero
https://bugs.freedesktop.org/show_bug.cgi?id=90162 --- Comment #7 from Martina Kollarova martina.kollar...@intel.com --- glGetFramebufferAttachmentParameteriv(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, type); This query generated a GL_INVALID_ENUM for me. -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util/u_atomic: use STATIC_ASSERT() when selecting the appropriate function
Emil Velikov emil.l.veli...@gmail.com writes: As we evaluate sizeof() at compile time, having the run-time assert() does not provide any benefits. Move to the compile-time version STATIC_ASSERT() which will kindly prompt us when this go wrong. This doesn't look right. AFAIK STATIC_ASSERT() is implemented by expanding to an array type-id of negative size, which is an error regardless of whether the sizeof expression is evaluated or not: i.e. 0 ? sizeof(invalid) : ... is still an error for the same reason that 0 * sizeof(invalid) or (void)sizeof(invalid) is an error. That and also that the whole thing is wrapped in a do-while loop you cannot use as operand of the ternary operator... Cc: Matt Turner matts...@gmail.com Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/util/u_atomic.h | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/src/util/u_atomic.h b/src/util/u_atomic.h index e38395a..10c0cca 100644 --- a/src/util/u_atomic.h +++ b/src/util/u_atomic.h @@ -86,7 +86,7 @@ #endif #include windows.h #include intrin.h -#include assert.h +#include util/macros.h #if _MSC_VER 1600 @@ -166,7 +166,7 @@ _InterlockedExchangeAdd8(char volatile *addend, char value) sizeof *(_v) == sizeof(short) ? _InterlockedIncrement16((short *) (_v)) : \ sizeof *(_v) == sizeof(long)? _InterlockedIncrement ((long *) (_v)) : \ sizeof *(_v) == sizeof(__int64) ? InterlockedIncrement64 ((__int64 *)(_v)) : \ - (assert(!should not get here), 0)) + (STATIC_ASSERT(!should not get here), 0)) #define p_atomic_dec(_v) \ ((void) p_atomic_dec_return(_v)) @@ -175,21 +175,21 @@ _InterlockedExchangeAdd8(char volatile *addend, char value) sizeof *(_v) == sizeof(short) ? _InterlockedDecrement16((short *) (_v)) : \ sizeof *(_v) == sizeof(long)? _InterlockedDecrement ((long *) (_v)) : \ sizeof *(_v) == sizeof(__int64) ? InterlockedDecrement64 ((__int64 *)(_v)) : \ - (assert(!should not get here), 0)) + (STATIC_ASSERT(!should not get here), 0)) #define p_atomic_add(_v, _i) (\ sizeof *(_v) == sizeof(char)? _InterlockedExchangeAdd8 ((char *) (_v), (_i)) : \ sizeof *(_v) == sizeof(short) ? _InterlockedExchangeAdd16((short *) (_v), (_i)) : \ sizeof *(_v) == sizeof(long)? _InterlockedExchangeAdd ((long *) (_v), (_i)) : \ sizeof *(_v) == sizeof(__int64) ? InterlockedExchangeAdd64((__int64 *)(_v), (_i)) : \ - (assert(!should not get here), 0)) + (STATIC_ASSERT(!should not get here), 0)) #define p_atomic_cmpxchg(_v, _old, _new) (\ sizeof *(_v) == sizeof(char)? _InterlockedCompareExchange8 ((char *) (_v), (char) (_new), (char) (_old)) : \ sizeof *(_v) == sizeof(short) ? _InterlockedCompareExchange16((short *) (_v), (short) (_new), (short) (_old)) : \ sizeof *(_v) == sizeof(long)? _InterlockedCompareExchange ((long *) (_v), (long) (_new), (long) (_old)) : \ sizeof *(_v) == sizeof(__int64) ? InterlockedCompareExchange64 ((__int64 *)(_v), (__int64)(_new), (__int64)(_old)) : \ - (assert(!should not get here), 0)) + (STATIC_ASSERT(!should not get here), 0)) #endif @@ -198,7 +198,7 @@ _InterlockedExchangeAdd8(char volatile *addend, char value) #define PIPE_ATOMIC Solaris OS atomic functions #include atomic.h -#include assert.h +#include util/macros.h #define p_atomic_set(_v, _i) (*(_v) = (_i)) #define p_atomic_read(_v) (*(_v)) @@ -208,49 +208,49 @@ _InterlockedExchangeAdd8(char volatile *addend, char value) sizeof(*v) == sizeof(uint16_t) ? atomic_dec_16_nv((uint16_t *)(v)) == 0 : \ sizeof(*v) == sizeof(uint32_t) ? atomic_dec_32_nv((uint32_t *)(v)) == 0 : \ sizeof(*v) == sizeof(uint64_t) ? atomic_dec_64_nv((uint64_t *)(v)) == 0 : \ -(assert(!should not get here), 0)) +(STATIC_ASSERT(!should not get here), 0)) #define p_atomic_inc(v) (void) (\ sizeof(*v) == sizeof(uint8_t) ? atomic_inc_8 ((uint8_t *)(v)) : \ sizeof(*v) == sizeof(uint16_t) ? atomic_inc_16((uint16_t *)(v)) : \ sizeof(*v) == sizeof(uint32_t) ? atomic_inc_32((uint32_t *)(v)) : \ sizeof(*v) == sizeof(uint64_t) ? atomic_inc_64((uint64_t *)(v)) : \ -(assert(!should not get here), 0)) +(STATIC_ASSERT(!should not get here), 0)) #define p_atomic_inc_return(v) ((__typeof(*v)) \ sizeof(*v) == sizeof(uint8_t) ? atomic_inc_8_nv ((uint8_t *)(v)) : \ sizeof(*v) == sizeof(uint16_t) ?
