[Mesa-dev] [PATCH 1/2] winsys/radeon: share winsys between different fd's
From: Christian König
Share the winsys between different fd's if they point to the same device.
Signed-off-by: Christian König
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 69c42a0..310965b 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
@@ -41,6 +41,9 @@
#include
#include
+#include
+#include
+#include
/*
* this are copy from radeon_drm, once an updated libdrm is released
@@ -520,12 +523,24 @@ static uint64_t radeon_query_value(struct radeon_winsys
*rws,
static unsigned hash_fd(void *key)
{
-return pointer_to_intptr(key);
+int fd = pointer_to_intptr(key);
+struct stat stat;
+fstat(fd, &stat);
+
+return stat.st_dev ^ stat.st_ino ^ stat.st_rdev;
}
static int compare_fd(void *key1, void *key2)
{
-return pointer_to_intptr(key1) != pointer_to_intptr(key2);
+int fd1 = pointer_to_intptr(key1);
+int fd2 = pointer_to_intptr(key2);
+struct stat stat1, stat2;
+fstat(fd1, &stat1);
+fstat(fd2, &stat2);
+
+return stat1.st_dev != stat2.st_dev ||
+ stat1.st_ino != stat2.st_ino ||
+ stat1.st_rdev != stat2.st_rdev;
}
void radeon_drm_ws_queue_cs(struct radeon_drm_winsys *ws, struct radeon_drm_cs
*cs)
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] implement NV_vdpau_interop v3
From: Christian König
v2: Actually implement interop between the gallium
state tracker and the VDPAU backend.
v3: Make it also available in non legacy contexts,
fix video buffer sharing.
Signed-off-by: Christian König
---
src/gallium/include/state_tracker/vdpau_interop.h | 49
src/gallium/state_trackers/vdpau/ftab.c | 31 ++-
src/gallium/state_trackers/vdpau/output.c | 11 +
src/gallium/state_trackers/vdpau/surface.c| 21 ++
src/gallium/state_trackers/vdpau/vdpau_private.h | 6 +
src/mapi/glapi/gen/Makefile.am| 1 +
src/mapi/glapi/gen/NV_vdpau_interop.xml | 69 ++
src/mapi/glapi/gen/gl_API.xml | 2 +
src/mapi/glapi/gen/gl_genexec.py | 1 +
src/mesa/Makefile.sources | 4 +-
src/mesa/main/dd.h| 14 ++
src/mesa/main/extensions.c| 1 +
src/mesa/main/mtypes.h| 9 +
src/mesa/main/vdpau.c | 279 ++
src/mesa/main/vdpau.h | 72 ++
src/mesa/state_tracker/st_context.c | 3 +
src/mesa/state_tracker/st_extensions.c| 1 +
src/mesa/state_tracker/st_vdpau.c | 193 +++
src/mesa/state_tracker/st_vdpau.h | 42
19 files changed, 800 insertions(+), 9 deletions(-)
create mode 100644 src/gallium/include/state_tracker/vdpau_interop.h
create mode 100644 src/mapi/glapi/gen/NV_vdpau_interop.xml
create mode 100644 src/mesa/main/vdpau.c
create mode 100644 src/mesa/main/vdpau.h
create mode 100644 src/mesa/state_tracker/st_vdpau.c
create mode 100644 src/mesa/state_tracker/st_vdpau.h
diff --git a/src/gallium/include/state_tracker/vdpau_interop.h
b/src/gallium/include/state_tracker/vdpau_interop.h
new file mode 100644
index 000..3ca7c9d
--- /dev/null
+++ b/src/gallium/include/state_tracker/vdpau_interop.h
@@ -0,0 +1,49 @@
+/**
+ *
+ * Copyright 2013 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * 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, sub license, 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 NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) 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:
+ * Christian König
+ *
+ */
+
+#ifndef _VDPAU_INTEROP_H_
+#define _VDPAU_INTEROP_H_
+
+/* driver specific functions for NV_vdpau_interop */
+
+#define VDP_FUNC_ID_BASE_DRIVER 0x2000
+#define VDP_FUNC_ID_VIDEO_SURFACE_GALLIUM (VDP_FUNC_ID_BASE_DRIVER + 0)
+#define VDP_FUNC_ID_OUTPUT_SURFACE_GALLIUM (VDP_FUNC_ID_BASE_DRIVER + 1)
+
+struct pipe_resource;
+struct pipe_video_buffer;
+
+typedef struct pipe_video_buffer *VdpVideoSurfaceGallium(uint32_t surface);
+typedef struct pipe_resource *VdpOutputSurfaceGallium(uint32_t surface);
+
+#endif /* _VDPAU_INTEROP_H_ */
diff --git a/src/gallium/state_trackers/vdpau/ftab.c
b/src/gallium/state_trackers/vdpau/ftab.c
index 81d16ec..2c84554 100644
--- a/src/gallium/state_trackers/vdpau/ftab.c
+++ b/src/gallium/state_trackers/vdpau/ftab.c
@@ -26,6 +26,9 @@
**/
#include
+
+#include "util/u_memory.h"
+
#include "vdpau_private.h"
static void* ftab[67] =
@@ -104,19 +107,31 @@ static void* ftab_winsys[1] =
&vlVdpPresentationQueueTargetCreateX11 /*
VDP_FUNC_ID_PRESENTATION_QUEUE_TARGET_CREATE_X11 */
};
+static void* ftab_driver[2] =
+{
+ &vlVdpVideoSurfaceGallium, /* VDP_FUNC_ID_SURFACE_GALLIUM */
+ &vlVdpOutputSurfaceGallium /* VDP_FUNC_ID_OUTPUT_SURFACE_GALLIUM */
+};
+
boolean vlGetFuncFTAB(VdpFuncId function_id, void **func)
{
assert(func);
+ *func = NULL;
+
if (function_id < VDP_FUNC_ID_BASE_WINSYS) {
- if (function_id > 66)
- return FALSE;
- *func = ftab[function_id];
- }
- e
Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...
On Thu, Sep 12, 2013 at 3:32 PM, Christian König wrote: > Am 12.09.2013 14:52, schrieb Marek Olšák: > >> I think current Gallium drivers only need one exported symbol to work: >> __driDriverExtensions. See: >> http://lists.freedesktop.org/archives/mesa-dev/2013-August/043038.html > > > Yes that's indeed the right way of doing it, feel free to make the changes > Chia-l Wu suggested to avoid the version file and commit the patch with my > rb. The version file is the only way not to export LLVM symbols as far as I know, so I'm afraid I can't get rid of it. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] winsys/radeon: fix killing the CS thread
From: Christian König
Kill the thread only after we checked that it's not used any more, not before.
Signed-off-by: Christian König
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 69c42a0..0a3b932 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
@@ -421,6 +421,10 @@ static void radeon_winsys_destroy(struct radeon_winsys
*rws)
{
struct radeon_drm_winsys *ws = (struct radeon_drm_winsys*)rws;
+if (!pipe_reference(&ws->base.reference, NULL)) {
+return;
+}
+
if (ws->thread) {
ws->kill_thread = 1;
pipe_semaphore_signal(&ws->cs_queued);
@@ -429,10 +433,6 @@ static void radeon_winsys_destroy(struct radeon_winsys
*rws)
pipe_semaphore_destroy(&ws->cs_queued);
pipe_condvar_destroy(ws->cs_queue_empty);
-if (!pipe_reference(&ws->base.reference, NULL)) {
-return;
-}
-
pipe_mutex_destroy(ws->hyperz_owner_mutex);
pipe_mutex_destroy(ws->cmask_owner_mutex);
pipe_mutex_destroy(ws->cs_stack_lock);
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] implement NV_vdpau_interop v3
From: Christian König
v2: Actually implement interop between the gallium
state tracker and the VDPAU backend.
v3: Make it also available in non legacy contexts,
fix video buffer sharing.
Signed-off-by: Christian König
---
src/gallium/include/state_tracker/vdpau_interop.h | 49
src/gallium/state_trackers/vdpau/ftab.c | 31 ++-
src/gallium/state_trackers/vdpau/output.c | 11 +
src/gallium/state_trackers/vdpau/surface.c| 21 ++
src/gallium/state_trackers/vdpau/vdpau_private.h | 6 +
src/mapi/glapi/gen/Makefile.am| 1 +
src/mapi/glapi/gen/NV_vdpau_interop.xml | 69 ++
src/mapi/glapi/gen/gl_API.xml | 2 +
src/mapi/glapi/gen/gl_genexec.py | 1 +
src/mesa/Makefile.sources | 4 +-
src/mesa/main/dd.h| 14 ++
src/mesa/main/extensions.c| 1 +
src/mesa/main/mtypes.h| 9 +
src/mesa/main/vdpau.c | 279 ++
src/mesa/main/vdpau.h | 72 ++
src/mesa/state_tracker/st_context.c | 3 +
src/mesa/state_tracker/st_extensions.c| 1 +
src/mesa/state_tracker/st_vdpau.c | 193 +++
src/mesa/state_tracker/st_vdpau.h | 42
19 files changed, 800 insertions(+), 9 deletions(-)
create mode 100644 src/gallium/include/state_tracker/vdpau_interop.h
create mode 100644 src/mapi/glapi/gen/NV_vdpau_interop.xml
create mode 100644 src/mesa/main/vdpau.c
create mode 100644 src/mesa/main/vdpau.h
create mode 100644 src/mesa/state_tracker/st_vdpau.c
create mode 100644 src/mesa/state_tracker/st_vdpau.h
diff --git a/src/gallium/include/state_tracker/vdpau_interop.h
b/src/gallium/include/state_tracker/vdpau_interop.h
new file mode 100644
index 000..3ca7c9d
--- /dev/null
+++ b/src/gallium/include/state_tracker/vdpau_interop.h
@@ -0,0 +1,49 @@
+/**
+ *
+ * Copyright 2013 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * 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, sub license, 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 NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) 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:
+ * Christian König
+ *
+ */
+
+#ifndef _VDPAU_INTEROP_H_
+#define _VDPAU_INTEROP_H_
+
+/* driver specific functions for NV_vdpau_interop */
+
+#define VDP_FUNC_ID_BASE_DRIVER 0x2000
+#define VDP_FUNC_ID_VIDEO_SURFACE_GALLIUM (VDP_FUNC_ID_BASE_DRIVER + 0)
+#define VDP_FUNC_ID_OUTPUT_SURFACE_GALLIUM (VDP_FUNC_ID_BASE_DRIVER + 1)
+
+struct pipe_resource;
+struct pipe_video_buffer;
+
+typedef struct pipe_video_buffer *VdpVideoSurfaceGallium(uint32_t surface);
+typedef struct pipe_resource *VdpOutputSurfaceGallium(uint32_t surface);
+
+#endif /* _VDPAU_INTEROP_H_ */
diff --git a/src/gallium/state_trackers/vdpau/ftab.c
b/src/gallium/state_trackers/vdpau/ftab.c
index 81d16ec..2c84554 100644
--- a/src/gallium/state_trackers/vdpau/ftab.c
+++ b/src/gallium/state_trackers/vdpau/ftab.c
@@ -26,6 +26,9 @@
**/
#include
+
+#include "util/u_memory.h"
+
#include "vdpau_private.h"
static void* ftab[67] =
@@ -104,19 +107,31 @@ static void* ftab_winsys[1] =
&vlVdpPresentationQueueTargetCreateX11 /*
VDP_FUNC_ID_PRESENTATION_QUEUE_TARGET_CREATE_X11 */
};
+static void* ftab_driver[2] =
+{
+ &vlVdpVideoSurfaceGallium, /* VDP_FUNC_ID_SURFACE_GALLIUM */
+ &vlVdpOutputSurfaceGallium /* VDP_FUNC_ID_OUTPUT_SURFACE_GALLIUM */
+};
+
boolean vlGetFuncFTAB(VdpFuncId function_id, void **func)
{
assert(func);
+ *func = NULL;
+
if (function_id < VDP_FUNC_ID_BASE_WINSYS) {
- if (function_id > 66)
- return FALSE;
- *func = ftab[function_id];
- }
- e
[Mesa-dev] [PATCH 5/5] radeon/uvd: async flush the UVD cs
From: Christian König No need to block for the CS thread here. Signed-off-by: Christian König --- src/gallium/drivers/radeon/radeon_uvd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/radeon/radeon_uvd.c b/src/gallium/drivers/radeon/radeon_uvd.c index 518978e..fa81105 100644 --- a/src/gallium/drivers/radeon/radeon_uvd.c +++ b/src/gallium/drivers/radeon/radeon_uvd.c @@ -110,7 +110,7 @@ static void flush(struct ruvd_decoder *dec) while(dec->cs->cdw % 16) pm4[dec->cs->cdw++] = RUVD_PKT2(); - dec->ws->cs_flush(dec->cs, 0, 0); + dec->ws->cs_flush(dec->cs, RADEON_FLUSH_ASYNC, 0); } /* add a new set register command to the IB */ -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] winsys/radeon: share winsys between different fd's
From: Christian König
Share the winsys between different fd's if they point to the same device.
Signed-off-by: Christian König
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 27bf348..61f0913 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
@@ -41,6 +41,9 @@
#include
#include
+#include
+#include
+#include
/*
* this are copy from radeon_drm, once an updated libdrm is released
@@ -519,12 +522,24 @@ static uint64_t radeon_query_value(struct radeon_winsys
*rws,
static unsigned hash_fd(void *key)
{
-return pointer_to_intptr(key);
+int fd = pointer_to_intptr(key);
+struct stat stat;
+fstat(fd, &stat);
+
+return stat.st_dev ^ stat.st_ino ^ stat.st_rdev;
}
static int compare_fd(void *key1, void *key2)
{
-return pointer_to_intptr(key1) != pointer_to_intptr(key2);
+int fd1 = pointer_to_intptr(key1);
+int fd2 = pointer_to_intptr(key2);
+struct stat stat1, stat2;
+fstat(fd1, &stat1);
+fstat(fd2, &stat2);
+
+return stat1.st_dev != stat2.st_dev ||
+ stat1.st_ino != stat2.st_ino ||
+ stat1.st_rdev != stat2.st_rdev;
}
void radeon_drm_ws_queue_cs(struct radeon_drm_winsys *ws, struct radeon_drm_cs
*cs)
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] winsys/radeon: remove cs_queue_empty
From: Christian König
Waiting for an empty queue is nonsense and can lead to deadlocks if we have
multiple waiters or another thread that continuously sends down new commands.
Just post the cs to the queue and immediately wait for it to finish.
This is a candidate for the stable branch.
Signed-off-by: Christian König
---
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 11 +++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 6 --
src/gallium/winsys/radeon/drm/radeon_drm_winsys.h | 5 -
3 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index 38a9209..d530011 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -560,17 +560,12 @@ static void radeon_drm_cs_flush(struct radeon_winsys_cs
*rcs, unsigned flags, ui
break;
}
-if (cs->ws->thread && (flags & RADEON_FLUSH_ASYNC)) {
+if (cs->ws->thread) {
cs->flush_started = 1;
radeon_drm_ws_queue_cs(cs->ws, cs);
+if (!(flags & RADEON_FLUSH_ASYNC))
+radeon_drm_cs_sync_flush(rcs);
} else {
-pipe_mutex_lock(cs->ws->cs_stack_lock);
-if (cs->ws->thread) {
-while (p_atomic_read(&cs->ws->ncs)) {
-pipe_condvar_wait(cs->ws->cs_queue_empty,
cs->ws->cs_stack_lock);
-}
-}
-pipe_mutex_unlock(cs->ws->cs_stack_lock);
radeon_drm_cs_emit_ioctl_oneshot(cs, cs->cst);
}
} else {
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 0a3b932..27bf348 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
@@ -431,7 +431,6 @@ static void radeon_winsys_destroy(struct radeon_winsys *rws)
pipe_thread_wait(ws->thread);
}
pipe_semaphore_destroy(&ws->cs_queued);
-pipe_condvar_destroy(ws->cs_queue_empty);
pipe_mutex_destroy(ws->hyperz_owner_mutex);
pipe_mutex_destroy(ws->cmask_owner_mutex);
@@ -567,9 +566,6 @@ next:
}
ws->cs_stack[p_atomic_read(&ws->ncs) - 1] = NULL;
empty_stack = p_atomic_dec_zero(&ws->ncs);
-if (empty_stack) {
-pipe_condvar_signal(ws->cs_queue_empty);
-}
pipe_mutex_unlock(ws->cs_stack_lock);
pipe_semaphore_signal(&cs->flush_completed);
@@ -585,7 +581,6 @@ next:
ws->cs_stack[i] = NULL;
}
p_atomic_set(&ws->ncs, 0);
-pipe_condvar_signal(ws->cs_queue_empty);
pipe_mutex_unlock(ws->cs_stack_lock);
return NULL;
}
@@ -651,7 +646,6 @@ struct radeon_winsys *radeon_drm_winsys_create(int fd)
p_atomic_set(&ws->ncs, 0);
pipe_semaphore_init(&ws->cs_queued, 0);
-pipe_condvar_init(ws->cs_queue_empty);
if (ws->num_cpus > 1 && debug_get_option_thread())
ws->thread = pipe_thread_create(radeon_drm_cs_emit_ioctl, ws);
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
index 682479e..ed90194 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
@@ -67,11 +67,6 @@ struct radeon_drm_winsys {
/* rings submission thread */
pipe_mutex cs_stack_lock;
pipe_semaphore cs_queued;
-/* we cannot use semaphore for empty queue because maintaining an even
- * number of call to semaphore_wait and semaphore_signal is, to say the
- * least, tricky
- */
-pipe_condvar cs_queue_empty;
pipe_thread thread;
int kill_thread;
int ncs;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/7] mesa: Convert some runtime asserts to static asserts.
On Fri, Sep 20, 2013 at 7:52 PM, Eric Anholt wrote:
> Noticed while grepping through the code for something else.
> ---
> src/mesa/program/program.c | 36 ++--
> 1 file changed, 22 insertions(+), 14 deletions(-)
>
> diff --git a/src/mesa/program/program.c b/src/mesa/program/program.c
> index 2529c13..5dd68d9 100644
> --- a/src/mesa/program/program.c
> +++ b/src/mesa/program/program.c
> @@ -55,27 +55,35 @@ _mesa_init_program(struct gl_context *ctx)
> * If this assertion fails, we need to increase the field
> * size for register indexes (see INST_INDEX_BITS).
> */
> - ASSERT(ctx->Const.VertexProgram.MaxUniformComponents / 4
> + STATIC_ASSERT(ctx->Const.VertexProgram.MaxUniformComponents / 4
><= (1 << INST_INDEX_BITS));
> - ASSERT(ctx->Const.FragmentProgram.MaxUniformComponents / 4
> + STATIC_ASSERT(ctx->Const.FragmentProgram.MaxUniformComponents / 4
><= (1 << INST_INDEX_BITS));
>
> - ASSERT(ctx->Const.VertexProgram.MaxTemps <= (1 << INST_INDEX_BITS));
> - ASSERT(ctx->Const.VertexProgram.MaxLocalParams <= (1 << INST_INDEX_BITS));
> - ASSERT(ctx->Const.FragmentProgram.MaxTemps <= (1 << INST_INDEX_BITS));
> - ASSERT(ctx->Const.FragmentProgram.MaxLocalParams <= (1 <<
> INST_INDEX_BITS));
> -
> - ASSERT(ctx->Const.VertexProgram.MaxUniformComponents <= 4 * MAX_UNIFORMS);
> - ASSERT(ctx->Const.FragmentProgram.MaxUniformComponents <= 4 *
> MAX_UNIFORMS);
> -
> - ASSERT(ctx->Const.VertexProgram.MaxAddressOffset <= (1 <<
> INST_INDEX_BITS));
> - ASSERT(ctx->Const.FragmentProgram.MaxAddressOffset <= (1 <<
> INST_INDEX_BITS));
> + STATIC_ASSERT(ctx->Const.VertexProgram.MaxTemps <=
> + (1 << INST_INDEX_BITS));
> + STATIC_ASSERT(ctx->Const.VertexProgram.MaxLocalParams <=
> + (1 << INST_INDEX_BITS));
> + STATIC_ASSERT(ctx->Const.FragmentProgram.MaxTemps <=
> + (1 << INST_INDEX_BITS));
> + STATIC_ASSERT(ctx->Const.FragmentProgram.MaxLocalParams <=
> + (1 << INST_INDEX_BITS));
> +
> + STATIC_ASSERT(ctx->Const.VertexProgram.MaxUniformComponents <=
> + 4 * MAX_UNIFORMS);
> + STATIC_ASSERT(ctx->Const.FragmentProgram.MaxUniformComponents <=
> + 4 * MAX_UNIFORMS);
> +
> + STATIC_ASSERT(ctx->Const.VertexProgram.MaxAddressOffset <=
> + (1 << INST_INDEX_BITS));
> + STATIC_ASSERT(ctx->Const.FragmentProgram.MaxAddressOffset <=
> + (1 << INST_INDEX_BITS));
Are you sure about those? How does the compiler know the values of
ctx->Const.Foo at compile time?
It's worrisome that our STATIC_ASSERT macro is silent at compile time
when the expression isn't a compile-time constant. The problem with
our macro now is variable-sized arrays are OK at compile time.
I think a macro based on bitfield width might be better:
#define STATIC_ASSERT(COND) \
do { \
struct dummy { \
int static_assert_failed:(!!(COND)); \
}; \
} while (0)
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] implement NV_vdpau_interop v3
1) The Errors section of the spec isn't implemented properly. 2) Passing GL_TEXTURE_RECTANGLE to the new functions should generate an error if ctx->Extensions.NV_texture_rectangle is false. 3) There should also probably be some checking for GL_ARB_texture_non_power_of_two, but the spec doesn't say what we should do (probably return GL_INVALID_OPERATION). 4) VDPAUGetSurfaceivNV isn't implemented properly. 5) The unregistering in VDPAUFiniNV should be implemented too. 6) Registered and mapped VDPAU textures are not allowed to be re-specified by TexImage, TexSubImage, TexImage*Multisample, CopyTexImage, CopyTexSubImage, TexStorage, TexStorage*Multisample, and similar functions. This should be properly handled in those functions and GL errors should be returned. 7) The extension spec says that all VDPAU textures should be y-inverted. Is that actually the case here? 8) Do we actually have enough tests, so that we can say this feature works? Marek On Sat, Sep 21, 2013 at 12:32 PM, Christian König wrote: > From: Christian König > > v2: Actually implement interop between the gallium > state tracker and the VDPAU backend. > > v3: Make it also available in non legacy contexts, > fix video buffer sharing. > > Signed-off-by: Christian König > --- > src/gallium/include/state_tracker/vdpau_interop.h | 49 > src/gallium/state_trackers/vdpau/ftab.c | 31 ++- > src/gallium/state_trackers/vdpau/output.c | 11 + > src/gallium/state_trackers/vdpau/surface.c| 21 ++ > src/gallium/state_trackers/vdpau/vdpau_private.h | 6 + > src/mapi/glapi/gen/Makefile.am| 1 + > src/mapi/glapi/gen/NV_vdpau_interop.xml | 69 ++ > src/mapi/glapi/gen/gl_API.xml | 2 + > src/mapi/glapi/gen/gl_genexec.py | 1 + > src/mesa/Makefile.sources | 4 +- > src/mesa/main/dd.h| 14 ++ > src/mesa/main/extensions.c| 1 + > src/mesa/main/mtypes.h| 9 + > src/mesa/main/vdpau.c | 279 > ++ > src/mesa/main/vdpau.h | 72 ++ > src/mesa/state_tracker/st_context.c | 3 + > src/mesa/state_tracker/st_extensions.c| 1 + > src/mesa/state_tracker/st_vdpau.c | 193 +++ > src/mesa/state_tracker/st_vdpau.h | 42 > 19 files changed, 800 insertions(+), 9 deletions(-) > create mode 100644 src/gallium/include/state_tracker/vdpau_interop.h > create mode 100644 src/mapi/glapi/gen/NV_vdpau_interop.xml > create mode 100644 src/mesa/main/vdpau.c > create mode 100644 src/mesa/main/vdpau.h > create mode 100644 src/mesa/state_tracker/st_vdpau.c > create mode 100644 src/mesa/state_tracker/st_vdpau.h > > diff --git a/src/gallium/include/state_tracker/vdpau_interop.h > b/src/gallium/include/state_tracker/vdpau_interop.h > new file mode 100644 > index 000..3ca7c9d > --- /dev/null > +++ b/src/gallium/include/state_tracker/vdpau_interop.h > @@ -0,0 +1,49 @@ > +/** > + * > + * Copyright 2013 Advanced Micro Devices, Inc. > + * All Rights Reserved. > + * > + * 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, sub license, 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 NON-INFRINGEMENT. > + * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) 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: > + * Christian König > + * > + */ > + > +#ifndef _VDPAU_INTEROP_H_ > +#define _VDPAU_INTEROP_H_ > + > +/* driver specific functions for NV_vdpau_interop */ > + > +#define VDP_FUNC_ID_BASE_DRIVER 0x2000 > +#define VDP_FUNC_ID_VIDEO_SURFACE_GALLIUM (VDP_FUNC_ID_BASE_DRIVER + 0) > +#define VDP_FUNC_ID_OUTPUT_SURFACE_GALLIUM (VDP_FUNC_ID_BASE_DRIVER + 1) > + > +struct pipe_resource; > +struct pipe
Re: [Mesa-dev] [PATCH 3/7] mesa: Shrink the size of the enum string lookup struct.
On Fri, Sep 20, 2013 at 7:52 PM, Eric Anholt wrote:
> Since it's only used for debug information, we can misalign the struct and
> save the disk space. Another 19k on a 64-bit build.
> ---
> src/mapi/glapi/gen/gl_enums.py | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/mapi/glapi/gen/gl_enums.py b/src/mapi/glapi/gen/gl_enums.py
> index e1ab600..6f54b06 100644
> --- a/src/mapi/glapi/gen/gl_enums.py
> +++ b/src/mapi/glapi/gen/gl_enums.py
> @@ -47,8 +47,8 @@ class PrintGlEnums(gl_XML.gl_print_base):
> print '#include "main/imports.h"'
> print '#include "main/mtypes.h"'
> print ''
> -print 'typedef struct {'
> -print ' size_t offset;'
> +print 'typedef struct __attribute__((__packed__)) {'
I don't know if that'll work with MSVC. To be safe, we should probably
wrap that in a #ifdef gcc test.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/7] mesa: Drop an extra copy-and-pasted copy in the program clone function.
On Fri, Sep 20, 2013 at 7:52 PM, Eric Anholt wrote: > --- > src/mesa/program/program.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/src/mesa/program/program.c b/src/mesa/program/program.c > index 5dd68d9..aa3c5b4 100644 > --- a/src/mesa/program/program.c > +++ b/src/mesa/program/program.c > @@ -485,7 +485,6 @@ _mesa_clone_program(struct gl_context *ctx, const struct > gl_program *prog) > if (prog->Parameters) >clone->Parameters = _mesa_clone_parameter_list(prog->Parameters); > memcpy(clone->LocalParams, prog->LocalParams, sizeof(clone->LocalParams)); > - memcpy(clone->LocalParams, prog->LocalParams, sizeof(clone->LocalParams)); > clone->IndirectRegisterFiles = prog->IndirectRegisterFiles; > clone->NumInstructions = prog->NumInstructions; > clone->NumTemporaries = prog->NumTemporaries; Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] mesa: Add core support for the GL_AMD_performance_monitor extension.
On Fri, Sep 20, 2013 at 3:42 PM, Kenneth Graunke wrote:
> On 09/20/2013 07:55 AM, Brian Paul wrote:
>> On Thu, Sep 19, 2013 at 5:27 PM, Kenneth Graunke
>> wrote:
> [snip]
>>> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
>>> index 6d700ec..70dba6e 100644
>>> --- a/src/mesa/main/mtypes.h
>>> +++ b/src/mesa/main/mtypes.h
>>> @@ -1778,6 +1778,89 @@ struct gl_transform_feedback_state
>>>
>>>
>>> /**
>>> + * A "performance monitor" as described in AMD_performance_monitor.
>>> + */
>>> +struct gl_perf_monitor_object
>>> +{
>>> + GLboolean Active;
>>> +
>>> + /**
>>> +* A list of groups with currently active counters.
>>> +*
>>> +* ActiveGroups[g] == n if there are n counters active from group 'g'.
>>> +*/
>>> + unsigned *ActiveGroups;
>>
>> GLuint?
>>
>
> I chose 'unsigned' over 'GLuint' here since it's only used internally,
> and never exposed by the API. But I can switch if you prefer that.
OK, I didn't realize that was the distinction being made. My impulse
is to either use all GL types in a struct or not (Mesa vs. gallium for
example). Your way is fine too.
I'm also trying to be watchful of signed vs. unsigned fields and loop
counters. MSVC likes to complain about signed/unsigned comparisons.
>
>>> +
>>> + /**
>>> +* An array of bitsets, subscripted by group ID, then indexed by
>>> counter ID.
>>> +*
>>> +* Checking whether counter 'c' in group 'g' is active can be done via:
>>> +*
>>> +*BITSET_TEST(ActiveCounters[g], c)
>>> +*/
>>> + GLuint **ActiveCounters;
>>
>> GLbitfield?
>
> The type here is actually BITSET_WORD (from bitset.h), which is a
> #define for GLuint. Including bitset.h from mtypes.h led to all kinds
> of problems, so I just used GLuint.
>
> It seems like we could do something better, but I'm not sure what.
OK, that's fine then.
>>> +};
>>> +
>>> +
>>> +union gl_perf_monitor_counter_value
>>> +{
>>> + float f;
>>> + uint64_t u64;
>>> + uint32_t u32;
>>> +};
>>> +
>>> +
>>> +struct gl_perf_monitor_counter
>>> +{
>>> + /** Human readable name for the counter. */
>>> + const char *Name;
>>> +
>>> + /**
>>> +* Data type of the counter. Valid values are FLOAT, UNSIGNED_INT,
>>> +* UNSIGNED_INT64_AMD, and PERCENTAGE_AMD.
>>> +*/
>>> + GLenum Type;
>>> +
>>> + /** Minimum counter value. */
>>> + union gl_perf_monitor_counter_value Minimum;
>>> +
>>> + /** Maximum counter value. */
>>> + union gl_perf_monitor_counter_value Maximum;
>>> +};
>>> +
>>> +
>>> +struct gl_perf_monitor_group
>>> +{
>>> + /** Human readable name for the group. */
>>> + const char *Name;
>>> +
>>> + /**
>>> +* Maximum number of counters in this group which can be active at the
>>> +* same time.
>>> +*/
>>> + GLint MaxActiveCounters;
>>
>> GLuint?
>
> That would make sense, but for some reason the AMD_performance_monitor
> extension exposes this value as a GLint:
>
> void GetPerfMonitorCountersAMD(uint group, int *numCounters,
>int *maxActiveCounters, sizei countersSize,
>uint *counters)
>
> I figured it should probably match...
Well, when I'm reading the code and see GLint, I think "ok, that value
could be negative". But that's not true here so I guess I'd still
prefer GLuint/unsigned.
>
>>> +
>>> + /** Array of counters within this group. */
>>> + const struct gl_perf_monitor_counter *Counters;
>>> + GLint NumCounters;
Same story with NumCounters??
>>> +};
>>> +
>>> +
>>> +/**
>>> + * Context state for AMD_performance_monitor.
>>> + */
>>> +struct gl_perf_monitor_state
>>> +{
>>> + /** Array of performance monitor groups (indexed by group ID) */
>>> + const struct gl_perf_monitor_group *Groups;
>>> + GLint NumGroups;
>>
>> GLuint?
>
> Likewise, the extension exposes this as a GLint:
>
> void GetPerfMonitorGroupsAMD(int *numGroups, sizei groupsSize,
> uint *groups)
>
> I don't know why...GLuint would have made more sense. Of course, nobody
> is going to have enough groups for it to make a difference :)
Yeah, but like I said, it matters when one's reading the code and
trying to get an understanding of what the legal values for a variable
might be.
>>> +void GLAPIENTRY
>>> +_mesa_GetPerfMonitorGroupStringAMD(GLuint group, GLsizei bufSize,
>>> + GLsizei *length, GLchar *groupString)
>>> +{
>>> + GET_CURRENT_CONTEXT(ctx);
>>> +
>>> + const struct gl_perf_monitor_group *group_obj = get_group(ctx, group);
>>> +
>>> + if (group_obj == NULL) {
>>> + _mesa_error(ctx, GL_INVALID_VALUE, "glGetPerfMonitorGroupStringAMD");
>>> + return;
>>> + }
>>> +
>>> + if (bufSize == 0) {
>>> + /* Return the number of characters that would be required to hold the
>>> + * group string, excluding the null terminator.
>>> + */
>>> + if (length != NULL)
>>> + *length = strlen(group_obj->Name);
>>> + } else {
>>> +
Re: [Mesa-dev] [PATCH 1/5] winsys/radeon: fix killing the CS thread
For all patches except NV_vdpau_interop:
Reviewed-by: Marek Olšák
For NV_vdpau_interop, I sent another review a while ago.
Mare
On Sat, Sep 21, 2013 at 4:41 PM, Christian König
wrote:
> From: Christian König
>
> Kill the thread only after we checked that it's not used any more, not before.
>
> Signed-off-by: Christian König
> ---
> src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> index 69c42a0..0a3b932 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> @@ -421,6 +421,10 @@ static void radeon_winsys_destroy(struct radeon_winsys
> *rws)
> {
> struct radeon_drm_winsys *ws = (struct radeon_drm_winsys*)rws;
>
> +if (!pipe_reference(&ws->base.reference, NULL)) {
> +return;
> +}
> +
> if (ws->thread) {
> ws->kill_thread = 1;
> pipe_semaphore_signal(&ws->cs_queued);
> @@ -429,10 +433,6 @@ static void radeon_winsys_destroy(struct radeon_winsys
> *rws)
> pipe_semaphore_destroy(&ws->cs_queued);
> pipe_condvar_destroy(ws->cs_queue_empty);
>
> -if (!pipe_reference(&ws->base.reference, NULL)) {
> -return;
> -}
> -
> pipe_mutex_destroy(ws->hyperz_owner_mutex);
> pipe_mutex_destroy(ws->cmask_owner_mutex);
> pipe_mutex_destroy(ws->cs_stack_lock);
> --
> 1.8.1.2
>
> ___
> 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 2/2] implement NV_vdpau_interop v3
Am 21.09.2013 16:56, schrieb Marek Olšák: 8) Do we actually have enough tests, so that we can say this feature works? I have integrated v2 of this patches yesterday in OpenELEC, an embedded XBMC distro and it looks already nice. I will start to create and provide testbuilds for our Users with this (Mesa-master, kernel 3.11). The goal for us is to replace the fglrx and fglrx-legacy driver with the radeon driver so we dont have to deal anymore with 2 fglrx driver versions, can update xorg and have a better support via the OSS community. Great work Christian and all others! greetings Stephan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/7] mesa: Shrink the size of the enum string lookup struct.
On 09/21/2013 07:59 AM, Brian Paul wrote:
> On Fri, Sep 20, 2013 at 7:52 PM, Eric Anholt wrote:
>> Since it's only used for debug information, we can misalign the struct and
>> save the disk space. Another 19k on a 64-bit build.
>> ---
>> src/mapi/glapi/gen/gl_enums.py | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mapi/glapi/gen/gl_enums.py b/src/mapi/glapi/gen/gl_enums.py
>> index e1ab600..6f54b06 100644
>> --- a/src/mapi/glapi/gen/gl_enums.py
>> +++ b/src/mapi/glapi/gen/gl_enums.py
>> @@ -47,8 +47,8 @@ class PrintGlEnums(gl_XML.gl_print_base):
>> print '#include "main/imports.h"'
>> print '#include "main/mtypes.h"'
>> print ''
>> -print 'typedef struct {'
>> -print ' size_t offset;'
>> +print 'typedef struct __attribute__((__packed__)) {'
>
> I don't know if that'll work with MSVC. To be safe, we should probably
> wrap that in a #ifdef gcc test.
>
> -Brian
Good catch - that doesn't work on MSVC.
Apparently on MSVC you do:
#pragma pack(push,1)
...
#pragma pack(pop)
Clang apparently supports either method.
Is it supposed to be __attribute__((__packed__)) or
__attribute__((packed))? I see both floating around the internet.
--Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] ralloc: Introduce new macros for defining C++ new/delete operators.
On 09/19/2013 03:35 PM, Ian Romanick wrote: > I like this approach a lot... certainly a lot more than various > inheritance-based approaches that we had discussed before. > > Patches 1, 2, 3, and 5 are > > Reviewed-by: Ian Romanick > > Patch 4 probably is too (with the comment addition that I suggested), > but I'd like to hear your thoughts about the performance implication > that I mentioned first. Since Ian, Eric, and Chad all responded favorably to the first three patches, and Francisco has started writing patches based against it, I've gone ahead and landed those. I've held off on the last two (hooking up destructors globally) due to Ian's concerns. It sounds like more discussion is necessary, which we can probably resume once things are a bit less chaotic :) --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 4/5] ralloc: Make the C++ macros arrange for class destructors to be called.
Ian Romanick writes:
> Premature "send" strikes again...
>
> On 09/19/2013 05:26 PM, Ian Romanick wrote:
>> On 09/18/2013 04:55 PM, Kenneth Graunke wrote:
>>> Previously, almost all classes didn't actually call their destructors,
>>> which is non-intuitive for C++ code. Setting them up to be called was
>>> somewhat of a pain, since it required defining a helper function.
>>>
>>> With the new macros, we can easily encapsulate this complexity, making
>>> destructors just happen automatically.
>>>
>>> Signed-off-by: Kenneth Graunke
>>> ---
>>> src/glsl/ralloc.h | 8
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/src/glsl/ralloc.h b/src/glsl/ralloc.h
>>> index 799d3a9..82a3daa 100644
>>> --- a/src/glsl/ralloc.h
>>> +++ b/src/glsl/ralloc.h
>>> @@ -405,15 +405,23 @@ bool ralloc_vasprintf_append(char **str, const char
>>> *fmt, va_list args);
>>> #endif
>>>
>>> #define _RALLOC_OPS(ALLOC, TYPE) \
>>> +private: \
>>> + static void _ralloc_##TYPE##_destructor_callback(void *p) \
>>> + { \
>>> + reinterpret_cast(p)->~TYPE(); \
>>> + } \
>>> +public: \
>>> static void* operator new(size_t size, void *mem_ctx) \
>>> { \
>>>void *p = ALLOC(mem_ctx, size);\
>>>assert(p != NULL); \
>>> + ralloc_set_destructor(p, _ralloc_##TYPE##_destructor_callback);\
>
> All of the IR objects share the ir_instruction destructor:
>
>virtual ~ir_instruction()
>{
>}
>
> Doing this universally will add two indirect function calls when every
> object is released. I wish we had a compiler benchmark so that we could
> know whether this is going to hurt app start up time on apps with lots
> of large shaders. :(
You can test this easily, thanks to shader_runner, "time", and
shader-db.
For a large l4d2 shader:
N Min MaxMedian AvgStddev
x 1088 0.012401 0.024984 0.017926 0.017903518 0.0018709739
+ 1088 0.012483 0.028997 0.017919 0.017883756 0.0019610448
No difference proven at 95.0% confidence
pgp5ojOD_bOWB.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Minor st/xorg related cleanups
A couple of small things that I've noticed while going through. Bit curious if there would be anyone to review and/or commit the nouveau patch so I've decided to send it along the st/xorg one :P Cheers Emil [PATCH 1/2] targets/xorg-nouveau: drop usage of dri1 function [PATCH 2/2] st/xorg: add sanity checks after malloc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] targets/xorg-nouveau: drop usage of dri1 function DRICreatePCIBusID
The function should have never used it in the first place as it was
a left over from the DRI1 days of the nouveau ddx. While we're around
check if KMS is supported before opening the nouveau device, and
add support for Fermi & Kepler cards.
Compile tested only due to the lack of a Fermi/Kepler card.
Signed-off-by: Emil Velikov
---
As there is not much testing of xorg-nouveau one could be rather
cautious with such commits, although this is a direct "port" from
the nouveau ddx. If anyone believes that if would be beneficial
to split the changes into separate patches, please give me a shout.
Cheers
Emil
---
src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 27 +
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
index 2324d24..035aa83 100644
--- a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
+++ b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
@@ -30,7 +30,6 @@
#include "../../state_trackers/xorg/xorg_winsys.h"
#include
-#include
#include
static void nouveau_xorg_identify(int flags);
@@ -130,32 +129,31 @@ nouveau_xorg_pci_probe(DriverPtr driver,
char *busid;
int chipset, ret;
-if (device->vendor_id != 0x10DE)
+busid = malloc(64);
+if (!busid)
return FALSE;
-if (!xf86LoaderCheckSymbol("DRICreatePCIBusID")) {
- xf86DrvMsg(-1, X_ERROR, "[drm] No DRICreatePCIBusID symbol\n");
+sprintf(busid, "pci:%04x:%02x:%02x.%d",
+ device->domain, device->bus,
+ device->dev, device->func);
+
+ret = drmCheckModesettingSupported(busid);
+if (ret) {
+ xf86DrvMsg(-1, X_ERROR, "[drm] KMS not enabled\n");
+ free(busid);
return FALSE;
}
-busid = DRICreatePCIBusID(device);
ret = nouveau_device_open(busid, &dev);
+free(busid);
if (ret) {
xf86DrvMsg(-1, X_ERROR, "[drm] failed to open device\n");
- free(busid);
return FALSE;
}
chipset = dev->chipset;
nouveau_device_del(&dev);
-ret = drmCheckModesettingSupported(busid);
-free(busid);
-if (ret) {
- xf86DrvMsg(-1, X_ERROR, "[drm] KMS not enabled\n");
- return FALSE;
-}
-
switch (chipset & 0xf0) {
case 0x00:
case 0x10:
@@ -170,6 +168,9 @@ nouveau_xorg_pci_probe(DriverPtr driver,
case 0x90:
case 0xa0:
case 0xc0:
+case 0xd0:
+case 0xe0:
+case 0xf0:
xf86DrvMsg(-1, X_INFO, "Detected chipset: NV%02x\n", chipset);
break;
default:
--
1.8.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] st/xorg: add sanity checks after malloc
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/xorg/xorg_driver.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/state_trackers/xorg/xorg_driver.c
b/src/gallium/state_trackers/xorg/xorg_driver.c
index 9d7713c..49e726b 100644
--- a/src/gallium/state_trackers/xorg/xorg_driver.c
+++ b/src/gallium/state_trackers/xorg/xorg_driver.c
@@ -125,6 +125,9 @@ Bool
xorg_tracker_have_modesetting(ScrnInfoPtr pScrn, struct pci_device *device)
{
char *BusID = malloc(64);
+
+if (!BusID)
+ return FALSE;
sprintf(BusID, "pci:%04x:%02x:%02x.%d",
device->domain, device->bus,
device->dev, device->func);
@@ -277,6 +280,9 @@ drv_init_drm(ScrnInfoPtr pScrn)
char *BusID;
BusID = malloc(64);
+ if (!BusID)
+ return FALSE;
+
sprintf(BusID, "PCI:%d:%d:%d",
((ms->PciInfo->domain << 8) | ms->PciInfo->bus),
ms->PciInfo->dev, ms->PciInfo->func
--
1.8.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Consolidate the remaining source files to Makefile.sources
On 12/09/13 18:04, Jakob Bornecrantz wrote:
> On Thu, Aug 15, 2013 at 7:04 PM, Emil Velikov wrote:
>
>> Hello list
>>
>> Feeling inspired by the automake work done in mesa, I felt like
>> finishing a few things that did not receive too much attention
>> * use Makefile.sources wherever possible
>> * cleanup the duplicated C{,PP,XX}FLAGS and factor out the the common
>> ones into Automake.inc
>>
>> If anyone is interested I have pushed my preliminary work to the
>> makefile.sources branch at https://github.com/evelikov/Mesa/
>>
>> Currently I have gone through the following:
>> gallium/drivers
>> gallium/state_trackers/dri/drm
>> gallium/state_trackers/dri/sw
>> gallium/state_trackers/vega
>> gallium/state_trackers/xorg
>>
>> Producing the following diff stat:
>> 54 files changed, 352 insertions(+), 552 deletions(-)
>>
>>
>> Pros:
>> * patches such as "gallium/dri-targets: hide all symbols except for
>> __driDriverExtensions" will be brought down to changing only with 2-3 lines
>> * one less chance of breaking builds when someone forgets to update the
>> SCons/Makefile.am/etc build, after adding/removing a file
>>
>> Cons:
>> * Non nouveau changes will be only(lacking any other the hardware atm).
>> Note that I will check the symbols for all drivers, to ensure that I do
>> not cause chaos.
>>
>> Curious if anyone is interested and have any comments on this.
>> Note: there may be some git rebase fails as I've started this ~3months ago
>>
>
> This seems to be have dropped on the floor.
>
> The Makefile.sources patches looks good, can't comment on the other ones.
>
> If you rebase them and you clobber the Makefile.sources ones, then send that
> along with the reset of the patches on that branch out I'm sure they will
> get reviewed.
>
Indeed, I was away for a few weeks and I'm just getting back to this.
While doing the Makefile.sources for the st/glx and st/egl I started
tearing my hairs out so I guess I'll leave that for later. The further
changes compacting the common flags/etc into drivers/targets/st specific
Automake.inc is in the works although I assume that some fun stuff may
happen around radeon/llvm.
First things first I'll send the Makefile.sources (plus a couple of
small fixes) later on tonight.
Cheers,
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] implement NV_vdpau_interop v3
Exactly as I though. It's code that I never worked with and I only implemented it so far that XBMC does indeed work, but clearly following the spec is something different. I've committed the rest of the patchset, but I have my doubts that Tim wants me to spend any more time on it, so we have a slightly resource conflict here. So does anybody from the list want to volunteer to fix the things Marek pointed out? Otherwise we should just leave it like this for now and if nobody else volunteered till Wednesday we are trying to shift priorities internally a bit. Thanks for the review, Christian. Am 21.09.2013 16:56, schrieb Marek Olšák: 1) The Errors section of the spec isn't implemented properly. 2) Passing GL_TEXTURE_RECTANGLE to the new functions should generate an error if ctx->Extensions.NV_texture_rectangle is false. 3) There should also probably be some checking for GL_ARB_texture_non_power_of_two, but the spec doesn't say what we should do (probably return GL_INVALID_OPERATION). 4) VDPAUGetSurfaceivNV isn't implemented properly. 5) The unregistering in VDPAUFiniNV should be implemented too. 6) Registered and mapped VDPAU textures are not allowed to be re-specified by TexImage, TexSubImage, TexImage*Multisample, CopyTexImage, CopyTexSubImage, TexStorage, TexStorage*Multisample, and similar functions. This should be properly handled in those functions and GL errors should be returned. 7) The extension spec says that all VDPAU textures should be y-inverted. Is that actually the case here? 8) Do we actually have enough tests, so that we can say this feature works? Marek On Sat, Sep 21, 2013 at 12:32 PM, Christian König wrote: From: Christian König v2: Actually implement interop between the gallium state tracker and the VDPAU backend. v3: Make it also available in non legacy contexts, fix video buffer sharing. Signed-off-by: Christian König --- src/gallium/include/state_tracker/vdpau_interop.h | 49 src/gallium/state_trackers/vdpau/ftab.c | 31 ++- src/gallium/state_trackers/vdpau/output.c | 11 + src/gallium/state_trackers/vdpau/surface.c| 21 ++ src/gallium/state_trackers/vdpau/vdpau_private.h | 6 + src/mapi/glapi/gen/Makefile.am| 1 + src/mapi/glapi/gen/NV_vdpau_interop.xml | 69 ++ src/mapi/glapi/gen/gl_API.xml | 2 + src/mapi/glapi/gen/gl_genexec.py | 1 + src/mesa/Makefile.sources | 4 +- src/mesa/main/dd.h| 14 ++ src/mesa/main/extensions.c| 1 + src/mesa/main/mtypes.h| 9 + src/mesa/main/vdpau.c | 279 ++ src/mesa/main/vdpau.h | 72 ++ src/mesa/state_tracker/st_context.c | 3 + src/mesa/state_tracker/st_extensions.c| 1 + src/mesa/state_tracker/st_vdpau.c | 193 +++ src/mesa/state_tracker/st_vdpau.h | 42 19 files changed, 800 insertions(+), 9 deletions(-) create mode 100644 src/gallium/include/state_tracker/vdpau_interop.h create mode 100644 src/mapi/glapi/gen/NV_vdpau_interop.xml create mode 100644 src/mesa/main/vdpau.c create mode 100644 src/mesa/main/vdpau.h create mode 100644 src/mesa/state_tracker/st_vdpau.c create mode 100644 src/mesa/state_tracker/st_vdpau.h diff --git a/src/gallium/include/state_tracker/vdpau_interop.h b/src/gallium/include/state_tracker/vdpau_interop.h new file mode 100644 index 000..3ca7c9d --- /dev/null +++ b/src/gallium/include/state_tracker/vdpau_interop.h @@ -0,0 +1,49 @@ +/** + * + * Copyright 2013 Advanced Micro Devices, Inc. + * All Rights Reserved. + * + * 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, sub license, 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 NON-INFRINGEMENT. + * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) 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
Re: [Mesa-dev] [PATCH 2/2] implement NV_vdpau_interop v3
Am 21.09.2013 17:35, schrieb Stephan Raue: Am 21.09.2013 16:56, schrieb Marek Olšák: 8) Do we actually have enough tests, so that we can say this feature works? I have integrated v2 of this patches yesterday in OpenELEC, an embedded XBMC distro and it looks already nice. I will start to create and provide testbuilds for our Users with this (Mesa-master, kernel 3.11). The goal for us is to replace the fglrx and fglrx-legacy driver with the radeon driver so we dont have to deal anymore with 2 fglrx driver versions, can update xorg and have a better support via the OSS community. Great work Christian and all others! Well that XBMC is now working is quite nice, but I think Marek though more about piglit or other dedicated unit tests to prove that we are following the spec here. Otherwise it's just a implementation that works with a single application and not much else. Christian. greetings Stephan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/7] mesa: Shrink the size of the enum string lookup struct.
On 21 September 2013 09:03, Kenneth Graunke wrote:
> On 09/21/2013 07:59 AM, Brian Paul wrote:
> > On Fri, Sep 20, 2013 at 7:52 PM, Eric Anholt wrote:
> >> Since it's only used for debug information, we can misalign the struct
> and
> >> save the disk space. Another 19k on a 64-bit build.
> >> ---
> >> src/mapi/glapi/gen/gl_enums.py | 6 --
> >> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/src/mapi/glapi/gen/gl_enums.py
> b/src/mapi/glapi/gen/gl_enums.py
> >> index e1ab600..6f54b06 100644
> >> --- a/src/mapi/glapi/gen/gl_enums.py
> >> +++ b/src/mapi/glapi/gen/gl_enums.py
> >> @@ -47,8 +47,8 @@ class PrintGlEnums(gl_XML.gl_print_base):
> >> print '#include "main/imports.h"'
> >> print '#include "main/mtypes.h"'
> >> print ''
> >> -print 'typedef struct {'
> >> -print ' size_t offset;'
> >> +print 'typedef struct __attribute__((__packed__)) {'
> >
> > I don't know if that'll work with MSVC. To be safe, we should probably
> > wrap that in a #ifdef gcc test.
> >
> > -Brian
>
> Good catch - that doesn't work on MSVC.
>
> Apparently on MSVC you do:
> #pragma pack(push,1)
> ...
> #pragma pack(pop)
>
> Clang apparently supports either method.
>
> Is it supposed to be __attribute__((__packed__)) or
> __attribute__((packed))? I see both floating around the internet.
>
GCC docs (
http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html#Type-Attributes)
indicate that either "__packed__" or "packed" is allowed. I don't think it
matters in our case--the rationale for using "__packed__" is if you're
worried about conflicts with a preprocessor macro called "packed".
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/7] glsl: Hide many classes local to individual .cpp files in anon namespaces.
On 09/20/2013 06:52 PM, Eric Anholt wrote: > This gives the compiler the chance to inline and not export class symbols > even in the absence of LTO. Saves about 60kb on disk. This is probably worth doing. Reviewed-by: Kenneth Graunke Another important reason for doing this is that it avoids name collisions. By default, classes have external linkage, which means that if you compile two files together that both define classes with the same name, bad things happen. You might get link errors, or it might just randomly link code against the wrong one, with no messages whatsoever. See commit 5cadb3ef7e6c1a67c45b0fdb2b0c2c1a369a97d8 for a bit of history where this was actually happening, and we had real bugs as a result. However, this is also extremely irritating: it prevents you from doing: (gdb) break builtin_builder::create_shader Instead, you have to do: (gdb) break (anonymous namespace)::builtin_builder::create_shader I'm having a really hard time believing that gdb doesn't have a better/shorter way of doing this, but I sure can't find one. If all else fails, you can always resort to line numbers: (gdb) break builtin_functions.cpp:599 Apparently, debugging with anonymous namespaces on MSVC is even worse. The lack of 'static' for forcing internal linkage on classes is simply maddening. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Reenable glBitmap() after the sRGB winsys enabling.
The format of the window system framebuffer changed from ARGB to
SARGB8, but we're still supposed to render to it the same as ARGB
unless the user flipped the GL_FRAMEBUFFER_SRGB switch.
---
src/mesa/drivers/dri/i965/intel_pixel_bitmap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_pixel_bitmap.c
b/src/mesa/drivers/dri/i965/intel_pixel_bitmap.c
index 5398cb8..91f21a3 100644
--- a/src/mesa/drivers/dri/i965/intel_pixel_bitmap.c
+++ b/src/mesa/drivers/dri/i965/intel_pixel_bitmap.c
@@ -25,6 +25,7 @@
*
**/
+#include "main/blend.h"
#include "main/glheader.h"
#include "main/enums.h"
#include "main/image.h"
@@ -227,7 +228,7 @@ do_blit_bitmap( struct gl_context *ctx,
UNCLAMPED_FLOAT_TO_UBYTE(ubcolor[2], tmpColor[2]);
UNCLAMPED_FLOAT_TO_UBYTE(ubcolor[3], tmpColor[3]);
- switch (irb->mt->format) {
+ switch (_mesa_get_render_format(ctx, intel_rb_format(irb))) {
case MESA_FORMAT_ARGB:
case MESA_FORMAT_XRGB:
color = PACK_COLOR_(ubcolor[3], ubcolor[0], ubcolor[1], ubcolor[2]);
--
1.8.4.rc3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/blorp: Fix the register types on blorp's push constants.
The UD values were getting set up as floats. This happened to work out
because they were used as the second argument where the first was a dword,
and gen6+ doesn't do source conversions. But it did trigger fulsim
warnings, and it meant if you used the push constant as the first operand
you would have been disappointed.
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 32 ++--
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index f07d39f..c1880e3 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -899,22 +899,22 @@ void
brw_blorp_blit_program::alloc_push_const_regs(int base_reg)
{
#define CONST_LOC(name) offsetof(brw_blorp_wm_push_constants, name)
-#define ALLOC_REG(name) \
- this->name = \
- brw_vec1_reg(BRW_GENERAL_REGISTER_FILE, \
- base_reg + CONST_LOC(name) / 32, \
- (CONST_LOC(name) % 32) / 4)
-
- ALLOC_REG(dst_x0);
- ALLOC_REG(dst_x1);
- ALLOC_REG(dst_y0);
- ALLOC_REG(dst_y1);
- ALLOC_REG(rect_grid_x1);
- ALLOC_REG(rect_grid_y1);
- ALLOC_REG(x_transform.multiplier);
- ALLOC_REG(x_transform.offset);
- ALLOC_REG(y_transform.multiplier);
- ALLOC_REG(y_transform.offset);
+#define ALLOC_REG(name, type) \
+ this->name = \
+ retype(brw_vec1_reg(BRW_GENERAL_REGISTER_FILE,\
+ base_reg + CONST_LOC(name) / 32, \
+ (CONST_LOC(name) % 32) / 4), type)
+
+ ALLOC_REG(dst_x0, BRW_REGISTER_TYPE_UD);
+ ALLOC_REG(dst_x1, BRW_REGISTER_TYPE_UD);
+ ALLOC_REG(dst_y0, BRW_REGISTER_TYPE_UD);
+ ALLOC_REG(dst_y1, BRW_REGISTER_TYPE_UD);
+ ALLOC_REG(rect_grid_x1, BRW_REGISTER_TYPE_F);
+ ALLOC_REG(rect_grid_y1, BRW_REGISTER_TYPE_F);
+ ALLOC_REG(x_transform.multiplier, BRW_REGISTER_TYPE_F);
+ ALLOC_REG(x_transform.offset, BRW_REGISTER_TYPE_F);
+ ALLOC_REG(y_transform.multiplier, BRW_REGISTER_TYPE_F);
+ ALLOC_REG(y_transform.offset, BRW_REGISTER_TYPE_F);
#undef CONST_LOC
#undef ALLOC_REG
}
--
1.8.4.rc3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/7] glsl: Hide many classes local to individual .cpp files in anon namespaces.
On 09/21/2013 03:16 PM, Kenneth Graunke wrote: > On 09/20/2013 06:52 PM, Eric Anholt wrote: >> This gives the compiler the chance to inline and not export class symbols >> even in the absence of LTO. Saves about 60kb on disk. > > This is probably worth doing. > Reviewed-by: Kenneth Graunke > > Another important reason for doing this is that it avoids name > collisions. By default, classes have external linkage, which means that > if you compile two files together that both define classes with the same > name, bad things happen. You might get link errors, or it might just > randomly link code against the wrong one, with no messages whatsoever. > > See commit 5cadb3ef7e6c1a67c45b0fdb2b0c2c1a369a97d8 for a bit of history > where this was actually happening, and we had real bugs as a result. > > However, this is also extremely irritating: it prevents you from doing: > > (gdb) break builtin_builder::create_shader > > Instead, you have to do: > > (gdb) break (anonymous namespace)::builtin_builder::create_shader Oof. Should we avoid the anonymous name space in debug builds? Hmm... that seems pretty awful too. > I'm having a really hard time believing that gdb doesn't have a > better/shorter way of doing this, but I sure can't find one. > > If all else fails, you can always resort to line numbers: > (gdb) break builtin_functions.cpp:599 > > Apparently, debugging with anonymous namespaces on MSVC is even worse. > > The lack of 'static' for forcing internal linkage on classes is simply > maddening. > ___ > 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] [RFC PATCH 4/5] ralloc: Make the C++ macros arrange for class destructors to be called.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/21/2013 11:41 AM, Eric Anholt wrote:
> Ian Romanick writes:
>
>> Premature "send" strikes again...
>>
>> On 09/19/2013 05:26 PM, Ian Romanick wrote:
>>> On 09/18/2013 04:55 PM, Kenneth Graunke wrote:
Previously, almost all classes didn't actually call their
destructors, which is non-intuitive for C++ code. Setting
them up to be called was somewhat of a pain, since it
required defining a helper function.
With the new macros, we can easily encapsulate this
complexity, making destructors just happen automatically.
Signed-off-by: Kenneth Graunke ---
src/glsl/ralloc.h | 8 1 file changed, 8
insertions(+)
diff --git a/src/glsl/ralloc.h b/src/glsl/ralloc.h index
799d3a9..82a3daa 100644 --- a/src/glsl/ralloc.h +++
b/src/glsl/ralloc.h @@ -405,15 +405,23 @@ bool
ralloc_vasprintf_append(char **str, const char *fmt, va_list
args); #endif
#define _RALLOC_OPS(ALLOC, TYPE)
\ +private:
\ + static void _ralloc_##TYPE##_destructor_callback(void
*p) \ + {
\ + reinterpret_cast(p)->~TYPE();
\ + }
\ +public:
\ static void* operator new(size_t size, void *mem_ctx)
\ {
\ void *p = ALLOC(mem_ctx, size);
\ assert(p != NULL);
\ + ralloc_set_destructor(p,
_ralloc_##TYPE##_destructor_callback);\
>>
>> All of the IR objects share the ir_instruction destructor:
>>
>> virtual ~ir_instruction() { }
>>
>> Doing this universally will add two indirect function calls when
>> every object is released. I wish we had a compiler benchmark so
>> that we could know whether this is going to hurt app start up
>> time on apps with lots of large shaders. :(
>
> You can test this easily, thanks to shader_runner, "time", and
> shader-db.
>
> For a large l4d2 shader: N Min Max
> Median AvgStddev x 1088 0.012401
> 0.024984 0.017926 0.017903518 0.0018709739 + 1088
> 0.012483 0.028997 0.017919 0.017883756 0.0019610448 No
> difference proven at 95.0% confidence
Does shader-db compile all the shaders in a single GL context? If it
doesn't there's probably a lot of other overhead that could mask the
issue. Still, this definitely means that compile times won't skyrocket...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
iEYEARECAAYFAlI+Z9UACgkQX1gOwKyEAw9xeACcCWkedkyMwQtHjZ1u8iXytgk+
RmgAn1pXSLSJ3yUMJrwW6nuJXzTGWTKb
=6g6N
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
