[Mesa-dev] [PATCH 1/2] winsys/svga: Update the vmwgfx_drm.h header to latest version from kernel
Cc: "10.1"
Signed-off-by: Thomas Hellstrom
---
src/gallium/winsys/svga/drm/vmwgfx_drm.h | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/gallium/winsys/svga/drm/vmwgfx_drm.h
b/src/gallium/winsys/svga/drm/vmwgfx_drm.h
index e42b3f5..73ad205 100644
--- a/src/gallium/winsys/svga/drm/vmwgfx_drm.h
+++ b/src/gallium/winsys/svga/drm/vmwgfx_drm.h
@@ -87,6 +87,16 @@
#define DRM_VMW_PARAM_MAX_SURF_MEMORY 7
#define DRM_VMW_PARAM_3D_CAPS_SIZE 8
#define DRM_VMW_PARAM_MAX_MOB_MEMORY 9
+#define DRM_VMW_PARAM_MAX_MOB_SIZE 10
+
+/**
+ * enum drm_vmw_handle_type - handle type for ref ioctls
+ *
+ */
+enum drm_vmw_handle_type {
+ DRM_VMW_HANDLE_LEGACY = 0,
+ DRM_VMW_HANDLE_PRIME = 1
+};
/**
* struct drm_vmw_getparam_arg
@@ -176,6 +186,7 @@ struct drm_vmw_surface_create_req {
* struct drm_wmv_surface_arg
*
* @sid: Surface id of created surface or surface to destroy or reference.
+ * @handle_type: Handle type for DRM_VMW_REF_SURFACE Ioctl.
*
* Output data from the DRM_VMW_CREATE_SURFACE Ioctl.
* Input argument to the DRM_VMW_UNREF_SURFACE Ioctl.
@@ -184,7 +195,7 @@ struct drm_vmw_surface_create_req {
struct drm_vmw_surface_arg {
int32_t sid;
- uint32_t pad64;
+ enum drm_vmw_handle_type handle_type;
};
/**
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] winsys/svga: Fix prime surface references also for guest-backed surfaces
Implement guest-backed surface sharing using prime fds. Previously only
legacy surfaces could use this functionality. Also use the vmwgfx 2.6
single-ioctl prime fd reference if available.
Cc: "10.1"
Signed-off-by: Thomas Hellstrom
---
src/gallium/winsys/svga/drm/vmw_screen.h | 4 +-
src/gallium/winsys/svga/drm/vmw_screen_dri.c | 7 ++-
src/gallium/winsys/svga/drm/vmw_screen_ioctl.c | 76 +-
3 files changed, 81 insertions(+), 6 deletions(-)
diff --git a/src/gallium/winsys/svga/drm/vmw_screen.h
b/src/gallium/winsys/svga/drm/vmw_screen.h
index b68bf43..1a39039 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen.h
+++ b/src/gallium/winsys/svga/drm/vmw_screen.h
@@ -74,6 +74,7 @@ struct vmw_winsys_screen
struct vmw_cap_3d *cap_3d;
uint64_t max_mob_memory;
uint64_t max_surface_memory;
+ boolean have_drm_2_6;
} ioctl;
struct {
@@ -138,10 +139,11 @@ vmw_ioctl_gb_surface_create(struct vmw_winsys_screen *vws,
int
vmw_ioctl_gb_surface_ref(struct vmw_winsys_screen *vws,
- uint32_t handle,
+ const struct winsys_handle *whandle,
SVGA3dSurfaceFlags *flags,
SVGA3dSurfaceFormat *format,
uint32_t *numMipLevels,
+ uint32_t *handle,
struct vmw_region **p_region);
void
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_dri.c
b/src/gallium/winsys/svga/drm/vmw_screen_dri.c
index 0f5a955..79a1b3e 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_dri.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_dri.c
@@ -183,10 +183,11 @@ vmw_drm_gb_surface_from_handle(struct svga_winsys_screen
*sws,
struct vmw_buffer_desc desc;
struct pb_manager *provider = vws->pools.gmr;
struct pb_buffer *pb_buf;
+uint32_t handle;
int ret;
-ret = vmw_ioctl_gb_surface_ref(vws, whandle->handle, &flags, format,
- &mip_levels, &desc.region);
+ret = vmw_ioctl_gb_surface_ref(vws, whandle, &flags, format,
+ &mip_levels, &handle, &desc.region);
if (ret) {
fprintf(stderr, "Failed referencing shared surface. SID %d.\n"
@@ -209,7 +210,7 @@ vmw_drm_gb_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;
vsrf->size = vmw_region_size(desc.region);
/*
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
index 2866a29..9c0abe9 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
@@ -37,6 +37,7 @@
#include "util/u_memory.h"
#include "util/u_math.h"
#include "svgadump/svga_dump.h"
+#include "state_tracker/drm_driver.h"
#include "vmw_screen.h"
#include "vmw_context.h"
#include "vmw_fence.h"
@@ -251,6 +252,63 @@ out_fail_create:
}
/**
+ * vmw_ioctl_surface_req - Fill in a struct surface_req
+ *
+ * @vws: Winsys screen
+ * @whandle: Surface handle
+ * @req: The struct surface req to fill in
+ * @needs_unref: This call takes a kernel surface reference that needs to
+ * be unreferenced.
+ *
+ * Returns 0 on success, negative error type otherwise.
+ * Fills in the surface_req structure according to handle type and kernel
+ * capabilities.
+ */
+static int
+vmw_ioctl_surface_req(const struct vmw_winsys_screen *vws,
+ const struct winsys_handle *whandle,
+ struct drm_vmw_surface_arg *req,
+ boolean *needs_unref)
+{
+ int ret;
+
+ switch(whandle->type) {
+ case DRM_API_HANDLE_TYPE_SHARED:
+ case DRM_API_HANDLE_TYPE_KMS:
+ *needs_unref = FALSE;
+ req->handle_type = DRM_VMW_HANDLE_LEGACY;
+ req->sid = whandle->handle;
+ break;
+ case DRM_API_HANDLE_TYPE_FD:
+ if (!vws->ioctl.have_drm_2_6) {
+ uint32_t handle;
+
+ 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 -EINVAL;
+ }
+
+ *needs_unref = TRUE;
+ req->handle_type = DRM_VMW_HANDLE_LEGACY;
+ req->sid = handle;
+ } else {
+ *needs_unref = FALSE;
+ req->handle_type = DRM_VMW_HANDLE_PRIME;
+ req->sid = whandle->handle;
+ }
+ break;
+ default:
+ vmw_error("Attempt to import unsupported handle type %d.\n",
+whandle->type);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/**
* vmw_ioctl_gb_surface_ref - Put a reference on a guest-backed surface and
* get surface information
*
@@ -266,16 +324,18 @@ out_fail_create:
*/
int
vmw_ioctl_gb_surface_ref(struct vmw_winsys_screen *vws,
-
Re: [Mesa-dev] [PATCH 1/2] winsys/svga: Update the vmwgfx_drm.h header to latest version from kernel
On Mon, Apr 7, 2014 at 11:50 AM, Thomas Hellstrom wrote:
> Cc: "10.1"
> Signed-off-by: Thomas Hellstrom
>
> ---
> src/gallium/winsys/svga/drm/vmwgfx_drm.h | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
Both patches are:
Reviewed-by: Jakob Bornecrantz
Cheers, Jakob.
>
> diff --git a/src/gallium/winsys/svga/drm/vmwgfx_drm.h
> b/src/gallium/winsys/svga/drm/vmwgfx_drm.h
> index e42b3f5..73ad205 100644
> --- a/src/gallium/winsys/svga/drm/vmwgfx_drm.h
> +++ b/src/gallium/winsys/svga/drm/vmwgfx_drm.h
> @@ -87,6 +87,16 @@
> #define DRM_VMW_PARAM_MAX_SURF_MEMORY 7
> #define DRM_VMW_PARAM_3D_CAPS_SIZE 8
> #define DRM_VMW_PARAM_MAX_MOB_MEMORY 9
> +#define DRM_VMW_PARAM_MAX_MOB_SIZE 10
> +
> +/**
> + * enum drm_vmw_handle_type - handle type for ref ioctls
> + *
> + */
> +enum drm_vmw_handle_type {
> + DRM_VMW_HANDLE_LEGACY = 0,
> + DRM_VMW_HANDLE_PRIME = 1
> +};
>
> /**
> * struct drm_vmw_getparam_arg
> @@ -176,6 +186,7 @@ struct drm_vmw_surface_create_req {
> * struct drm_wmv_surface_arg
> *
> * @sid: Surface id of created surface or surface to destroy or reference.
> + * @handle_type: Handle type for DRM_VMW_REF_SURFACE Ioctl.
> *
> * Output data from the DRM_VMW_CREATE_SURFACE Ioctl.
> * Input argument to the DRM_VMW_UNREF_SURFACE Ioctl.
> @@ -184,7 +195,7 @@ struct drm_vmw_surface_create_req {
>
> struct drm_vmw_surface_arg {
> int32_t sid;
> - uint32_t pad64;
> + enum drm_vmw_handle_type handle_type;
> };
>
> /**
> --
> 1.9.1
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xa: Bind destination before setting new state
Binding a new destination may cause the svga driver to emit draw calls
while propagating the surface. Make sure this doesn't happen in the middle
of sampler state setup where state may be incosistent.
In practice, surface propagation should never happen here and even if it did,
it wouldn't be a valid reason for the svga driver to emit partially set up
state, but to avoid future uncertainties, make sure this doesn't happen
anyway.
Found while auditing the state tracker for inconsistent sampler state /
sampler view setup.
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/xa/xa_renderer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_renderer.c
b/src/gallium/state_trackers/xa/xa_renderer.c
index b775509..d22851f 100644
--- a/src/gallium/state_trackers/xa/xa_renderer.c
+++ b/src/gallium/state_trackers/xa/xa_renderer.c
@@ -406,6 +406,9 @@ renderer_copy_prepare(struct xa_context *r,
PIPE_BIND_RENDER_TARGET));
(void)screen;
+renderer_bind_destination(r, dst_surface,
+ dst_surface->width, dst_surface->height);
+
/* set misc state we care about */
{
struct pipe_blend_state blend;
@@ -435,9 +438,6 @@ renderer_copy_prepare(struct xa_context *r,
cso_single_sampler_done(r->cso, PIPE_SHADER_FRAGMENT);
}
-renderer_bind_destination(r, dst_surface,
- dst_surface->width, dst_surface->height);
-
/* texture/sampler view */
{
struct pipe_sampler_view templ;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] util: Rework endian handling in python code
Ping. Richard Sandiford writes: > Ping (with fixed subject) > > Richard Sandiford writes: >> This is a refresh of: >> >>http://lists.freedesktop.org/archives/mesa-dev/2013-June/040594.html >> >> At the moment the python code uses sys.byteorder to decide whether >> u_format_table.c should be for big or little endian. With this series >> it instead generates both forms, using blocks like: >> >> #ifdef PIPE_ARCH_BIG_ENDIAN >> ... >> #else >> ... >> #endif >> >> in cases where endianness matters. >> >> Doing it this way is more cross-compiler-friendly. It also means people >> working on LE systems can see what the differences would be for BE. >> >> Tested on x86_64 and z. I don't have commit access so please apply if OK. >> >> Thanks, >> Richard >> >> ___ >> 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 mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium glsl: Fix crash with piglit fs-deref-literal-array-of-structs.shader_test
op 03-04-14 18:19, Marek Olšák schreef:
Acked-by: Marek Olšák
Nacked by self btw, the alternative fix below doesn't break other testcases.
The original fix did..
No idea why it is legal to move a constant struct/array here, but it appears to
pass all tests...
---
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index c3e36ec..18351a8 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -632,7 +632,10 @@ glsl_to_tgsi_visitor::get_opcode(ir_instruction *ir,
unsigned op,
st_src_reg src0, st_src_reg src1)
{
int type = GLSL_TYPE_FLOAT;
-
+
+ if (op == TGSI_OPCODE_MOV)
+ return op;
+
assert(src0.type != GLSL_TYPE_ARRAY);
assert(src0.type != GLSL_TYPE_STRUCT);
assert(src1.type != GLSL_TYPE_ARRAY);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xa: Bind destination before setting new state
On Mon, Apr 7, 2014 at 12:32 PM, Thomas Hellstrom wrote:
> Binding a new destination may cause the svga driver to emit draw calls
> while propagating the surface. Make sure this doesn't happen in the middle
> of sampler state setup where state may be incosistent.
>
> In practice, surface propagation should never happen here and even if it did,
> it wouldn't be a valid reason for the svga driver to emit partially set up
> state, but to avoid future uncertainties, make sure this doesn't happen
> anyway.
>
> Found while auditing the state tracker for inconsistent sampler state /
> sampler view setup.
>
> Signed-off-by: Thomas Hellstrom
> ---
> src/gallium/state_trackers/xa/xa_renderer.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Jakob Bornecrantz
Cheers, Jakob.
>
> diff --git a/src/gallium/state_trackers/xa/xa_renderer.c
> b/src/gallium/state_trackers/xa/xa_renderer.c
> index b775509..d22851f 100644
> --- a/src/gallium/state_trackers/xa/xa_renderer.c
> +++ b/src/gallium/state_trackers/xa/xa_renderer.c
> @@ -406,6 +406,9 @@ renderer_copy_prepare(struct xa_context *r,
>PIPE_BIND_RENDER_TARGET));
> (void)screen;
>
> +renderer_bind_destination(r, dst_surface,
> + dst_surface->width, dst_surface->height);
> +
> /* set misc state we care about */
> {
> struct pipe_blend_state blend;
> @@ -435,9 +438,6 @@ renderer_copy_prepare(struct xa_context *r,
> cso_single_sampler_done(r->cso, PIPE_SHADER_FRAGMENT);
> }
>
> -renderer_bind_destination(r, dst_surface,
> - dst_surface->width, dst_surface->height);
> -
> /* texture/sampler view */
> {
> struct pipe_sampler_view templ;
> --
> 1.9.1
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa/mesa] Hardcode the DRI driver extension as .so to match it's current uses.
On 06/04/2014 17:45, Emil Velikov wrote: > Sorry about this breakage. I assumed that the library extensions are handled > consistently across mesa. Seems like I was wrong. > > Guessing that you meant to send this to the mesa-dev ? Yes, sorry about that. > On 06/04/14 15:59, Jon TURNEY wrote: >> A similar fix is probably also needed for gallium DRI drivers. >> > Currently the only gallium related part is the "compatibility symlinks" > script, that is enabled only for linux. Thanks for the heads up :) That's the only place in gallium that LIB_EXT is used, but a '-shrext .so' is needed somewhere (in GALLIUM_DRI_LINKER_FLAGS?) so that the gallium DRI drivers are built with names matching those hardcoded into the loader. >> (Consider that if we were starting from scratch, perhaps we would use a >> custom >> extension like .dri instead) >> > IMHO if we're starting from scratch we should use the platform specific > extensions consistently but neither suggestion matter in this case :'( Can you explain your reasoning? This seems to me to be a foolish consistency. For libraries which are only ever used with dlopen() and are not intended to be linked with (i.e. have some sort of plug-in style interface), there is no advantage to using the platform's default shared library extension, and it introduces extra platform dependent code to determine the library name when the library is used. > With that said the patch is > Reviewed-by: Emil Velikov Thanks. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/9] glsl: Make is_16bit_constant from i965 an ir_constant method.
On Mon, Apr 7, 2014 at 2:49 AM, Kenneth Graunke wrote:
> The i965 MUL instruction doesn't natively support 32-bit by 32-bit
> integer multiplication; additional instructions (MACH/MOV) are required.
> However, we can avoid those if we know one of the operands can be
> represented in 16 bits or less. The vector backend's is_16bit_constant
> static helper function checks for this.
>
> We want to be able to use it in the scalar backend as well, which means
> moving the function to a more generally-usable location. Since it isn't
> i965 specific, I decided to make it an ir_constant method, in case it
> ends up being useful to other people as well.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/glsl/ir.cpp| 9 +
> src/glsl/ir.h | 11 +++
> src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 18 ++
> 3 files changed, 22 insertions(+), 16 deletions(-)
>
> diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
> index a41eddf..07c0a9b 100644
> --- a/src/glsl/ir.cpp
> +++ b/src/glsl/ir.cpp
> @@ -1223,6 +1223,15 @@ ir_constant::is_basis() const
> return ones == 1;
> }
>
> +bool
> +ir_constant::is_16bit_integer_constant() const
Perhaps make this is_uint16_constant? Otherwise one might assume based
on the name that it would return true for a value like -1.
> +{
> + if (!type->is_integer())
> + return false;
> +
> + return value.u[0] < (1 << 16);
> +}
> +
> ir_loop::ir_loop()
> {
> this->ir_type = ir_type_loop;
> diff --git a/src/glsl/ir.h b/src/glsl/ir.h
> index ee276d2..862eddc 100644
> --- a/src/glsl/ir.h
> +++ b/src/glsl/ir.h
> @@ -265,6 +265,12 @@ public:
> */
> virtual bool is_basis() const;
>
> + /**
> +* Determine if an r-value is an integer constant that fits in 16 bits.
> +*
> +* \sa ir_constant::is_16bit_integer_constant.
> +*/
> + virtual bool is_16bit_integer_constant() const { return false; }
>
> /**
> * Return a generic value of error_type.
> @@ -2165,6 +2171,11 @@ public:
> virtual bool is_basis() const;
>
> /**
> +* Return true for integer constants which can be represented in 16 bits.
> +*/
> + virtual bool is_16bit_integer_constant() const;
> +
> + /**
> * Value of the constant.
> *
> * The field used to back the values supplied by the constant is
> determined
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> index c73e58d..3df1c9b 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> @@ -1174,20 +1174,6 @@ vec4_visitor::emit_lrp(const dst_reg &dst,
> }
> }
>
> -static bool
> -is_16bit_constant(ir_rvalue *rvalue)
> -{
> - ir_constant *constant = rvalue->as_constant();
> - if (!constant)
> - return false;
> -
> - if (constant->type != glsl_type::int_type &&
> - constant->type != glsl_type::uint_type)
> - return false;
> -
> - return constant->value.u[0] < (1 << 16);
> -}
> -
> void
> vec4_visitor::visit(ir_expression *ir)
> {
> @@ -1371,12 +1357,12 @@ vec4_visitor::visit(ir_expression *ir)
> * operand. If we can determine that one of the args is in the low
> * 16 bits, though, we can just emit a single MUL.
>*/
> - if (is_16bit_constant(ir->operands[0])) {
> + if (ir->operands[0]->is_16bit_integer_constant()) {
> if (brw->gen < 7)
> emit(MUL(result_dst, op[0], op[1]));
> else
> emit(MUL(result_dst, op[1], op[0]));
> - } else if (is_16bit_constant(ir->operands[1])) {
> + } else if (ir->operands[1]->is_16bit_integer_constant()) {
> if (brw->gen < 7)
> emit(MUL(result_dst, op[1], op[0]));
> else
> --
> 1.9.0
>
> ___
> 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 2/2] st/xa: Move version information into a single place
Previously the version was specified in configure.ac as well as one of the xa headers. Thus incleasing the risk of discrepancies when a developer bumps one but forgets about the other. Currently only automake builds the xa state-tracker + targets, and we should move the version definitions to a build system independent file (similar to VERSION) once any of the other two decide to join the fun. Cc: Thomas Hellstrom Signed-off-by: Emil Velikov --- src/gallium/state_trackers/xa/Makefile.am | 6 +- src/gallium/state_trackers/xa/xa_tracker.h | 4 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/gallium/state_trackers/xa/Makefile.am b/src/gallium/state_trackers/xa/Makefile.am index 72486b9..d24fcd4 100644 --- a/src/gallium/state_trackers/xa/Makefile.am +++ b/src/gallium/state_trackers/xa/Makefile.am @@ -26,7 +26,11 @@ include $(top_srcdir)/src/gallium/Automake.inc AM_CFLAGS = \ -Wall -pedantic \ $(GALLIUM_CFLAGS) \ - $(VISIBILITY_CFLAGS) + $(VISIBILITY_CFLAGS) \ + -DXA_TRACKER_VERSION_MAJOR=$(XA_MAJOR) \ + -DXA_TRACKER_VERSION_MINOR=$(XA_MINOR) \ + -DXA_TRACKER_VERSION_PATCH=$(XA_TINY) + AM_CPPFLAGS = \ $(GALLIUM_PIPE_LOADER_DEFINES) \ diff --git a/src/gallium/state_trackers/xa/xa_tracker.h b/src/gallium/state_trackers/xa/xa_tracker.h index 43e56ff..74ee878 100644 --- a/src/gallium/state_trackers/xa/xa_tracker.h +++ b/src/gallium/state_trackers/xa/xa_tracker.h @@ -36,10 +36,6 @@ #include -#define XA_TRACKER_VERSION_MAJOR 2 -#define XA_TRACKER_VERSION_MINOR 1 -#define XA_TRACKER_VERSION_PATCH 0 - #define XA_FLAG_SHARED (1 << 0) #define XA_FLAG_RENDER_TARGET (1 << 1) #define XA_FLAG_SCANOUT(1 << 2) -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] Revert "st/xa: Fix advertized version number and try to avoid future discrepancies"
Parsing source files through build systems is never a good idea.
Especially when the issue can be resolved by adding a couple of
definitions to CPPFLAGS via the build system.
This reverts commit 61bedc3d6b08943f015f9d590c07a6af36c2a92c.
Cc: Thomas Hellstrom
---
Seems like I was a bit too quick to call it out, although IMHO we
should avoid making things more convoluted than what they already
are.
Cheers
Emil
configure.ac | 1 -
src/gallium/state_trackers/xa/xa_tracker.h| 200 ++
src/gallium/state_trackers/xa/xa_tracker.h.in | 200 --
3 files changed, 200 insertions(+), 201 deletions(-)
create mode 100644 src/gallium/state_trackers/xa/xa_tracker.h
delete mode 100644 src/gallium/state_trackers/xa/xa_tracker.h.in
diff --git a/configure.ac b/configure.ac
index ee5c2d1..d182a39 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2063,7 +2063,6 @@ AC_CONFIG_FILES([Makefile
src/gallium/state_trackers/vdpau/Makefile
src/gallium/state_trackers/vega/Makefile
src/gallium/state_trackers/xa/Makefile
-src/gallium/state_trackers/xa/xa_tracker.h
src/gallium/state_trackers/xvmc/Makefile
src/gallium/targets/Makefile
src/gallium/targets/dri-freedreno/Makefile
diff --git a/src/gallium/state_trackers/xa/xa_tracker.h
b/src/gallium/state_trackers/xa/xa_tracker.h
new file mode 100644
index 000..43e56ff
--- /dev/null
+++ b/src/gallium/state_trackers/xa/xa_tracker.h
@@ -0,0 +1,200 @@
+/**
+ * Copyright 2009-2011 VMware, Inc. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy,
+ * modify, merge, publish, distribute, sublicense, and/or sell copies
+ * of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ * The format encoding idea is partially borrowed from libpixman, but it is not
+ * considered a "substantial part of the software", so the pixman copyright
+ * is left out for simplicity, and acknowledgment is instead given in this way.
+ *
+ *
+ * Authors:
+ * Zack Rusin
+ * Thomas Hellstrom
+ */
+
+#ifndef _XA_TRACKER_H_
+#define _XA_TRACKER_H_
+
+#include
+
+#define XA_TRACKER_VERSION_MAJOR 2
+#define XA_TRACKER_VERSION_MINOR 1
+#define XA_TRACKER_VERSION_PATCH 0
+
+#define XA_FLAG_SHARED (1 << 0)
+#define XA_FLAG_RENDER_TARGET (1 << 1)
+#define XA_FLAG_SCANOUT(1 << 2)
+
+#define XA_MAP_READ (1 << 0)
+#define XA_MAP_WRITE(1 << 1)
+#define XA_MAP_MAP_DIRECTLY (1 << 2)
+#define XA_MAP_UNSYNCHRONIZED (1 << 3)
+#define XA_MAP_DONTBLOCK(1 << 4)
+#define XA_MAP_DISCARD_WHOLE_RESOURCE (1 << 5)
+
+#define XA_ERR_NONE0
+#define XA_ERR_NORES 1
+#define XA_ERR_INVAL 2
+#define XA_ERR_BUSY3
+
+enum xa_surface_type {
+xa_type_other,
+xa_type_a,
+xa_type_argb,
+xa_type_abgr,
+xa_type_bgra,
+xa_type_z,
+xa_type_zs,
+xa_type_sz,
+xa_type_yuv_component
+};
+
+/*
+ * Note that these formats should not be assumed to be binary compatible with
+ * pixman formats, but with the below macros and a format type map,
+ * conversion should be simple. Macros for now. We might replace with
+ * inline functions.
+ */
+
+#define xa_format(bpp,type,a,r,g,b)(((bpp) << 24) | \
+((type) << 16) | \
+((a) << 12) |\
+((r) << 8) | \
+((g) << 4) | \
+((b)))
+/*
+ * Non-RGBA one- and two component formats.
+ */
+
+#define xa_format_c(bpp,type,c1,c2) (((bpp) << 24) | \
+((type) << 16) | \
+((c1) << 8) |\
+((c2)))
+#d
[Mesa-dev] [PATCH] nouveau: fix firmware check on nvd7/nvd9
The kernel driver expects the class to be based on chipset generation
rather than VP generation. Make sure to pass 90b1 for NVDX chipsets
instead of 95b1.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77102
Fixes: 40dd777b33073
Signed-off-by: Ilia Mirkin
Cc: "10.1 10.0"
---
src/gallium/drivers/nouveau/nouveau_vp3_video.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video.c
b/src/gallium/drivers/nouveau/nouveau_vp3_video.c
index 11cf729..f3a64b2 100644
--- a/src/gallium/drivers/nouveau/nouveau_vp3_video.c
+++ b/src/gallium/drivers/nouveau/nouveau_vp3_video.c
@@ -371,10 +371,10 @@ firmware_present(struct pipe_screen *pscreen, enum
pipe_video_profile profile)
int size, oclass;
if (chipset < 0xc0)
oclass = 0x85b1;
- else if (vp5)
- oclass = 0x95b1;
- else
+ else if (chipset < 0xe0)
oclass = 0x90b1;
+ else
+ oclass = 0x95b1;
if (chipset < 0xc0) {
data = &nv04_data;
--
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 1/2] winsys/svga: Update the vmwgfx_drm.h header to latest version from kernel
On 07/04/14 10:50, Thomas Hellstrom wrote:
> Cc: "10.1"
> Signed-off-by: Thomas Hellstrom
Rather silly question:
Why do you guys pull this header inside mesa and over using the one provided
by libdrm ? AFAICS every other driver seems to do the latter.
-Emil
> ---
> src/gallium/winsys/svga/drm/vmwgfx_drm.h | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/winsys/svga/drm/vmwgfx_drm.h
> b/src/gallium/winsys/svga/drm/vmwgfx_drm.h
> index e42b3f5..73ad205 100644
> --- a/src/gallium/winsys/svga/drm/vmwgfx_drm.h
> +++ b/src/gallium/winsys/svga/drm/vmwgfx_drm.h
> @@ -87,6 +87,16 @@
> #define DRM_VMW_PARAM_MAX_SURF_MEMORY 7
> #define DRM_VMW_PARAM_3D_CAPS_SIZE 8
> #define DRM_VMW_PARAM_MAX_MOB_MEMORY 9
> +#define DRM_VMW_PARAM_MAX_MOB_SIZE 10
> +
> +/**
> + * enum drm_vmw_handle_type - handle type for ref ioctls
> + *
> + */
> +enum drm_vmw_handle_type {
> + DRM_VMW_HANDLE_LEGACY = 0,
> + DRM_VMW_HANDLE_PRIME = 1
> +};
>
> /**
> * struct drm_vmw_getparam_arg
> @@ -176,6 +186,7 @@ struct drm_vmw_surface_create_req {
> * struct drm_wmv_surface_arg
> *
> * @sid: Surface id of created surface or surface to destroy or reference.
> + * @handle_type: Handle type for DRM_VMW_REF_SURFACE Ioctl.
> *
> * Output data from the DRM_VMW_CREATE_SURFACE Ioctl.
> * Input argument to the DRM_VMW_UNREF_SURFACE Ioctl.
> @@ -184,7 +195,7 @@ struct drm_vmw_surface_create_req {
>
> struct drm_vmw_surface_arg {
> int32_t sid;
> - uint32_t pad64;
> + enum drm_vmw_handle_type handle_type;
> };
>
> /**
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] Revert "st/xa: Fix advertized version number and try to avoid future discrepancies"
On 04/07/2014 02:44 PM, Emil Velikov wrote: > Parsing source files through build systems is never a good idea. > Especially when the issue can be resolved by adding a couple of > definitions to CPPFLAGS via the build system. I've nothing against reverting the commit, but the log message is incorrect, xa_tracker.h is an installed header and thus must include the correct defines. (see my commit message). If we don't parse it using autoconf, we need to use sed or some other tool to fix the header. Otherwise Acked-by: Thomas Hellstrom /Thomas > > This reverts commit 61bedc3d6b08943f015f9d590c07a6af36c2a92c. > > Cc: Thomas Hellstrom > --- > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/xa: Move version information into a single place
On 04/07/2014 02:44 PM, Emil Velikov wrote: > Previously the version was specified in configure.ac as well as > one of the xa headers. Thus incleasing the risk of discrepancies > when a developer bumps one but forgets about the other. > > Currently only automake builds the xa state-tracker + targets, > and we should move the version definitions to a build system > independent file (similar to VERSION) once any of the other two > decide to join the fun. > > Cc: Thomas Hellstrom > Signed-off-by: Emil Velikov Hi! nak. The users of libxatracker expects to find those defines in the header. /Thomas > --- > src/gallium/state_trackers/xa/Makefile.am | 6 +- > src/gallium/state_trackers/xa/xa_tracker.h | 4 > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/src/gallium/state_trackers/xa/Makefile.am > b/src/gallium/state_trackers/xa/Makefile.am > index 72486b9..d24fcd4 100644 > --- a/src/gallium/state_trackers/xa/Makefile.am > +++ b/src/gallium/state_trackers/xa/Makefile.am > @@ -26,7 +26,11 @@ include $(top_srcdir)/src/gallium/Automake.inc > AM_CFLAGS = \ > -Wall -pedantic \ > $(GALLIUM_CFLAGS) \ > - $(VISIBILITY_CFLAGS) > + $(VISIBILITY_CFLAGS) \ > + -DXA_TRACKER_VERSION_MAJOR=$(XA_MAJOR) \ > + -DXA_TRACKER_VERSION_MINOR=$(XA_MINOR) \ > + -DXA_TRACKER_VERSION_PATCH=$(XA_TINY) > + > > AM_CPPFLAGS = \ > $(GALLIUM_PIPE_LOADER_DEFINES) \ > diff --git a/src/gallium/state_trackers/xa/xa_tracker.h > b/src/gallium/state_trackers/xa/xa_tracker.h > index 43e56ff..74ee878 100644 > --- a/src/gallium/state_trackers/xa/xa_tracker.h > +++ b/src/gallium/state_trackers/xa/xa_tracker.h > @@ -36,10 +36,6 @@ > > #include > > -#define XA_TRACKER_VERSION_MAJOR 2 > -#define XA_TRACKER_VERSION_MINOR 1 > -#define XA_TRACKER_VERSION_PATCH 0 > - > #define XA_FLAG_SHARED (1 << 0) > #define XA_FLAG_RENDER_TARGET (1 << 1) > #define XA_FLAG_SCANOUT(1 << 2) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 10.2 release plan strawman
On 04/04/2014 05:52 PM, Matt Turner wrote: > On Fri, Apr 4, 2014 at 5:18 PM, Ian Romanick wrote: >> Fast forwarding 3 months from the 10.1 release (March 4th, planned for >> February 28th) is May 30th. I'd like to propose the following set of dates: >> >> May 2nd: Feature freeze / 10.2 branch created. >> >> May 16th: RC1 > > Same comment as last time. It's not clear to me that we need a week > between the branch and RC1. We're not going to get users testing the > branch until there's an RC that distros can offer. The thinking behind having some gap is that a lot of people don't change from feature work to bug fixing until the branch is made. There are usually a bunch of bug fixes landed right after the branch is made... there's also often a bunch of... chaos right before the branch is made. Having an RC that doesn't build, has lot of known bugs, etc is useless. Having a time gap between features landing and making RC1 allows things to settle down a bit. I thought your complaint before was that a week wasn't long enough. That's why I bumped it to two weeks this time. I guess I must have misunderstood the concern. > Also, for XWayland glamor-based acceleration, the X Server needs a > release of Mesa it can depend on. I'm Cc'ing Keith and Kristian who > can fill in more details. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/vec4: fix record clearing in copy propagation
On 04/06/2014 09:31 PM, Chia-I Wu wrote:
> From: Chia-I Wu
>
> Given
>
> mov vgrf7, vgrf9.xyxz
> add vgrf9.xyz, vgrf4.xyzw, vgrf5.xyzw
> add vgrf10.x, vgrf6.xyzw, vgrf7.
>
> the last instruction would be wrongly changed to
>
> add vgrf10.x, vgrf6.xyzw, vgrf9.
>
> during copy propagation.
>
> The issue is that when deciding if a record should be cleared, the old code
> checked for
>
> inst->dst.writemask & (1 << ch)
>
> instead of
>
> inst->dst.writemask & (1 << BRW_GET_SWZ(src->swizzle, ch))
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76749
> Signed-off-by: Chia-I Wu
> Cc: Jordan Justen
> Cc: Matt Turner
Mark for stable? It looks like the same code exists in the 10.1 branch.
The fix looks correct to me, but you should wait for Matt, Eric, or Ken
to comment as well.
Reviewed-by: Ian Romainck
> ---
> .../drivers/dri/i965/brw_vec4_copy_propagation.cpp | 21
> -
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> index 3d68f0e..83cf191 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> @@ -58,6 +58,21 @@ is_dominated_by_previous_instruction(vec4_instruction
> *inst)
> }
>
> static bool
> +is_channel_updated(vec4_instruction *inst, src_reg *values[4], int ch)
> +{
> + const src_reg *src = values[ch];
> +
> + /* consider GRF only */
> + assert(inst->dst.file == GRF);
> + if (!src || src->file != GRF)
> + return false;
> +
> + return (src->reg == inst->dst.reg &&
> +src->reg_offset == inst->dst.reg_offset &&
> +inst->dst.writemask & (1 << BRW_GET_SWZ(src->swizzle, ch)));
> +}
> +
> +static bool
> try_constant_propagation(vec4_instruction *inst, int arg, src_reg *values[4])
> {
> /* For constant propagation, we only handle the same constant
> @@ -357,11 +372,7 @@ vec4_visitor::opt_copy_propagation()
>else {
> for (int i = 0; i < virtual_grf_reg_count; i++) {
> for (int j = 0; j < 4; j++) {
> - if (inst->dst.writemask & (1 << j) &&
> - cur_value[i][j] &&
> - cur_value[i][j]->file == GRF &&
> - cur_value[i][j]->reg == inst->dst.reg &&
> - cur_value[i][j]->reg_offset == inst->dst.reg_offset) {
> + if (is_channel_updated(inst, cur_value[i], j)){
>cur_value[i][j] = NULL;
> }
> }
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] winsys/svga: Update the vmwgfx_drm.h header to latest version from kernel
On 04/07/2014 02:49 PM, Emil Velikov wrote: > On 07/04/14 10:50, Thomas Hellstrom wrote: >> Cc: "10.1" >> Signed-off-by: Thomas Hellstrom > Rather silly question: > > Why do you guys pull this header inside mesa and over using the one provided > by libdrm ? AFAICS every other driver seems to do the latter. Basically to avoid a new release of libdrm when we change the header. There is no other vmware-specific libdrm code... Thanks, Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/9] glsl: Make is_16bit_constant from i965 an ir_constant method.
On 04/06/2014 11:49 PM, Kenneth Graunke wrote:
> The i965 MUL instruction doesn't natively support 32-bit by 32-bit
> integer multiplication; additional instructions (MACH/MOV) are required.
> However, we can avoid those if we know one of the operands can be
> represented in 16 bits or less. The vector backend's is_16bit_constant
> static helper function checks for this.
In IVB+ the hardware actually does 32-bit by 16-bit to give a 48-bit
result (on SNB and earlier it's 16-bit by 16-bit... yay). According to
Emil Persson, new generation consoles have similar (but different)
integer multiplication issues (see slide 35 from
http://www.humus.name/index.php?page=Comments&ID=371). Should we expose
a lesser precision integer multiply function similar to mul24()?
> We want to be able to use it in the scalar backend as well, which means
> moving the function to a more generally-usable location. Since it isn't
> i965 specific, I decided to make it an ir_constant method, in case it
> ends up being useful to other people as well.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/glsl/ir.cpp| 9 +
> src/glsl/ir.h | 11 +++
> src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 18 ++
> 3 files changed, 22 insertions(+), 16 deletions(-)
>
> diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
> index a41eddf..07c0a9b 100644
> --- a/src/glsl/ir.cpp
> +++ b/src/glsl/ir.cpp
> @@ -1223,6 +1223,15 @@ ir_constant::is_basis() const
> return ones == 1;
> }
>
> +bool
> +ir_constant::is_16bit_integer_constant() const
> +{
> + if (!type->is_integer())
> + return false;
> +
> + return value.u[0] < (1 << 16);
> +}
> +
> ir_loop::ir_loop()
> {
> this->ir_type = ir_type_loop;
> diff --git a/src/glsl/ir.h b/src/glsl/ir.h
> index ee276d2..862eddc 100644
> --- a/src/glsl/ir.h
> +++ b/src/glsl/ir.h
> @@ -265,6 +265,12 @@ public:
> */
> virtual bool is_basis() const;
>
> + /**
> +* Determine if an r-value is an integer constant that fits in 16 bits.
> +*
> +* \sa ir_constant::is_16bit_integer_constant.
> +*/
> + virtual bool is_16bit_integer_constant() const { return false; }
>
> /**
> * Return a generic value of error_type.
> @@ -2165,6 +2171,11 @@ public:
> virtual bool is_basis() const;
>
> /**
> +* Return true for integer constants which can be represented in 16 bits.
> +*/
> + virtual bool is_16bit_integer_constant() const;
> +
> + /**
> * Value of the constant.
> *
> * The field used to back the values supplied by the constant is
> determined
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> index c73e58d..3df1c9b 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> @@ -1174,20 +1174,6 @@ vec4_visitor::emit_lrp(const dst_reg &dst,
> }
> }
>
> -static bool
> -is_16bit_constant(ir_rvalue *rvalue)
> -{
> - ir_constant *constant = rvalue->as_constant();
> - if (!constant)
> - return false;
> -
> - if (constant->type != glsl_type::int_type &&
> - constant->type != glsl_type::uint_type)
> - return false;
> -
> - return constant->value.u[0] < (1 << 16);
> -}
> -
> void
> vec4_visitor::visit(ir_expression *ir)
> {
> @@ -1371,12 +1357,12 @@ vec4_visitor::visit(ir_expression *ir)
> * operand. If we can determine that one of the args is in the low
> * 16 bits, though, we can just emit a single MUL.
>*/
> - if (is_16bit_constant(ir->operands[0])) {
> + if (ir->operands[0]->is_16bit_integer_constant()) {
> if (brw->gen < 7)
> emit(MUL(result_dst, op[0], op[1]));
> else
> emit(MUL(result_dst, op[1], op[0]));
> - } else if (is_16bit_constant(ir->operands[1])) {
> + } else if (ir->operands[1]->is_16bit_integer_constant()) {
> if (brw->gen < 7)
> emit(MUL(result_dst, op[1], op[0]));
> else
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] glsl: Pass ctx->Const.NativeIntegers to do_common_optimization().
On 04/06/2014 11:49 PM, Kenneth Graunke wrote: > diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp > index 3bf2789..d8edc95 100644 > --- a/src/glsl/linker.cpp > +++ b/src/glsl/linker.cpp > @@ -2298,7 +2298,7 @@ link_shaders(struct gl_context *ctx, struct > gl_shader_program *prog) > >unsigned max_unroll = > ctx->ShaderCompilerOptions[i].MaxUnrollIterations; > > - while (do_common_optimization(prog->_LinkedShaders[i]->ir, true, > false, max_unroll, &ctx->ShaderCompilerOptions[i])) > + while (do_common_optimization(prog->_LinkedShaders[i]->ir, true, > false, max_unroll, &ctx->ShaderCompilerOptions[i], ctx->Const.NativeIntegers)) I think now is a good opportunity to wrap this long line. :) >; > } > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Partially revert "st/xa: Fix advertized version number and try to avoid future discrepancies"
This reverts commit 61bedc3d6b08943f015f9d590c07a6af36c2a92c. As the header is the one defining the API/ABI and is distributed during installation, we should be using it rather than re-defining the XA version in configure.ac. Bump the version in the header to 2.2.0, to reflect what was the original intent of commit 42158926c6d7d3ddbe61b9a04d60544ff1b50a96. Cc: Thomas Hellstrom Signed-off-by: Emil Velikov --- Yikes, thanks for the reminder Thomas. I've completely missed the "xa_tracker is installed header" part. Considering that we already have a cannonical place where the version is defined, one can simply use it (be that a build system or not). IMHO this approach looks alot better. Hopefully I did not miss something this time. Emil configure.ac | 12 +- src/gallium/state_trackers/xa/xa_tracker.h| 200 ++ src/gallium/state_trackers/xa/xa_tracker.h.in | 200 -- 3 files changed, 208 insertions(+), 204 deletions(-) create mode 100644 src/gallium/state_trackers/xa/xa_tracker.h delete mode 100644 src/gallium/state_trackers/xa/xa_tracker.h.in diff --git a/configure.ac b/configure.ac index ee5c2d1..1a3ef87 100644 --- a/configure.ac +++ b/configure.ac @@ -2000,9 +2000,14 @@ AC_SUBST([VDPAU_MINOR], 0) AC_SUBST([XVMC_MAJOR], 1) AC_SUBST([XVMC_MINOR], 0) -AC_SUBST([XA_MAJOR], 2) -AC_SUBST([XA_MINOR], 2) -AC_SUBST([XA_TINY], 0) +XA_HEADER="$srcdir/src/gallium/state_trackers/xa/xa_tracker.h" +XA_MAJOR=`grep "#define XA_TRACKER_VERSION_MAJOR" $XA_HEADER | $SED 's/^#define XA_TRACKER_VERSION_MAJOR //'` +XA_MINOR=`grep "#define XA_TRACKER_VERSION_MINOR" $XA_HEADER | $SED 's/^#define XA_TRACKER_VERSION_MINOR //'` +XA_TINY=`grep "#define XA_TRACKER_VERSION_PATCH" $XA_HEADER | $SED 's/^#define XA_TRACKER_VERSION_PATCH //'` + +AC_SUBST([XA_MAJOR], $XA_MAJOR) +AC_SUBST([XA_MINOR], $XA_MINOR) +AC_SUBST([XA_TINY], $XA_TINY) AC_SUBST([XA_VERSION], "$XA_MAJOR.$XA_MINOR.$XA_TINY") dnl Restore LDFLAGS and CPPFLAGS @@ -2063,7 +2068,6 @@ AC_CONFIG_FILES([Makefile src/gallium/state_trackers/vdpau/Makefile src/gallium/state_trackers/vega/Makefile src/gallium/state_trackers/xa/Makefile -src/gallium/state_trackers/xa/xa_tracker.h src/gallium/state_trackers/xvmc/Makefile src/gallium/targets/Makefile src/gallium/targets/dri-freedreno/Makefile diff --git a/src/gallium/state_trackers/xa/xa_tracker.h b/src/gallium/state_trackers/xa/xa_tracker.h new file mode 100644 index 000..5c6435e --- /dev/null +++ b/src/gallium/state_trackers/xa/xa_tracker.h @@ -0,0 +1,200 @@ +/** + * Copyright 2009-2011 VMware, Inc. All rights reserved. + * + * Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, copy, + * modify, merge, publish, distribute, sublicense, and/or sell copies + * of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be + * included in all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE + * SOFTWARE. + * + * The format encoding idea is partially borrowed from libpixman, but it is not + * considered a "substantial part of the software", so the pixman copyright + * is left out for simplicity, and acknowledgment is instead given in this way. + * + * + * Authors: + * Zack Rusin + * Thomas Hellstrom + */ + +#ifndef _XA_TRACKER_H_ +#define _XA_TRACKER_H_ + +#include + +#define XA_TRACKER_VERSION_MAJOR 2 +#define XA_TRACKER_VERSION_MINOR 2 +#define XA_TRACKER_VERSION_PATCH 0 + +#define XA_FLAG_SHARED (1 << 0) +#define XA_FLAG_RENDER_TARGET (1 << 1) +#define XA_FLAG_SCANOUT(1 << 2) + +#define XA_MAP_READ (1 << 0) +#define XA_MAP_WRITE(1 << 1) +#define XA_MAP_MAP_DIRECTLY (1 << 2) +#define XA_MAP_UNSYNCHRONIZED (1 << 3) +#define XA_MAP_DONTBLOCK(1 << 4) +#define XA_MAP_DISCARD_WHOLE_RESOURCE (1 << 5) + +#define XA_ERR_NONE0 +#define XA_ERR_NORES 1 +#define XA_ERR_INVAL 2 +#define XA_E
Re: [Mesa-dev] [PATCH 9/9] glsl: Convert mul/div by power-of-two factors to shift expressions.
On 04/06/2014 11:49 PM, Kenneth Graunke wrote:
> Integer shifts are basically always well supported and efficient; that
> isn't always true of integer division, and sometimes even integer
> multiplication isn't without issues.
>
> On some Intel hardware, INTDIV can't be used in SIMD16 mode. It also
> doesn't support immediate operands (on any generation), while ASR can.
>
> On Haswell, this cuts the number of instructions in dolphin/efb2ram by
> 7.94%. It also removes a single MOV in dolphin/realxfb (due to ASR
> supporting immediates), and gains SIMD16 support (due to no INTDIV).
>
> Signed-off-by: Kenneth Graunke
> ---
> src/glsl/opt_algebraic.cpp | 70
> --
> 1 file changed, 68 insertions(+), 2 deletions(-)
>
> diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
> index 9d55392..eccc2eb 100644
> --- a/src/glsl/opt_algebraic.cpp
> +++ b/src/glsl/opt_algebraic.cpp
> @@ -34,6 +34,7 @@
> #include "ir_optimization.h"
> #include "ir_builder.h"
> #include "glsl_types.h"
> +#include "main/macros.h"
>
> using namespace ir_builder;
>
> @@ -68,6 +69,8 @@ public:
>int op2);
> ir_rvalue *swizzle_if_required(ir_expression *expr,
> ir_rvalue *operand);
> + ir_rvalue *convert_int_math_to_shifts(ir_expression *ir,
> + ir_constant *op_const_array[4]);
>
> void *mem_ctx;
>
> @@ -185,6 +188,59 @@ ir_algebraic_visitor::reassociate_constant(ir_expression
> *ir1, int const_index,
> return false;
> }
>
> +/**
> + * Transform integer multiplication/division by a constant power-of-two
> + * factor into shift instructions.
> + */
> +ir_rvalue *
> +ir_algebraic_visitor::convert_int_math_to_shifts(ir_expression *ir,
> + ir_constant
> *op_const_array[4])
> +{
> + /* This optimization only makes sense for GPUs with native integers. */
> + if (!native_integers)
> + return NULL;
> +
> + assert(ir->operation == ir_binop_mul || ir->operation == ir_binop_div);
> +
> + /* Shifts only work for integer types. */
> + if (!ir->type->is_integer())
> + return NULL;
After the previous conversation about converting division to shifts, I
think at least division only generally works for unsigned. -1 / 2 => 0,
but -1 >> 1 => -1. I don't know what the rules are for multiplication
overflow... I think the result of int32_t(0x7000)*2 is undefined, so
that should be fine.
> +
> + ir_constant *const_op;
> + ir_rvalue *other_op;
> + if (op_const_array[0]) {
> + const_op = op_const_array[0];
> + other_op = ir->operands[1];
> + } else if (op_const_array[1]) {
> + const_op = op_const_array[1];
> + other_op = ir->operands[0];
> + } else {
> + /* If neither is a constant, we can't check for powers of two. */
> + return NULL;
> + }
> +
> + ir_constant_data shift_data;
> + for (int i = 0; i < const_op->type->vector_elements; i++) {
> + if (const_op->type->base_type == GLSL_TYPE_INT &&
> + const_op->value.i[i] <= 0) {
> + /* Negative values aren't powers of two. */
> + return NULL;
> + }
But... we could convert x*-4 into -x*4... assuming negation is free on
integer operands. Seems like that would be good follow-on work...
> +
> + if (!is_power_of_two(const_op->value.u[i]))
> + return NULL;
> +
> + shift_data.u[i] = ffs(const_op->value.u[i]) - 1;
> + }
> +
> + ir_constant *shifts = new(mem_ctx) ir_constant(ir->type, &shift_data);
> +
> + if (ir->operation == ir_binop_mul)
> + return lshift(other_op, shifts);
> + else
> + return rshift(other_op, shifts);
> +}
> +
> /* When eliminating an expression and just returning one of its operands,
> * we may need to swizzle that operand out to a vector if the expression was
> * vector type.
> @@ -389,7 +445,7 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
>return ir->operands[0];
>break;
>
> - case ir_binop_mul:
> + case ir_binop_mul: {
>if (is_vec_one(op_const[0]))
>return ir->operands[1];
>if (is_vec_one(op_const[1]))
> @@ -403,6 +459,9 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
>if (is_vec_negative_one(op_const[1]))
> return neg(ir->operands[0]);
>
> + ir_rvalue *shift_expr = convert_int_math_to_shifts(ir, op_const);
> + if (shift_expr)
> + return shift_expr;
>
>/* Reassociate multiplication of constants so that we can do
> * constant folding.
> @@ -413,8 +472,9 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
>reassociate_constant(ir, 1, op_const[1], op_expr[0]);
>
>break;
> + }
>
> - case ir_binop_div:
> + case ir_binop_div: {
>if (is_vec_one(op_const[0]) && ir->type->base_type == GLSL_TYPE_FLOAT)
> {
>return new(mem_ctx) ir_expression(ir_u
Re: [Mesa-dev] [PATCH 1/9] i965: Fix "SIMD16 unsupported" messages via KHR_debug.
I made a couple random comments on several patches. I also like Ilia's
suggestion on patch 3.
Patches 1 through 8 (with Ilia's suggestion on 3) are
Reviewed-by: Ian Romanick
I think patch 9 still needs some work for signed numerator handling in
division.
On 04/06/2014 11:49 PM, Kenneth Graunke wrote:
> Performance warnings are logged via KHR_debug in addition to when the
> INTEL_DEBUG=perf environment variable is set. Without this, messages in
> debug contexts would have "(null)" for the reason.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index ad9c1f5..7eac9ad 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -697,7 +697,7 @@ fs_visitor::no16(const char *format, ...)
> } else {
>simd16_unsupported = true;
>
> - if (INTEL_DEBUG & DEBUG_PERF) {
> + if (brw->perf_debug) {
> if (no16_msg)
> ralloc_vasprintf_append(&no16_msg, format, va);
> else
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [WIP 11/13] glsl: parser changes for GL_ARB_explicit_uniform_location
On 04/06/2014 10:27 PM, Tapani Pälli wrote:
> On 04/05/2014 12:58 AM, Ian Romanick wrote:
>> On 04/04/2014 02:42 PM, Ian Romanick wrote:
>>> On 03/27/2014 11:45 PM, Tapani Pälli wrote:
Patch adds a preprocessor define for the extension and stores
explicit location data for uniforms during AST->HIR conversion.
It also sets layout token to be available when having the
extension in place.
Signed-off-by: Tapani Pälli
---
src/glsl/ast_to_hir.cpp | 13 +
src/glsl/glcpp/glcpp-parse.y | 3 +++
src/glsl/glsl_lexer.ll | 1 +
3 files changed, 17 insertions(+)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 8f6e901..3bfad02 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2123,6 +2123,19 @@ validate_explicit_location(const struct
ast_type_qualifier *qual,
{
bool fail = false;
+ /* Checks for GL_ARB_explicit_uniform_location. */
+ if (qual->flags.q.uniform) {
+
+ if (qual->index < 0) {
+ _mesa_glsl_error(loc, state,
+ "explicit location < 0 for uniform %s",
var->name);
>>> We also need to check that the explicit location isn't too large. I
>>> don't think that check can happen here because (I think) it will depend
>>> on the size of the uniform. The spec isn't completely clear, but I think
>>>
>>> // assume GL_MAX_UNIFORM_LOCATIONS is 65536
>>> layout(location=65535) float foo[1];
>>>
>>> should fail because foo[1] would have location 65536 (larger than
>>> GL_MAX_UNIFORM_LOCATIONS-1).
>>>
>>> Given the other rules in the spec about counting and use of locations, I
>>> think ast_to_hir is the right time to do the upper bound check. I
>>> believe we can figure out how many locations a structure or array
>>> uniform will maximally use at that point.
>> I now see that you added that check in patch 8. Maybe just put a
>> comment here explaining why the check can't happen here.
>
> OK, I'll try to move check for bounds to happen while parsing to be able
> to fail earlier. I originally preferred to have all checks in one place
> and location assignment felt like the right spot.
I think the check is fine where it is. I just want a comment here so
that the next person doesn't say, "Hey! We need to check the other
bound too!" :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa/mesa] Hardcode the DRI driver extension as .so to match it's current uses.
On 07/04/14 13:05, Jon TURNEY wrote: > On 06/04/2014 17:45, Emil Velikov wrote: >> IMHO if we're starting from scratch we should use the platform specific >> extensions consistently but neither suggestion matter in this case :'( > > Can you explain your reasoning? This seems to me to be a foolish consistency. > > For libraries which are only ever used with dlopen() and are not intended to > be linked with (i.e. have some sort of plug-in style interface), there is no > advantage to using the platform's default shared library extension, and it > introduces extra platform dependent code to determine the library name when > the library is used. > It's just me being different (I like my bikeshed in green). Either way it does not matter, as we're a bit too later for the party :) -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] build: force .so extension for the gallium dri modules
While linux uses .so as a default extension of a shared library that is not the case for other platforms. The loader in libGL (and others) assume that the dri module will always have a .so extension, thus it will fail to load it on some platforms. Spotted-by: Jon TURNEY Signed-off-by: Emil Velikov --- install-gallium-links.mk | 2 +- src/gallium/Automake.inc | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/install-gallium-links.mk b/install-gallium-links.mk index 6ed8a24a..757b288 100644 --- a/install-gallium-links.mk +++ b/install-gallium-links.mk @@ -12,7 +12,7 @@ all-local : .libs/install-gallium-links link_dir=$(top_builddir)/$(LIB_DIR)/egl;\ fi; \ $(MKDIR_P) $$link_dir; \ - file_list=$(dri_LTLIBRARIES:%.la=.libs/%.$(LIB_EXT)*); \ + file_list=$(dri_LTLIBRARIES:%.la=.libs/%.so); \ file_list+=$(vdpau_LTLIBRARIES:%.la=.libs/%.$(LIB_EXT)*); \ file_list+=$(egl_LTLIBRARIES:%.la=.libs/%.$(LIB_EXT)*); \ file_list+=$(lib_LTLIBRARIES:%.la=.libs/%.$(LIB_EXT)*); \ diff --git a/src/gallium/Automake.inc b/src/gallium/Automake.inc index bafde36..1f5d532 100644 --- a/src/gallium/Automake.inc +++ b/src/gallium/Automake.inc @@ -55,6 +55,7 @@ DRI_VERSION_SCRIPT ?= $(top_srcdir)/src/gallium/state_trackers/dri/dri.link GALLIUM_DRI_LINKER_FLAGS = \ -shared \ + -shrext .so \ -module \ -avoid-version \ $(GC_SECTIONS) \ -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/10] swrast: rename texture fetch functions (pt. 1)
On 04/05/2014 03:50 PM, Brian Paul wrote:
> Rename functions to match format names.
>
> sed commands:
> s/signed_rgba_rev/R8G8B8A8_SNORM/g
> s/signed_rgba/A8B8G8R8_SNORM/g
> s/f_rgba_rev/R8G8B8A_UNORM/g
> s/f_rgba/A8B8G8R8_UNORM/g
> s/f_rgbx_rev/R8G8B8X8_UNORM/g
> s/f_rgbx/X8B8G8R8_UNORM/g
> s/f_argb_rev/A8R8G8B8_UNORM/g
> s/f_argb/B8G8R8A8_UNORM/g
> s/f_xrgb_rev/X8R8G8B8_UNORM/g
> s/f_xrgb/B8G8R8X8_UNORM/g
> s/signed_rgbx/X8B8G8R8_SNORM/g
> ---
> src/mesa/swrast/s_texfetch.c | 66
> +++---
> src/mesa/swrast/s_texfetch_tmp.h | 22 ++---
> 2 files changed, 44 insertions(+), 44 deletions(-)
>
> diff --git a/src/mesa/swrast/s_texfetch.c b/src/mesa/swrast/s_texfetch.c
> index cd09827..e041dd5 100644
> --- a/src/mesa/swrast/s_texfetch.c
> +++ b/src/mesa/swrast/s_texfetch.c
> @@ -151,51 +151,51 @@ texfetch_funcs[] =
> /* Packed unorm formats */
> {
>MESA_FORMAT_A8B8G8R8_UNORM,
> - fetch_texel_1d_f_rgba,
> - fetch_texel_2d_f_rgba,
> - fetch_texel_3d_f_rgba
> + fetch_texel_1d_A8B8G8R8_UNORM,
> + fetch_texel_2d_A8B8G8R8_UNORM,
> + fetch_texel_3d_A8B8G8R8_UNORM
> },
At the end, is it also worth wrapping this in a macro?
#define FETCH_FUNCS(name) {\
MESA_FORMAT_ ## name,\
fetch_texel_1d_ ## name, \
fetch_texel_2d_ ## name, \
fetch_texel_3d_ ## name, \
}
> {
>MESA_FORMAT_X8B8G8R8_UNORM,
> - fetch_texel_1d_f_rgbx,
> - fetch_texel_2d_f_rgbx,
> - fetch_texel_3d_f_rgbx
> + fetch_texel_1d_X8B8G8R8_UNORM,
> + fetch_texel_2d_X8B8G8R8_UNORM,
> + fetch_texel_3d_X8B8G8R8_UNORM
> },
> {
>MESA_FORMAT_R8G8B8A8_UNORM,
> - fetch_texel_1d_f_rgba_rev,
> - fetch_texel_2d_f_rgba_rev,
> - fetch_texel_3d_f_rgba_rev
> + fetch_texel_1d_R8G8B8A_UNORM,
> + fetch_texel_2d_R8G8B8A_UNORM,
> + fetch_texel_3d_R8G8B8A_UNORM
> },
> {
>MESA_FORMAT_R8G8B8X8_UNORM,
> - fetch_texel_1d_f_rgbx_rev,
> - fetch_texel_2d_f_rgbx_rev,
> - fetch_texel_3d_f_rgbx_rev
> + fetch_texel_1d_R8G8B8X8_UNORM,
> + fetch_texel_2d_R8G8B8X8_UNORM,
> + fetch_texel_3d_R8G8B8X8_UNORM
> },
> {
>MESA_FORMAT_B8G8R8A8_UNORM,
> - fetch_texel_1d_f_argb,
> - fetch_texel_2d_f_argb,
> - fetch_texel_3d_f_argb
> + fetch_texel_1d_B8G8R8A8_UNORM,
> + fetch_texel_2d_B8G8R8A8_UNORM,
> + fetch_texel_3d_B8G8R8A8_UNORM
> },
> {
>MESA_FORMAT_B8G8R8X8_UNORM,
> - fetch_texel_1d_f_xrgb,
> - fetch_texel_2d_f_xrgb,
> - fetch_texel_3d_f_xrgb
> + fetch_texel_1d_B8G8R8X8_UNORM,
> + fetch_texel_2d_B8G8R8X8_UNORM,
> + fetch_texel_3d_B8G8R8X8_UNORM
> },
> {
>MESA_FORMAT_A8R8G8B8_UNORM,
> - fetch_texel_1d_f_argb_rev,
> - fetch_texel_2d_f_argb_rev,
> - fetch_texel_3d_f_argb_rev
> + fetch_texel_1d_A8R8G8B8_UNORM,
> + fetch_texel_2d_A8R8G8B8_UNORM,
> + fetch_texel_3d_A8R8G8B8_UNORM
> },
> {
>MESA_FORMAT_X8R8G8B8_UNORM,
> - fetch_texel_1d_f_xrgb_rev,
> - fetch_texel_2d_f_xrgb_rev,
> - fetch_texel_3d_f_xrgb_rev
> + fetch_texel_1d_X8R8G8B8_UNORM,
> + fetch_texel_2d_X8R8G8B8_UNORM,
> + fetch_texel_3d_X8R8G8B8_UNORM
> },
> {
>MESA_FORMAT_L16A16_UNORM,
> @@ -467,21 +467,21 @@ texfetch_funcs[] =
> /* Packed signed/normalized formats */
> {
>MESA_FORMAT_A8B8G8R8_SNORM,
> - fetch_texel_1d_signed_rgba,
> - fetch_texel_2d_signed_rgba,
> - fetch_texel_3d_signed_rgba
> + fetch_texel_1d_A8B8G8R8_SNORM,
> + fetch_texel_2d_A8B8G8R8_SNORM,
> + fetch_texel_3d_A8B8G8R8_SNORM
> },
> {
>MESA_FORMAT_X8B8G8R8_SNORM,
> - fetch_texel_1d_signed_rgbx,
> - fetch_texel_2d_signed_rgbx,
> - fetch_texel_3d_signed_rgbx
> + fetch_texel_1d_X8B8G8R8_SNORM,
> + fetch_texel_2d_X8B8G8R8_SNORM,
> + fetch_texel_3d_X8B8G8R8_SNORM
> },
> {
>MESA_FORMAT_R8G8B8A8_SNORM,
> - fetch_texel_1d_signed_rgba_rev,
> - fetch_texel_2d_signed_rgba_rev,
> - fetch_texel_3d_signed_rgba_rev
> + fetch_texel_1d_R8G8B8A8_SNORM,
> + fetch_texel_2d_R8G8B8A8_SNORM,
> + fetch_texel_3d_R8G8B8A8_SNORM
> },
> {
>MESA_FORMAT_R8G8B8X8_SNORM,
> diff --git a/src/mesa/swrast/s_texfetch_tmp.h
> b/src/mesa/swrast/s_texfetch_tmp.h
> index f749b49..0acbe4f 100644
> --- a/src/mesa/swrast/s_texfetch_tmp.h
> +++ b/src/mesa/swrast/s_texfetch_tmp.h
> @@ -391,7 +391,7 @@ static void FETCH(f_rg_f16)( const struct
> swrast_texture_image *texImage,
> /* MESA_FORMAT_A8B8G8R8_UNORM
> **/
>
> /* Fetch texel from 1D, 2D or 3D rgba te
Re: [Mesa-dev] [PATCH 01/10] mesa: rename stencil/Z functions in format_unpack.c
The series is
Reviewed-by: Ian Romanick
On 04/05/2014 03:50 PM, Brian Paul wrote:
> So the function names match the format names.
> ---
> src/mesa/main/format_unpack.c | 80
> -
> 1 file changed, 40 insertions(+), 40 deletions(-)
>
> diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
> index 2ef2e31..cf96609 100644
> --- a/src/mesa/main/format_unpack.c
> +++ b/src/mesa/main/format_unpack.c
> @@ -645,7 +645,7 @@ unpack_R10G10B10A2_UINT(const void *src, GLfloat
> dst[][4], GLuint n)
>
>
> static void
> -unpack_Z24_S8(const void *src, GLfloat dst[][4], GLuint n)
> +unpack_S8_UINT_Z24_UNORM(const void *src, GLfloat dst[][4], GLuint n)
> {
> /* only return Z, not stencil data */
> const GLuint *s = ((const GLuint *) src);
> @@ -662,7 +662,7 @@ unpack_Z24_S8(const void *src, GLfloat dst[][4], GLuint n)
> }
>
> static void
> -unpack_S8_Z24(const void *src, GLfloat dst[][4], GLuint n)
> +unpack_Z24_UNORM_S8_UINT(const void *src, GLfloat dst[][4], GLuint n)
> {
> /* only return Z, not stencil data */
> const GLuint *s = ((const GLuint *) src);
> @@ -679,7 +679,7 @@ unpack_S8_Z24(const void *src, GLfloat dst[][4], GLuint n)
> }
>
> static void
> -unpack_Z16(const void *src, GLfloat dst[][4], GLuint n)
> +unpack_Z_UNORM16(const void *src, GLfloat dst[][4], GLuint n)
> {
> const GLushort *s = ((const GLushort *) src);
> GLuint i;
> @@ -692,19 +692,19 @@ unpack_Z16(const void *src, GLfloat dst[][4], GLuint n)
> }
>
> static void
> -unpack_X8_Z24(const void *src, GLfloat dst[][4], GLuint n)
> +unpack_Z24_UNORM_X8_UINT(const void *src, GLfloat dst[][4], GLuint n)
> {
> - unpack_S8_Z24(src, dst, n);
> + unpack_Z24_UNORM_S8_UINT(src, dst, n);
> }
>
> static void
> -unpack_Z24_X8(const void *src, GLfloat dst[][4], GLuint n)
> +unpack_X8_UINT_Z24_UNORM(const void *src, GLfloat dst[][4], GLuint n)
> {
> - unpack_Z24_S8(src, dst, n);
> + unpack_S8_UINT_Z24_UNORM(src, dst, n);
> }
>
> static void
> -unpack_Z32(const void *src, GLfloat dst[][4], GLuint n)
> +unpack_Z_UNORM32(const void *src, GLfloat dst[][4], GLuint n)
> {
> const GLuint *s = ((const GLuint *) src);
> GLuint i;
> @@ -717,7 +717,7 @@ unpack_Z32(const void *src, GLfloat dst[][4], GLuint n)
> }
>
> static void
> -unpack_Z32_FLOAT_X24S8(const void *src, GLfloat dst[][4], GLuint n)
> +unpack_Z32_FLOAT_S8X24_UINT(const void *src, GLfloat dst[][4], GLuint n)
> {
> const struct z32f_x24s8 *s = (const struct z32f_x24s8 *) src;
> GLuint i;
> @@ -730,7 +730,7 @@ unpack_Z32_FLOAT_X24S8(const void *src, GLfloat dst[][4],
> GLuint n)
> }
>
> static void
> -unpack_Z32_FLOAT(const void *src, GLfloat dst[][4], GLuint n)
> +unpack_Z_FLOAT32(const void *src, GLfloat dst[][4], GLuint n)
> {
> const GLfloat *s = ((const GLfloat *) src);
> GLuint i;
> @@ -2391,12 +2391,12 @@ get_unpack_rgba_function(mesa_format format)
>table[MESA_FORMAT_B10G10R10A2_UNORM] = unpack_B10G10R10A2_UNORM;
>table[MESA_FORMAT_B10G10R10A2_UINT] = unpack_B10G10R10A2_UINT;
>table[MESA_FORMAT_R10G10B10A2_UINT] = unpack_R10G10B10A2_UINT;
> - table[MESA_FORMAT_S8_UINT_Z24_UNORM] = unpack_Z24_S8;
> - table[MESA_FORMAT_Z24_UNORM_S8_UINT] = unpack_S8_Z24;
> - table[MESA_FORMAT_Z_UNORM16] = unpack_Z16;
> - table[MESA_FORMAT_Z24_UNORM_X8_UINT] = unpack_X8_Z24;
> - table[MESA_FORMAT_X8_UINT_Z24_UNORM] = unpack_Z24_X8;
> - table[MESA_FORMAT_Z_UNORM32] = unpack_Z32;
> + table[MESA_FORMAT_S8_UINT_Z24_UNORM] = unpack_S8_UINT_Z24_UNORM;
> + table[MESA_FORMAT_Z24_UNORM_S8_UINT] = unpack_Z24_UNORM_S8_UINT;
> + table[MESA_FORMAT_Z_UNORM16] = unpack_Z_UNORM16;
> + table[MESA_FORMAT_Z24_UNORM_X8_UINT] = unpack_Z24_UNORM_X8_UINT;
> + table[MESA_FORMAT_X8_UINT_Z24_UNORM] = unpack_X8_UINT_Z24_UNORM;
> + table[MESA_FORMAT_Z_UNORM32] = unpack_Z_UNORM32;
>table[MESA_FORMAT_S_UINT8] = unpack_S8;
>table[MESA_FORMAT_BGR_SRGB8] = unpack_BGR_SRGB8;
>table[MESA_FORMAT_A8B8G8R8_SRGB] = unpack_A8B8G8R8_SRGB;
> @@ -2533,8 +2533,8 @@ get_unpack_rgba_function(mesa_format format)
>table[MESA_FORMAT_R9G9B9E5_FLOAT] = unpack_R9G9B9E5_FLOAT;
>table[MESA_FORMAT_R11G11B10_FLOAT] = unpack_R11G11B10_FLOAT;
>
> - table[MESA_FORMAT_Z_FLOAT32] = unpack_Z32_FLOAT;
> - table[MESA_FORMAT_Z32_FLOAT_S8X24_UINT] = unpack_Z32_FLOAT_X24S8;
> + table[MESA_FORMAT_Z_FLOAT32] = unpack_Z_FLOAT32;
> + table[MESA_FORMAT_Z32_FLOAT_S8X24_UINT] = unpack_Z32_FLOAT_S8X24_UINT;
>
>table[MESA_FORMAT_B4G4R4X4_UNORM] = unpack_XRGB_UNORM;
>table[MESA_FORMAT_B5G5R5X1_UNORM] = unpack_XRGB1555_UNORM;
> @@ -3935,7 +3935,7 @@ _mesa_unpack_rgba_block(mesa_format format,
> typedef void (*unpack_float_z_func)(GLuint n, const void *src, GLfloat *dst);
>
> static void
> -unpack_float_z_Z24_X8(GLuint n, const void *src, GLfloat *dst)
> +unpack_float_z_X8_
Re: [Mesa-dev] [PATCH 02/10] swrast: rename texture fetch functions (pt. 1)
On 04/07/2014 09:17 AM, Ian Romanick wrote:
On 04/05/2014 03:50 PM, Brian Paul wrote:
Rename functions to match format names.
sed commands:
s/signed_rgba_rev/R8G8B8A8_SNORM/g
s/signed_rgba/A8B8G8R8_SNORM/g
s/f_rgba_rev/R8G8B8A_UNORM/g
s/f_rgba/A8B8G8R8_UNORM/g
s/f_rgbx_rev/R8G8B8X8_UNORM/g
s/f_rgbx/X8B8G8R8_UNORM/g
s/f_argb_rev/A8R8G8B8_UNORM/g
s/f_argb/B8G8R8A8_UNORM/g
s/f_xrgb_rev/X8R8G8B8_UNORM/g
s/f_xrgb/B8G8R8X8_UNORM/g
s/signed_rgbx/X8B8G8R8_SNORM/g
---
src/mesa/swrast/s_texfetch.c | 66 +++---
src/mesa/swrast/s_texfetch_tmp.h | 22 ++---
2 files changed, 44 insertions(+), 44 deletions(-)
diff --git a/src/mesa/swrast/s_texfetch.c b/src/mesa/swrast/s_texfetch.c
index cd09827..e041dd5 100644
--- a/src/mesa/swrast/s_texfetch.c
+++ b/src/mesa/swrast/s_texfetch.c
@@ -151,51 +151,51 @@ texfetch_funcs[] =
/* Packed unorm formats */
{
MESA_FORMAT_A8B8G8R8_UNORM,
- fetch_texel_1d_f_rgba,
- fetch_texel_2d_f_rgba,
- fetch_texel_3d_f_rgba
+ fetch_texel_1d_A8B8G8R8_UNORM,
+ fetch_texel_2d_A8B8G8R8_UNORM,
+ fetch_texel_3d_A8B8G8R8_UNORM
},
At the end, is it also worth wrapping this in a macro?
#define FETCH_FUNCS(name) {\
MESA_FORMAT_ ## name,\
fetch_texel_1d_ ## name, \
fetch_texel_2d_ ## name, \
fetch_texel_3d_ ## name, \
}
Yeah, I was thinking of doing that.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61750] Undefined references linking libGLESv2 when configured with --disable-dri
https://bugs.freedesktop.org/show_bug.cgi?id=61750 --- Comment #4 from Will Wagner --- This appears to be a duplicate of bug 75098? -- 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] i965: Don't enable reset notification support on Gen4-5.
On 03/13/2014 08:15 AM, Mika Kuoppala wrote:
> Ian Romanick writes:
>
>> On 03/12/2014 01:43 AM, Kenneth Graunke wrote:
>>> arekm reported that using Chrome with GPU acceleration enabled on GM45
>>> triggered the hw_ctx != NULL assertion in brw_get_graphics_reset_status.
>>>
>>> We definitely do not want to advertise reset notification support on
>>> Gen4-5 systems, since it needs hardware contexts, and we never even
>>> request a hardware context on those systems.
>>>
>>> Cc: Ian Romanick
>>> Signed-off-by: Kenneth Graunke
>>> ---
>>> src/mesa/drivers/dri/i965/intel_screen.c | 13 +
>>> 1 file changed, 9 insertions(+), 4 deletions(-)
>>>
>>> This may not be the best solution; if someone would like to send patches for
>>> a better one, I'm more than happy to go with something else. Checking for
>>> hardware contexts is a bit awkward - we need to decide whether to advertise
>>> support here in the screen, but we don't create hardware contexts until
>>> context creation time, which is a fair bit later. So, I'm not sure how to
>>> do better than the generation check, for now.
>>
>> I'm confused. I thought the ioctl was was supposed to fail with EINVAL
>> in that case. Mika, what's your suggestion?
>
> I think two ioctl queries are needed to catch the combinations,
> unfortunately :(
>
> For gens without hw_contexts, we keep statistics per file
> descriptor and thus we can ban batch submission through
> file desc if has been sending hanging batches. This is
> tied to reset stats so that if there is no hw_contexts,
> you get statistics for your fd.
>
> Here is how I do it in tests:
So... in the reset tests, you do something like:
if (gem_has_hw_contexts(fd) && gem_has_reset_stats(fd))
do_reset_with_context_test();
I guess that wouldn't be a terrible way to handle it in Mesa...
> static bool gem_has_hw_contexts(int fd)
> {
> struct local_drm_i915_gem_context_create create;
> int ret;
>
> memset(&create, 0, sizeof(create));
> ret = drmIoctl(fd, CONTEXT_CREATE_IOCTL, &create);
>
> if (ret == 0) {
> drmIoctl(fd, CONTEXT_DESTROY_IOCTL, &create);
> return true;
> }
>
> return false;
> }
>
> static bool gem_has_reset_stats(int fd)
> {
> struct local_drm_i915_reset_stats rs;
> int ret;
>
> /* Carefully set flags and pad to zero, otherwise
> we get -EINVAL
> */
> memset(&rs, 0, sizeof(rs));
>
> ret = drmIoctl(fd, GET_RESET_STATS_IOCTL, &rs);
> if (ret == 0)
> return true;
>
> /* If we get EPERM, we have support but did not
> have CAP_SYSADM */
> if (ret == -1 && errno == EPERM)
> return true;
>
> return false;
> }
>
> -Mika
>
>
>>> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
>>> b/src/mesa/drivers/dri/i965/intel_screen.c
>>> index 464cebf..12006be 100644
>>> --- a/src/mesa/drivers/dri/i965/intel_screen.c
>>> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
>>> @@ -1342,13 +1342,18 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp)
>>> * no error. If the ioctl is not supported, it always generate EINVAL.
>>> * Use this to determine whether to advertise the __DRI2_ROBUSTNESS
>>> * extension to the loader.
>>> +*
>>> +* Don't even try on pre-Gen6, since we don't attempt to use contexts
>>> there.
>>> */
>>> - struct drm_i915_reset_stats stats;
>>> - memset(&stats, 0, sizeof(stats));
>>> + if (intelScreen->devinfo->gen >= 6) {
>>> + struct drm_i915_reset_stats stats;
>>> + memset(&stats, 0, sizeof(stats));
>>>
>>> - const int ret = drmIoctl(psp->fd, DRM_IOCTL_I915_GET_RESET_STATS,
>>> &stats);
>>> + const int ret = drmIoctl(psp->fd, DRM_IOCTL_I915_GET_RESET_STATS,
>>> &stats);
>>>
>>> - intelScreen->has_context_reset_notification = (ret != -1 || errno !=
>>> EINVAL);
>>> + intelScreen->has_context_reset_notification =
>>> + (ret != -1 || errno != EINVAL);
>>> + }
>>>
>>> psp->extensions = !intelScreen->has_context_reset_notification
>>>? intelScreenExtensions : intelRobustScreenExtensions;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965/gs: Add dummy source to prepare_channel_masks instruction.
Kenneth Graunke writes: > On 04/04/2014 03:28 PM, Matt Turner wrote: >> The generator uses its destination as a source implicitly, which breaks >> some assumptions in dead code elimination. Giving the instruction a >> source allows us to reason about it better. >> --- >> src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp >> b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp >> index 13d6d38..1321a94 100644 >> --- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp >> +++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp >> @@ -408,7 +408,8 @@ vec4_gs_visitor::emit_control_data_bits() >> src_reg channel_mask(this, glsl_type::uint_type); >> inst = emit(SHL(dst_reg(channel_mask), one, channel)); >> inst->force_writemask_all = true; >> - emit(GS_OPCODE_PREPARE_CHANNEL_MASKS, dst_reg(channel_mask)); >> + emit(GS_OPCODE_PREPARE_CHANNEL_MASKS, dst_reg(channel_mask), >> + channel_mask); >> emit(GS_OPCODE_SET_CHANNEL_MASKS, mrf_reg, channel_mask); >>} >> >> > > This seems reasonable, though I'd like to see generator changes to > match. Either use the source register, or at least: > >assert(src[0] == dst); > > in both generators. With Ken's change (or maybe you have to just assert on file and reg, possibly): Reviewed-by: Eric Anholt I feel like I've used this strategy before for fixing up dead code problems, but I just noticed that in general there's a risk of the dummy source getting copy propagation happen to it, and then not actually serving its purpose. We know that's not the case here because we can see the channel_mask setup right there. pgp75HDRrF2_N.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 10.2 release plan strawman
Ian Romanick writes: > On 04/04/2014 05:52 PM, Matt Turner wrote: >> On Fri, Apr 4, 2014 at 5:18 PM, Ian Romanick wrote: >>> Fast forwarding 3 months from the 10.1 release (March 4th, planned for >>> February 28th) is May 30th. I'd like to propose the following set of dates: >>> >>> May 2nd: Feature freeze / 10.2 branch created. >>> >>> May 16th: RC1 >> >> Same comment as last time. It's not clear to me that we need a week >> between the branch and RC1. We're not going to get users testing the >> branch until there's an RC that distros can offer. > > The thinking behind having some gap is that a lot of people don't change > from feature work to bug fixing until the branch is made. There are > usually a bunch of bug fixes landed right after the branch is made... > there's also often a bunch of... chaos right before the branch is made. > Having an RC that doesn't build, has lot of known bugs, etc is useless. > Having a time gap between features landing and making RC1 allows things > to settle down a bit. > > I thought your complaint before was that a week wasn't long enough. > That's why I bumped it to two weeks this time. I guess I must have > misunderstood the concern. FWIW, I also don't see the point in having the branch but no RC. pgp3jkNhNW3Lr.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] i965: fix MakeCurrent when switching a context between multiple drawables.
Iago Toral Quiroga writes:
> Commit 11baad35088dfd4bdabc1710df650dbfb413e7a3 produces a regression when
> switching a single context between multiple drawables.
>
> The problem is that we check whether we have a viewport set to decide if we
> need to generate buffers for the drawble, but the viewport is initialized
> with the first call to MakeCurrent for that context, so calling MakeCurrent on
> the same context with a different drawable will have the viewport already
> initialized and will not generate buffers for the new drawable.
>
> This patch fixes the problem by reverting to the previous solution implemented
> in commit 05da4a7a5e7d5bd988cb31f94ed8e1f053d9ee39 with a small fix to
> suppport
> single buffer drawables too. This solution checks if we have a renderbuffer
> for
> the drawable to decide if we need to generate a buffer or not. The original
> implementation, however, did this by checking the BACK_LEFT buffer, which is
> not a valid solution for single buffer drawables. This patch modifies this
> to check the FRONT_LEFT buffer instead, which should work in both scenarios.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74005
> ---
> src/mesa/drivers/dri/i965/brw_context.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> b/src/mesa/drivers/dri/i965/brw_context.c
> index c9719f5..c593286 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -926,6 +926,7 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
> {
> struct brw_context *brw;
> GET_CURRENT_CONTEXT(curCtx);
> + struct intel_renderbuffer *rb = NULL;
>
> if (driContextPriv)
>brw = (struct brw_context *) driContextPriv->driverPrivate;
> @@ -950,6 +951,7 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
>} else {
> fb = driDrawPriv->driverPrivate;
> readFb = driReadPriv->driverPrivate;
> + rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
> driContextPriv->dri2.draw_stamp = driDrawPriv->dri2.stamp - 1;
> driContextPriv->dri2.read_stamp = driReadPriv->dri2.stamp - 1;
>}
> @@ -961,10 +963,9 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
>intel_gles3_srgb_workaround(brw, fb);
>intel_gles3_srgb_workaround(brw, readFb);
>
> - /* If the context viewport hasn't been initialized, force a call out to
> - * the loader to get buffers so we have a drawable size for the initial
> - * viewport. */
> - if (!brw->ctx.ViewportInitialized)
> + /* If we don't have buffers for the drawable yet, force a call to
> + * getbuffers here so we can have a default drawable size. */
> + if (rb && !rb->mt)
> intel_prepare_render(brw);
We won't have an rb->mt for the front unless you're doing front buffer
rendering, so I think you're basically just backing out krh's change.
Which I think is good -- it looks like he was papering over a bug
elsewhere, and I think we *should* just prepare_render in makecurrent.
But if we're going to revert, let's just actually revert.
pgpCQhqn__qGT.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 7/7] i965/fs: Check for interference after finding all channels.
Matt Turner writes: > It's more likely that we won't find writes to all channels than one will > interfere, and calculating interference is more expensive. This change > will also help prepare for coalescing load_payload instructions' > operands. > > Also update the live intervals for all channels, and not just the last > that we saw. These last two are: Reviewed-by: Eric Anholt pgpJJPBKIg3oI.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Use M_PI_* macros.
Notice our multiple values for M_PI_2, which rounded ...32 up to
...4 and ...5.
---
The float casts are ugly. I tried to define M_PI_2f using the
preprocessor -- something like
#define M_PI_2f M_PI_2##f
but no luck.
src/glsl/builtin_functions.cpp | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index 26ea923..62bf154 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -2538,11 +2538,11 @@ ir_expression *
builtin_builder::asin_expr(ir_variable *x)
{
return mul(sign(x),
- sub(imm(1.5707964f),
+ sub(imm((float)M_PI_2),
mul(sqrt(sub(imm(1.0f), abs(x))),
- add(imm(1.5707964f),
+ add(imm((float)M_PI_2),
mul(abs(x),
- add(imm(-0.21460183f),
+ add(imm((float)(1.0 - M_PI_4)),
mul(abs(x),
add(imm(0.086566724f),
mul(abs(x),
imm(-0.03102955f));
@@ -2586,7 +2586,7 @@ builtin_builder::_acos(const glsl_type *type)
ir_variable *x = in_var(type, "x");
MAKE_SIG(type, always_available, 1, x);
- body.emit(ret(sub(imm(1.5707964f), asin_expr(x;
+ body.emit(ret(sub(imm((float)M_PI_2), asin_expr(x;
return sig;
}
@@ -2623,13 +2623,13 @@ builtin_builder::_atan2(const glsl_type *type)
ir_if *inner_if = new(mem_ctx) ir_if(less(x, imm(0.0f)));
inner_if->then_instructions.push_tail(
if_tree(gequal(y, imm(0.0f)),
- assign(r, add(r, imm(3.141593f))),
- assign(r, sub(r, imm(3.141593f);
+ assign(r, add(r, imm((float)M_PI))),
+ assign(r, sub(r, imm((float)M_PI);
outer_then.emit(inner_if);
/* Else... */
outer_if->else_instructions.push_tail(
- assign(r, mul(sign(y), imm(1.5707965f;
+ assign(r, mul(sign(y), imm((float)M_PI_2;
body.emit(outer_if);
--
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] glsl: Use M_PI_* macros.
On Mon, Apr 7, 2014 at 12:19 PM, Matt Turner wrote:
> Notice our multiple values for M_PI_2, which rounded ...32 up to
> ...4 and ...5.
> ---
> The float casts are ugly. I tried to define M_PI_2f using the
> preprocessor -- something like
>#define M_PI_2f M_PI_2##f
> but no luck.
>
> src/glsl/builtin_functions.cpp | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
> index 26ea923..62bf154 100644
> --- a/src/glsl/builtin_functions.cpp
> +++ b/src/glsl/builtin_functions.cpp
> @@ -2538,11 +2538,11 @@ ir_expression *
> builtin_builder::asin_expr(ir_variable *x)
> {
> return mul(sign(x),
> - sub(imm(1.5707964f),
> + sub(imm((float)M_PI_2),
>mul(sqrt(sub(imm(1.0f), abs(x))),
> - add(imm(1.5707964f),
> + add(imm((float)M_PI_2),
>mul(abs(x),
> - add(imm(-0.21460183f),
> + add(imm((float)(1.0 - M_PI_4)),
1 - M_PI_4 comes out to 0.21460 (positive), not -0.21460. You
probably want to switch the operand order in the subtraction here
(unless this change was intentional).
--Aaron
>mul(abs(x),
>add(imm(0.086566724f),
>mul(abs(x),
> imm(-0.03102955f));
> @@ -2586,7 +2586,7 @@ builtin_builder::_acos(const glsl_type *type)
> ir_variable *x = in_var(type, "x");
> MAKE_SIG(type, always_available, 1, x);
>
> - body.emit(ret(sub(imm(1.5707964f), asin_expr(x;
> + body.emit(ret(sub(imm((float)M_PI_2), asin_expr(x;
>
> return sig;
> }
> @@ -2623,13 +2623,13 @@ builtin_builder::_atan2(const glsl_type *type)
>ir_if *inner_if = new(mem_ctx) ir_if(less(x, imm(0.0f)));
>inner_if->then_instructions.push_tail(
> if_tree(gequal(y, imm(0.0f)),
> - assign(r, add(r, imm(3.141593f))),
> - assign(r, sub(r, imm(3.141593f);
> + assign(r, add(r, imm((float)M_PI))),
> + assign(r, sub(r, imm((float)M_PI);
>outer_then.emit(inner_if);
>
>/* Else... */
>outer_if->else_instructions.push_tail(
> - assign(r, mul(sign(y), imm(1.5707965f;
> + assign(r, mul(sign(y), imm((float)M_PI_2;
>
>body.emit(outer_if);
>
> --
> 1.8.3.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] glsl: Use M_PI_* macros.
On Mon, Apr 7, 2014 at 10:28 AM, Aaron Watry wrote:
> On Mon, Apr 7, 2014 at 12:19 PM, Matt Turner wrote:
>> Notice our multiple values for M_PI_2, which rounded ...32 up to
>> ...4 and ...5.
>> ---
>> The float casts are ugly. I tried to define M_PI_2f using the
>> preprocessor -- something like
>>#define M_PI_2f M_PI_2##f
>> but no luck.
>>
>> src/glsl/builtin_functions.cpp | 14 +++---
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
>> index 26ea923..62bf154 100644
>> --- a/src/glsl/builtin_functions.cpp
>> +++ b/src/glsl/builtin_functions.cpp
>> @@ -2538,11 +2538,11 @@ ir_expression *
>> builtin_builder::asin_expr(ir_variable *x)
>> {
>> return mul(sign(x),
>> - sub(imm(1.5707964f),
>> + sub(imm((float)M_PI_2),
>>mul(sqrt(sub(imm(1.0f), abs(x))),
>> - add(imm(1.5707964f),
>> + add(imm((float)M_PI_2),
>>mul(abs(x),
>> - add(imm(-0.21460183f),
>> + add(imm((float)(1.0 - M_PI_4)),
>
> 1 - M_PI_4 comes out to 0.21460 (positive), not -0.21460. You
> probably want to switch the operand order in the subtraction here
> (unless this change was intentional).
>
> --Aaron
Indeed, thanks for noticing.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 9/9] glsl: Convert mul/div by power-of-two factors to shift expressions.
Am 07.04.2014 15:52, schrieb Ian Romanick:
> On 04/06/2014 11:49 PM, Kenneth Graunke wrote:
>> Integer shifts are basically always well supported and efficient; that
>> isn't always true of integer division, and sometimes even integer
>> multiplication isn't without issues.
>>
>> On some Intel hardware, INTDIV can't be used in SIMD16 mode. It also
>> doesn't support immediate operands (on any generation), while ASR can.
>>
>> On Haswell, this cuts the number of instructions in dolphin/efb2ram by
>> 7.94%. It also removes a single MOV in dolphin/realxfb (due to ASR
>> supporting immediates), and gains SIMD16 support (due to no INTDIV).
>>
>> Signed-off-by: Kenneth Graunke
>> ---
>> src/glsl/opt_algebraic.cpp | 70
>> --
>> 1 file changed, 68 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
>> index 9d55392..eccc2eb 100644
>> --- a/src/glsl/opt_algebraic.cpp
>> +++ b/src/glsl/opt_algebraic.cpp
>> @@ -34,6 +34,7 @@
>> #include "ir_optimization.h"
>> #include "ir_builder.h"
>> #include "glsl_types.h"
>> +#include "main/macros.h"
>>
>> using namespace ir_builder;
>>
>> @@ -68,6 +69,8 @@ public:
>> int op2);
>> ir_rvalue *swizzle_if_required(ir_expression *expr,
>>ir_rvalue *operand);
>> + ir_rvalue *convert_int_math_to_shifts(ir_expression *ir,
>> + ir_constant *op_const_array[4]);
>>
>> void *mem_ctx;
>>
>> @@ -185,6 +188,59 @@
>> ir_algebraic_visitor::reassociate_constant(ir_expression *ir1, int
>> const_index,
>> return false;
>> }
>>
>> +/**
>> + * Transform integer multiplication/division by a constant power-of-two
>> + * factor into shift instructions.
>> + */
>> +ir_rvalue *
>> +ir_algebraic_visitor::convert_int_math_to_shifts(ir_expression *ir,
>> + ir_constant
>> *op_const_array[4])
>> +{
>> + /* This optimization only makes sense for GPUs with native integers. */
>> + if (!native_integers)
>> + return NULL;
>> +
>> + assert(ir->operation == ir_binop_mul || ir->operation == ir_binop_div);
>> +
>> + /* Shifts only work for integer types. */
>> + if (!ir->type->is_integer())
>> + return NULL;
>
> After the previous conversation about converting division to shifts, I
> think at least division only generally works for unsigned. -1 / 2 => 0,
> but -1 >> 1 => -1. I don't know what the rules are for multiplication
> overflow... I think the result of int32_t(0x7000)*2 is undefined, so
> that should be fine.
Hmm c99 seems to say _unsigned_ multiplication silently wraps (as it
essentially does result modulo largest value + 1), but signed one indeed
could have undefined behavior. I think though usually everything out
there will do the same modulo arithmetic in any case - and shift should
provide the same result.
glsl actually does have this as defined behavior: "Unsigned integers
have exactly 32 bits of precision. Signed integers use 32 bits,
including a sign bit, in two's complement form. Operations resulting in
overflow or underflow will not cause any exception, nor will they
saturate, rather they will “wrap” to yield the low-order 32 bits of the
result."
I'm still unsure about division actually, I could not find anything
indicating it has to conform to c99 rules in glsl spec. If it is defined
it is well hidden, otherwise it would be nice if the spec would specify
this one way or another... It does say though modulo operation is
undefined if any of the two operands is negative, which is a hint that
rounding towards negative infinity for division might be ok too...
(I was looking at slightly older glsl 4.10 since the server seems to be
down.)
Though if division actually does rounding toward zero, and you'll happen
to hit the optimization and it then does rounding toward negative
infinity, that would be a bit awkward indeed.
Roland
>> +
>> + ir_constant *const_op;
>> + ir_rvalue *other_op;
>> + if (op_const_array[0]) {
>> + const_op = op_const_array[0];
>> + other_op = ir->operands[1];
>> + } else if (op_const_array[1]) {
>> + const_op = op_const_array[1];
>> + other_op = ir->operands[0];
>> + } else {
>> + /* If neither is a constant, we can't check for powers of two. */
>> + return NULL;
>> + }
>> +
>> + ir_constant_data shift_data;
>> + for (int i = 0; i < const_op->type->vector_elements; i++) {
>> + if (const_op->type->base_type == GLSL_TYPE_INT &&
>> + const_op->value.i[i] <= 0) {
>> + /* Negative values aren't powers of two. */
>> + return NULL;
>> + }
>
> But... we could convert x*-4 into -x*4... assuming negation is free on
> integer operands. Seems like that would be good follow-on work...
>
>> +
>> + if (!is_power_of_two(const_op->value.u[i]))
>> + return NULL;
>> +
>> + shift_data.u[i] = ffs(con
Re: [Mesa-dev] [PATCH] i965: glClearBuffer() should only clear a single buffer.
Iago Toral Quiroga writes: > glClearBuffer() is currently clearing all active draw color buffers (all > buffers that have not been set to GL_NONE when calling glDrawBuffers) instead > of only clearing the one it receives as parameter. Altough brw_clear() > receives a bit mask indicating the color buffers that should be cleared, > this mask is ignored when calling brw_blorp_clear_color(). > > This was breaking the 'fbo-drawbuffers-none glClearBuffer' piglit test. > > The patch provides the bit mask to brw_blorp_clear_color() so it can limit > clearing to the color buffers present in the mask. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76832 Reviewed-by: Eric Anholt pgpPZgxxnOIXH.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 3/3] i965: Fix missing dirty bits in the gen8_sbe_state atom.
Kenneth Graunke writes: > These are clearly needed---the comments in the function are even present > for each one of them. I originally had two separate state atoms for > 3DSTATE_SBE and 3DSTATE_SBE_SWIZ. When I combined the functions, I must > have forgotten to add the atoms for 3DSTATE_SBE_SWIZ. > > Signed-off-by: Kenneth Graunke These 3 are: Reviewed-by: Eric Anholt pgpmdmCJv6PSC.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] i965: Make sure we always compute valid index bounds before drawing.
Iago Toral Quiroga writes:
> When doing software rendering (i.e. rendering to the selection buffer) we need
> to make sure that we have valid index bounds before calling _tnl_draw_prims(),
> otherwise we can crash.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59455
> ---
> src/mesa/drivers/dri/i965/brw_draw.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> b/src/mesa/drivers/dri/i965/brw_draw.c
> index d684c17..ef0f273 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> @@ -554,7 +554,8 @@ void brw_draw_prims( struct gl_context *ctx,
> * get the minimum and maximum of their index buffer so we know what range
> * to upload.
> */
> - if (!vbo_all_varyings_in_vbos(arrays) && !index_bounds_valid) {
> + if (!index_bounds_valid &&
> + (ctx->RenderMode != GL_RENDER || !vbo_all_varyings_in_vbos(arrays))) {
>perf_debug("Scanning index buffer to compute index buffer bounds. "
> "Use glDrawRangeElements() to avoid this.\n");
>vbo_get_minmax_indices(ctx, prims, ib, &min_index, &max_index,
> nr_prims);
How about instead, let's just merge _tnl_vbo_draw_prims() into
_tnl_draw_prims(), so that this mistake can't be made again?
pgpwUUcp9a1mZ.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Add glBlitFramebuffer to commands affected by conditional rendering
Fixes failures in Khronos OpenGL CTS test conditional_render_test9
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/dri/i965/intel_fbo.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
b/src/mesa/drivers/dri/i965/intel_fbo.c
index d0e1349..b5b93a6 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.c
+++ b/src/mesa/drivers/dri/i965/intel_fbo.c
@@ -38,6 +38,7 @@
#include "main/image.h"
#include "main/hash_table.h"
#include "main/set.h"
+#include "main/condrender.h"
#include "swrast/swrast.h"
#include "drivers/common/meta.h"
@@ -833,6 +834,13 @@ intel_blit_framebuffer(struct gl_context *ctx,
GLint dstX0, GLint dstY0, GLint dstX1, GLint dstY1,
GLbitfield mask, GLenum filter)
{
+ /* Page 679 of OpenGL 4.4 spec says:
+*"Added BlitFramebuffer to commands affected by conditional rendering
in
+* section 10.10 (Bug 9562)."
+*/
+ if (!_mesa_check_conditional_render(ctx))
+ return;
+
mask = brw_blorp_framebuffer(brw_context(ctx),
srcX0, srcY0, srcX1, srcY1,
dstX0, dstY0, dstX1, dstY1,
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 9/9] glsl: Convert mul/div by power-of-two factors to shift expressions.
On Sun, Apr 6, 2014 at 11:49 PM, Kenneth Graunke wrote:
> Integer shifts are basically always well supported and efficient; that
> isn't always true of integer division, and sometimes even integer
> multiplication isn't without issues.
>
> On some Intel hardware, INTDIV can't be used in SIMD16 mode. It also
> doesn't support immediate operands (on any generation), while ASR can.
>
> On Haswell, this cuts the number of instructions in dolphin/efb2ram by
> 7.94%. It also removes a single MOV in dolphin/realxfb (due to ASR
> supporting immediates), and gains SIMD16 support (due to no INTDIV).
Just a note that the upstream shaders have already been changed to not
do integer division. That's the reason I didn't bother fixing up my
patch a couple of weeks ago.
> Signed-off-by: Kenneth Graunke
> ---
> src/glsl/opt_algebraic.cpp | 70
> --
> 1 file changed, 68 insertions(+), 2 deletions(-)
>
> diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
> index 9d55392..eccc2eb 100644
> --- a/src/glsl/opt_algebraic.cpp
> +++ b/src/glsl/opt_algebraic.cpp
> @@ -34,6 +34,7 @@
> #include "ir_optimization.h"
> #include "ir_builder.h"
> #include "glsl_types.h"
> +#include "main/macros.h"
>
> using namespace ir_builder;
>
> @@ -68,6 +69,8 @@ public:
> int op2);
> ir_rvalue *swizzle_if_required(ir_expression *expr,
> ir_rvalue *operand);
> + ir_rvalue *convert_int_math_to_shifts(ir_expression *ir,
> + ir_constant *op_const_array[4]);
>
> void *mem_ctx;
>
> @@ -185,6 +188,59 @@ ir_algebraic_visitor::reassociate_constant(ir_expression
> *ir1, int const_index,
> return false;
> }
>
> +/**
> + * Transform integer multiplication/division by a constant power-of-two
> + * factor into shift instructions.
> + */
> +ir_rvalue *
> +ir_algebraic_visitor::convert_int_math_to_shifts(ir_expression *ir,
> + ir_constant
> *op_const_array[4])
> +{
> + /* This optimization only makes sense for GPUs with native integers. */
> + if (!native_integers)
> + return NULL;
> +
> + assert(ir->operation == ir_binop_mul || ir->operation == ir_binop_div);
> +
> + /* Shifts only work for integer types. */
> + if (!ir->type->is_integer())
> + return NULL;
> +
> + ir_constant *const_op;
> + ir_rvalue *other_op;
> + if (op_const_array[0]) {
> + const_op = op_const_array[0];
> + other_op = ir->operands[1];
> + } else if (op_const_array[1]) {
> + const_op = op_const_array[1];
> + other_op = ir->operands[0];
> + } else {
> + /* If neither is a constant, we can't check for powers of two. */
> + return NULL;
> + }
> +
> + ir_constant_data shift_data;
> + for (int i = 0; i < const_op->type->vector_elements; i++) {
> + if (const_op->type->base_type == GLSL_TYPE_INT &&
> + const_op->value.i[i] <= 0) {
> + /* Negative values aren't powers of two. */
I was going to comment on the is_power_of_two() function returning
true for 0 and how this was going to break things, but I see this
check for <= 0 should handle it.
I don't know what is_power_of_two() should return for zero. The
comment "Negative values" would be more correct if we returned false
from is_power_of_two() though.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/9] i965: Fix "SIMD16 unsupported" messages via KHR_debug.
On Sun, Apr 6, 2014 at 11:49 PM, Kenneth Graunke wrote:
> Performance warnings are logged via KHR_debug in addition to when the
> INTEL_DEBUG=perf environment variable is set. Without this, messages in
> debug contexts would have "(null)" for the reason.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index ad9c1f5..7eac9ad 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -697,7 +697,7 @@ fs_visitor::no16(const char *format, ...)
> } else {
>simd16_unsupported = true;
>
> - if (INTEL_DEBUG & DEBUG_PERF) {
> + if (brw->perf_debug) {
> if (no16_msg)
> ralloc_vasprintf_append(&no16_msg, format, va);
> else
> --
> 1.9.0
1-8 are
Reviewed-by: Matt Turner
I sent a (different) comment about #9.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77152] New: libglapi.so: undefined reference to `entry_get_public'
https://bugs.freedesktop.org/show_bug.cgi?id=77152 Priority: medium Bug ID: 77152 Keywords: regression CC: matts...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: libglapi.so: undefined reference to `entry_get_public' Severity: blocker Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Mesa core Product: Mesa mesa: 144bbb7b78ecac33c62c6dc28df1747a73c4eb39 (master 10.2.0-devel) $ make [...] CXX check_table.o CXXLDshared-glapi-test ../../../../src/mapi/shared-glapi/.libs/libglapi.so: undefined reference to `entry_get_public' ../../../../src/mapi/shared-glapi/.libs/libglapi.so: undefined reference to `entry_patch_public' ../../../../src/mapi/shared-glapi/.libs/libglapi.so: undefined reference to `entry_generate' ../../../../src/mapi/shared-glapi/.libs/libglapi.so: undefined reference to `entry_patch' -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Use M_PI_* macros.
On 04/07/2014 10:28 AM, Aaron Watry wrote:
> On Mon, Apr 7, 2014 at 12:19 PM, Matt Turner wrote:
>> Notice our multiple values for M_PI_2, which rounded ...32 up to
>> ...4 and ...5.
>> ---
>> The float casts are ugly. I tried to define M_PI_2f using the
>> preprocessor -- something like
>>#define M_PI_2f M_PI_2##f
>> but no luck.
>>
>> src/glsl/builtin_functions.cpp | 14 +++---
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
>> index 26ea923..62bf154 100644
>> --- a/src/glsl/builtin_functions.cpp
>> +++ b/src/glsl/builtin_functions.cpp
>> @@ -2538,11 +2538,11 @@ ir_expression *
>> builtin_builder::asin_expr(ir_variable *x)
>> {
>> return mul(sign(x),
>> - sub(imm(1.5707964f),
>> + sub(imm((float)M_PI_2),
>>mul(sqrt(sub(imm(1.0f), abs(x))),
>> - add(imm(1.5707964f),
>> + add(imm((float)M_PI_2),
>>mul(abs(x),
>> - add(imm(-0.21460183f),
>> + add(imm((float)(1.0 - M_PI_4)),
>
> 1 - M_PI_4 comes out to 0.21460 (positive), not -0.21460. You
> probably want to switch the operand order in the subtraction here
> (unless this change was intentional).
There are a couple asin() tests, so it seems like this should have
caused at least one of them to fail... Matt, did you run all of piglit?
If this didn't cause an existing test to fail, we should add a new test.
> --Aaron
>
>>mul(abs(x),
>>add(imm(0.086566724f),
>>mul(abs(x),
>> imm(-0.03102955f));
>> @@ -2586,7 +2586,7 @@ builtin_builder::_acos(const glsl_type *type)
>> ir_variable *x = in_var(type, "x");
>> MAKE_SIG(type, always_available, 1, x);
>>
>> - body.emit(ret(sub(imm(1.5707964f), asin_expr(x;
>> + body.emit(ret(sub(imm((float)M_PI_2), asin_expr(x;
>>
>> return sig;
>> }
>> @@ -2623,13 +2623,13 @@ builtin_builder::_atan2(const glsl_type *type)
>>ir_if *inner_if = new(mem_ctx) ir_if(less(x, imm(0.0f)));
>>inner_if->then_instructions.push_tail(
>> if_tree(gequal(y, imm(0.0f)),
>> - assign(r, add(r, imm(3.141593f))),
>> - assign(r, sub(r, imm(3.141593f);
>> + assign(r, add(r, imm((float)M_PI))),
>> + assign(r, sub(r, imm((float)M_PI);
>>outer_then.emit(inner_if);
>>
>>/* Else... */
>>outer_if->else_instructions.push_tail(
>> - assign(r, mul(sign(y), imm(1.5707965f;
>> + assign(r, mul(sign(y), imm((float)M_PI_2;
>>
>>body.emit(outer_if);
>>
>> --
>> 1.8.3.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] Mesa 10.2 release plan strawman
On 04/07/2014 09:14 AM, Eric Anholt wrote: > Ian Romanick writes: > >> On 04/04/2014 05:52 PM, Matt Turner wrote: >>> On Fri, Apr 4, 2014 at 5:18 PM, Ian Romanick wrote: Fast forwarding 3 months from the 10.1 release (March 4th, planned for February 28th) is May 30th. I'd like to propose the following set of dates: May 2nd: Feature freeze / 10.2 branch created. May 16th: RC1 >>> >>> Same comment as last time. It's not clear to me that we need a week >>> between the branch and RC1. We're not going to get users testing the >>> branch until there's an RC that distros can offer. >> >> The thinking behind having some gap is that a lot of people don't change >> from feature work to bug fixing until the branch is made. There are >> usually a bunch of bug fixes landed right after the branch is made... >> there's also often a bunch of... chaos right before the branch is made. >> Having an RC that doesn't build, has lot of known bugs, etc is useless. >> Having a time gap between features landing and making RC1 allows things >> to settle down a bit. >> >> I thought your complaint before was that a week wasn't long enough. >> That's why I bumped it to two weeks this time. I guess I must have >> misunderstood the concern. > > FWIW, I also don't see the point in having the branch but no RC. What's the point of having an RC is that is complete garbage? If you can explain that to me, I will do the work of creating it. Otherwise, I'll just skip the pointless busywork kthanks. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/vec4: Add a test for copy propagation behavior.
I thought I was seeing a bug in the code while reviewing, but it's not
there.
---
src/mesa/drivers/dri/i965/.gitignore | 1 +
src/mesa/drivers/dri/i965/Makefile.am | 7 +
.../dri/i965/test_vec4_copy_propagation.cpp| 156 +
3 files changed, 164 insertions(+)
create mode 100644 src/mesa/drivers/dri/i965/test_vec4_copy_propagation.cpp
diff --git a/src/mesa/drivers/dri/i965/.gitignore
b/src/mesa/drivers/dri/i965/.gitignore
index 777e8d9..3cf4ba0 100644
--- a/src/mesa/drivers/dri/i965/.gitignore
+++ b/src/mesa/drivers/dri/i965/.gitignore
@@ -1,4 +1,5 @@
i965_symbols_test
test_eu_compact
+test_vec4_copy_propagation
test_vec4_register_coalesce
test_blorp_blit_eu_gen
diff --git a/src/mesa/drivers/dri/i965/Makefile.am
b/src/mesa/drivers/dri/i965/Makefile.am
index 54a38bd..7ab376c 100644
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/mesa/drivers/dri/i965/Makefile.am
@@ -55,6 +55,7 @@ TEST_LIBS = \
TESTS = \
test_eu_compact \
+test_vec4_copy_propagation \
test_vec4_register_coalesce \
test_blorp_blit_eu_gen
@@ -66,6 +67,12 @@ test_vec4_register_coalesce_LDADD = \
$(TEST_LIBS) \
$(top_builddir)/src/gtest/libgtest.la
+test_vec4_copy_propagation_SOURCES = \
+ test_vec4_copy_propagation.cpp
+test_vec4_copy_propagation_LDADD = \
+$(TEST_LIBS) \
+$(top_builddir)/src/gtest/libgtest.la
+
test_eu_compact_SOURCES = \
test_eu_compact.c
nodist_EXTRA_test_eu_compact_SOURCES = dummy.cpp
diff --git a/src/mesa/drivers/dri/i965/test_vec4_copy_propagation.cpp
b/src/mesa/drivers/dri/i965/test_vec4_copy_propagation.cpp
new file mode 100644
index 000..cb70096
--- /dev/null
+++ b/src/mesa/drivers/dri/i965/test_vec4_copy_propagation.cpp
@@ -0,0 +1,156 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include
+#include "brw_vec4.h"
+#include "brw_vs.h"
+
+using namespace brw;
+
+int ret = 0;
+
+class copy_propagation_test : public ::testing::Test {
+ virtual void SetUp();
+
+public:
+ struct brw_context *brw;
+ struct gl_context *ctx;
+ struct gl_shader_program *shader_prog;
+ struct brw_vertex_program *vp;
+ vec4_visitor *v;
+};
+
+class copy_propagation_vec4_visitor : public vec4_visitor
+{
+public:
+ copy_propagation_vec4_visitor(struct brw_context *brw,
+ struct gl_shader_program *shader_prog)
+ : vec4_visitor(brw, NULL, NULL, NULL, NULL, shader_prog,
+ MESA_SHADER_VERTEX, NULL,
+ false, false /* no_spills */,
+ ST_NONE, ST_NONE, ST_NONE)
+ {
+ }
+
+protected:
+ virtual dst_reg *make_reg_for_system_value(ir_variable *ir)
+ {
+ assert(!"Not reached");
+ return NULL;
+ }
+
+ virtual void setup_payload()
+ {
+ assert(!"Not reached");
+ }
+
+ virtual void emit_prolog()
+ {
+ assert(!"Not reached");
+ }
+
+ virtual void emit_program_code()
+ {
+ assert(!"Not reached");
+ }
+
+ virtual void emit_thread_end()
+ {
+ assert(!"Not reached");
+ }
+
+ virtual void emit_urb_write_header(int mrf)
+ {
+ assert(!"Not reached");
+ }
+
+ virtual vec4_instruction *emit_urb_write_opcode(bool complete)
+ {
+ assert(!"Not reached");
+ unreachable();
+ }
+};
+
+
+void copy_propagation_test::SetUp()
+{
+ brw = (struct brw_context *)calloc(1, sizeof(*brw));
+ ctx = &brw->ctx;
+
+ vp = ralloc(NULL, struct brw_vertex_program);
+
+ shader_prog = ralloc(NULL, struct gl_shader_program);
+
+ v = new copy_propagation_vec4_visitor(brw, shader_prog);
+
+ _mesa_init_vertex_program(ctx, &vp->program, GL_VERTEX_SHADER, 0);
+
+ brw->gen = 4;
+}
+
+static void
+copy_propagation(vec4_visitor *v)
+{
+ bool print = false;
+
+ if (print) {
+ fprintf(stderr, "instructions bef
Re: [Mesa-dev] [PATCH] i965/vec4: fix record clearing in copy propagation
Chia-I Wu writes: > From: Chia-I Wu > > Given > > mov vgrf7, vgrf9.xyxz > add vgrf9.xyz, vgrf4.xyzw, vgrf5.xyzw > add vgrf10.x, vgrf6.xyzw, vgrf7. > > the last instruction would be wrongly changed to > > add vgrf10.x, vgrf6.xyzw, vgrf9. > > during copy propagation. > > The issue is that when deciding if a record should be cleared, the old code > checked for > > inst->dst.writemask & (1 << ch) > > instead of > > inst->dst.writemask & (1 << BRW_GET_SWZ(src->swizzle, ch)) > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76749 > Signed-off-by: Chia-I Wu > Cc: Jordan Justen > Cc: Matt Turner Reviewed-by: Eric Anholt I've just sent a patch for adding a unit test of copy propagation -- it would be nice to see an additional test on top of that for this bug. pgpwgE9B1r8lz.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] gallium/u_gen_mipmap: rewrite using pipe->blit (v2)
From: Marek Olšák
This replaces u_gen_mipmap with an extremely simple implementation based
on pipe->blit. st/mesa is also cleaned up.
Pros:
- less code
- correct mipmap generation for NPOT 3D textures (u_blitter uses a better
formula)
- queries are not affected by mipmap generation if drivers disable them
v2: add "first_layer", "last_layer" parameters, drop "face"
v2.1: add format
---
src/gallium/auxiliary/util/u_gen_mipmap.c | 539 --
src/gallium/auxiliary/util/u_gen_mipmap.h | 23 +-
src/mesa/state_tracker/st_context.c | 2 -
src/mesa/state_tracker/st_context.h | 1 -
src/mesa/state_tracker/st_gen_mipmap.c| 73 +---
src/mesa/state_tracker/st_gen_mipmap.h| 8 -
6 files changed, 80 insertions(+), 566 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_gen_mipmap.c
b/src/gallium/auxiliary/util/u_gen_mipmap.c
index a2f4218..4325fdc 100644
--- a/src/gallium/auxiliary/util/u_gen_mipmap.c
+++ b/src/gallium/auxiliary/util/u_gen_mipmap.c
@@ -3,6 +3,7 @@
* Copyright 2008 VMware, Inc.
* All Rights Reserved.
* Copyright 2008 VMware, Inc. All rights reserved.
+ * Copyright 2014 Advanced Micro Devices, Inc.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the
@@ -30,509 +31,97 @@
* @file
* Mipmap generation utility
*
- * @author Brian Paul
+ * @author Brian Paul, Marek Olšák
*/
-#include "pipe/p_context.h"
-#include "util/u_debug.h"
-#include "pipe/p_defines.h"
-#include "util/u_inlines.h"
-#include "pipe/p_shader_tokens.h"
-#include "pipe/p_state.h"
-
-#include "util/u_format.h"
-#include "util/u_memory.h"
-#include "util/u_draw_quad.h"
#include "util/u_gen_mipmap.h"
-#include "util/u_simple_shaders.h"
-#include "util/u_math.h"
-#include "util/u_texture.h"
-#include "util/u_half.h"
-#include "util/u_surface.h"
-
-#include "cso_cache/cso_context.h"
-
-
-struct gen_mipmap_state
-{
- struct pipe_context *pipe;
- struct cso_context *cso;
-
- struct pipe_blend_state blend_keep_color, blend_write_color;
- struct pipe_depth_stencil_alpha_state dsa_keep_depth, dsa_write_depth;
- struct pipe_rasterizer_state rasterizer;
- struct pipe_sampler_state sampler;
- struct pipe_vertex_element velem[2];
-
- void *vs;
-
- /** Not all are used, but simplifies code */
- void *fs_color[TGSI_TEXTURE_COUNT];
- void *fs_depth[TGSI_TEXTURE_COUNT];
-
- struct pipe_resource *vbuf; /**< quad vertices */
- unsigned vbuf_slot;
-
- float vertices[4][2][4]; /**< vertex/texcoords for quad */
-};
-
-
-/**
- * Create a mipmap generation context.
- * The idea is to create one of these and re-use it each time we need to
- * generate a mipmap.
- */
-struct gen_mipmap_state *
-util_create_gen_mipmap(struct pipe_context *pipe,
- struct cso_context *cso)
-{
- struct gen_mipmap_state *ctx;
- uint i;
-
- ctx = CALLOC_STRUCT(gen_mipmap_state);
- if (!ctx)
- return NULL;
-
- ctx->pipe = pipe;
- ctx->cso = cso;
-
- /* disabled blending/masking */
- memset(&ctx->blend_keep_color, 0, sizeof(ctx->blend_keep_color));
- memset(&ctx->blend_write_color, 0, sizeof(ctx->blend_write_color));
- ctx->blend_write_color.rt[0].colormask = PIPE_MASK_RGBA;
-
- /* no-op depth/stencil/alpha */
- memset(&ctx->dsa_keep_depth, 0, sizeof(ctx->dsa_keep_depth));
- memset(&ctx->dsa_write_depth, 0, sizeof(ctx->dsa_write_depth));
- ctx->dsa_write_depth.depth.enabled = 1;
- ctx->dsa_write_depth.depth.func = PIPE_FUNC_ALWAYS;
- ctx->dsa_write_depth.depth.writemask = 1;
-
- /* rasterizer */
- memset(&ctx->rasterizer, 0, sizeof(ctx->rasterizer));
- ctx->rasterizer.cull_face = PIPE_FACE_NONE;
- ctx->rasterizer.half_pixel_center = 1;
- ctx->rasterizer.bottom_edge_rule = 1;
- ctx->rasterizer.depth_clip = 1;
-
- /* sampler state */
- memset(&ctx->sampler, 0, sizeof(ctx->sampler));
- ctx->sampler.wrap_s = PIPE_TEX_WRAP_CLAMP_TO_EDGE;
- ctx->sampler.wrap_t = PIPE_TEX_WRAP_CLAMP_TO_EDGE;
- ctx->sampler.wrap_r = PIPE_TEX_WRAP_CLAMP_TO_EDGE;
- ctx->sampler.min_mip_filter = PIPE_TEX_MIPFILTER_NEAREST;
- ctx->sampler.normalized_coords = 1;
-
- /* vertex elements state */
- memset(&ctx->velem[0], 0, sizeof(ctx->velem[0]) * 2);
- for (i = 0; i < 2; i++) {
- ctx->velem[i].src_offset = i * 4 * sizeof(float);
- ctx->velem[i].instance_divisor = 0;
- ctx->velem[i].vertex_buffer_index = cso_get_aux_vertex_buffer_slot(cso);
- ctx->velem[i].src_format = PIPE_FORMAT_R32G32B32A32_FLOAT;
- }
-
- /* vertex data that doesn't change */
- for (i = 0; i < 4; i++) {
- ctx->vertices[i][0][2] = 0.0f; /* z */
- ctx->vertices[i][0][3] = 1.0f; /* w */
- ctx->vertices[i][1][3] = 1.0f; /* q */
- }
-
- /* Note: the actual vertex buffer is allocated as needed below */
-
- return ctx;
-}
-
-
-/**
- * Helper function to set the fragment shaders.
- */
-static INLINE void
-set_fragment_shad
[Mesa-dev] [PATCH] swrast: Add glBlitFramebuffer to commands affected by conditional rendering
Signed-off-by: Anuj Phogat
---
src/mesa/swrast/s_blit.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/swrast/s_blit.c b/src/mesa/swrast/s_blit.c
index 1ba188c..e3b45f1 100644
--- a/src/mesa/swrast/s_blit.c
+++ b/src/mesa/swrast/s_blit.c
@@ -29,6 +29,7 @@
#include "main/macros.h"
#include "main/format_unpack.h"
#include "main/format_pack.h"
+#include "main/condrender.h"
#include "s_context.h"
@@ -748,6 +749,13 @@ _swrast_BlitFramebuffer(struct gl_context *ctx,
};
GLint i;
+ /* Page 679 of OpenGL 4.4 spec says:
+*"Added BlitFramebuffer to commands affected by conditional rendering
in
+* section 10.10 (Bug 9562)."
+*/
+ if (!_mesa_check_conditional_render(ctx))
+ return; /* Do not blit */
+
if (!_mesa_clip_blit(ctx, &srcX0, &srcY0, &srcX1, &srcY1,
&dstX0, &dstY0, &dstX1, &dstY1)) {
return;
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: add bounds checking to eliminate buffer overrun
Updated patch to include reference to bug that it resolves. Since this fixes a buffer overrun in the driver (found running GLBenchmark's Manhattan test) I think it would be a good candidate for the stable branch. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] gallium/u_gen_mipmap: rewrite using pipe->blit (v2)
Just a trivial comment, otherwise looks good to me.
Thanks!
Roland
Am 07.04.2014 21:05, schrieb Marek Olšák:
> From: Marek Olšák
>
> This replaces u_gen_mipmap with an extremely simple implementation based
> on pipe->blit. st/mesa is also cleaned up.
>
> Pros:
> - less code
> - correct mipmap generation for NPOT 3D textures (u_blitter uses a better
> formula)
> - queries are not affected by mipmap generation if drivers disable them
>
> v2: add "first_layer", "last_layer" parameters, drop "face"
> v2.1: add format
> ---
> src/gallium/auxiliary/util/u_gen_mipmap.c | 539
> --
> src/gallium/auxiliary/util/u_gen_mipmap.h | 23 +-
> src/mesa/state_tracker/st_context.c | 2 -
> src/mesa/state_tracker/st_context.h | 1 -
> src/mesa/state_tracker/st_gen_mipmap.c| 73 +---
> src/mesa/state_tracker/st_gen_mipmap.h| 8 -
> 6 files changed, 80 insertions(+), 566 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_gen_mipmap.c
> b/src/gallium/auxiliary/util/u_gen_mipmap.c
> index a2f4218..4325fdc 100644
> --- a/src/gallium/auxiliary/util/u_gen_mipmap.c
> +++ b/src/gallium/auxiliary/util/u_gen_mipmap.c
> @@ -3,6 +3,7 @@
> * Copyright 2008 VMware, Inc.
> * All Rights Reserved.
> * Copyright 2008 VMware, Inc. All rights reserved.
> + * Copyright 2014 Advanced Micro Devices, Inc.
> *
> * Permission is hereby granted, free of charge, to any person obtaining a
> * copy of this software and associated documentation files (the
> @@ -30,509 +31,97 @@
> * @file
> * Mipmap generation utility
> *
> - * @author Brian Paul
> + * @author Brian Paul, Marek Olšák
> */
>
>
> -#include "pipe/p_context.h"
> -#include "util/u_debug.h"
> -#include "pipe/p_defines.h"
> -#include "util/u_inlines.h"
> -#include "pipe/p_shader_tokens.h"
> -#include "pipe/p_state.h"
> -
> -#include "util/u_format.h"
> -#include "util/u_memory.h"
> -#include "util/u_draw_quad.h"
> #include "util/u_gen_mipmap.h"
> -#include "util/u_simple_shaders.h"
> -#include "util/u_math.h"
> -#include "util/u_texture.h"
> -#include "util/u_half.h"
> -#include "util/u_surface.h"
> -
> -#include "cso_cache/cso_context.h"
> -
> -
> -struct gen_mipmap_state
> -{
> - struct pipe_context *pipe;
> - struct cso_context *cso;
> -
> - struct pipe_blend_state blend_keep_color, blend_write_color;
> - struct pipe_depth_stencil_alpha_state dsa_keep_depth, dsa_write_depth;
> - struct pipe_rasterizer_state rasterizer;
> - struct pipe_sampler_state sampler;
> - struct pipe_vertex_element velem[2];
> -
> - void *vs;
> -
> - /** Not all are used, but simplifies code */
> - void *fs_color[TGSI_TEXTURE_COUNT];
> - void *fs_depth[TGSI_TEXTURE_COUNT];
> -
> - struct pipe_resource *vbuf; /**< quad vertices */
> - unsigned vbuf_slot;
> -
> - float vertices[4][2][4]; /**< vertex/texcoords for quad */
> -};
> -
> -
> -/**
> - * Create a mipmap generation context.
> - * The idea is to create one of these and re-use it each time we need to
> - * generate a mipmap.
> - */
> -struct gen_mipmap_state *
> -util_create_gen_mipmap(struct pipe_context *pipe,
> - struct cso_context *cso)
> -{
> - struct gen_mipmap_state *ctx;
> - uint i;
> -
> - ctx = CALLOC_STRUCT(gen_mipmap_state);
> - if (!ctx)
> - return NULL;
> -
> - ctx->pipe = pipe;
> - ctx->cso = cso;
> -
> - /* disabled blending/masking */
> - memset(&ctx->blend_keep_color, 0, sizeof(ctx->blend_keep_color));
> - memset(&ctx->blend_write_color, 0, sizeof(ctx->blend_write_color));
> - ctx->blend_write_color.rt[0].colormask = PIPE_MASK_RGBA;
> -
> - /* no-op depth/stencil/alpha */
> - memset(&ctx->dsa_keep_depth, 0, sizeof(ctx->dsa_keep_depth));
> - memset(&ctx->dsa_write_depth, 0, sizeof(ctx->dsa_write_depth));
> - ctx->dsa_write_depth.depth.enabled = 1;
> - ctx->dsa_write_depth.depth.func = PIPE_FUNC_ALWAYS;
> - ctx->dsa_write_depth.depth.writemask = 1;
> -
> - /* rasterizer */
> - memset(&ctx->rasterizer, 0, sizeof(ctx->rasterizer));
> - ctx->rasterizer.cull_face = PIPE_FACE_NONE;
> - ctx->rasterizer.half_pixel_center = 1;
> - ctx->rasterizer.bottom_edge_rule = 1;
> - ctx->rasterizer.depth_clip = 1;
> -
> - /* sampler state */
> - memset(&ctx->sampler, 0, sizeof(ctx->sampler));
> - ctx->sampler.wrap_s = PIPE_TEX_WRAP_CLAMP_TO_EDGE;
> - ctx->sampler.wrap_t = PIPE_TEX_WRAP_CLAMP_TO_EDGE;
> - ctx->sampler.wrap_r = PIPE_TEX_WRAP_CLAMP_TO_EDGE;
> - ctx->sampler.min_mip_filter = PIPE_TEX_MIPFILTER_NEAREST;
> - ctx->sampler.normalized_coords = 1;
> -
> - /* vertex elements state */
> - memset(&ctx->velem[0], 0, sizeof(ctx->velem[0]) * 2);
> - for (i = 0; i < 2; i++) {
> - ctx->velem[i].src_offset = i * 4 * sizeof(float);
> - ctx->velem[i].instance_divisor = 0;
> - ctx->velem[i].vertex_buffer_index =
> cso_get_aux_vertex_buffer_slot(cso);
> - ctx->velem[i].src_format = PIPE_FORMAT_R32G32B32A32_FLOAT;
> - }
> -
> - /
[Mesa-dev] [PATCH 02/12] mesa: add missing null checks in _tnl_register_fastpath()
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Matt Turner
---
src/mesa/tnl/t_vertex.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/mesa/tnl/t_vertex.c b/src/mesa/tnl/t_vertex.c
index b3deac0..5a4bb0b 100644
--- a/src/mesa/tnl/t_vertex.c
+++ b/src/mesa/tnl/t_vertex.c
@@ -83,12 +83,22 @@ void _tnl_register_fastpath( struct tnl_clipspace *vtx,
struct tnl_clipspace_fastpath *fastpath =
CALLOC_STRUCT(tnl_clipspace_fastpath);
GLuint i;
+ if (fastpath == NULL) {
+ _mesa_error_no_memory(__func__);
+ return;
+ }
+
fastpath->vertex_size = vtx->vertex_size;
fastpath->attr_count = vtx->attr_count;
fastpath->match_strides = match_strides;
fastpath->func = vtx->emit;
- fastpath->attr =
- malloc(vtx->attr_count * sizeof(fastpath->attr[0]));
+ fastpath->attr = malloc(vtx->attr_count * sizeof(fastpath->attr[0]));
+
+ if (fastpath->attr == NULL) {
+ FREE(fastpath);
+ _mesa_error_no_memory(__func__);
+ return;
+ }
for (i = 0; i < vtx->attr_count; i++) {
fastpath->attr[i].format = vtx->attr[i].format;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/12] Again Klocwork patches
Set of patches which mostly were here earlier, hope I did not this time miss any comments. #12 is new to the set. These pass Piglit quick tests with no regression on my Ivybridge. /Juha-Pekka Ian Romanick (1): mesa: Add _mesa_error_no_memory for logging out-of-memory messages Juha-Pekka Heikkila (11): mesa: add missing null checks in _tnl_register_fastpath() mesa: add extra null checks in vbo_rebase_prims() mesa: In emit_texenv() type mismatch was forced with typecast mesa: Add missing null checks into prog_hash_table.c glsl: add missing null check in tfeedback_decl::init() mesa: add missing null check in _mesa_NewHashTable() i965: check malloc return value in intel_resolve_map_set() mesa: add null checks in symbol_table.c glsl: Add null check in loop_analysis.cpp glsl: check _mesa_hash_table_create return value in link_uniform_blocks i965/fs: Check variable_storage return value in fs_visitor::visit src/glsl/Makefile.am | 13 src/glsl/link_uniform_blocks.cpp | 5 + src/glsl/link_varyings.cpp| 5 + src/glsl/loop_analysis.cpp| 6 -- src/glsl/main.cpp | 6 ++ src/glsl/tests/common.c | 30 +++ src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 6 ++ src/mesa/drivers/dri/i965/intel_resolve_map.c | 7 +++ src/mesa/main/errors.c| 6 ++ src/mesa/main/errors.h| 3 +++ src/mesa/main/ff_fragment_shader.cpp | 17 --- src/mesa/main/hash.c | 10 + src/mesa/program/prog_hash_table.c| 8 +++ src/mesa/program/symbol_table.c | 30 +++ src/mesa/tnl/t_vertex.c | 14 +++-- src/mesa/vbo/vbo_rebase.c | 19 + 16 files changed, 169 insertions(+), 16 deletions(-) create mode 100644 src/glsl/tests/common.c -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/12] mesa: add extra null checks in vbo_rebase_prims()
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Matt Turner
---
src/mesa/vbo/vbo_rebase.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/src/mesa/vbo/vbo_rebase.c b/src/mesa/vbo/vbo_rebase.c
index f3fe5f7..374d129 100644
--- a/src/mesa/vbo/vbo_rebase.c
+++ b/src/mesa/vbo/vbo_rebase.c
@@ -60,6 +60,11 @@ static void *rebase_##TYPE( const void *ptr,
\
{ \
const TYPE *in = (TYPE *)ptr; \
TYPE *tmp_indices = malloc(count * sizeof(TYPE)); \
+ if (tmp_indices == NULL) { \
+ _mesa_error_no_memory(__func__); \
+ return NULL; \
+ }\
+ \
GLuint i; \
\
for (i = 0; i < count; i++) \
@@ -148,6 +153,11 @@ void vbo_rebase_prims( struct gl_context *ctx,
*/
tmp_prims = malloc(sizeof(*prim) * nr_prims);
+ if (tmp_prims == NULL) {
+ _mesa_error_no_memory(__func__);
+ return;
+ }
+
for (i = 0; i < nr_prims; i++) {
tmp_prims[i] = prim[i];
tmp_prims[i].basevertex -= min_index;
@@ -186,6 +196,10 @@ void vbo_rebase_prims( struct gl_context *ctx,
if (map_ib)
ctx->Driver.UnmapBuffer(ctx, ib->obj, MAP_INTERNAL);
+ if (tmp_indices == NULL) {
+ return;
+ }
+
tmp_ib.obj = ctx->Shared->NullBufferObj;
tmp_ib.ptr = tmp_indices;
tmp_ib.count = ib->count;
@@ -198,6 +212,11 @@ void vbo_rebase_prims( struct gl_context *ctx,
*/
tmp_prims = malloc(sizeof(*prim) * nr_prims);
+ if (tmp_prims == NULL) {
+ _mesa_error_no_memory(__func__);
+ return;
+ }
+
for (i = 0; i < nr_prims; i++) {
/* If this fails, it could indicate an application error:
*/
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/12] mesa: Add _mesa_error_no_memory for logging out-of-memory messages
From: Ian Romanick
This can be called from locations that don't have a context pointer
handy. This patch also adds enough infrastructure so that the unit
tests for the GLSL compiler and the stand-alone compiler will build and
function.
This patch was originally signed off by Ian Romanick, now v2 fixed
from breaking the build by Juha-Pekka Heikkilä
Signed-off-by: Juha-Pekka Heikkila
Cc: Ian Romanick
---
src/glsl/Makefile.am| 13 +
src/glsl/main.cpp | 6 ++
src/glsl/tests/common.c | 30 ++
src/mesa/main/errors.c | 6 ++
src/mesa/main/errors.h | 3 +++
5 files changed, 54 insertions(+), 4 deletions(-)
create mode 100644 src/glsl/tests/common.c
diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
index 534eaa3..2cd98a5 100644
--- a/src/glsl/Makefile.am
+++ b/src/glsl/Makefile.am
@@ -61,7 +61,8 @@ tests_general_ir_test_SOURCES = \
$(GLSL_SRCDIR)/standalone_scaffolding.cpp \
tests/builtin_variable_test.cpp \
tests/invalidate_locations_test.cpp \
- tests/general_ir_test.cpp
+ tests/general_ir_test.cpp \
+ tests/common.c
tests_general_ir_test_CFLAGS = \
$(PTHREAD_CFLAGS)
tests_general_ir_test_LDADD = \
@@ -76,7 +77,8 @@ tests_uniform_initializer_test_SOURCES = \
$(top_srcdir)/src/mesa/program/symbol_table.c \
tests/copy_constant_to_storage_tests.cpp\
tests/set_uniform_initializer_tests.cpp \
- tests/uniform_initializer_utils.cpp
+ tests/uniform_initializer_utils.cpp \
+ tests/common.c
tests_uniform_initializer_test_CFLAGS =\
$(PTHREAD_CFLAGS)
tests_uniform_initializer_test_LDADD = \
@@ -95,7 +97,8 @@ tests_ralloc_test_LDADD = \
tests_sampler_types_test_SOURCES = \
$(top_srcdir)/src/mesa/program/prog_hash_table.c\
$(top_srcdir)/src/mesa/program/symbol_table.c \
- tests/sampler_types_test.cpp
+ tests/sampler_types_test.cpp\
+ tests/common.c
tests_sampler_types_test_CFLAGS = \
$(PTHREAD_CFLAGS)
tests_sampler_types_test_LDADD = \
@@ -110,7 +113,8 @@ libglcpp_la_SOURCES =
\
glcpp_glcpp_SOURCES = \
glcpp/glcpp.c \
- $(top_srcdir)/src/mesa/program/prog_hash_table.c
+ $(top_srcdir)/src/mesa/program/prog_hash_table.c \
+ tests/common.c
glcpp_glcpp_LDADD =\
libglcpp.la \
-lm
@@ -138,6 +142,7 @@ glsl_test_SOURCES = \
$(top_srcdir)/src/mesa/program/prog_hash_table.c \
$(top_srcdir)/src/mesa/program/symbol_table.c \
$(GLSL_SRCDIR)/standalone_scaffolding.cpp \
+ tests/common.c \
test.cpp \
test_optpass.cpp
diff --git a/src/glsl/main.cpp b/src/glsl/main.cpp
index 4ae8f09..a4452e0 100644
--- a/src/glsl/main.cpp
+++ b/src/glsl/main.cpp
@@ -40,6 +40,12 @@
static int glsl_version = 330;
+extern "C" void
+_mesa_error_no_memory(const char *caller)
+{
+ fprintf(stderr, "Mesa error: out of memory in %s", caller);
+}
+
static void
initialize_context(struct gl_context *ctx, gl_api api)
{
diff --git a/src/glsl/tests/common.c b/src/glsl/tests/common.c
new file mode 100644
index 000..d69f54d
--- /dev/null
+++ b/src/glsl/tests/common.c
@@ -0,0 +1,30 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+#include
+#include "main/errors.h"
+
+void
+_mesa_error_no_memory(const char *caller)
+{
+ fprintf(stderr, "Mesa error: out of m
[Mesa-dev] [PATCH 06/12] glsl: add missing null check in tfeedback_decl::init()
Signed-off-by: Juha-Pekka Heikkila
---
src/glsl/link_varyings.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index c925c00..c3cc509 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -278,6 +278,11 @@ tfeedback_decl::init(struct gl_context *ctx, const void
*mem_ctx,
const char *base_name_end;
long subscript = parse_program_resource_name(input, &base_name_end);
this->var_name = ralloc_strndup(mem_ctx, input, base_name_end - input);
+ if (this->var_name == NULL) {
+ _mesa_error_no_memory(__func__);
+ return;
+ }
+
if (subscript >= 0) {
this->array_subscript = subscript;
this->is_subscripted = true;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/12] mesa: Add missing null checks into prog_hash_table.c
Check calloc return values in hash_table_insert() and
hash_table_replace()
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/program/prog_hash_table.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/program/prog_hash_table.c
b/src/mesa/program/prog_hash_table.c
index f45ed46..2445d84 100644
--- a/src/mesa/program/prog_hash_table.c
+++ b/src/mesa/program/prog_hash_table.c
@@ -142,6 +142,10 @@ hash_table_insert(struct hash_table *ht, void *data, const
void *key)
struct hash_node *node;
node = calloc(1, sizeof(*node));
+if (node == NULL) {
+ _mesa_error_no_memory(__func__);
+ return;
+}
node->data = data;
node->key = key;
@@ -167,6 +171,10 @@ hash_table_replace(struct hash_table *ht, void *data,
const void *key)
}
hn = calloc(1, sizeof(*hn));
+if (hn == NULL) {
+ _mesa_error_no_memory(__func__);
+ return false;
+}
hn->data = data;
hn->key = key;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/12] mesa: add missing null check in _mesa_NewHashTable()
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/main/hash.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/mesa/main/hash.c b/src/mesa/main/hash.c
index 4c92005..976f7b8 100644
--- a/src/mesa/main/hash.c
+++ b/src/mesa/main/hash.c
@@ -115,10 +115,20 @@ _mesa_NewHashTable(void)
if (table) {
table->ht = _mesa_hash_table_create(NULL, uint_key_compare);
+ if (table->ht == NULL) {
+ FREE(table);
+ _mesa_error_no_memory(__func__);
+ return NULL;
+ }
+
_mesa_hash_table_set_deleted_key(table->ht, uint_key(DELETED_KEY_VALUE));
mtx_init(&table->Mutex, mtx_plain);
mtx_init(&table->WalkMutex, mtx_plain);
}
+ else {
+ _mesa_error_no_memory(__func__);
+ }
+
return table;
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/12] i965: check malloc return value in intel_resolve_map_set()
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/intel_resolve_map.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_resolve_map.c
b/src/mesa/drivers/dri/i965/intel_resolve_map.c
index 04b5c94..c5a4cd7 100644
--- a/src/mesa/drivers/dri/i965/intel_resolve_map.c
+++ b/src/mesa/drivers/dri/i965/intel_resolve_map.c
@@ -22,6 +22,7 @@
*/
#include "intel_resolve_map.h"
+#include "main/imports.h"
#include
#include
@@ -51,6 +52,12 @@ intel_resolve_map_set(struct intel_resolve_map *head,
}
*tail = malloc(sizeof(**tail));
+
+ if (*tail == NULL) {
+ _mesa_error_no_memory(__func__);
+ return;
+ }
+
(*tail)->prev = prev;
(*tail)->next = NULL;
(*tail)->level = level;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 10.2 release plan strawman
On 04/07/2014 11:47 AM, Ian Romanick wrote: > On 04/07/2014 09:14 AM, Eric Anholt wrote: >> Ian Romanick writes: >> >>> On 04/04/2014 05:52 PM, Matt Turner wrote: On Fri, Apr 4, 2014 at 5:18 PM, Ian Romanick wrote: > Fast forwarding 3 months from the 10.1 release (March 4th, planned for > February 28th) is May 30th. I'd like to propose the following set of > dates: > > May 2nd: Feature freeze / 10.2 branch created. > > May 16th: RC1 Same comment as last time. It's not clear to me that we need a week between the branch and RC1. We're not going to get users testing the branch until there's an RC that distros can offer. >>> >>> The thinking behind having some gap is that a lot of people don't change >>> from feature work to bug fixing until the branch is made. There are >>> usually a bunch of bug fixes landed right after the branch is made... >>> there's also often a bunch of... chaos right before the branch is made. >>> Having an RC that doesn't build, has lot of known bugs, etc is useless. >>> Having a time gap between features landing and making RC1 allows things >>> to settle down a bit. >>> >>> I thought your complaint before was that a week wasn't long enough. >>> That's why I bumped it to two weeks this time. I guess I must have >>> misunderstood the concern. >> >> FWIW, I also don't see the point in having the branch but no RC. > > What's the point of having an RC is that is complete garbage? If you > can explain that to me, I will do the work of creating it. Otherwise, > I'll just skip the pointless busywork kthanks. The alternative, which has been rejected every time it has been proposed, is to "close" master for feature work for some amount of time before making the release branch. Since people are accustomed to pushing to master whenever patches are reviewed, and we have no mechanism to control that, this seems unlikely to succeed. This is also effectively what the release branch is, so it feels a bit like tomayto versus tomahto. Look at master for the last two weeks... for at least some users the build has been broken for a good portion of that time. Who does it help to have a release candidate of that? Either way... we previously loosely agreed to a month stabalization period for bug fixes between feature freeze and release. I don't really care how we accomplish that... as long as it will actually work. If you guys feel really strongly about having an RC the moment the branch is made, tell me how to make that successful. Taking the thing that was master 30 seconds previously is not that. What is your suggestion? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/vec4: Add a test for copy propagation behavior.
On 04/07/2014 11:51 AM, Eric Anholt wrote:
> I thought I was seeing a bug in the code while reviewing, but it's not
> there.
One observation below. Regardless,
Reviewed-by: Ian Romanick
> ---
> src/mesa/drivers/dri/i965/.gitignore | 1 +
> src/mesa/drivers/dri/i965/Makefile.am | 7 +
> .../dri/i965/test_vec4_copy_propagation.cpp| 156
> +
> 3 files changed, 164 insertions(+)
> create mode 100644 src/mesa/drivers/dri/i965/test_vec4_copy_propagation.cpp
>
> diff --git a/src/mesa/drivers/dri/i965/.gitignore
> b/src/mesa/drivers/dri/i965/.gitignore
> index 777e8d9..3cf4ba0 100644
> --- a/src/mesa/drivers/dri/i965/.gitignore
> +++ b/src/mesa/drivers/dri/i965/.gitignore
> @@ -1,4 +1,5 @@
> i965_symbols_test
> test_eu_compact
> +test_vec4_copy_propagation
> test_vec4_register_coalesce
> test_blorp_blit_eu_gen
> diff --git a/src/mesa/drivers/dri/i965/Makefile.am
> b/src/mesa/drivers/dri/i965/Makefile.am
> index 54a38bd..7ab376c 100644
> --- a/src/mesa/drivers/dri/i965/Makefile.am
> +++ b/src/mesa/drivers/dri/i965/Makefile.am
> @@ -55,6 +55,7 @@ TEST_LIBS = \
>
> TESTS = \
> test_eu_compact \
> +test_vec4_copy_propagation \
> test_vec4_register_coalesce \
> test_blorp_blit_eu_gen
>
> @@ -66,6 +67,12 @@ test_vec4_register_coalesce_LDADD = \
> $(TEST_LIBS) \
> $(top_builddir)/src/gtest/libgtest.la
>
> +test_vec4_copy_propagation_SOURCES = \
> + test_vec4_copy_propagation.cpp
> +test_vec4_copy_propagation_LDADD = \
> +$(TEST_LIBS) \
> +$(top_builddir)/src/gtest/libgtest.la
> +
> test_eu_compact_SOURCES = \
> test_eu_compact.c
> nodist_EXTRA_test_eu_compact_SOURCES = dummy.cpp
> diff --git a/src/mesa/drivers/dri/i965/test_vec4_copy_propagation.cpp
> b/src/mesa/drivers/dri/i965/test_vec4_copy_propagation.cpp
> new file mode 100644
> index 000..cb70096
> --- /dev/null
> +++ b/src/mesa/drivers/dri/i965/test_vec4_copy_propagation.cpp
> @@ -0,0 +1,156 @@
> +/*
> + * Copyright © 2014 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include
> +#include "brw_vec4.h"
> +#include "brw_vs.h"
> +
> +using namespace brw;
> +
> +int ret = 0;
> +
> +class copy_propagation_test : public ::testing::Test {
> + virtual void SetUp();
> +
> +public:
> + struct brw_context *brw;
> + struct gl_context *ctx;
> + struct gl_shader_program *shader_prog;
> + struct brw_vertex_program *vp;
> + vec4_visitor *v;
> +};
> +
> +class copy_propagation_vec4_visitor : public vec4_visitor
> +{
> +public:
> + copy_propagation_vec4_visitor(struct brw_context *brw,
> + struct gl_shader_program *shader_prog)
> + : vec4_visitor(brw, NULL, NULL, NULL, NULL, shader_prog,
> + MESA_SHADER_VERTEX, NULL,
> + false, false /* no_spills */,
> + ST_NONE, ST_NONE, ST_NONE)
> + {
> + }
> +
> +protected:
> + virtual dst_reg *make_reg_for_system_value(ir_variable *ir)
> + {
> + assert(!"Not reached");
> + return NULL;
> + }
> +
> + virtual void setup_payload()
> + {
> + assert(!"Not reached");
> + }
> +
> + virtual void emit_prolog()
> + {
> + assert(!"Not reached");
> + }
> +
> + virtual void emit_program_code()
> + {
> + assert(!"Not reached");
> + }
> +
> + virtual void emit_thread_end()
> + {
> + assert(!"Not reached");
> + }
> +
> + virtual void emit_urb_write_header(int mrf)
> + {
> + assert(!"Not reached");
> + }
> +
> + virtual vec4_instruction *emit_urb_write_opcode(bool complete)
> + {
> + assert(!"Not reached");
> + unreachable();
> + }
> +};
> +
> +
> +void copy_propagation_test::SetUp()
> +{
> + brw = (struct brw_context *)calloc(1, sizeof(*brw));
> + ctx = &brw-
Re: [Mesa-dev] [PATCH] mesa: add bounds checking to eliminate buffer overrun
On 04/07/2014 12:19 PM, Courtney Goeltzenleuchter wrote: > Updated patch to include reference to bug that it resolves. Where? The proper way to do this is to send the path with git-send-mail, and include extra verbage in the commit message like: v3: Updated patch to include reference to bug that it resolves. Unless, of course, that update is just to add a Bugzilla: line to the commit message. I don't know if that's the change because... :) > Since this fixes a buffer overrun in the driver (found running GLBenchmark's > Manhattan test) I think it would be a good candidate for the stable branch. > > ___ > 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 00/12] Again Klocwork patches
Hmm... Wonder where my patches 9..12 vanished. They show in git send-email as "Result: 250 ok: Message ### accepted". If they don't magically show up here I will resend entire set tomorrow from better connection. /Juha-Pekka On Mon, Apr 7, 2014 at 10:48 PM, Juha-Pekka Heikkila wrote: > Set of patches which mostly were here earlier, hope I did not this time miss > any comments. #12 is new to the set. These pass Piglit quick tests with no > regression on my Ivybridge. > > /Juha-Pekka > > Ian Romanick (1): > mesa: Add _mesa_error_no_memory for logging out-of-memory messages > > Juha-Pekka Heikkila (11): > mesa: add missing null checks in _tnl_register_fastpath() > mesa: add extra null checks in vbo_rebase_prims() > mesa: In emit_texenv() type mismatch was forced with typecast > mesa: Add missing null checks into prog_hash_table.c > glsl: add missing null check in tfeedback_decl::init() > mesa: add missing null check in _mesa_NewHashTable() > i965: check malloc return value in intel_resolve_map_set() > mesa: add null checks in symbol_table.c > glsl: Add null check in loop_analysis.cpp > glsl: check _mesa_hash_table_create return value in > link_uniform_blocks > i965/fs: Check variable_storage return value in fs_visitor::visit > > src/glsl/Makefile.am | 13 > src/glsl/link_uniform_blocks.cpp | 5 + > src/glsl/link_varyings.cpp| 5 + > src/glsl/loop_analysis.cpp| 6 -- > src/glsl/main.cpp | 6 ++ > src/glsl/tests/common.c | 30 > +++ > src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 6 ++ > src/mesa/drivers/dri/i965/intel_resolve_map.c | 7 +++ > src/mesa/main/errors.c| 6 ++ > src/mesa/main/errors.h| 3 +++ > src/mesa/main/ff_fragment_shader.cpp | 17 --- > src/mesa/main/hash.c | 10 + > src/mesa/program/prog_hash_table.c| 8 +++ > src/mesa/program/symbol_table.c | 30 > +++ > src/mesa/tnl/t_vertex.c | 14 +++-- > src/mesa/vbo/vbo_rebase.c | 19 + > 16 files changed, 169 insertions(+), 16 deletions(-) > create mode 100644 src/glsl/tests/common.c > > -- > 1.8.1.2 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/12] Again Klocwork patches
On 07/04/14 21:06, Juha-Pekka Heikkilä wrote: > Hmm... Wonder where my patches 9..12 vanished. They show in git > send-email as "Result: 250 ok: Message ### accepted". If they don't > magically show up here I will resend entire set tomorrow from better > connection. > An innocent bystander type of questions: - Why do you resend the whole series every time, rather than re-sending only the updated patches ? - Noticed that you mention the changes between patch revisions only in some cases. Is that intentional ? Just curious :) -Emil > /Juha-Pekka > > On Mon, Apr 7, 2014 at 10:48 PM, Juha-Pekka Heikkila > wrote: >> Set of patches which mostly were here earlier, hope I did not this time miss >> any comments. #12 is new to the set. These pass Piglit quick tests with no >> regression on my Ivybridge. >> >> /Juha-Pekka >> >> Ian Romanick (1): >> mesa: Add _mesa_error_no_memory for logging out-of-memory messages >> >> Juha-Pekka Heikkila (11): >> mesa: add missing null checks in _tnl_register_fastpath() >> mesa: add extra null checks in vbo_rebase_prims() >> mesa: In emit_texenv() type mismatch was forced with typecast >> mesa: Add missing null checks into prog_hash_table.c >> glsl: add missing null check in tfeedback_decl::init() >> mesa: add missing null check in _mesa_NewHashTable() >> i965: check malloc return value in intel_resolve_map_set() >> mesa: add null checks in symbol_table.c >> glsl: Add null check in loop_analysis.cpp >> glsl: check _mesa_hash_table_create return value in >> link_uniform_blocks >> i965/fs: Check variable_storage return value in fs_visitor::visit >> >> src/glsl/Makefile.am | 13 >> src/glsl/link_uniform_blocks.cpp | 5 + >> src/glsl/link_varyings.cpp| 5 + >> src/glsl/loop_analysis.cpp| 6 -- >> src/glsl/main.cpp | 6 ++ >> src/glsl/tests/common.c | 30 >> +++ >> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 6 ++ >> src/mesa/drivers/dri/i965/intel_resolve_map.c | 7 +++ >> src/mesa/main/errors.c| 6 ++ >> src/mesa/main/errors.h| 3 +++ >> src/mesa/main/ff_fragment_shader.cpp | 17 --- >> src/mesa/main/hash.c | 10 + >> src/mesa/program/prog_hash_table.c| 8 +++ >> src/mesa/program/symbol_table.c | 30 >> +++ >> src/mesa/tnl/t_vertex.c | 14 +++-- >> src/mesa/vbo/vbo_rebase.c | 19 + >> 16 files changed, 169 insertions(+), 16 deletions(-) >> create mode 100644 src/glsl/tests/common.c >> >> -- >> 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] glsl: Use M_PI_* macros.
On Mon, Apr 7, 2014 at 11:39 AM, Ian Romanick wrote:
> On 04/07/2014 10:28 AM, Aaron Watry wrote:
>> On Mon, Apr 7, 2014 at 12:19 PM, Matt Turner wrote:
>>> Notice our multiple values for M_PI_2, which rounded ...32 up to
>>> ...4 and ...5.
>>> ---
>>> The float casts are ugly. I tried to define M_PI_2f using the
>>> preprocessor -- something like
>>>#define M_PI_2f M_PI_2##f
>>> but no luck.
>>>
>>> src/glsl/builtin_functions.cpp | 14 +++---
>>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
>>> index 26ea923..62bf154 100644
>>> --- a/src/glsl/builtin_functions.cpp
>>> +++ b/src/glsl/builtin_functions.cpp
>>> @@ -2538,11 +2538,11 @@ ir_expression *
>>> builtin_builder::asin_expr(ir_variable *x)
>>> {
>>> return mul(sign(x),
>>> - sub(imm(1.5707964f),
>>> + sub(imm((float)M_PI_2),
>>>mul(sqrt(sub(imm(1.0f), abs(x))),
>>> - add(imm(1.5707964f),
>>> + add(imm((float)M_PI_2),
>>>mul(abs(x),
>>> - add(imm(-0.21460183f),
>>> + add(imm((float)(1.0 - M_PI_4)),
>>
>> 1 - M_PI_4 comes out to 0.21460 (positive), not -0.21460. You
>> probably want to switch the operand order in the subtraction here
>> (unless this change was intentional).
>
> There are a couple asin() tests, so it seems like this should have
> caused at least one of them to fail... Matt, did you run all of piglit?
Nope, I didn't. My bad.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xa: Make sure unused samplers are set to NULL
renderer_copy_prepare was setting the first sampler but never telling
the cso code how many samplers were actually used. Fix this.
Cc: "10.1"
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/xa/xa_renderer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_renderer.c
b/src/gallium/state_trackers/xa/xa_renderer.c
index 9ba78be..bbd35f0 100644
--- a/src/gallium/state_trackers/xa/xa_renderer.c
+++ b/src/gallium/state_trackers/xa/xa_renderer.c
@@ -422,6 +422,7 @@ renderer_copy_prepare(struct xa_context *r,
/* sampler */
{
struct pipe_sampler_state sampler;
+const struct pipe_sampler_state *p_sampler = &sampler;
memset(&sampler, 0, sizeof(sampler));
sampler.wrap_s = PIPE_TEX_WRAP_CLAMP_TO_EDGE;
@@ -431,8 +432,8 @@ renderer_copy_prepare(struct xa_context *r,
sampler.min_img_filter = PIPE_TEX_FILTER_NEAREST;
sampler.mag_img_filter = PIPE_TEX_FILTER_NEAREST;
sampler.normalized_coords = 1;
- cso_single_sampler(r->cso, PIPE_SHADER_FRAGMENT, 0, &sampler);
- cso_single_sampler_done(r->cso, PIPE_SHADER_FRAGMENT);
+cso_set_samplers(r->cso, PIPE_SHADER_FRAGMENT, 1, &p_sampler);
+r->num_bound_samplers = 1;
}
renderer_bind_destination(r, dst_surface,
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xa: Make sure unused samplers are set to NULL
On 04/07/2014 02:48 PM, Thomas Hellstrom wrote:
renderer_copy_prepare was setting the first sampler but never telling
the cso code how many samplers were actually used. Fix this.
Cc: "10.1"
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/xa/xa_renderer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_renderer.c
b/src/gallium/state_trackers/xa/xa_renderer.c
index 9ba78be..bbd35f0 100644
--- a/src/gallium/state_trackers/xa/xa_renderer.c
+++ b/src/gallium/state_trackers/xa/xa_renderer.c
@@ -422,6 +422,7 @@ renderer_copy_prepare(struct xa_context *r,
/* sampler */
{
struct pipe_sampler_state sampler;
+const struct pipe_sampler_state *p_sampler = &sampler;
memset(&sampler, 0, sizeof(sampler));
sampler.wrap_s = PIPE_TEX_WRAP_CLAMP_TO_EDGE;
@@ -431,8 +432,8 @@ renderer_copy_prepare(struct xa_context *r,
sampler.min_img_filter = PIPE_TEX_FILTER_NEAREST;
sampler.mag_img_filter = PIPE_TEX_FILTER_NEAREST;
sampler.normalized_coords = 1;
- cso_single_sampler(r->cso, PIPE_SHADER_FRAGMENT, 0, &sampler);
- cso_single_sampler_done(r->cso, PIPE_SHADER_FRAGMENT);
+cso_set_samplers(r->cso, PIPE_SHADER_FRAGMENT, 1, &p_sampler);
+r->num_bound_samplers = 1;
}
renderer_bind_destination(r, dst_surface,
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/12] Again Klocwork patches
On Mon, Apr 7, 2014 at 11:21 PM, Emil Velikov wrote: > On 07/04/14 21:06, Juha-Pekka Heikkilä wrote: >> Hmm... Wonder where my patches 9..12 vanished. They show in git >> send-email as "Result: 250 ok: Message ### accepted". If they don't >> magically show up here I will resend entire set tomorrow from better >> connection. >> > An innocent bystander type of questions: > > - Why do you resend the whole series every time, rather than re-sending only > the updated patches ? The set changes often quite much and due to nature of Klocwork touches totally different areas in Mesa, bookkeeping I guess is not among my best features -- patches in any case reflect the expected change I think. As a side nuance I use gmail for sending patches, gmail strips headers from emails causing I often don't find "Message-Id" field so easy for old emails. If anyone know where to get full email headers with gmail I will be happy to know :) > - Noticed that you mention the changes between patch revisions only in some > cases. Is that intentional ? When the set has gone through bigger change its easier just to ditch the history rather than to strip what's left and what's not. Last I separated reviewed committable patches which Tapani committed to master thus I left the history again out, ie. the amount of patches maybe stay close to same as before but its just because I don't want to over grow the set. In total through these Klocwork patches there went fixes which so far allowed to close 200+ Klocwork reported issues from Mesa. > > Just curious :) > > -Emil > >> /Juha-Pekka >> >> On Mon, Apr 7, 2014 at 10:48 PM, Juha-Pekka Heikkila >> wrote: >>> Set of patches which mostly were here earlier, hope I did not this time miss >>> any comments. #12 is new to the set. These pass Piglit quick tests with no >>> regression on my Ivybridge. >>> >>> /Juha-Pekka >>> >>> Ian Romanick (1): >>> mesa: Add _mesa_error_no_memory for logging out-of-memory messages >>> >>> Juha-Pekka Heikkila (11): >>> mesa: add missing null checks in _tnl_register_fastpath() >>> mesa: add extra null checks in vbo_rebase_prims() >>> mesa: In emit_texenv() type mismatch was forced with typecast >>> mesa: Add missing null checks into prog_hash_table.c >>> glsl: add missing null check in tfeedback_decl::init() >>> mesa: add missing null check in _mesa_NewHashTable() >>> i965: check malloc return value in intel_resolve_map_set() >>> mesa: add null checks in symbol_table.c >>> glsl: Add null check in loop_analysis.cpp >>> glsl: check _mesa_hash_table_create return value in >>> link_uniform_blocks >>> i965/fs: Check variable_storage return value in fs_visitor::visit >>> >>> src/glsl/Makefile.am | 13 >>> src/glsl/link_uniform_blocks.cpp | 5 + >>> src/glsl/link_varyings.cpp| 5 + >>> src/glsl/loop_analysis.cpp| 6 -- >>> src/glsl/main.cpp | 6 ++ >>> src/glsl/tests/common.c | 30 >>> +++ >>> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 6 ++ >>> src/mesa/drivers/dri/i965/intel_resolve_map.c | 7 +++ >>> src/mesa/main/errors.c| 6 ++ >>> src/mesa/main/errors.h| 3 +++ >>> src/mesa/main/ff_fragment_shader.cpp | 17 --- >>> src/mesa/main/hash.c | 10 + >>> src/mesa/program/prog_hash_table.c| 8 +++ >>> src/mesa/program/symbol_table.c | 30 >>> +++ >>> src/mesa/tnl/t_vertex.c | 14 +++-- >>> src/mesa/vbo/vbo_rebase.c | 19 + >>> 16 files changed, 169 insertions(+), 16 deletions(-) >>> create mode 100644 src/glsl/tests/common.c >>> >>> -- >>> 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] i965: Don't enable reset notification support on Gen4-5.
On 12.03.2014 10:43, Kenneth Graunke wrote: > arekm reported that using Chrome with GPU acceleration enabled on GM45 > triggered the hw_ctx != NULL assertion in brw_get_graphics_reset_status. > > We definitely do not want to advertise reset notification support on > Gen4-5 systems, since it needs hardware contexts, and we never even > request a hardware context on those systems. > > Cc: Ian Romanick > Signed-off-by: Kenneth Graunke this has been on bugzilla too for some time now: https://bugs.freedesktop.org/show_bug.cgi?id=75723 -- t ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/12] Again Klocwork patches
On 07/04/14 22:10, Juha-Pekka Heikkilä wrote: > On Mon, Apr 7, 2014 at 11:21 PM, Emil Velikov > wrote: >> On 07/04/14 21:06, Juha-Pekka Heikkilä wrote: >>> Hmm... Wonder where my patches 9..12 vanished. They show in git >>> send-email as "Result: 250 ok: Message ### accepted". If they don't >>> magically show up here I will resend entire set tomorrow from better >>> connection. >>> >> An innocent bystander type of questions: >> >> - Why do you resend the whole series every time, rather than re-sending only >> the updated patches ? > > The set changes often quite much and due to nature of Klocwork touches > totally different areas in Mesa, bookkeeping I guess is not among my > best features -- patches in any case reflect the expected change I > think. As a side nuance I use gmail for sending patches, gmail strips > headers from emails causing I often don't find "Message-Id" field so > easy for old emails. If anyone know where to get full email headers > with gmail I will be happy to know :) > AFAICS you're using git send-email to send that patches, which preserves all the header tags (including the message-id). Although I'm not sure if using gmail's web UI won't mess things up. >> - Noticed that you mention the changes between patch revisions only in some >> cases. Is that intentional ? > > When the set has gone through bigger change its easier just to ditch > the history rather than to strip what's left and what's not. Last I > separated reviewed committable patches which Tapani committed to > master thus I left the history again out, ie. the amount of patches > maybe stay close to same as before but its just because I don't want > to over grow the set. In total through these Klocwork patches there > went fixes which so far allowed to close 200+ Klocwork reported issues > from Mesa. > Only 200 issues, that's nothing :P Thanks for the extensive reply. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/12] mesa: In emit_texenv() type mismatch was forced with typecast
Type mismatch caused random memory to be copied when casted
memory area was smaller than expected type.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/main/ff_fragment_shader.cpp | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/src/mesa/main/ff_fragment_shader.cpp
b/src/mesa/main/ff_fragment_shader.cpp
index 1d2ad60..5aa90c2 100644
--- a/src/mesa/main/ff_fragment_shader.cpp
+++ b/src/mesa/main/ff_fragment_shader.cpp
@@ -888,14 +888,15 @@ emit_texenv(texenv_fragment_program *p, GLuint unit)
shift = new(p->mem_ctx) ir_constant((float)(1 << rgb_shift));
}
else {
-float const_data[4] = {
- float(1 << rgb_shift),
- float(1 << rgb_shift),
- float(1 << rgb_shift),
- float(1 << alpha_shift)
-};
-shift = new(p->mem_ctx) ir_constant(glsl_type::vec4_type,
-(ir_constant_data *)const_data);
+ ir_constant_data const_data;
+
+ const_data.f[0] = float(1 << rgb_shift);
+ const_data.f[1] = float(1 << rgb_shift);
+ const_data.f[2] = float(1 << rgb_shift);
+ const_data.f[3] = float(1 << alpha_shift);
+
+ shift = new(p->mem_ctx) ir_constant(glsl_type::vec4_type,
+ &const_data);
}
return saturate(mul(deref, shift));
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/12] mesa: add null checks in symbol_table.c
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/program/symbol_table.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/src/mesa/program/symbol_table.c b/src/mesa/program/symbol_table.c
index 9462978..5b22745 100644
--- a/src/mesa/program/symbol_table.c
+++ b/src/mesa/program/symbol_table.c
@@ -172,6 +172,11 @@ _mesa_symbol_table_push_scope(struct _mesa_symbol_table
*table)
{
struct scope_level *const scope = calloc(1, sizeof(*scope));
+if (scope == NULL) {
+ _mesa_error_no_memory(__func__);
+ return;
+}
+
scope->next = table->current_scope;
table->current_scope = scope;
table->depth++;
@@ -254,7 +259,17 @@ _mesa_symbol_table_add_symbol(struct _mesa_symbol_table
*table,
if (hdr == NULL) {
hdr = calloc(1, sizeof(*hdr));
+ if (hdr == NULL) {
+ _mesa_error_no_memory(__func__);
+ return -1;
+ }
+
hdr->name = strdup(name);
+ if (hdr->name == NULL) {
+ free(hdr);
+ _mesa_error_no_memory(__func__);
+ return -1;
+ }
hash_table_insert(table->ht, hdr, hdr->name);
hdr->next = table->hdr;
@@ -276,6 +291,11 @@ _mesa_symbol_table_add_symbol(struct _mesa_symbol_table
*table,
return -1;
sym = calloc(1, sizeof(*sym));
+if (sym == NULL) {
+ _mesa_error_no_memory(__func__);
+ return -1;
+}
+
sym->next_with_same_name = hdr->symbols;
sym->next_with_same_scope = table->current_scope->symbols;
sym->hdr = hdr;
@@ -311,6 +331,11 @@ _mesa_symbol_table_add_global_symbol(struct
_mesa_symbol_table *table,
if (hdr == NULL) {
hdr = calloc(1, sizeof(*hdr));
+if (hdr == NULL) {
+ _mesa_error_no_memory(__func__);
+ return -1;
+}
+
hdr->name = strdup(name);
hash_table_insert(table->ht, hdr, hdr->name);
@@ -340,6 +365,11 @@ _mesa_symbol_table_add_global_symbol(struct
_mesa_symbol_table *table,
}
sym = calloc(1, sizeof(*sym));
+if (sym == NULL) {
+ _mesa_error_no_memory(__func__);
+ return -1;
+}
+
sym->next_with_same_scope = top_scope->symbols;
sym->hdr = hdr;
sym->name_space = name_space;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/12] glsl: check _mesa_hash_table_create return value in link_uniform_blocks
Signed-off-by: Juha-Pekka Heikkila
---
src/glsl/link_uniform_blocks.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/glsl/link_uniform_blocks.cpp b/src/glsl/link_uniform_blocks.cpp
index 72d6c53..add3ef4 100644
--- a/src/glsl/link_uniform_blocks.cpp
+++ b/src/glsl/link_uniform_blocks.cpp
@@ -170,6 +170,11 @@ link_uniform_blocks(void *mem_ctx,
struct hash_table *block_hash =
_mesa_hash_table_create(mem_ctx, _mesa_key_string_equal);
+ if (block_hash == NULL) {
+ _mesa_error_no_memory(__func__);
+ return 0;
+ }
+
/* Determine which uniform blocks are active.
*/
link_uniform_block_active_visitor v(mem_ctx, block_hash, prog);
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/12] i965/fs: Check variable_storage return value in fs_visitor::visit
check variable_storage() found the requested fs_reg.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index ce6d3da..f0a84f9 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -151,6 +151,12 @@ void
fs_visitor::visit(ir_dereference_variable *ir)
{
fs_reg *reg = variable_storage(ir->var);
+
+ if (!reg) {
+ fail("Failed to find variable storage for %s\n", ir->var->name);
+ this->result = fs_reg(reg_null_d);
+ return;
+ }
this->result = *reg;
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/12] glsl: Add null check in loop_analysis.cpp
Check return value from hash_table_find before using it as a pointer
Signed-off-by: Juha-Pekka Heikkila
---
src/glsl/loop_analysis.cpp | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/glsl/loop_analysis.cpp b/src/glsl/loop_analysis.cpp
index d6a9ac7..78ac300 100644
--- a/src/glsl/loop_analysis.cpp
+++ b/src/glsl/loop_analysis.cpp
@@ -589,8 +589,10 @@ get_basic_induction_increment(ir_assignment *ir,
hash_table *var_hash)
loop_variable *lv =
(loop_variable *) hash_table_find(var_hash, inc_var);
-if (!lv->is_loop_constant())
- inc = NULL;
+ if (lv == NULL || !lv->is_loop_constant()) {
+assert(lv != NULL);
+inc = NULL;
+ }
} else
inc = NULL;
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 10.2 release plan strawman
Ian Romanick writes: > On 04/07/2014 09:14 AM, Eric Anholt wrote: >> Ian Romanick writes: >> >>> On 04/04/2014 05:52 PM, Matt Turner wrote: On Fri, Apr 4, 2014 at 5:18 PM, Ian Romanick wrote: > Fast forwarding 3 months from the 10.1 release (March 4th, planned for > February 28th) is May 30th. I'd like to propose the following set of > dates: > > May 2nd: Feature freeze / 10.2 branch created. > > May 16th: RC1 Same comment as last time. It's not clear to me that we need a week between the branch and RC1. We're not going to get users testing the branch until there's an RC that distros can offer. >>> >>> The thinking behind having some gap is that a lot of people don't change >>> from feature work to bug fixing until the branch is made. There are >>> usually a bunch of bug fixes landed right after the branch is made... >>> there's also often a bunch of... chaos right before the branch is made. >>> Having an RC that doesn't build, has lot of known bugs, etc is useless. >>> Having a time gap between features landing and making RC1 allows things >>> to settle down a bit. >>> >>> I thought your complaint before was that a week wasn't long enough. >>> That's why I bumped it to two weeks this time. I guess I must have >>> misunderstood the concern. >> >> FWIW, I also don't see the point in having the branch but no RC. > > What's the point of having an RC is that is complete garbage? If you > can explain that to me, I will do the work of creating it. Otherwise, > I'll just skip the pointless busywork kthanks. Mesa master runs for me almost all the time, and I haven't experienced Mesa master being any less likely to run right around the branchpoints. So, I disagree with you saying that not delaying would produce a garbage RC. pgpDPWXI9I5XR.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77152] libglapi.so: undefined reference to `entry_get_public'
https://bugs.freedesktop.org/show_bug.cgi?id=77152 Matt Turner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Matt Turner --- Thanks. Eric fixed this with 34f15903d6f5807b34a4c9be6d8daaedbbdd64bc. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: add bounds checking to eliminate buffer overrun
Hi Ian, I didn't think this even got out. I was getting a weird error from git-send-mail when it tried to send to the gmail server and I got distracted with other things. Here's log: Send this email? ([y]es|[n]o|[q]uit|[a]ll): y Password for 'smtp://court...@lunarg.com@smtp.gmail.com:587': OK. Log says: Server: smtp.gmail.com MAIL FROM: RCPT TO: From: Courtney Goeltzenleuchter To: mesa-dev@lists.freedesktop.org Subject: [PATCH] mesa: add bounds checking to eliminate buffer overrun Date: Mon, 7 Apr 2014 13:19:17 -0600 Message-Id: <1396898358-14649-1-git-send-email-court...@lunarg.com> X-Mailer: git-send-email 1.8.3.2 In-Reply-To: References: Result: 250 2.0.0 OK 1396898380 on9sm125685igb.11 - gsmtp In git 1.7.0, the default has changed to --no-chain-reply-to Set sendemail.chainreplyto configuration variable to true if you want to keep --chain-reply-to as your default. (mbox) Adding cc: Courtney Goeltzenleuchter from line 'From: Courtney Goeltzenleuchter ' (body) Adding cc: "9.2 10.0 10.1" mailto:mesa-sta...@lists.freedesktop.org>> I'll give it another try. On Mon, Apr 7, 2014 at 2:06 PM, Ian Romanick wrote: > On 04/07/2014 12:19 PM, Courtney Goeltzenleuchter wrote: > > Updated patch to include reference to bug that it resolves. > > Where? > > The proper way to do this is to send the path with git-send-mail, and > include extra verbage in the commit message like: > > v3: Updated patch to include reference to bug that it resolves. > > Unless, of course, that update is just to add a Bugzilla: line to the > commit message. I don't know if that's the change because... :) > > > Since this fixes a buffer overrun in the driver (found running > GLBenchmark's Manhattan test) I think it would be a good candidate for the > stable branch. > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > -- Courtney Goeltzenleuchter LunarG ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] mesa: add bounds checking to eliminate buffer overrun
Decompressing ETC2 textures was causing intermitent segfault
by copying resulting 4x4 texel block to the destination texture
regardless of the size of the destination texture. Issue found
via application crash in GLBenchmark 3.0's Manhattan test.
v2: add more explanatory comments
v3: add bugzilla reference
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74988
Cc: "9.2 10.0 10.1" mailto:mesa-sta...@lists.freedesktop.org>>
---
src/mesa/main/texcompress_etc.c | 49 +
1 file changed, 25 insertions(+), 24 deletions(-)
diff --git a/src/mesa/main/texcompress_etc.c b/src/mesa/main/texcompress_etc.c
index 28203f4..d025488 100644
--- a/src/mesa/main/texcompress_etc.c
+++ b/src/mesa/main/texcompress_etc.c
@@ -685,9 +685,10 @@ etc2_unpack_rgb8(uint8_t *dst_row,
etc2_rgb8_parse_block(&block, src,
false /* punchthrough_alpha */);
- for (j = 0; j < bh; j++) {
+ /* be sure to stay within the bounds of the texture */
+ for (j = 0; j < bh && (j+y) < height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps;
-for (i = 0; i < bw; i++) {
+for (i = 0; i < bw && (i+x) < width; i++) {
etc2_rgb8_fetch_texel(&block, i, j, dst,
false /* punchthrough_alpha */);
dst[3] = 255;
@@ -722,9 +723,9 @@ etc2_unpack_srgb8(uint8_t *dst_row,
etc2_rgb8_parse_block(&block, src,
false /* punchthrough_alpha */);
- for (j = 0; j < bh; j++) {
+ for (j = 0; j < bh && (j+y) < height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps;
-for (i = 0; i < bw; i++) {
+for (i = 0; i < bw && (i+x) < width; i++) {
etc2_rgb8_fetch_texel(&block, i, j, dst,
false /* punchthrough_alpha */);
/* Convert to MESA_FORMAT_SARGB8 */
@@ -765,9 +766,9 @@ etc2_unpack_rgba8(uint8_t *dst_row,
for (x = 0; x < width; x+= bw) {
etc2_rgba8_parse_block(&block, src);
- for (j = 0; j < bh; j++) {
+ for (j = 0; j < bh && (j+y) < height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps;
-for (i = 0; i < bw; i++) {
+for (i = 0; i < bw && (i+x) < width; i++) {
etc2_rgba8_fetch_texel(&block, i, j, dst);
dst += comps;
}
@@ -802,9 +803,9 @@ etc2_unpack_srgb8_alpha8(uint8_t *dst_row,
for (x = 0; x < width; x+= bw) {
etc2_rgba8_parse_block(&block, src);
- for (j = 0; j < bh; j++) {
+ for (j = 0; j < bh && (j+y) < height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps;
-for (i = 0; i < bw; i++) {
+for (i = 0; i < bw && (i+x) < width; i++) {
etc2_rgba8_fetch_texel(&block, i, j, dst);
/* Convert to MESA_FORMAT_SARGB8 */
@@ -844,9 +845,9 @@ etc2_unpack_r11(uint8_t *dst_row,
for (x = 0; x < width; x+= bw) {
etc2_r11_parse_block(&block, src);
- for (j = 0; j < bh; j++) {
+ for (j = 0; j < bh && (j+y) < height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps *
comp_size;
-for (i = 0; i < bw; i++) {
+for (i = 0; i < bw && (i+x) < width; i++) {
etc2_r11_fetch_texel(&block, i, j, dst);
dst += comps * comp_size;
}
@@ -880,10 +881,10 @@ etc2_unpack_rg11(uint8_t *dst_row,
/* red component */
etc2_r11_parse_block(&block, src);
- for (j = 0; j < bh; j++) {
+ for (j = 0; j < bh && (j+y) < height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride +
x * comps * comp_size;
-for (i = 0; i < bw; i++) {
+for (i = 0; i < bw && (i+x) < width; i++) {
etc2_r11_fetch_texel(&block, i, j, dst);
dst += comps * comp_size;
}
@@ -891,10 +892,10 @@ etc2_unpack_rg11(uint8_t *dst_row,
/* green component */
etc2_r11_parse_block(&block, src + 8);
- for (j = 0; j < bh; j++) {
+ for (j = 0; j < bh && (j+y) < height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride +
x * comps * comp_size;
-for (i = 0; i < bw; i++) {
+for (i = 0; i < bw && (i+x) < width; i++) {
etc2_r11_fetch_texel(&block, i, j, dst + comp_size);
dst += comps * comp_size;
}
@@ -927,10 +928,10 @@ etc2_unpack_signed_r11(uint8_t *dst_row,
for (x = 0; x < width; x+= bw) {
etc2_r11_parse_block(&block, src);
- for (j = 0; j < bh; j++) {
+ for (j = 0; j < bh && (j+y) < height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride +
Re: [Mesa-dev] [PATCH] mesa: add bounds checking to eliminate buffer overrun
On 08/04/14 01:18, Courtney Goeltzenleuchter wrote: > Hi Ian, > > I didn't think this even got out. I was getting a weird error from > git-send-mail when it tried to send to the gmail server and I got > distracted with other things. > > Here's log: > Send this email? ([y]es|[n]o|[q]uit|[a]ll): y > Password for 'smtp://court...@lunarg.com@smtp.gmail.com:587': > OK. Log says: > Server: smtp.gmail.com > MAIL FROM: > RCPT TO: > From: Courtney Goeltzenleuchter > To: mesa-dev@lists.freedesktop.org > Subject: [PATCH] mesa: add bounds checking to eliminate buffer overrun > Date: Mon, 7 Apr 2014 13:19:17 -0600 > Message-Id: <1396898358-14649-1-git-send-email-court...@lunarg.com> > X-Mailer: git-send-email 1.8.3.2 > In-Reply-To: fp_a3ng2rkclqh2q-suuz...@mail.gmail.com> > References: fp_a3ng2rkclqh2q-suuz...@mail.gmail.com> > > Result: 250 2.0.0 OK 1396898380 on9sm125685igb.11 - gsmtp > > In git 1.7.0, the default has changed to --no-chain-reply-to > Set sendemail.chainreplyto configuration variable to true if > you want to keep --chain-reply-to as your default. > (mbox) Adding cc: Courtney Goeltzenleuchter from line > 'From: Courtney Goeltzenleuchter ' > (body) Adding cc: "9.2 10.0 10.1" line 'Cc: "9.2 10.0 10.1" http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77161] New: [softpipe] piglit fbo-generatemipmap-cubemap S3TC_DXT1 regression
https://bugs.freedesktop.org/show_bug.cgi?id=77161
Priority: medium
Bug ID: 77161
Keywords: regression
CC: mar...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [softpipe] piglit fbo-generatemipmap-cubemap S3TC_DXT1
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: 34f15903d6f5807b34a4c9be6d8daaedbbdd64bc (master 10.2.0-devel)
$ ./bin/fbo-generatemipmap-cubemap S3TC_DXT1 -auto
Probe color at (0,0)
Expected: 0.25 0.50 0.50 1.00
Observed: 0.00 0.490196 0.482353 1.00
when testing face 2, level 5, cube 0
PIGLIT: {'result': 'fail' }
8ab7bb4707ae5fb6e5e841f0f2e369c14b5ffbea is the first bad commit
commit 8ab7bb4707ae5fb6e5e841f0f2e369c14b5ffbea
Author: Marek Olšák
Date: Sun Mar 16 03:40:54 2014 +0100
gallium/u_blitter: don't adjust cubemap coordinates by a small number
It may cause issues with mipmap generation.
I think it was used to make some piglit tests pass on r300g.
:04 04 de431ecef78cd73917bdae4846194821bcfe9862
234da266ee4cbe859f5e9a9671fdb82026953304 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] mesa: add bounds checking to eliminate buffer overrun
Thanks Emil, I've got it sorted out I think. The format of the cc: was incorrect, it shouldn't have the piece. Should look like: Cc: "9.2 10.0 10.1" I'll send out updated patch. Courtney On Mon, Apr 7, 2014 at 6:28 PM, Emil Velikov wrote: > On 08/04/14 01:18, Courtney Goeltzenleuchter wrote: > > Hi Ian, > > > > I didn't think this even got out. I was getting a weird error from > > git-send-mail when it tried to send to the gmail server and I got > > distracted with other things. > > > > Here's log: > > Send this email? ([y]es|[n]o|[q]uit|[a]ll): y > > Password for 'smtp://court...@lunarg.com@smtp.gmail.com:587': > > OK. Log says: > > Server: smtp.gmail.com > > MAIL FROM: > > RCPT TO: > > From: Courtney Goeltzenleuchter > > To: mesa-dev@lists.freedesktop.org > > Subject: [PATCH] mesa: add bounds checking to eliminate buffer overrun > > Date: Mon, 7 Apr 2014 13:19:17 -0600 > > Message-Id: <1396898358-14649-1-git-send-email-court...@lunarg.com> > > X-Mailer: git-send-email 1.8.3.2 > > In-Reply-To: > fp_a3ng2rkclqh2q-suuz...@mail.gmail.com> > > References: > fp_a3ng2rkclqh2q-suuz...@mail.gmail.com> > > > > Result: 250 2.0.0 OK 1396898380 on9sm125685igb.11 - gsmtp > > > > In git 1.7.0, the default has changed to --no-chain-reply-to > > Set sendemail.chainreplyto configuration variable to true if > > you want to keep --chain-reply-to as your default. > > (mbox) Adding cc: Courtney Goeltzenleuchter from > line > > 'From: Courtney Goeltzenleuchter ' > > (body) Adding cc: "9.2 10.0 10.1" > line 'Cc: "9.2 10.0 10.1"^^ > I could be day dreaming but it seems like you've missed the closing arrow > bracket. That's when git starts being helpful and things go bonkers :) > > -Emil > > -- Courtney Goeltzenleuchter LunarG ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: add bounds checking to eliminate buffer overrun
Decompressing ETC2 textures was causing intermitent segfault
by copying resulting 4x4 texel block to the destination texture
regardless of the size of the destination texture. Issue found
via application crash in GLBenchmark 3.0's Manhattan test.
v2: add more explanatory comments
v3: add bugzilla reference
v4: Correct cc syntax in commit log
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74988
Cc: "9.2 10.0 10.1"
---
src/mesa/main/texcompress_etc.c | 49 +
1 file changed, 25 insertions(+), 24 deletions(-)
diff --git a/src/mesa/main/texcompress_etc.c b/src/mesa/main/texcompress_etc.c
index cbda689..39775e2 100644
--- a/src/mesa/main/texcompress_etc.c
+++ b/src/mesa/main/texcompress_etc.c
@@ -683,9 +683,10 @@ etc2_unpack_rgb8(uint8_t *dst_row,
etc2_rgb8_parse_block(&block, src,
false /* punchthrough_alpha */);
- for (j = 0; j < bh; j++) {
+ /* be sure to stay within the bounds of the texture */
+ for (j = 0; j < bh && (j+y) < height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps;
-for (i = 0; i < bw; i++) {
+for (i = 0; i < bw && (i+x) < width; i++) {
etc2_rgb8_fetch_texel(&block, i, j, dst,
false /* punchthrough_alpha */);
dst[3] = 255;
@@ -720,9 +721,9 @@ etc2_unpack_srgb8(uint8_t *dst_row,
etc2_rgb8_parse_block(&block, src,
false /* punchthrough_alpha */);
- for (j = 0; j < bh; j++) {
+ for (j = 0; j < bh && (j+y) < height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps;
-for (i = 0; i < bw; i++) {
+for (i = 0; i < bw && (i+x) < width; i++) {
etc2_rgb8_fetch_texel(&block, i, j, dst,
false /* punchthrough_alpha */);
/* Convert to MESA_FORMAT_B8G8R8A8_SRGB */
@@ -763,9 +764,9 @@ etc2_unpack_rgba8(uint8_t *dst_row,
for (x = 0; x < width; x+= bw) {
etc2_rgba8_parse_block(&block, src);
- for (j = 0; j < bh; j++) {
+ for (j = 0; j < bh && (j+y) < height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps;
-for (i = 0; i < bw; i++) {
+for (i = 0; i < bw && (i+x) < width; i++) {
etc2_rgba8_fetch_texel(&block, i, j, dst);
dst += comps;
}
@@ -800,9 +801,9 @@ etc2_unpack_srgb8_alpha8(uint8_t *dst_row,
for (x = 0; x < width; x+= bw) {
etc2_rgba8_parse_block(&block, src);
- for (j = 0; j < bh; j++) {
+ for (j = 0; j < bh && (j+y) < height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps;
-for (i = 0; i < bw; i++) {
+for (i = 0; i < bw && (i+x) < width; i++) {
etc2_rgba8_fetch_texel(&block, i, j, dst);
/* Convert to MESA_FORMAT_B8G8R8A8_SRGB */
@@ -842,9 +843,9 @@ etc2_unpack_r11(uint8_t *dst_row,
for (x = 0; x < width; x+= bw) {
etc2_r11_parse_block(&block, src);
- for (j = 0; j < bh; j++) {
+ for (j = 0; j < bh && (j+y) < height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride + x * comps *
comp_size;
-for (i = 0; i < bw; i++) {
+for (i = 0; i < bw && (i+x) < width; i++) {
etc2_r11_fetch_texel(&block, i, j, dst);
dst += comps * comp_size;
}
@@ -878,10 +879,10 @@ etc2_unpack_rg11(uint8_t *dst_row,
/* red component */
etc2_r11_parse_block(&block, src);
- for (j = 0; j < bh; j++) {
+ for (j = 0; j < bh && (j+y) < height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride +
x * comps * comp_size;
-for (i = 0; i < bw; i++) {
+for (i = 0; i < bw && (i+x) < width; i++) {
etc2_r11_fetch_texel(&block, i, j, dst);
dst += comps * comp_size;
}
@@ -889,10 +890,10 @@ etc2_unpack_rg11(uint8_t *dst_row,
/* green component */
etc2_r11_parse_block(&block, src + 8);
- for (j = 0; j < bh; j++) {
+ for (j = 0; j < bh && (j+y) < height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_stride +
x * comps * comp_size;
-for (i = 0; i < bw; i++) {
+for (i = 0; i < bw && (i+x) < width; i++) {
etc2_r11_fetch_texel(&block, i, j, dst + comp_size);
dst += comps * comp_size;
}
@@ -925,10 +926,10 @@ etc2_unpack_signed_r11(uint8_t *dst_row,
for (x = 0; x < width; x+= bw) {
etc2_r11_parse_block(&block, src);
- for (j = 0; j < bh; j++) {
+ for (j = 0; j < bh && (j+y) < height; j++) {
uint8_t *dst = dst_row + (y + j) * dst_
Re: [Mesa-dev] [PATCH] Partially revert "st/xa: Fix advertized version number and try to avoid future discrepancies"
Hi! Thanks, This looks good to me. Reviewed-by: Thomas Hellstrom /Thomas On 04/07/2014 03:45 PM, Emil Velikov wrote: > This reverts commit 61bedc3d6b08943f015f9d590c07a6af36c2a92c. > > As the header is the one defining the API/ABI and is distributed > during installation, we should be using it rather than re-defining > the XA version in configure.ac. > > Bump the version in the header to 2.2.0, to reflect what was the > original intent of commit 42158926c6d7d3ddbe61b9a04d60544ff1b50a96. > > Cc: Thomas Hellstrom > Signed-off-by: Emil Velikov > --- > > Yikes, thanks for the reminder Thomas. > > I've completely missed the "xa_tracker is installed header" part. > > Considering that we already have a cannonical place where the > version is defined, one can simply use it (be that a build system > or not). > > IMHO this approach looks alot better. Hopefully I did not miss > something this time. > > Emil > > configure.ac | 12 +- > src/gallium/state_trackers/xa/xa_tracker.h| 200 > ++ > src/gallium/state_trackers/xa/xa_tracker.h.in | 200 > -- > 3 files changed, 208 insertions(+), 204 deletions(-) > create mode 100644 src/gallium/state_trackers/xa/xa_tracker.h > delete mode 100644 src/gallium/state_trackers/xa/xa_tracker.h.in > > diff --git a/configure.ac b/configure.ac > index ee5c2d1..1a3ef87 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2000,9 +2000,14 @@ AC_SUBST([VDPAU_MINOR], 0) > AC_SUBST([XVMC_MAJOR], 1) > AC_SUBST([XVMC_MINOR], 0) > > -AC_SUBST([XA_MAJOR], 2) > -AC_SUBST([XA_MINOR], 2) > -AC_SUBST([XA_TINY], 0) > +XA_HEADER="$srcdir/src/gallium/state_trackers/xa/xa_tracker.h" > +XA_MAJOR=`grep "#define XA_TRACKER_VERSION_MAJOR" $XA_HEADER | $SED > 's/^#define XA_TRACKER_VERSION_MAJOR //'` > +XA_MINOR=`grep "#define XA_TRACKER_VERSION_MINOR" $XA_HEADER | $SED > 's/^#define XA_TRACKER_VERSION_MINOR //'` > +XA_TINY=`grep "#define XA_TRACKER_VERSION_PATCH" $XA_HEADER | $SED > 's/^#define XA_TRACKER_VERSION_PATCH //'` > + > +AC_SUBST([XA_MAJOR], $XA_MAJOR) > +AC_SUBST([XA_MINOR], $XA_MINOR) > +AC_SUBST([XA_TINY], $XA_TINY) > AC_SUBST([XA_VERSION], "$XA_MAJOR.$XA_MINOR.$XA_TINY") > > dnl Restore LDFLAGS and CPPFLAGS > @@ -2063,7 +2068,6 @@ AC_CONFIG_FILES([Makefile > src/gallium/state_trackers/vdpau/Makefile > src/gallium/state_trackers/vega/Makefile > src/gallium/state_trackers/xa/Makefile > -src/gallium/state_trackers/xa/xa_tracker.h > src/gallium/state_trackers/xvmc/Makefile > src/gallium/targets/Makefile > src/gallium/targets/dri-freedreno/Makefile > diff --git a/src/gallium/state_trackers/xa/xa_tracker.h > b/src/gallium/state_trackers/xa/xa_tracker.h > new file mode 100644 > index 000..5c6435e > --- /dev/null > +++ b/src/gallium/state_trackers/xa/xa_tracker.h > @@ -0,0 +1,200 @@ > +/** > + * Copyright 2009-2011 VMware, Inc. All rights reserved. > + * > + * Permission is hereby granted, free of charge, to any person > + * obtaining a copy of this software and associated documentation > + * files (the "Software"), to deal in the Software without > + * restriction, including without limitation the rights to use, copy, > + * modify, merge, publish, distribute, sublicense, and/or sell copies > + * of the Software, and to permit persons to whom the Software is > + * furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be > + * included in all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS > + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN > + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN > + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE > + * SOFTWARE. > + * > + * The format encoding idea is partially borrowed from libpixman, but it is > not > + * considered a "substantial part of the software", so the pixman copyright > + * is left out for simplicity, and acknowledgment is instead given in this > way. > + * > + * > + * Authors: > + * Zack Rusin > + * Thomas Hellstrom > + */ > + > +#ifndef _XA_TRACKER_H_ > +#define _XA_TRACKER_H_ > + > +#include > + > +#define XA_TRACKER_VERSION_MAJOR 2 > +#define XA_TRACKER_VERSION_MINOR 2 > +#define XA_TRACKER_VERSION_PATCH 0 > + > +#define XA_FLAG_SHARED (1 << 0) > +#define XA_FLAG_RENDER_TARGET (1 << 1) > +#define XA_FLAG_SCANOUT(1 << 2) > + > +#define XA_MAP_READ (1 << 0) > +#define XA_
Re: [Mesa-dev] [PATCH 3/9] glsl: Make is_16bit_constant from i965 an ir_constant method.
On 04/07/2014 06:24 AM, Ian Romanick wrote: > On 04/06/2014 11:49 PM, Kenneth Graunke wrote: >> The i965 MUL instruction doesn't natively support 32-bit by 32-bit >> integer multiplication; additional instructions (MACH/MOV) are required. >> However, we can avoid those if we know one of the operands can be >> represented in 16 bits or less. The vector backend's is_16bit_constant >> static helper function checks for this. > > In IVB+ the hardware actually does 32-bit by 16-bit to give a 48-bit > result (on SNB and earlier it's 16-bit by 16-bit... yay). According to > Emil Persson, new generation consoles have similar (but different) > integer multiplication issues (see slide 35 from > http://www.humus.name/index.php?page=Comments&ID=371). Should we expose > a lesser precision integer multiply function similar to mul24()? As, say, a GLSL built-in function? Possibly. Presumably our restrictions are different than anyone else's though, and even ours changed between generations. So I wonder if anyone would bother using what we cooked up. Plus, Broadwell just handles this properly, so this really only saves a couple of instructions on "old" hardware. Obviously, it's not really "old", but...by the time we draft a GL extension, implement it, and get people to bother using it in upcoming applications...we'll be down the road a ways. So, I doubt it's really worth doing, but I wouldn't be horribly against it if someone bothered. One big source of integer multiplication is for computing byte offsets into UBOs or other constant buffers. In that case, we're usually scaling by a small constant factor (say, 4 or 16 bytes), which is well covered by our existing optimization. --Ken signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/9] glsl: Make is_16bit_constant from i965 an ir_constant method.
On 04/07/2014 05:41 AM, Ilia Mirkin wrote: > On Mon, Apr 7, 2014 at 2:49 AM, Kenneth Graunke wrote: >> The i965 MUL instruction doesn't natively support 32-bit by 32-bit >> integer multiplication; additional instructions (MACH/MOV) are required. >> However, we can avoid those if we know one of the operands can be >> represented in 16 bits or less. The vector backend's is_16bit_constant >> static helper function checks for this. >> >> We want to be able to use it in the scalar backend as well, which means >> moving the function to a more generally-usable location. Since it isn't >> i965 specific, I decided to make it an ir_constant method, in case it >> ends up being useful to other people as well. >> >> Signed-off-by: Kenneth Graunke >> --- >> src/glsl/ir.cpp| 9 + >> src/glsl/ir.h | 11 +++ >> src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 18 ++ >> 3 files changed, 22 insertions(+), 16 deletions(-) >> >> diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp >> index a41eddf..07c0a9b 100644 >> --- a/src/glsl/ir.cpp >> +++ b/src/glsl/ir.cpp >> @@ -1223,6 +1223,15 @@ ir_constant::is_basis() const >> return ones == 1; >> } >> >> +bool >> +ir_constant::is_16bit_integer_constant() const > > Perhaps make this is_uint16_constant? Otherwise one might assume based > on the name that it would return true for a value like -1. I like that. I've renamed it to is_uint16_constant and updated the comments to clarify that it can return true for signed values, as long as those values are non-negative and fit in 16-bits. --Ken signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] docs: Expand ARB_gpu_shader5 to describe status of individual features
This extension is a huge grab-bag of "stuff that's in DX11". Break it apart to make it clear what still needs to be done. Signed-off-by: Chris Forbes --- docs/GL3.txt | 11 +++ 1 file changed, 11 insertions(+) diff --git a/docs/GL3.txt b/docs/GL3.txt index bf51e3a..0688977 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -101,6 +101,17 @@ GL 4.0: GL_ARB_draw_buffers_blendDONE (i965, nv50, nvc0, r600, radeonsi, softpipe) GL_ARB_draw_indirect DONE (i965) GL_ARB_gpu_shader5 started + - 'precise' qualifiernot started + - Dynamically uniform sampler array indices not started + - Unrestricted UBO array indices not started + - Implicit signed -> unsigned conversionsnot started + - Fused multiply-add DONE + - Packing/bitfield/conversion functions DONE + - Enhanced textureGather DONE + - Geometry shader instancing DONE + - Geometry shader multiple streams not started + - Enhanced per-sample shadingDONE + - Interpolation functionsstarted GL_ARB_gpu_shader_fp64 not started GL_ARB_sample_shadingDONE (i965) GL_ARB_shader_subroutine not started -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
