Re: [Mesa-dev] [PATCH] mesa context: generate an error for uninstalled context functions
On 07/16/2012 05:44 PM, Jordan Justen wrote:
> On Mon, Jul 16, 2012 at 4:47 PM, Jordan Justen
> wrote:
>> For 'non-legacy' contexts we will want to generate an error
>> if an uninstalled function is called.
>>
>> The effect of this change will be that we can avoid installing
>> legacy functions, and they will then generate an error as
>> needed for deprecated functions in GL >= 3.1.
>>
>> Signed-off-by: Jordan Justen
>> Cc: Ian Romanick
>> ---
>> src/mesa/main/context.c |5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
>> index d5ccce0..b3b935b 100644
>> --- a/src/mesa/main/context.c
>> +++ b/src/mesa/main/context.c
>> @@ -844,7 +844,10 @@ update_default_objects(struct gl_context *ctx)
>> static int
>> generic_nop(void)
>> {
>> - _mesa_warning(NULL, "User called no-op dispatch function (an unsupported
>> extension function?)");
>> + GET_CURRENT_CONTEXT(ctx);
>> + _mesa_error(NULL, GL_INVALID_OPERATION,
>> + "unsupported function called "
>> + "(unsupported extension or deprecated function?)");
>
> Whoops. NULL should be ctx in the _mesa_error call...
>
> -Jordan
With that change, this is:
Reviewed-by: Kenneth Graunke
though obviously I'd wait for Ian and others to comment...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52130] [PATCH] Fix compiling error in src/glsl/Makefile.am
https://bugs.freedesktop.org/show_bug.cgi?id=52130 Kenneth Graunke changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Kenneth Graunke 2012-07-17 06:43:31 PDT --- Closing at the reporter's suggestion. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/5] add wayland-drm test with gbm/intel-driver update
I had tried to add YUYV support to dri image(to support overlay), however Kristian enabled YUYV as a special planar YUV for wayland (two planes which are overlaped). so I try to follow it and pick up the useful part in my previous patches. - add tiling support for bo update (from user data) - add shared_handle (global region name) in gbm - add YUYV support in gbm - test case to render XRGB or YUYV buffer to weston my understanding of current YUV buffer support in mesa is: it can interpret a YUV buffer, not how to create such buffer. it make me a little nervous to add YUYV to gbm since there is no such format in dri image yet (though there is WL_DRM_FORMAT_YUYV for wayland buffer); I just try to use __DRI_IMAGE_FORMAT_GR88 instead to make sure it create buffer with same size. so, one point I want to seek your comments are: should we consider YUYV buffer allocation in mesa/gbm? should we still need a YUYV format for dri image? thanks. Zhao Halley (5): intel driver: dri image write update gbm: add shared_handle(drm buffer region name) gbm dri backend: add YUYV support wayland: add YUYV to wayland-drm test: test case drm-test-client in src/egl/wayland/wayland-drm src/egl/wayland/wayland-drm/Makefile.am | 16 +- src/egl/wayland/wayland-drm/drm-test-client.c | 478 + src/egl/wayland/wayland-drm/wayland-drm.c |3 +- src/gbm/backends/dri/gbm_dri.c| 26 ++ src/gbm/main/gbm.c| 18 + src/gbm/main/gbm.h|8 +- src/gbm/main/gbmint.h |2 + src/mesa/drivers/dri/intel/intel_screen.c | 17 +- 8 files changed, 563 insertions(+), 5 deletions(-) mode change 100644 => 100755 src/egl/wayland/wayland-drm/Makefile.am create mode 100755 src/egl/wayland/wayland-drm/drm-test-client.c mode change 100644 => 100755 src/egl/wayland/wayland-drm/wayland-drm.c mode change 100644 => 100755 src/gbm/backends/dri/gbm_dri.c mode change 100644 => 100755 src/gbm/main/gbm.c mode change 100644 => 100755 src/gbm/main/gbm.h mode change 100644 => 100755 src/gbm/main/gbmint.h -- 1.7.5.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] intel driver: dri image write update
add tiling support for intel_image_write() all drm image can be written from app --- src/mesa/drivers/dri/intel/intel_screen.c | 17 +++-- 1 files changed, 15 insertions(+), 2 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_screen.c b/src/mesa/drivers/dri/intel/intel_screen.c index 6daeb05..3ce9a46 100644 --- a/src/mesa/drivers/dri/intel/intel_screen.c +++ b/src/mesa/drivers/dri/intel/intel_screen.c @@ -324,10 +324,13 @@ intel_create_image(__DRIscreen *screen, tiling = I915_TILING_NONE; } +#if 0 + // add tiling support in intel_image_write(), so all drm images are ok for write /* We only support write for cursor drm images */ if ((use & __DRI_IMAGE_USE_WRITE) && use != (__DRI_IMAGE_USE_WRITE | __DRI_IMAGE_USE_CURSOR)) return NULL; +#endif image = intel_allocate_image(format, loaderPrivate); image->usage = use; @@ -417,9 +420,19 @@ intel_image_write(__DRIimage *image, const void *buf, size_t count) if (!(image->usage & __DRI_IMAGE_USE_WRITE)) return -1; - drm_intel_bo_map(image->region->bo, true); + int tiling, swizzle; + dri_bo_get_tiling(image->region->bo, &tiling, &swizzle); + if (tiling != I915_TILING_NONE) + drm_intel_gem_bo_map_gtt(image->region->bo); + else + drm_intel_bo_map(image->region->bo, true); + memcpy(image->region->bo->virtual, buf, count); - drm_intel_bo_unmap(image->region->bo); + + if (tiling != I915_TILING_NONE) + drm_intel_gem_bo_unmap_gtt(image->region->bo); + else + drm_intel_bo_unmap(image->region->bo); return 0; } -- 1.7.5.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] gbm: add shared_handle(drm buffer region name)
---
src/gbm/backends/dri/gbm_dri.c | 13 +
src/gbm/main/gbm.c | 18 ++
src/gbm/main/gbm.h |3 +++
src/gbm/main/gbmint.h |2 ++
4 files changed, 36 insertions(+), 0 deletions(-)
mode change 100644 => 100755 src/gbm/backends/dri/gbm_dri.c
mode change 100644 => 100755 src/gbm/main/gbm.c
mode change 100644 => 100755 src/gbm/main/gbm.h
mode change 100644 => 100755 src/gbm/main/gbmint.h
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
old mode 100644
new mode 100755
index f09f6ef..fef9d47
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -344,6 +344,18 @@ gbm_dri_to_gbm_format(uint32_t dri_format)
return ret;
}
+static union gbm_bo_handle
+gbm_dri_bo_get_shared_handle(struct gbm_bo *_bo)
+{
+ struct gbm_dri_device *dri = gbm_dri_device(_bo->gbm);
+ struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
+
+ dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_NAME,
+ (uint32_t *) &bo->base.base.shared_handle.u32);
+
+ return bo->base.base.shared_handle;
+}
+
static struct gbm_bo *
gbm_dri_bo_import(struct gbm_device *gbm,
uint32_t type, void *buffer, uint32_t usage)
@@ -557,6 +569,7 @@ dri_device_create(int fd)
dri->base.base.destroy = dri_destroy;
dri->base.base.surface_create = gbm_dri_surface_create;
dri->base.base.surface_destroy = gbm_dri_surface_destroy;
+ dri->base.base.bo_get_shared_handle = gbm_dri_bo_get_shared_handle;
dri->base.type = GBM_DRM_DRIVER_TYPE_DRI;
dri->base.base.name = "drm";
diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
old mode 100644
new mode 100755
index c58576d..317962b
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -231,6 +231,24 @@ gbm_bo_get_handle(struct gbm_bo *bo)
return bo->handle;
}
+/** Get shared handle(global buffer region name) of the buffer object,
+ * this handle can be shared among processes
+ *
+ * This is stored in the platform generic union gbm_bo_handle type. However
+ * the format of this handle is platform specific.
+ *
+ * \param bo The buffer object
+ * \return Returns the handle of the allocated buffer object
+ */
+GBM_EXPORT union gbm_bo_handle
+gbm_bo_get_shared_handle(struct gbm_bo *bo)
+{
+ if (bo->shared_handle.u32) return bo->shared_handle;
+
+ return bo->gbm->bo_get_shared_handle(bo);
+
+}
+
/** Write data into the buffer object
*
* If the buffer object was created with the GBM_BO_USE_WRITE flag,
diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
old mode 100644
new mode 100755
index 9d2a030..55f012a
--- a/src/gbm/main/gbm.h
+++ b/src/gbm/main/gbm.h
@@ -255,6 +255,9 @@ gbm_bo_get_device(struct gbm_bo *bo);
union gbm_bo_handle
gbm_bo_get_handle(struct gbm_bo *bo);
+union gbm_bo_handle
+gbm_bo_get_shared_handle(struct gbm_bo *bo);
+
int
gbm_bo_write(struct gbm_bo *bo, const void *buf, size_t count);
diff --git a/src/gbm/main/gbmint.h b/src/gbm/main/gbmint.h
old mode 100644
new mode 100755
index a467bea..01c55ec
--- a/src/gbm/main/gbmint.h
+++ b/src/gbm/main/gbmint.h
@@ -68,6 +68,7 @@ struct gbm_device {
uint32_t usage);
struct gbm_bo *(*bo_import)(struct gbm_device *gbm, uint32_t type,
void *buffer, uint32_t usage);
+ union gbm_bo_handle (*bo_get_shared_handle)(struct gbm_bo *bo);
int (*bo_write)(struct gbm_bo *bo, const void *buf, size_t data);
void (*bo_destroy)(struct gbm_bo *bo);
@@ -93,6 +94,7 @@ struct gbm_bo {
uint32_t stride;
uint32_t format;
union gbm_bo_handle handle;
+ union gbm_bo_handle shared_handle; // global handle can be shared among
processes
void *user_data;
void (*destroy_user_data)(struct gbm_bo *, void *);
};
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] gbm dri backend: add YUYV support
---
src/gbm/backends/dri/gbm_dri.c | 13 +
src/gbm/main/gbm.h |5 -
2 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index fef9d47..4812e6b 100755
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -285,6 +285,9 @@ gbm_dri_is_format_supported(struct gbm_device *gbm,
if (usage & GBM_BO_USE_SCANOUT)
return 0;
break;
+ case GBM_BO_FORMAT_YUYV:
+ case GBM_FORMAT_YUYV:
+ break;
default:
return 0;
}
@@ -336,6 +339,9 @@ gbm_dri_to_gbm_format(uint32_t dri_format)
case __DRI_IMAGE_FORMAT_ABGR:
ret = GBM_FORMAT_ABGR;
break;
+ case __DRI_IMAGE_FORMAT_GR88:
+ ret = GBM_FORMAT_YUYV;
+ break;
default:
ret = 0;
break;
@@ -484,6 +490,13 @@ gbm_dri_bo_create(struct gbm_device *gbm,
case GBM_FORMAT_ABGR:
dri_format = __DRI_IMAGE_FORMAT_ABGR;
break;
+ /* wayland/driimage doesn't have a specific format for YUYV, but
+ * treat it as a special case of planar YUV: two overlaped planes
+ * so we use GR88 for YUYV dirimage allocation
+ */
+ case GBM_FORMAT_YUYV:
+ dri_format = __DRI_IMAGE_FORMAT_GR88;
+ break;
default:
return NULL;
}
diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
index 55f012a..50ccb43 100755
--- a/src/gbm/main/gbm.h
+++ b/src/gbm/main/gbm.h
@@ -73,7 +73,10 @@ enum gbm_bo_format {
/** RGB with 8 bits per channel in a 32 bit value */
GBM_BO_FORMAT_XRGB,
/** ARGB with 8 bits per channel in a 32 bit value */
- GBM_BO_FORMAT_ARGB
+ GBM_BO_FORMAT_ARGB,
+ /** YUYV: packed YUV format with 422 subsampling*/
+ GBM_BO_FORMAT_YUYV,
+
};
#define __gbm_fourcc_code(a,b,c,d) ((uint32_t)(a) | ((uint32_t)(b) << 8) | \
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] wayland: add YUYV to wayland-drm
--- src/egl/wayland/wayland-drm/wayland-drm.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) mode change 100644 => 100755 src/egl/wayland/wayland-drm/wayland-drm.c diff --git a/src/egl/wayland/wayland-drm/wayland-drm.c b/src/egl/wayland/wayland-drm/wayland-drm.c old mode 100644 new mode 100755 index 45b307f..0b3287d --- a/src/egl/wayland/wayland-drm/wayland-drm.c +++ b/src/egl/wayland/wayland-drm/wayland-drm.c @@ -176,7 +176,8 @@ drm_create_planar_buffer(struct wl_client *client, case WL_DRM_FORMAT_YUV422: case WL_DRM_FORMAT_YUV444: case WL_DRM_FORMAT_NV12: -case WL_DRM_FORMAT_NV16: +case WL_DRM_FORMAT_NV16: +case WL_DRM_FORMAT_YUYV: break; default: wl_resource_post_error(resource, -- 1.7.5.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] test: test case drm-test-client in src/egl/wayland/wayland-drm
- it shows how wayland-drm protocol works between server and client
buffer are shared basing on dri image
- XRGB and YUYV format are supported,
it can render to overlay plane potentially
---
src/egl/wayland/wayland-drm/Makefile.am | 16 +-
src/egl/wayland/wayland-drm/drm-test-client.c | 478 +
2 files changed, 493 insertions(+), 1 deletions(-)
mode change 100644 => 100755 src/egl/wayland/wayland-drm/Makefile.am
create mode 100755 src/egl/wayland/wayland-drm/drm-test-client.c
diff --git a/src/egl/wayland/wayland-drm/Makefile.am
b/src/egl/wayland/wayland-drm/Makefile.am
old mode 100644
new mode 100755
index 4b2aeb3..e2cffe0
--- a/src/egl/wayland/wayland-drm/Makefile.am
+++ b/src/egl/wayland/wayland-drm/Makefile.am
@@ -10,7 +10,21 @@ noinst_HEADERS = wayland-drm.h
BUILT_SOURCES = wayland-drm-protocol.c \
wayland-drm-client-protocol.h \
wayland-drm-server-protocol.h
-CLEANFILES = $(BUILT_SOURCES)
+
+noinst_PROGRAMS = drm_test_client
+drm_test_client_CFLAGS = $(DEFINES) \
+ -I$(top_srcdir)/src/gbm/main \
+ $(WAYLAND_CFLAGS) \
+ $(LIBDRM_CFLAGS)
+
+drm_test_client_LDADD = $(WAYLAND_LIBS) $(LIBDRM_LIBS)
+drm_test_client_LDADD += $(top_srcdir)/src/gbm/libgbm.la
+
+drm_test_client_SOURCES = drm-test-client.c wayland-drm-protocol.c \
+ wayland-drm-client-protocol.h
+
+CLEANFILES = $(BUILT_SOURCES) $(drm_test_client_SOURCES)
+
%-protocol.c : %.xml
$(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@
diff --git a/src/egl/wayland/wayland-drm/drm-test-client.c
b/src/egl/wayland/wayland-drm/drm-test-client.c
new file mode 100755
index 000..771aa33
--- /dev/null
+++ b/src/egl/wayland/wayland-drm/drm-test-client.c
@@ -0,0 +1,478 @@
+/*
+ * Copyright © 2012 Halley Zhao
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Halley Zhao
+ */
+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "gbm.h"
+#include
+#include
+#include "wayland-drm-client-protocol.h"
+
+int win_width = 256, win_height = 256;
+int drm_fd = -1;
+int wayland_server_support_yuyv = 0;
+struct wl_drm *wl_drm;
+
+struct display {
+ struct wl_display *display;
+ struct wl_compositor *compositor;
+ struct wl_shell *shell;
+ struct wl_input_device *input;
+ uint32_t mask;
+struct gbm_device *gbm;
+};
+
+struct window {
+ struct display *display;
+ struct wl_surface *surface;
+ struct wl_shell_surface *shell_surface;
+ struct wl_callback *callback;
+ struct {
+ int width, height;
+ } geometry;
+unsigned int format;
+struct wl_buffer *buffer;
+struct gbm_bo *gbm_bo;
+unsigned int bo_stride;
+};
+
+void fill_window_XRGB(struct window *win);
+void fill_window_YUYV(struct window *win);
+int wayland_drm_init(struct wl_display *wl_dpy);
+void wayland_drm_destroy(void);
+void redraw(void *data, struct wl_callback *callback, uint32_t time);
+
+void fill_window_XRGB(struct window *win)
+{
+unsigned char *mem = malloc (win->bo_stride* win_height);
+static int color_index = 0;
+static unsigned int color_arr[4] = {0xff00, 0x00ff, 0xff00,
0x00ff};
+unsigned int color;
+int i;
+unsigned int *i_ptr;
+unsigned char *c_ptr;
+
+color = color_arr[color_index];
+i_ptr = (unsigned int *)mem;
+for (i=0; ibo_stride;
+for (i = 1; ibo_stride;
+}
+
+color = color_arr[(color_index+2)%4];
+i_ptr = (unsigned int *)c_ptr;
+for (i=0; ibo_stride;
+for (i = win_height/2+2; ibo_stride;
+}
+
+gbm_bo_write(win->gbm_bo, mem, win->bo_stride * win_height);
+free(mem);
+color_index = (color_index+1) % 4;
+
+}
+
+void fill_window_YUYV(struct window *win)
+{
+
Re: [Mesa-dev] [PATCH 00/11] Add YUYV format support of dri image
Thanks Gwenole. I found kristian had checked in YUV support to mea, he treated YUYV as a special case of planar YUV. It addressed my initial requirement. So I rebased other features in these patch set and resent it > -Original Message- > From: Gwenole Beauchesne [mailto:gb.de...@gmail.com] > Sent: Thursday, July 12, 2012 3:27 PM > To: Zhao, Halley > Cc: Ian Romanick; mesa-dev@lists.freedesktop.org > Subject: Re: [Mesa-dev] [PATCH 00/11] Add YUYV format support of dri image > > Hi Halley, > > 2012/7/12 Zhao, Halley : > > > There is no other comments for these patches, could you help me commit it > to git tree? > > Please rebase against current git master tree. YUV support, including YUYV > was added. The remaining patchset should reduce to the GBM bits. > > Thanks, > Gwenole. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] [PATCH 1/5] intel gen4/5: fix GL_VERTEX_PROGRAM_TWO_SIDE.
On Mon, Jul 16, 2012 at 08:43:17PM -0700, Paul Berry wrote: > Can you split this into three separate patches? That will make it easier > to troubleshoot in case we find bugs with these patches in the future. I'm going to try. > Also, I'm not convinced that #3 is necessary. Is there something in the > spec that dictates this behaviour? My reading of the spec is that if the > vertex shader writes to gl_BackColor but not glFrontColor, then the > contents of gl_Color in the fragment shader is undefined. Given the number of security issues/information leaks that happen due to reads out of place, I'm always extremely wary of reads from nowhere. So one pretty much has a choice between forcing a specific value (like 0) or reading from someplace else that makes sense. In that particular case I considered reading from the other color slot the easy way out. > If we *do* decide that #3 is necessary, then I think a better way to > accomplish it is to handle it in the GLSL vertex shader front-end, by > replacing gl_BackColor with gl_FrontColor in cases where gl_FrontColor is > not written to. That way our special case code to handle this situation > would be in just one place, rather than in three places (both fragment > shader back-ends, and the SF program). Also then the fix would apply to > all hardware, not just Intel Gen4-5. You'd have to switch off two-sided lighting too, but why not. > Finally, I couldn't figure out what you meant by "the stray mov into > lalaland". Can you elaborate on which piece of code used to generate that > stray mov, and why it doesn't anymore? Thanks. Looking at it again, I was wrong, it was protected. OG. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] intel gen4/5: fix GL_VERTEX_PROGRAM_TWO_SIDE.
On Mon, Jul 16, 2012 at 08:43:17PM -0700, Paul Berry wrote: > Also, I'm not convinced that #3 is necessary. Is there something in the > spec that dictates this behaviour? My reading of the spec is that if the > vertex shader writes to gl_BackColor but not glFrontColor, then the > contents of gl_Color in the fragment shader is undefined. Oh, I remember why I did that in the first place. All the front/back piglit tests only write the appropriate color slot and not the other one. The language is annoying: The following built-in vertex output variables are available, but deprecated. A particular one should be written to if any functionality in a corresponding fragment shader or fixed pipeline uses it or state derived from it. Otherwise, behavior is undefined. out vec4 gl_FrontColor; out vec4 gl_BackColor; out vec4 gl_FrontSecondaryColor; out vec4 gl_BackSecondaryColor; [...] One could argue that you don't "use" gl_FrontColor if all your polygons are back-facing. Dunno. Do you consider all of the twoside piglit tests buggy? We can fix *that*. OG. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 51960] [bisected] Mesa master fails to build
https://bugs.freedesktop.org/show_bug.cgi?id=51960 --- Comment #3 from Michel Dänzer 2012-07-17 10:27:43 PDT --- (In reply to comment #2) > I did try make clean, make distclean, git clean -fdx, git reset --hard, none > of > this helps. Only reverting the mentioned commit helps. Are you using ccache or something like that? If so, the object file might be corrupted in the cache. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52140] Ubuntu Unity - Launcher and switcher icons disappeared
https://bugs.freedesktop.org/show_bug.cgi?id=52140 Michel Dänzer changed: What|Removed |Added AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Product|DRI |Mesa Version|XOrg CVS|git Component|DRM/Radeon |Mesa core --- Comment #4 from Michel Dänzer 2012-07-17 10:41:42 UTC --- Or it could be a regression in code shared between the drivers. Mesa seems most likely at this point. Would be great if somebody could confirm that this happen with current upstream Git master but not with the 8.0 branch, and bisect. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/egl: Fix build for wayland includes
common/native_wayland_drm_bufmgr_helper.c fails to find wayland-server.h Signed-off-by: Elvis Lee --- src/gallium/state_trackers/egl/Makefile |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/gallium/state_trackers/egl/Makefile b/src/gallium/state_trackers/egl/Makefile index fe42fbb..66b2e7e 100644 --- a/src/gallium/state_trackers/egl/Makefile +++ b/src/gallium/state_trackers/egl/Makefile @@ -28,7 +28,7 @@ wayland_INCLUDES = \ -I$(TOP)/src/gallium/winsys \ -I$(TOP)/src/egl/wayland/wayland-egl \ -I$(TOP)/src/egl/wayland/wayland-drm \ - $(shell $(PKG_CONFIG) --cflags-only-I libdrm wayland-client) + $(shell $(PKG_CONFIG) --cflags-only-I libdrm wayland-client wayland-server) wayland_SOURCES = $(wildcard wayland/*.c) wayland_OBJECTS = $(wayland_SOURCES:.c=.o) @@ -49,8 +49,8 @@ null_SOURCES = $(wildcard null/*.c) null_OBJECTS = $(null_SOURCES:.c=.o) -ALL_INCLUDES = $(common_INCLUDES) $(x11_INCLUDES) $(drm_INCLUDES) $(fbdev_INCLUDES) $(null_INCLUDES) -ALL_SOURCES = $(common_SOURCES) $(x11_SOURCES) $(drm_SOURCES) $(fbdev_SOURCES) $(null_SOURCES) +ALL_INCLUDES = $(common_INCLUDES) $(x11_INCLUDES) $(drm_INCLUDES) $(fbdev_INCLUDES) $(null_INCLUDES) $(wayland_INCLUDES) +ALL_SOURCES = $(common_SOURCES) $(x11_SOURCES) $(drm_SOURCES) $(fbdev_SOURCES) $(null_SOURCES) $(wayland_SOURCES) EGL_OBJECTS = $(common_OBJECTS) EGL_CPPFLAGS = $(common_INCLUDES) @@ -64,6 +64,7 @@ ifneq ($(findstring wayland, $(EGL_PLATFORMS)),) EGL_OBJECTS += $(wayland_OBJECTS) EGL_CPPFLAGS += -DHAVE_WAYLAND_BACKEND DEFINES += -DHAVE_WAYLAND_BACKEND +common_INCLUDES += $(wayland_INCLUDES) endif ifneq ($(findstring drm, $(EGL_PLATFORMS)),) EGL_OBJECTS += $(drm_OBJECTS) -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Fix build for gbm having wayland
gbm: backends/dri/gbm_dri.c fails to find wayland-drm-server-protocol.h because egl/wayland is not built before gbm. Signed-off-by: Elvis Lee --- src/gbm/Makefile.am |3 +++ 1 file changed, 3 insertions(+) diff --git a/src/gbm/Makefile.am b/src/gbm/Makefile.am index 5ca2839..8f56873 100644 --- a/src/gbm/Makefile.am +++ b/src/gbm/Makefile.am @@ -22,6 +22,7 @@ libgbm_la_LIBADD = $(LIBUDEV_LIBS) $(DLOPEN_LIBS) if HAVE_EGL_PLATFORM_WAYLAND AM_CPPFLAGS = -DHAVE_WAYLAND_PLATFORM +BUILT_SOURCES = wayland-drm-server-protocol.h endif if HAVE_DRI @@ -42,3 +43,5 @@ endif all-local: libgbm.la $(MKDIR_P) $(top_builddir)/$(LIB_DIR); ln -f .libs/libgbm.so.1.0.0 $(top_builddir)/$(LIB_DIR)/libgbm.so +wayland-drm-server-protocol.h : ../egl/wayland/wayland-drm/Makefile + $(MAKE) -C ../egl/wayland/wayland-drm/ wayland-drm-server-protocol.h -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/gbm: renaming pitch to stride on gallium
commit '7250cd506baa0bd4649b30d87509cdd0cbc06a57' changes struct gbm_bo, renaming it's 'pitch' to 'stride'. This applies to Gallium. Signed-off-by: Elvis Lee --- src/gallium/state_trackers/gbm/gbm_drm.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/state_trackers/gbm/gbm_drm.c b/src/gallium/state_trackers/gbm/gbm_drm.c index a327fda..eb426ef 100644 --- a/src/gallium/state_trackers/gbm/gbm_drm.c +++ b/src/gallium/state_trackers/gbm/gbm_drm.c @@ -131,7 +131,7 @@ gbm_gallium_drm_bo_create_from_egl_image(struct gbm_device *gbm, gdrm->screen->resource_get_handle(gdrm->screen, bo->resource, &whandle); bo->base.base.handle.u32 = whandle.handle; - bo->base.base.pitch = whandle.stride; + bo->base.base.stride = whandle.stride; return &bo->base.base; } @@ -180,7 +180,7 @@ gbm_gallium_drm_bo_create(struct gbm_device *gbm, gdrm->screen->resource_get_handle(gdrm->screen, bo->resource, &whandle); bo->base.base.handle.u32 = whandle.handle; - bo->base.base.pitch = whandle.stride; + bo->base.base.stride = whandle.stride; return &bo->base.base; } -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52168] lp_test_blend regression
https://bugs.freedesktop.org/show_bug.cgi?id=52168 José Fonseca changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from José Fonseca 2012-07-17 12:33:41 PDT --- Thanks Vinson. Should be fixed with commit e253175c9c8034bfc13ecc3e16ab72007bde744a Author: James Benton Date: Tue Jul 17 12:08:02 2012 +0100 llvmpipe: Fix bug with blend factor in complementary optimisations. Fixes fdo 52168. Reviewed-by: José Fonseca -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52098] [llvmpipe] piglit glsl-mat-from-int-ctor-03.shader_test regression
https://bugs.freedesktop.org/show_bug.cgi?id=52098 José Fonseca changed: What|Removed |Added AssignedTo|mesa-dev@lists.freedesktop. |jfons...@vmware.com |org | --- Comment #1 from José Fonseca 2012-07-17 12:47:57 PDT --- Hi Vinson. The test passes here with LLVM 3.1 on x86. What's your setup? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 3/5] intel gen4-5: Correctly setup the parameters in the sf.
On 30 June 2012 11:50, Olivier Galibert wrote:
> This patch also correct a couple of problems with noperspective
> interpolation.
>
> At that point all the glsl 1.1/1.3 interpolation tests that do not
> clip pass (the -none ones).
>
> The fs code does not use the pre-resolved interpolation modes in order
> not to mess with gen6+. Sharing the resolution would require putting
> brw_wm_prog before brw_clip_prog and brw_sf_prog. This may be a good
> thing, but it could have unexpected consequences, so it's better be
> done independently in any case.
>
> Signed-off-by: Olivier Galibert
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp |2 +-
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |5 +
> src/mesa/drivers/dri/i965/brw_sf.c |9 +-
> src/mesa/drivers/dri/i965/brw_sf.h |2 +-
> src/mesa/drivers/dri/i965/brw_sf_emit.c | 164
> +-
> 5 files changed, 95 insertions(+), 87 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 710f2ff..b142f2b 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -506,7 +506,7 @@ fs_visitor::emit_general_interpolation(ir_variable *ir)
> struct brw_reg interp = interp_reg(location, k);
>emit_linterp(attr, fs_reg(interp), interpolation_mode,
> ir->centroid);
> - if (intel->gen < 6) {
> + if (intel->gen < 6 && interpolation_mode ==
> INTERP_QUALIFIER_SMOOTH) {
> emit(BRW_OPCODE_MUL, attr, attr, this->pixel_w);
> }
>}
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> index 9bd1e67..ab83a95 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> @@ -1924,6 +1924,11 @@ fs_visitor::emit_interpolation_setup_gen4()
> emit(BRW_OPCODE_ADD,
> this->delta_y[BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC],
> this->pixel_y, fs_reg(negate(brw_vec1_grf(1, 1;
>
> + this->delta_x[BRW_WM_NONPERSPECTIVE_PIXEL_BARYCENTRIC] =
> + this->delta_x[BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC];
> + this->delta_y[BRW_WM_NONPERSPECTIVE_PIXEL_BARYCENTRIC] =
> + this->delta_y[BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC];
> +
>
Can we add a comment explaining why this is correct? Something like this
maybe:
"On Gen4-5, we accomplish perspective-correct interpolation by dividing the
attribute values by w in the vertex shader, interpolating the result
linearly in screen space, and then multiplying by w in the fragment
shader. So the interpolation step is always linear in screen space,
regardless of whether the attribute is perspective or non-perspective.
Accordingly, we use the same delta_x and delta_y values for both kinds of
interpolation."
> this->current_annotation = "compute pos.w and 1/pos.w";
> /* Compute wpos.w. It's always in our setup, since it's needed to
> * interpolate the other attributes.
> diff --git a/src/mesa/drivers/dri/i965/brw_sf.c
> b/src/mesa/drivers/dri/i965/brw_sf.c
> index 0cc4fc7..85f5f51 100644
> --- a/src/mesa/drivers/dri/i965/brw_sf.c
> +++ b/src/mesa/drivers/dri/i965/brw_sf.c
> @@ -139,6 +139,7 @@ brw_upload_sf_prog(struct brw_context *brw)
> struct brw_sf_prog_key key;
> /* _NEW_BUFFERS */
> bool render_to_fbo = _mesa_is_user_fbo(ctx->DrawBuffer);
> + int i;
>
> memset(&key, 0, sizeof(key));
>
> @@ -191,7 +192,13 @@ brw_upload_sf_prog(struct brw_context *brw)
>key.sprite_origin_lower_left = true;
>
> /* _NEW_LIGHT */
> - key.do_flat_shading = (ctx->Light.ShadeModel == GL_FLAT);
> + key.has_flat_shading = 0;
> + for (i = 0; i < BRW_VERT_RESULT_MAX; i++) {
> + if (brw_get_interpolation_mode(brw, i) == INTERP_QUALIFIER_FLAT) {
> + key.has_flat_shading = 1;
> + break;
> + }
> + }
> key.do_twoside_color = (ctx->Light.Enabled &&
> ctx->Light.Model.TwoSide) ||
> ctx->VertexProgram._TwoSideEnabled;
> brw_copy_interpolation_modes(brw, key.interpolation_mode);
> diff --git a/src/mesa/drivers/dri/i965/brw_sf.h
> b/src/mesa/drivers/dri/i965/brw_sf.h
> index 0a8135c..c718072 100644
> --- a/src/mesa/drivers/dri/i965/brw_sf.h
> +++ b/src/mesa/drivers/dri/i965/brw_sf.h
> @@ -50,7 +50,7 @@ struct brw_sf_prog_key {
> uint8_t point_sprite_coord_replace;
> GLuint primitive:2;
> GLuint do_twoside_color:1;
> - GLuint do_flat_shading:1;
> + GLuint has_flat_shading:1;
> GLuint frontface_ccw:1;
> GLuint do_point_sprite:1;
> GLuint do_point_coord:1;
> diff --git a/src/mesa/drivers/dri/i965/brw_sf_emit.c
> b/src/mesa/drivers/dri/i965/brw_sf_emit.c
> index 9d8aa38..387685a 100644
> --- a/src/mesa/drivers/dri/i965/brw_sf_emit.c
> +++ b/src/mesa/drivers/dri/i965/brw_sf_emit.c
> @@ -44,6 +44,17 @@
>
>
> /**
> + * Determine the vue sl
[Mesa-dev] [Bug 46528] Compilation fail with LLVM under Windows 7 x64 in release
https://bugs.freedesktop.org/show_bug.cgi?id=46528 José Fonseca changed: What|Removed |Added CC||jfons...@vmware.com --- Comment #1 from José Fonseca 2012-07-17 12:52:05 PDT --- The output is illegible. I'll need to find a way to get ungarbled output. I think you need to install python win32 extensions for scons to behave properly. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52167] llvmpipe test programs link fails when ld --as-needed option is used
https://bugs.freedesktop.org/show_bug.cgi?id=52167 José Fonseca changed: What|Removed |Added CC||jfons...@vmware.com --- Comment #2 from José Fonseca 2012-07-17 12:54:34 PDT --- "-ldl" appears several time in the command line. So I don't understand why dlclose is not dlclose. I'm not an automake expert so I don't know how to help here. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 4/5] intel gen4-5: Correctly handle flat vs. non-flat in the clipper.
On 30 June 2012 11:50, Olivier Galibert wrote:
> At that point, all interpolation piglit tests involving fixed clipping
> work as long as there's no noperspective.
>
> Signed-off-by: Olivier Galibert
> ---
> src/mesa/drivers/dri/i965/brw_clip.c | 10 -
> src/mesa/drivers/dri/i965/brw_clip.h |6 +--
> src/mesa/drivers/dri/i965/brw_clip_line.c |6 +--
> src/mesa/drivers/dri/i965/brw_clip_tri.c | 20 -
> src/mesa/drivers/dri/i965/brw_clip_unfilled.c |2 +-
> src/mesa/drivers/dri/i965/brw_clip_util.c | 56
> +++--
> 6 files changed, 41 insertions(+), 59 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_clip.c
> b/src/mesa/drivers/dri/i965/brw_clip.c
> index 52e8c47..952eb4a 100644
> --- a/src/mesa/drivers/dri/i965/brw_clip.c
> +++ b/src/mesa/drivers/dri/i965/brw_clip.c
> @@ -215,7 +215,7 @@ brw_upload_clip_prog(struct brw_context *brw)
> struct intel_context *intel = &brw->intel;
> struct gl_context *ctx = &intel->ctx;
> struct brw_clip_prog_key key;
> -
> + int i;
> memset(&key, 0, sizeof(key));
>
> brw_lookup_interpolation(brw);
> @@ -227,7 +227,13 @@ brw_upload_clip_prog(struct brw_context *brw)
> /* CACHE_NEW_VS_PROG (also part of VUE map) */
> key.attrs = brw->vs.prog_data->outputs_written;
> /* _NEW_LIGHT */
> - key.do_flat_shading = (ctx->Light.ShadeModel == GL_FLAT);
> + key.has_flat_shading = 0;
> + for (i = 0; i < BRW_VERT_RESULT_MAX; i++) {
> + if (brw_get_interpolation_mode(brw, i) == INTERP_QUALIFIER_FLAT) {
> + key.has_flat_shading = 1;
> + break;
> + }
> + }
> key.pv_first = (ctx->Light.ProvokingVertex ==
> GL_FIRST_VERTEX_CONVENTION);
> brw_copy_interpolation_modes(brw, key.interpolation_mode);
> /* _NEW_TRANSFORM (also part of VUE map)*/
> diff --git a/src/mesa/drivers/dri/i965/brw_clip.h
> b/src/mesa/drivers/dri/i965/brw_clip.h
> index 6f811ae..0ea0394 100644
> --- a/src/mesa/drivers/dri/i965/brw_clip.h
> +++ b/src/mesa/drivers/dri/i965/brw_clip.h
> @@ -46,7 +46,7 @@ struct brw_clip_prog_key {
> GLbitfield64 interpolation_mode[2]; /* copy of the main context */
> GLuint primitive:4;
> GLuint nr_userclip:4;
> - GLuint do_flat_shading:1;
> + GLuint has_flat_shading:1;
> GLuint pv_first:1;
> GLuint do_unfilled:1;
> GLuint fill_cw:2; /* includes cull information */
> @@ -166,8 +166,8 @@ void brw_clip_kill_thread(struct brw_clip_compile *c);
> struct brw_reg brw_clip_plane_stride( struct brw_clip_compile *c );
> struct brw_reg brw_clip_plane0_address( struct brw_clip_compile *c );
>
> -void brw_clip_copy_colors( struct brw_clip_compile *c,
> - GLuint to, GLuint from );
> +void brw_clip_copy_flatshaded_attributes( struct brw_clip_compile *c,
> + GLuint to, GLuint from );
>
> void brw_clip_init_clipmask( struct brw_clip_compile *c );
>
> diff --git a/src/mesa/drivers/dri/i965/brw_clip_line.c
> b/src/mesa/drivers/dri/i965/brw_clip_line.c
> index 6cf2bd2..729d8c0 100644
> --- a/src/mesa/drivers/dri/i965/brw_clip_line.c
> +++ b/src/mesa/drivers/dri/i965/brw_clip_line.c
> @@ -271,11 +271,11 @@ void brw_emit_line_clip( struct brw_clip_compile *c )
> brw_clip_line_alloc_regs(c);
> brw_clip_init_ff_sync(c);
>
> - if (c->key.do_flat_shading) {
> + if (c->key.has_flat_shading) {
>if (c->key.pv_first)
> - brw_clip_copy_colors(c, 1, 0);
> + brw_clip_copy_flatshaded_attributes(c, 1, 0);
>else
> - brw_clip_copy_colors(c, 0, 1);
> + brw_clip_copy_flatshaded_attributes(c, 0, 1);
> }
>
> clip_and_emit_line(c);
> diff --git a/src/mesa/drivers/dri/i965/brw_clip_tri.c
> b/src/mesa/drivers/dri/i965/brw_clip_tri.c
> index a29f8e0..71225f5 100644
> --- a/src/mesa/drivers/dri/i965/brw_clip_tri.c
> +++ b/src/mesa/drivers/dri/i965/brw_clip_tri.c
> @@ -187,8 +187,8 @@ void brw_clip_tri_flat_shade( struct brw_clip_compile
> *c )
>
> brw_IF(p, BRW_EXECUTE_1);
> {
> - brw_clip_copy_colors(c, 1, 0);
> - brw_clip_copy_colors(c, 2, 0);
> + brw_clip_copy_flatshaded_attributes(c, 1, 0);
> + brw_clip_copy_flatshaded_attributes(c, 2, 0);
> }
> brw_ELSE(p);
> {
> @@ -200,19 +200,19 @@ void brw_clip_tri_flat_shade( struct
> brw_clip_compile *c )
> brw_imm_ud(_3DPRIM_TRIFAN));
> brw_IF(p, BRW_EXECUTE_1);
> {
> - brw_clip_copy_colors(c, 0, 1);
> - brw_clip_copy_colors(c, 2, 1);
> + brw_clip_copy_flatshaded_attributes(c, 0, 1);
> + brw_clip_copy_flatshaded_attributes(c, 2, 1);
> }
> brw_ELSE(p);
> {
> - brw_clip_copy_colors(c, 1, 0);
> - brw_clip_copy_colors(c, 2, 0);
> + brw_clip_copy_flatshaded_attributes(c, 1, 0);
> + brw_clip_copy_flatshaded_attributes(c, 2, 0);
> }
> brw_ENDIF(p);
>}
>
Re: [Mesa-dev] wider registers in llvmpipe
- Original Message - > FYI, I've just pushed a branch named llvmpipe-wider-regs, which > allows llvmpipe to leverage SIMD registers wider than 128bits. > > Unfortunately, performance-wise this doesn't change much, as llvmpipe > performance is dominated by integer SIMD instructions, whereas > currently the AVX instruction set currently only supports floating > SIMD instructions. Actually, often things will get slightly slower, > as there are considerable overheads in piecing together the 256 > floating point code paths and 128-bit integer code paths. > > The benefit for this change is foremost architectural: llvmpipe now > makes less assumptions regarding the number of pixels/quads/etc that > fit into a hardware register, a flexibility which will be necessary > to get things like per-pixel LOD working properly. > > This barely touch files outside gallivm/draw/llvmpipe modules. I > haven't tested i915g, r300g, so let me know if there are regressions > / concerns. I'd like to merge this into master soon. I went ahead and pushed, after doing more testing. If there's any regression on any driver as consequence just let me know. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix build for gbm having wayland
On Tue, Jul 17, 2012 at 08:14:32PM +0900, Elvis Lee wrote: > gbm: backends/dri/gbm_dri.c fails to find wayland-drm-server-protocol.h > because egl/wayland is not built before gbm. I just pushed a different fix to include a copy of the format enums in wayland-drm.h instead and not try to include the generated files across directories. Thanks, Kristian > Signed-off-by: Elvis Lee > --- > src/gbm/Makefile.am |3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/src/gbm/Makefile.am b/src/gbm/Makefile.am > index 5ca2839..8f56873 100644 > --- a/src/gbm/Makefile.am > +++ b/src/gbm/Makefile.am > @@ -22,6 +22,7 @@ libgbm_la_LIBADD = $(LIBUDEV_LIBS) $(DLOPEN_LIBS) > > if HAVE_EGL_PLATFORM_WAYLAND > AM_CPPFLAGS = -DHAVE_WAYLAND_PLATFORM > +BUILT_SOURCES = wayland-drm-server-protocol.h > endif > > if HAVE_DRI > @@ -42,3 +43,5 @@ endif > all-local: libgbm.la > $(MKDIR_P) $(top_builddir)/$(LIB_DIR); > ln -f .libs/libgbm.so.1.0.0 $(top_builddir)/$(LIB_DIR)/libgbm.so > +wayland-drm-server-protocol.h : ../egl/wayland/wayland-drm/Makefile > + $(MAKE) -C ../egl/wayland/wayland-drm/ wayland-drm-server-protocol.h > -- > 1.7.9.5 > > ___ > 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] st/gbm: renaming pitch to stride on gallium
On Tue, Jul 17, 2012 at 08:28:57PM +0900, Elvis Lee wrote: > commit '7250cd506baa0bd4649b30d87509cdd0cbc06a57' > changes struct gbm_bo, renaming it's 'pitch' to 'stride'. > This applies to Gallium. Thanks, applied. I'm trying to update it to support the new gbm import function now. Did you consider gallium as a dri driver though? I'm thinking that maintaining 1) the native gallium interface, 2) the gallium dri interface and 3) the intel dri interface is just too much. I'd like to drop support for the the gbm gallium state tracker and just use the DRI statetracker instead. Kristian > Signed-off-by: Elvis Lee > --- > src/gallium/state_trackers/gbm/gbm_drm.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/gallium/state_trackers/gbm/gbm_drm.c > b/src/gallium/state_trackers/gbm/gbm_drm.c > index a327fda..eb426ef 100644 > --- a/src/gallium/state_trackers/gbm/gbm_drm.c > +++ b/src/gallium/state_trackers/gbm/gbm_drm.c > @@ -131,7 +131,7 @@ gbm_gallium_drm_bo_create_from_egl_image(struct > gbm_device *gbm, > gdrm->screen->resource_get_handle(gdrm->screen, bo->resource, &whandle); > > bo->base.base.handle.u32 = whandle.handle; > - bo->base.base.pitch = whandle.stride; > + bo->base.base.stride = whandle.stride; > > return &bo->base.base; > } > @@ -180,7 +180,7 @@ gbm_gallium_drm_bo_create(struct gbm_device *gbm, > gdrm->screen->resource_get_handle(gdrm->screen, bo->resource, &whandle); > > bo->base.base.handle.u32 = whandle.handle; > - bo->base.base.pitch = whandle.stride; > + bo->base.base.stride = whandle.stride; > > return &bo->base.base; > } > -- > 1.7.9.5 > > ___ > 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 3/5] intel gen4-5: Correctly setup the parameters in the sf.
On 17 July 2012 05:50, Paul Berry wrote:
> On 30 June 2012 11:50, Olivier Galibert wrote:
>
>> This patch also correct a couple of problems with noperspective
>> interpolation.
>>
>> At that point all the glsl 1.1/1.3 interpolation tests that do not
>> clip pass (the -none ones).
>>
>> The fs code does not use the pre-resolved interpolation modes in order
>> not to mess with gen6+. Sharing the resolution would require putting
>> brw_wm_prog before brw_clip_prog and brw_sf_prog. This may be a good
>> thing, but it could have unexpected consequences, so it's better be
>> done independently in any case.
>>
>> Signed-off-by: Olivier Galibert
>> ---
>> src/mesa/drivers/dri/i965/brw_fs.cpp |2 +-
>> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |5 +
>> src/mesa/drivers/dri/i965/brw_sf.c |9 +-
>> src/mesa/drivers/dri/i965/brw_sf.h |2 +-
>> src/mesa/drivers/dri/i965/brw_sf_emit.c | 164
>> +-
>> 5 files changed, 95 insertions(+), 87 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> index 710f2ff..b142f2b 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> @@ -506,7 +506,7 @@ fs_visitor::emit_general_interpolation(ir_variable
>> *ir)
>> struct brw_reg interp = interp_reg(location, k);
>>emit_linterp(attr, fs_reg(interp), interpolation_mode,
>> ir->centroid);
>> - if (intel->gen < 6) {
>> + if (intel->gen < 6 && interpolation_mode ==
>> INTERP_QUALIFIER_SMOOTH) {
>> emit(BRW_OPCODE_MUL, attr, attr, this->pixel_w);
>> }
>>}
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
>> b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
>> index 9bd1e67..ab83a95 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
>> @@ -1924,6 +1924,11 @@ fs_visitor::emit_interpolation_setup_gen4()
>> emit(BRW_OPCODE_ADD,
>> this->delta_y[BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC],
>> this->pixel_y, fs_reg(negate(brw_vec1_grf(1, 1;
>>
>> + this->delta_x[BRW_WM_NONPERSPECTIVE_PIXEL_BARYCENTRIC] =
>> + this->delta_x[BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC];
>> + this->delta_y[BRW_WM_NONPERSPECTIVE_PIXEL_BARYCENTRIC] =
>> + this->delta_y[BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC];
>> +
>>
>
> Can we add a comment explaining why this is correct? Something like this
> maybe:
>
> "On Gen4-5, we accomplish perspective-correct interpolation by dividing
> the attribute values by w in the vertex shader, interpolating the result
> linearly in screen space, and then multiplying by w in the fragment
> shader. So the interpolation step is always linear in screen space,
> regardless of whether the attribute is perspective or non-perspective.
> Accordingly, we use the same delta_x and delta_y values for both kinds of
> interpolation."
>
Whoops, my memory was faulty. This should say "...in the sf thread...",
not "...in the vertex shader...".
>
>
>> this->current_annotation = "compute pos.w and 1/pos.w";
>> /* Compute wpos.w. It's always in our setup, since it's needed to
>> * interpolate the other attributes.
>> diff --git a/src/mesa/drivers/dri/i965/brw_sf.c
>> b/src/mesa/drivers/dri/i965/brw_sf.c
>> index 0cc4fc7..85f5f51 100644
>> --- a/src/mesa/drivers/dri/i965/brw_sf.c
>> +++ b/src/mesa/drivers/dri/i965/brw_sf.c
>> @@ -139,6 +139,7 @@ brw_upload_sf_prog(struct brw_context *brw)
>> struct brw_sf_prog_key key;
>> /* _NEW_BUFFERS */
>> bool render_to_fbo = _mesa_is_user_fbo(ctx->DrawBuffer);
>> + int i;
>>
>> memset(&key, 0, sizeof(key));
>>
>> @@ -191,7 +192,13 @@ brw_upload_sf_prog(struct brw_context *brw)
>>key.sprite_origin_lower_left = true;
>>
>> /* _NEW_LIGHT */
>> - key.do_flat_shading = (ctx->Light.ShadeModel == GL_FLAT);
>> + key.has_flat_shading = 0;
>> + for (i = 0; i < BRW_VERT_RESULT_MAX; i++) {
>> + if (brw_get_interpolation_mode(brw, i) == INTERP_QUALIFIER_FLAT) {
>> + key.has_flat_shading = 1;
>> + break;
>> + }
>> + }
>> key.do_twoside_color = (ctx->Light.Enabled &&
>> ctx->Light.Model.TwoSide) ||
>> ctx->VertexProgram._TwoSideEnabled;
>> brw_copy_interpolation_modes(brw, key.interpolation_mode);
>> diff --git a/src/mesa/drivers/dri/i965/brw_sf.h
>> b/src/mesa/drivers/dri/i965/brw_sf.h
>> index 0a8135c..c718072 100644
>> --- a/src/mesa/drivers/dri/i965/brw_sf.h
>> +++ b/src/mesa/drivers/dri/i965/brw_sf.h
>> @@ -50,7 +50,7 @@ struct brw_sf_prog_key {
>> uint8_t point_sprite_coord_replace;
>> GLuint primitive:2;
>> GLuint do_twoside_color:1;
>> - GLuint do_flat_shading:1;
>> + GLuint has_flat_shading:1;
>> GLuint frontface_ccw:1;
>> GLuint do_point_sprite:1;
>> GLuint do_point_coord:1;
>>
Re: [Mesa-dev] [PATCH] st/egl: Fix build for wayland includes
On Tue, Jul 17, 2012 at 08:01:43PM +0900, Elvis Lee wrote: > common/native_wayland_drm_bufmgr_helper.c fails to find wayland-server.h Applied, thanks. Kristian > Signed-off-by: Elvis Lee > --- > src/gallium/state_trackers/egl/Makefile |7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/src/gallium/state_trackers/egl/Makefile > b/src/gallium/state_trackers/egl/Makefile > index fe42fbb..66b2e7e 100644 > --- a/src/gallium/state_trackers/egl/Makefile > +++ b/src/gallium/state_trackers/egl/Makefile > @@ -28,7 +28,7 @@ wayland_INCLUDES = \ > -I$(TOP)/src/gallium/winsys \ > -I$(TOP)/src/egl/wayland/wayland-egl \ > -I$(TOP)/src/egl/wayland/wayland-drm \ > - $(shell $(PKG_CONFIG) --cflags-only-I libdrm wayland-client) > + $(shell $(PKG_CONFIG) --cflags-only-I libdrm wayland-client > wayland-server) > > wayland_SOURCES = $(wildcard wayland/*.c) > wayland_OBJECTS = $(wayland_SOURCES:.c=.o) > @@ -49,8 +49,8 @@ null_SOURCES = $(wildcard null/*.c) > null_OBJECTS = $(null_SOURCES:.c=.o) > > > -ALL_INCLUDES = $(common_INCLUDES) $(x11_INCLUDES) $(drm_INCLUDES) > $(fbdev_INCLUDES) $(null_INCLUDES) > -ALL_SOURCES = $(common_SOURCES) $(x11_SOURCES) $(drm_SOURCES) > $(fbdev_SOURCES) $(null_SOURCES) > +ALL_INCLUDES = $(common_INCLUDES) $(x11_INCLUDES) $(drm_INCLUDES) > $(fbdev_INCLUDES) $(null_INCLUDES) $(wayland_INCLUDES) > +ALL_SOURCES = $(common_SOURCES) $(x11_SOURCES) $(drm_SOURCES) > $(fbdev_SOURCES) $(null_SOURCES) $(wayland_SOURCES) > > EGL_OBJECTS = $(common_OBJECTS) > EGL_CPPFLAGS = $(common_INCLUDES) > @@ -64,6 +64,7 @@ ifneq ($(findstring wayland, $(EGL_PLATFORMS)),) > EGL_OBJECTS += $(wayland_OBJECTS) > EGL_CPPFLAGS += -DHAVE_WAYLAND_BACKEND > DEFINES += -DHAVE_WAYLAND_BACKEND > +common_INCLUDES += $(wayland_INCLUDES) > endif > ifneq ($(findstring drm, $(EGL_PLATFORMS)),) > EGL_OBJECTS += $(drm_OBJECTS) > -- > 1.7.9.5 > > ___ > 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] wider registers in llvmpipe
On Tue, Jul 17, 2012 at 05:57:37AM -0700, Jose Fonseca wrote: > - Original Message - > > FYI, I've just pushed a branch named llvmpipe-wider-regs, which > > allows llvmpipe to leverage SIMD registers wider than 128bits. > > > > Unfortunately, performance-wise this doesn't change much, as llvmpipe > > performance is dominated by integer SIMD instructions, whereas > > currently the AVX instruction set currently only supports floating > > SIMD instructions. Actually, often things will get slightly slower, > > as there are considerable overheads in piecing together the 256 > > floating point code paths and 128-bit integer code paths. > > > > The benefit for this change is foremost architectural: llvmpipe now > > makes less assumptions regarding the number of pixels/quads/etc that > > fit into a hardware register, a flexibility which will be necessary > > to get things like per-pixel LOD working properly. > > > > This barely touch files outside gallivm/draw/llvmpipe modules. I > > haven't tested i915g, r300g, so let me know if there are regressions > > / concerns. I'd like to merge this into master soon. > > I went ahead and pushed, after doing more testing. If there's any regression > on any driver as consequence just let me know. We'll need something like this. Kristian >From 1ae59bde4c960004aa22255b25fb4175beaafdd6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kristian=20H=C3=B8gsberg?= Date: Tue, 17 Jul 2012 09:24:39 -0400 Subject: [PATCH] gallium: Add $(TOP)/src/gallium/auxiliary/util to include path MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit So we pick up the new util/u_cpu_detect.h Signed-off-by: Kristian Høgsberg --- src/gallium/Makefile.template |1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/Makefile.template b/src/gallium/Makefile.template index 036c119..ed14977 100644 --- a/src/gallium/Makefile.template +++ b/src/gallium/Makefile.template @@ -20,6 +20,7 @@ INCLUDES = \ -I. \ -I$(TOP)/src/gallium/include \ -I$(TOP)/src/gallium/auxiliary \ + -I$(TOP)/src/gallium/auxiliary/util \ -I$(TOP)/src/gallium/drivers \ $(LIBRARY_INCLUDES) -- 1.7.10.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx: build tests after libglx.la
On 17/07/2012 04:48, Matt Turner wrote: > Previously, if you ran make followed by make check it would work, but > if you just ran make check the test program would fail to compile. > --- > src/glx/Makefile.am |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am > index 6ca85cd..bb23998 100644 > --- a/src/glx/Makefile.am > +++ b/src/glx/Makefile.am > @@ -24,7 +24,7 @@ SHARED_GLAPI_CFLAGS = -DGLX_SHARED_GLAPI > SHARED_GLAPI_LIBS = $(top_builddir)/src/mapi/shared-glapi/libglapi.la > endif > > -SUBDIRS=tests > +SUBDIRS=. tests > > GLAPI_LIB = ../mapi/glapi/libglapi.la Reviewed-by: Jon TURNEY ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] wider registers in llvmpipe
On Tue, Jul 17, 2012 at 09:26:49AM -0400, Kristian Høgsberg wrote: > On Tue, Jul 17, 2012 at 05:57:37AM -0700, Jose Fonseca wrote: > > - Original Message - > > > FYI, I've just pushed a branch named llvmpipe-wider-regs, which > > > allows llvmpipe to leverage SIMD registers wider than 128bits. > > > > > > Unfortunately, performance-wise this doesn't change much, as llvmpipe > > > performance is dominated by integer SIMD instructions, whereas > > > currently the AVX instruction set currently only supports floating > > > SIMD instructions. Actually, often things will get slightly slower, > > > as there are considerable overheads in piecing together the 256 > > > floating point code paths and 128-bit integer code paths. > > > > > > The benefit for this change is foremost architectural: llvmpipe now > > > makes less assumptions regarding the number of pixels/quads/etc that > > > fit into a hardware register, a flexibility which will be necessary > > > to get things like per-pixel LOD working properly. > > > > > > This barely touch files outside gallivm/draw/llvmpipe modules. I > > > haven't tested i915g, r300g, so let me know if there are regressions > > > / concerns. I'd like to merge this into master soon. > > > > I went ahead and pushed, after doing more testing. If there's any > > regression on any driver as consequence just let me know. > > We'll need something like this. > > Kristian > > From 1ae59bde4c960004aa22255b25fb4175beaafdd6 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Kristian=20H=C3=B8gsberg?= > Date: Tue, 17 Jul 2012 09:24:39 -0400 > Subject: [PATCH] gallium: Add $(TOP)/src/gallium/auxiliary/util to include > path > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > So we pick up the new util/u_cpu_detect.h > > Signed-off-by: Kristian Høgsberg > --- > src/gallium/Makefile.template |1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/gallium/Makefile.template b/src/gallium/Makefile.template > index 036c119..ed14977 100644 > --- a/src/gallium/Makefile.template > +++ b/src/gallium/Makefile.template > @@ -20,6 +20,7 @@ INCLUDES = \ > -I. \ > -I$(TOP)/src/gallium/include \ > -I$(TOP)/src/gallium/auxiliary \ > + -I$(TOP)/src/gallium/auxiliary/util \ > -I$(TOP)/src/gallium/drivers \ > $(LIBRARY_INCLUDES) > > -- > 1.7.10.2 > I think we need to add the util prefix to the u_cpu_detect.h include in lp_bld_quad.c. This is what is done in all the other gallivm files. See attached patch. -Tom > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > >From 00089d54d37fd39d2c98c9ddabd4024f76513b68 Mon Sep 17 00:00:00 2001 From: Tom Stellard Date: Tue, 17 Jul 2012 09:58:36 -0400 Subject: [PATCH] gallivm: Use full include path for u_cpu_detect.h --- src/gallium/auxiliary/gallivm/lp_bld_quad.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_quad.c b/src/gallium/auxiliary/gallivm/lp_bld_quad.c index b1ba7c7..209f6a1 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_quad.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_quad.c @@ -26,7 +26,7 @@ **/ -#include "u_cpu_detect.h" +#include "util/u_cpu_detect.h" #include "lp_bld_type.h" #include "lp_bld_arit.h" #include "lp_bld_const.h" -- 1.7.6.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] intel gen4-5: Make noperspective clipping work.
On 30 June 2012 11:50, Olivier Galibert wrote:
> At this point all interpolation tests with fixed clipping work.
>
> Signed-off-by: Olivier Galibert
> ---
> src/mesa/drivers/dri/i965/brw_clip.c |9 ++
> src/mesa/drivers/dri/i965/brw_clip.h |1 +
> src/mesa/drivers/dri/i965/brw_clip_util.c | 133
> ++---
> 3 files changed, 132 insertions(+), 11 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_clip.c
> b/src/mesa/drivers/dri/i965/brw_clip.c
> index 952eb4a..6bfdf24 100644
> --- a/src/mesa/drivers/dri/i965/brw_clip.c
> +++ b/src/mesa/drivers/dri/i965/brw_clip.c
> @@ -234,6 +234,15 @@ brw_upload_clip_prog(struct brw_context *brw)
> break;
>}
> }
> + key.has_noperspective_shading = 0;
> + for (i = 0; i < BRW_VERT_RESULT_MAX; i++) {
> + if (brw_get_interpolation_mode(brw, i) ==
> INTERP_QUALIFIER_NOPERSPECTIVE &&
> + brw->vs.prog_data->vue_map.slot_to_vert_result[i] !=
> VERT_RESULT_HPOS) {
> + key.has_noperspective_shading = 1;
> + break;
> + }
> + }
> +
> key.pv_first = (ctx->Light.ProvokingVertex ==
> GL_FIRST_VERTEX_CONVENTION);
> brw_copy_interpolation_modes(brw, key.interpolation_mode);
> /* _NEW_TRANSFORM (also part of VUE map)*/
> diff --git a/src/mesa/drivers/dri/i965/brw_clip.h
> b/src/mesa/drivers/dri/i965/brw_clip.h
> index 0ea0394..2a7245a 100644
> --- a/src/mesa/drivers/dri/i965/brw_clip.h
> +++ b/src/mesa/drivers/dri/i965/brw_clip.h
> @@ -47,6 +47,7 @@ struct brw_clip_prog_key {
> GLuint primitive:4;
> GLuint nr_userclip:4;
> GLuint has_flat_shading:1;
> + GLuint has_noperspective_shading:1;
> GLuint pv_first:1;
> GLuint do_unfilled:1;
> GLuint fill_cw:2; /* includes cull information */
> diff --git a/src/mesa/drivers/dri/i965/brw_clip_util.c
> b/src/mesa/drivers/dri/i965/brw_clip_util.c
> index 7b0205a..5bdcef8 100644
> --- a/src/mesa/drivers/dri/i965/brw_clip_util.c
> +++ b/src/mesa/drivers/dri/i965/brw_clip_util.c
> @@ -129,6 +129,8 @@ static void brw_clip_project_vertex( struct
> brw_clip_compile *c,
>
> /* Interpolate between two vertices and put the result into a0.0.
> * Increment a0.0 accordingly.
> + *
> + * Beware that dest_ptr can be equal to v0_ptr.
> */
> void brw_clip_interp_vertex( struct brw_clip_compile *c,
> struct brw_indirect dest_ptr,
> @@ -138,8 +140,9 @@ void brw_clip_interp_vertex( struct brw_clip_compile
> *c,
> bool force_edgeflag)
> {
> struct brw_compile *p = &c->func;
> - struct brw_reg tmp = get_tmp(c);
> - GLuint slot;
> + struct brw_context *brw = p->brw;
> + struct brw_reg tmp, t_nopersp, v0_ndc_copy;
> + GLuint slot, delta;
>
> /* Just copy the vertex header:
> */
> @@ -148,13 +151,119 @@ void brw_clip_interp_vertex( struct
> brw_clip_compile *c,
> * back on Ironlake, so needn't change it
> */
> brw_copy_indirect_to_indirect(p, dest_ptr, v0_ptr, 1);
> -
> - /* Iterate over each attribute (could be done in pairs?)
> +
> + /*
> +* First handle the 3D and NDC positioning, in case we need
> +* noperspective interpolation. Doing it early has no performance
> +* impact in any case.
> +*/
> +
> + /* Start by picking up the v0 NDC coordinates, because that vertex
> +* may be shared with the destination.
> +*/
> + if (c->key.has_noperspective_shading) {
> + v0_ndc_copy = get_tmp(c);
> + brw_MOV(p, v0_ndc_copy, deref_4f(v0_ptr,
> +
> brw_vert_result_to_offset(&c->vue_map,
> +
> BRW_VERT_RESULT_NDC)));
> + }
>
Style nit-pick: this is a lot of indentation. How about this instead:
if (c->key.has_noperspective_shading) {
unsigned offset =
brw_vert_result_to_offset(&c->vue_map, BRW_VERT_RESULT_NDC);
v0_ndc_copy = get_tmp(c);
brw_MOV(p, v0_ndc_copy, deref_4f(v0_ptr, offset));
}
> +
> + /*
> +* Compute the new 3D position
> +*/
> +
> + delta = brw_vert_result_to_offset(&c->vue_map, VERT_RESULT_HPOS);
> + tmp = get_tmp(c);
> + brw_MUL(p,
> + vec4(brw_null_reg()),
> + deref_4f(v1_ptr, delta),
> + t0);
> +
> + brw_MAC(p,
> + tmp,
> + negate(deref_4f(v0_ptr, delta)),
> + t0);
> +
> + brw_ADD(p,
> + deref_4f(dest_ptr, delta),
> + deref_4f(v0_ptr, delta),
> + tmp);
> + release_tmp(c, tmp);
>
Since delta and tmp are used elsewhere in this function for other purposes,
I would feel more comfortable if we created a local scope for them by
enclosing this small chunk of code in curly braces, e.g.:
{
/*
* Compute the new 3D position
*/
GLuint delta = brw_vert_result_to_offset(&c->vue_map,
VERT_RESULT_HPOS);
struct brw_reg tmp = get_tmp(c);
brw_MUL(p,
vec4(brw_null_reg()),
deref_4f(v1_ptr, delta),
t0);
brw_MAC(p,
tmp,
[Mesa-dev] [PATCH] configure.ac: Add libLLVMMCJIT to the LLVM_LDFLAGS
This is neccessary for linking the llvmpipe tests. It appears this
dependency was introduced by the "wider native register" changes.
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 9227474..068f632 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1849,7 +1849,7 @@ if test "x$enable_gallium_llvm" = xyes; then
else
LLVM_LIBS="`$LLVM_CONFIG --libs engine bitwriter`"
if test "x$enable_opencl" = xyes; then
-LLVM_LIBS="${LLVM_LIBS} `llvm-config --libs ipo linker
instrumentation`"
+LLVM_LIBS="${LLVM_LIBS} `llvm-config --libs ipo linker
instrumentation mcjit`"
fi
fi
LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
--
1.7.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] intel gen4/5: fix GL_VERTEX_PROGRAM_TWO_SIDE.
On 17 July 2012 01:57, Olivier Galibert wrote: > On Mon, Jul 16, 2012 at 08:43:17PM -0700, Paul Berry wrote: > > Also, I'm not convinced that #3 is necessary. Is there something in the > > spec that dictates this behaviour? My reading of the spec is that if the > > vertex shader writes to gl_BackColor but not glFrontColor, then the > > contents of gl_Color in the fragment shader is undefined. > > Oh, I remember why I did that in the first place. All the front/back > piglit tests only write the appropriate color slot and not the other > one. > > The language is annoying: > The following built-in vertex output variables are available, but > deprecated. A particular one should be > written to if any functionality in a corresponding fragment shader or > fixed pipeline uses it or state derived > from it. Otherwise, behavior is undefined. > out vec4 gl_FrontColor; > out vec4 gl_BackColor; > out vec4 gl_FrontSecondaryColor; > out vec4 gl_BackSecondaryColor; > [...] > > One could argue that you don't "use" gl_FrontColor if all your > polygons are back-facing. Dunno. Do you consider all of the twoside > piglit tests buggy? We can fix *that*. > > OG. > > You have a good point about the piglit tests. It's weird that they don't set gl_FrontColor, but I can't bring myself to consider it a bug. Sigh, I was really hoping we could consider it undefined to write to gl_BackColor and not gl_FrontColor, but I guess it's reasonable for someone to expect that if they only write to gl_BackColor, and they only render backfacing polygons, they should get a sensible value in the fragment shader. If possible, I would still like to think of a way to address this situation that (a) doesn't require modifying both fragment shader back-ends and the SF program, and (b) helps all Mesa drivers, not just Intel Gen4-5. Especially because I suspect we may have bugs in Gen6-7 related to this situation. Would you be happy with one of the following two alternatives? 1. In the GLSL front-end, if we detect that a vertex shader writes to gl_BackColor but not gl_FrontColor, then automatically insert "gl_FrontColor = 0;" into the shader. This will guarantee that whenever gl_BackColor is written, gl_FrontColor is too. 2. In the function brw_compute_vue_map(), assign a VUE slot for VERT_RESULT_COL0 whenever *either* VERT_RESULT_COL0 or VERT_RESULT_BFC0 is used. This will guarantee that we always have a VUE slot available for front color, so we don't have to be as tricky in the FS and SF code. Note that alternative 2 leaves the contents of gl_FrontColor undefined if the vertex shader doesn't write to it. Although I appreciate what you're saying about security leaks due to reads out of place, I think that in this case the security risk is negligible, since the garbage value that winds up in gl_FrontColor will just be a value out of some random register in the vertex shader, not a random value out of memory and not a value belonging to some other process. This morning I'll try to ask some other Intel folks for their opinion on the subject. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] [PATCH 0/5] First batch of gm45 clipping/interpolation fixes
On 16 July 2012 19:33, Paul Berry wrote: > On 14 July 2012 02:21, Olivier Galibert wrote: > >> On Fri, Jul 13, 2012 at 02:45:10PM -0700, Kenneth Graunke wrote: >> > Sorry...been really busy, and most of us haven't actually spent much if >> > any time in the clipper shaders. I'll try and review it within a week. >> >> Ok cool, lack of time is something I completely understand :-) >> >> >> > Despite the lack of response, I am really excited to see that you're >> > working on this---this is a huge step toward bringing GL 3.x back to >> > Gen4/5, and we're all really glad to see it happen! >> >> Excellent. I was starting to wonder if gen4/5 was abandoned (by lack >> of resources if anything), nice to see it isn't. >> > > I'm starting to look at these patches too, since I'm the one who wrote the > VUE code, and I have some familiarity with the Gen4/5 clipper. I'll try to > get some feedback to you within the next 24 hours. > By the way I want to commend you for digging into a really complex corner of the code and making what look like very solid improvements to it. I'm excited to see what else you have planned :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/gbm: renaming pitch to stride on gallium
On Die, 2012-07-17 at 09:07 -0400, Kristian Høgsberg wrote: > On Tue, Jul 17, 2012 at 08:28:57PM +0900, Elvis Lee wrote: > > commit '7250cd506baa0bd4649b30d87509cdd0cbc06a57' > > changes struct gbm_bo, renaming it's 'pitch' to 'stride'. > > This applies to Gallium. > > Thanks, applied. I'm trying to update it to support the new gbm > import function now. Did you consider gallium as a dri driver though? > I'm thinking that maintaining 1) the native gallium interface, 2) the > gallium dri interface and 3) the intel dri interface is just too much. > I'd like to drop support for the the gbm gallium state tracker and > just use the DRI statetracker instead. I don't think that would work for all scenarios supported with Gallium, e.g. for OpenVG. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] wider registers in llvmpipe
Am 17.07.2012 16:02, schrieb Tom Stellard: > On Tue, Jul 17, 2012 at 09:26:49AM -0400, Kristian Høgsberg wrote: >> On Tue, Jul 17, 2012 at 05:57:37AM -0700, Jose Fonseca wrote: >>> - Original Message - FYI, I've just pushed a branch named llvmpipe-wider-regs, which allows llvmpipe to leverage SIMD registers wider than 128bits. Unfortunately, performance-wise this doesn't change much, as llvmpipe performance is dominated by integer SIMD instructions, whereas currently the AVX instruction set currently only supports floating SIMD instructions. Actually, often things will get slightly slower, as there are considerable overheads in piecing together the 256 floating point code paths and 128-bit integer code paths. The benefit for this change is foremost architectural: llvmpipe now makes less assumptions regarding the number of pixels/quads/etc that fit into a hardware register, a flexibility which will be necessary to get things like per-pixel LOD working properly. This barely touch files outside gallivm/draw/llvmpipe modules. I haven't tested i915g, r300g, so let me know if there are regressions / concerns. I'd like to merge this into master soon. >>> >>> I went ahead and pushed, after doing more testing. If there's any >>> regression on any driver as consequence just let me know. >> >> We'll need something like this. >> >> Kristian >> >> From 1ae59bde4c960004aa22255b25fb4175beaafdd6 Mon Sep 17 00:00:00 2001 >> From: =?UTF-8?q?Kristian=20H=C3=B8gsberg?= >> Date: Tue, 17 Jul 2012 09:24:39 -0400 >> Subject: [PATCH] gallium: Add $(TOP)/src/gallium/auxiliary/util to include >> path >> MIME-Version: 1.0 >> Content-Type: text/plain; charset=UTF-8 >> Content-Transfer-Encoding: 8bit >> >> So we pick up the new util/u_cpu_detect.h >> >> Signed-off-by: Kristian Høgsberg >> --- >> src/gallium/Makefile.template |1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/src/gallium/Makefile.template b/src/gallium/Makefile.template >> index 036c119..ed14977 100644 >> --- a/src/gallium/Makefile.template >> +++ b/src/gallium/Makefile.template >> @@ -20,6 +20,7 @@ INCLUDES = \ >> -I. \ >> -I$(TOP)/src/gallium/include \ >> -I$(TOP)/src/gallium/auxiliary \ >> +-I$(TOP)/src/gallium/auxiliary/util \ >> -I$(TOP)/src/gallium/drivers \ >> $(LIBRARY_INCLUDES) >> >> -- >> 1.7.10.2 >> > > I think we need to add the util prefix to the u_cpu_detect.h include > in lp_bld_quad.c. This is what is done in all the other gallivm files. > > See attached patch. Yes I think that would be what was intended. That said, the include is only there for something I didn't actually do in the end, so I've just removed it. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/gbm: renaming pitch to stride on gallium
On Tue, Jul 17, 2012 at 04:51:49PM +0200, Michel Dänzer wrote: > On Die, 2012-07-17 at 09:07 -0400, Kristian Høgsberg wrote: > > On Tue, Jul 17, 2012 at 08:28:57PM +0900, Elvis Lee wrote: > > > commit '7250cd506baa0bd4649b30d87509cdd0cbc06a57' > > > changes struct gbm_bo, renaming it's 'pitch' to 'stride'. > > > This applies to Gallium. > > > > Thanks, applied. I'm trying to update it to support the new gbm > > import function now. Did you consider gallium as a dri driver though? > > I'm thinking that maintaining 1) the native gallium interface, 2) the > > gallium dri interface and 3) the intel dri interface is just too much. > > I'd like to drop support for the the gbm gallium state tracker and > > just use the DRI statetracker instead. > > I don't think that would work for all scenarios supported with Gallium, > e.g. for OpenVG. Yes, I understand that tradeoff. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Add libLLVMMCJIT to the LLVM_LDFLAGS
Thanks.
Reviewed-by: Jose Fonseca
Jose
- Original Message -
> This is neccessary for linking the llvmpipe tests. It appears this
> dependency was introduced by the "wider native register" changes.
> ---
> configure.ac |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 9227474..068f632 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1849,7 +1849,7 @@ if test "x$enable_gallium_llvm" = xyes; then
> else
> LLVM_LIBS="`$LLVM_CONFIG --libs engine bitwriter`"
> if test "x$enable_opencl" = xyes; then
> -LLVM_LIBS="${LLVM_LIBS} `llvm-config --libs ipo
> linker instrumentation`"
> +LLVM_LIBS="${LLVM_LIBS} `llvm-config --libs ipo
> linker instrumentation mcjit`"
> fi
> fi
> LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
> --
> 1.7.7.6
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] can't build/install osmesa and gl at same time
On 17/07/2012 06:55, Dave Airlie wrote: > In Fedora we've always built both osmesa and GL versions of mesa, we > used to do this in two passes but its been possible for a while to do > this in a single pass, and it seems to work. > > However now src/mesa/Makefile.am contains this: > > if HAVE_OSMESA_DRIVER > pkgconfig_DATA = osmesa.pc > else > pkgconfig_DATA = gl.pc > endif > > > so when we go to finish packaging we don't get gl.pc anymore. > > Any ideas? Yes, it looks like commit 39785488 indirectly broke this. http://lists.freedesktop.org/archives/mesa-dev/2012-July/023720.html has a patch. Although really it might make more sense to move osmesa.pc.in down to drivers/osmesa and do it all there ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52140] Ubuntu Unity - Launcher and switcher icons disappeared
https://bugs.freedesktop.org/show_bug.cgi?id=52140 --- Comment #5 from Robert Hooker (Sarvatt) 2012-07-17 16:39:00 PDT --- I haven't been able to bisect it yet but 8.0 branch is fine, master is fine as of may 29th up to f92b2e5e90f456491fc15b3b9612381a83726606 (just before out of tree builds were massively broken) and bad at 22d032707e888dc9718d66c1f59e6efbc04ab9bd (first time I could build it out of tree) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52140] Ubuntu Unity - Launcher and switcher icons disappeared
https://bugs.freedesktop.org/show_bug.cgi?id=52140 Robert Hooker (Sarvatt) changed: What|Removed |Added CC||sarv...@gmail.com -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52209] New: lp_test_format regression
https://bugs.freedesktop.org/show_bug.cgi?id=52209 Bug #: 52209 Summary: lp_test_format regression Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: v...@freedesktop.org CC: jfons...@vmware.com 3469715a8a171512cf9b528702e70393f01c6041 is the first bad commit commit 3469715a8a171512cf9b528702e70393f01c6041 Author: José Fonseca Date: Fri Jul 13 18:09:30 2012 +0100 gallivm,draw,llvmpipe: Support wider native registers. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Drop obsolete .gitignore entries.
From: Michel Dänzer Helps spotting and removing the obsolete generated files, which otherwise break the build. Signed-off-by: Michel Dänzer --- src/glsl/.gitignore |2 -- 1 file changed, 2 deletions(-) diff --git a/src/glsl/.gitignore b/src/glsl/.gitignore index c9a9f30..81240b9 100644 --- a/src/glsl/.gitignore +++ b/src/glsl/.gitignore @@ -1,8 +1,6 @@ glsl_compiler glsl_lexer.cc -glsl_lexer.cpp glsl_parser.cc -glsl_parser.cpp glsl_parser.h glsl_parser.output builtin_function.cpp -- 1.7.10 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure.ac: Further LLVM fixups.
From: Michel Dänzer
* Also add mcjit in the non-OpenCL case.
* Replace hardcoded llvm-config with $LLVM_CONFIG everywhere.
Signed-off-by: Michel Dänzer
---
configure.ac |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index 068f632..1ab75e6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1847,9 +1847,9 @@ if test "x$enable_gallium_llvm" = xyes; then
dnl We can't use $LLVM_VERSION because it has 'svn' stripped out,
LLVM_LIBS="-lLLVM-`$LLVM_CONFIG --version`"
else
- LLVM_LIBS="`$LLVM_CONFIG --libs engine bitwriter`"
+ LLVM_LIBS="`$LLVM_CONFIG --libs engine bitwriter mcjit`"
if test "x$enable_opencl" = xyes; then
-LLVM_LIBS="${LLVM_LIBS} `llvm-config --libs ipo linker
instrumentation mcjit`"
+LLVM_LIBS="${LLVM_LIBS} `$LLVM_CONFIG --libs ipo linker
instrumentation mcjit`"
fi
fi
LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
@@ -2007,7 +2007,7 @@ if test "x$with_gallium_drivers" != x; then
USE_R600_LLVM_COMPILER=yes;
fi
if test "x$enable_opencl" = xyes -a "x$with_llvm_shared_libs" =
xno; then
-LLVM_LIBS="${LLVM_LIBS} `llvm-config --libs bitreader
asmparser`"
+LLVM_LIBS="${LLVM_LIBS} `$LLVM_CONFIG --libs bitreader
asmparser`"
fi
gallium_check_st "radeon/drm" "dri-r600" "xorg-r600" ""
"xvmc-r600" "vdpau-r600" "va-r600"
;;
--
1.7.10
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Further LLVM fixups.
On Tue, Jul 17, 2012 at 07:00:48PM +0200, Michel Dänzer wrote:
> From: Michel Dänzer
>
> * Also add mcjit in the non-OpenCL case.
> * Replace hardcoded llvm-config with $LLVM_CONFIG everywhere.
>
> Signed-off-by: Michel Dänzer
I just pushed a fix for mcjit, but the rest is:
Reviewed-by: Tom Stellad
> ---
> configure.ac |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 068f632..1ab75e6 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1847,9 +1847,9 @@ if test "x$enable_gallium_llvm" = xyes; then
> dnl We can't use $LLVM_VERSION because it has 'svn' stripped out,
> LLVM_LIBS="-lLLVM-`$LLVM_CONFIG --version`"
> else
> - LLVM_LIBS="`$LLVM_CONFIG --libs engine bitwriter`"
> + LLVM_LIBS="`$LLVM_CONFIG --libs engine bitwriter mcjit`"
> if test "x$enable_opencl" = xyes; then
> -LLVM_LIBS="${LLVM_LIBS} `llvm-config --libs ipo linker
> instrumentation mcjit`"
> +LLVM_LIBS="${LLVM_LIBS} `$LLVM_CONFIG --libs ipo linker
> instrumentation mcjit`"
> fi
> fi
> LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
> @@ -2007,7 +2007,7 @@ if test "x$with_gallium_drivers" != x; then
> USE_R600_LLVM_COMPILER=yes;
> fi
> if test "x$enable_opencl" = xyes -a "x$with_llvm_shared_libs" =
> xno; then
> -LLVM_LIBS="${LLVM_LIBS} `llvm-config --libs bitreader
> asmparser`"
> +LLVM_LIBS="${LLVM_LIBS} `$LLVM_CONFIG --libs bitreader
> asmparser`"
> fi
> gallium_check_st "radeon/drm" "dri-r600" "xorg-r600" ""
> "xvmc-r600" "vdpau-r600" "va-r600"
> ;;
> --
> 1.7.10
>
> ___
> 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: Drop obsolete .gitignore entries.
On Tue, Jul 17, 2012 at 10:00 AM, Michel Dänzer wrote: > From: Michel Dänzer > > Helps spotting and removing the obsolete generated files, which otherwise > break > the build. > > Signed-off-by: Michel Dänzer > --- Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Further LLVM fixups.
- Original Message - > On Tue, Jul 17, 2012 at 07:00:48PM +0200, Michel Dänzer wrote: > > From: Michel Dänzer > > > > * Also add mcjit in the non-OpenCL case. > > * Replace hardcoded llvm-config with $LLVM_CONFIG everywhere. > > > > Signed-off-by: Michel Dänzer > > I just pushed a fix for mcjit, but the rest is: > > Reviewed-by: Tom Stellad Thanks. And sorry for forgetting to test with autoconf.. :-/ Reviewed-by: Jose Fonseca Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Further LLVM fixups.
On Die, 2012-07-17 at 13:06 -0400, Tom Stellard wrote: > On Tue, Jul 17, 2012 at 07:00:48PM +0200, Michel Dänzer wrote: > > From: Michel Dänzer > > > > * Also add mcjit in the non-OpenCL case. > > * Replace hardcoded llvm-config with $LLVM_CONFIG everywhere. > > > > Signed-off-by: Michel Dänzer > > I just pushed a fix for mcjit, but the rest is: Your fix only applied when OpenCL was enabled. But as you pointed out on IRC, my fix would add the mcjit flags twice in the OpenCL case. > Reviewed-by: Tom Stellad Thanks, pushed with the above fixed. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52209] lp_test_format regression
https://bugs.freedesktop.org/show_bug.cgi?id=52209 --- Comment #1 from José Fonseca 2012-07-17 17:53:21 PDT --- Could you describe the failure and environment a bit more? I'm not seeing it here. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] r600g: hyperz
So this patch serie add hyperz but does not enable it by default. I think i addressed all comment in v9 for htile. I am also asking to include the flushing rework as without it hyperz lockup with thing such as gears. So with both patch most application should be fine with hyperz, but application that switch depth are the most likely to trigger lockup. >From regression pov the 2 patch doesn't seems to regress anything according to piglit (r6xx,r7xx,evergreen). However, enabling hyperz lead to some rendering issue with evergreen and lightmark, but as i can't run piglit regression without lockup i haven't tracked down exactly what (my guess is that it's related to hyper-stencil). Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] r600g: add htile support v9
From: Jerome Glisse
htile is used for HiZ and HiS support and fast Z/S clears.
This commit just adds the htile setup and Fast Z clear.
We don't take full advantage of HiS with that patch.
v2 really use fast clear, still random issue with some tiles
need to try more flush combination, fix depth/stencil
texture decompression
v3 fix random issue on r6xx/r7xx
v4 rebase on top of lastest mesa, disable CB export when clearing
htile surface to avoid wasting bandwidth
v5 resummarize htile surface when uploading z value. Fix z/stencil
decompression, the custom blitter with custom dsa is no longer
needed.
v6 Reorganize render control/override update mecanism, fixing more
issues in the process.
v7 Add nop after depth surface base update to work around some htile
flushing issue. For htile to 8x8 on r6xx/r7xx as other combination
have issue. Do not enable hyperz when flushing/uncompressing
depth buffer.
v8 Fix htile surface, preload and prefetch setup. Only set preload
and prefetch on htile surface clear like fglrx. Record depth
clear value per level. Support several level for the htile
surface. First depth clear can't be a fast clear.
v9 Fix comments, properly account new register in emit function,
disable fast zclear if clearing different layer of texture
array to different value
Signed-off-by: Pierre-Eric Pelloux-Prayer
Signed-off-by: Alex Deucher
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r600/evergreen_hw_context.c |6 +
src/gallium/drivers/r600/evergreen_state.c | 102 -
src/gallium/drivers/r600/evergreend.h |4 +
src/gallium/drivers/r600/r600_blit.c| 38 +++
src/gallium/drivers/r600/r600_hw_context.c | 25 +
src/gallium/drivers/r600/r600_pipe.c|8 ++
src/gallium/drivers/r600/r600_pipe.h| 13 ++-
src/gallium/drivers/r600/r600_resource.h|7 ++
src/gallium/drivers/r600/r600_state.c | 133 ---
src/gallium/drivers/r600/r600_texture.c | 103 ++
src/gallium/drivers/r600/r600d.h|6 +
11 files changed, 399 insertions(+), 46 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c
b/src/gallium/drivers/r600/evergreen_hw_context.c
index 081701f..546c884 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -62,6 +62,9 @@ static const struct r600_reg evergreen_context_reg_list[] = {
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_028058_DB_DEPTH_SIZE, 0, 0},
{R_02805C_DB_DEPTH_SLICE, 0, 0},
+ {R_02802C_DB_DEPTH_CLEAR, 0, 0},
+ {R_028ABC_DB_HTILE_SURFACE, 0, 0},
+ {R_028AC8_DB_PRELOAD_CONTROL, 0, 0},
{R_028204_PA_SC_WINDOW_SCISSOR_TL, 0, 0},
{R_028208_PA_SC_WINDOW_SCISSOR_BR, 0, 0},
{R_028234_PA_SU_HARDWARE_SCREEN_OFFSET, 0, 0},
@@ -319,6 +322,9 @@ static const struct r600_reg cayman_context_reg_list[] = {
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_028058_DB_DEPTH_SIZE, 0, 0},
{R_02805C_DB_DEPTH_SLICE, 0, 0},
+ {R_02802C_DB_DEPTH_CLEAR, 0, 0},
+ {R_028ABC_DB_HTILE_SURFACE, 0, 0},
+ {R_028AC8_DB_PRELOAD_CONTROL, 0, 0},
{R_028204_PA_SC_WINDOW_SCISSOR_TL, 0, 0},
{R_028208_PA_SC_WINDOW_SCISSOR_BR, 0, 0},
{R_028234_PA_SU_HARDWARE_SCREEN_OFFSET, 0, 0},
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index a66387b..214d76b 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -710,13 +710,15 @@ static void *evergreen_create_blend_state(struct
pipe_context *ctx,
}
blend->cb_target_mask = target_mask;
- if (target_mask)
+ if (target_mask) {
color_control |= S_028808_MODE(V_028808_CB_NORMAL);
- else
+ } else {
color_control |= S_028808_MODE(V_028808_CB_DISABLE);
+ }
r600_pipe_state_add_reg(rstate, R_028808_CB_COLOR_CONTROL,
color_control);
+
/* only have dual source on MRT0 */
blend->dual_src_blend = util_blend_state_is_dual(state, 0);
for (int i = 0; i < 8; i++) {
@@ -1668,6 +1670,26 @@ static void evergreen_db(struct r600_context *rctx,
struct r600_pipe_state *rsta
}
}
+ /* hyperz */
+ if (rtex->hyperz) {
+ uint64_t htile_offset =
rtex->hyperz->surface.level[level].offset;
+
+ rctx->db_misc_state.hyperz = true;
+ rctx->db_misc_state.db_htile_surface_mask = 0x;
+ r600_atom_dirty(rctx, &rctx->db_misc_state.atom);
+ z_info |= S_028040_TILE_SURFACE_ENABLE(1);
+ r600_pipe_state_add_reg_bo(rstate, R_028014_DB_HTILE_DATA_BASE,
+ htile_offset >> 8,
&rtex->hyperz->resource,
+
[Mesa-dev] [PATCH 2/2] r600g: simplify and fix flushing and synchronization v2
From: Jerome Glisse
Flushing and synchronization only need to happen at begining
and end of cs, and after each draw packet if necessary. This
patch is especialy needed for hyperz/htile feature.
v2: Separate evergreen and r6xx/r7xx flushing/syncing allow
easier specialization of each functions. Fix r6xx/r7xx
regression.
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r600/evergreen_compute.c | 23 +--
.../drivers/r600/evergreen_compute_internal.c |4 +-
src/gallium/drivers/r600/evergreen_hw_context.c| 110 ++-
src/gallium/drivers/r600/evergreen_state.c | 14 +-
src/gallium/drivers/r600/evergreend.h |3 +-
src/gallium/drivers/r600/r600.h| 19 +-
src/gallium/drivers/r600/r600_buffer.c |2 +-
src/gallium/drivers/r600/r600_hw_context.c | 203
src/gallium/drivers/r600/r600_hw_context_priv.h|3 +-
src/gallium/drivers/r600/r600_pipe.c |2 -
src/gallium/drivers/r600/r600_pipe.h |6 +-
src/gallium/drivers/r600/r600_state.c | 23 +--
src/gallium/drivers/r600/r600_state_common.c | 68 ++-
13 files changed, 297 insertions(+), 183 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index 947a328..37c3395 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -96,7 +96,7 @@ static void evergreen_cs_set_vertex_buffer(
vb->buffer = buffer;
vb->user_buffer = NULL;
- r600_inval_vertex_cache(rctx);
+ rctx->flags |= R600_CONTEXT_VTX_FLUSH;
state->dirty_mask |= 1 << vb_index;
r600_atom_dirty(rctx, &state->atom);
}
@@ -208,8 +208,7 @@ static void evergreen_bind_compute_state(struct
pipe_context *ctx_, void *state)
res->usage = RADEON_USAGE_READ;
res->coher_bo_size = ctx->cs_shader->bc.ndw*4;
- r600_inval_shader_cache(ctx);
-
+ ctx->flags |= R600_CONTEXT_SH_FLUSH;
}
/* The kernel parameters are stored a vtx buffer (ID=0), besides the explicit
@@ -364,8 +363,11 @@ static void compute_emit_cs(struct r600_context *ctx)
*/
r600_emit_atom(ctx, &ctx->start_compute_cs_cmd.atom);
+ ctx->flags |= R600_CONTEXT_CB_FLUSH;
+ r600_flush_emit(ctx);
+
/* Emit cb_state */
-cb_state = ctx->states[R600_PIPE_STATE_FRAMEBUFFER];
+ cb_state = ctx->states[R600_PIPE_STATE_FRAMEBUFFER];
r600_context_pipe_state_emit(ctx, cb_state,
RADEON_CP_PACKET3_COMPUTE_MODE);
/* Emit vertex buffer state */
@@ -405,15 +407,8 @@ static void compute_emit_cs(struct r600_context *ctx)
}
}
- /* r600_flush_framebuffer() updates the cb_flush_flags and then
-* calls r600_emit_atom() on the ctx->surface_sync_cmd.atom, which emits
-* a SURFACE_SYNC packet via r600_emit_surface_sync().
-*
-* XXX r600_emit_surface_sync() hardcodes the CP_COHER_SIZE to
-* 0x, so we will need to add a field to struct
-* r600_surface_sync_cmd if we want to manually set this value.
-*/
- r600_flush_framebuffer(ctx, true /* Flush now */);
+ ctx->flags |= R600_CONTEXT_CB_FLUSH;
+ r600_flush_emit(ctx);
#if 0
COMPUTE_DBG("cdw: %i\n", cs->cdw);
@@ -460,6 +455,8 @@ static void evergreen_launch_grid(
evergreen_set_lds(ctx->cs_shader, 0, 0, num_waves);
evergreen_compute_upload_input(ctx_, block_layout, grid_layout, input);
evergreen_direct_dispatch(ctx_, block_layout, grid_layout);
+ /* set draw pending so flush function know we mean business */
+ ctx->flags |= R600_CONTEXT_DRAW_PENDING;
compute_emit_cs(ctx);
}
diff --git a/src/gallium/drivers/r600/evergreen_compute_internal.c
b/src/gallium/drivers/r600/evergreen_compute_internal.c
index 1d11bab..8bb6426 100644
--- a/src/gallium/drivers/r600/evergreen_compute_internal.c
+++ b/src/gallium/drivers/r600/evergreen_compute_internal.c
@@ -559,7 +559,7 @@ void evergreen_set_tex_resource(
res->coher_bo_size = tmp->offset[0] +
util_format_get_blockwidth(tmp->real_format)*view->base.texture->width0*height*depth;
- r600_inval_texture_cache(pipe->ctx);
+ pipe->ctx->flags |= R600_CONTEXT_TEX_FLUSH;
evergreen_emit_force_reloc(res);
evergreen_emit_force_reloc(res);
@@ -618,7 +618,7 @@ void evergreen_set_const_cache(
res->usage = RADEON_USAGE_READ;
res->coher_bo_size = size;
- r600_inval_shader_cache(pipe->ctx);
+ pipe->ctx->flags |= R600_CONTEXT_SH_FLUSH;
}
struct r600_resource* r600_compute_buffer_alloc_vram(
diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c
b/src/gallium/drivers/r600/evergreen_hw_context.c
index 546c884..cf4a225 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_h
[Mesa-dev] [Bug 52140] Ubuntu Unity - Launcher and switcher icons disappeared
https://bugs.freedesktop.org/show_bug.cgi?id=52140 --- Comment #6 from Kenneth Graunke 2012-07-17 18:05:45 PDT --- I'm pretty sure I saw this on Ubuntu 12.04 on Intel Ivybridge when installing xorg-edgers (which comes with Mesa master). Smells like a core Mesa regression. (This was on someone else's machine, though, so unfortunately I won't be able to reproduce or debug this further...) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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: Drop obsolete .gitignore entries.
On 07/17/2012 10:00 AM, Michel Dänzer wrote: > From: Michel Dänzer > > Helps spotting and removing the obsolete generated files, which otherwise > break > the build. > > Signed-off-by: Michel Dänzer > --- > src/glsl/.gitignore |2 -- > 1 file changed, 2 deletions(-) > > diff --git a/src/glsl/.gitignore b/src/glsl/.gitignore > index c9a9f30..81240b9 100644 > --- a/src/glsl/.gitignore > +++ b/src/glsl/.gitignore > @@ -1,8 +1,6 @@ > glsl_compiler > glsl_lexer.cc > -glsl_lexer.cpp > glsl_parser.cc > -glsl_parser.cpp > glsl_parser.h > glsl_parser.output > builtin_function.cpp Reviewed-by: Kenneth Graunke Feel free to just push these. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52209] lp_test_format regression
https://bugs.freedesktop.org/show_bug.cgi?id=52209 --- Comment #2 from Vinson Lee 2012-07-17 18:07:14 PDT --- mesa: 761131ce4591e5f55f38d13f2c4d2194bc9cb0fd (master) llvm: 2.9+dfsg-3ubuntu4 Linux distribution: Ubuntu 12.04 amd64 $ ./build/linux-x86_64-debug/bin/lp_test_format Testing PIPE_FORMAT_B8G8R8A8_UNORM (float) ... Testing PIPE_FORMAT_B8G8R8A8_UNORM (unorm8) ... Testing PIPE_FORMAT_B8G8R8X8_UNORM (float) ... Testing PIPE_FORMAT_B8G8R8X8_UNORM (unorm8) ... Testing PIPE_FORMAT_A8R8G8B8_UNORM (float) ... Testing PIPE_FORMAT_A8R8G8B8_UNORM (unorm8) ... Testing PIPE_FORMAT_X8R8G8B8_UNORM (float) ... Testing PIPE_FORMAT_X8R8G8B8_UNORM (unorm8) ... Testing PIPE_FORMAT_B5G5R5A1_UNORM (float) ... Testing PIPE_FORMAT_B5G5R5A1_UNORM (unorm8) ... Testing PIPE_FORMAT_B4G4R4A4_UNORM (float) ... Testing PIPE_FORMAT_B4G4R4A4_UNORM (unorm8) ... Testing PIPE_FORMAT_B5G6R5_UNORM (float) ... Testing PIPE_FORMAT_B5G6R5_UNORM (unorm8) ... Testing PIPE_FORMAT_R10G10B10A2_UNORM (float) ... Testing PIPE_FORMAT_R10G10B10A2_UNORM (unorm8) ... Testing PIPE_FORMAT_L8_UNORM (float) ... Testing PIPE_FORMAT_L8_UNORM (unorm8) ... Testing PIPE_FORMAT_A8_UNORM (float) ... Testing PIPE_FORMAT_A8_UNORM (unorm8) ... Testing PIPE_FORMAT_I8_UNORM (float) ... Testing PIPE_FORMAT_I8_UNORM (unorm8) ... Testing PIPE_FORMAT_L8A8_UNORM (float) ... Testing PIPE_FORMAT_L8A8_UNORM (unorm8) ... Testing PIPE_FORMAT_L16_UNORM (float) ... Testing PIPE_FORMAT_L16_UNORM (unorm8) ... Testing PIPE_FORMAT_UYVY (float) ... Testing PIPE_FORMAT_UYVY (unorm8) ... Testing PIPE_FORMAT_YUYV (float) ... Testing PIPE_FORMAT_YUYV (unorm8) ... Testing PIPE_FORMAT_R32_FLOAT (float) ... Testing PIPE_FORMAT_R32_FLOAT (unorm8) ... Testing PIPE_FORMAT_R32G32_FLOAT (float) ... Testing PIPE_FORMAT_R32G32_FLOAT (unorm8) ... Testing PIPE_FORMAT_R32G32B32_FLOAT (float) ... Testing PIPE_FORMAT_R32G32B32_FLOAT (unorm8) ... Testing PIPE_FORMAT_R32G32B32A32_FLOAT (float) ... Testing PIPE_FORMAT_R32G32B32A32_FLOAT (unorm8) ... Testing PIPE_FORMAT_R32_UNORM (float) ... Testing PIPE_FORMAT_R32_UNORM (unorm8) ... Testing PIPE_FORMAT_R32G32_UNORM (float) ... Testing PIPE_FORMAT_R32G32_UNORM (unorm8) ... Testing PIPE_FORMAT_R32G32B32_UNORM (float) ... Testing PIPE_FORMAT_R32G32B32_UNORM (unorm8) ... Testing PIPE_FORMAT_R32G32B32A32_UNORM (float) ... Testing PIPE_FORMAT_R32G32B32A32_UNORM (unorm8) ... Testing PIPE_FORMAT_R32_USCALED (float) ... Testing PIPE_FORMAT_R32_USCALED (unorm8) ... Testing PIPE_FORMAT_R32G32_USCALED (float) ... Testing PIPE_FORMAT_R32G32_USCALED (unorm8) ... FAILED Packed: 00 00 00 01 Unpacked (0,0): 00 00 00 ff obtained ff 00 00 ff expected FAILED Packed: 00 00 00 00 Unpacked (0,0): 00 00 00 ff obtained 00 ff 00 ff expected FAILED Packed: 00 00 00 01 Unpacked (0,0): 00 00 00 ff obtained ff ff 00 ff expected Testing PIPE_FORMAT_R32G32B32_USCALED (float) ... Testing PIPE_FORMAT_R32G32B32_USCALED (unorm8) ... FAILED Packed: 00 00 00 01 Unpacked (0,0): 00 00 00 ff obtained ff 00 00 ff expected FAILED Packed: 00 00 00 00 Unpacked (0,0): 00 00 00 ff obtained 00 ff 00 ff expected FAILED Packed: 00 00 00 00 Unpacked (0,0): 00 00 00 ff obtained 00 00 ff ff expected FAILED Packed: 00 00 00 01 Unpacked (0,0): 00 00 00 ff obtained ff ff ff ff expected Testing PIPE_FORMAT_R32G32B32A32_USCALED (float) ... Testing PIPE_FORMAT_R32G32B32A32_USCALED (unorm8) ... FAILED Packed: 00 00 00 01 Unpacked (0,0): 00 00 00 00 obtained ff 00 00 00 expected FAILED Packed: 00 00 00 00 Unpacked (0,0): 00 00 00 00 obtained 00 ff 00 00 expected FAILED Packed: 00 00 00 00 Unpacked (0,0): 00 00 00 00 obtained 00 00 ff 00 expected FAILED Packed: 00 00 00 00 Unpacked (0,0): 00 00 00 00 obtained 00 00 00 ff expected FAILED Packed: 00 00 00 01 Unpacked (0,0): 00 00 00 00 obtained ff ff ff ff expected Testing PIPE_FORMAT_R32_SNORM (float) ... Testing PIPE_FORMAT_R32_SNORM (unorm8) ... Testing PIPE_FORMAT_R32G32_SNORM (float) ... Testing PIPE_FORMAT_R32G32_SNORM (unorm8) ... Testing PIPE_FORMAT_R32G32B32_SNORM (float) ... Testing PIPE_FORMAT_R32G32B32_SNORM (unorm8) ... Testing PIPE_FORMAT_R32G32B32A32_SNORM (float) ... Testing PIPE_FORMAT_R32G32B32A32_SNORM (unorm8) ... Testing PIPE_FORMAT_R32_SSCALED (float) ... Testing PIPE_FORMAT_R32_SSCALED (unorm8) ... FAILED Packed: 00 00 00 01 Unpacked (0,0): 00 00 00 ff obtained ff 00 00 ff expected Testing PIPE_FORMAT_R32G32_SSCALED (float) ... Testing PIPE_FORMAT_R32G32_SSCALED (unorm8) ... FAILED Packed: 00 00 00 01 Unpacked (0,0): 00 00 00 ff obtained ff 00 00 ff expected FAILED Packed: 00 00 00 00 Unpacked (0,0): 00 00 00 ff obtained 00 ff 00 ff expected Testing PIPE_FORMAT_R32G32B32_SSCALED (float) ... Testing PIPE_FORMAT_R32G3
[Mesa-dev] [Bug 52209] lp_test_format regression
https://bugs.freedesktop.org/show_bug.cgi?id=52209 --- Comment #3 from José Fonseca 2012-07-17 19:01:47 PDT --- Thanks. And what's your CPU, and LLVM version? Does setting LP_NATIVE_VECTOR_WIDTH=128 help? If not, please run the test as GALLIVM_DEBUG=tgsi,ir,asm /path/to/lp_test_format -v -v and attatch the output. Before and after the faulty commit above. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 v2] android: fix the build
On Mon, Jul 9, 2012 at 11:50 AM, Chad Versace wrote: > > Tapani, > > Is this patch still applicable? It seems that the autoconf work has calmed > down, > and now is a good time to fix the Android build. > > -Chad Tapani is out. But this patch has never quite worked for me. The build still breaks on Android over failure to generate enums.c Sean > > On 06/07/2012 04:11 AM, Tapani Pälli wrote: > > Some more of the files are now autogenerated, this caused build > > breakage, > > patch adds generation of these missing files. Patch also changes > > existing > > make so that the files are created to be part of the local source > > (not intermediate directory, this causes several problems). > > > > Signed-off-by: Tapani Pälli > > --- > > src/mesa/Android.gen.mk | 45 > > - > > 1 file changed, 16 insertions(+), 29 deletions(-) > > > > diff --git a/src/mesa/Android.gen.mk b/src/mesa/Android.gen.mk > > index 2a08184..2ea8cc4 100644 > > --- a/src/mesa/Android.gen.mk > > +++ b/src/mesa/Android.gen.mk > > @@ -28,16 +28,13 @@ LOCAL_MODULE_CLASS := STATIC_LIBRARIES > > endif > > > > intermediates := $(call local-intermediates-dir) > > +mydir := $(call my-dir) > > > > sources := \ > > - main/api_exec_es1.c \ > > main/api_exec_es1_dispatch.h \ > > main/api_exec_es1_remap_helper.h \ > > - main/api_exec_es2.c \ > > main/api_exec_es2_dispatch.h \ > > - main/api_exec_es2_remap_helper.h \ > > - program/lex.yy.c \ > > - program/program_parse.tab.c > > + main/api_exec_es2_remap_helper.h > > > > LOCAL_SRC_FILES := $(filter-out $(sources), $(LOCAL_SRC_FILES)) > > > > @@ -53,6 +50,7 @@ endif > > sources += main/git_sha1.h > > > > sources := $(addprefix $(intermediates)/, $(sources)) > > + > > LOCAL_GENERATED_SOURCES += $(sources) > > > > glapi := $(MESA_TOP)/src/mapi/glapi/gen > > @@ -73,43 +71,31 @@ define es-gen > > $(hide) $(PRIVATE_SCRIPT) $(1) $(PRIVATE_XML) > $@ > > endef > > > > -define local-l-to-c > > - @mkdir -p $(dir $@) > > - @echo "Mesa Lex: $(PRIVATE_MODULE) <= $<" > > - $(hide) $(LEX) -o$@ $< > > -endef > > - > > -define local-y-to-c-and-h > > - @mkdir -p $(dir $@) > > - @echo "Mesa Yacc: $(PRIVATE_MODULE) <= $<" > > - $(hide) $(YACC) -o $@ $< > > +define generate-local > > + @echo "generate local sources" > > + $(hide) $(MESA_PYTHON2) $(glapi)/gl_enums.py -f > > $(glapi)/gl_and_es_API.xml > $(mydir)/main/enums.c > > + $(hide) $(MESA_PYTHON2) $(glapi)/gl_table.py -m remap_table -f > > $(glapi)/gl_and_es_API.xml > $(mydir)/main/dispatch.h > > + $(hide) $(MESA_PYTHON2) $(glapi)/remap_helper.py -f > > $(glapi)/gl_API.xml > $(mydir)/main/remap_helper.h > > + $(hide) $(MESA_PYTHON2) $(mydir)/main/es_generator.py -V GLES1.1 > > -S $(mydir)/main/APIspec.xml > $(mydir)/main/api_exec_es1.c > > + $(hide) $(MESA_PYTHON2) $(mydir)/main/es_generator.py -V GLES2.0 > > -S $(mydir)/main/APIspec.xml > $(mydir)/main/api_exec_es2.c > > + > > + @echo "Mesa Lex : $(PRIVATE_MODULE)" > > + $(hide) $(LEX) -o $(mydir)/program/lex.yy.c > > $(mydir)/program/program_lexer.l > > + @echo "Mesa Yacc: $(PRIVATE_MODULE)" > > + $(hide) $(YACC) -d -o $(mydir)/program/program_parse.tab.c > > $(mydir)/program/program_parse.y > > endef > > > > -$(intermediates)/main/api_exec_%.c: PRIVATE_SCRIPT := $(MESA_PYTHON2) > > $(LOCAL_PATH)/main/es_generator.py > > -$(intermediates)/main/api_exec_%.c: PRIVATE_XML := -S > > $(LOCAL_PATH)/main/APIspec.xml > > $(intermediates)/main/api_exec_%_dispatch.h: PRIVATE_SCRIPT := > > $(MESA_PYTHON2) $(glapi)/gl_table.py > > $(intermediates)/main/api_exec_%_dispatch.h: PRIVATE_XML := -f > > $(glapi)/gl_and_es_API.xml > > $(intermediates)/main/api_exec_%_remap_helper.h: PRIVATE_SCRIPT := > > $(MESA_PYTHON2) $(glapi)/remap_helper.py > > $(intermediates)/main/api_exec_%_remap_helper.h: PRIVATE_XML := -f > > $(glapi)/gl_and_es_API.xml > > > > -$(intermediates)/main/api_exec_es1.c: $(es_src_deps) > > - $(call es-gen,-V GLES1.1) > > - > > -$(intermediates)/main/api_exec_es2.c: $(es_src_deps) > > - $(call es-gen,-V GLES2.0) > > - > > $(intermediates)/main/api_exec_%_dispatch.h: $(es_hdr_deps) > > $(call es-gen, -c $* -m remap_table) > > > > $(intermediates)/main/api_exec_%_remap_helper.h: $(es_hdr_deps) > > $(call es-gen, -c $*) > > > > -$(intermediates)/program/program_parse.tab.c: > > $(LOCAL_PATH)/program/program_parse.y > > - $(local-y-to-c-and-h) > > - > > -$(intermediates)/program/lex.yy.c: > > $(LOCAL_PATH)/program/program_lexer.l > > - $(local-l-to-c) > > - > > $(intermediates)/main/git_sha1.h: > > @mkdir -p $(dir $@) > > @echo "GIT-SHA1: $(PRIVATE_MODULE) <= git" > > @@ -129,3 +115,4 @@ $(intermediates)/x86/matypes.h: $(matypes_deps) > > @mkdir -p $(dir $@) > > @echo "MATYPES: $(PRIVATE_MODULE) <= $(notdir $@)" > > $(hide) $< > $@ > > + $(call generate-local) > > > > __
[Mesa-dev] [PATCH] configure.ac: Add --with-llvm-prefix option
This option allows you to specify the llvm install prefix. It is useful for switching between different versions of LLVM. --- configure.ac | 13 - 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 1d60957..10216a3 100644 --- a/configure.ac +++ b/configure.ac @@ -1829,6 +1829,13 @@ AC_ARG_WITH([llvm-shared-libs], [with_llvm_shared_libs=yes], [with_llvm_shared_libs=no]) +AC_ARG_WITH([llvm-prefix], +[AS_HELP_STRING([--with-llvm-prefix], +[Prefix for LLVM installations in non-standard locations])], +[llvm_prefix="$withval"], +[llvm_prefix=""]) + + if test "x$with_gallium_drivers" = x; then enable_gallium_llvm=no fi @@ -1838,7 +1845,11 @@ if test "x$enable_gallium_llvm" = xauto; then esac fi if test "x$enable_gallium_llvm" = xyes; then -AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no]) +if test "x$llvm_prefix" != x; then +AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no], ["$llvm_prefix/bin"]) +else +AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no]) +fi if test "x$LLVM_CONFIG" != xno; then LLVM_VERSION=`$LLVM_CONFIG --version | sed 's/svn.*//g'` -- 1.7.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] pipe_loader: Try to make a connection with the X server before probing pciids
When X is running it is neccesary for pipe_loader to authenticate with
DRM, in order to be able to use the device.
This makes it possible to run OpenCL programs while X is running.
---
configure.ac |6 ++
.../auxiliary/pipe-loader/pipe_loader_drm.c| 57
2 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 10216a3..35cc579 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2084,6 +2084,12 @@ if test "x$enable_gallium_loader" = xyes; then
if test "x$enable_gallium_drm_loader" = xyes; then
GALLIUM_PIPE_LOADER_DEFINES="$GALLIUM_PIPE_LOADER_DEFINES
-DHAVE_PIPE_LOADER_DRM"
+PKG_CHECK_MODULES([GALLIUM_PIPE_LOADER_XCB], [x11-xcb xcb-dri2],
+ pipe_loader_have_xcb=yes, pipe_loader_have_xcb=no)
+if test "x$pipe_loader_have_xcb" = xyes; then
+GALLIUM_PIPE_LOADER_DEFINES="$GALLIUM_PIPE_LOADER_DEFINES
-DPIPE_LOADER_HAVE_XCB"
+GALLIUM_PIPE_LOADER_LIBS="$GALLIUM_PIPE_LOADER_LIBS
$GALLIUM_PIPE_LOADER_XCB_LIBS $LIBDRM_LIBS"
+fi
fi
AC_SUBST([GALLIUM_PIPE_LOADER_DEFINES])
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
index 518f3da..6af455c 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
@@ -35,6 +35,13 @@
#include
#include
+#ifdef PIPE_LOADER_HAVE_XCB
+
+#include
+#include
+
+#endif
+
#include "state_tracker/drm_driver.h"
#include "pipe_loader_priv.h"
@@ -132,6 +139,56 @@ pipe_loader_drm_probe_fd(struct pipe_loader_device **dev,
int fd)
{
struct pipe_loader_drm_device *ddev = CALLOC_STRUCT(pipe_loader_drm_device);
+#if PIPE_LOADER_HAVE_XCB
+ // Try authenticate with the X server to give us access to devices that X
+ // is running on.
+ Display *disp;
+ xcb_connection_t *xcb_conn;
+ xcb_screen_iterator_t s;
+ xcb_dri2_connect_cookie_t connect_cookie;
+ xcb_dri2_connect_reply_t *connect;
+ drm_magic_t magic;
+ xcb_dri2_authenticate_cookie_t authenticate_cookie;
+ xcb_dri2_authenticate_reply_t *authenticate;
+
+ disp = XOpenDisplay(NULL);
+
+ if (!disp)
+ goto done;
+
+ xcb_conn = XGetXCBConnection(disp);
+
+ if(!xcb_conn)
+ goto done;
+
+ s = xcb_setup_roots_iterator(xcb_get_setup(xcb_conn));
+ connect_cookie = xcb_dri2_connect_unchecked(xcb_conn, s.data->root,
+ XCB_DRI2_DRIVER_TYPE_DRI);
+ connect = xcb_dri2_connect_reply(xcb_conn, connect_cookie, NULL);
+
+ if (!connect || connect->driver_name_length
+ + connect->device_name_length == 0) {
+
+ goto free_connect;
+ }
+
+ if (drmGetMagic(fd, &magic))
+ goto free_connect;
+
+ authenticate_cookie = xcb_dri2_authenticate_unchecked(xcb_conn,
+ s.data->root,
+ magic);
+ authenticate = xcb_dri2_authenticate_reply(xcb_conn,
+ authenticate_cookie,
+ NULL);
+
+ FREE(authenticate);
+free_connect:
+ FREE(connect);
+done:
+
+#endif
+
ddev->base.type = PIPE_LOADER_DEVICE_PCI;
ddev->base.ops = &pipe_loader_drm_ops;
ddev->fd = fd;
--
1.7.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] __DRIimage: Add formats with implied swizzling
When we sample U and V from YUYV buffers, U and V ends up in G and A
in the shader. Instead of pushing this to the application, just swizzle
U and V to R and G and set B to 0 and A to 1.
---
docs/WL_bind_wayland_display.spec| 24 +++-
include/EGL/eglmesaext.h |1 -
include/GL/internal/dri_interface.h |7 +++
src/egl/drivers/dri2/egl_dri2.c |6 +++---
src/mesa/drivers/dri/intel/intel_screen.c|2 ++
src/mesa/drivers/dri/intel/intel_tex_image.c | 22 ++
6 files changed, 45 insertions(+), 17 deletions(-)
diff --git a/docs/WL_bind_wayland_display.spec
b/docs/WL_bind_wayland_display.spec
index e1aca53..9b84e91 100644
--- a/docs/WL_bind_wayland_display.spec
+++ b/docs/WL_bind_wayland_display.spec
@@ -122,15 +122,13 @@ Additions to the EGL 1.4 Specification:
each EGLImage and how they map to rgba components in the shader.
The naming conventions separates planes by _ and within each
plane, the order or R, G, B, A, Y, U, and V indicates how those
-components map to the rgba value returned by the sampler. X
-indicates that the corresponding component in the rgba value isn't
-used.
+components map to the rgba value returned by the sampler.
RGB and RGBA buffer types:
EGL_WAYLAND_BUFFER_RGB_WL
One plane, samples RGB from the texture to rgb in the
-shader. Alpha channel is not valid.
+shader. Alpha channel is one.
EGL_WAYLAND_BUFFER_RGBA_WL 0x31D9
One plane, samples RGBA from the texture to rgba in the
@@ -139,17 +137,14 @@ Additions to the EGL 1.4 Specification:
YUV buffer types:
EGL_WAYLAND_BUFFER_Y_U_V_WL 0x31Da
-Three planes, samples Y from the first plane to r in
-the shader, U from the second plane to r, and V from
-the third plane to r.
+Three planes, samples Y from the first plane to r in the
+shader, U from the second plane to r, and V from the third
+plane to r. Components g and b are zero, a is one.
EGL_WAYLAND_BUFFER_Y_UV_WL 0x31Db
-Two planes, samples Y from the first plane to r in
-the shader, U and V from the second plane to rg.
-
-EGL_WAYLAND_BUFFER_Y_XUXV_WL0x31Dc
-Two planes, samples Y from the first plane to r in
-the shader, U and V from the second plane to g and a.
+Two planes, samples Y from the first plane to r in the shader,
+U and V from the second plane to rg. Component b is zero, a
+is one.
After querying the wl_buffer layout, create EGLImages for the
planes by calling eglCreateImageKHR with wl_buffer as
@@ -174,3 +169,6 @@ Revision History
Version 3, July 10, 2012
Add eglQueryWaylandBufferWL and the various buffer
formats. (Kristian Høgsberg)
+Version 4, July 10, 2012
+Drop Y_XUXV format and just make the driver swizzle incoming values
+so they map to rgba in that order. (Kristian Høgsberg)
diff --git a/include/EGL/eglmesaext.h b/include/EGL/eglmesaext.h
index 74d8ced..85b44e4 100644
--- a/include/EGL/eglmesaext.h
+++ b/include/EGL/eglmesaext.h
@@ -121,7 +121,6 @@ typedef EGLDisplay (EGLAPIENTRYP PFNEGLGETDRMDISPLAYMESA)
(int fd);
#define EGL_WAYLAND_BUFFER_RGBA_WL 0x31D9
#define EGL_WAYLAND_BUFFER_Y_U_V_WL0x31Da
#define EGL_WAYLAND_BUFFER_Y_UV_WL 0x31Db
-#define EGL_WAYLAND_BUFFER_Y_XUXV_WL 0x31Dc
struct wl_display;
struct wl_buffer;
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index d3a66c5..29c0872 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -920,6 +920,11 @@ struct __DRIdri2ExtensionRec {
* little endian __DRI_IMAGE_FORMAT_XRGB corresponds to
* MESA_FORMAT_XRGB, but MESA_FORMAT_XRGB_REV on big endian.
*
+ * The 0R88 ang G0R0 formats implies a swizzle to zero out the 0
+ * components and swizzle the R and G components into place. The formats are
+ * native endian and thus, for G0R0 on little endian, bits 8-15 (second
+ * byte) maps to red and bits 24-31 (fourth byte) maps to green.
+ *
* __DRI_IMAGE_FORMAT_NONE is for images that aren't directly usable
* by the driver (YUV planar formats) but serve as a base image for
* creating sub-images for the different planes within the image.
@@ -932,6 +937,8 @@ struct __DRIdri2ExtensionRec {
#define __DRI_IMAGE_FORMAT_R8 0x1006 /* Since version 5 */
#define __DRI_IMAGE_FORMAT_GR88 0x1007
#define __DRI_IMAGE_FORMAT_NONE 0x1008
+#define __DRI_IMAGE_FORMAT_0R88 0x1009
+#define __DRI_IMAGE_FORMAT_G0R0 0x100a
#define __DRI_IMAGE_USE_SHARE 0x0001
#define __DRI_
[Mesa-dev] [Bug 52209] lp_test_format regression
https://bugs.freedesktop.org/show_bug.cgi?id=52209 --- Comment #4 from Vinson Lee 2012-07-17 21:15:10 PDT --- Created attachment 64334 --> https://bugs.freedesktop.org/attachment.cgi?id=64334 lp_test_format.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52209] lp_test_format regression
https://bugs.freedesktop.org/show_bug.cgi?id=52209 --- Comment #5 from Vinson Lee 2012-07-17 21:18:25 PDT --- (In reply to comment #3) > Thanks. And what's your CPU, and LLVM version? Intel Westmere llvm-2.9 > Does setting > > LP_NATIVE_VECTOR_WIDTH=128 > > help? No. > If not, please run the test as > > GALLIVM_DEBUG=tgsi,ir,asm /path/to/lp_test_format -v -v > > and attatch the output. Before and after the faulty commit above. See attachment #64334 for output after faulty commit. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] softpipe: Take all lods into account when texture sampling.
On 07/13/2012 10:30 AM, Olivier Galibert wrote: On Wed, Jun 20, 2012 at 08:33:38AM -0600, Brian Paul wrote: Yeah, I think it's pretty clear that we need to support per-pixel LOD selection. For softpipe, Olivier's big patch looks good. ... and then nothing happened. Ping? The only code remark was a whitespace issue on one line :-) I'll commit/push your patch soon. I don't always remember who has git-write access so if you can't push patches yourself you should probably indicate so. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52209] lp_test_format regression
https://bugs.freedesktop.org/show_bug.cgi?id=52209 --- Comment #6 from Vinson Lee 2012-07-17 21:45:56 PDT --- lp_test_format only passes on llvm-3.1 on my machine. llvm-2.6: fail llvm-2.7: fail llvm-2.8: fail llvm-2.9: fail llvm-3.0: fail llvm-3.1: pass llvm-3.2svn: fail -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] wider registers in llvmpipe
On Mon, Jul 16, 2012 at 11:43 AM, Jose Fonseca wrote: > FYI, I've just pushed a branch named llvmpipe-wider-regs, which allows > llvmpipe to leverage SIMD registers wider than 128bits. > > Unfortunately, performance-wise this doesn't change much, as llvmpipe > performance is dominated by integer SIMD instructions, whereas currently the > AVX instruction set currently only supports floating SIMD instructions. > Actually, often things will get slightly slower, as there are considerable > overheads in piecing together the 256 floating point code paths and 128-bit > integer code paths. > > The benefit for this change is foremost architectural: llvmpipe now makes > less assumptions regarding the number of pixels/quads/etc that fit into a > hardware register, a flexibility which will be necessary to get things like > per-pixel LOD working properly. > > This barely touch files outside gallivm/draw/llvmpipe modules. I haven't > tested i915g, r300g, so let me know if there are regressions / concerns. I'd > like to merge this into master soon. It regresses the following on i915g (and I suspect it will regress on llvmpipe also): draw-vertices pass -> abort draw-vertices-half-float pass -> crash draw-vertices-half-float-user pass -> crash draw-vertices-user pass -> abort The machine in question doesn't have AVX (or llvm 3.1 for that matter). Stéphane ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/msaa: Disable alpha-to-{coverage, one} when drawbuffer zero is in integer format
OpenGL specification 3.3 (page 196), section 4.1.3 says:
If drawbuffer zero is not NONE and the buffer it references has an
integer format, the SAMPLE_ALPHA_TO_COVERAGE and SAMPLE_ALPHA_TO_ONE
operations are skipped."
This should work properly even if there are other draw buffers that
are not in integer format.
This patch makes following piglit tests pass on mesa:
int-draw-buffers-alpha-to-coverage
int-draw-buffers-alpha-to-one
Note: Patches for these piglit tests are under review on piglit mailing
list.
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/dri/i965/gen6_cc.c | 29 ++---
1 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_cc.c
b/src/mesa/drivers/dri/i965/gen6_cc.c
index e0523ef..427cca9 100644
--- a/src/mesa/drivers/dri/i965/gen6_cc.c
+++ b/src/mesa/drivers/dri/i965/gen6_cc.c
@@ -35,6 +35,7 @@
static void
gen6_upload_blend_state(struct brw_context *brw)
{
+ bool is_buffer_zero_integer_format = false;
struct gl_context *ctx = &brw->intel.ctx;
struct gen6_blend_state *blend;
int b;
@@ -76,6 +77,9 @@ gen6_upload_blend_state(struct brw_context *brw)
*/
integer = (rb_type == GL_INT || rb_type == GL_UNSIGNED_INT);
+ if(b == 0 && integer)
+ is_buffer_zero_integer_format = true;
+
/* _NEW_COLOR */
if (ctx->Color.ColorLogicOpEnabled) {
/* Floating point RTs should have no effect from LogicOp,
@@ -161,13 +165,24 @@ gen6_upload_blend_state(struct brw_context *brw)
blend[b].blend1.write_disable_g = !ctx->Color.ColorMask[b][1];
blend[b].blend1.write_disable_b = !ctx->Color.ColorMask[b][2];
blend[b].blend1.write_disable_a = !ctx->Color.ColorMask[b][3];
-
- /* _NEW_MULTISAMPLE */
- blend[b].blend1.alpha_to_coverage =
- ctx->Multisample._Enabled && ctx->Multisample.SampleAlphaToCoverage;
- blend[b].blend1.alpha_to_one =
- ctx->Multisample._Enabled && ctx->Multisample.SampleAlphaToOne;
- blend[b].blend1.alpha_to_coverage_dither = (brw->intel.gen >= 7);
+
+ /* OpenGL specification 3.3 (page 196), section 4.1.3 says:
+ * "If drawbuffer zero is not NONE and the buffer it references has an
+ * integer format, the SAMPLE_ALPHA_TO_COVERAGE and SAMPLE_ALPHA_TO_ONE
+ * operations are skipped."
+ */
+ if(!is_buffer_zero_integer_format) {
+ /* _NEW_MULTISAMPLE */
+ blend[b].blend1.alpha_to_coverage =
+ctx->Multisample._Enabled &&
ctx->Multisample.SampleAlphaToCoverage;
+ blend[b].blend1.alpha_to_one =
+ctx->Multisample._Enabled && ctx->Multisample.SampleAlphaToOne;
+ blend[b].blend1.alpha_to_coverage_dither = (brw->intel.gen >= 7);
+ }
+ else {
+ blend[b].blend1.alpha_to_coverage = false;
+blend[b].blend1.alpha_to_one = false;
+ }
}
brw->state.dirty.cache |= CACHE_NEW_BLEND_STATE;
--
1.7.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Don't print messages to stderr if context creation fails.
On Thu, 12 Jul 2012 12:45:22 -0700
Kenneth Graunke wrote:
> Since there is no getparam for hardware context support, Mesa always
> tries to obtain a context by calling drm_intel_gem_context_create and
> NULL-checking the result. On an older kernel without context support,
> this caused libdrm to print an unwanted message to stderr:
>
> DRM_IOCTL_I915_GEM_CONTEXT_CREATE failed: Invalid argument
>
> In fact, this caused every Piglit test to fail with a "warn" status due
> to the unrecognized error message.
>
> Simply delete the message. It's OK for context creation to fail.
Change it to DBG() and you have my:
Reviewed-by: Ben Widawsky
>
> Cc: Ben Widawsky
> Cc: Paul Berry
> Cc: mesa-de...@lists.freedesktop.org
> Signed-off-by: Kenneth Graunke
> ---
> intel/intel_bufmgr_gem.c |5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index a957c28..1b4ac78 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -2850,11 +2850,8 @@ drm_intel_gem_context_create(drm_intel_bufmgr *bufmgr)
> int tmp = 0, ret;
>
> ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE,
> &create);
> - if (ret != 0) {
> - fprintf(stderr, "DRM_IOCTL_I915_GEM_CONTEXT_CREATE failed:
> %s\n",
> - strerror(errno));
> + if (ret != 0)
> return NULL;
> - }
>
> context = calloc(1, sizeof(*context));
> context->ctx_id = create.ctx_id;
--
Ben Widawsky, Intel Open Source Technology Center
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52209] lp_test_format regression
https://bugs.freedesktop.org/show_bug.cgi?id=52209
--- Comment #7 from Roland Scheidegger 2012-07-17 23:25:56
PDT ---
Since the test doesn't use any sized vectors depending on cpu caps
LP_NATIVE_VECTOR_WIDTH shouldn't affect anything.
Here's the IR of a test which fails:
define void @fetch_r32g32_sscaled_unorm8(<4 x i8>*, i8*, i32, i32) {
entry:
%4 = bitcast i8* %1 to <2 x i32>*
%5 = load <2 x i32>* %4, align 4
%6 = shufflevector <2 x i32> %5, <2 x i32> undef, <4 x i32>
%7 = call <4 x i32> @llvm.x86.sse41.pmaxsd(<4 x i32> %6, <4 x i32>
zeroinitializer)
%8 = call <4 x i32> @llvm.x86.sse41.pminsd(<4 x i32> %7, <4 x i32> )
%9 = ashr <4 x i32> %8,
%10 = sub <4 x i32> %8, %9
%11 = extractelement <4 x i32> %10, i32 0
%12 = extractelement <4 x i32> %10, i32 1
%13 = extractelement <4 x i32> %10, i32 2
%14 = extractelement <4 x i32> %10, i32 3
%15 = bitcast i32 %11 to <2 x i16>
%16 = bitcast i32 %12 to <2 x i16>
%17 = shufflevector <2 x i16> %15, <2 x i16> %16, <2 x i32>
%18 = bitcast i32 %13 to <2 x i16>
%19 = bitcast i32 %14 to <2 x i16>
%20 = shufflevector <2 x i16> %18, <2 x i16> %19, <2 x i32>
%21 = bitcast <2 x i16> %17 to <4 x i8>
%22 = bitcast <2 x i16> %20 to <4 x i8>
%23 = shufflevector <4 x i8> %21, <4 x i8> %22, <4 x i32>
%24 = shl <4 x i8> %23,
%25 = sub <4 x i8> %24, %23
%26 = bitcast <4 x i8> %25 to i32
%27 = and i32 %26, 65535
%28 = or i32 bitcast (<4 x i8> to i32), %27
%29 = bitcast i32 %28 to <4 x i8>
store <4 x i8> %29, <4 x i8>* %0
ret void
}
With llvm 3.1 it passes but not with 2.9/3.0.
But there's more to it, with 2.9 AND a cpu which isn't sse41-capable it also
passes (and on top of it the code generated is way _better_ despite it can't
use the pminsd/pmaxsd intrinsics but those aren't the issue).
So with sse41 or avx capable cpu llvm 3.1 generates correct but crappy code,
whereas it is crappy and wrong with 2.9/3.0. Only if you have a not-sse41
capable cpu it produces correct and good code...
I believe the issue here is use of the non-native vectors toward the end (2x16,
4x8) since llvm uses padded vector elements for them (a 4xi8 vector looks like
4xi32) so it has to do lots of weird shuffles (those harmless looking bitcasts
cause lots of unpacks, shuffles etc.). Well that's the explanation for the
crappy code (probably some optimization wasn't available without sse41 which
turned out to be much better in the end). Fortunately it shouldn't happen with
llvmpipe since we don't generally use such vectors (we always fetch multiple of
4 values). This doesn't explain why it isn't correct though. Maybe we're
relying somewhere on some properties of those values when resizing which don't
hold true if the vector elements aren't packed but padded.
There's another issue with this code, which may or may not be related to this
bug:
%9 = ashr <4 x i32> %8,
(the uscaled formats will have a lshr instead).
This shuffle is illegal since shuffles with values larger or equal than vector
width (which this is) are undefined in llvm (ok not illegal just the result is
undefined). However, llvm itself doesn't care and with sse2 it just happily
issues the psrad 255 instruction, which has defined (and reasonable) behavior
(for the non-vector domain the hardware will just use the last count bits which
would still work). This comes from lp_build_conv(), line 594 (since src_shift
is zero, and src_offset is 0 and dst_offset is 1). So something seems wrong
with this calculation, maybe we'd need to do something different if destination
is normalized format instead.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] st/xorg: attach EDID to outputs
Allows tools like GNOME's monitor configuration to show meaningful names.
Signed-off-by: Lucas Stach
---
src/gallium/state_trackers/xorg/xorg_output.c | 32 -
1 Datei geändert, 31 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_output.c
b/src/gallium/state_trackers/xorg/xorg_output.c
index b51..d851383 100644
--- a/src/gallium/state_trackers/xorg/xorg_output.c
+++ b/src/gallium/state_trackers/xorg/xorg_output.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -54,7 +55,8 @@
struct output_private
{
drmModeConnectorPtr drm_connector;
-
+drmModePropertyBlobPtr edid_blob;
+int fd;
int c;
};
@@ -122,9 +124,34 @@ output_get_modes(xf86OutputPtr output)
struct output_private *priv = output->driver_private;
drmModeConnectorPtr drm_connector = priv->drm_connector;
drmModeModeInfoPtr drm_mode = NULL;
+drmModePropertyPtr props = NULL;
+xf86MonPtr ddc_mon = NULL;
DisplayModePtr modes = NULL, mode = NULL;
int i;
+ for (i = 0; i < drm_connector->count_props; i++) {
+ props = drmModeGetProperty(priv->fd, drm_connector->props[i]);
+ if (!props || !(props->flags & DRM_MODE_PROP_BLOB))
+ continue;
+
+ if (!strcmp(props->name, "EDID")) {
+ if (priv->edid_blob)
+ drmModeFreePropertyBlob(priv->edid_blob);
+ priv->edid_blob = drmModeGetPropertyBlob(priv->fd,
+
drm_connector->prop_values[i]);
+ }
+ drmModeFreeProperty(props);
+ }
+
+ if (priv->edid_blob) {
+ ddc_mon = xf86InterpretEDID(output->scrn->scrnIndex,
+
priv->edid_blob->data);
+
+ if (ddc_mon && priv->edid_blob->length > 128)
+ ddc_mon->flags |= MONITOR_EDID_COMPLETE_RAWDATA;
+ }
+ xf86OutputSetEDID(output, ddc_mon);
+
for (i = 0; i < drm_connector->count_modes; i++) {
drm_mode = &drm_connector->modes[i];
if (drm_mode) {
@@ -194,6 +221,8 @@ static void
output_destroy(xf86OutputPtr output)
{
struct output_private *priv = output->driver_private;
+if (priv->edid_blob)
+ drmModeFreePropertyBlob(priv->edid_blob);
drmModeFreeConnector(priv->drm_connector);
free(priv);
output->driver_private = NULL;
@@ -283,6 +312,7 @@ xorg_output_init(ScrnInfoPtr pScrn)
}
priv->c = c;
priv->drm_connector = drm_connector;
+ priv->fd = ms->fd;
output->driver_private = priv;
output->subpixel_order = SubPixelHorizontalRGB;
output->interlaceAllowed = FALSE;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] st/xorg: reorder exa context creation and use screen param queries
Gives the x-server a more accurate description of the exa hardware
capabilities.
Signed-off-by: Lucas Stach
---
src/gallium/state_trackers/xorg/xorg_exa.c | 17 ++---
1 Datei geändert, 10 Zeilen hinzugefügt(+), 7 Zeilen entfernt(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_exa.c
b/src/gallium/state_trackers/xorg/xorg_exa.c
index 91669ce..27a814a 100644
--- a/src/gallium/state_trackers/xorg/xorg_exa.c
+++ b/src/gallium/state_trackers/xorg/xorg_exa.c
@@ -991,6 +991,11 @@ xorg_exa_init(ScrnInfoPtr pScrn, Bool accel)
if (!exa)
return NULL;
+ exa->scrn = ms->screen;
+ exa->pipe = exa->scrn->context_create(exa->scrn, NULL);
+ if (exa->pipe == NULL)
+ goto out_err;
+
pExa = exaDriverAlloc();
if (!pExa) {
goto out_err;
@@ -1012,8 +1017,11 @@ xorg_exa_init(ScrnInfoPtr pScrn, Bool accel)
#ifdef EXA_MIXED_PIXMAPS
pExa->flags|= EXA_MIXED_PIXMAPS;
#endif
- pExa->maxX = 8191; /* FIXME */
- pExa->maxY = 8191; /* FIXME */
+ if (!exa->scrn->get_param(exa->scrn, PIPE_CAP_NPOT_TEXTURES))
+ pExa->flags |= EXA_OFFSCREEN_ALIGN_POT;
+
+ pExa->maxX = pExa->maxY =
+ 1 << (exa->scrn->get_param(exa->scrn, PIPE_CAP_MAX_TEXTURE_2D_LEVELS) - 1);
pExa->WaitMarker = ExaWaitMarker;
pExa->MarkSync = ExaMarkSync;
@@ -1040,11 +1048,6 @@ xorg_exa_init(ScrnInfoPtr pScrn, Bool accel)
goto out_err;
}
- exa->scrn = ms->screen;
- exa->pipe = exa->scrn->context_create(exa->scrn, NULL);
- if (exa->pipe == NULL)
- goto out_err;
-
/* Share context with DRI */
ms->ctx = exa->pipe;
if (cust && cust->winsys_context_throttle)
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] st/xorg: remove superfluous memset
exaDriverAlloc() uses calloc, which already initialises pExa to zero. Signed-off-by: Lucas Stach --- src/gallium/state_trackers/xorg/xorg_exa.c |2 -- 1 Datei geändert, 2 Zeilen entfernt(-) diff --git a/src/gallium/state_trackers/xorg/xorg_exa.c b/src/gallium/state_trackers/xorg/xorg_exa.c index 27a814a..0ea13fe 100644 --- a/src/gallium/state_trackers/xorg/xorg_exa.c +++ b/src/gallium/state_trackers/xorg/xorg_exa.c @@ -1001,8 +1001,6 @@ xorg_exa_init(ScrnInfoPtr pScrn, Bool accel) goto out_err; } - memset(pExa, 0, sizeof(*pExa)); - pExa->exa_major = 2; pExa->exa_minor = 2; pExa->memoryBase= 0; -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] wider registers in llvmpipe
Am 17.07.2012 23:49, schrieb Stéphane Marchesin: > On Mon, Jul 16, 2012 at 11:43 AM, Jose Fonseca wrote: >> FYI, I've just pushed a branch named llvmpipe-wider-regs, which allows >> llvmpipe to leverage SIMD registers wider than 128bits. >> >> Unfortunately, performance-wise this doesn't change much, as llvmpipe >> performance is dominated by integer SIMD instructions, whereas currently the >> AVX instruction set currently only supports floating SIMD instructions. >> Actually, often things will get slightly slower, as there are considerable >> overheads in piecing together the 256 floating point code paths and 128-bit >> integer code paths. >> >> The benefit for this change is foremost architectural: llvmpipe now makes >> less assumptions regarding the number of pixels/quads/etc that fit into a >> hardware register, a flexibility which will be necessary to get things like >> per-pixel LOD working properly. >> >> This barely touch files outside gallivm/draw/llvmpipe modules. I haven't >> tested i915g, r300g, so let me know if there are regressions / concerns. I'd >> like to merge this into master soon. > > > It regresses the following on i915g (and I suspect it will regress on > llvmpipe also): > draw-vertices pass -> abort > draw-vertices-half-float pass -> crash > draw-vertices-half-float-user pass -> crash > draw-vertices-user pass -> abort > > The machine in question doesn't have AVX (or llvm 3.1 for that matter). I've tested this with both llvm 3.1 and 2.9, with and without avx and draw-vertices and draw-vertices-half-float always pass with llvmpipe. I don't see the other two tests (draw-vertices-half-float-user and draw-vertices-user) in piglit. Can you provide any more information about the crashes/aborts? Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52209] lp_test_format regression
https://bugs.freedesktop.org/show_bug.cgi?id=52209 --- Comment #8 from Roland Scheidegger 2012-07-18 02:03:19 PDT --- Ah I think I got it. %24 = shl <4 x i8> %23, This is another extremely questionable shift (count must be smaller than number of bits), coming from lp_build_conv(), line 690). This shift is what probably causes most of the crazy code generated (because there is no native vector byte shift). Most likely this causes the wrong results - since llvm does some really crazy things to emulate this shift, I suspect this emulation can cause wrong results as those crazy things it does probably are only guaranteed to work when the shift count is legal (the code generated is too unreadable to be sure). Note that this format conversion is rather crazy anyway - all values get mapped to either 0 or 1, that shift above is what is done to get those 0/1 values into unorm format (together with the sub following it). In any case I don't think this is really a regression. Most likely we just got lucky before. I think the old code would have used extract/scalar truncation/insert before that shift, hence llvm probably would have just used scalar shifts instead of the complicated emulation (which actually in this case most likely was better). But technically the shift still was undefined. To fix this properly I think we must move arounds those shifts a bit (before/after lp_build_resize()) but that's going to depend on what the src/dst format is. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] st/gbm: renaming pitch to stride on gallium
> Thanks, applied. I'm trying to update it to support the new gbm import > function now. Did you consider gallium as a dri driver though? > I'm thinking that maintaining 1) the native gallium interface, 2) the > gallium dri interface and 3) the intel dri interface is just too much. > I'd like to drop support for the the gbm gallium state tracker and just > use the DRI statetracker instead. > > Kristian Actually, I didn't think that much and I don't know well about it. I just tried to resolve build errors. Elvis -- Elvis Lee (이광웅) Software Engineer @ LG Electronics Inc. CTO Division / SW Platform Lab. / Advanced OS Tech Team. Yang-jae dong 221, Seoul, Korea. > > > Signed-off-by: Elvis Lee > > --- > > src/gallium/state_trackers/gbm/gbm_drm.c |4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/src/gallium/state_trackers/gbm/gbm_drm.c > > b/src/gallium/state_trackers/gbm/gbm_drm.c > > index a327fda..eb426ef 100644 > > --- a/src/gallium/state_trackers/gbm/gbm_drm.c > > +++ b/src/gallium/state_trackers/gbm/gbm_drm.c > > @@ -131,7 +131,7 @@ gbm_gallium_drm_bo_create_from_egl_image(struct > gbm_device *gbm, > > gdrm->screen->resource_get_handle(gdrm->screen, bo->resource, > > &whandle); > > > > bo->base.base.handle.u32 = whandle.handle; > > - bo->base.base.pitch = whandle.stride; > > + bo->base.base.stride = whandle.stride; > > > > return &bo->base.base; > > } > > @@ -180,7 +180,7 @@ gbm_gallium_drm_bo_create(struct gbm_device *gbm, > > gdrm->screen->resource_get_handle(gdrm->screen, bo->resource, > > &whandle); > > > > bo->base.base.handle.u32 = whandle.handle; > > - bo->base.base.pitch = whandle.stride; > > + bo->base.base.stride = whandle.stride; > > > > return &bo->base.base; > > } > > -- > > 1.7.9.5 > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52064] build fails with "git_sha1.h.tmp": permission denied
https://bugs.freedesktop.org/show_bug.cgi?id=52064 --- Comment #2 from Brian Paterni 2012-07-18 03:14:04 PDT --- I've managed to come up with a solution to this on my own. I'm no automake expert and it's a bit of a hack IMO, but it works for me. Let me know what you think. [PATCH] automake: build git_sha1.h without BUILT_SOURCES BUILT_SOURCES are applied to 'all', 'check', and 'install' targets. So when make install is run as root, git_sha1.h.tmp is generated again as root for some reason(?) which causes the next build to fail with 'Permission denied' error. --- src/mesa/Makefile.am | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am index 2b023d7..e459ac0 100644 --- a/src/mesa/Makefile.am +++ b/src/mesa/Makefile.am @@ -35,7 +35,7 @@ main/git_sha1.h.tmp: fi \ fi -main/git_sha1.h: main/git_sha1.h.tmp +main/git_sha1.h: Makefile main/git_sha1.h.tmp @echo "updating main/git_sha1.h" @if ! cmp -s main/git_sha1.h.tmp main/git_sha1.h; then \ mv main/git_sha1.h.tmp main/git_sha1.h ;\ @@ -47,7 +47,6 @@ GLAPI = $(TOP)/src/mapi/glapi/gen include $(GLAPI)/glapi_gen.mk BUILT_SOURCES = \ -main/git_sha1.h \ main/api_exec_es1_dispatch.h \ main/api_exec_es1_remap_helper.h \ main/api_exec_es2_dispatch.h \ @@ -59,7 +58,7 @@ BUILT_SOURCES = \ program/lex.yy.c CLEANFILES = \ $(BUILT_SOURCES) \ -git_sha1.h.tmp +main/git_sha1.h.tmp main/api_exec_es1_dispatch.h: $(GLAPI)/gl_and_es_API.xml $(glapi_gen_dispatch_deps) $(call glapi_gen_dispatch,$<,es1) @@ -115,11 +114,18 @@ if HAVE_SPARC_ASM MESA_ASM_FILES_FOR_ARCH += $(SPARC_FILES) endif +nodist_libmesa_la_SOURCES = \ +main/git_sha1.h +noinst_libmesa_la_SOURCES = \ +main/git_sha1.h + libmesa_la_SOURCES = \ $(MESA_FILES) \ $(MESA_CXX_FILES) \ $(MESA_ASM_FILES_FOR_ARCH) +$(SRCDIR)/main/version.c: main/git_sha1.h + libmesa_la_LIBADD = $(top_builddir)/src/glsl/libglsl.la libmesa_la_LDFLAGS = -- 1.7.10.4 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nv50/ir: set position before i instead of i->next in NV50LoweringPreSSA::visit
Fixes rendering glitches in Psychonauts such as Raz's eyes flickering white. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=51962. --- .../drivers/nv50/codegen/nv50_ir_lowering_nv50.cpp |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nv50/codegen/nv50_ir_lowering_nv50.cpp b/src/gallium/drivers/nv50/codegen/nv50_ir_lowering_nv50.cpp index 39e0cfa..b688172 100644 --- a/src/gallium/drivers/nv50/codegen/nv50_ir_lowering_nv50.cpp +++ b/src/gallium/drivers/nv50/codegen/nv50_ir_lowering_nv50.cpp @@ -1034,7 +1034,7 @@ NV50LoweringPreSSA::visit(Instruction *i) bld.setPosition(i->prev, true); else if (i->next) - bld.setPosition(i->next, false); + bld.setPosition(i, false); else bld.setPosition(i->bb, true); -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] build: fix location of generated files in src/mesa (v2)
Also fix include paths for the generated headers. v2: Switch to using self-explanatory BUILDDIR/SRCDIR defined from top_builddir/top_srcdir rather than the ambiguous TOP. Signed-off-by: Christopher James Halse Rogers --- src/glx/apple/Makefile |4 src/mesa/Makefile.am|7 --- src/mesa/Makefile.old |5 - src/mesa/libdricore/Makefile.am |3 --- src/mesa/sources.mak| 34 -- 5 files changed, 32 insertions(+), 21 deletions(-) diff --git a/src/glx/apple/Makefile b/src/glx/apple/Makefile index 35edb09..ef12eb0 100644 --- a/src/glx/apple/Makefile +++ b/src/glx/apple/Makefile @@ -1,4 +1,8 @@ TOP = ../../.. +top_builddir = $(TOP) +# This can be a filthy lie. But it doesn't currently build out-of-tree +# anyway, so it's no worse than what we've got now. +top_srcdir = $(TOP) include $(TOP)/configs/current diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am index 2b023d7..f70a5c1 100644 --- a/src/mesa/Makefile.am +++ b/src/mesa/Makefile.am @@ -42,8 +42,7 @@ main/git_sha1.h: main/git_sha1.h.tmp fi # include glapi_gen.mk for generating glapi headers for GLES -TOP = $(top_srcdir) -GLAPI = $(TOP)/src/mapi/glapi/gen +GLAPI = $(top_srcdir)/src/mapi/glapi/gen include $(GLAPI)/glapi_gen.mk BUILT_SOURCES = \ @@ -95,7 +94,6 @@ program/lex.yy.c: program/program_lexer.l noinst_LTLIBRARIES = libmesa.la libmesagallium.la -SRCDIR = $(top_srcdir)/src/mesa include sources.mak AM_CPPFLAGS = $(API_DEFINES) $(DEFINES) $(INCLUDE_DIRS) @@ -107,12 +105,15 @@ MESA_ASM_FILES_FOR_ARCH = if HAVE_X86_ASM MESA_ASM_FILES_FOR_ARCH += $(X86_FILES) +AM_CPPFLAGS += -I$(top_builddir)/src/mesa/x86 endif if HAVE_X86_64_ASM MESA_ASM_FILES_FOR_ARCH += $(X86_64_FILES) +AM_CPPFLAGS += -I$(top_builddir)/src/mesa/x86-64 endif if HAVE_SPARC_ASM MESA_ASM_FILES_FOR_ARCH += $(SPARC_FILES) +AM_CPPFLAGS += -I$(top_builddir)/src/mesa/sparc endif libmesa_la_SOURCES = \ diff --git a/src/mesa/Makefile.old b/src/mesa/Makefile.old index 3266a5d..5b5c745 100644 --- a/src/mesa/Makefile.old +++ b/src/mesa/Makefile.old @@ -1,9 +1,12 @@ # src/mesa/Makefile TOP = ../.. +top_builddir = $(TOP) +# This is a filthy lie in the case of out-of-tree builds. But it doesn't +# currently build out-of-tree anyway, so it's no worse than what we've got now. +top_srcdir = $(TOP) include $(TOP)/configs/current -SRCDIR = . include sources.mak default: diff --git a/src/mesa/libdricore/Makefile.am b/src/mesa/libdricore/Makefile.am index 26d8a88..7e1c22a 100644 --- a/src/mesa/libdricore/Makefile.am +++ b/src/mesa/libdricore/Makefile.am @@ -19,10 +19,7 @@ # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS # IN THE SOFTWARE. -TOP=$(top_srcdir) -SRCDIR = $(srcdir)/.. include ../sources.mak -GLSL_SRCDIR = $(srcdir)/../../glsl include ../../glsl/Makefile.sources noinst_PROGRAMS = diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak index d22f059..9f83069 100644 --- a/src/mesa/sources.mak +++ b/src/mesa/sources.mak @@ -1,11 +1,12 @@ ### Lists of source files, included by Makefiles -SRCDIR ?= . +SRCDIR=$(top_srcdir)/src/mesa +BUILDDIR=$(top_builddir)/src/mesa # this is part of MAIN_FILES MAIN_ES_FILES = \ - $(SRCDIR)/main/api_exec_es1.c \ - $(SRCDIR)/main/api_exec_es2.c + $(BUILDDIR)/main/api_exec_es1.c \ + $(BUILDDIR)/main/api_exec_es2.c MAIN_FILES = \ $(SRCDIR)/main/api_arrayelt.c \ @@ -34,7 +35,6 @@ MAIN_FILES = \ $(SRCDIR)/main/drawpix.c \ $(SRCDIR)/main/drawtex.c \ $(SRCDIR)/main/enable.c \ - $(SRCDIR)/main/enums.c \ $(SRCDIR)/main/errors.c \ $(SRCDIR)/main/eval.c \ $(SRCDIR)/main/execmem.c \ @@ -105,6 +105,7 @@ MAIN_FILES = \ $(SRCDIR)/main/version.c \ $(SRCDIR)/main/viewport.c \ $(SRCDIR)/main/vtxfmt.c \ + $(BUILDDIR)/main/enums.c \ $(MAIN_ES_FILES) MAIN_CXX_FILES = \ @@ -249,11 +250,9 @@ STATETRACKER_FILES = \ PROGRAM_FILES = \ $(SRCDIR)/program/arbprogparse.c \ $(SRCDIR)/program/hash_table.c \ - $(SRCDIR)/program/lex.yy.c \ $(SRCDIR)/program/nvfragparse.c \ $(SRCDIR)/program/nvvertparse.c \ $(SRCDIR)/program/program.c \ - $(SRCDIR)/program/program_parse.tab.c \ $(SRCDIR)/program/program_parse_extra.c \ $(SRCDIR)/program/prog_cache.c \ $(SRCDIR)/program/prog_execute.c \ @@ -267,7 +266,9 @@ PROGRAM_FILES = \ $(SRCDIR)/program/prog_statevars.c \ $(SRCDIR)/program/programopt.c \ $(SRCDIR)/program/register_allocate.c \ - $(SRCDIR)/program/symbol_table.c + $(SRCDIR)/program/symbol_table.c \ + $(BUILDDIR)/program/lex.yy.c \ + $(BUILDDIR)/program/program_parse.tab.c SHADER_CXX_FILES = \ @@ -373,15 +374,20 @@ COMMON_DRIVER_OBJECTS = $(COMMON_DRIVER_FILES:.c=.o) ### Other archives/libraries GLSL_LIBS = \ - $(TOP)/src/glsl/
[Mesa-dev] [PATCH 2/6] bulid/glx: fix include paths for out-of-tree builds
Signed-off-by: Christopher James Halse Rogers --- src/glx/Makefile.am |2 ++ 1 file changed, 2 insertions(+) diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am index bb23998..23d5753 100644 --- a/src/glx/Makefile.am +++ b/src/glx/Makefile.am @@ -37,6 +37,8 @@ AM_CFLAGS = \ -I$(top_srcdir)/include/GL/internal \ -I$(top_srcdir)/src/mapi \ -I$(top_srcdir)/src/mapi/glapi \ + -I$(top_builddir)/src/mapi \ + -I$(top_builddir)/src/mapi/glapi \ $(SHARED_GLAPI_CFLAGS) \ $(EXTRA_DEFINES_XF86VIDMODE) \ -D_REENTRANT \ -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/6] build: fix out of tree generation of glapi_mapi_tmp.h
Signed-off-by: Christopher James Halse Rogers --- src/mapi/glapi/gen/Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am index 52aeb3a..499ec09 100644 --- a/src/mapi/glapi/gen/Makefile.am +++ b/src/mapi/glapi/gen/Makefile.am @@ -176,7 +176,7 @@ $(XORG_GLAPI_DIR)/%.h: $(MESA_GLAPI_DIR)/%.h $(MESA_GLAPI_DIR)/glapi_mapi_tmp.h: $(MESA_MAPI_DIR)/mapi_abi.py $(COMMON_ES) $(PYTHON_GEN) $< \ - --printer glapi --mode lib gl_and_es_API.xml > $@ + --printer glapi --mode lib $(srcdir)/gl_and_es_API.xml > $@ $(MESA_GLAPI_DIR)/glprocs.h: gl_procs.py $(COMMON) $(PYTHON_GEN) $< -f $(srcdir)/gl_API.xml > $@ -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/6] build/glapi: fix includes for generated files
Signed-off-by: Christopher James Halse Rogers --- src/mapi/glapi/Makefile.am |1 + 1 file changed, 1 insertion(+) diff --git a/src/mapi/glapi/Makefile.am b/src/mapi/glapi/Makefile.am index 668d7fa..181a28a 100644 --- a/src/mapi/glapi/Makefile.am +++ b/src/mapi/glapi/Makefile.am @@ -27,6 +27,7 @@ AM_CPPFLAGS = \ $(DEFINES) \ -I$(top_srcdir)/include \ -I$(top_srcdir)/src/mapi \ +-I$(top_builddir)/src/mapi \ -I$(top_srcdir)/src/mesa if HAVE_X86_ASM -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] build/glsl: fix location of generated files.
Like in src/mesa, use GLSL_BUILDDIR/GLSL_SRCDIR to unambiguously distinguish between in-tree and generated files. Signed-off-by: Christopher James Halse Rogers --- src/glsl/Makefile.am|4 src/glsl/Makefile.sources | 15 --- src/glsl/glcpp/Makefile.am |4 src/mapi/es1api/Makefile|4 src/mapi/glapi/gen/glapi_gen.mk | 14 +++--- 5 files changed, 19 insertions(+), 22 deletions(-) diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am index d86153c..0ab6672 100644 --- a/src/glsl/Makefile.am +++ b/src/glsl/Makefile.am @@ -23,9 +23,6 @@ # builtin_compiler is built before libglsl to generate builtin_function.cpp for libglsl. # For this to work, a dummy version of builtin_function.cpp, builtin_stubs.cpp, is used. -# Hack to make some of the non-automake variables work. -TOP=$(top_builddir) - AM_CFLAGS = \ -I$(top_srcdir)/include \ -I$(top_srcdir)/src/mapi \ @@ -39,7 +36,6 @@ AM_CXXFLAGS = $(AM_CFLAGS) AM_LFLAGS = --nounistd -o$(LEX_OUTPUT_ROOT).c -GLSL_SRCDIR=$(top_srcdir)/src/glsl include Makefile.sources noinst_LTLIBRARIES = libglslcommon.la libglsl.la diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources index f2743f7..15c717a 100644 --- a/src/glsl/Makefile.sources +++ b/src/glsl/Makefile.sources @@ -1,6 +1,7 @@ # shared source lists for Makefile, SConscript, and Android.mk -GLSL_SRCDIR ?= . +GLSL_SRCDIR = $(top_srcdir)/src/glsl +GLSL_BUILDDIR = $(top_builddir)/src/glsl # libglcpp @@ -8,8 +9,8 @@ LIBGLCPP_FILES = \ $(GLSL_SRCDIR)/glcpp/pp.c LIBGLCPP_GENERATED_FILES = \ - $(GLSL_SRCDIR)/glcpp/glcpp-lex.c \ - $(GLSL_SRCDIR)/glcpp/glcpp-parse.c + $(GLSL_BUILDDIR)/glcpp/glcpp-lex.c \ + $(GLSL_BUILDDIR)/glcpp/glcpp-parse.c # libglsl @@ -101,10 +102,10 @@ BUILTIN_COMPILER_CXX_FILES = \ $(GLSL_SRCDIR)/builtin_stubs.cpp BUILTIN_COMPILER_GENERATED_CXX_FILES = \ - $(GLSL_SRCDIR)/glsl_lexer.cc \ - $(GLSL_SRCDIR)/glsl_parser.cc + $(GLSL_BUILDDIR)/glsl_lexer.cc \ + $(GLSL_BUILDDIR)/glsl_parser.cc # libglsl generated sources LIBGLSL_GENERATED_CXX_FILES = \ - $(GLSL_SRCDIR)/$(BUILTIN_COMPILER_GENERATED_CXX_FILES) \ - $(GLSL_SRCDIR)/builtin_function.cpp + $(BUILTIN_COMPILER_GENERATED_CXX_FILES) \ + $(GLSL_BUILDDIR)/builtin_function.cpp diff --git a/src/glsl/glcpp/Makefile.am b/src/glsl/glcpp/Makefile.am index e7d5d2c..7a95b68 100644 --- a/src/glsl/glcpp/Makefile.am +++ b/src/glsl/glcpp/Makefile.am @@ -20,10 +20,6 @@ # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS # IN THE SOFTWARE. -# Hack to make some of the non-automake variables work. -TOP=$(top_builddir) - -GLSL_SRCDIR=$(top_srcdir)/src/glsl include ../Makefile.sources AM_CFLAGS = \ diff --git a/src/mapi/es1api/Makefile b/src/mapi/es1api/Makefile index a9c9123..6f4c35a 100644 --- a/src/mapi/es1api/Makefile +++ b/src/mapi/es1api/Makefile @@ -40,6 +40,10 @@ esapi_CPPFLAGS := \ -I$(TOP)/src/mapi \ -DMAPI_ABI_HEADER=\"$(ESAPI)/glapi_mapi_tmp.h\" + +# This is a lie when doing out-of-tree builds, but it's no worse than the +# current situation, and can be dropped should this get automakified +top_srcdir = $(TOP) include $(MAPI)/sources.mak esapi_SOURCES := $(MAPI_BRIDGE_FILES) esapi_OBJECTS := $(notdir $(MAPI_BRIDGE_FILES:.c=.o)) diff --git a/src/mapi/glapi/gen/glapi_gen.mk b/src/mapi/glapi/gen/glapi_gen.mk index 1b05a40..eab8eb4 100644 --- a/src/mapi/glapi/gen/glapi_gen.mk +++ b/src/mapi/glapi/gen/glapi_gen.mk @@ -1,14 +1,14 @@ # Helpers for glapi header generation -ifndef TOP -$(error TOP must be defined.) +ifndef top_srcdir +$(error top_srcdir must be defined.) endif glapi_gen_common_deps := \ - $(wildcard $(TOP)/src/mapi/glapi/gen/*.xml) \ - $(wildcard $(TOP)/src/mapi/glapi/gen/*.py) + $(wildcard $(top_srcdir)/src/mapi/glapi/gen/*.xml) \ + $(wildcard $(top_srcdir)/src/mapi/glapi/gen/*.py) -glapi_gen_mapi_script := $(TOP)/src/mapi/mapi/mapi_abi.py +glapi_gen_mapi_script := $(top_srcdir)/src/mapi/mapi/mapi_abi.py glapi_gen_mapi_deps := \ $(glapi_gen_mapi_script) \ $(glapi_gen_common_deps) @@ -21,7 +21,7 @@ $(AM_V_GEN)$(PYTHON2) $(PYTHON_FLAGS) $(glapi_gen_mapi_script) \ --mode lib --printer $(2) $(1) > $@ endef -glapi_gen_dispatch_script := $(TOP)/src/mapi/glapi/gen/gl_table.py +glapi_gen_dispatch_script := $(top_srcdir)/src/mapi/glapi/gen/gl_table.py glapi_gen_dispatch_deps := $(glapi_gen_common_deps) # $(1): path to an XML file @@ -32,7 +32,7 @@ $(AM_V_GEN)$(PYTHON2) $(PYTHON_FLAGS) $(glapi_gen_dispatch_script) \ -f $(1) -m remap_table $(if $(2),-c $(2),) > $@ endef -glapi_gen_remap_script := $(TOP)/src/mapi/glapi/gen/remap_helper.py +glapi_gen_remap_script := $(top_srcdir)/src/mapi/glapi/gen/remap_helper.py glapi_gen_remap_deps := $(glapi_gen_common_deps) # $(1): path to an XML file -- 1.7.10.4
[Mesa-dev] [PATCH 6/6] build: Fix libdricore out-of-tree builds
Signed-off-by: Christopher James Halse Rogers --- src/mesa/libdricore/Makefile.am |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/mesa/libdricore/Makefile.am b/src/mesa/libdricore/Makefile.am index 7e1c22a..e46d5bd 100644 --- a/src/mesa/libdricore/Makefile.am +++ b/src/mesa/libdricore/Makefile.am @@ -41,7 +41,7 @@ libdricore@VERSION@_la_SOURCES = \ $(LIBGLSL_FILES) \ $(LIBGLSL_CXX_FILES) \ $(BUILTIN_COMPILER_GENERATED_CXX_FILES) \ - $(top_srcdir)/src/glsl/builtin_function.cpp + $(top_builddir)/src/glsl/builtin_function.cpp libdricore@VERSION@_la_LDFLAGS = -version-number 1:0 libdricore@VERSION@_la_LIBADD = libdricore-asm.la @@ -55,14 +55,20 @@ libdricore_asm_la_CCASFLAGS = $(AM_CCASFLAGS) -DWORKAROUND_AUTOMAKE_OBJ_FILE_CON if HAVE_X86_ASM libdricore_asm_la_SOURCES += $(X86_FILES) +libdricore_asm_la_CPPFLAGS = $(AM_CPPFLAGS) \ +-I$(top_builddir)/src/mesa/x86 endif if HAVE_X86_64_ASM libdricore_asm_la_SOURCES += $(X86_64_FILES) +libdricore_asm_la_CPPFLAGS = $(AM_CPPFLAGS) \ +-I$(top_builddir)/src/mesa/x86-64 endif if HAVE_SPARC_ASM libdricore_asm_la_SOURCES += $(SPARC_FILES) +libdricore_asm_la_CPPFLAGS = $(AM_CPPFLAGS) \ +-I$(top_builddir)/src/mesa/sparc endif if HAVE_DRICORE -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] wider registers in llvmpipe
On Wed, Jul 18, 2012 at 1:58 AM, Roland Scheidegger wrote: > Am 17.07.2012 23:49, schrieb Stéphane Marchesin: >> On Mon, Jul 16, 2012 at 11:43 AM, Jose Fonseca wrote: >>> FYI, I've just pushed a branch named llvmpipe-wider-regs, which allows >>> llvmpipe to leverage SIMD registers wider than 128bits. >>> >>> Unfortunately, performance-wise this doesn't change much, as llvmpipe >>> performance is dominated by integer SIMD instructions, whereas currently >>> the AVX instruction set currently only supports floating SIMD instructions. >>> Actually, often things will get slightly slower, as there are considerable >>> overheads in piecing together the 256 floating point code paths and 128-bit >>> integer code paths. >>> >>> The benefit for this change is foremost architectural: llvmpipe now makes >>> less assumptions regarding the number of pixels/quads/etc that fit into a >>> hardware register, a flexibility which will be necessary to get things like >>> per-pixel LOD working properly. >>> >>> This barely touch files outside gallivm/draw/llvmpipe modules. I haven't >>> tested i915g, r300g, so let me know if there are regressions / concerns. >>> I'd like to merge this into master soon. >> >> >> It regresses the following on i915g (and I suspect it will regress on >> llvmpipe also): >> draw-vertices pass -> abort >> draw-vertices-half-float pass -> crash >> draw-vertices-half-float-user pass -> crash >> draw-vertices-user pass -> abort >> >> The machine in question doesn't have AVX (or llvm 3.1 for that matter). > > > I've tested this with both llvm 3.1 and 2.9, with and without avx and > draw-vertices and draw-vertices-half-float always pass with llvmpipe. > I don't see the other two tests (draw-vertices-half-float-user and > draw-vertices-user) in piglit. Those are the same tests but with the first parameter being "user". The test names in all.tests do not necessarily have to match the executable filenames. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
