Re: [Mesa-dev] [PATCH 0/3] i965: Let driconf clamp_max_samples affect context version
On 11/20/2013 02:10 PM, Chad Versace wrote: This series makes clamp_max_samples actually useful enabling/disabling MSAA on Chromium. Without this series, clamp_max_samples=0 makes WebGL context creation fail on Chromium. Eric complained that brw_clamp_max_samples() too closely resembled intel_quantize_num_samples(), so this series removes the conceptual duplication between the two functions. It moves the list of supported MSAA modes to a shared function. Chad Versace (3): i965: Terminate brw_supported_msaa_modes() list with -1, not 0 i965: Share code between intel_quantize_num_samples and clamp_max_samples i965: Let driconf clamp_max_samples affect context version src/mesa/drivers/dri/i965/brw_context.c | 77 +--- src/mesa/drivers/dri/i965/intel_fbo.c| 28 +--- src/mesa/drivers/dri/i965/intel_screen.c | 20 + src/mesa/drivers/dri/i965/intel_screen.h | 3 ++ 4 files changed, 53 insertions(+), 75 deletions(-) This series is: Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 9/9] svga/winsys: Implement surface sharing using prime fd handles
On 11/21/2013 05:11 AM, christopher.halse.rog...@canonical.com wrote:
From: Thomas Hellstrom thellst...@vmware.com
This needs a prime-aware vmwgfx kernel module to work properly.
(With additions by Christopher James Halse Rogers r...@ubuntu.com)
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/targets/dri-vmwgfx/target.c | 13 +
src/gallium/winsys/svga/drm/vmw_screen_dri.c | 79 +---
2 files changed, 74 insertions(+), 18 deletions(-)
diff --git a/src/gallium/targets/dri-vmwgfx/target.c
b/src/gallium/targets/dri-vmwgfx/target.c
index e01e465..aaf37b0 100644
--- a/src/gallium/targets/dri-vmwgfx/target.c
+++ b/src/gallium/targets/dri-vmwgfx/target.c
@@ -31,11 +31,24 @@ static const struct drm_conf_ret throttle_ret = {
.val.val_int = 2,
};
+/* Technically this requires kernel support that is not yet
+ * widespread.
+ *
+ * We could check for support in create_screen and return the correct
+ * value, but for now just return true in all cases.
+ */
Good point. I will bump the drm vmwgfx driver minor to advertise prime
support,
but this is fine for now.
+static const struct drm_conf_ret share_fd_ret = {
+ .type = DRM_CONF_BOOL,
+ .val.val_int = true,
+};
+
static const struct drm_conf_ret *drm_configuration(enum drm_conf conf)
{
switch (conf) {
case DRM_CONF_THROTTLE:
return throttle_ret;
+ case DRM_CONF_SHARE_FD:
+ return share_fd_ret;
default:
break;
}
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_dri.c
b/src/gallium/winsys/svga/drm/vmw_screen_dri.c
index 6323a8a..a17cdf7 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_dri.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_dri.c
@@ -40,6 +40,7 @@
#include xf86drm.h
#include stdio.h
+#include fcntl.h
struct dri1_api_version {
int major;
@@ -160,37 +161,57 @@ vmw_drm_surface_from_handle(struct svga_winsys_screen
*sws,
union drm_vmw_surface_reference_arg arg;
struct drm_vmw_surface_arg *req = arg.req;
struct drm_vmw_surface_create_req *rep = arg.rep;
+uint32_t handle = 0;
int ret;
int i;
-if (whandle-type != DRM_API_HANDLE_TYPE_SHARED) {
-vmw_error(Attempt to import unknown handle type %d\n,
- whandle-type);
-return NULL;
+switch (whandle-type) {
+case DRM_API_HANDLE_TYPE_SHARED:
+case DRM_API_HANDLE_TYPE_KMS:
+ handle = whandle-handle;
+ break;
+case DRM_API_HANDLE_TYPE_FD:
+ ret = drmPrimeFDToHandle(vws-ioctl.drm_fd, whandle-handle,
+handle);
+ if (ret) {
+ vmw_error(Failed to get handle from prime fd %d.\n,
+ (int) whandle-handle);
+ return NULL;
+ }
+ break;
+default:
+ vmw_error(Attempt to import unsupported handle type %d.\n,
+ whandle-type);
+ return NULL;
}
-/**
- * The vmware device specific handle is the hardware SID.
- * FIXME: We probably want to move this to the ioctl implementations.
- */
-
memset(arg, 0, sizeof(arg));
-req-sid = whandle-handle;
+req-sid = handle;
ret = drmCommandWriteRead(vws-ioctl.drm_fd, DRM_VMW_REF_SURFACE,
arg, sizeof(arg));
+/*
+ * Need to close the handle we got from prime.
+ */
+if (whandle-type == DRM_API_HANDLE_TYPE_FD)
+ vmw_ioctl_surface_destroy(vws, handle);
+
if (ret) {
-vmw_error(Failed referencing shared surface. SID %d.\n
- Error %d (%s).\n,
- whandle-handle, ret, strerror(-ret));
- return NULL;
+ /*
+* Any attempt to share something other than a surface, like a dumb
+* kms buffer, should fail here.
+*/
+ vmw_error(Failed referencing shared surface. SID %d.\n
+ Error %d (%s).\n,
+ handle, ret, strerror(-ret));
+ return NULL;
}
if (rep-mip_levels[0] != 1) {
vmw_error(Incorrect number of mipmap levels on shared surface.
SID %d, levels %d\n,
- whandle-handle, rep-mip_levels[0]);
+ handle, rep-mip_levels[0]);
goto out_mip;
}
@@ -198,7 +219,7 @@ vmw_drm_surface_from_handle(struct svga_winsys_screen *sws,
if (rep-mip_levels[i] != 0) {
vmw_error(Incorrect number of faces levels on shared surface.
SID %d, face %d present.\n,
- whandle-handle, i);
+ handle, i);
goto out_mip;
}
}
@@ -210,14 +231,15 @@ vmw_drm_surface_from_handle(struct svga_winsys_screen
*sws,
pipe_reference_init(vsrf-refcnt, 1);
p_atomic_set(vsrf-validated, 0);
vsrf-screen = vws;
-vsrf-sid = whandle-handle;
+vsrf-sid = handle;
ssrf = svga_winsys_surface(vsrf);
*format = rep-format;
return ssrf;
Re: [Mesa-dev] [PATCH] mesa: Update MESA_INFO to eliminate error
On 10/24/2013 12:13 PM, Courtney Goeltzenleuchter wrote:
If a user set MESA_INFO and the OpenGL application uses a
3.0 or later context then the MESA_INFO debug output will have
an error when it queries for extensions using the deprecated
enum GL_EXTENSIONS. Passing context argument allows code
to return extension list directly regardless of profile.
Commit title updated as recommended by Kenneth Graunke.
---
src/mesa/main/context.c | 2 +-
src/mesa/main/debug.c | 10 +++---
src/mesa/main/debug.h | 2 +-
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 0d1f71c..8218153 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1522,7 +1522,7 @@ _mesa_make_current( struct gl_context *newCtx,
* information.
*/
if (_mesa_getenv(MESA_INFO)) {
- _mesa_print_info();
+ _mesa_print_info(newCtx);
}
newCtx-FirstTimeCurrent = GL_FALSE;
diff --git a/src/mesa/main/debug.c b/src/mesa/main/debug.c
index 9434c1e..99b2147 100644
--- a/src/mesa/main/debug.c
+++ b/src/mesa/main/debug.c
@@ -103,7 +103,7 @@ _mesa_print_state( const char *msg, GLuint state )
/**
* Print information about this Mesa version and build options.
*/
-void _mesa_print_info( void )
+void _mesa_print_info( struct gl_context *ctx )
{
_mesa_debug(NULL, Mesa GL_VERSION = %s\n,
(char *) _mesa_GetString(GL_VERSION));
@@ -111,8 +111,12 @@ void _mesa_print_info( void )
(char *) _mesa_GetString(GL_RENDERER));
_mesa_debug(NULL, Mesa GL_VENDOR = %s\n,
(char *) _mesa_GetString(GL_VENDOR));
- _mesa_debug(NULL, Mesa GL_EXTENSIONS = %s\n,
-(char *) _mesa_GetString(GL_EXTENSIONS));
+
+ /* use ctx as GL_EXTENSIONS will not work on 3.0 or higher
+* core contexts.
+*/
+ _mesa_debug(NULL, Mesa GL_EXTENSIONS = %s\n, ctx-Extensions.String);
+
#if defined(THREADS)
_mesa_debug(NULL, Mesa thread-safe: YES\n);
#else
diff --git a/src/mesa/main/debug.h b/src/mesa/main/debug.h
index 8414c5e..902f595 100644
--- a/src/mesa/main/debug.h
+++ b/src/mesa/main/debug.h
@@ -43,7 +43,7 @@ struct gl_texture_image;
extern void _mesa_print_enable_flags( const char *msg, GLuint flags );
extern void _mesa_print_state( const char *msg, GLuint state );
-extern void _mesa_print_info( void );
+extern void _mesa_print_info( struct gl_context *ctx );
extern void _mesa_init_debug( struct gl_context *ctx );
extern void
I just realized this never went upstream.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
Also pushed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Don't use gbm_dri_device when its not there
On 10/23/2013 01:41 AM, Jørgen Lind wrote: --- src/egl/drivers/dri2/egl_dri2.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c index b29eb1c..b143a95 100644 --- a/src/egl/drivers/dri2/egl_dri2.c +++ b/src/egl/drivers/dri2/egl_dri2.c @@ -1843,10 +1843,12 @@ dri2_bind_wayland_display_wl(_EGLDriver *drv, _EGLDisplay *disp, if (!dri2_dpy-wl_server_drm) return EGL_FALSE; +#ifdef HAVE_DRM_PLATFORM /* We have to share the wl_drm instance with gbm, so gbm can convert * wl_buffers to gbm bos. */ if (dri2_dpy-gbm_dri) dri2_dpy-gbm_dri-wl_drm = dri2_dpy-wl_server_drm; +#endif return EGL_TRUE; } Kristian, I noticed this patch never received any review of any sort, and isn't upstream. Could you take a look? Thanks, --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 50754] Building 32 bit mesa on 64 bit OS fails since change for automake
https://bugs.freedesktop.org/show_bug.cgi?id=50754 Eero Tamminen eero.t.tammi...@intel.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- CC||eero.t.tammi...@intel.com, ||petri.latv...@intel.com --- Comment #23 from Eero Tamminen eero.t.tammi...@intel.com --- (In reply to comment #22) I'm closing this bug because I'm able to crosscompile anytime with the help of some variables. This is Mesa bug. You being able to work around Mesa bug doesn't mean that it's fixed in Mesa. Re-opening. IMHO either --enable-32-bit should be removed as misleading[1], or Mesa should be fixed. [1] as discussed, it sets CFLAGS/CXXFLAGS too late, so they don't have the required effect. Regarding Tapani's patch fixing this, there would need to be also a comment in configure.ac about the libtool initialization dependency on C/XXFLAGS values. -- 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 45466] Updated configure.ac check for llvm-config to use 32 version when appropriate
https://bugs.freedesktop.org/show_bug.cgi?id=45466 Bug 45466 depends on bug 50754, which changed state. Bug 50754 Summary: Building 32 bit mesa on 64 bit OS fails since change for automake https://bugs.freedesktop.org/show_bug.cgi?id=50754 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 41700] Gallium won't build with --enable-32-bit on a 64-bit system
https://bugs.freedesktop.org/show_bug.cgi?id=41700 Bug 41700 depends on bug 50754, which changed state. Bug 50754 Summary: Building 32 bit mesa on 64 bit OS fails since change for automake https://bugs.freedesktop.org/show_bug.cgi?id=50754 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: support 8bit subpixel precision
Great!
Couple of comments inline.
On 11/21/2013 12:02 AM, Zack Rusin wrote:
8 bit precision is required by d3d10 but unfortunately
requires 64 bit rasterizer. This commit implements
64 bit rasterization with full support for 8bit subpixel
precision. It's a combination of all individual commits
from the llvmpipe-rast-64 branch.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/drivers/llvmpipe/lp_rast.c | 11 ++
src/gallium/drivers/llvmpipe/lp_rast.h | 47 +--
src/gallium/drivers/llvmpipe/lp_rast_debug.c | 6 +-
src/gallium/drivers/llvmpipe/lp_rast_priv.h| 27
src/gallium/drivers/llvmpipe/lp_rast_tri.c | 173 +
src/gallium/drivers/llvmpipe/lp_rast_tri_tmp.h | 56
src/gallium/drivers/llvmpipe/lp_setup_line.c | 2 +-
src/gallium/drivers/llvmpipe/lp_setup_tri.c| 155 ++
src/gallium/tests/graw/SConscript | 1 +
src/gallium/tests/graw/tri-large.c | 173 +
10 files changed, 500 insertions(+), 151 deletions(-)
create mode 100644 src/gallium/tests/graw/tri-large.c
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c
b/src/gallium/drivers/llvmpipe/lp_rast.c
index af661e9..0cd62c2 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -589,6 +589,17 @@ static lp_rast_cmd_func dispatch[LP_RAST_OP_MAX] =
lp_rast_begin_query,
lp_rast_end_query,
lp_rast_set_state,
+ lp_rast_triangle_32_1,
+ lp_rast_triangle_32_2,
+ lp_rast_triangle_32_3,
+ lp_rast_triangle_32_4,
+ lp_rast_triangle_32_5,
+ lp_rast_triangle_32_6,
+ lp_rast_triangle_32_7,
+ lp_rast_triangle_32_8,
+ lp_rast_triangle_32_3_4,
+ lp_rast_triangle_32_3_16,
+ lp_rast_triangle_32_4_16
};
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.h
b/src/gallium/drivers/llvmpipe/lp_rast.h
index 43c598d..b81d94f 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.h
+++ b/src/gallium/drivers/llvmpipe/lp_rast.h
@@ -46,10 +46,11 @@ struct lp_scene;
struct lp_fence;
struct cmd_bin;
-#define FIXED_TYPE_WIDTH 32
+#define FIXED_TYPE_WIDTH 64
/** For sub-pixel positioning */
-#define FIXED_ORDER 4
+#define FIXED_ORDER 8
#define FIXED_ONE (1FIXED_ORDER)
+#define FIXED_SHIFT (FIXED_TYPE_WIDTH - 1)
/** Maximum length of an edge in a primitive in pixels.
* If the framebuffer is large we have to think about fixed-point
* integer overflow. Coordinates need ((FIXED_TYPE_WIDTH/2) - 1) bits
@@ -59,11 +60,14 @@ struct cmd_bin;
*/
#define MAX_FIXED_LENGTH (1 (((FIXED_TYPE_WIDTH/2) - 1) - FIXED_ORDER))
+#define MAX_FIXED_LENGTH32 (1 (((32/2) - 1) - FIXED_ORDER))
+
/* Rasterizer output size going to jit fs, width/height */
#define LP_RASTER_BLOCK_SIZE 4
#define LP_MAX_ACTIVE_BINNED_QUERIES 16
+#define IMUL64(a, b) (((int64_t)(a)) * ((int64_t)(b)))
struct lp_rasterizer_task;
@@ -102,18 +106,15 @@ struct lp_rast_shader_inputs {
/* followed by a0, dadx, dady and planes[] */
};
-/* Note: the order of these values is important as they are loaded by
- * sse code in rasterization:
- */
struct lp_rast_plane {
/* edge function values at minx,miny ?? */
- int c;
+ int64_t c;
- int dcdx;
- int dcdy;
+ int32_t dcdx;
+ int32_t dcdy;
/* one-pixel sized trivial reject offsets for each plane */
- int eo;
+ int64_t eo;
};
I'm still not entirely happy that even for rasterization we need 64bits.
And even more unhappy that we have to deal with pseudo-64bit values even
when we can use the 32bit versions so we get a metric crapload of scalar
loads. But then again I'm not happy about other things in
rasterization... It may be avoidable by doing some per-tile fixup (the
64bit rasterization, the need for having 64bit structs for 32bit
rasterization could be avoided by using separate plane arg for 32bit).
But we can always fix that later. I bet that if you're on a 32bit arch
it will be very slow.
/**
@@ -277,8 +278,19 @@ lp_rast_arg_null( void )
#define LP_RAST_OP_BEGIN_QUERY 0xf
#define LP_RAST_OP_END_QUERY 0x10
#define LP_RAST_OP_SET_STATE 0x11
-
-#define LP_RAST_OP_MAX 0x12
+#define LP_RAST_OP_TRIANGLE_32_1 0x12
+#define LP_RAST_OP_TRIANGLE_32_2 0x13
+#define LP_RAST_OP_TRIANGLE_32_3 0x14
+#define LP_RAST_OP_TRIANGLE_32_4 0x15
+#define LP_RAST_OP_TRIANGLE_32_5 0x16
+#define LP_RAST_OP_TRIANGLE_32_6 0x17
+#define LP_RAST_OP_TRIANGLE_32_7 0x18
+#define LP_RAST_OP_TRIANGLE_32_8 0x19
+#define LP_RAST_OP_TRIANGLE_32_3_4 0x1a
+#define LP_RAST_OP_TRIANGLE_32_3_16 0x1b
+#define LP_RAST_OP_TRIANGLE_32_4_16 0x1c
+
+#define LP_RAST_OP_MAX 0x1d
#define LP_RAST_OP_MASK 0xff
void
@@ -289,4 +301,17 @@ void
lp_debug_draw_bins_by_coverage( struct lp_scene *scene );
+#ifdef PIPE_ARCH_SSE
+#include emmintrin.h
+#include util/u_sse.h
+
+static INLINE __m128i
[Mesa-dev] [PATCH 1/2] st/mesa: simplify writemask for emitting fog result
---
src/mesa/state_tracker/st_mesa_to_tgsi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_mesa_to_tgsi.c
b/src/mesa/state_tracker/st_mesa_to_tgsi.c
index 7d79c62..1c2abc1 100644
--- a/src/mesa/state_tracker/st_mesa_to_tgsi.c
+++ b/src/mesa/state_tracker/st_mesa_to_tgsi.c
@@ -1124,7 +1124,7 @@ st_translate_mesa_program(
if (outputSemanticName[i] == TGSI_SEMANTIC_FOG) {
/* force register to contain a fog coordinate in the form (F, 0,
0, 1). */
ureg_MOV(ureg,
- ureg_writemask(t-outputs[i], TGSI_WRITEMASK_XYZW
~TGSI_WRITEMASK_X),
+ ureg_writemask(t-outputs[i], TGSI_WRITEMASK_YZW),
ureg_imm4f(ureg, 0.0f, 0.0f, 0.0f, 1.0f));
t-outputs[i] = ureg_writemask(t-outputs[i], TGSI_WRITEMASK_X);
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] mesa: fix indentation in ffvertex_prog.c
And use a better assertion.
---
src/mesa/main/ffvertex_prog.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/src/mesa/main/ffvertex_prog.c b/src/mesa/main/ffvertex_prog.c
index be6ac0f..074fbf9 100644
--- a/src/mesa/main/ffvertex_prog.c
+++ b/src/mesa/main/ffvertex_prog.c
@@ -1306,20 +1306,22 @@ static void build_fog( struct tnl_program *p )
switch (p-state-fog_distance_mode) {
case FDM_EYE_RADIAL: /* Z = sqrt(Xe*Xe + Ye*Ye + Ze*Ze) */
- input = get_eye_position(p);
- emit_op2(p, OPCODE_DP3, fog, WRITEMASK_X, input, input);
- emit_op1(p, OPCODE_RSQ, fog, WRITEMASK_X, fog);
- emit_op1(p, OPCODE_RCP, fog, WRITEMASK_X, fog);
- break;
+ input = get_eye_position(p);
+ emit_op2(p, OPCODE_DP3, fog, WRITEMASK_X, input, input);
+ emit_op1(p, OPCODE_RSQ, fog, WRITEMASK_X, fog);
+ emit_op1(p, OPCODE_RCP, fog, WRITEMASK_X, fog);
+ break;
case FDM_EYE_PLANE: /* Z = Ze */
- input = get_eye_position_z(p);
- emit_op1(p, OPCODE_MOV, fog, WRITEMASK_X, input);
- break;
+ input = get_eye_position_z(p);
+ emit_op1(p, OPCODE_MOV, fog, WRITEMASK_X, input);
+ break;
case FDM_EYE_PLANE_ABS: /* Z = abs(Ze) */
- input = get_eye_position_z(p);
- emit_op1(p, OPCODE_ABS, fog, WRITEMASK_X, input);
- break;
- default: assert(0); break; /* can't happen */
+ input = get_eye_position_z(p);
+ emit_op1(p, OPCODE_ABS, fog, WRITEMASK_X, input);
+ break;
+ default:
+ assert(!Bad fog mode in build_fog());
+ break;
}
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/5] mesa: Track number of layers in layered framebuffers.
On Wed, 2013-11-20 at 14:29 -0800, Paul Berry wrote:
In order to properly clear layered framebuffers, we need to know how
many layers they have. The easiest way to do this is to record it in
the gl_framebuffer struct when we check framebuffer completeness.
This patch replaces the gl_framebuffer::Layered boolean with a
gl_framebuffer::NumLayers integer, which is 0 if the framebuffer is
not layered, and equal to the number of layers otherwise.
v2: Remove gl_framebuffer::Layered and make gl_framebuffer::NumLayers
always have a defined value. Fix factor of 6 error in the number of
layers in a cube map array.
Cc: 10.0 mesa-sta...@lists.freedesktop.org
Reviewed-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 2 +-
src/mesa/drivers/dri/i965/gen6_clip_state.c | 2 +-
src/mesa/drivers/dri/i965/gen7_misc_state.c | 2 +-
src/mesa/main/fbobject.c | 13 +++--
src/mesa/main/mtypes.h | 8 +++-
5 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 662c975..fd6954b 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -701,7 +701,7 @@ brw_update_renderbuffer_surfaces(struct brw_context *brw)
for (i = 0; i ctx-DrawBuffer-_NumColorDrawBuffers; i++) {
if (intel_renderbuffer(ctx-DrawBuffer-_ColorDrawBuffers[i])) {
brw-vtbl.update_renderbuffer_surface(brw,
ctx-DrawBuffer-_ColorDrawBuffers[i],
- ctx-DrawBuffer-Layered,
i);
+ ctx-DrawBuffer-NumLayers
0, i);
} else {
brw-vtbl.update_null_renderbuffer_surface(brw, i);
}
diff --git a/src/mesa/drivers/dri/i965/gen6_clip_state.c
b/src/mesa/drivers/dri/i965/gen6_clip_state.c
index 03d0f90..37a39b8 100644
--- a/src/mesa/drivers/dri/i965/gen6_clip_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_clip_state.c
@@ -121,7 +121,7 @@ upload_clip_state(struct brw_context *brw)
dw2);
OUT_BATCH(U_FIXED(0.125, 3) GEN6_CLIP_MIN_POINT_WIDTH_SHIFT |
U_FIXED(255.875, 3) GEN6_CLIP_MAX_POINT_WIDTH_SHIFT |
- (fb-Layered ? 0 : GEN6_CLIP_FORCE_ZERO_RTAINDEX));
+ (fb-NumLayers 0 ? 0 : GEN6_CLIP_FORCE_ZERO_RTAINDEX));
ADVANCE_BATCH();
}
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c
b/src/mesa/drivers/dri/i965/gen7_misc_state.c
index 3f3833e..4251949 100644
--- a/src/mesa/drivers/dri/i965/gen7_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_misc_state.c
@@ -81,7 +81,7 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
break;
}
- if (fb-Layered || !irb) {
+ if (fb-NumLayers 0 || !irb) {
min_array_element = 0;
} else if (irb-mt-num_samples 1) {
/* Convert physical layer to logical layer. */
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 9dd7161..e8cf274 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -905,6 +905,7 @@ _mesa_test_framebuffer_completeness(struct gl_context
*ctx,
struct gl_renderbuffer_attachment *att;
GLenum f;
gl_format attFormat;
+ GLenum att_tex_target = GL_NONE;
/*
* XXX for ARB_fbo, only check color buffers that are named by
@@ -945,6 +946,7 @@ _mesa_test_framebuffer_completeness(struct gl_context
*ctx,
*/
if (att-Type == GL_TEXTURE) {
const struct gl_texture_image *texImg = att-Renderbuffer-TexImage;
+ att_tex_target = att-Texture-Target;
minWidth = MIN2(minWidth, texImg-Width);
maxWidth = MAX2(maxWidth, texImg-Width);
minHeight = MIN2(minHeight, texImg-Height);
@@ -1057,7 +1059,14 @@ _mesa_test_framebuffer_completeness(struct gl_context
*ctx,
}
/* Check that layered rendering is consistent. */
- att_layer_count = att-Layered ? att-Renderbuffer-Depth : 0;
+ if (att-Layered) {
+ if (att_tex_target == GL_TEXTURE_CUBE_MAP)
+att_layer_count = 6;
+ else
+att_layer_count = att-Renderbuffer-Depth;
+ } else {
+ att_layer_count = 0;
+ }
This seems like a separate change. I'll leave it up to you
whether you bother moving it out or not.
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/18] mesa: Add ARB_viewport_array plumbing
Hi Chris, Where are you getting your defines? I copied them from include/GL/gl.h #define GL_VIEWPORT 0x0BA2 /* Scissor box */ #define GL_SCISSOR_BOX 0x0C10 #define GL_SCISSOR_TEST 0x0C11 #define GL_SCISSOR_TEST 0x0C11 #define GL_DEPTH_RANGE 0x0B70 Ah, FIRST_VERTEX looks different. #define GL_FIRST_VERTEX_CONVENTION0x8E4D I'll add PROVOKING_VERTEX Looks like UNDEFINED_VERTEX was wrong as well. (include/GL/glext.h) #define GL_UNDEFINED_VERTEX 0x8260 I was modelling one of the other extension xml files and they had similar defines, though I could see no effect including or excluding them. Should I just get rid of the definitions for values that already exist in gl.h or glext.h? Courtney On Thu, Nov 21, 2013 at 1:00 PM, Chris Forbes chr...@ijw.co.nz wrote: I'm surprised the build system accepts the conflicting second definition of SCISSOR_BOX at all, actually -- that's weird. On Fri, Nov 22, 2013 at 8:55 AM, Chris Forbes chr...@ijw.co.nz wrote: I mean some of the values don't match the spec :) On Fri, Nov 22, 2013 at 7:52 AM, Courtney Goeltzenleuchter court...@lunarg.com wrote: On Wed, Nov 20, 2013 at 7:28 PM, Chris Forbes chr...@ijw.co.nz wrote: Oops -- the 8E4E is obviously correct. Artifact of me switching how I was commenting halfway through. On Thu, Nov 21, 2013 at 3:25 PM, Chris Forbes chr...@ijw.co.nz wrote: These are bogus: +enum name=SCISSOR_BOX value=0x0C10/ +enum name=VIEWPORT value=0x0BA2/ +enum name=DEPTH_RANGE value=0x0B70/ +enum name=SCISSOR_TEST value=0x0C11/ +enum name=FIRST_VERTEX_CONVENTION value=0x0C10/ What do you mean by bogus? I was emulating other extension xml files. Are these not needed because they are already defined in gl_ext.h? 0x8E4D +enum name=LAST_VERTEX_CONVENTION value=0x8E4E/ 0x8E4E add: enum name=PROVOKING_VERTEX value=0x8E4F/ +enum name=UNDEFINED_VERTEX value=0x8E4F/ 0x8260 -- Courtney Goeltzenleuchter LunarG -- Courtney Goeltzenleuchter LunarG ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/5] meta: fix meta clear of layered framebuffers
I currently work on a simpler solution for Gallium. I'm using
AMD_vertex_shader_layer and this vertex shader (I wrote it in TGSI
though):
void main()
{
gl_Position = gl_Vertex;
gl_TexCoord[0] = MultiTexCoord0; // clear color
gl_Layer = gl_InstanceID;
}
Then I render the quad with DrawArraysInstanced and set the instance
count = NumLayers. That way each instance (each quad) is sent to a
different layer and everything is cleared in one draw call.
Drivers not supporting AMD_vertex_shader_layer will have to use a GS though.
Marek
On Wed, Nov 20, 2013 at 5:47 AM, Paul Berry stereotype...@gmail.com wrote:
From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
When the Clear or ClearBuffer* commands are used to clear a
layered framebuffer attachment, all layers of the attachment are
cleared.
This patch fixes meta clears to properly clear all layers of a layered
framebuffer attachment. We accomplish this by adding a geometry
shader to the meta clear program which sets gl_Layer to a uniform
value. When clearing a layered framebuffer, we execute in a loop,
setting the uniform to point to each layer in turn.
Cc: 10.0 mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/common/meta.c | 51
+++---
1 file changed, 48 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 99b02ba..a6d5098 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -241,9 +241,11 @@ struct clear_state
GLuint VBO;
GLuint ShaderProg;
GLint ColorLocation;
+ GLint LayerLocation;
GLuint IntegerShaderProg;
GLint IntegerColorLocation;
+ GLint IntegerLayerLocation;
};
@@ -2145,6 +2147,19 @@ meta_glsl_clear_init(struct gl_context *ctx, struct
clear_state *clear)
{\n
gl_Position = position;\n
}\n;
+ const char *gs_source =
+ #version 150\n
+ layout(triangles) in;\n
+ layout(triangle_strip, max_vertices = 4) out;\n
+ uniform int layer;\n
+ void main()\n
+ {\n
+for (int i = 0; i 3; i++) {\n
+ gl_Layer = layer;\n
+ gl_Position = gl_in[i].gl_Position;\n
+ EmitVertex();\n
+}\n
+ }\n;
const char *fs_source =
#ifdef GL_ES\n
precision highp float;\n
@@ -2154,7 +2169,7 @@ meta_glsl_clear_init(struct gl_context *ctx, struct
clear_state *clear)
{\n
gl_FragColor = color;\n
}\n;
- GLuint vs, fs;
+ GLuint vs, gs = 0, fs;
bool has_integer_textures;
if (clear-ArrayObj != 0)
@@ -2176,6 +2191,12 @@ meta_glsl_clear_init(struct gl_context *ctx, struct
clear_state *clear)
_mesa_ShaderSource(vs, 1, vs_source, NULL);
_mesa_CompileShader(vs);
+ if (_mesa_has_geometry_shaders(ctx)) {
+ gs = _mesa_CreateShaderObjectARB(GL_GEOMETRY_SHADER);
+ _mesa_ShaderSource(gs, 1, gs_source, NULL);
+ _mesa_CompileShader(gs);
+ }
+
fs = _mesa_CreateShaderObjectARB(GL_FRAGMENT_SHADER);
_mesa_ShaderSource(fs, 1, fs_source, NULL);
_mesa_CompileShader(fs);
@@ -2183,6 +2204,8 @@ meta_glsl_clear_init(struct gl_context *ctx, struct
clear_state *clear)
clear-ShaderProg = _mesa_CreateProgramObjectARB();
_mesa_AttachShader(clear-ShaderProg, fs);
_mesa_DeleteObjectARB(fs);
+ if (gs != 0)
+ _mesa_AttachShader(clear-ShaderProg, gs);
_mesa_AttachShader(clear-ShaderProg, vs);
_mesa_DeleteObjectARB(vs);
_mesa_BindAttribLocation(clear-ShaderProg, 0, position);
@@ -2190,6 +2213,10 @@ meta_glsl_clear_init(struct gl_context *ctx, struct
clear_state *clear)
clear-ColorLocation = _mesa_GetUniformLocation(clear-ShaderProg,
color);
+ if (gs != 0) {
+ clear-LayerLocation = _mesa_GetUniformLocation(clear-ShaderProg,
+ layer);
+ }
has_integer_textures = _mesa_is_gles3(ctx) ||
(_mesa_is_desktop_gl(ctx) ctx-Const.GLSLVersion = 130);
@@ -2227,6 +2254,8 @@ meta_glsl_clear_init(struct gl_context *ctx, struct
clear_state *clear)
clear-IntegerShaderProg = _mesa_CreateProgramObjectARB();
_mesa_AttachShader(clear-IntegerShaderProg, fs);
_mesa_DeleteObjectARB(fs);
+ if (gs != 0)
+ _mesa_AttachShader(clear-IntegerShaderProg, gs);
_mesa_AttachShader(clear-IntegerShaderProg, vs);
_mesa_DeleteObjectARB(vs);
_mesa_BindAttribLocation(clear-IntegerShaderProg, 0, position);
@@ -2240,7 +2269,13 @@ meta_glsl_clear_init(struct gl_context *ctx, struct
clear_state *clear)
clear-IntegerColorLocation =
_mesa_GetUniformLocation(clear-IntegerShaderProg, color);
+ if (gs != 0) {
+ clear-IntegerLayerLocation =
+_mesa_GetUniformLocation(clear-IntegerShaderProg, layer);
+ }
}
+
Re: [Mesa-dev] [PATCH v2 5/5] i965: Fix fast clear of depth buffers.
I sent one suggestion on patch 1.
Series: Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
On Wed, Nov 20, 2013 at 2:29 PM, Paul Berry stereotype...@gmail.com wrote:
From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
When the Clear or ClearBuffer* commands are used to clear a
layered framebuffer attachment, all layers of the attachment are
cleared.
This patch fixes the fast depth clear path.
Fixes piglit test spec/!OpenGL 3.2/layered-rendering/clear-depth.
Cc: 10.0 mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/dri/i965/brw_clear.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clear.c
b/src/mesa/drivers/dri/i965/brw_clear.c
index a727e6e..95a6490 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -181,8 +181,16 @@ brw_fast_clear_depth(struct gl_context *ctx)
*/
intel_batchbuffer_emit_mi_flush(brw);
- intel_hiz_exec(brw, mt, depth_irb-mt_level, depth_irb-mt_layer,
- GEN6_HIZ_OP_DEPTH_CLEAR);
+ if (fb-NumLayers 0) {
+ assert(fb-NumLayers ==
depth_irb-mt-level[depth_irb-mt_level].depth);
+ for (unsigned layer = 0; layer fb-NumLayers; layer++) {
+ intel_hiz_exec(brw, mt, depth_irb-mt_level, layer,
+GEN6_HIZ_OP_DEPTH_CLEAR);
+ }
+ } else {
+ intel_hiz_exec(brw, mt, depth_irb-mt_level, depth_irb-mt_layer,
+ GEN6_HIZ_OP_DEPTH_CLEAR);
+ }
if (brw-gen == 6) {
/* From the Sandy Bridge PRM, volume 2 part 1, page 314:
--
1.8.4.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 1/2] tgsi_ureg: Refactor the ureg_* inline so that all variables are pre-declared.
The patch looks fine, but I'm not sure I understand the comment with
respect to the code change. I'd probably just call it something like
tgsi: rework calls to ureg_emit_insn()
But not a big deal.
Reviewed-by: Brian Paul bri...@vmware.com
On 11/21/2013 07:01 AM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
Mere syntactical change.
---
src/gallium/auxiliary/tgsi/tgsi_ureg.h | 200 +
1 file changed, 104 insertions(+), 96 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index e104cd9..cf0c75e 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -564,18 +564,19 @@ ureg_fixup_insn_size(struct ureg_program *ureg,
static INLINE void ureg_##op( struct ureg_program *ureg ) \
{ \
unsigned opcode = TGSI_OPCODE_##op; \
- unsigned insn = ureg_emit_insn(ureg, \
- opcode, \
- FALSE,\
- FALSE,\
- FALSE,\
- TGSI_SWIZZLE_X, \
- TGSI_SWIZZLE_Y, \
- TGSI_SWIZZLE_Z, \
- TGSI_SWIZZLE_W, \
- 0,\
- 0).insn_token;\
- ureg_fixup_insn_size( ureg, insn ); \
+ struct ureg_emit_insn_result insn; \
+ insn = ureg_emit_insn(ureg, \
+ opcode,\
+ FALSE, \
+ FALSE, \
+ FALSE, \
+ TGSI_SWIZZLE_X,\
+ TGSI_SWIZZLE_Y,\
+ TGSI_SWIZZLE_Z,\
+ TGSI_SWIZZLE_W,\
+ 0, \
+ 0);\
+ ureg_fixup_insn_size( ureg, insn.insn_token ); \
}
#define OP01( op ) \
@@ -583,19 +584,20 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
struct ureg_src src ) \
{ \
unsigned opcode = TGSI_OPCODE_##op; \
- unsigned insn = ureg_emit_insn(ureg, \
- opcode, \
- FALSE,\
- FALSE,\
- FALSE,\
- TGSI_SWIZZLE_X, \
- TGSI_SWIZZLE_Y, \
- TGSI_SWIZZLE_Z, \
- TGSI_SWIZZLE_W, \
- 0,\
- 1).insn_token;\
+ struct ureg_emit_insn_result insn; \
+ insn = ureg_emit_insn(ureg, \
+ opcode,\
+ FALSE, \
+ FALSE, \
+ FALSE, \
+ TGSI_SWIZZLE_X,\
+ TGSI_SWIZZLE_Y,\
+ TGSI_SWIZZLE_Z,\
+ TGSI_SWIZZLE_W,\
+ 0, \
+ 1);\
ureg_emit_src( ureg, src ); \
- ureg_fixup_insn_size( ureg, insn ); \
+ ureg_fixup_insn_size( ureg, insn.insn_token ); \
}
#define OP00_LBL( op ) \
@@ -647,19 +649,20 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
struct ureg_dst dst )
Re: [Mesa-dev] [PATCH v2 2/5] meta: fix meta clear of layered framebuffers
Paul Berry stereotype...@gmail.com writes: From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec: When the Clear or ClearBuffer* commands are used to clear a layered framebuffer attachment, all layers of the attachment are cleared. This patch fixes meta clears to properly clear all layers of a layered framebuffer attachment. We accomplish this by adding a geometry shader to the meta clear program which sets gl_Layer to a uniform value. When clearing a layered framebuffer, we execute in a loop, setting the uniform to point to each layer in turn. I don't think we should be running a gs in the !NumLayers case. The other patches are: Reviewed-by: Eric Anholt e...@anholt.net pgpTfZx36ywOk.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Anonymous structure in uniform question
Hello,
just recently I encountered a problem when linking shaders, containing
uniform consisting of anonymous structure.
Here is the code of shaders, triggering the problem:
//vertex shader
uniform struct {vec3 a; vec3 b;} a;
void main()
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}
//fragment shader
uniform struct {vec3 a; vec3 b;} a;
void main()
{
gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);
}
The error message pops up when linking is performed:
error: uniform `a' declared as type `#anon_struct_0002' and type `#anon_
struct_0001'
The problem is, that each anonymous structure gets its own unique type,
without checking if such type already exists. It seems to me, that such code
is somewhat in the gray area - the rest of OpenGL implementations doesn't
seem to have a problem with this code (Intel on Win, OSX, Nvidia and AMD
drivers in Win, OSX and Linux), which of course doesn't mean such a behavior
is correct.
I'd like to ask you, what is your take on this? Should anonymous structs be
checked against ones seen already and the type name reused when suitable one
is found?
Thank you,
Michal Navratil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: Add a section with recommended reading for llvmpipe development.
On 11/21/2013 11:03 AM, jfons...@vmware.com wrote: From: José Fonseca jfons...@vmware.com Several links contributed by Keith Whitwell and Roland Scheidegger. --- Nice. Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] tgsi: Prevent emission of instructions with empty writemask.
On 11/21/2013 02:01 PM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
These degenerate instructions can often be emitted by state trackers
when the semantics of instructions don't match precisely.
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 8
src/gallium/auxiliary/tgsi/tgsi_ureg.h | 22 ++
2 files changed, 30 insertions(+)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 432ed00..f06858e 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -1113,6 +1113,10 @@ ureg_insn(struct ureg_program *ureg,
boolean negate = FALSE;
unsigned swizzle[4] = { 0 };
+ if (nr_dst ureg_dst_is_empty(dst[0])) {
+ return;
+ }
This is technically not really correct, as the instruction may have
multiple destinations.
Not saying we really have any such instructions (or even that we should
have them), but this helper (and the one below) has code to deal with
multiple destinations, so that's a bit inconsistent.
Also, there are instructions which have just one dst reg but side
effects, though it may be restricted to OPCODE_POPA (and I wouldn't mind
seeing it disappear) (I think the fence/atomic instructions might be
fine and at first glance I don't see anything else).
saturate = nr_dst ? dst[0].Saturate : FALSE;
predicate = nr_dst ? dst[0].Predicate : FALSE;
if (predicate) {
@@ -1162,6 +1166,10 @@ ureg_tex_insn(struct ureg_program *ureg,
boolean negate = FALSE;
unsigned swizzle[4] = { 0 };
+ if (nr_dst ureg_dst_is_empty(dst[0])) {
+ return;
+ }
Same as above.
saturate = nr_dst ? dst[0].Saturate : FALSE;
predicate = nr_dst ? dst[0].Predicate : FALSE;
if (predicate) {
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index cf0c75e..d973edb 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -454,6 +454,16 @@ ureg_imm1i( struct ureg_program *ureg,
return ureg_DECL_immediate_int( ureg, a, 1 );
}
+/* Where the destination register has a valid file, but an empty
+ * writemask.
+ */
+static INLINE boolean
+ureg_dst_is_empty( struct ureg_dst dst )
+{
+ return dst.File != TGSI_FILE_NULL
+ dst.WriteMask == 0;
+}
+
/***
* Functions for patching up labels
*/
@@ -650,6 +660,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
{ \
unsigned opcode = TGSI_OPCODE_##op; \
struct ureg_emit_insn_result insn; \
+ if (ureg_dst_is_empty(dst)) return; \
insn = ureg_emit_insn(ureg, \
opcode,\
dst.Saturate, \
@@ -673,6 +684,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
{ \
unsigned opcode = TGSI_OPCODE_##op; \
struct ureg_emit_insn_result insn; \
+ if (ureg_dst_is_empty(dst)) return; \
insn = ureg_emit_insn(ureg, \
opcode,\
dst.Saturate, \
@@ -697,6 +709,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
{ \
unsigned opcode = TGSI_OPCODE_##op; \
struct ureg_emit_insn_result insn; \
+ if (ureg_dst_is_empty(dst)) return; \
insn = ureg_emit_insn(ureg, \
opcode,\
dst.Saturate, \
@@ -723,6 +736,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
{ \
unsigned opcode = TGSI_OPCODE_##op; \
struct ureg_emit_insn_result insn; \
+ if (ureg_dst_is_empty(dst)) return; \
insn = ureg_emit_insn(ureg, \
opcode,\
dst.Saturate, \
@@ -750,6
Re: [Mesa-dev] [PATCH 2/2] mesa: fix indentation in ffvertex_prog.c
On 11/21/2013 10:12 PM, Brian Paul wrote:
And use a better assertion.
---
src/mesa/main/ffvertex_prog.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/src/mesa/main/ffvertex_prog.c b/src/mesa/main/ffvertex_prog.c
index be6ac0f..074fbf9 100644
--- a/src/mesa/main/ffvertex_prog.c
+++ b/src/mesa/main/ffvertex_prog.c
@@ -1306,20 +1306,22 @@ static void build_fog( struct tnl_program *p )
switch (p-state-fog_distance_mode) {
case FDM_EYE_RADIAL: /* Z = sqrt(Xe*Xe + Ye*Ye + Ze*Ze) */
- input = get_eye_position(p);
- emit_op2(p, OPCODE_DP3, fog, WRITEMASK_X, input, input);
- emit_op1(p, OPCODE_RSQ, fog, WRITEMASK_X, fog);
- emit_op1(p, OPCODE_RCP, fog, WRITEMASK_X, fog);
- break;
+ input = get_eye_position(p);
+ emit_op2(p, OPCODE_DP3, fog, WRITEMASK_X, input, input);
+ emit_op1(p, OPCODE_RSQ, fog, WRITEMASK_X, fog);
+ emit_op1(p, OPCODE_RCP, fog, WRITEMASK_X, fog);
+ break;
case FDM_EYE_PLANE: /* Z = Ze */
- input = get_eye_position_z(p);
- emit_op1(p, OPCODE_MOV, fog, WRITEMASK_X, input);
- break;
+ input = get_eye_position_z(p);
+ emit_op1(p, OPCODE_MOV, fog, WRITEMASK_X, input);
+ break;
case FDM_EYE_PLANE_ABS: /* Z = abs(Ze) */
- input = get_eye_position_z(p);
- emit_op1(p, OPCODE_ABS, fog, WRITEMASK_X, input);
- break;
- default: assert(0); break; /* can't happen */
+ input = get_eye_position_z(p);
+ emit_op1(p, OPCODE_ABS, fog, WRITEMASK_X, input);
+ break;
+ default:
+ assert(!Bad fog mode in build_fog());
+ break;
}
}
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/18] mesa: Add ARB_viewport_array plumbing
I was just comparing to the list in the ARB_viewport_array spec. On Fri, Nov 22, 2013 at 11:33 AM, Courtney Goeltzenleuchter court...@lunarg.com wrote: Hi Chris, Where are you getting your defines? I copied them from include/GL/gl.h #define GL_VIEWPORT 0x0BA2 /* Scissor box */ #define GL_SCISSOR_BOX 0x0C10 #define GL_SCISSOR_TEST 0x0C11 #define GL_SCISSOR_TEST 0x0C11 #define GL_DEPTH_RANGE 0x0B70 Ah, FIRST_VERTEX looks different. #define GL_FIRST_VERTEX_CONVENTION0x8E4D I'll add PROVOKING_VERTEX Looks like UNDEFINED_VERTEX was wrong as well. (include/GL/glext.h) #define GL_UNDEFINED_VERTEX 0x8260 I was modelling one of the other extension xml files and they had similar defines, though I could see no effect including or excluding them. Should I just get rid of the definitions for values that already exist in gl.h or glext.h? Courtney On Thu, Nov 21, 2013 at 1:00 PM, Chris Forbes chr...@ijw.co.nz wrote: I'm surprised the build system accepts the conflicting second definition of SCISSOR_BOX at all, actually -- that's weird. On Fri, Nov 22, 2013 at 8:55 AM, Chris Forbes chr...@ijw.co.nz wrote: I mean some of the values don't match the spec :) On Fri, Nov 22, 2013 at 7:52 AM, Courtney Goeltzenleuchter court...@lunarg.com wrote: On Wed, Nov 20, 2013 at 7:28 PM, Chris Forbes chr...@ijw.co.nz wrote: Oops -- the 8E4E is obviously correct. Artifact of me switching how I was commenting halfway through. On Thu, Nov 21, 2013 at 3:25 PM, Chris Forbes chr...@ijw.co.nz wrote: These are bogus: +enum name=SCISSOR_BOX value=0x0C10/ +enum name=VIEWPORT value=0x0BA2/ +enum name=DEPTH_RANGE value=0x0B70/ +enum name=SCISSOR_TEST value=0x0C11/ +enum name=FIRST_VERTEX_CONVENTION value=0x0C10/ What do you mean by bogus? I was emulating other extension xml files. Are these not needed because they are already defined in gl_ext.h? 0x8E4D +enum name=LAST_VERTEX_CONVENTION value=0x8E4E/ 0x8E4E add: enum name=PROVOKING_VERTEX value=0x8E4F/ +enum name=UNDEFINED_VERTEX value=0x8E4F/ 0x8260 -- Courtney Goeltzenleuchter LunarG -- Courtney Goeltzenleuchter LunarG ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/18] mesa: Add ARB_viewport_array plumbing
I mean some of the values don't match the spec :) On Fri, Nov 22, 2013 at 7:52 AM, Courtney Goeltzenleuchter court...@lunarg.com wrote: On Wed, Nov 20, 2013 at 7:28 PM, Chris Forbes chr...@ijw.co.nz wrote: Oops -- the 8E4E is obviously correct. Artifact of me switching how I was commenting halfway through. On Thu, Nov 21, 2013 at 3:25 PM, Chris Forbes chr...@ijw.co.nz wrote: These are bogus: +enum name=SCISSOR_BOX value=0x0C10/ +enum name=VIEWPORT value=0x0BA2/ +enum name=DEPTH_RANGE value=0x0B70/ +enum name=SCISSOR_TEST value=0x0C11/ +enum name=FIRST_VERTEX_CONVENTION value=0x0C10/ What do you mean by bogus? I was emulating other extension xml files. Are these not needed because they are already defined in gl_ext.h? 0x8E4D +enum name=LAST_VERTEX_CONVENTION value=0x8E4E/ 0x8E4E add: enum name=PROVOKING_VERTEX value=0x8E4F/ +enum name=UNDEFINED_VERTEX value=0x8E4F/ 0x8260 -- Courtney Goeltzenleuchter LunarG ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/18] mesa: Add ARB_viewport_array plumbing
I'm surprised the build system accepts the conflicting second definition of SCISSOR_BOX at all, actually -- that's weird. On Fri, Nov 22, 2013 at 8:55 AM, Chris Forbes chr...@ijw.co.nz wrote: I mean some of the values don't match the spec :) On Fri, Nov 22, 2013 at 7:52 AM, Courtney Goeltzenleuchter court...@lunarg.com wrote: On Wed, Nov 20, 2013 at 7:28 PM, Chris Forbes chr...@ijw.co.nz wrote: Oops -- the 8E4E is obviously correct. Artifact of me switching how I was commenting halfway through. On Thu, Nov 21, 2013 at 3:25 PM, Chris Forbes chr...@ijw.co.nz wrote: These are bogus: +enum name=SCISSOR_BOX value=0x0C10/ +enum name=VIEWPORT value=0x0BA2/ +enum name=DEPTH_RANGE value=0x0B70/ +enum name=SCISSOR_TEST value=0x0C11/ +enum name=FIRST_VERTEX_CONVENTION value=0x0C10/ What do you mean by bogus? I was emulating other extension xml files. Are these not needed because they are already defined in gl_ext.h? 0x8E4D +enum name=LAST_VERTEX_CONVENTION value=0x8E4E/ 0x8E4E add: enum name=PROVOKING_VERTEX value=0x8E4F/ +enum name=UNDEFINED_VERTEX value=0x8E4F/ 0x8260 -- Courtney Goeltzenleuchter LunarG ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/9] gallium/dri2: Set winsys_handle type to KMS for stride query.
On Thu, 2013-11-21 at 14:12 +0100, Thomas Hellstrom wrote: On 11/21/2013 05:11 AM, christopher.halse.rog...@canonical.com wrote: From: Christopher James Halse Rogers r...@ubuntu.com Otherwise the default is TYPE_SHARED, which will flink the bo. This seems rather unnecessary for a simple stride query. Is there no way we can cache this stuff in a __DRIimage? Changing the calling conventions to adapt to poor implementations seems like the wrong way to go. What if other drivers use a slow approach to get the KMS handle? It's not really an issue of poor driver implementation - the semantics of requesting a DRM_API_HANDLE_TYPE_SHARED require that the target be flinked. Only the driver actually knows the stride, and AFAIK resource_get_handle is the only API to get that out of the driver at the moment. So we could cache it in __DRIimage, but we'd still need to call resource_get_handle at least once, so the problem remains. I'm not sure if this is on any critical paths, either, so I'm unsure whether this being slow matters. Unless asking for a KMS handle causes the driver to reallocate or something similarly awkward. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] Move the code to open the graphic device. Support for render-nodes.
On Thu, Nov 07, 2013 at 05:13:36PM +0100, Axel Davy wrote:
This patch moves the code to open the graphic device in the Wayland backend,
removes the authentication request when we are on a render-node,
and has a few fixes.
Signed-off-by: Axel Davy axel.d...@ens.fr
---
src/egl/drivers/dri2/egl_dri2.h | 1 +
src/egl/drivers/dri2/platform_wayland.c | 93
++---
2 files changed, 63 insertions(+), 31 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index c7d6484..350a626 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -133,6 +133,7 @@ struct dri2_egl_display
intauthenticated;
intformats;
uint32_t capabilities;
+ intenable_tiling;
#endif
int (*authenticate) (_EGLDisplay *disp, uint32_t id);
diff --git a/src/egl/drivers/dri2/platform_wayland.c
b/src/egl/drivers/dri2/platform_wayland.c
index c0de16b..709df36 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -622,8 +622,8 @@ dri2_terminate(_EGLDriver *drv, _EGLDisplay *disp)
_eglCleanupDisplay(disp);
dri2_dpy-core-destroyScreen(dri2_dpy-dri_screen);
- close(dri2_dpy-fd);
dlclose(dri2_dpy-driver);
+ close(dri2_dpy-fd);
Why is this necessary? If it's a fix not a typo, it should be in its
own patch.
free(dri2_dpy-driver_name);
free(dri2_dpy-device_name);
wl_drm_destroy(dri2_dpy-wl_drm);
@@ -635,34 +635,28 @@ dri2_terminate(_EGLDriver *drv, _EGLDisplay *disp)
return EGL_TRUE;
}
+static char
+is_fd_render_node(int fd)
+{
+ struct stat render;
+
+ if (fstat(fd, render))
+return 0;
+
+ if (!S_ISCHR(render.st_mode))
+return 0;
+
+ if (render.st_rdev 0x80)
+return 1;
+ return 0;
+}
mesa (and in particular this file) uses 3 space indents, please follow
the convention.
static void
drm_handle_device(void *data, struct wl_drm *drm, const char *device)
{
struct dri2_egl_display *dri2_dpy = data;
- drm_magic_t magic;
dri2_dpy-device_name = strdup(device);
- if (!dri2_dpy-device_name)
- return;
-
-#ifdef O_CLOEXEC
- dri2_dpy-fd = open(dri2_dpy-device_name, O_RDWR | O_CLOEXEC);
- if (dri2_dpy-fd == -1 errno == EINVAL)
-#endif
- {
- dri2_dpy-fd = open(dri2_dpy-device_name, O_RDWR);
- if (dri2_dpy-fd != -1)
- fcntl(dri2_dpy-fd, F_SETFD, fcntl(dri2_dpy-fd, F_GETFD) |
-FD_CLOEXEC);
- }
- if (dri2_dpy-fd == -1) {
- _eglLog(_EGL_WARNING, wayland-egl: could not open %s (%s),
- dri2_dpy-device_name, strerror(errno));
- return;
- }
-
- drmGetMagic(dri2_dpy-fd, magic);
- wl_drm_authenticate(dri2_dpy-wl_drm, magic);
}
static void
@@ -738,7 +732,8 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay
*disp)
struct dri2_egl_display *dri2_dpy;
const __DRIconfig *config;
uint32_t types;
- int i;
+ int i, is_render_node;
+ drm_magic_t magic;
static const unsigned int argb_masks[4] =
{ 0xff, 0xff00, 0xff, 0xff00 };
static const unsigned int rgb_masks[4] = { 0xff, 0xff00, 0xff, 0 };
@@ -778,9 +773,39 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay
*disp)
if (roundtrip(dri2_dpy) 0 || dri2_dpy-wl_drm == NULL)
goto cleanup_dpy;
- if (roundtrip(dri2_dpy) 0 || dri2_dpy-fd == -1)
+ if (roundtrip(dri2_dpy) 0 || dri2_dpy-device_name == NULL)
goto cleanup_drm;
+#ifdef O_CLOEXEC
+ dri2_dpy-fd = open(dri2_dpy-device_name, O_RDWR | O_CLOEXEC);
+ if (dri2_dpy-fd == -1 errno == EINVAL)
+#endif
+ {
+ dri2_dpy-fd = open(dri2_dpy-device_name, O_RDWR);
+ if (dri2_dpy-fd != -1)
+ fcntl(dri2_dpy-fd, F_SETFD, fcntl(dri2_dpy-fd, F_GETFD) |
+FD_CLOEXEC);
+ }
Let's start out with a patch to split this O_CLOEXEC helper out into
its own function, open_cloexec() or something. Having this compat
logic here makes the interesting code harder to follow and your 3/3
patch duplicates it.
+ if (dri2_dpy-fd == -1) {
+ _eglLog(_EGL_WARNING, wayland-egl: could not open %s (%s),
+ dri2_dpy-device_name, strerror(errno));
+ goto cleanup_drm;
+ }
+
+ if (is_fd_render_node(dri2_dpy-fd))
I would like the compositor to still send the classic drm device in
the wl_drm.device event. The client can then use stat(2) to stat it
and defer the corresponding render node from that by adding 128 to the
minor. This way we don't break older mesa versions by sending them a
render node that they'll then fail to authenticate.
+ {
The open brace '{' goes on the same line as the if statement, like
everywhere else in this file.
+ _eglLog(_EGL_DEBUG, wayland-egl: card is render-node);
+ dri2_dpy-authenticated = 1;
+
Re: [Mesa-dev] [PATCH 2/3] Create untiled buffers in get_back_bo when needed.
On Thu, Nov 07, 2013 at 05:13:37PM +0100, Axel Davy wrote:
We must send to the compositor buffer it is able to read.
Since tiling modes are different on graphic cards, we have
to disable tiling when creating the buffers if we render
with a different graphic card than the compositor.
Signed-off-by: Axel Davy axel.d...@ens.fr
This looks fine.
Kristian
---
src/egl/drivers/dri2/platform_wayland.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/egl/drivers/dri2/platform_wayland.c
b/src/egl/drivers/dri2/platform_wayland.c
index 709df36..b922ff5 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -283,12 +283,17 @@ get_back_bo(struct dri2_egl_surface *dri2_surf,
__DRIbuffer *buffer)
if (dri2_surf-back == NULL)
return -1;
if (dri2_surf-back-dri_image == NULL) {
- dri2_surf-back-dri_image =
- dri2_dpy-image-createImage(dri2_dpy-dri_screen,
- dri2_surf-base.Width,
- dri2_surf-base.Height,
- __DRI_IMAGE_FORMAT_ARGB,
- __DRI_IMAGE_USE_SHARE,
+ unsigned int use_flags = __DRI_IMAGE_USE_SHARE;
+
+ if (!dri2_dpy-enable_tiling)
+ use_flags |= __DRI_IMAGE_USE_LINEAR;
+
+ dri2_surf-back-dri_image =
+ dri2_dpy-image-createImage(dri2_dpy-dri_screen,
+ dri2_surf-base.Width,
+ dri2_surf-base.Height,
+ __DRI_IMAGE_FORMAT_ARGB,
+ use_flags,
NULL);
dri2_surf-back-age = 0;
}
--
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 0/3] Implement DRI_PRIME support for Wayland
On Thu, Nov 07, 2013 at 05:13:35PM +0100, Axel Davy wrote: These patches enable using DRI_PRIME to use a different card than the compositor card (with render-nodes). At the time of writing, Mesa Wayland egl backend doesn't support render-nodes, because it uses the dri2 backend, which require using GEM names (render-nodes aren't allowed to use GEM names). But I'm confident this week or next week, the __DRIimage remplacement will be ready, thanks to Keith Packard, Kristian Hosberg and Christopher James Halse Rogers. That's why I'm publishing these patches now, so they have the time to be reviewed. Initially, I wanted to use driconf too, as a complement of DRI_PRIME, but driconf doesn't support string parameters yet, so it'll come later. To choose a specific device, the user has to specify the id_path_tag of the device he wants to use. We get the id_path_tag with udev. Systemd didn't fill this field for render-nodes, so it has to be set as an additional rule. David Herrmann has sent a patch for that for Systemd, but I don't know if it is already pushed. The choice to use id_path_tag comes to the fact that the id_path is stable, and that it describes non-pci graphic devices too (usb devices, etc). An alternative to choose the device to use is to set DRI_PRIME to 1, which means choose any other card than the one used by the compositor. If Mesa doesn't find the device asked by the user, it will use the same card than the Wayland compositor. The Wayland Prime support implemented with these patches is different from X Prime support. A client using an other card than the compositor will allocate buffers with no-tiling to render to, and share them with the compositor, unlike on X, where it would render to a tiled buffer, not shared with the other card, and a copy mechanism will make the main card receive an untiled buffer. That means that these (Wayland) clients will perform slowly, compared to if they weren't using Prime. In fact it is not how the user is supposed to run a game, for example, on its dedicated card. Using a shared, untiled-buffer, but avoiding any copy, is better for application which wouldn't do much rendering. An example of such an application is an embedded Wayland compositor. To use an heavy application, the user is supposed to launch an embedded Wayland compositor on the dedicated card, and run the game inside. The compositor will render into the shared, untiled buffer, and will copy the content of the game buffers. Note that the game know it is using the same cards than its compositor, that's why it enables tiling. I'm planning to write a Weston shell, designed to run embedded fullscreen games, that would make Weston resize to the game size, and close when it closes. I'm not sold on the nested compositor for this use case. It introduces another context switch between the game and the main compositor and more input and output lag. Instead I think we need to consider whether we want a new __DRIimage entry point like: (*blitImage)(__DRIcontext *ctx, __DRIimage *src, __DRIimage *ctx) and then do the copy in platform_wayland.c when we have non-matching tile-formats. Kristian Pros: .If you launch a fullscreen Wayland compositor on the dedicated card, inside a compositor supporting composite bypass, you'll render the whole desktop on the dedicated card. The integrated card would only display the buffer generated, without doing any copy. .More flexibility Cons: .The user has to use a script to launch a game on the dedicated card. Pros over X dri2 Prime support: .Vsync works, whatever the cards used by the client .You can understand easily how prime support works As a last note, this Prime support suffers too from the lack of dma-buf fences (glitches when the client is still writing on the buffer when the compositor's card reads it). Using an embedded compositor suppress all the glitches when it doesn't take (1/refresh_rate) seconds for it to render a frame, that is when you don't have an input lag. Axel Davy (3): Move the code to open the graphic device. Support for render-nodes. Create untiled buffers in get_back_bo when needed. Implement choosing the device to use with DRI_PRIME src/egl/drivers/dri2/egl_dri2.h | 1 + src/egl/drivers/dri2/platform_wayland.c | 262 +++- 2 files changed, 226 insertions(+), 37 deletions(-) -- 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
[Mesa-dev] [PATCH] docs: Add a section with recommended reading for llvmpipe development.
From: José Fonseca jfons...@vmware.com Several links contributed by Keith Whitwell and Roland Scheidegger. --- docs/llvmpipe.html | 58 -- 1 file changed, 56 insertions(+), 2 deletions(-) diff --git a/docs/llvmpipe.html b/docs/llvmpipe.html index 80f8a01..d695907 100644 --- a/docs/llvmpipe.html +++ b/docs/llvmpipe.html @@ -203,11 +203,65 @@ for posterior analysis, e.g.: We use LLVM-C bindings for now. They are not documented, but follow the C++ interfaces very closely, and appear to be complete enough for code generation. See - http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html - for a stand-alone example. See the llvm-c/Core.h file for reference. + a href=http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html; + this stand-alone example/a. See the llvm-c/Core.h file for reference. /li /ul +h1 id=recommended_readingRecommended Reading/h1 + +ul + li +pRasterization/p +ul + lia href=http://www.cs.unc.edu/~olano/papers/2dh-tri/;Triangle Scan Conversion using 2D Homogeneous Coordinates/a/li + lia href=http://www.drdobbs.com/parallel/rasterization-on-larrabee/217200602;Rasterization on Larrabee/a (a href=http://devmaster.net/posts/2887/rasterization-on-larrabee;DevMaster copy/a)/li + lia href=http://devmaster.net/posts/6133/rasterization-using-half-space-functions;Rasterization using half-space functions/a/li + lia href=http://devmaster.net/posts/6145/advanced-rasterization;Advanced Rasterization/a/li + lia href=http://fgiesen.wordpress.com/2013/02/17/optimizing-sw-occlusion-culling-index/;Optimizing Software Occlusion Culling/a/li +/ul + /li + li +pTexture sampling/p +ul + lia href=http://chrishecker.com/Miscellaneous_Technical_Articles#Perspective_Texture_Mapping;Perspective Texture Mapping/a/li + lia href=http://www.flipcode.com/archives/Texturing_As_In_Unreal.shtml;Texturing As In Unreal/a/li + lia href=http://www.gamasutra.com/view/feature/3301/runtime_mipmap_filtering.php;Run-Time MIP-Map Filtering/a/li + lia href=http://alt.3dcenter.org/artikel/2003/10-26_a_english.php;Will brilinear filtering persist?/a/li + lia href=http://ixbtlabs.com/articles2/gffx/nv40-rx800-3.html;Trilinear filtering/a/li + lia href=http://devmaster.net/posts/12785/texture-swizzling;Texture Swizzling/a/li +/ul + /li + li +pSIMD/p +ul + lia href=http://www.cdl.uni-saarland.de/projects/wfv/#header4;Whole-Function Vectorization/a/li +/ul + /li + li +pOptimization/p +ul + lia href=http://www.drdobbs.com/optimizing-pixomatic-for-modern-x86-proc/184405807;Optimizing Pixomatic For Modern x86 Processors/a/li + lia href=http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html;Intel 64 and IA-32 Architectures Optimization Reference Manual/a/li + lia href=http://www.agner.org/optimize/;Software optimization resources/a/li + lia href=http://software.intel.com/en-us/articles/intel-intrinsics-guide;Intel Intrinsics Guide/ali +/ul + /li + li +pLLVM/p +ul + lia href=http://llvm.org/docs/LangRef.html;LLVM Language Reference Manual/a/li + lia href=http://npcontemplation.blogspot.co.uk/2008/06/secret-of-llvm-c-bindings.html;The secret of LLVM C bindings/a/li +/ul + /li + li +pMisc/p +ul + lia href=http://msdn.microsoft.com/en-us/library/gg615082.aspx#architecture;WARP Architecture and Performance/a/li +/ul + /li +/ul + /div /body /html -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] tgsi: Prevent emission of instructions with empty writemask.
On 11/21/2013 07:01 AM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
These degenerate instructions can often be emitted by state trackers
when the semantics of instructions don't match precisely.
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 8
src/gallium/auxiliary/tgsi/tgsi_ureg.h | 22 ++
2 files changed, 30 insertions(+)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 432ed00..f06858e 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -1113,6 +1113,10 @@ ureg_insn(struct ureg_program *ureg,
boolean negate = FALSE;
unsigned swizzle[4] = { 0 };
+ if (nr_dst ureg_dst_is_empty(dst[0])) {
+ return;
+ }
+
saturate = nr_dst ? dst[0].Saturate : FALSE;
predicate = nr_dst ? dst[0].Predicate : FALSE;
if (predicate) {
@@ -1162,6 +1166,10 @@ ureg_tex_insn(struct ureg_program *ureg,
boolean negate = FALSE;
unsigned swizzle[4] = { 0 };
+ if (nr_dst ureg_dst_is_empty(dst[0])) {
+ return;
+ }
+
saturate = nr_dst ? dst[0].Saturate : FALSE;
predicate = nr_dst ? dst[0].Predicate : FALSE;
if (predicate) {
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index cf0c75e..d973edb 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -454,6 +454,16 @@ ureg_imm1i( struct ureg_program *ureg,
return ureg_DECL_immediate_int( ureg, a, 1 );
}
+/* Where the destination register has a valid file, but an empty
+ * writemask.
+ */
+static INLINE boolean
+ureg_dst_is_empty( struct ureg_dst dst )
+{
+ return dst.File != TGSI_FILE_NULL
+ dst.WriteMask == 0;
+}
+
/***
* Functions for patching up labels
*/
@@ -650,6 +660,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
{ \
unsigned opcode = TGSI_OPCODE_##op; \
struct ureg_emit_insn_result insn; \
+ if (ureg_dst_is_empty(dst)) return; \
If it were me, I'd put the return stmt on the next line in case someone
wanted to put a breakpoint on that event.
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] tgsi_ureg: Refactor the ureg_* inline so that all variables are pre-declared.
From: José Fonseca jfons...@vmware.com
Mere syntactical change.
---
src/gallium/auxiliary/tgsi/tgsi_ureg.h | 200 +
1 file changed, 104 insertions(+), 96 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index e104cd9..cf0c75e 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -564,18 +564,19 @@ ureg_fixup_insn_size(struct ureg_program *ureg,
static INLINE void ureg_##op( struct ureg_program *ureg ) \
{ \
unsigned opcode = TGSI_OPCODE_##op; \
- unsigned insn = ureg_emit_insn(ureg, \
- opcode, \
- FALSE,\
- FALSE,\
- FALSE,\
- TGSI_SWIZZLE_X, \
- TGSI_SWIZZLE_Y, \
- TGSI_SWIZZLE_Z, \
- TGSI_SWIZZLE_W, \
- 0,\
- 0).insn_token;\
- ureg_fixup_insn_size( ureg, insn ); \
+ struct ureg_emit_insn_result insn; \
+ insn = ureg_emit_insn(ureg, \
+ opcode,\
+ FALSE, \
+ FALSE, \
+ FALSE, \
+ TGSI_SWIZZLE_X,\
+ TGSI_SWIZZLE_Y,\
+ TGSI_SWIZZLE_Z,\
+ TGSI_SWIZZLE_W,\
+ 0, \
+ 0);\
+ ureg_fixup_insn_size( ureg, insn.insn_token ); \
}
#define OP01( op ) \
@@ -583,19 +584,20 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
struct ureg_src src ) \
{ \
unsigned opcode = TGSI_OPCODE_##op; \
- unsigned insn = ureg_emit_insn(ureg, \
- opcode, \
- FALSE,\
- FALSE,\
- FALSE,\
- TGSI_SWIZZLE_X, \
- TGSI_SWIZZLE_Y, \
- TGSI_SWIZZLE_Z, \
- TGSI_SWIZZLE_W, \
- 0,\
- 1).insn_token;\
+ struct ureg_emit_insn_result insn; \
+ insn = ureg_emit_insn(ureg, \
+ opcode,\
+ FALSE, \
+ FALSE, \
+ FALSE, \
+ TGSI_SWIZZLE_X,\
+ TGSI_SWIZZLE_Y,\
+ TGSI_SWIZZLE_Z,\
+ TGSI_SWIZZLE_W,\
+ 0, \
+ 1);\
ureg_emit_src( ureg, src ); \
- ureg_fixup_insn_size( ureg, insn ); \
+ ureg_fixup_insn_size( ureg, insn.insn_token ); \
}
#define OP00_LBL( op ) \
@@ -647,19 +649,20 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
struct ureg_dst dst ) \
{ \
unsigned opcode = TGSI_OPCODE_##op; \
- unsigned insn = ureg_emit_insn(ureg, \
- opcode,
Re: [Mesa-dev] [PATCH 3/9] gallium/dri2: Set winsys_handle type to KMS for stride query.
On 11/21/2013 05:11 AM, christopher.halse.rog...@canonical.com wrote:
From: Christopher James Halse Rogers r...@ubuntu.com
Otherwise the default is TYPE_SHARED, which will flink the bo. This seems
rather unnecessary for a simple stride query.
Is there no way we can cache this stuff in a __DRIimage? Changing the
calling conventions to adapt to poor implementations seems like
the wrong way to go. What if other drivers use a slow approach to get
the KMS handle?
/Thomas
---
src/gallium/state_trackers/dri/drm/dri2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
b/src/gallium/state_trackers/dri/drm/dri2.c
index 42c863b..db034bd 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -691,6 +691,7 @@ dri2_query_image(__DRIimage *image, int attrib, int *value)
switch (attrib) {
case __DRI_IMAGE_ATTRIB_STRIDE:
+ whandle.type = DRM_API_HANDLE_TYPE_KMS;
image-texture-screen-resource_get_handle(image-texture-screen,
image-texture, whandle);
*value = whandle.stride;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [v3 0/8] Add ARB_texture_view
On 11/19/2013 04:16 PM, Courtney Goeltzenleuchter wrote: The following patches add the necessary functions to Mesa to support ARB_texture_view. These patches do not include the actual driver elements, just the device independent portion. This extension requires ARB_texture_storage. The extension supports one new API call, glTextureView and a handful of enums that have been added as queriable texture parameters. Adds one new driver entry point for the driver to map the view specified onto the origtexture given. Includes review feedback and a bug fix in compatible_format. Passes non-rendering ARB_texture_view piglit tests. Courtney Goeltzenleuchter (8): mesa: Add API definitions for ARB_texture_view mesa: Tracking for ARB_texture_view extension mesa: update texture object for ARB_texture_view mesa: ARB_texture_view get parameters mesa: Add driver entry point for ARB_texture_view mesa: Fill out ARB_texture_view entry points mesa: add texture_view helper function for TexStorage mesa: Update TexStorage to support ARB_texture_view src/mapi/glapi/gen/ARB_texture_view.xml | 23 ++ src/mapi/glapi/gen/Makefile.am | 1 + src/mapi/glapi/gen/gl_API.xml | 4 +- src/mapi/glapi/gen/gl_genexec.py| 1 + src/mesa/Makefile.sources | 1 + src/mesa/SConscript | 1 + src/mesa/drivers/common/driverfuncs.c | 3 + src/mesa/main/dd.h | 5 + src/mesa/main/extensions.c | 1 + src/mesa/main/mtypes.h | 6 + src/mesa/main/tests/dispatch_sanity.cpp | 2 +- src/mesa/main/teximage.c| 6 + src/mesa/main/texparam.c| 60 ++- src/mesa/main/texstorage.c | 5 +- src/mesa/main/textureview.c | 684 src/mesa/main/textureview.h | 43 ++ 16 files changed, 838 insertions(+), 8 deletions(-) create mode 100644 src/mapi/glapi/gen/ARB_texture_view.xml create mode 100644 src/mesa/main/textureview.c create mode 100644 src/mesa/main/textureview.h For patches 1-4, 8: Reviewed-by: Brian Paul bri...@vmware.com For patches 5-7: minor comments Nice work. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [v3 5/8] mesa: Add driver entry point for ARB_texture_view
On 11/19/2013 04:16 PM, Courtney Goeltzenleuchter wrote:
Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
src/mesa/drivers/common/driverfuncs.c | 3 +++
src/mesa/main/dd.h| 5 +
2 files changed, 8 insertions(+)
diff --git a/src/mesa/drivers/common/driverfuncs.c
b/src/mesa/drivers/common/driverfuncs.c
index 5faa98a..f185688 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/driverfuncs.c
@@ -211,6 +211,9 @@ _mesa_init_driver_functions(struct dd_function_table
*driver)
/* GL_ARB_texture_storage */
driver-AllocTextureStorage = _mesa_alloc_texture_storage;
+ /* GL_ARB_texture_view */
+ driver-TextureView = NULL;
+
/* GL_ARB_texture_multisample */
driver-GetSamplePosition = NULL;
}
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index b5b874f..3e263f4 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -375,6 +375,11 @@ struct dd_function_table {
GLsizei levels, GLsizei width,
GLsizei height, GLsizei depth);
+ /** Called as part of glTextureView to add views to origTexObj */
+ GLboolean (*TextureView)(struct gl_context *ctx,
+struct gl_texture_object *texObj,
+struct gl_texture_object *origTexObj);
Either the comment on this function, or the place where it's called from
should probably be beefed up with more info about what's expected of the
driver. Is it possible to return FALSE for any reason beyond out-of-memory?
+
/**
* Map a renderbuffer into user space.
* \param mode bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT and
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [v3 7/8] mesa: add texture_view helper function for TexStorage
On 11/19/2013 04:16 PM, Courtney Goeltzenleuchter wrote:
Add helper function to set texture_view state from TexStorage calls.
Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
src/mesa/main/textureview.c | 59 +
src/mesa/main/textureview.h | 4 +++
2 files changed, 63 insertions(+)
diff --git a/src/mesa/main/textureview.c b/src/mesa/main/textureview.c
index 1858465..a25b928 100644
--- a/src/mesa/main/textureview.c
+++ b/src/mesa/main/textureview.c
@@ -379,6 +379,65 @@ compatible_format(struct gl_context *ctx, struct
gl_texture_object *origTexObj,
_mesa_lookup_enum_by_nr(origInternalFormat));
return GL_FALSE;
}
+/**
+ * Helper function for TexStorage to set TextureView state
+ */
Could you put a bit more info into that comment?
+void
+set_texture_view_state(struct gl_context *ctx, struct gl_texture_object
*texObj,
+ GLenum target, GLuint levels)
non-static functions should be prefixed with _mesa_.
+{
+ struct gl_texture_image *texImage;
+
+ /* Get a reference to what will become this View's base level */
+ texImage = _mesa_select_tex_image(ctx, texObj, target, 0);
Early return if texImage is NULL (out of memory, etc?)?
+
+ /* If the command is successful,
If what command is successful? glTexStorage()?
+* TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
+* TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS become levels.
+* If the texture target is TEXTURE_1D_ARRAY then
+* TEXTURE_VIEW_NUM_LAYERS becomes height.
+* If the texture target is TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY,
+* or TEXTURE_2D_MULTISAMPLE_ARRAY then TEXTURE_VIEW_NUM_LAYERS becomes
depth.
+* If the texture target is TEXTURE_CUBE_MAP, then
+* TEXTURE_VIEW_NUM_LAYERS becomes 6.
+* For any other texture target, TEXTURE_VIEW_NUM_LAYERS becomes 1.
+*
+* ARB_texture_multisample: Multisample textures do
+* not have multiple image levels.
+*/
+
+ texObj-Immutable = GL_TRUE;
+ texObj-ImmutableLevels = levels;
+ texObj-MinLevel = 0;
+ texObj-NumLevels = levels;
+ texObj-MinLayer = 0;
+ texObj-NumLayers = 1;
+ switch (target) {
+ case GL_TEXTURE_1D_ARRAY:
+ texObj-NumLayers = texImage-Height;
+ break;
+
+ case GL_TEXTURE_2D_MULTISAMPLE:
+ texObj-NumLevels = 1;
+ texObj-ImmutableLevels = 1;
+ break;
+
+ case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
+ texObj-NumLevels = 1;
+ texObj-ImmutableLevels = 1;
+ /* fall through to set NumLayers */
+
+ case GL_TEXTURE_2D_ARRAY:
+ case GL_TEXTURE_CUBE_MAP_ARRAY:
+ texObj-NumLayers = texImage-Depth;
+ break;
+
+ case GL_TEXTURE_CUBE_MAP:
+ texObj-NumLayers = 6;
+ break;
+
+ }
+}
/**
* glTextureView (ARB_texture_view)
diff --git a/src/mesa/main/textureview.h b/src/mesa/main/textureview.h
index c2f0f32..36a8ed3 100644
--- a/src/mesa/main/textureview.h
+++ b/src/mesa/main/textureview.h
@@ -36,4 +36,8 @@ _mesa_TextureView(GLuint texture, GLenum target, GLuint
origtexture,
GLuint minlevel, GLuint numlevels,
GLuint minlayer, GLuint numlayers);
+extern void
+set_texture_view_state(struct gl_context *ctx, struct gl_texture_object
*texObj,
+ GLenum target, GLuint levels);
+
#endif /* TEXTUREVIEW_H */
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] tgsi: Prevent emission of instructions with empty writemask.
From: José Fonseca jfons...@vmware.com
These degenerate instructions can often be emitted by state trackers
when the semantics of instructions don't match precisely.
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 8
src/gallium/auxiliary/tgsi/tgsi_ureg.h | 22 ++
2 files changed, 30 insertions(+)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 432ed00..f06858e 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -1113,6 +1113,10 @@ ureg_insn(struct ureg_program *ureg,
boolean negate = FALSE;
unsigned swizzle[4] = { 0 };
+ if (nr_dst ureg_dst_is_empty(dst[0])) {
+ return;
+ }
+
saturate = nr_dst ? dst[0].Saturate : FALSE;
predicate = nr_dst ? dst[0].Predicate : FALSE;
if (predicate) {
@@ -1162,6 +1166,10 @@ ureg_tex_insn(struct ureg_program *ureg,
boolean negate = FALSE;
unsigned swizzle[4] = { 0 };
+ if (nr_dst ureg_dst_is_empty(dst[0])) {
+ return;
+ }
+
saturate = nr_dst ? dst[0].Saturate : FALSE;
predicate = nr_dst ? dst[0].Predicate : FALSE;
if (predicate) {
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index cf0c75e..d973edb 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -454,6 +454,16 @@ ureg_imm1i( struct ureg_program *ureg,
return ureg_DECL_immediate_int( ureg, a, 1 );
}
+/* Where the destination register has a valid file, but an empty
+ * writemask.
+ */
+static INLINE boolean
+ureg_dst_is_empty( struct ureg_dst dst )
+{
+ return dst.File != TGSI_FILE_NULL
+ dst.WriteMask == 0;
+}
+
/***
* Functions for patching up labels
*/
@@ -650,6 +660,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
{ \
unsigned opcode = TGSI_OPCODE_##op; \
struct ureg_emit_insn_result insn; \
+ if (ureg_dst_is_empty(dst)) return; \
insn = ureg_emit_insn(ureg, \
opcode,\
dst.Saturate, \
@@ -673,6 +684,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
{ \
unsigned opcode = TGSI_OPCODE_##op; \
struct ureg_emit_insn_result insn; \
+ if (ureg_dst_is_empty(dst)) return; \
insn = ureg_emit_insn(ureg, \
opcode,\
dst.Saturate, \
@@ -697,6 +709,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
{ \
unsigned opcode = TGSI_OPCODE_##op; \
struct ureg_emit_insn_result insn; \
+ if (ureg_dst_is_empty(dst)) return; \
insn = ureg_emit_insn(ureg, \
opcode,\
dst.Saturate, \
@@ -723,6 +736,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
{ \
unsigned opcode = TGSI_OPCODE_##op; \
struct ureg_emit_insn_result insn; \
+ if (ureg_dst_is_empty(dst)) return; \
insn = ureg_emit_insn(ureg, \
opcode,\
dst.Saturate, \
@@ -750,6 +764,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
unsigned opcode = TGSI_OPCODE_##op; \
unsigned target = TGSI_TEXTURE_UNKNOWN; \
struct ureg_emit_insn_result insn; \
+ if (ureg_dst_is_empty(dst)) return; \
insn = ureg_emit_insn(ureg, \
opcode,\
dst.Saturate, \
@@ -777,6 +792,7 @@ static INLINE void ureg_##op(
Re: [Mesa-dev] [PATCH 15/18] mesa: Add ARB_viewport_array plumbing
On Wed, Nov 20, 2013 at 7:28 PM, Chris Forbes chr...@ijw.co.nz wrote: Oops -- the 8E4E is obviously correct. Artifact of me switching how I was commenting halfway through. On Thu, Nov 21, 2013 at 3:25 PM, Chris Forbes chr...@ijw.co.nz wrote: These are bogus: +enum name=SCISSOR_BOX value=0x0C10/ +enum name=VIEWPORT value=0x0BA2/ +enum name=DEPTH_RANGE value=0x0B70/ +enum name=SCISSOR_TEST value=0x0C11/ +enum name=FIRST_VERTEX_CONVENTION value=0x0C10/ What do you mean by bogus? I was emulating other extension xml files. Are these not needed because they are already defined in gl_ext.h? 0x8E4D +enum name=LAST_VERTEX_CONVENTION value=0x8E4E/ 0x8E4E add: enum name=PROVOKING_VERTEX value=0x8E4F/ +enum name=UNDEFINED_VERTEX value=0x8E4F/ 0x8260 -- Courtney Goeltzenleuchter LunarG ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/5] meta: fix meta clear of layered framebuffers
On 21 November 2013 05:21, Marek Olšák mar...@gmail.com wrote:
I currently work on a simpler solution for Gallium. I'm using
AMD_vertex_shader_layer and this vertex shader (I wrote it in TGSI
though):
void main()
{
gl_Position = gl_Vertex;
gl_TexCoord[0] = MultiTexCoord0; // clear color
gl_Layer = gl_InstanceID;
}
Then I render the quad with DrawArraysInstanced and set the instance
count = NumLayers. That way each instance (each quad) is sent to a
different layer and everything is cleared in one draw call.
Drivers not supporting AMD_vertex_shader_layer will have to use a GS
though.
Your approach potentially has better performance, but I'm concerned about
risk, because I'm hoping to get this patch cherry-picked into 10.0 (which
is due to be released in a week). Currently GLSL clear uses 4 different
shaders:
1. A vertex shader that just sets gl_Position (compilable for either
desktop GLSL 1.10 or GLSL ES 1.00)
2. A vertex shader that just sets gl_Position (compilable for either
desktop GLSL 1.30 or GLSL ES 3.00)
3. A fragment shader that outputs floating point color (compilable for
either desktop GLSL or GLSL ES)
4. A fragment shader that outputs integer color (compilable for either
desktop GLSL 1.30 or GLSL ES 3.00)
My proposal adds a fifth:
5. A geometry shader that sets gl_Position and gl_Layer
If we want to use gl_InstanceID and AMD_vertex_shader_layer, we would have
to add two more:
6. A vertex shader that sets gl_Position and gl_Layer (for drivers that
support AMD_vertex_shader_layer)
7. A vertex shader that sets gl_Position and passes through gl_InstanceID
to the GS (for drivers that support GS but not AMD_vertex_shader_layer)
Testing on the Meta clear path is already pretty thin (at least for i965)
because most i965 clears can be done by faster mechanisms (fast color
clear, fast depth clear, or the blorp color clear). I'm worried about
introducing 3 new shaders to a poorly-tested Meta path this late in the
release process.
Anyone want to weigh in on this subject from a risk perspective?
I'm also wondering how important performance really is in this patch. I
suspect it's not a big issue for i965, since i965 usually does clears using
faster mechanisms. It's not an issue for i915, since i915 doesn't support
geometry shaders. Are there other drivers that use Meta other than those
two? If not, I'm tempted to leave this patch as is, based on the reasoning
that since Meta is a fallback mechanism, correctness is more important than
performance.
Marek
On Wed, Nov 20, 2013 at 5:47 AM, Paul Berry stereotype...@gmail.com
wrote:
From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
When the Clear or ClearBuffer* commands are used to clear a
layered framebuffer attachment, all layers of the attachment are
cleared.
This patch fixes meta clears to properly clear all layers of a layered
framebuffer attachment. We accomplish this by adding a geometry
shader to the meta clear program which sets gl_Layer to a uniform
value. When clearing a layered framebuffer, we execute in a loop,
setting the uniform to point to each layer in turn.
Cc: 10.0 mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/common/meta.c | 51
+++---
1 file changed, 48 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c
b/src/mesa/drivers/common/meta.c
index 99b02ba..a6d5098 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -241,9 +241,11 @@ struct clear_state
GLuint VBO;
GLuint ShaderProg;
GLint ColorLocation;
+ GLint LayerLocation;
GLuint IntegerShaderProg;
GLint IntegerColorLocation;
+ GLint IntegerLayerLocation;
};
@@ -2145,6 +2147,19 @@ meta_glsl_clear_init(struct gl_context *ctx,
struct clear_state *clear)
{\n
gl_Position = position;\n
}\n;
+ const char *gs_source =
+ #version 150\n
+ layout(triangles) in;\n
+ layout(triangle_strip, max_vertices = 4) out;\n
+ uniform int layer;\n
+ void main()\n
+ {\n
+for (int i = 0; i 3; i++) {\n
+ gl_Layer = layer;\n
+ gl_Position = gl_in[i].gl_Position;\n
+ EmitVertex();\n
+}\n
+ }\n;
const char *fs_source =
#ifdef GL_ES\n
precision highp float;\n
@@ -2154,7 +2169,7 @@ meta_glsl_clear_init(struct gl_context *ctx,
struct clear_state *clear)
{\n
gl_FragColor = color;\n
}\n;
- GLuint vs, fs;
+ GLuint vs, gs = 0, fs;
bool has_integer_textures;
if (clear-ArrayObj != 0)
@@ -2176,6 +2191,12 @@ meta_glsl_clear_init(struct gl_context *ctx,
struct clear_state *clear)
_mesa_ShaderSource(vs, 1, vs_source, NULL);
_mesa_CompileShader(vs);
+ if (_mesa_has_geometry_shaders(ctx)) {
+ gs =
Re: [Mesa-dev] [PATCH 0/9] DRI Image 7 support for gallium
On 11/21/2013 05:11 AM, christopher.halse.rog...@canonical.com wrote: Now includes support for Image 6 as a bonus feature, and 7 is only exposed on the gallium drivers which support dma-buf import/export. Still useful for Wayland-Prime and Mir, now also useful for DRI3000 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev For the series (but some driver guys should check the driver prime implementations, particularly gem handle closing), and perhaps if there's a better fix for patch 3 Reviewed-by: Thomas Hellstrom thellst...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71591] Second Life shaders fail to compile
https://bugs.freedesktop.org/show_bug.cgi?id=71591 --- Comment #6 from Eero Tamminen eero.t.tammi...@intel.com --- Giving an error when the extension changes behavior of existing functionality can be useful for developers, as such things may cause grief for them. For anything else, it's the error itself that causes grief. Options for fixing this issue are: - changing all errors about this to warnings - making the error extension specific: outputting it only for behavior changing extensions - adding a config option for whether this gives an error or not. Default config could then disable this error for binaries that are known to use extension declarations in wrong place. How common this issue is, what other programs have this issue besides Second life client, photoshop, and Unigine Heaven benchmark? And what extensions those declare in wrong place? -- 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 2/5] meta: fix meta clear of layered framebuffers
Considering you're the only user of meta_clear who cares about it,
it's all up to you. If your hardware can do AMD_vertex_shader_layer,
you won't ever have to implement any other code path.
It's silly to have multiple GLSL shaders for different versions of the
API. I think this should be API-independent and the GLSL compiler
should allow you to compile any shader for internal purposes. If we
adopted the GLSL IR as the main IR in Gallium, we would make it
API-agnostic and allow compilation of all shaders the GLSL compiler
knows how to compile.
I don't think you need a separate shader for outputting a float vs
integer color. What we do in Gallium is that we set the clear color as
a vertex input which is R32G32B32A32_FLOAT, which is passed to the
fragment shader as a flat varying and written to gl_FragColor. If it's
an integer clear, it doesn't matter. The bits of the clear color are
not changed anywhere, so integer clears work too.
Marek
On Thu, Nov 21, 2013 at 4:52 PM, Paul Berry stereotype...@gmail.com wrote:
On 21 November 2013 05:21, Marek Olšák mar...@gmail.com wrote:
I currently work on a simpler solution for Gallium. I'm using
AMD_vertex_shader_layer and this vertex shader (I wrote it in TGSI
though):
void main()
{
gl_Position = gl_Vertex;
gl_TexCoord[0] = MultiTexCoord0; // clear color
gl_Layer = gl_InstanceID;
}
Then I render the quad with DrawArraysInstanced and set the instance
count = NumLayers. That way each instance (each quad) is sent to a
different layer and everything is cleared in one draw call.
Drivers not supporting AMD_vertex_shader_layer will have to use a GS
though.
Your approach potentially has better performance, but I'm concerned about
risk, because I'm hoping to get this patch cherry-picked into 10.0 (which is
due to be released in a week). Currently GLSL clear uses 4 different
shaders:
1. A vertex shader that just sets gl_Position (compilable for either desktop
GLSL 1.10 or GLSL ES 1.00)
2. A vertex shader that just sets gl_Position (compilable for either desktop
GLSL 1.30 or GLSL ES 3.00)
3. A fragment shader that outputs floating point color (compilable for
either desktop GLSL or GLSL ES)
4. A fragment shader that outputs integer color (compilable for either
desktop GLSL 1.30 or GLSL ES 3.00)
My proposal adds a fifth:
5. A geometry shader that sets gl_Position and gl_Layer
If we want to use gl_InstanceID and AMD_vertex_shader_layer, we would have
to add two more:
6. A vertex shader that sets gl_Position and gl_Layer (for drivers that
support AMD_vertex_shader_layer)
7. A vertex shader that sets gl_Position and passes through gl_InstanceID to
the GS (for drivers that support GS but not AMD_vertex_shader_layer)
Testing on the Meta clear path is already pretty thin (at least for i965)
because most i965 clears can be done by faster mechanisms (fast color clear,
fast depth clear, or the blorp color clear). I'm worried about
introducing 3 new shaders to a poorly-tested Meta path this late in the
release process.
Anyone want to weigh in on this subject from a risk perspective?
I'm also wondering how important performance really is in this patch. I
suspect it's not a big issue for i965, since i965 usually does clears using
faster mechanisms. It's not an issue for i915, since i915 doesn't support
geometry shaders. Are there other drivers that use Meta other than those
two? If not, I'm tempted to leave this patch as is, based on the reasoning
that since Meta is a fallback mechanism, correctness is more important than
performance.
Marek
On Wed, Nov 20, 2013 at 5:47 AM, Paul Berry stereotype...@gmail.com
wrote:
From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
When the Clear or ClearBuffer* commands are used to clear a
layered framebuffer attachment, all layers of the attachment are
cleared.
This patch fixes meta clears to properly clear all layers of a layered
framebuffer attachment. We accomplish this by adding a geometry
shader to the meta clear program which sets gl_Layer to a uniform
value. When clearing a layered framebuffer, we execute in a loop,
setting the uniform to point to each layer in turn.
Cc: 10.0 mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/common/meta.c | 51
+++---
1 file changed, 48 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c
b/src/mesa/drivers/common/meta.c
index 99b02ba..a6d5098 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -241,9 +241,11 @@ struct clear_state
GLuint VBO;
GLuint ShaderProg;
GLint ColorLocation;
+ GLint LayerLocation;
GLuint IntegerShaderProg;
GLint IntegerColorLocation;
+ GLint IntegerLayerLocation;
};
@@ -2145,6 +2147,19 @@ meta_glsl_clear_init(struct gl_context *ctx,
struct clear_state *clear)
{\n
Re: [Mesa-dev] [PATCH] llvmpipe: support 8bit subpixel precision
- Original Message -
Great!
Couple of comments inline.
On 11/21/2013 12:02 AM, Zack Rusin wrote:
8 bit precision is required by d3d10 but unfortunately
requires 64 bit rasterizer. This commit implements
64 bit rasterization with full support for 8bit subpixel
precision. It's a combination of all individual commits
from the llvmpipe-rast-64 branch.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/drivers/llvmpipe/lp_rast.c | 11 ++
src/gallium/drivers/llvmpipe/lp_rast.h | 47 +--
src/gallium/drivers/llvmpipe/lp_rast_debug.c | 6 +-
src/gallium/drivers/llvmpipe/lp_rast_priv.h| 27
src/gallium/drivers/llvmpipe/lp_rast_tri.c | 173
+
src/gallium/drivers/llvmpipe/lp_rast_tri_tmp.h | 56
src/gallium/drivers/llvmpipe/lp_setup_line.c | 2 +-
src/gallium/drivers/llvmpipe/lp_setup_tri.c| 155
++
src/gallium/tests/graw/SConscript | 1 +
src/gallium/tests/graw/tri-large.c | 173
+
10 files changed, 500 insertions(+), 151 deletions(-)
create mode 100644 src/gallium/tests/graw/tri-large.c
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c
b/src/gallium/drivers/llvmpipe/lp_rast.c
index af661e9..0cd62c2 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -589,6 +589,17 @@ static lp_rast_cmd_func dispatch[LP_RAST_OP_MAX] =
lp_rast_begin_query,
lp_rast_end_query,
lp_rast_set_state,
+ lp_rast_triangle_32_1,
+ lp_rast_triangle_32_2,
+ lp_rast_triangle_32_3,
+ lp_rast_triangle_32_4,
+ lp_rast_triangle_32_5,
+ lp_rast_triangle_32_6,
+ lp_rast_triangle_32_7,
+ lp_rast_triangle_32_8,
+ lp_rast_triangle_32_3_4,
+ lp_rast_triangle_32_3_16,
+ lp_rast_triangle_32_4_16
};
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.h
b/src/gallium/drivers/llvmpipe/lp_rast.h
index 43c598d..b81d94f 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.h
+++ b/src/gallium/drivers/llvmpipe/lp_rast.h
@@ -46,10 +46,11 @@ struct lp_scene;
struct lp_fence;
struct cmd_bin;
-#define FIXED_TYPE_WIDTH 32
+#define FIXED_TYPE_WIDTH 64
/** For sub-pixel positioning */
-#define FIXED_ORDER 4
+#define FIXED_ORDER 8
#define FIXED_ONE (1FIXED_ORDER)
+#define FIXED_SHIFT (FIXED_TYPE_WIDTH - 1)
/** Maximum length of an edge in a primitive in pixels.
* If the framebuffer is large we have to think about fixed-point
* integer overflow. Coordinates need ((FIXED_TYPE_WIDTH/2) - 1) bits
@@ -59,11 +60,14 @@ struct cmd_bin;
*/
#define MAX_FIXED_LENGTH (1 (((FIXED_TYPE_WIDTH/2) - 1) -
FIXED_ORDER))
+#define MAX_FIXED_LENGTH32 (1 (((32/2) - 1) - FIXED_ORDER))
+
/* Rasterizer output size going to jit fs, width/height */
#define LP_RASTER_BLOCK_SIZE 4
#define LP_MAX_ACTIVE_BINNED_QUERIES 16
+#define IMUL64(a, b) (((int64_t)(a)) * ((int64_t)(b)))
struct lp_rasterizer_task;
@@ -102,18 +106,15 @@ struct lp_rast_shader_inputs {
/* followed by a0, dadx, dady and planes[] */
};
-/* Note: the order of these values is important as they are loaded by
- * sse code in rasterization:
- */
struct lp_rast_plane {
/* edge function values at minx,miny ?? */
- int c;
+ int64_t c;
- int dcdx;
- int dcdy;
+ int32_t dcdx;
+ int32_t dcdy;
/* one-pixel sized trivial reject offsets for each plane */
- int eo;
+ int64_t eo;
};
I'm still not entirely happy that even for rasterization we need 64bits.
And even more unhappy that we have to deal with pseudo-64bit values even
when we can use the 32bit versions so we get a metric crapload of scalar
loads. But then again I'm not happy about other things in
rasterization... It may be avoidable by doing some per-tile fixup (the
64bit rasterization, the need for having 64bit structs for 32bit
rasterization could be avoided by using separate plane arg for 32bit).
But we can always fix that later. I bet that if you're on a 32bit arch
it will be very slow.
I'm not happy about rain neither, but there's not much that can be done about
it. 64bit arithmetic at setup/binning stage is impossible except for tiny
(128x128) rendertargets that nobody cares about. We can manage with 32bit
arithmetic at tile rasterization, if triangles are small (again 128x128).
/**
@@ -277,8 +278,19 @@ lp_rast_arg_null( void )
#define LP_RAST_OP_BEGIN_QUERY 0xf
#define LP_RAST_OP_END_QUERY 0x10
#define LP_RAST_OP_SET_STATE 0x11
-
-#define LP_RAST_OP_MAX 0x12
+#define LP_RAST_OP_TRIANGLE_32_1 0x12
+#define LP_RAST_OP_TRIANGLE_32_2 0x13
+#define LP_RAST_OP_TRIANGLE_32_3 0x14
+#define LP_RAST_OP_TRIANGLE_32_4 0x15
+#define
Re: [Mesa-dev] [v3 6/8] mesa: Fill out ARB_texture_view entry points
I'd rename this summary as something like mesa: implement the
_mesa_TextureView() function
On 11/19/2013 04:16 PM, Courtney Goeltzenleuchter wrote:
Add Mesa TextureView logic.
Incorporate feedback on ARB_texture_view
Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
src/mesa/main/textureview.c | 562 +++-
1 file changed, 561 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/textureview.c b/src/mesa/main/textureview.c
index 4a6bd62..1858465 100644
--- a/src/mesa/main/textureview.c
+++ b/src/mesa/main/textureview.c
@@ -40,8 +40,346 @@
#include texobj.h
#include texstorage.h
#include textureview.h
+#include stdbool.h
#include mtypes.h
+/* Table 3.X.2 (Compatible internal formats for TextureView)
+---
+| Class | Internal formats|
+---
+| VIEW_CLASS_128_BITS | RGBA32F, RGBA32UI, RGBA32I |
+---
+| VIEW_CLASS_96_BITS| RGB32F, RGB32UI, RGB32I |
+---
+| VIEW_CLASS_64_BITS| RGBA16F, RG32F, RGBA16UI, RG32UI, RGBA16I, |
+| | RG32I, RGBA16, RGBA16_SNORM |
+---
+| VIEW_CLASS_48_BITS| RGB16, RGB16_SNORM, RGB16F, RGB16UI, RGB16I |
+---
+| VIEW_CLASS_32_BITS| RG16F, R11F_G11F_B10F, R32F,|
+| | RGB10_A2UI, RGBA8UI, RG16UI, R32UI, |
+| | RGBA8I, RG16I, R32I, RGB10_A2, RGBA8, RG16, |
+| | RGBA8_SNORM, RG16_SNORM, SRGB8_ALPHA8, RGB9_E5 |
+---
+| VIEW_CLASS_24_BITS| RGB8, RGB8_SNORM, SRGB8, RGB8UI, RGB8I |
+---
+| VIEW_CLASS_16_BITS| R16F, RG8UI, R16UI, RG8I, R16I, RG8, R16, |
+| | RG8_SNORM, R16_SNORM|
+---
+| VIEW_CLASS_8_BITS | R8UI, R8I, R8, R8_SNORM |
+---
+| VIEW_CLASS_RGTC1_RED | COMPRESSED_RED_RGTC1, |
+| | COMPRESSED_SIGNED_RED_RGTC1 |
+---
+| VIEW_CLASS_RGTC2_RG | COMPRESSED_RG_RGTC2,|
+| | COMPRESSED_SIGNED_RG_RGTC2 |
+---
+| VIEW_CLASS_BPTC_UNORM | COMPRESSED_RGBA_BPTC_UNORM, |
+| | COMPRESSED_SRGB_ALPHA_BPTC_UNORM|
+---
+| VIEW_CLASS_BPTC_FLOAT | COMPRESSED_RGB_BPTC_SIGNED_FLOAT, |
+| | COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT |
+---
+ */
+struct internal_format_class_info {
+ GLenum view_class;
+ GLenum internal_format;
+};
+#define INFO(c,f) {GL_##c, GL_##f}
+static const struct internal_format_class_info _compatible_internal_formats[]
= {
+ INFO(VIEW_CLASS_128_BITS, RGBA32F),
If the point of the macro is just to save typing GL_ prefixes, I don't
think it's worth it.
The leading underscore on _compatible_internal_formats isn't really
necessary.
+ INFO(VIEW_CLASS_128_BITS, RGBA32UI),
+ INFO(VIEW_CLASS_128_BITS, RGBA32I),
+ INFO(VIEW_CLASS_96_BITS, RGB32F),
+ INFO(VIEW_CLASS_96_BITS, RGB32UI),
+ INFO(VIEW_CLASS_96_BITS, RGB32I),
+ INFO(VIEW_CLASS_64_BITS, RGBA16F),
+ INFO(VIEW_CLASS_64_BITS, RG32F),
+ INFO(VIEW_CLASS_64_BITS, RGBA16UI),
+ INFO(VIEW_CLASS_64_BITS, RG32UI),
+ INFO(VIEW_CLASS_64_BITS, RGBA16I),
+ INFO(VIEW_CLASS_64_BITS, RG32I),
+ INFO(VIEW_CLASS_64_BITS, RGBA16),
+ INFO(VIEW_CLASS_64_BITS, RGBA16_SNORM),
+ INFO(VIEW_CLASS_48_BITS, RGB16),
+ INFO(VIEW_CLASS_48_BITS, RGB16_SNORM),
+ INFO(VIEW_CLASS_48_BITS, RGB16F),
+ INFO(VIEW_CLASS_48_BITS, RGB16UI),
+ INFO(VIEW_CLASS_48_BITS, RGB16I),
+ INFO(VIEW_CLASS_32_BITS, RG16F),
+ INFO(VIEW_CLASS_32_BITS, R11F_G11F_B10F),
+ INFO(VIEW_CLASS_32_BITS, R32F),
+ INFO(VIEW_CLASS_32_BITS,
Re: [Mesa-dev] [PATCH v2 2/5] meta: fix meta clear of layered framebuffers
Eric Anholt e...@anholt.net writes: Paul Berry stereotype...@gmail.com writes: From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec: When the Clear or ClearBuffer* commands are used to clear a layered framebuffer attachment, all layers of the attachment are cleared. This patch fixes meta clears to properly clear all layers of a layered framebuffer attachment. We accomplish this by adding a geometry shader to the meta clear program which sets gl_Layer to a uniform value. When clearing a layered framebuffer, we execute in a loop, setting the uniform to point to each layer in turn. I don't think we should be running a gs in the !NumLayers case. The other patches are: Reviewed-by: Eric Anholt e...@anholt.net Paul reminded that thanks to the simd16 repdata clear, we're basically never calling glsl clear on gen6+, and we only enable GS on gen7+. As such, I'm not really concerned about the performance any more, and by the time anyone else can care about it we should have ARB_sso, at which point optionally slotting in a GS to do this work on a layered FB is easy. I think. Reviewed-by: Eric Anholt e...@anholt.net pgp0GOulKBhPT.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: Add a section with recommended reading for llvmpipe development.
On 11/21/2013 06:03 PM, jfons...@vmware.com wrote: From: José Fonseca jfons...@vmware.com Several links contributed by Keith Whitwell and Roland Scheidegger. --- docs/llvmpipe.html | 58 -- 1 file changed, 56 insertions(+), 2 deletions(-) diff --git a/docs/llvmpipe.html b/docs/llvmpipe.html index 80f8a01..d695907 100644 --- a/docs/llvmpipe.html +++ b/docs/llvmpipe.html @@ -203,11 +203,65 @@ for posterior analysis, e.g.: We use LLVM-C bindings for now. They are not documented, but follow the C++ interfaces very closely, and appear to be complete enough for code generation. See - http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html - for a stand-alone example. See the llvm-c/Core.h file for reference. + a href=http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html; + this stand-alone example/a. See the llvm-c/Core.h file for reference. /li /ul +h1 id=recommended_readingRecommended Reading/h1 + +ul + li +pRasterization/p +ul + lia href=http://www.cs.unc.edu/~olano/papers/2dh-tri/;Triangle Scan Conversion using 2D Homogeneous Coordinates/a/li + lia href=http://www.drdobbs.com/parallel/rasterization-on-larrabee/217200602;Rasterization on Larrabee/a (a href=http://devmaster.net/posts/2887/rasterization-on-larrabee;DevMaster copy/a)/li + lia href=http://devmaster.net/posts/6133/rasterization-using-half-space-functions;Rasterization using half-space functions/a/li + lia href=http://devmaster.net/posts/6145/advanced-rasterization;Advanced Rasterization/a/li + lia href=http://fgiesen.wordpress.com/2013/02/17/optimizing-sw-occlusion-culling-index/;Optimizing Software Occlusion Culling/a/li +/ul + /li + li +pTexture sampling/p +ul + lia href=http://chrishecker.com/Miscellaneous_Technical_Articles#Perspective_Texture_Mapping;Perspective Texture Mapping/a/li + lia href=http://www.flipcode.com/archives/Texturing_As_In_Unreal.shtml;Texturing As In Unreal/a/li + lia href=http://www.gamasutra.com/view/feature/3301/runtime_mipmap_filtering.php;Run-Time MIP-Map Filtering/a/li + lia href=http://alt.3dcenter.org/artikel/2003/10-26_a_english.php;Will brilinear filtering persist?/a/li + lia href=http://ixbtlabs.com/articles2/gffx/nv40-rx800-3.html;Trilinear filtering/a/li + lia href=http://devmaster.net/posts/12785/texture-swizzling;Texture Swizzling/a/li +/ul + /li + li +pSIMD/p +ul + lia href=http://www.cdl.uni-saarland.de/projects/wfv/#header4;Whole-Function Vectorization/a/li +/ul + /li + li +pOptimization/p +ul + lia href=http://www.drdobbs.com/optimizing-pixomatic-for-modern-x86-proc/184405807;Optimizing Pixomatic For Modern x86 Processors/a/li + lia href=http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html;Intel 64 and IA-32 Architectures Optimization Reference Manual/a/li + lia href=http://www.agner.org/optimize/;Software optimization resources/a/li + lia href=http://software.intel.com/en-us/articles/intel-intrinsics-guide;Intel Intrinsics Guide/ali +/ul + /li + li +pLLVM/p +ul + lia href=http://llvm.org/docs/LangRef.html;LLVM Language Reference Manual/a/li + lia href=http://npcontemplation.blogspot.co.uk/2008/06/secret-of-llvm-c-bindings.html;The secret of LLVM C bindings/a/li +/ul + /li + li +pMisc/p +ul + lia href=http://msdn.microsoft.com/en-us/library/gg615082.aspx#architecture;WARP Architecture and Performance/a/li +/ul + /li +/ul + /div /body /html Loods good to me. Thought that would be just one link from me :-). Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] i965: Keep pointers to IF/ELSE/ENDIF instructions in the cfg.
Useful for finding the associated control flow instructions, given a
block ending in one.
---
v2: Handle nested control flow properly. When we reach the ENDIF, we have
still have the pointers to the IF and ELSE (if it exists).
The confusing bit of this code is that while bblock_t *cur_if is the
block that ends in the IF, but cur_else and cur_endif are the blocks
immediately after the ELSE and ENDIF instructions.
src/mesa/drivers/dri/i965/brw_cfg.cpp | 33 +
src/mesa/drivers/dri/i965/brw_cfg.h | 10 ++
2 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.cpp
b/src/mesa/drivers/dri/i965/brw_cfg.cpp
index e9d2bb8..e1a3662 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.cpp
+++ b/src/mesa/drivers/dri/i965/brw_cfg.cpp
@@ -28,7 +28,7 @@
#include brw_fs.h
#include brw_cfg.h
-/** @file brw_cfg_t.cpp
+/** @file brw_cfg.cpp
*
* Walks the shader instructions generated and creates a set of basic
* blocks with successor/predecessor edges connecting them.
@@ -52,6 +52,10 @@ bblock_t::bblock_t() :
parents.make_empty();
children.make_empty();
+
+ if_inst = NULL;
+ else_inst = NULL;
+ endif_inst = NULL;
}
void
@@ -142,20 +146,41 @@ cfg_t::create(void *parent_mem_ctx, exec_list
*instructions)
set_next_block(next);
break;
- case BRW_OPCODE_ENDIF:
+ case BRW_OPCODE_ENDIF: {
cur_endif-start = (backend_instruction *)inst-next;
cur-add_successor(mem_ctx, cur_endif);
+
set_next_block(cur_endif);
-if (!cur_else)
+ backend_instruction *else_inst = cur_else ?
+(backend_instruction *) cur_else-start-prev : NULL;
+
+ assert(cur_if-end-opcode == BRW_OPCODE_IF);
+ assert(!else_inst || else_inst-opcode == BRW_OPCODE_ELSE);
+ assert(inst-opcode == BRW_OPCODE_ENDIF);
+
+ cur_if-if_inst = cur_if-end;
+ cur_if-else_inst = else_inst;
+ cur_if-endif_inst = inst;
+
+if (!cur_else) {
cur_if-add_successor(mem_ctx, cur_endif);
+ } else {
+cur_else-if_inst = cur_if-end;
+cur_else-else_inst = else_inst;
+cur_else-endif_inst = inst;
+ }
+
+ cur-if_inst = cur_if-end;
+ cur-else_inst = else_inst;
+ cur-endif_inst = inst;
/* Pop the stack so we're in the previous if/else/endif */
cur_if = pop_stack(if_stack);
cur_else = pop_stack(else_stack);
cur_endif = pop_stack(endif_stack);
break;
-
+ }
case BRW_OPCODE_DO:
/* Push our information onto a stack so we can recover from
* nested loops.
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
b/src/mesa/drivers/dri/i965/brw_cfg.h
index ec5a3a0..2f5e3f9 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
+++ b/src/mesa/drivers/dri/i965/brw_cfg.h
@@ -56,6 +56,16 @@ public:
exec_list parents;
exec_list children;
int block_num;
+
+ /* If the current basic block ends in an IF, ELSE, or ENDIF instruction,
+* these pointers will hold the locations of the other associated control
+* flow instructions.
+*
+* Otherwise they are NULL.
+*/
+ backend_instruction *if_inst;
+ backend_instruction *else_inst;
+ backend_instruction *endif_inst;
};
class cfg_t {
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888
The __DRIimage createImageFromFds function takes a fourcc code, but there was
no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for
that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to
__DRI_IMAGE_FOURCC_SARGB and then adds translations *back* to
__IMAGE_FORMAT_SARGB8 in both the i915 and i965 drivers.
I'll refrain from comments on whether I think having two separate sets of
format defines in dri_interface.h is a good idea or not...
Signed-off-by: Keith Packard kei...@keithp.com
---
This gets iceweasel running with the GL compositor enabled.
include/GL/internal/dri_interface.h | 1 +
src/glx/dri3_glx.c | 1 +
src/mesa/drivers/dri/i915/intel_screen.c | 3 +++
src/mesa/drivers/dri/i965/intel_screen.c | 3 +++
4 files changed, 8 insertions(+)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index b012570..a4387c4 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1034,6 +1034,7 @@ struct __DRIdri2ExtensionRec {
#define __DRI_IMAGE_FOURCC_XRGB0x34325258
#define __DRI_IMAGE_FOURCC_ABGR0x34324241
#define __DRI_IMAGE_FOURCC_XBGR0x34324258
+#define __DRI_IMAGE_FOURCC_SARGB0x83324258
#define __DRI_IMAGE_FOURCC_YUV410 0x39565559
#define __DRI_IMAGE_FOURCC_YUV411 0x31315559
#define __DRI_IMAGE_FOURCC_YUV420 0x32315559
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index b047cc8..5861317 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -890,6 +890,7 @@ image_format_to_fourcc(int format)
/* Convert from __DRI_IMAGE_FORMAT to __DRI_IMAGE_FOURCC (sigh) */
switch (format) {
+ case __DRI_IMAGE_FORMAT_SARGB8: return __DRI_IMAGE_FOURCC_SARGB;
case __DRI_IMAGE_FORMAT_RGB565: return __DRI_IMAGE_FOURCC_RGB565;
case __DRI_IMAGE_FORMAT_XRGB: return __DRI_IMAGE_FOURCC_XRGB;
case __DRI_IMAGE_FORMAT_ARGB: return __DRI_IMAGE_FOURCC_ARGB;
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c
b/src/mesa/drivers/dri/i915/intel_screen.c
index 7f1fc6b..2dd2bc7 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -184,6 +184,9 @@ static struct intel_image_format intel_image_formats[] = {
{ __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
{ { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
+ { __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_SARGB8, 4 } } },
+
{ __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
{ { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index e44d0f6..cf8c3e2 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -220,6 +220,9 @@ static struct intel_image_format intel_image_formats[] = {
{ __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
{ { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
+ { __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_SARGB8, 4 } } },
+
{ __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
{ { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
--
1.8.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71903] New: [swrast] piglit hiz-depth-read-window-stencil0 regression
https://bugs.freedesktop.org/show_bug.cgi?id=71903
Priority: medium
Bug ID: 71903
Keywords: regression
CC: airl...@freedesktop.org
Assignee: mesa-dev@lists.freedesktop.org
Summary: [swrast] piglit hiz-depth-read-window-stencil0
regression
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: v...@freedesktop.org
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Other
Product: Mesa
mesa: bb354c6c279031dafc08029a62cd3e76a6c1ca71 (master)
$ ./bin/hiz-depth-read-window-stencil0 -auto
Probe color at (16,16)
Expected: 0.00 1.00 0.00
Observed: 0.501961 0.501961 0.501961
Probe color at (66,16)
Expected: 0.00 1.00 0.00
Observed: 0.00 0.00 1.00
Probe color at (116,16)
Expected: 0.50 0.50 0.50
Observed: 0.00 0.00 1.00
Probe color at (16,116)
Expected: 0.50 0.50 0.50
Observed: 0.00 1.00 0.00
Probe color at (66,116)
Expected: 0.00 0.00 1.00
Observed: 0.00 1.00 0.00
Probe color at (116,116)
Expected: 0.00 0.00 1.00
Observed: 0.501961 0.501961 0.501961
PIGLIT: {'result': 'fail' }
a43b49dfb13dc7e6d2d6d7ceee892077038d7102 is the first bad commit
commit a43b49dfb13dc7e6d2d6d7ceee892077038d7102
Author: Dave Airlie airl...@redhat.com
Date: Wed Nov 13 12:53:52 2013 +1000
mesa/swrast: fix inverted front buffer rendering with old-school swrast
I've no idea when this broke, but we have some people who wanted it fixed,
so here's my attempt.
reproducer, run readpix with swrast hit f, or run trival tri -sb things are
upside down, after this patch they aren't.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62142
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66213
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Dave Airlie airl...@redhat.com
:04 04 70e437e84fa67556a6469a8bf75277a6ec07e8a6
a307a4bc1dcb80aae42897ce27b7771dd8760f4f Msrc
bisect run success
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71904] New: [swrast] piglit glsl-reload-source regression
https://bugs.freedesktop.org/show_bug.cgi?id=71904
Priority: medium
Bug ID: 71904
Keywords: regression
CC: airl...@freedesktop.org
Assignee: mesa-dev@lists.freedesktop.org
Summary: [swrast] piglit glsl-reload-source regression
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: v...@freedesktop.org
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Other
Product: Mesa
mesa: bb354c6c279031dafc08029a62cd3e76a6c1ca71 (master)
$ ./bin/glsl-reload-source -auto
Probe color at (37,37)
Expected: 0.00 0.40 0.00
Observed: 0.00 0.00 0.00
Probe color at (112,37)
Expected: 0.40 0.40 0.40
Observed: 0.00 0.00 0.00
Probe color at (37,112)
Expected: 0.40 0.40 0.00
Observed: 0.00 0.40 0.00
Probe color at (112,112)
Expected: 0.80 0.40 0.40
Observed: 0.40 0.40 0.40
PIGLIT: {'result': 'fail' }
a43b49dfb13dc7e6d2d6d7ceee892077038d7102 is the first bad commit
commit a43b49dfb13dc7e6d2d6d7ceee892077038d7102
Author: Dave Airlie airl...@redhat.com
Date: Wed Nov 13 12:53:52 2013 +1000
mesa/swrast: fix inverted front buffer rendering with old-school swrast
I've no idea when this broke, but we have some people who wanted it fixed,
so here's my attempt.
reproducer, run readpix with swrast hit f, or run trival tri -sb things are
upside down, after this patch they aren't.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62142
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66213
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Dave Airlie airl...@redhat.com
:04 04 70e437e84fa67556a6469a8bf75277a6ec07e8a6
a307a4bc1dcb80aae42897ce27b7771dd8760f4f Msrc
bisect run success
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: support 8bit subpixel precision
For me too, other than the fixed_position members, looks good. Thanks for
your perseverance on this Zack!
Thanks! ok, attached is a version that makes position and dx/dy 32bit again, it
seems to work great. I have a question for you guys if you run the piglits:
./bin/triangle-rasterization-overdraw -max_size -seed 0xA8402F24 -count 1 -auto
on master does it fail for you? It fails for me on master, with and without the
patch. I'm not sure what to make of it, I might have been looking at
rasterization for too long. Looking at the rendering it looks correct.
zFrom 55c9a288c7ebc37b32bc75526e6de71a838ccaef Mon Sep 17 00:00:00 2001
From: Zack Rusin za...@vmware.com
Date: Thu, 24 Oct 2013 22:05:22 -0400
Subject: [PATCH] llvmpipe: support 8bit subpixel precision
8 bit precision is required by d3d10 but unfortunately
requires 64 bit rasterizer. This commit implements
64 bit rasterization with full support for 8bit subpixel
precision. It's a combination of all individual commits
from the llvmpipe-rast-64 branch.
---
src/gallium/drivers/llvmpipe/lp_rast.c | 11 ++
src/gallium/drivers/llvmpipe/lp_rast.h | 47 +--
src/gallium/drivers/llvmpipe/lp_rast_debug.c | 6 +-
src/gallium/drivers/llvmpipe/lp_rast_priv.h| 27
src/gallium/drivers/llvmpipe/lp_rast_tri.c | 173
src/gallium/drivers/llvmpipe/lp_rast_tri_tmp.h | 56
src/gallium/drivers/llvmpipe/lp_setup_line.c | 2 +-
src/gallium/drivers/llvmpipe/lp_setup_tri.c| 147 +
src/gallium/tests/graw/SConscript | 1 +
src/gallium/tests/graw/tri-large.c | 174 +
10 files changed, 496 insertions(+), 148 deletions(-)
create mode 100644 src/gallium/tests/graw/tri-large.c
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c b/src/gallium/drivers/llvmpipe/lp_rast.c
index af661e9..0cd62c2 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -589,6 +589,17 @@ static lp_rast_cmd_func dispatch[LP_RAST_OP_MAX] =
lp_rast_begin_query,
lp_rast_end_query,
lp_rast_set_state,
+ lp_rast_triangle_32_1,
+ lp_rast_triangle_32_2,
+ lp_rast_triangle_32_3,
+ lp_rast_triangle_32_4,
+ lp_rast_triangle_32_5,
+ lp_rast_triangle_32_6,
+ lp_rast_triangle_32_7,
+ lp_rast_triangle_32_8,
+ lp_rast_triangle_32_3_4,
+ lp_rast_triangle_32_3_16,
+ lp_rast_triangle_32_4_16
};
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.h b/src/gallium/drivers/llvmpipe/lp_rast.h
index 43c598d..b81d94f 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.h
+++ b/src/gallium/drivers/llvmpipe/lp_rast.h
@@ -46,10 +46,11 @@ struct lp_scene;
struct lp_fence;
struct cmd_bin;
-#define FIXED_TYPE_WIDTH 32
+#define FIXED_TYPE_WIDTH 64
/** For sub-pixel positioning */
-#define FIXED_ORDER 4
+#define FIXED_ORDER 8
#define FIXED_ONE (1FIXED_ORDER)
+#define FIXED_SHIFT (FIXED_TYPE_WIDTH - 1)
/** Maximum length of an edge in a primitive in pixels.
* If the framebuffer is large we have to think about fixed-point
* integer overflow. Coordinates need ((FIXED_TYPE_WIDTH/2) - 1) bits
@@ -59,11 +60,14 @@ struct cmd_bin;
*/
#define MAX_FIXED_LENGTH (1 (((FIXED_TYPE_WIDTH/2) - 1) - FIXED_ORDER))
+#define MAX_FIXED_LENGTH32 (1 (((32/2) - 1) - FIXED_ORDER))
+
/* Rasterizer output size going to jit fs, width/height */
#define LP_RASTER_BLOCK_SIZE 4
#define LP_MAX_ACTIVE_BINNED_QUERIES 16
+#define IMUL64(a, b) (((int64_t)(a)) * ((int64_t)(b)))
struct lp_rasterizer_task;
@@ -102,18 +106,15 @@ struct lp_rast_shader_inputs {
/* followed by a0, dadx, dady and planes[] */
};
-/* Note: the order of these values is important as they are loaded by
- * sse code in rasterization:
- */
struct lp_rast_plane {
/* edge function values at minx,miny ?? */
- int c;
+ int64_t c;
- int dcdx;
- int dcdy;
+ int32_t dcdx;
+ int32_t dcdy;
/* one-pixel sized trivial reject offsets for each plane */
- int eo;
+ int64_t eo;
};
/**
@@ -277,8 +278,19 @@ lp_rast_arg_null( void )
#define LP_RAST_OP_BEGIN_QUERY 0xf
#define LP_RAST_OP_END_QUERY 0x10
#define LP_RAST_OP_SET_STATE 0x11
-
-#define LP_RAST_OP_MAX 0x12
+#define LP_RAST_OP_TRIANGLE_32_1 0x12
+#define LP_RAST_OP_TRIANGLE_32_2 0x13
+#define LP_RAST_OP_TRIANGLE_32_3 0x14
+#define LP_RAST_OP_TRIANGLE_32_4 0x15
+#define LP_RAST_OP_TRIANGLE_32_5 0x16
+#define LP_RAST_OP_TRIANGLE_32_6 0x17
+#define LP_RAST_OP_TRIANGLE_32_7 0x18
+#define LP_RAST_OP_TRIANGLE_32_8 0x19
+#define LP_RAST_OP_TRIANGLE_32_3_4 0x1a
+#define LP_RAST_OP_TRIANGLE_32_3_16 0x1b
+#define LP_RAST_OP_TRIANGLE_32_4_16 0x1c
+
+#define LP_RAST_OP_MAX 0x1d
#define LP_RAST_OP_MASK 0xff
void
@@ -289,4 +301,17 @@ void
lp_debug_draw_bins_by_coverage( struct lp_scene *scene );
+#ifdef PIPE_ARCH_SSE
+#include emmintrin.h
+#include util/u_sse.h
+
[Mesa-dev] [PATCH] dri3: Free resources when drawable is destroyed.
Always nice to clean up after ourselves.
Signed-off-by: Keith Packard kei...@keithp.com
---
Ok, so not having this in the dri3 code led to a bit of extra memory
usage in apps and the X server.
src/glx/dri3_glx.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 239d58b..669f0bb 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -266,13 +266,25 @@ dri3_create_context(struct glx_screen *base,
}
static void
+dri3_free_render_buffer(struct dri3_drawable *pdraw, struct dri3_buffer
*buffer);
+
+static void
dri3_destroy_drawable(__GLXDRIdrawable *base)
{
struct dri3_screen *psc = (struct dri3_screen *) base-psc;
struct dri3_drawable *pdraw = (struct dri3_drawable *) base;
+ xcb_connection_t *c = XGetXCBConnection(pdraw-base.psc-dpy);
+ int i;
(*psc-core-destroyDrawable) (pdraw-driDrawable);
+ for (i = 0; i DRI3_NUM_BUFFERS; i++) {
+ if (pdraw-buffers[i])
+ dri3_free_render_buffer(pdraw, pdraw-buffers[i]);
+ }
+
+ if (pdraw-special_event)
+ xcb_unregister_for_special_event(c, pdraw-special_event);
free(pdraw);
}
@@ -736,6 +748,7 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen,
Drawable draw,
fence_fd);
buffer-pixmap = pixmap;
+ buffer-own_pixmap = true;
buffer-sync_fence = sync_fence;
buffer-shm_fence = shm_fence;
buffer-width = width;
@@ -769,7 +782,8 @@ dri3_free_render_buffer(struct dri3_drawable *pdraw, struct
dri3_buffer *buffer)
struct dri3_screen *psc = (struct dri3_screen *) pdraw-base.psc;
xcb_connection_t *c = XGetXCBConnection(pdraw-base.psc-dpy);
- xcb_free_pixmap(c, buffer-pixmap);
+ if (buffer-own_pixmap)
+ xcb_free_pixmap(c, buffer-pixmap);
xcb_sync_destroy_fence(c, buffer-sync_fence);
xshmfence_unmap_shm(buffer-shm_fence);
(*psc-image-destroyImage)(buffer-image);
@@ -988,6 +1002,7 @@ dri3_get_pixmap_buffer(__DRIdrawable *driDrawable,
goto no_image;
buffer-pixmap = pixmap;
+ buffer-own_pixmap = false;
buffer-width = bp_reply-width;
buffer-height = bp_reply-height;
buffer-buffer_type = buffer_type;
--
1.8.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] v2: dri3: Free resources when drawable is destroyed.
Always nice to clean up after ourselves.
Signed-off-by: Keith Packard kei...@keithp.com
---
v2: Include changes to dri3_priv.h as well
src/glx/dri3_glx.c | 17 -
src/glx/dri3_priv.h | 5 -
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 239d58b..669f0bb 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -266,13 +266,25 @@ dri3_create_context(struct glx_screen *base,
}
static void
+dri3_free_render_buffer(struct dri3_drawable *pdraw, struct dri3_buffer
*buffer);
+
+static void
dri3_destroy_drawable(__GLXDRIdrawable *base)
{
struct dri3_screen *psc = (struct dri3_screen *) base-psc;
struct dri3_drawable *pdraw = (struct dri3_drawable *) base;
+ xcb_connection_t *c = XGetXCBConnection(pdraw-base.psc-dpy);
+ int i;
(*psc-core-destroyDrawable) (pdraw-driDrawable);
+ for (i = 0; i DRI3_NUM_BUFFERS; i++) {
+ if (pdraw-buffers[i])
+ dri3_free_render_buffer(pdraw, pdraw-buffers[i]);
+ }
+
+ if (pdraw-special_event)
+ xcb_unregister_for_special_event(c, pdraw-special_event);
free(pdraw);
}
@@ -736,6 +748,7 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen,
Drawable draw,
fence_fd);
buffer-pixmap = pixmap;
+ buffer-own_pixmap = true;
buffer-sync_fence = sync_fence;
buffer-shm_fence = shm_fence;
buffer-width = width;
@@ -769,7 +782,8 @@ dri3_free_render_buffer(struct dri3_drawable *pdraw, struct
dri3_buffer *buffer)
struct dri3_screen *psc = (struct dri3_screen *) pdraw-base.psc;
xcb_connection_t *c = XGetXCBConnection(pdraw-base.psc-dpy);
- xcb_free_pixmap(c, buffer-pixmap);
+ if (buffer-own_pixmap)
+ xcb_free_pixmap(c, buffer-pixmap);
xcb_sync_destroy_fence(c, buffer-sync_fence);
xshmfence_unmap_shm(buffer-shm_fence);
(*psc-image-destroyImage)(buffer-image);
@@ -988,6 +1002,7 @@ dri3_get_pixmap_buffer(__DRIdrawable *driDrawable,
goto no_image;
buffer-pixmap = pixmap;
+ buffer-own_pixmap = false;
buffer-width = bp_reply-width;
buffer-height = bp_reply-height;
buffer-buffer_type = buffer_type;
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 0d21e67..05f66cf 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -89,6 +89,7 @@ struct dri3_buffer {
uint32_t sync_fence; /* XID of X SyncFence object */
void *shm_fence; /* pointer to xshmfence object */
GLbooleanbusy; /* Set on swap, cleared on IdleNotify */
+ GLbooleanown_pixmap; /* We allocated the pixmap ID, free on destroy
*/
void *driverPrivate;
uint32_t size;
@@ -171,6 +172,8 @@ dri3_pixmap_buf_id(enum dri3_buffer_type buffer_type)
return DRI3_FRONT_ID;
}
+#define DRI3_NUM_BUFFERS(1 + DRI3_MAX_BACK)
+
struct dri3_drawable {
__GLXDRIdrawable base;
__DRIdrawable *driDrawable;
@@ -194,7 +197,7 @@ struct dri3_drawable {
uint64_t previous_time;
unsigned frames;
- struct dri3_buffer *buffers[1 + DRI3_MAX_BACK];
+ struct dri3_buffer *buffers[DRI3_NUM_BUFFERS];
int cur_back;
int depth;
--
1.8.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] radeonsi: implement MSAA for CIK
On Mit, 2013-11-20 at 15:20 +0100, Marek Olšák wrote: From: Marek Olšák marek.ol...@amd.com There are also some changes to the printfs. This series is Reviewed-and-Tested-by: Michel Dänzer michel.daen...@amd.com -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 45466] Updated configure.ac check for llvm-config to use 32 version when appropriate
https://bugs.freedesktop.org/show_bug.cgi?id=45466 --- Comment #3 from Alexandre Demers alexandre.f.dem...@gmail.com --- Comment on attachment 56473 -- https://bugs.freedesktop.org/attachment.cgi?id=56473 Improved version of the patch that touches mklib as well Review of attachment 56473: - ::: configure.ac @@ +1776,1 @@ Since this bug as been reopened. I may be wrong here, but according to the following patch (http://cgit.freedesktop.org/beignet/commit/?id=25bfb6ca3b22fc8f439ebd58ee03e33bfceeb927), using llvm-config-32 is not the same as llvm-config32. The former points to llvm-config version 3.2 on some distributions (or it could be on concurrent llvm installations), while the second points to a 32bit version of llvm-config. However, on other distributions, I've seen the form you are proposing being used to identify 32 and 64bit versions. -- 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 50754] Building 32 bit mesa on 64 bit OS fails since change for automake
https://bugs.freedesktop.org/show_bug.cgi?id=50754 --- Comment #24 from Alexandre Demers alexandre.f.dem...@gmail.com --- (In reply to comment #23) (In reply to comment #22) I'm closing this bug because I'm able to crosscompile anytime with the help of some variables. This is Mesa bug. You being able to work around Mesa bug doesn't mean that it's fixed in Mesa. Re-opening. IMHO either --enable-32-bit should be removed as misleading[1], or Mesa should be fixed. [1] as discussed, it sets CFLAGS/CXXFLAGS too late, so they don't have the required effect. Regarding Tapani's patch fixing this, there would need to be also a comment in configure.ac about the libtool initialization dependency on C/XXFLAGS values. The problem has been flagged many times. No decision has ever been taken. Having a recurring bug like this one where it is a matter of either fixing it or removing it shouldn't stay forever opened. When I closed it, because I had a workaround, I was considering the silence on this bug and the other similar ones as WONTBEFIXED. I'd be glad to either see it being fixed or dumped. As you say, if --enable-32-bit is not working as intended for anybody, then it is misleading and useless, thus it should be removed. In the Doc, we could indicate the workaround (which is not a workaround per-se because it is actually the detailed way of doing it instead of relying on an automated flag like --enable-32-bit). We even have an almost (yet simple) patch proposed that only needs a little fix as it seems. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] present: Send GLX_BufferSwapComplete events from present extension
This allows GL to support the GLX_INTEL_swap_event extension
Signed-off-by: Keith Packard kei...@keithp.com
---
This is the X server side; the mesa patch will be sent shortly (it's tiny)
glx/Makefile.am | 3 ++-
glx/glxcmds.c | 69 +
glx/glxdri2.c | 26 +--
glx/glxext.c| 3 +++
glx/glxserver.h | 9 +++
present/present.h | 9 +++
present/present_event.c | 10 +++
7 files changed, 109 insertions(+), 20 deletions(-)
diff --git a/glx/Makefile.am b/glx/Makefile.am
index 5f28e87..44d3a7d 100644
--- a/glx/Makefile.am
+++ b/glx/Makefile.am
@@ -20,7 +20,8 @@ AM_CPPFLAGS = \
-I$(top_srcdir)/hw/xfree86/os-support/bus \
-I$(top_srcdir)/hw/xfree86/common \
-I$(top_srcdir)/hw/xfree86/dri \
- -I$(top_srcdir)/mi
+ -I$(top_srcdir)/mi \
+ -I$(top_srcdir)/present
if DRI2_AIGLX
AM_CPPFLAGS += -I$(top_srcdir)/hw/xfree86/dri2
diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index efa4aec..2c5de70 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -2468,3 +2468,72 @@ __glXDisp_ClientInfo(__GLXclientState * cl, GLbyte * pc)
return Success;
}
+
+#include GL/glxtokens.h
+
+void
+__glXsendSwapEvent(__GLXdrawable *drawable, int type, CARD64 ust,
+ CARD64 msc, CARD32 sbc)
+{
+ClientPtr client = clients[CLIENT_ID(drawable-drawId)];
+
+xGLXBufferSwapComplete2 wire = {
+.type = __glXEventBase + GLX_BufferSwapComplete
+};
+
+if (!client)
+return;
+
+if (!(drawable-eventMask GLX_BUFFER_SWAP_COMPLETE_INTEL_MASK))
+return;
+
+wire.event_type = type;
+wire.drawable = drawable-drawId;
+wire.ust_hi = ust 32;
+wire.ust_lo = ust 0x;
+wire.msc_hi = msc 32;
+wire.msc_lo = msc 0x;
+wire.sbc = sbc;
+
+WriteEventsToClient(client, 1, (xEvent *) wire);
+}
+
+#if PRESENT
+static void
+__glXpresentCompleteNotify(WindowPtr window, CARD8 present_mode, CARD32 serial,
+ uint64_t ust, uint64_t msc)
+{
+__GLXdrawable *drawable;
+int error;
+int glx_type;
+int rc;
+
+rc = dixLookupResourceByType((pointer *) drawable, window-drawable.id,
+ __glXDrawableRes, serverClient,
DixGetAttrAccess);
+
+if (rc != Success)
+return;
+
+switch(present_mode) {
+case PresentCompleteModeFlip:
+glx_type = GLX_FLIP_COMPLETE_INTEL;
+break;
+case PresentCompleteModeCopy:
+glx_type = GLX_BLIT_COMPLETE_INTEL;
+break;
+default:
+glx_type = 0;
+break;
+}
+
+__glXsendSwapEvent(drawable, glx_type, ust, msc, serial);
+}
+
+#include present.h
+
+void
+__glXregisterPresentCompleteNotify(void)
+{
+present_register_complete_notify(__glXpresentCompleteNotify);
+}
+#endif
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 1d74c8f..9d3f3c3 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -177,36 +177,24 @@ __glXdriSwapEvent(ClientPtr client, void *data, int type,
CARD64 ust,
CARD64 msc, CARD32 sbc)
{
__GLXdrawable *drawable = data;
-xGLXBufferSwapComplete2 wire = {
-.type = __glXEventBase + GLX_BufferSwapComplete
-};
-
-if (!(drawable-eventMask GLX_BUFFER_SWAP_COMPLETE_INTEL_MASK))
-return;
-
+int glx_type;
switch (type) {
case DRI2_EXCHANGE_COMPLETE:
-wire.event_type = GLX_EXCHANGE_COMPLETE_INTEL;
+glx_type = GLX_EXCHANGE_COMPLETE_INTEL;
break;
case DRI2_BLIT_COMPLETE:
-wire.event_type = GLX_BLIT_COMPLETE_INTEL;
+glx_type = GLX_BLIT_COMPLETE_INTEL;
break;
case DRI2_FLIP_COMPLETE:
-wire.event_type = GLX_FLIP_COMPLETE_INTEL;
+glx_type = GLX_FLIP_COMPLETE_INTEL;
break;
default:
/* unknown swap completion type */
-wire.event_type = 0;
+glx_type = 0;
break;
}
-wire.drawable = drawable-drawId;
-wire.ust_hi = ust 32;
-wire.ust_lo = ust 0x;
-wire.msc_hi = msc 32;
-wire.msc_lo = msc 0x;
-wire.sbc = sbc;
-
-WriteEventsToClient(client, 1, (xEvent *) wire);
+
+__glXsendSwapEvent(drawable, glx_type, ust, msc, sbc);
}
/*
diff --git a/glx/glxext.c b/glx/glxext.c
index 3a7de28..601d08a 100644
--- a/glx/glxext.c
+++ b/glx/glxext.c
@@ -399,6 +399,9 @@ GlxExtensionInit(void)
__glXErrorBase = extEntry-errorBase;
__glXEventBase = extEntry-eventBase;
+#if PRESENT
+__glXregisterPresentCompleteNotify();
+#endif
}
//
diff --git a/glx/glxserver.h b/glx/glxserver.h
index 5e29abb..f862b63 100644
--- a/glx/glxserver.h
+++ b/glx/glxserver.h
@@ -120,6 +120,15 @@ void glxResumeClients(void);
void __glXsetGetProcAddress(void (*(*get_proc_address) (const char *)) (void));
void *__glGetProcAddress(const char *);
[Mesa-dev] [PATCH] dri3: Support GLX_INTEL_swap_event
The easy part is turning on the extension, now that the X server has a patch
to send the events.
The only trick was making sure the Present extension reliably provided the
right 'sbc' count back in the event, and that's done by making sure the sbc
count is always the same as the sequence number that we send in the
PresentPixmap requests, and that's done by using the same variable for both
roles.
Signed-off-by: Keith Packard kei...@keithp.com
---
This passes the piglet glx-swap-event test.
src/glx/dri3_glx.c | 27 ++-
src/glx/dri3_priv.h | 3 +--
2 files changed, 7 insertions(+), 23 deletions(-)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 669f0bb..a7bf318 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -423,7 +423,7 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t
target_msc, int64_t divisor,
*ust = priv-ust;
*msc = priv-msc;
- *sbc = priv-sbc;
+ *sbc = priv-present_count;
return 1;
}
@@ -450,7 +450,7 @@ dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t
target_sbc, int64_t *ust,
{
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
- while (priv-sbc target_sbc) {
+ while (priv-present_count target_sbc) {
sleep(1);
}
return dri3_wait_for_msc(pdraw, 0, 0, 0, ust, msc, sbc);
@@ -1282,7 +1282,8 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t
target_msc, int64_t divisor,
/* Compute when we want the frame shown by taking the last known
successful
* MSC and adding in a swap interval for each outstanding swap request
*/
- ++priv-present_request_serial;
+ ++priv-present_count;
+ priv-present_request_serial = (uint32_t) priv-present_count;
if (target_msc == 0)
target_msc = priv-msc + priv-swap_interval *
(priv-present_request_serial - priv-present_event_serial);
@@ -1302,7 +1303,7 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t
target_msc, int64_t divisor,
target_msc,
divisor,
remainder, 0, NULL);
- ret = ++priv-sbc;
+ ret = priv-present_count;
/* If there's a fake front, then copy the source back buffer
* to the fake front to keep it up to date. This needs
@@ -1494,23 +1495,7 @@ dri3_bind_extensions(struct dri3_screen *psc, struct
glx_display * priv,
__glXEnableDirectExtension(psc-base, GLX_SGI_swap_control);
__glXEnableDirectExtension(psc-base, GLX_MESA_swap_control);
__glXEnableDirectExtension(psc-base, GLX_SGI_make_current_read);
-
- /*
-* GLX_INTEL_swap_event is broken on the server side, where it's
-* currently unconditionally enabled. This completely breaks
-* systems running on drivers which don't support that extension.
-* There's no way to test for its presence on this side, so instead
-* of disabling it unconditionally, just disable it for drivers
-* which are known to not support it, or for DDX drivers supporting
-* only an older (pre-ScheduleSwap) version of DRI2.
-*
-* This is a hack which is required until:
-* http://lists.x.org/archives/xorg-devel/2013-February/035449.html
-* is merged and updated xserver makes it's way into distros:
-*/
-// if (pdp-swapAvailable strcmp(driverName, vmwgfx) != 0) {
-// __glXEnableDirectExtension(psc-base, GLX_INTEL_swap_event);
-// }
+ __glXEnableDirectExtension(psc-base, GLX_INTEL_swap_event);
mask = psc-image_driver-getAPIMask(psc-driScreen);
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 05f66cf..cdf986d 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -183,11 +183,10 @@ struct dri3_drawable {
uint8_t have_fake_front;
uint8_t is_pixmap;
+ uint64_t present_count;
uint32_t present_request_serial;
uint32_t present_event_serial;
- uint64_t sbc;
-
uint64_t ust, msc;
/* For WaitMSC */
--
1.8.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 50754] Building 32 bit mesa on 64 bit OS fails since change for automake
https://bugs.freedesktop.org/show_bug.cgi?id=50754 Alexandre Demers alexandre.f.dem...@gmail.com changed: What|Removed |Added Attachment #65690|0 |1 is obsolete|| --- Comment #25 from Alexandre Demers alexandre.f.dem...@gmail.com --- Created attachment 89621 -- https://bugs.freedesktop.org/attachment.cgi?id=89621action=edit Move LT_INIT where it should so it can test correctly (AM_)C(XX)FLAGS and others Updated patch against latest git code. Based on previous patch with further explanations. LT_INIT needs to work with the final content of variables to be able to correctly run some tests and determine the host type. So it must be called after setting anything we want to set in (AM_)C(XX)FLAGS or (AM_)LDFLAGS. Fixing LT_INIT must be done independently from modifying environment variables or build variables since LT_INIT will check both variables and shadow variables if they are set. Tested on my setup and it works. I'd like someone else to also test it. Another patch should be made to fix llvm-config, which is another topic. -- 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
