[Mesa-dev] [Bug 44519] SIGABRT src/gallium/tests/unit/translate_test.c:250
https://bugs.freedesktop.org/show_bug.cgi?id=44519 --- Comment #2 from Vinson Lee v...@freedesktop.org 2012-06-04 23:40:13 PDT --- mesa: 555e00fdc30514b45e9afae18f56a9a4bc65f364 The translate_test unit test is still failing. -- 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 00/25] i915 HW context support
On 06/04/2012 10:53 PM, Dave Airlie wrote: I've run these on various workloads and saw nothing worth mentioning. Nothing at all? no speedups, slowdowns, etc why should we merge all this code then :-) Dave. Preserving hardware state across batches is going to be necessary for: * Transform feedback in the presence of geometry shaders Right now, Mesa counts the number of primitives emitted on the CPU, relies on the kernel resetting the register to 0, and offset values in software. With GS, we obviously can't count primitives on the CPU. * Primitive restart in hardware and seems to be increasingly necessary for new features as we move forward. So we'd like to get it in place; we can cut more state uploads and tune Mesa further once it's there. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Add GL_TEXTURE_CUBE_MAP to _mesa_max_texture_levels().
For cube maps, _mesa_generate_mipmap() calls this with
GL_TEXTURE_CUBE_MAP_ARB (the gl_texture_object's Target) rather than one
of the faces. This caused _mesa_max_texture_levels() to return 0, which
resulted in maxLevels == -1 and the next line's assertion to fail.
This function is called from several places. It looks like texstorage.c
also wants this enum to be handled, while most callers don't care.
TexImage, CompressedTexImage, FramebufferTexture, and GetTexImage
already appear to filter out illegal targets, so they should be fine.
However, GetTexLevelParameter does rely on this function for filtering
out invalid targets, and does not accept GL_TEXTURE_CUBE_MAP. Special
case this, since it apparently supports every other target.
+2 oglconforms (float-texture/mipmap.automatic and mipmap.manual)
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/main/teximage.c |1 +
src/mesa/main/texparam.c |2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 694f6fa..e5f804c 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -936,6 +936,7 @@ _mesa_max_texture_levels(struct gl_context *ctx, GLenum
target)
case GL_TEXTURE_3D:
case GL_PROXY_TEXTURE_3D:
return ctx-Const.Max3DTextureLevels;
+ case GL_TEXTURE_CUBE_MAP:
case GL_TEXTURE_CUBE_MAP_POSITIVE_X_ARB:
case GL_TEXTURE_CUBE_MAP_NEGATIVE_X_ARB:
case GL_TEXTURE_CUBE_MAP_POSITIVE_Y_ARB:
diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index 9abc503..a1aaecd 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -917,7 +917,7 @@ _mesa_GetTexLevelParameteriv( GLenum target, GLint level,
/* this will catch bad target values */
maxLevels = _mesa_max_texture_levels(ctx, target);
- if (maxLevels == 0) {
+ if (maxLevels == 0 || target == GL_TEXTURE_CUBE_MAP) {
_mesa_error(ctx, GL_INVALID_ENUM,
glGetTexLevelParameter[if]v(target=0x%x), target);
return;
--
1.7.10.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] mesa intel driver:
Thanks Paul, Thanks Ian as well for the comments on it.
I will update internal_format to GL_YCBCR_MESA.
(I didn't notice glext.h before, but gl2.h only)
As to the error in intel_image_target_texture_2d(), it isn't caused by wrong
internal format, but hw limitation since we don't support packed YUV as texture.
-Original Message-
From: Pauli Nieminen [mailto:pauli.niemi...@linux.intel.com]
Sent: Monday, June 04, 2012 9:11 PM
To: Zhao, Halley
Cc: Eric Anholt; mesa-dev@lists.freedesktop.org; Barnes, Jesse
Subject: Re: [Mesa-dev] [PATCH 2/6] mesa intel driver:
On Mon, Jun 04, 2012 at 10:00:47AM +, Zhao, Halley wrote:
Thanks for careful review.
1. My mistake for the s, we can remove it.
There is MESA_FORMAT_YCBCR_REV for UYVY, so
MESA_FORMAT_YCBCR is exactly for YUYV format.
GL_LUMINANCE should be ok since YUYV is an luminance format.
internal_format should be GL_YCBCR_MESA that is supposed to be working
texture format with GL.
2. as to intel_image_target_texture_2d(), an error is added for YUYV region.
Updated patch see below.
Could it be because of wrong internal format?
3. A test case is added to demonstrate the usage:
http://lists.freedesktop.org/archives/mesa-dev/2012-June/022487.html
As to the case when hw overlay is not available, it is considered in
following way:
3.1) when client connect to wayland-server, it gets which formats are
supported from server in drm_handle_format(). Client sends YUYV buffer to
server only when the server supports it.
Client can convert a YUYV/NV12 buffer to XRGB format through
libva:
http://lists.freedesktop.org/archives/libva/2012-May/000845.html
(YUYV--NV12/YV12 are supported)
3.2) if Weston want to support YUYV internally, it can depend on libva's
color conversion or some special shader to do it.
From 5356270a25a300bbe7e0d36a79b031d2fb108a88 Mon Sep 17 00:00:00
2001
From: Zhao halley halley.z...@intel.com
Date: Fri, 25 May 2012 11:36:48 +0800
Subject: [PATCH 2/7] mesa intel driver:
add YUYV format for dri image
YUYV image doesn't use for texture
---
src/mesa/drivers/dri/intel/intel_screen.c|5 +
src/mesa/drivers/dri/intel/intel_tex_image.c |6 ++
2 files changed, 11 insertions(+), 0 deletions(-) mode change 100644
= 100755 src/mesa/drivers/dri/intel/intel_screen.c
mode change 100644 = 100755
src/mesa/drivers/dri/intel/intel_tex_image.c
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
old mode 100644
new mode 100755
index 458178f..b8d44ba
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -216,6 +216,11 @@ intel_create_image_from_name(__DRIscreen
*screen,
image-internal_format = GL_RGB;
image-data_type = GL_UNSIGNED_BYTE;
break;
+case __DRI_IMAGE_FORMAT_YUYV:
+ image-format = MESA_FORMAT_YCBCR;
+ image-internal_format = GL_LUMINANCE;
+ image-data_type = GL_UNSIGNED_BYTE;
+ break;
default:
free(image);
return NULL;
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
b/src/mesa/drivers/dri/intel/intel_tex_image.c
old mode 100644
new mode 100755
index 094d3cd..8b94cb1
--- a/src/mesa/drivers/dri/intel/intel_tex_image.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_image.c
@@ -388,6 +388,12 @@ intel_image_target_texture_2d(struct gl_context
*ctx, GLenum target,
if (image == NULL)
return;
+ if (image-format == MESA_FORMAT_YCBCR) {
+ _mesa_error(intel-ctx,
+ GL_INVALID_OPERATION, glEGLImageTargetTexture2DOES,
attach YUYV region to texture is not supported);
+ return;
+}
+
intel_set_texture_image_region(ctx, texImage, image-region,
target, image-internal_format,
image-format); }
--
1.7.5.4
-Original Message-
From: Eric Anholt [mailto:e...@anholt.net]
Sent: Saturday, June 02, 2012 5:33 AM
To: Zhao, Halley; mesa-dev@lists.freedesktop.org
Cc: Barnes, Jesse; Zhao, Halley
Subject: Re: [PATCH 2/6] mesa intel driver:
On Thu, 31 May 2012 17:23:59 +0800, Zhao halley
halley.z...@intel.com
wrote:
add YUYV format for dri image
YUYV image doesn't use for texture
---
src/mesa/drivers/dri/intel/intel_screen.c|5 +
src/mesa/drivers/dri/intel/intel_tex_image.c |3 +++
2 files changed, 8 insertions(+), 0 deletions(-) mode change
100644 = 100755 src/mesa/drivers/dri/intel/intel_screen.c
mode change 100644 = 100755
src/mesa/drivers/dri/intel/intel_tex_image.c
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
old mode 100644
new mode 100755
index 458178f..5ff2e49
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++
Re: [Mesa-dev] [PATCH] add test for wayland drm, XRGB/YUYV is supported
Hi Pauli: Thanks for your suggestion. gbm doesn't support: - Buffer name which is used by wayland-drm protocol (since buffer is shared across processes) - tiling (overlay required I915_TILING_X, though intel 3D use TILING_X as default, media pipeline uses TILING_Y as default) - buffer update: intel_image_write() (only cursor image is supported now) anyway, I will update gbm/intel-driver to fill the above gaps, and make the test case basing on gbm. -Original Message- From: Pauli Nieminen [mailto:pauli.niemi...@linux.intel.com] Sent: Monday, June 04, 2012 8:55 PM To: Zhao, Halley Cc: mesa-dev@lists.freedesktop.org; Barnes, Jesse Subject: Re: [Mesa-dev] [PATCH] add test for wayland drm, XRGB/YUYV is supported This test is using intel specific interfaces. Is there something missing from libgbm that prevents you from using it? In any case I think this test should be using gdm for memory management. see src/gbm/main/gbm.h On Mon, Jun 04, 2012 at 09:43:06AM +, Zhao, Halley wrote: Move the test case to $mesa/test/wayland-drm. From f8843a118e9d7f41b5acedcb396c82adae36841d Mon Sep 17 00:00:00 2001 From: Zhao halley halley.z...@intel.com Date: Mon, 4 Jun 2012 15:58:24 +0800 Subject: [PATCH] add test for wayland drm, XRGB/YUYV is supported when I sent patches for YUYV support of dri image, a test case is required to make sure the patches can work well. so it is created. it also shows how wayland-drm protocol works between wayland client and server -- they communicate data in buffer/drm level. --- configure.ac |4 +- src/egl/wayland/Makefile.am |2 +- tests/Makefile.am|2 +- tests/wayland-drm/Makefile.am| 12 + tests/wayland-drm/wayland-drm-test.c | 462 ++ 5 files changed, 479 insertions(+), 3 deletions(-) create mode 100644 tests/wayland-drm/Makefile.am create mode 100644 tests/wayland-drm/wayland-drm-test.c diff --git a/configure.ac b/configure.ac index 3bc59ca..58c05bc 100644 --- a/configure.ac +++ b/configure.ac @@ -2033,7 +2033,9 @@ AC_CONFIG_FILES([configs/autoconf src/mesa/drivers/dri/radeon/Makefile src/mesa/drivers/dri/swrast/Makefile tests/Makefile - tests/glx/Makefile]) + tests/glx/Makefile + tests/wayland-drm/Makefile +]) dnl Replace the configs/current symlink AC_CONFIG_COMMANDS([configs],[ diff --git a/src/egl/wayland/Makefile.am b/src/egl/wayland/Makefile.am index ca7207c..526d64f 100644 --- a/src/egl/wayland/Makefile.am +++ b/src/egl/wayland/Makefile.am @@ -1 +1 @@ -SUBDIRS = wayland-drm wayland-egl +SUBDIRS = wayland-drm wayland-egl diff --git a/tests/Makefile.am b/tests/Makefile.am index 4079bb9..f6125f1 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -1 +1 @@ -SUBDIRS=glx +SUBDIRS=glx wayland-drm diff --git a/tests/wayland-drm/Makefile.am b/tests/wayland-drm/Makefile.am new file mode 100644 index 000..526acde --- /dev/null +++ b/tests/wayland-drm/Makefile.am @@ -0,0 +1,12 @@ +bin_PROGRAMS = wayland_drm_test +wayland_drm_test_CFLAGS = -I$(top_srcdir)/src/egl/main \ + -I$(top_srcdir)/include \ + $(DEFINES) \ + $(WAYLAND_CFLAGS) \ + $(LIBDRM_CFLAGS) + +wayland_drm_test_LDADD = $(WAYLAND_LIBS) $(LIBDRM_LIBS) -ldrm_intel +wayland_drm_test_LDADD += $(top_srcdir)/src/egl/main/libEGL.la + +wayland_drm_test_SOURCES = wayland-drm-test.c \ + +$(top_srcdir)/src/egl/wayland/wayland-drm//wayland-drm-client-protoco +l.h diff --git a/tests/wayland-drm/wayland-drm-test.c b/tests/wayland-drm/wayland-drm-test.c new file mode 100644 index 000..ea2e230 --- /dev/null +++ b/tests/wayland-drm/wayland-drm-test.c @@ -0,0 +1,462 @@ +/* + * Copyright (c) 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, + *
[Mesa-dev] [PATCH 0/9 v2] Add YUYV format support of dri image
Intel SNB/IVB platform supports rendering YUYV buffer to overlay plane, however YUYV is missing support from mesa/dri-image yet. so I go ahead to add it; basing on it, libva can send YUYV buffer directly to wayland/weston, then weston output it to overlay plane. I notice that there are some patches from Gwenole for YUV planar texture support. these patches have little to do with that. because: YUYV is packed format, it doesn't require additional attribute like buffer layout (introduced by Gwenole) YUYV is introduced for overlay support, no shaders for texture is required. update: - set internal_format to GL_YCBCR_MESA - improve gbm/intel-driver to support YUYV bo generation, add handle2 (intel buffer name) in gbm buffer data update (intel_image_write with tiling support) - update test case to depend on gbm instead of intel driver directly Zhao Halley (9): GL: add YUYV to dri image format mesa intel driver: egl wayland: add YUYV support gallium egl wayland: add YUYV support gbm dri backend: add YUYV support wayland-drm: add YUYV support gbm: add handle2(buffer region name) intel driver: add tiling support for intel_image_write() all drm image are supported for write test: test case for wayland-drm in tests/wayland-drm configure.ac |4 +- include/GL/internal/dri_interface.h|1 + src/egl/drivers/dri2/egl_dri2.c| 17 +- src/egl/drivers/dri2/platform_wayland.c|8 +- src/egl/wayland/wayland-drm/wayland-drm.c |3 + .../state_trackers/egl/wayland/native_drm.c|3 + .../state_trackers/egl/wayland/native_wayland.h|3 +- src/gbm/backends/dri/gbm_dri.c | 12 +- src/gbm/main/gbm.c | 14 + src/gbm/main/gbm.h |3 + src/gbm/main/gbmint.h |1 + src/mesa/drivers/dri/intel/intel_screen.c | 27 ++- src/mesa/drivers/dri/intel/intel_tex_image.c |6 + tests/Makefile.am |2 +- tests/wayland-drm/Makefile.am | 12 + tests/wayland-drm/wayland-drm-test.c | 456 16 files changed, 562 insertions(+), 10 deletions(-) mode change 100644 = 100755 configure.ac mode change 100644 = 100755 include/GL/internal/dri_interface.h mode change 100644 = 100755 src/egl/drivers/dri2/egl_dri2.c mode change 100644 = 100755 src/egl/drivers/dri2/platform_wayland.c mode change 100644 = 100755 src/egl/wayland/wayland-drm/wayland-drm.c mode change 100644 = 100755 src/gallium/state_trackers/egl/wayland/native_drm.c mode change 100644 = 100755 src/gallium/state_trackers/egl/wayland/native_wayland.h 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 mode change 100644 = 100755 src/mesa/drivers/dri/intel/intel_screen.c mode change 100644 = 100755 src/mesa/drivers/dri/intel/intel_tex_image.c mode change 100644 = 100755 tests/Makefile.am create mode 100755 tests/wayland-drm/Makefile.am create mode 100755 tests/wayland-drm/wayland-drm-test.c -- 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/9 v2] GL: add YUYV to dri image format
---
include/GL/internal/dri_interface.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
mode change 100644 = 100755 include/GL/internal/dri_interface.h
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
old mode 100644
new mode 100755
index e37917e..5e325cf
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -907,6 +907,7 @@ struct __DRIdri2ExtensionRec {
#define __DRI_IMAGE_FORMAT_ARGB 0x1003
#define __DRI_IMAGE_FORMAT_ABGR 0x1004
#define __DRI_IMAGE_FORMAT_XBGR 0x1005
+#define __DRI_IMAGE_FORMAT_YUYV 0x1006
#define __DRI_IMAGE_USE_SHARE 0x0001
#define __DRI_IMAGE_USE_SCANOUT0x0002
--
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/9 v2] mesa intel driver:
add YUYV format for dri image
YUYV image doesn't use for texture
---
src/mesa/drivers/dri/intel/intel_screen.c| 10 ++
src/mesa/drivers/dri/intel/intel_tex_image.c |6 ++
2 files changed, 16 insertions(+), 0 deletions(-)
mode change 100644 = 100755 src/mesa/drivers/dri/intel/intel_screen.c
mode change 100644 = 100755 src/mesa/drivers/dri/intel/intel_tex_image.c
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
old mode 100644
new mode 100755
index 458178f..3b8f81e
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -216,6 +216,11 @@ intel_create_image_from_name(__DRIscreen *screen,
image-internal_format = GL_RGB;
image-data_type = GL_UNSIGNED_BYTE;
break;
+case __DRI_IMAGE_FORMAT_YUYV:
+ image-format = MESA_FORMAT_YCBCR;
+ image-internal_format = GL_YCBCR_MESA;
+ image-data_type = GL_UNSIGNED_BYTE;
+ break;
default:
free(image);
return NULL;
@@ -343,6 +348,11 @@ intel_create_image(__DRIscreen *screen,
image-internal_format = GL_RGB;
image-data_type = GL_UNSIGNED_BYTE;
break;
+ case __DRI_IMAGE_FORMAT_YUYV:
+ image-format = MESA_FORMAT_YCBCR;
+ image-internal_format = GL_YCBCR_MESA;
+ image-data_type = GL_UNSIGNED_BYTE;
+ break;
default:
free(image);
return NULL;
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
b/src/mesa/drivers/dri/intel/intel_tex_image.c
old mode 100644
new mode 100755
index 094d3cd..8b94cb1
--- a/src/mesa/drivers/dri/intel/intel_tex_image.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_image.c
@@ -388,6 +388,12 @@ intel_image_target_texture_2d(struct gl_context *ctx,
GLenum target,
if (image == NULL)
return;
+ if (image-format == MESA_FORMAT_YCBCR) {
+ _mesa_error(intel-ctx,
+ GL_INVALID_OPERATION, glEGLImageTargetTexture2DOES, attach
YUYV region to texture is not supported);
+ return;
+}
+
intel_set_texture_image_region(ctx, texImage, image-region,
target, image-internal_format,
image-format);
}
--
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/9 v2] egl wayland: add YUYV support
---
src/egl/drivers/dri2/egl_dri2.c | 17 ++---
src/egl/drivers/dri2/platform_wayland.c |8 +++-
2 files changed, 21 insertions(+), 4 deletions(-)
mode change 100644 = 100755 src/egl/drivers/dri2/egl_dri2.c
mode change 100644 = 100755 src/egl/drivers/dri2/platform_wayland.c
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
old mode 100644
new mode 100755
index 4a02838..a058046
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1096,9 +1096,15 @@ dri2_create_image_wayland_wl_buffer(_EGLDisplay *disp,
_EGLContext *ctx,
switch (wayland_drm_buffer_get_format(buffer)) {
case WL_DRM_FORMAT_ARGB:
format = __DRI_IMAGE_FORMAT_ARGB;
+ pitch = stride / 4;
break;
case WL_DRM_FORMAT_XRGB:
format = __DRI_IMAGE_FORMAT_XRGB;
+ pitch = stride / 4;
+ break;
+ case WL_DRM_FORMAT_YUYV:
+ format = __DRI_IMAGE_FORMAT_YUYV;
+ pitch = stride / 2;
break;
default:
_eglError(EGL_BAD_PARAMETER,
@@ -1106,8 +1112,6 @@ dri2_create_image_wayland_wl_buffer(_EGLDisplay *disp,
_EGLContext *ctx,
return NULL;
}
- pitch = stride / 4;
-
return dri2_create_image_drm_name(disp, ctx, name, attrs, format, pitch);
}
#endif
@@ -1270,21 +1274,28 @@ dri2_wl_reference_buffer(void *user_data, uint32_t name,
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
__DRIimage *image;
int dri_format;
+ int pitch = 0;
switch (format) {
case WL_DRM_FORMAT_ARGB:
dri_format =__DRI_IMAGE_FORMAT_ARGB;
+ pitch = stride/4;
break;
case WL_DRM_FORMAT_XRGB:
dri_format = __DRI_IMAGE_FORMAT_XRGB;
+ pitch = stride/4;
break;
+ case WL_DRM_FORMAT_YUYV:
+ dri_format = __DRI_IMAGE_FORMAT_YUYV;
+ pitch = stride/2;
+ break;
default:
return NULL;
}
image = dri2_dpy-image-createImageFromName(dri2_dpy-dri_screen,
width, height,
- dri_format, name, stride / 4,
+ dri_format, name, pitch,
NULL);
return image;
diff --git a/src/egl/drivers/dri2/platform_wayland.c
b/src/egl/drivers/dri2/platform_wayland.c
old mode 100644
new mode 100755
index d291f0f..6d330b7
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -42,7 +42,9 @@
enum wl_drm_format_flags {
HAS_ARGB = 1,
- HAS_XRGB = 2
+ HAS_XRGB = (1 1),
+ HAS_YUYV = (1 2)
+
};
static void
@@ -778,6 +780,9 @@ drm_handle_format(void *data, struct wl_drm *drm, uint32_t
format)
case WL_DRM_FORMAT_XRGB:
dri2_dpy-formats |= HAS_XRGB;
break;
+ case WL_DRM_FORMAT_YUYV:
+ dri2_dpy-formats |= HAS_YUYV;
+ break;
}
}
@@ -878,6 +883,7 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay *disp)
dri2_add_config(disp, config, i + 1, 0, types, NULL, rgb_masks);
if (dri2_dpy-formats HAS_ARGB)
dri2_add_config(disp, config, i + 1, 0, types, NULL, argb_masks);
+ // , should we do something for YUYV here?
}
disp-Extensions.KHR_image_pixmap = EGL_TRUE;
--
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/9 v2] gallium egl wayland: add YUYV support
---
.../state_trackers/egl/wayland/native_drm.c|3 +++
.../state_trackers/egl/wayland/native_wayland.h|3 ++-
2 files changed, 5 insertions(+), 1 deletions(-)
mode change 100644 = 100755
src/gallium/state_trackers/egl/wayland/native_drm.c
mode change 100644 = 100755
src/gallium/state_trackers/egl/wayland/native_wayland.h
diff --git a/src/gallium/state_trackers/egl/wayland/native_drm.c
b/src/gallium/state_trackers/egl/wayland/native_drm.c
old mode 100644
new mode 100755
index e3bd628..f2d2e74
--- a/src/gallium/state_trackers/egl/wayland/native_drm.c
+++ b/src/gallium/state_trackers/egl/wayland/native_drm.c
@@ -164,6 +164,9 @@ drm_handle_format(void *data, struct wl_drm *drm, uint32_t
format)
case WL_DRM_FORMAT_XRGB:
drmdpy-base.formats |= HAS_XRGB;
break;
+ case WL_DRM_FORMAT_YUYV:
+ drmdpy-base.formats |= HAS_YUYV;
+ break;
}
}
diff --git a/src/gallium/state_trackers/egl/wayland/native_wayland.h
b/src/gallium/state_trackers/egl/wayland/native_wayland.h
old mode 100644
new mode 100755
index e6a914f..bd26bf0
--- a/src/gallium/state_trackers/egl/wayland/native_wayland.h
+++ b/src/gallium/state_trackers/egl/wayland/native_wayland.h
@@ -38,7 +38,8 @@ struct wayland_surface;
enum wayland_format_flag {
HAS_ARGB= (1 0),
- HAS_XRGB= (1 1)
+ HAS_XRGB= (1 1),
+ HAS_YUYV= (1 2)
};
struct wayland_display {
--
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/9 v2] gbm dri backend: add YUYV support
--- src/gbm/backends/dri/gbm_dri.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) mode change 100644 = 100755 src/gbm/backends/dri/gbm_dri.c 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 e5ddfb6..32cde66 --- a/src/gbm/backends/dri/gbm_dri.c +++ b/src/gbm/backends/dri/gbm_dri.c @@ -331,6 +331,9 @@ gbm_dri_to_gbm_format(uint32_t dri_format) case __DRI_IMAGE_FORMAT_ABGR: ret = GBM_FORMAT_ABGR; break; + case __DRI_IMAGE_FORMAT_YUYV: + ret = GBM_FORMAT_YUYV; + break; default: ret = 0; break; @@ -428,6 +431,9 @@ gbm_dri_bo_create(struct gbm_device *gbm, case GBM_FORMAT_ABGR: dri_format = __DRI_IMAGE_FORMAT_ABGR; break; + case GBM_FORMAT_YUYV: + dri_format = __DRI_IMAGE_FORMAT_YUYV; + break; default: return NULL; } -- 1.7.5.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/9 v2] wayland-drm: add YUYV support
---
src/egl/wayland/wayland-drm/wayland-drm.c |3 +++
1 files changed, 3 insertions(+), 0 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 5f831b3..d9cfe09
--- a/src/egl/wayland/wayland-drm/wayland-drm.c
+++ b/src/egl/wayland/wayland-drm/wayland-drm.c
@@ -111,6 +111,7 @@ drm_create_buffer(struct wl_client *client, struct
wl_resource *resource,
switch (format) {
case WL_DRM_FORMAT_ARGB:
case WL_DRM_FORMAT_XRGB:
+case WL_DRM_FORMAT_YUYV:
break;
default:
wl_resource_post_error(resource,
@@ -186,6 +187,8 @@ bind_drm(struct wl_client *client, void *data, uint32_t
version, uint32_t id)
WL_DRM_FORMAT_ARGB);
wl_resource_post_event(resource, WL_DRM_FORMAT,
WL_DRM_FORMAT_XRGB);
+ wl_resource_post_event(resource, WL_DRM_FORMAT,
+ WL_DRM_FORMAT_YUYV);
}
struct wl_drm *
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/9 v2] gbm: add handle2(buffer region name)
---
src/gbm/backends/dri/gbm_dri.c |6 +-
src/gbm/main/gbm.c | 14 ++
src/gbm/main/gbm.h |3 +++
src/gbm/main/gbmint.h |1 +
4 files changed, 23 insertions(+), 1 deletions(-)
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
index 32cde66..383a5a5 100755
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -389,6 +389,8 @@ gbm_dri_bo_create_from_egl_image(struct gbm_device *gbm,
(int *) bo-base.base.pitch);
dri-image-queryImage(bo-image, __DRI_IMAGE_ATTRIB_FORMAT,
dri_format);
+ dri-image-queryImage(bo-image, __DRI_IMAGE_ATTRIB_NAME,
+ (uint32_t *) bo-base.base.handle2.u32);
bo-base.base.format = gbm_dri_to_gbm_format(dri_format);
@@ -457,7 +459,9 @@ gbm_dri_bo_create(struct gbm_device *gbm,
bo-base.base.handle.s32);
dri-image-queryImage(bo-image, __DRI_IMAGE_ATTRIB_STRIDE,
(int *) bo-base.base.pitch);
-
+ dri-image-queryImage(bo-image, __DRI_IMAGE_ATTRIB_NAME,
+ (uint32_t *) bo-base.base.handle2.u32);
+
return bo-base.base;
}
diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
old mode 100644
new mode 100755
index 3994f86..f445bb1
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -231,6 +231,20 @@ gbm_bo_get_handle(struct gbm_bo *bo)
return bo-handle;
}
+/** Get handle2 (buffer region name) of the buffer object
+ *
+ * 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_handle2(struct gbm_bo *bo)
+{
+ return bo-handle2;
+}
+
/** 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 af5dc5a..b7a2ffa
--- a/src/gbm/main/gbm.h
+++ b/src/gbm/main/gbm.h
@@ -254,6 +254,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_handle2(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 8eb8671..5e48e89
--- a/src/gbm/main/gbmint.h
+++ b/src/gbm/main/gbmint.h
@@ -95,6 +95,7 @@ struct gbm_bo {
uint32_t pitch;
uint32_t format;
union gbm_bo_handle handle;
+ union gbm_bo_handle handle2;
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 8/9 v2] intel driver: add tiling support for intel_image_write() all drm image are supported for write
--- 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 3b8f81e..63b6b24 100755 --- a/src/mesa/drivers/dri/intel/intel_screen.c +++ b/src/mesa/drivers/dri/intel/intel_screen.c @@ -310,10 +310,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 = CALLOC(sizeof *image); if (image == NULL) @@ -441,9 +444,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 + dri_bo_map(image-region-bo, 1); + 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 + dri_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 9/9 v2] test: test case for wayland-drm in tests/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
---
configure.ac |4 +-
tests/Makefile.am|2 +-
tests/wayland-drm/Makefile.am| 12 +
tests/wayland-drm/wayland-drm-test.c | 456 ++
4 files changed, 472 insertions(+), 2 deletions(-)
mode change 100644 = 100755 configure.ac
mode change 100644 = 100755 tests/Makefile.am
create mode 100755 tests/wayland-drm/Makefile.am
create mode 100755 tests/wayland-drm/wayland-drm-test.c
diff --git a/configure.ac b/configure.ac
old mode 100644
new mode 100755
index 3bc59ca..58c05bc
--- a/configure.ac
+++ b/configure.ac
@@ -2033,7 +2033,9 @@ AC_CONFIG_FILES([configs/autoconf
src/mesa/drivers/dri/radeon/Makefile
src/mesa/drivers/dri/swrast/Makefile
tests/Makefile
- tests/glx/Makefile])
+ tests/glx/Makefile
+ tests/wayland-drm/Makefile
+])
dnl Replace the configs/current symlink
AC_CONFIG_COMMANDS([configs],[
diff --git a/tests/Makefile.am b/tests/Makefile.am
old mode 100644
new mode 100755
index 4079bb9..f6125f1
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -1 +1 @@
-SUBDIRS=glx
+SUBDIRS=glx wayland-drm
diff --git a/tests/wayland-drm/Makefile.am b/tests/wayland-drm/Makefile.am
new file mode 100755
index 000..7673368
--- /dev/null
+++ b/tests/wayland-drm/Makefile.am
@@ -0,0 +1,12 @@
+bin_PROGRAMS = wayland_drm_test
+wayland_drm_test_CFLAGS = -I$(top_srcdir)/src/egl/main \
+ -I$(top_srcdir)/include \
+ $(DEFINES) \
+ $(WAYLAND_CFLAGS) \
+ $(LIBDRM_CFLAGS)
+
+wayland_drm_test_LDADD = $(WAYLAND_LIBS) $(LIBDRM_LIBS)
+wayland_drm_test_LDADD += $(top_srcdir)/src/egl/main/libEGL.la
$(top_srcdir)/src/gbm/libgbm.la
+
+wayland_drm_test_SOURCES = wayland-drm-test.c \
+
$(top_srcdir)/src/egl/wayland/wayland-drm//wayland-drm-client-protocol.h
diff --git a/tests/wayland-drm/wayland-drm-test.c
b/tests/wayland-drm/wayland-drm-test.c
new file mode 100755
index 000..aa6f001
--- /dev/null
+++ b/tests/wayland-drm/wayland-drm-test.c
@@ -0,0 +1,456 @@
+/*
+ * 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 halley.z...@intel.com
+ */
+
+
+#include stdlib.h
+#include unistd.h
+#include errno.h
+#include fcntl.h
+#include sys/stat.h
+#include string.h
+#include assert.h
+#include xf86drm.h
+#include i915_drm.h
+#include libdrm/intel_bufmgr.h
+#include drm.h
+#include ../../src/gbm/main/gbm.h
+#include wayland-client.h
+#include wayland-client-protocol.h
+#include ../../src/egl/wayland/wayland-drm/wayland-drm-client-protocol.h
+
+int win_width = 1024, win_height = 512;
+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_pitch;
+};
+
+void fill_window_XRGB(struct window *win);
+void fill_window_YUYV(struct window *win);
+int wayland_drm_init(struct wl_display *wl_dpy);
+
+void fill_window_XRGB(struct window *win)
+{
+unsigned char *mem = malloc (win-bo_pitch * win_height);
+static int color_index = 0;
+static unsigned int
[Mesa-dev] ARB_RGB10_A2UI support
Hi all: Is anyone has a demo about GL_ARB_texture_rgb10_a2ui ? BR thanks! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] xmlconfig: use __progname when building for Android
__progname symbol and strrchr are available with bionic.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/drivers/dri/common/xmlconfig.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/common/xmlconfig.c
b/src/mesa/drivers/dri/common/xmlconfig.c
index 6d1d5ec..039e98a 100644
--- a/src/mesa/drivers/dri/common/xmlconfig.c
+++ b/src/mesa/drivers/dri/common/xmlconfig.c
@@ -86,7 +86,7 @@ static const char *__getProgramName () {
#endif
#if !defined(GET_PROGRAM_NAME)
-#if defined(__OpenBSD__) || defined(NetBSD) || defined(__UCLIBC__)
+#if defined(__OpenBSD__) || defined(NetBSD) || defined(__UCLIBC__) ||
defined(ANDROID)
/* This is a hack. It's said to work on OpenBSD, NetBSD and GNU.
* Rogelio M.Serrano Jr. reported it's also working with UCLIBC. It's
* used as a last resort, if there is no documented facility available. */
--
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] mesa: Add GL_TEXTURE_CUBE_MAP to _mesa_max_texture_levels().
On 06/05/2012 01:16 AM, Kenneth Graunke wrote: For cube maps, _mesa_generate_mipmap() calls this with GL_TEXTURE_CUBE_MAP_ARB (the gl_texture_object's Target) rather than one of the faces. This caused _mesa_max_texture_levels() to return 0, which resulted in maxLevels == -1 and the next line's assertion to fail. This function is called from several places. It looks like texstorage.c also wants this enum to be handled, while most callers don't care. TexImage, CompressedTexImage, FramebufferTexture, and GetTexImage already appear to filter out illegal targets, so they should be fine. However, GetTexLevelParameter does rely on this function for filtering out invalid targets, and does not accept GL_TEXTURE_CUBE_MAP. Special case this, since it apparently supports every other target. I think glGet[Compressed]TexImage() needs the special case too. For example, getteximage_error_check() also uses max levels to error check the target. It might be good to beef-up the comment on _mesa_max_texture_levels() to clarify that the function is also used to error-check 'target' in various places and some care should be taken when adding support for new targets (GL_TEXTURE_CUBE_MAP_ARRAY someday). -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Is the pure-make build system still supported?
On 06/04/2012 12:29 PM, Brian Paul wrote: On 06/01/2012 12:55 PM, Brad King wrote: However, I still get the above undefined symbols on x86_64 when linking to the resulting GL library. The patch below (also in my previous post) solves it. It seems configs/* is still in use even by the autotools system. Hmmm, I don't quite see how the linux-x86-64 file is getting pulled in. The files under configs/ will be gone soon. Okay, I can patch it locally until then. However, please consider the main patch I posted in this thread to allow the (GL|GLU|OSMESA)_LIB names to be changed at configuration time with autotools. Thanks, -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 50604] [compile error] ../../../../../src/mesa/libdricore/../main/api_arrayelt.c:45:27: fatal error: main/dispatch.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=50604 --- Comment #2 from Fabio Pedretti fabio@libero.it 2012-06-05 07:21:43 PDT --- I tried doing a non parallel build but I get the same error: https://launchpadlibrarian.net/106916928/buildlog_ubuntu-precise-i386.mesa_8.1~git1206051530.555e00~gd~p_FAILEDTOBUILD.txt.gz -- 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] Is the pure-make build system still supported?
On 06/05/2012 08:07 AM, Brad King wrote: On 06/04/2012 12:29 PM, Brian Paul wrote: On 06/01/2012 12:55 PM, Brad King wrote: However, I still get the above undefined symbols on x86_64 when linking to the resulting GL library. The patch below (also in my previous post) solves it. It seems configs/* is still in use even by the autotools system. Hmmm, I don't quite see how the linux-x86-64 file is getting pulled in. The files under configs/ will be gone soon. Okay, I can patch it locally until then. However, please consider the main patch I posted in this thread to allow the (GL|GLU|OSMESA)_LIB names to be changed at configuration time with autotools. I'm an automake novice so I'm leaving it up to others to review such patches. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] automake: Honor (GL|GLU|OSMESA)_LIB from environment
On 6/4/12, Brad King brad.k...@kitware.com wrote:
On 06/01/2012 05:49 PM, Dan Nicholson wrote:
+AC_ARG_VAR([GL_LIB],[name of GL library @:@default=GL@:@])
+AC_ARG_VAR([GLU_LIB],[name of GLU library @:@default=GLU@:@])
+AC_ARG_VAR([OSMESA_LIB],[name of OSMesa library
@:@default=OSMesa@:@])
+GL_LIB=${GL_LIB-GL}
+GLU_LIB=${GLU_LIB-GLU}
+OSMESA_LIB=${OSMESA_LIB-OSMesa}
I don't think this part is necessary. AC_ARG_VAR does this already. The
rest makes sense though.
Thanks for taking a look. I think the init lines are needed in
order to set the default values. With the patch below on top of
this one I get output
GL_LIB=
GLU_LIB=
OSMESA_LIB=
and the build fails. I see no mention in AC_ARG_VAR documentation
about default value selection:
http://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Setting-Output-Variables.html#index-AC_005fARG_005fVAR-1134
Duh, you're right. I think this original patch is good to go. The
variables should be substituted in configs/autoconf and a quick grep
shows that there are no remaining hardcoded -lGL around (I think).
--
Dan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] automake: Honor (GL|GLU|OSMESA)_LIB from environment
On 06/05/2012 11:12 AM, Dan Nicholson wrote: Duh, you're right. I think this original patch is good to go. Great, thanks! a quick grep shows that there are no remaining hardcoded -lGL around (I think). I've built with a custom configs/current in the old pure-make system that sets GL_LIB for years, so I think $(GL_LIB) is used everywhere unless there is new autotools-specific code that hard-codes -lGL. -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/25] i915 HW context support
On Tue, 05 Jun 2012 00:08:10 -0700 Kenneth Graunke kenn...@whitecape.org wrote: On 06/04/2012 10:53 PM, Dave Airlie wrote: I've run these on various workloads and saw nothing worth mentioning. Nothing at all? no speedups, slowdowns, etc why should we merge all this code then :-) Dave. Preserving hardware state across batches is going to be necessary for: * Transform feedback in the presence of geometry shaders Right now, Mesa counts the number of primitives emitted on the CPU, relies on the kernel resetting the register to 0, and offset values in software. With GS, we obviously can't count primitives on the CPU. * Primitive restart in hardware and seems to be increasingly necessary for new features as we move forward. So we'd like to get it in place; we can cut more state uploads and tune Mesa further once it's there. Also, my testing was far from comprehensive. -- Ben Widawsky, Intel Open Source Technology Center ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] configure.ac: Fail if egl x11 platform dependencies are not available
On Sun, 3 Jun 2012 23:36:16 -0400, Kristian Høgsberg k...@bitplanet.net wrote: Currently, if you pass --with-egl-platforms=x11 but xcb-dri2 isn't available we just silently fail and disables building the EGL DRI2 driver. This commit cleans up the EGL platfrom checking and fails if a selected platform can't find its required dependencies. Signed-off-by: Kristian Høgsberg k...@bitplanet.net Reviewed-by: Eric Anholt e...@anholt.net pgpIXFb1ySnYj.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Add GL_TEXTURE_CUBE_MAP to _mesa_max_texture_levels().
On 06/05/2012 07:05 AM, Brian Paul wrote: On 06/05/2012 01:16 AM, Kenneth Graunke wrote: For cube maps, _mesa_generate_mipmap() calls this with GL_TEXTURE_CUBE_MAP_ARB (the gl_texture_object's Target) rather than one of the faces. This caused _mesa_max_texture_levels() to return 0, which resulted in maxLevels == -1 and the next line's assertion to fail. This function is called from several places. It looks like texstorage.c also wants this enum to be handled, while most callers don't care. TexImage, CompressedTexImage, FramebufferTexture, and GetTexImage already appear to filter out illegal targets, so they should be fine. However, GetTexLevelParameter does rely on this function for filtering out invalid targets, and does not accept GL_TEXTURE_CUBE_MAP. Special case this, since it apparently supports every other target. I think glGet[Compressed]TexImage() needs the special case too. For example, getteximage_error_check() also uses max levels to error check the target. It might be good to beef-up the comment on _mesa_max_texture_levels() to clarify that the function is also used to error-check 'target' in various places and some care should be taken when adding support for new targets (GL_TEXTURE_CUBE_MAP_ARRAY someday). -Brian You're right, I think I missed a few cases. I'm tempted to make more functions like legal_teximage_target() and convert the callers to use that for their checking rather than implicitly relying on _mesa_max_texture_levels(). It feels like we have one function doing target checking for many different API calls...not all of which necessarily support the same set of targets. Thoughts? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] automake: Honor (GL|GLU|OSMESA)_LIB from environment
On 06/01/2012 12:06 PM, Brad King wrote: Teach 'configure' to read the default GL_LIB, GLU_LIB, and OSMESA_LIB values from the environment. This allows one to mangle the library names (without also mangling the symbol names) to make them distinct from other GL libraries on the system. --- On 06/01/2012 10:06 AM, Brian Paul wrote: You should transition to using autoconf One feature I used in the pure-make build system was to create a custom configs/current to set GL_LIB, GLU_LIB, and OSMESA_LIB to have a Mesa prefix. This helps ensure that VTK both builds and runs against my nightly Mesa build regardless of what other GL libraries appear in the dynamic loader's search path. With this patch I can run $ GL_LIB=MesaGL GLU_LIB=MesaGLU OSMESA_LIB=MesaOSMesa ./autogen.sh ... to build with custom library names. Please review. Thanks, -Brad This looks good to me. The only real question I have is whether it makes sense to set them via environment variables, like you did, or whether it'd be better to use AC_ARG_WITH and do: ./autogen.sh --with-gl-lib-name=GL --with-glu-lib-name=GLU --with-osmesa-lib-name=OSMesa ... If people like the environment variables, this patch is Reviewed-by: Kenneth Graunke kenn...@whitecape.org and I'll be happy to push it upstream. Otherwise, it's a trivial change... Thoughts? Thanks for the patch and for bearing with us during the crazy automake transition :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965/fs: Fix texelFetchOffset() on pre-Gen7.
On Mon, 4 Jun 2012 14:15:10 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
Commit f41ecade7b458c02d504158b522acb2231585040 fixed texelFetchOffset()
on Ivybridge, but didn't update the Ironlake/Sandybridge code.
+15 piglits on Sandybridge.
NOTE: This and f41ecade7b458 are both candidates for stable branches.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 45
+++---
1 file changed, 33 insertions(+), 12 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 275a1f4..8d124a0 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -884,20 +884,41 @@ fs_visitor::emit_texture_gen5(ir_texture *ir, fs_reg
dst, fs_reg coordinate,
const int vector_elements =
ir-coordinate ? ir-coordinate-type-vector_elements : 0;
- if (ir-offset) {
- /* The offsets set up by the ir_texture visitor are in the
- * m1 header, so we can't go headerless.
+ if (ir-offset != NULL ir-op == ir_txf) {
+ /* It appears that the ld instruction used for txf does its
+ * address bounds check before adding in the offset. To work
+ * around this, just add the integer offset to the integer texel
+ * coordinate, and don't put the offset in the header.
*/
- header_present = true;
- mlen++;
- base_mrf--;
- }
+ int offsets[3];
+ ir_constant *offset = ir-offset-as_constant();
+ offsets[0] = offset-value.i[0];
+ offsets[1] = offset-value.i[1];
+ offsets[2] = offset-value.i[2];
No need for this temporary array (unlike in the fs where it was shared
with a non-offset path).
Other than that,
Reviewed-by: Eric Anholt e...@anholt.net
pgp2P0DAYKMFW.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure.ac: Add --with-(gl|glu|osmesa)-lib-name options
These allow one to mangle the library names, without also mangling the
symbol names, to make them distinct from other GL libraries on the
system.
---
On 06/05/2012 01:38 PM, Kenneth Graunke wrote:
This looks good to me. The only real question I have is whether it
makes sense to set them via environment variables, like you did, or
whether it'd be better to use AC_ARG_WITH and do:
./autogen.sh --with-gl-lib-name=GL --with-glu-lib-name=GLU
--with-osmesa-lib-name=OSMesa ...
That looks cleaner to me. Here is a patch for it.
Thanks,
-Brad
configure.ac | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index 9fb8149..e607d1c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -355,6 +355,24 @@ else
LIB_EXTENSION='so' ;;
esac
fi
+AC_ARG_WITH([gl-lib-name],
+ [AS_HELP_STRING([--with-gl-lib-name@:@=NAME@:@],
+[specify GL library name @:@default=GL@:@])],
+ [GL_LIB=$withval],
+ [GL_LIB=GL])
+AC_ARG_WITH([glu-lib-name],
+ [AS_HELP_STRING([--with-glu-lib-name@:@=NAME@:@],
+[specify GLU library name @:@default=GLU@:@])],
+ [GLU_LIB=$withval],
+ [GLU_LIB=GLU])
+AC_ARG_WITH([osmesa-lib-name],
+ [AS_HELP_STRING([--with-osmesa-lib-name@:@=NAME@:@],
+[specify OSMesa library name @:@default=OSMesa@:@])],
+ [OSMESA_LIB=$withval],
+ [OSMESA_LIB=OSMesa])
+AS_IF([test x$GL_LIB = xyes], [GL_LIB=GL])
+AS_IF([test x$GLU_LIB = xyes], [GLU_LIB=GLU])
+AS_IF([test x$OSMESA_LIB = xyes], [OSMESA_LIB=OSMesa])
dnl
dnl Mangled Mesa support
@@ -365,19 +383,16 @@ AC_ARG_ENABLE([mangling],
[enable_mangling=${enableval}],
[enable_mangling=no]
)
-GL_LIB=GL
-GLU_LIB=GLU
-OSMESA_LIB=OSMesa
if test x${enable_mangling} = xyes ; then
DEFINES=${DEFINES} -DUSE_MGL_NAMESPACE
- GL_LIB=MangledGL
- GLU_LIB=MangledGLU
- OSMESA_LIB=MangledOSMesa
+ GL_LIB=Mangled${GL_LIB}
+ GLU_LIB=Mangled${GLU_LIB}
+ OSMESA_LIB=Mangled${OSMESA_LIB}
fi
AC_SUBST([GL_LIB])
AC_SUBST([GLU_LIB])
AC_SUBST([OSMESA_LIB])
-AM_CONDITIONAL(HAVE_MANGLED_GL, test $GL_LIB = MangledGL)
+AM_CONDITIONAL(HAVE_MANGLED_GL, test x${enable_mangling} = xyes)
dnl
dnl potentially-infringing-but-nobody-knows-for-sure stuff
--
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: Add --with-(gl|glu|osmesa)-lib-name options
On 06/05/2012 10:59 AM, Brad King wrote:
These allow one to mangle the library names, without also mangling the
symbol names, to make them distinct from other GL libraries on the
system.
---
On 06/05/2012 01:38 PM, Kenneth Graunke wrote:
This looks good to me. The only real question I have is whether it
makes sense to set them via environment variables, like you did, or
whether it'd be better to use AC_ARG_WITH and do:
./autogen.sh --with-gl-lib-name=GL --with-glu-lib-name=GLU
--with-osmesa-lib-name=OSMesa ...
That looks cleaner to me. Here is a patch for it.
Thanks,
-Brad
configure.ac | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index 9fb8149..e607d1c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -355,6 +355,24 @@ else
LIB_EXTENSION='so' ;;
esac
fi
+AC_ARG_WITH([gl-lib-name],
+ [AS_HELP_STRING([--with-gl-lib-name@:@=NAME@:@],
+[specify GL library name @:@default=GL@:@])],
+ [GL_LIB=$withval],
+ [GL_LIB=GL])
+AC_ARG_WITH([glu-lib-name],
+ [AS_HELP_STRING([--with-glu-lib-name@:@=NAME@:@],
+[specify GLU library name @:@default=GLU@:@])],
+ [GLU_LIB=$withval],
+ [GLU_LIB=GLU])
+AC_ARG_WITH([osmesa-lib-name],
+ [AS_HELP_STRING([--with-osmesa-lib-name@:@=NAME@:@],
+[specify OSMesa library name @:@default=OSMesa@:@])],
+ [OSMESA_LIB=$withval],
+ [OSMESA_LIB=OSMesa])
+AS_IF([test x$GL_LIB = xyes], [GL_LIB=GL])
+AS_IF([test x$GLU_LIB = xyes], [GLU_LIB=GLU])
+AS_IF([test x$OSMESA_LIB = xyes], [OSMESA_LIB=OSMesa])
dnl
dnl Mangled Mesa support
@@ -365,19 +383,16 @@ AC_ARG_ENABLE([mangling],
[enable_mangling=${enableval}],
[enable_mangling=no]
)
-GL_LIB=GL
-GLU_LIB=GLU
-OSMESA_LIB=OSMesa
if test x${enable_mangling} = xyes ; then
DEFINES=${DEFINES} -DUSE_MGL_NAMESPACE
- GL_LIB=MangledGL
- GLU_LIB=MangledGLU
- OSMESA_LIB=MangledOSMesa
+ GL_LIB=Mangled${GL_LIB}
+ GLU_LIB=Mangled${GLU_LIB}
+ OSMESA_LIB=Mangled${OSMESA_LIB}
fi
AC_SUBST([GL_LIB])
AC_SUBST([GLU_LIB])
AC_SUBST([OSMESA_LIB])
-AM_CONDITIONAL(HAVE_MANGLED_GL, test $GL_LIB = MangledGL)
+AM_CONDITIONAL(HAVE_MANGLED_GL, test x${enable_mangling} = xyes)
dnl
dnl potentially-infringing-but-nobody-knows-for-sure stuff
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
If there are no objections, I'll push this tomorrow. Thanks!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Add --with-(gl|glu|osmesa)-lib-name options
On 06/05/2012 02:03 PM, Kenneth Graunke wrote: On 06/05/2012 01:38 PM, Kenneth Graunke wrote: ./autogen.sh --with-gl-lib-name=GL --with-glu-lib-name=GLU --with-osmesa-lib-name=OSMesa ... That looks cleaner to me. Here is a patch for it. Reviewed-by: Kenneth Graunke kenn...@whitecape.org If there are no objections, I'll push this tomorrow. Thanks! Great, thanks. If you want it: Signed-off-by: Brad King brad.k...@kitware.com -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965/fs: Fix texelFetchOffset() on pre-Gen7.
On 06/05/2012 10:59 AM, Eric Anholt wrote:
On Mon, 4 Jun 2012 14:15:10 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
Commit f41ecade7b458c02d504158b522acb2231585040 fixed texelFetchOffset()
on Ivybridge, but didn't update the Ironlake/Sandybridge code.
+15 piglits on Sandybridge.
NOTE: This and f41ecade7b458 are both candidates for stable branches.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 45
+++---
1 file changed, 33 insertions(+), 12 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 275a1f4..8d124a0 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -884,20 +884,41 @@ fs_visitor::emit_texture_gen5(ir_texture *ir, fs_reg
dst, fs_reg coordinate,
const int vector_elements =
ir-coordinate ? ir-coordinate-type-vector_elements : 0;
- if (ir-offset) {
- /* The offsets set up by the ir_texture visitor are in the
- * m1 header, so we can't go headerless.
+ if (ir-offset != NULL ir-op == ir_txf) {
+ /* It appears that the ld instruction used for txf does its
+ * address bounds check before adding in the offset. To work
+ * around this, just add the integer offset to the integer texel
+ * coordinate, and don't put the offset in the header.
*/
- header_present = true;
- mlen++;
- base_mrf--;
- }
+ int offsets[3];
+ ir_constant *offset = ir-offset-as_constant();
+ offsets[0] = offset-value.i[0];
+ offsets[1] = offset-value.i[1];
+ offsets[2] = offset-value.i[2];
No need for this temporary array (unlike in the fs where it was shared
with a non-offset path).
Other than that,
Reviewed-by: Eric Anholt e...@anholt.net
Eheh...right. Fixed that, thanks :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Add GL_TEXTURE_CUBE_MAP to _mesa_max_texture_levels().
On 06/05/2012 11:21 AM, Kenneth Graunke wrote: On 06/05/2012 07:05 AM, Brian Paul wrote: On 06/05/2012 01:16 AM, Kenneth Graunke wrote: For cube maps, _mesa_generate_mipmap() calls this with GL_TEXTURE_CUBE_MAP_ARB (the gl_texture_object's Target) rather than one of the faces. This caused _mesa_max_texture_levels() to return 0, which resulted in maxLevels == -1 and the next line's assertion to fail. This function is called from several places. It looks like texstorage.c also wants this enum to be handled, while most callers don't care. TexImage, CompressedTexImage, FramebufferTexture, and GetTexImage already appear to filter out illegal targets, so they should be fine. However, GetTexLevelParameter does rely on this function for filtering out invalid targets, and does not accept GL_TEXTURE_CUBE_MAP. Special case this, since it apparently supports every other target. I think glGet[Compressed]TexImage() needs the special case too. For example, getteximage_error_check() also uses max levels to error check the target. It might be good to beef-up the comment on _mesa_max_texture_levels() to clarify that the function is also used to error-check 'target' in various places and some care should be taken when adding support for new targets (GL_TEXTURE_CUBE_MAP_ARRAY someday). -Brian You're right, I think I missed a few cases. I'm tempted to make more functions like legal_teximage_target() and convert the callers to use that for their checking rather than implicitly relying on _mesa_max_texture_levels(). It feels like we have one function doing target checking for many different API calls...not all of which necessarily support the same set of targets. Thoughts? Sound OK to me. The original idea was to avoid doing several different switches on one target. But I'm sure the benefit of clearer code would trump any miniscule increase in runtime. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] glsl: Check for zero vectors in ir_binop_dot
---
src/glsl/opt_algebraic.cpp |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index cade961..1567ecd 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -305,6 +305,13 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
}
break;
+ case ir_binop_dot:
+ if (is_vec_zero(op_const[0]) || is_vec_zero(op_const[1])) {
+this-progress = true;
+return ir_constant::zero(mem_ctx, ir-type);
+ }
+ break;
+
case ir_binop_logic_and:
/* FINISHME: Also simplify (a a) to (a). */
if (is_vec_one(op_const[0])) {
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] glsl: Add is_basis function
Determines whether it's a basis vector, i.e., a vector with one element
equal to 1 and all other elements equal to 0.
---
src/glsl/ir.cpp | 48
src/glsl/ir.h | 26 ++
2 files changed, 70 insertions(+), 4 deletions(-)
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index 970d8f3..8277170 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -46,6 +46,11 @@ bool ir_rvalue::is_negative_one() const
return false;
}
+bool ir_rvalue::is_basis() const
+{
+ return false;
+}
+
/**
* Modify the swizzle make to move one component to another
*
@@ -1117,6 +1122,49 @@ ir_constant::is_negative_one() const
return true;
}
+bool
+ir_constant::is_basis() const
+{
+ if (!this-type-is_scalar() !this-type-is_vector())
+ return false;
+
+ if (this-type-is_boolean())
+ return false;
+
+ unsigned ones = 0;
+ for (unsigned c = 0; c this-type-vector_elements; c++) {
+ switch (this-type-base_type) {
+ case GLSL_TYPE_FLOAT:
+if (this-value.f[c] == 1.0)
+ ones++;
+else if (this-value.f[c] != 0.0)
+ return false;
+break;
+ case GLSL_TYPE_INT:
+if (this-value.i[c] == 1)
+ ones++;
+else if (this-value.i[c] != 0)
+ return false;
+break;
+ case GLSL_TYPE_UINT:
+if (int(this-value.u[c]) == 1)
+ ones++;
+else if (int(this-value.u[c]) != 0)
+ return false;
+break;
+ default:
+/* The only other base types are structures, arrays, samplers, and
+ * booleans. Samplers cannot be constants, and the others should
+ * have been filtered out above.
+ */
+assert(!Should not get here.);
+return false;
+ }
+ }
+
+ return ones == 1;
+}
+
ir_loop::ir_loop()
{
this-ir_type = ir_type_loop;
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 9c7961a..e55c3af 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -191,7 +191,8 @@ public:
* for vector and scalar types that have all elements set to the value
* zero (or \c false for booleans).
*
-* \sa ir_constant::has_value, ir_rvalue::is_one, ir_rvalue::is_negative_one
+* \sa ir_constant::has_value, ir_rvalue::is_one,
ir_rvalue::is_negative_one,
+* ir_constant::is_basis
*/
virtual bool is_zero() const;
@@ -203,7 +204,8 @@ public:
* for vector and scalar types that have all elements set to the value
* one (or \c true for booleans).
*
-* \sa ir_constant::has_value, ir_rvalue::is_zero,
ir_rvalue::is_negative_one
+* \sa ir_constant::has_value, ir_rvalue::is_zero,
ir_rvalue::is_negative_one,
+* ir_constant::is_basis
*/
virtual bool is_one() const;
@@ -213,12 +215,27 @@ public:
* The base implementation of this function always returns \c false. The
* \c ir_constant class over-rides this function to return \c true \b only
* for vector and scalar types that have all elements set to the value
-* negative one. For boolean times, the result is always \c false.
+* negative one. For boolean types, the result is always \c false.
*
* \sa ir_constant::has_value, ir_rvalue::is_zero, ir_rvalue::is_one
+* ir_constant::is_basis
*/
virtual bool is_negative_one() const;
+ /**
+* Determine if an r-value is a basis vector
+*
+* The base implementation of this function always returns \c false. The
+* \c ir_constant class over-rides this function to return \c true \b only
+* for vector and scalar types that have one element set to the value one,
+* and the other elements set to the value zero. For boolean types, the
+* result is always \c false.
+*
+* \sa ir_constant::has_value, ir_rvalue::is_zero, ir_rvalue::is_one,
+* is_constant::is_negative_one
+*/
+ virtual bool is_basis() const;
+
/**
* Return a generic value of error_type.
@@ -1729,13 +1746,14 @@ public:
* Determine whether a constant has the same value as another constant
*
* \sa ir_constant::is_zero, ir_constant::is_one,
-* ir_constant::is_negative_one
+* ir_constant::is_negative_one, ir_constant::is_basis
*/
bool has_value(const ir_constant *) const;
virtual bool is_zero() const;
virtual bool is_one() const;
virtual bool is_negative_one() const;
+ virtual bool is_basis() const;
/**
* Value of the constant.
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] glsl: Transform dot product by a basis vector into a swizzle
---
src/glsl/TODO |3 ---
src/glsl/opt_algebraic.cpp | 24
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/src/glsl/TODO b/src/glsl/TODO
index eb73fc2..bd077a8 100644
--- a/src/glsl/TODO
+++ b/src/glsl/TODO
@@ -6,9 +6,6 @@
constant index values. For others it is more complicated. Perhaps these
cases should be silently converted to uniforms?
-- Implement support for ir_binop_dot in opt_algebraic.cpp. Perform
- transformations such as dot(v, vec3(0.0, 1.0, 0.0)) - v.y.
-
- Track source locations throughout the IR. There are currently several
places where we cannot emit line numbers for errors (and currently emit 0:0)
because we've lost the line number information. This is particularly
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 1567ecd..38e7f14 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -80,6 +80,12 @@ is_vec_one(ir_constant *ir)
return (ir == NULL) ? false : ir-is_one();
}
+static inline bool
+is_vec_basis(ir_constant *ir)
+{
+ return (ir == NULL) ? false : ir-is_basis();
+}
+
static void
update_type(ir_expression *ir)
{
@@ -310,6 +316,24 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
this-progress = true;
return ir_constant::zero(mem_ctx, ir-type);
}
+ if (is_vec_basis(op_const[0])) {
+this-progress = true;
+unsigned component = 0;
+for (unsigned c = 0; c op_const[0]-type-vector_elements; c++) {
+ if (op_const[0]-value.f[c] == 1.0)
+ component = c;
+}
+return new(mem_ctx) ir_swizzle(ir-operands[1], component, 0, 0, 0, 1);
+ }
+ if (is_vec_basis(op_const[1])) {
+this-progress = true;
+unsigned component = 0;
+for (unsigned c = 0; c op_const[1]-type-vector_elements; c++) {
+ if (op_const[1]-value.f[c] == 1.0)
+ component = c;
+}
+return new(mem_ctx) ir_swizzle(ir-operands[0], component, 0, 0, 0, 1);
+ }
break;
case ir_binop_logic_and:
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] intel: sanitize i915_drm.h
run make headers_isntall on d-i-n, copy to here
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
include/drm/i915_drm.h |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index af3ce17..725a8de 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -33,6 +33,7 @@
* subject to backwards-compatibility constraints.
*/
+
/* Each region is a minimum of 16k, and there are at most 255 of them.
*/
#define I915_NR_TEX_REGIONS 255/* table size 2k - maximum due to use
@@ -287,7 +288,8 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_EXEC_CONSTANTS 14
#define I915_PARAM_HAS_RELAXED_DELTA15
#define I915_PARAM_HAS_GEN7_SOL_RESET 16
-#define I915_PARAM_HAS_LLC 17
+#define I915_PARAM_HAS_LLC 17
+#define I915_PARAM_HAS_ALIASING_PPGTT 18
typedef struct drm_i915_getparam {
int param;
--
1.7.10.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] intel: wait render header updates
make headers_install in kernel. Copy to here.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
include/drm/i915_drm.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 725a8de..1881f8a 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -192,6 +192,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_EXECBUFFER2 0x29
#define DRM_I915_GET_SPRITE_COLORKEY 0x2a
#define DRM_I915_SET_SPRITE_COLORKEY 0x2b
+#define DRM_I915_GEM_WAIT 0x2c
#define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
#define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_FLUSH)
@@ -235,6 +236,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_OVERLAY_ATTRS DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_OVERLAY_ATTRS, struct drm_intel_overlay_attrs)
#define DRM_IOCTL_I915_SET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
#define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
+#define DRM_IOCTL_I915_GEM_WAITDRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT, struct drm_i915_gem_wait)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -290,6 +292,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_GEN7_SOL_RESET 16
#define I915_PARAM_HAS_LLC 17
#define I915_PARAM_HAS_ALIASING_PPGTT 18
+#define I915_PARAM_HAS_WAIT_TIMEOUT 19
typedef struct drm_i915_getparam {
int param;
@@ -878,4 +881,12 @@ struct drm_intel_sprite_colorkey {
__u32 flags;
};
+struct drm_i915_gem_wait {
+ /** Handle of BO we shall wait on */
+ __u32 bo_handle;
+ __u32 flags;
+ /** Number of nanoseconds to wait, Returns time remaining. */
+ __u64 timeout_ns;
+};
+
#endif /* _I915_DRM_H_ */
--
1.7.10.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] mesa intel driver:
On 06/05/2012 12:55 AM, Zhao, Halley wrote:
Thanks Paul, Thanks Ian as well for the comments on it.
I will update internal_format to GL_YCBCR_MESA.
(I didn't notice glext.h before, but gl2.h only)
As to the error in intel_image_target_texture_2d(), it isn't caused by wrong
internal format, but hw limitation since we don't support packed YUV as texture.
Yes and no. The hardware natively supports the 422 subsampling, but
GEN4 and later do not support the color space conversion. For
GL_YCBCR_MESA textures extra instructions are added after the texture
lookup to perform the conversion.
-Original Message-
From: Pauli Nieminen [mailto:pauli.niemi...@linux.intel.com]
Sent: Monday, June 04, 2012 9:11 PM
To: Zhao, Halley
Cc: Eric Anholt; mesa-dev@lists.freedesktop.org; Barnes, Jesse
Subject: Re: [Mesa-dev] [PATCH 2/6] mesa intel driver:
On Mon, Jun 04, 2012 at 10:00:47AM +, Zhao, Halley wrote:
Thanks for careful review.
1. My mistake for the s, we can remove it.
There is MESA_FORMAT_YCBCR_REV for UYVY, so
MESA_FORMAT_YCBCR is exactly for YUYV format.
GL_LUMINANCE should be ok since YUYV is an luminance format.
internal_format should be GL_YCBCR_MESA that is supposed to be working
texture format with GL.
2. as to intel_image_target_texture_2d(), an error is added for YUYV region.
Updated patch see below.
Could it be because of wrong internal format?
3. A test case is added to demonstrate the usage:
http://lists.freedesktop.org/archives/mesa-dev/2012-June/022487.html
As to the case when hw overlay is not available, it is considered in
following way:
3.1) when client connect to wayland-server, it gets which formats are
supported from server in drm_handle_format(). Client sends YUYV buffer to
server only when the server supports it.
Client can convert a YUYV/NV12 buffer to XRGB format through
libva:
http://lists.freedesktop.org/archives/libva/2012-May/000845.html
(YUYV--NV12/YV12 are supported)
3.2) if Weston want to support YUYV internally, it can depend on libva's
color conversion or some special shader to do it.
From 5356270a25a300bbe7e0d36a79b031d2fb108a88 Mon Sep 17 00:00:00
2001
From: Zhao halleyhalley.z...@intel.com
Date: Fri, 25 May 2012 11:36:48 +0800
Subject: [PATCH 2/7] mesa intel driver:
add YUYV format for dri image
YUYV image doesn't use for texture
---
src/mesa/drivers/dri/intel/intel_screen.c|5 +
src/mesa/drivers/dri/intel/intel_tex_image.c |6 ++
2 files changed, 11 insertions(+), 0 deletions(-) mode change 100644
= 100755 src/mesa/drivers/dri/intel/intel_screen.c
mode change 100644 = 100755
src/mesa/drivers/dri/intel/intel_tex_image.c
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
old mode 100644
new mode 100755
index 458178f..b8d44ba
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -216,6 +216,11 @@ intel_create_image_from_name(__DRIscreen
*screen,
image-internal_format = GL_RGB;
image-data_type = GL_UNSIGNED_BYTE;
break;
+case __DRI_IMAGE_FORMAT_YUYV:
+ image-format = MESA_FORMAT_YCBCR;
+ image-internal_format = GL_LUMINANCE;
+ image-data_type = GL_UNSIGNED_BYTE;
+ break;
default:
free(image);
return NULL;
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
b/src/mesa/drivers/dri/intel/intel_tex_image.c
old mode 100644
new mode 100755
index 094d3cd..8b94cb1
--- a/src/mesa/drivers/dri/intel/intel_tex_image.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_image.c
@@ -388,6 +388,12 @@ intel_image_target_texture_2d(struct gl_context
*ctx, GLenum target,
if (image == NULL)
return;
+ if (image-format == MESA_FORMAT_YCBCR) {
+ _mesa_error(intel-ctx,
+ GL_INVALID_OPERATION, glEGLImageTargetTexture2DOES,
attach YUYV region to texture is not supported);
+ return;
+}
+
intel_set_texture_image_region(ctx, texImage, image-region,
target, image-internal_format,
image-format); }
--
1.7.5.4
-Original Message-
From: Eric Anholt [mailto:e...@anholt.net]
Sent: Saturday, June 02, 2012 5:33 AM
To: Zhao, Halley; mesa-dev@lists.freedesktop.org
Cc: Barnes, Jesse; Zhao, Halley
Subject: Re: [PATCH 2/6] mesa intel driver:
On Thu, 31 May 2012 17:23:59 +0800, Zhao halley
halley.z...@intel.com
wrote:
add YUYV format for dri image
YUYV image doesn't use for texture
---
src/mesa/drivers/dri/intel/intel_screen.c|5 +
src/mesa/drivers/dri/intel/intel_tex_image.c |3 +++
2 files changed, 8 insertions(+), 0 deletions(-) mode change
100644 = 100755 src/mesa/drivers/dri/intel/intel_screen.c
mode change 100644 = 100755
src/mesa/drivers/dri/intel/intel_tex_image.c
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
old mode
Re: [Mesa-dev] [PATCH 2/6] mesa intel driver:
On 06/05/2012 01:12 PM, Ian Romanick wrote: On 06/05/2012 12:55 AM, Zhao, Halley wrote: Thanks Paul, Thanks Ian as well for the comments on it. I will update internal_format to GL_YCBCR_MESA. (I didn't notice glext.h before, but gl2.h only) As to the error in intel_image_target_texture_2d(), it isn't caused by wrong internal format, but hw limitation since we don't support packed YUV as texture. Yes and no. The hardware natively supports the 422 subsampling, but GEN4 and later do not support the color space conversion. For GL_YCBCR_MESA textures extra instructions are added after the texture lookup to perform the conversion. But only in the old brw_wm_emit backend. The new brw_fs backend broke this, and nobody's bothered to fix it. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
On 06/04/2012 03:23 PM, Paul Berry wrote: On 4 June 2012 14:50, Ian Romanick i...@freedesktop.org mailto:i...@freedesktop.org wrote: On 06/04/2012 01:31 PM, Olivier Galibert wrote: On Mon, Jun 04, 2012 at 01:11:13PM -0700, Ian Romanick wrote: From: Ian Romanickian.d.romanick@intel.__com mailto:ian.d.roman...@intel.com In single precision, 1.5707963 becomes 1.5707962513 tel:1.5707962513 which is too small. However, 1.5707964 becomes 1.5707963705 tel:1.5707963705 which is just right. The value 1.5707964 is already used in asin.ir http://asin.ir. NOTE: This is a candidate for stable release branches. If piglit stops bitching on that partical problem thanks to such a small change, it's just beautiful. It does fix the acos issue in piglit. The closed-source test suite that we use still isn't happy, but I think that just means we need better approximations for acos and asin. asin(vec4(.2, .6, .8, 1.)) has an absolute error of (0.105351 0.0001987219 0.0001262426 0.003576). The results for .6 and .8 are especially bad, but even the .2 result should be better. The closed-source test suite wants an absolute error of 1e-5 for asin and acos. Do we have any quantitative information about how much accuracy is really needed for asin? Of course, an error of 1.9e-4 would be embarrassingly bad for scientific use, but are you sure that it isn't adequate for graphics purposes? I'd hate to spend a lot of effort The test expects an absolute error not more than 1e-5, and other desktop implementations achieve that. I don't think we should be significantly less precise than other implementations. implementing a more accurate asin, only to find that the only user-visible effect is for shaders to run slower because we're doing more accurate math. As fun as it is to numerically approximate trig functions (I'm not even kidding--I love this stuff and I'm jealous that I didn't think for even a fraction of a second that you were kidding. :) I don't have time to work on it right now) I'm not convinced it's worth it yet. Having said that, I *do* think it's worth making sure the asin function is well-behaved enough near zero that derivatives won't do unexpected things. If you do wind up working on this, I hope you'll keep the improvements I made last july (d4c80f5f85c749df3fc091ff07b60ef4989fa6d9) where I made the first two terms of the approximation pi/2 and pi/4-1. If these terms aren't exact, then asin behaves poorly near zero. Right. I've been trying to think of a good way to test this, but I keep coming up empty handed. Do we need a better precision atan, or should piglit just be told to shutup? The shutup patch has been sent it ages ago, but I can't do the more precision one if that's what's wanted. I think we need a better atan. The result that it produces is not very good. I plan to look into that more tonight. FYI, our formulas for atan and acos are exact trig identities in terms of asin, so probably any improvement made to asin will carry over to the others, at least until you reach the realm of rounding errors (which I'm guessing you won't reach if your target is 1e-5). That's a good point. Starting with asin may bear fruit more quickly than starting with atan. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: fix loop_variable_state-var_hash leak
---
src/glsl/loop_analysis.cpp |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/glsl/loop_analysis.cpp b/src/glsl/loop_analysis.cpp
index 6a0e4da..6548e15 100644
--- a/src/glsl/loop_analysis.cpp
+++ b/src/glsl/loop_analysis.cpp
@@ -42,8 +42,14 @@ loop_state::loop_state()
}
+static void destroy_loop_var_state(const void *key, void *data, void *closure)
+{
+ delete (loop_variable_state *)data;
+}
+
loop_state::~loop_state()
{
+ hash_table_call_foreach(this-ht, destroy_loop_var_state, NULL);
hash_table_dtor(this-ht);
ralloc_free(this-mem_ctx);
}
--
1.7.8.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: fix deref_hash memory leak in constant_expression_value
---
src/glsl/ir_constant_expression.cpp |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/glsl/ir_constant_expression.cpp
b/src/glsl/ir_constant_expression.cpp
index 08a3328..0713fd7 100644
--- a/src/glsl/ir_constant_expression.cpp
+++ b/src/glsl/ir_constant_expression.cpp
@@ -1275,8 +1275,11 @@
ir_function_signature::constant_expression_value(exec_list *actual_parameters, s
foreach_list(n, actual_parameters) {
ir_constant *constant = ((ir_rvalue *)
n)-constant_expression_value(variable_context);
- if (constant == NULL)
-return NULL;
+ if (constant == NULL) {
+ hash_table_dtor(deref_hash);
+ return NULL;
+ }
+
ir_variable *var = (ir_variable *)parameter_info;
hash_table_insert(deref_hash, constant, var);
--
1.7.8.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: fix deref_hash memory leak in constant_expression_value
On 06/05/2012 02:50 PM, Marcin Slusarz wrote:
---
src/glsl/ir_constant_expression.cpp |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/glsl/ir_constant_expression.cpp
b/src/glsl/ir_constant_expression.cpp
index 08a3328..0713fd7 100644
--- a/src/glsl/ir_constant_expression.cpp
+++ b/src/glsl/ir_constant_expression.cpp
@@ -1275,8 +1275,11 @@
ir_function_signature::constant_expression_value(exec_list
*actual_parameters, s
foreach_list(n, actual_parameters) {
ir_constant *constant = ((ir_rvalue *)
n)-constant_expression_value(variable_context);
- if (constant == NULL)
- return NULL;
+ if (constant == NULL) {
+ hash_table_dtor(deref_hash);
+ return NULL;
+ }
+
ir_variable *var = (ir_variable *)parameter_info;
hash_table_insert(deref_hash, constant, var);
Oops...thanks.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] mesa: consolidate internal glTexImage1/2/3D code
The functions for handling 1D, 2D and 3D texture images were nearly
identical. This folds them all together.
---
src/mesa/drivers/common/driverfuncs.c |4 +-
src/mesa/drivers/dri/intel/intel_tex_image.c | 60 ++
src/mesa/drivers/dri/nouveau/nouveau_texture.c | 43 +++---
src/mesa/drivers/dri/radeon/radeon_texture.c | 41 ++--
src/mesa/main/dd.h | 44 +++--
src/mesa/main/teximage.c | 36 ++-
src/mesa/main/texobj.c | 28 +---
src/mesa/main/texstore.c | 78
src/mesa/main/texstore.h | 31 ++---
src/mesa/state_tracker/st_cb_texture.c | 51 +++-
10 files changed, 73 insertions(+), 343 deletions(-)
diff --git a/src/mesa/drivers/common/driverfuncs.c
b/src/mesa/drivers/common/driverfuncs.c
index ca12057..54e5221 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/driverfuncs.c
@@ -91,9 +91,7 @@ _mesa_init_driver_functions(struct dd_function_table *driver)
/* Texture functions */
driver-ChooseTextureFormat = _mesa_choose_tex_format;
- driver-TexImage1D = _mesa_store_teximage1d;
- driver-TexImage2D = _mesa_store_teximage2d;
- driver-TexImage3D = _mesa_store_teximage3d;
+ driver-TexImage = _mesa_store_teximage;
driver-TexSubImage1D = _mesa_store_texsubimage1d;
driver-TexSubImage2D = _mesa_store_texsubimage2d;
driver-TexSubImage3D = _mesa_store_texsubimage3d;
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
b/src/mesa/drivers/dri/intel/intel_tex_image.c
index abd75c5..6e7e7018 100644
--- a/src/mesa/drivers/dri/intel/intel_tex_image.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_image.c
@@ -203,13 +203,12 @@ try_pbo_upload(struct gl_context *ctx,
static void
intelTexImage(struct gl_context * ctx,
- GLint dims,
+ GLuint dims,
struct gl_texture_image *texImage,
GLint internalFormat,
- GLint width, GLint height, GLint depth,
+ GLint width, GLint height, GLint depth, GLint border,
GLenum format, GLenum type, const void *pixels,
- const struct gl_pixelstore_attrib *unpack,
- GLsizei imageSize)
+ const struct gl_pixelstore_attrib *unpack)
{
DBG(%s target %s level %d %dx%dx%d\n, __FUNCTION__,
_mesa_lookup_enum_by_nr(texImage-TexObject-Target),
@@ -226,52 +225,9 @@ intelTexImage(struct gl_context * ctx,
DBG(%s: upload image %dx%dx%d pixels %p\n,
__FUNCTION__, width, height, depth, pixels);
- _mesa_store_teximage3d(ctx, texImage, internalFormat,
- width, height, depth, 0,
- format, type, pixels, unpack);
-}
-
-
-static void
-intelTexImage3D(struct gl_context * ctx,
-struct gl_texture_image *texImage,
-GLint internalFormat,
-GLint width, GLint height, GLint depth,
-GLint border,
-GLenum format, GLenum type, const void *pixels,
-const struct gl_pixelstore_attrib *unpack)
-{
- intelTexImage(ctx, 3, texImage,
- internalFormat, width, height, depth,
- format, type, pixels, unpack, 0);
-}
-
-
-static void
-intelTexImage2D(struct gl_context * ctx,
-struct gl_texture_image *texImage,
-GLint internalFormat,
-GLint width, GLint height, GLint border,
-GLenum format, GLenum type, const void *pixels,
-const struct gl_pixelstore_attrib *unpack)
-{
- intelTexImage(ctx, 2, texImage,
- internalFormat, width, height, 1,
- format, type, pixels, unpack, 0);
-}
-
-
-static void
-intelTexImage1D(struct gl_context * ctx,
-struct gl_texture_image *texImage,
-GLint internalFormat,
-GLint width, GLint border,
-GLenum format, GLenum type, const void *pixels,
-const struct gl_pixelstore_attrib *unpack)
-{
- intelTexImage(ctx, 1, texImage,
- internalFormat, width, 1, 1,
- format, type, pixels, unpack, 0);
+ _mesa_store_teximage(ctx, dims, texImage, internalFormat,
+width, height, depth, 0,
+format, type, pixels, unpack);
}
@@ -398,9 +354,7 @@ intel_image_target_texture_2d(struct gl_context *ctx,
GLenum target,
void
intelInitTextureImageFuncs(struct dd_function_table *functions)
{
- functions-TexImage1D = intelTexImage1D;
- functions-TexImage2D = intelTexImage2D;
- functions-TexImage3D = intelTexImage3D;
+ functions-TexImage = intelTexImage;
#if FEATURE_OES_EGL_image
functions-EGLImageTargetTexture2D = intel_image_target_texture_2d;
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_texture.c
[Mesa-dev] [PATCH 2/5] mesa: consolidate internal glTexSubImage1/2/3D code
---
src/mesa/drivers/common/driverfuncs.c |4 +-
src/mesa/drivers/common/meta.c | 21 ++---
src/mesa/drivers/dri/intel/intel_tex_subimage.c | 28 +++--
src/mesa/drivers/dri/nouveau/nouveau_texture.c | 43
src/mesa/main/dd.h | 45
src/mesa/main/mipmap.c |8 ++--
src/mesa/main/teximage.c| 24 ++-
src/mesa/main/texstore.c| 50 ---
src/mesa/main/texstore.h| 29 +++--
src/mesa/state_tracker/st_cb_texture.c |4 +-
10 files changed, 61 insertions(+), 195 deletions(-)
diff --git a/src/mesa/drivers/common/driverfuncs.c
b/src/mesa/drivers/common/driverfuncs.c
index 54e5221..a9ccbd5 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/driverfuncs.c
@@ -92,9 +92,7 @@ _mesa_init_driver_functions(struct dd_function_table *driver)
/* Texture functions */
driver-ChooseTextureFormat = _mesa_choose_tex_format;
driver-TexImage = _mesa_store_teximage;
- driver-TexSubImage1D = _mesa_store_texsubimage1d;
- driver-TexSubImage2D = _mesa_store_texsubimage2d;
- driver-TexSubImage3D = _mesa_store_texsubimage3d;
+ driver-TexSubImage = _mesa_store_texsubimage;
driver-GetTexImage = _mesa_meta_GetTexImage;
driver-CopyTexSubImage1D = _mesa_meta_CopyTexSubImage1D;
driver-CopyTexSubImage2D = _mesa_meta_CopyTexSubImage2D;
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index a20e419..69761d6 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -3127,7 +3127,6 @@ copy_tex_sub_image(struct gl_context *ctx,
GLsizei width, GLsizei height)
{
struct gl_texture_object *texObj = texImage-TexObject;
- const GLenum target = texObj-Target;
GLenum format, type;
GLint bpp;
void *buf;
@@ -3181,21 +3180,11 @@ copy_tex_sub_image(struct gl_context *ctx,
* Store texture data (with pixel transfer ops)
*/
_mesa_meta_begin(ctx, MESA_META_PIXEL_STORE);
- if (target == GL_TEXTURE_1D) {
- ctx-Driver.TexSubImage1D(ctx, texImage,
-xoffset, width,
-format, type, buf, ctx-Unpack);
- }
- else if (target == GL_TEXTURE_3D) {
- ctx-Driver.TexSubImage3D(ctx, texImage,
-xoffset, yoffset, zoffset, width, height, 1,
-format, type, buf, ctx-Unpack);
- }
- else {
- ctx-Driver.TexSubImage2D(ctx, texImage,
-xoffset, yoffset, width, height,
-format, type, buf, ctx-Unpack);
- }
+
+ ctx-Driver.TexSubImage(ctx, dims, texImage,
+ xoffset, yoffset, zoffset, width, height, 1,
+ format, type, buf, ctx-Unpack);
+
_mesa_meta_end(ctx);
_mesa_lock_texture(ctx, texObj); /* re-lock */
diff --git a/src/mesa/drivers/dri/intel/intel_tex_subimage.c
b/src/mesa/drivers/dri/intel/intel_tex_subimage.c
index eb8b983..ae4b3bc 100644
--- a/src/mesa/drivers/dri/intel/intel_tex_subimage.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_subimage.c
@@ -149,27 +149,29 @@ intel_blit_texsubimage(struct gl_context * ctx,
}
static void
-intelTexSubImage2D(struct gl_context * ctx,
- struct gl_texture_image *texImage,
- GLint xoffset, GLint yoffset,
- GLsizei width, GLsizei height,
- GLenum format, GLenum type,
- const GLvoid * pixels,
- const struct gl_pixelstore_attrib *packing)
+intelTexSubImage(struct gl_context * ctx,
+ GLuint dims,
+ struct gl_texture_image *texImage,
+ GLint xoffset, GLint yoffset, GLint zoffset,
+ GLsizei width, GLsizei height, GLsizei depth,
+ GLenum format, GLenum type,
+ const GLvoid * pixels,
+ const struct gl_pixelstore_attrib *packing)
{
- if (!intel_blit_texsubimage(ctx, texImage,
+ /* The intel_blit_texsubimage() function only handles 2D images */
+ if (dims != 2 || !intel_blit_texsubimage(ctx, texImage,
xoffset, yoffset,
width, height,
format, type, pixels, packing)) {
- _mesa_store_texsubimage2d(ctx, texImage,
- xoffset, yoffset,
- width, height,
- format, type, pixels, packing);
+ _mesa_store_texsubimage(ctx, dims, texImage,
+ xoffset, yoffset, zoffset,
+ width, height, depth,
+ format, type, pixels, packing);
}
}
void
[Mesa-dev] [PATCH 3/5] mesa: consolidate internal glCopyTexSubImage1/2/3D code
---
src/mesa/drivers/common/driverfuncs.c |4 +-
src/mesa/drivers/common/meta.c| 55 +++
src/mesa/drivers/common/meta.h| 27 +++-
src/mesa/drivers/dri/intel/intel_tex_copy.c | 40 +
src/mesa/drivers/dri/radeon/radeon_tex_copy.c | 18
src/mesa/drivers/dri/radeon/radeon_texture.c |2 +-
src/mesa/drivers/dri/radeon/radeon_texture.h | 12 +++---
src/mesa/main/dd.h| 33 +++---
src/mesa/main/teximage.c | 31 +++---
src/mesa/state_tracker/st_cb_texture.c| 58 +++--
10 files changed, 61 insertions(+), 219 deletions(-)
diff --git a/src/mesa/drivers/common/driverfuncs.c
b/src/mesa/drivers/common/driverfuncs.c
index a9ccbd5..118fc4a 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/driverfuncs.c
@@ -94,9 +94,7 @@ _mesa_init_driver_functions(struct dd_function_table *driver)
driver-TexImage = _mesa_store_teximage;
driver-TexSubImage = _mesa_store_texsubimage;
driver-GetTexImage = _mesa_meta_GetTexImage;
- driver-CopyTexSubImage1D = _mesa_meta_CopyTexSubImage1D;
- driver-CopyTexSubImage2D = _mesa_meta_CopyTexSubImage2D;
- driver-CopyTexSubImage3D = _mesa_meta_CopyTexSubImage3D;
+ driver-CopyTexSubImage = _mesa_meta_CopyTexSubImage;
driver-GenerateMipmap = _mesa_meta_GenerateMipmap;
driver-TestProxyTexImage = _mesa_test_proxy_teximage;
driver-CompressedTexImage1D = _mesa_store_compressed_teximage1d;
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 69761d6..8e2c8fc 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -3117,14 +3117,13 @@ get_temp_image_type(struct gl_context *ctx, GLenum
baseFormat)
* Helper for _mesa_meta_CopyTexSubImage1/2/3D() functions.
* Have to be careful with locking and meta state for pixel transfer.
*/
-static void
-copy_tex_sub_image(struct gl_context *ctx,
- GLuint dims,
- struct gl_texture_image *texImage,
- GLint xoffset, GLint yoffset, GLint zoffset,
- struct gl_renderbuffer *rb,
- GLint x, GLint y,
- GLsizei width, GLsizei height)
+void
+_mesa_meta_CopyTexSubImage(struct gl_context *ctx, GLuint dims,
+ struct gl_texture_image *texImage,
+ GLint xoffset, GLint yoffset, GLint zoffset,
+ struct gl_renderbuffer *rb,
+ GLint x, GLint y,
+ GLsizei width, GLsizei height)
{
struct gl_texture_object *texObj = texImage-TexObject;
GLenum format, type;
@@ -3151,7 +3150,7 @@ copy_tex_sub_image(struct gl_context *ctx,
type = get_temp_image_type(ctx, format);
bpp = _mesa_bytes_per_pixel(format, type);
if (bpp = 0) {
- _mesa_problem(ctx, Bad bpp in meta copy_tex_sub_image());
+ _mesa_problem(ctx, Bad bpp in _mesa_meta_CopyTexSubImage());
return;
}
@@ -3193,44 +3192,6 @@ copy_tex_sub_image(struct gl_context *ctx,
}
-void
-_mesa_meta_CopyTexSubImage1D(struct gl_context *ctx,
- struct gl_texture_image *texImage,
- GLint xoffset,
- struct gl_renderbuffer *rb,
- GLint x, GLint y, GLsizei width)
-{
- copy_tex_sub_image(ctx, 1, texImage, xoffset, 0, 0,
- rb, x, y, width, 1);
-}
-
-
-void
-_mesa_meta_CopyTexSubImage2D(struct gl_context *ctx,
- struct gl_texture_image *texImage,
- GLint xoffset, GLint yoffset,
- struct gl_renderbuffer *rb,
- GLint x, GLint y,
- GLsizei width, GLsizei height)
-{
- copy_tex_sub_image(ctx, 2, texImage, xoffset, yoffset, 0,
- rb, x, y, width, height);
-}
-
-
-void
-_mesa_meta_CopyTexSubImage3D(struct gl_context *ctx,
- struct gl_texture_image *texImage,
- GLint xoffset, GLint yoffset, GLint zoffset,
- struct gl_renderbuffer *rb,
- GLint x, GLint y,
- GLsizei width, GLsizei height)
-{
- copy_tex_sub_image(ctx, 3, texImage, xoffset, yoffset, zoffset,
- rb, x, y, width, height);
-}
-
-
/**
* Decompress a texture image by drawing a quad with the compressed
* texture and reading the pixels out of the color buffer.
diff --git a/src/mesa/drivers/common/meta.h b/src/mesa/drivers/common/meta.h
index de039b5..7a80b1d 100644
--- a/src/mesa/drivers/common/meta.h
+++ b/src/mesa/drivers/common/meta.h
@@ -111,27 +111,12 @@ _mesa_meta_GenerateMipmap(struct gl_context *ctx, GLenum
target,
[Mesa-dev] [PATCH 4/5] mesa: consolidate internal glCompressedTexImage1/2/3D code
---
src/mesa/drivers/common/driverfuncs.c |4 +-
src/mesa/drivers/dri/nouveau/nouveau_texture.c |6 +-
src/mesa/main/dd.h | 37 +++---
src/mesa/main/teximage.c | 29 ++--
src/mesa/main/texstore.c | 62 +---
src/mesa/main/texstore.h | 26 ++
src/mesa/state_tracker/st_cb_texture.c | 18
7 files changed, 43 insertions(+), 139 deletions(-)
diff --git a/src/mesa/drivers/common/driverfuncs.c
b/src/mesa/drivers/common/driverfuncs.c
index 118fc4a..3d68936 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/driverfuncs.c
@@ -97,9 +97,7 @@ _mesa_init_driver_functions(struct dd_function_table *driver)
driver-CopyTexSubImage = _mesa_meta_CopyTexSubImage;
driver-GenerateMipmap = _mesa_meta_GenerateMipmap;
driver-TestProxyTexImage = _mesa_test_proxy_teximage;
- driver-CompressedTexImage1D = _mesa_store_compressed_teximage1d;
- driver-CompressedTexImage2D = _mesa_store_compressed_teximage2d;
- driver-CompressedTexImage3D = _mesa_store_compressed_teximage3d;
+ driver-CompressedTexImage = _mesa_store_compressed_teximage;
driver-CompressedTexSubImage1D = _mesa_store_compressed_texsubimage1d;
driver-CompressedTexSubImage2D = _mesa_store_compressed_texsubimage2d;
driver-CompressedTexSubImage3D = _mesa_store_compressed_texsubimage3d;
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_texture.c
b/src/mesa/drivers/dri/nouveau/nouveau_texture.c
index 4d6518d..281d1dd 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_texture.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_texture.c
@@ -555,10 +555,10 @@ nouveau_teximage_123d(struct gl_context *ctx, GLuint dims,
}
static void
-nouveau_compressed_teximage_2d(struct gl_context *ctx,
+nouveau_compressed_teximage(struct gl_context *ctx, GLuint dims,
struct gl_texture_image *ti,
GLint internalFormat,
- GLint width, GLint height, GLint border,
+ GLint width, GLint height, GLint depth, GLint border,
GLsizei imageSize, const GLvoid *data)
{
nouveau_teximage(ctx, 2, ti, internalFormat,
@@ -708,7 +708,7 @@ nouveau_texture_functions_init(struct dd_function_table
*functions)
functions-ChooseTextureFormat = nouveau_choose_tex_format;
functions-TexImage = nouveau_teximage_123d;
functions-TexSubImage = nouveau_texsubimage_123d;
- functions-CompressedTexImage2D = nouveau_compressed_teximage_2d;
+ functions-CompressedTexImage = nouveau_compressed_teximage;
functions-CompressedTexSubImage2D = nouveau_compressed_texsubimage_2d;
functions-BindTexture = nouveau_bind_texture;
functions-MapTextureImage = nouveau_map_texture_image;
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index f66e754..07106ac 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -269,37 +269,14 @@ struct dd_function_table {
/*@{*/
/**
-* Called by glCompressedTexImage1D().
-* The parameters are the same as for glCompressedTexImage1D(), plus a
-* pointer to the destination texure image.
-*/
- void (*CompressedTexImage1D)(struct gl_context *ctx,
-struct gl_texture_image *texImage,
-GLint internalFormat,
-GLsizei width, GLint border,
-GLsizei imageSize, const GLvoid *data);
- /**
-* Called by glCompressedTexImage2D().
-*
-* \sa dd_function_table::CompressedTexImage1D.
-*/
- void (*CompressedTexImage2D)(struct gl_context *ctx,
-struct gl_texture_image *texImage,
-GLint internalFormat,
-GLsizei width, GLsizei height, GLint border,
-GLsizei imageSize, const GLvoid *data);
-
- /**
-* Called by glCompressedTexImage3D().
-*
-* \sa dd_function_table::CompressedTexImage3D.
-*/
- void (*CompressedTexImage3D)(struct gl_context *ctx,
-struct gl_texture_image *texImage,
-GLint internalFormat,
-GLsizei width, GLsizei height, GLsizei depth,
-GLint border,
-GLsizei imageSize, const GLvoid *data);
+* Called by glCompressedTexImage[123]D().
+*/
+ void (*CompressedTexImage)(struct gl_context *ctx, GLuint dims,
+ struct gl_texture_image *texImage,
+ GLint internalFormat,
+ GLsizei width, GLsizei height, GLsizei depth,
+ GLint border,
+ GLsizei imageSize, const GLvoid *data);
/**
* Called by
[Mesa-dev] [PATCH 5/5] mesa: consolidate internal glCompressedTexSubImage1/2/3D code
---
src/mesa/drivers/common/driverfuncs.c |4 +-
src/mesa/drivers/dri/nouveau/nouveau_texture.c | 12 ++--
src/mesa/main/dd.h | 33 +++-
src/mesa/main/teximage.c | 31 ++-
src/mesa/main/texstore.c | 69 ++--
src/mesa/main/texstore.h | 27 ++---
src/mesa/state_tracker/st_cb_texture.c |4 +-
7 files changed, 42 insertions(+), 138 deletions(-)
diff --git a/src/mesa/drivers/common/driverfuncs.c
b/src/mesa/drivers/common/driverfuncs.c
index 3d68936..93fa3c7 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/driverfuncs.c
@@ -98,9 +98,7 @@ _mesa_init_driver_functions(struct dd_function_table *driver)
driver-GenerateMipmap = _mesa_meta_GenerateMipmap;
driver-TestProxyTexImage = _mesa_test_proxy_teximage;
driver-CompressedTexImage = _mesa_store_compressed_teximage;
- driver-CompressedTexSubImage1D = _mesa_store_compressed_texsubimage1d;
- driver-CompressedTexSubImage2D = _mesa_store_compressed_texsubimage2d;
- driver-CompressedTexSubImage3D = _mesa_store_compressed_texsubimage3d;
+ driver-CompressedTexSubImage = _mesa_store_compressed_texsubimage;
driver-GetCompressedTexImage = _mesa_get_compressed_teximage;
driver-BindTexture = NULL;
driver-NewTextureObject = _mesa_new_texture_object;
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_texture.c
b/src/mesa/drivers/dri/nouveau/nouveau_texture.c
index 281d1dd..0060f46 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_texture.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_texture.c
@@ -624,15 +624,15 @@ nouveau_texsubimage_123d(struct gl_context *ctx, GLuint
dims,
}
static void
-nouveau_compressed_texsubimage_2d(struct gl_context *ctx,
+nouveau_compressed_texsubimage(struct gl_context *ctx, GLuint dims,
struct gl_texture_image *ti,
- GLint xoffset, GLint yoffset,
- GLsizei width, GLint height,
+ GLint xoffset, GLint yoffset, GLint zoffset,
+ GLsizei width, GLint height, GLint depth,
GLenum format,
GLint imageSize, const void *data)
{
- nouveau_texsubimage(ctx, 2, ti, xoffset, yoffset, 0,
- width, height, 1, imageSize, format, 0, data,
+ nouveau_texsubimage(ctx, dims, ti, xoffset, yoffset, zoffset,
+ width, height, depth, imageSize, format, 0, data,
ctx-Unpack, GL_TRUE);
}
@@ -709,7 +709,7 @@ nouveau_texture_functions_init(struct dd_function_table
*functions)
functions-TexImage = nouveau_teximage_123d;
functions-TexSubImage = nouveau_texsubimage_123d;
functions-CompressedTexImage = nouveau_compressed_teximage;
- functions-CompressedTexSubImage2D = nouveau_compressed_texsubimage_2d;
+ functions-CompressedTexSubImage = nouveau_compressed_texsubimage;
functions-BindTexture = nouveau_bind_texture;
functions-MapTextureImage = nouveau_map_texture_image;
functions-UnmapTextureImage = nouveau_unmap_texture_image;
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 07106ac..1582a8c 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -279,33 +279,14 @@ struct dd_function_table {
GLsizei imageSize, const GLvoid *data);
/**
-* Called by glCompressedTexSubImage1D().
+* Called by glCompressedTexSubImage[123]D().
*/
- void (*CompressedTexSubImage1D)(struct gl_context *ctx,
- struct gl_texture_image *texImage,
- GLint xoffset, GLsizei width,
- GLenum format,
- GLsizei imageSize, const GLvoid *data);
-
- /**
-* Called by glCompressedTexSubImage2D().
-*/
- void (*CompressedTexSubImage2D)(struct gl_context *ctx,
- struct gl_texture_image *texImage,
- GLint xoffset, GLint yoffset,
- GLsizei width, GLint height,
- GLenum format,
- GLsizei imageSize, const GLvoid *data);
-
- /**
-* Called by glCompressedTexSubImage3D().
-*/
- void (*CompressedTexSubImage3D)(struct gl_context *ctx,
- struct gl_texture_image *texImage,
- GLint xoffset, GLint yoffset, GLint zoffset,
- GLsizei width, GLint height, GLint depth,
- GLenum format,
- GLsizei imageSize, const GLvoid *data);
+ void (*CompressedTexSubImage)(struct gl_context *ctx, GLuint dims,
+ struct gl_texture_image *texImage,
[Mesa-dev] [PATCH 3/3] intel: wait render timeout implementation
int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
This should bump the libdrm version. We're waiting for context support
so we can do both features in one bump.
v2: don't return remaining timeout amount
use get param and fallback for older kernels
v3: only doing getparam at init
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
intel/intel_bufmgr.h |1 +
intel/intel_bufmgr_gem.c | 30 ++
2 files changed, 31 insertions(+)
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index c197abc..10ccc25 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -184,6 +184,7 @@ int drm_intel_get_pipe_from_crtc_id(drm_intel_bufmgr
*bufmgr, int crtc_id);
int drm_intel_get_aperture_sizes(int fd, size_t *mappable, size_t *total);
int drm_intel_bufmgr_gem_get_devid(drm_intel_bufmgr *bufmgr);
+int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns);
/* drm_intel_bufmgr_fake.c */
drm_intel_bufmgr *drm_intel_bufmgr_fake_init(int fd,
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index b776d2f..b780ab9 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -119,6 +119,7 @@ typedef struct _drm_intel_bufmgr_gem {
unsigned int has_blt : 1;
unsigned int has_relaxed_fencing : 1;
unsigned int has_llc : 1;
+ unsigned int has_wait_timeout : 1;
unsigned int bo_reuse : 1;
unsigned int no_exec : 1;
bool fenced_relocs;
@@ -1479,6 +1480,31 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
}
/**
+ * Same as drm_intel_gem_bo_wait_rendering except a timeout parameter allows
the
+ * operation to give up after a certain amount of time.
+ *
+ * A 0 return value implies that the wait was successful. Otherwise some
+ * negative return value describes the error.
+ */
+int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
+{
+ drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo-bufmgr;
+ drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+ struct drm_i915_gem_wait wait;
+ int ret;
+
+ if (!bufmgr_gem-has_wait_timeout) {
+ drm_intel_gem_bo_wait_rendering(bo);
+ return 0;
+ }
+
+ wait.bo_handle = bo_gem-gem_handle;
+ wait.timeout_ns = timeout_ns;
+ wait.flags = 0;
+ return drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GEM_WAIT, wait);
+}
+
+/**
* Sets the object to the GTT read and possibly write domain, used by the X
* 2D driver in the absence of kernel support to do drm_intel_gem_bo_map_gtt().
*
@@ -2898,6 +2924,10 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
bufmgr_gem-has_relaxed_fencing = ret == 0;
+ gp.param = I915_PARAM_HAS_WAIT_TIMEOUT;
+ ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
+ bufmgr_gem-has_wait_timeout = ret == 0;
+
gp.param = I915_PARAM_HAS_LLC;
ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
if (ret != 0) {
--
1.7.10.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] intel: wait render header updates
make headers_install in kernel. Copy to here.
v2: signed ns_timeout
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
include/drm/i915_drm.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 725a8de..4931107 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -192,6 +192,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_EXECBUFFER2 0x29
#define DRM_I915_GET_SPRITE_COLORKEY 0x2a
#define DRM_I915_SET_SPRITE_COLORKEY 0x2b
+#define DRM_I915_GEM_WAIT 0x2c
#define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
#define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_FLUSH)
@@ -235,6 +236,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_OVERLAY_ATTRS DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_OVERLAY_ATTRS, struct drm_intel_overlay_attrs)
#define DRM_IOCTL_I915_SET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
#define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
+#define DRM_IOCTL_I915_GEM_WAITDRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT, struct drm_i915_gem_wait)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -290,6 +292,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_GEN7_SOL_RESET 16
#define I915_PARAM_HAS_LLC 17
#define I915_PARAM_HAS_ALIASING_PPGTT 18
+#define I915_PARAM_HAS_WAIT_TIMEOUT 19
typedef struct drm_i915_getparam {
int param;
@@ -878,4 +881,12 @@ struct drm_intel_sprite_colorkey {
__u32 flags;
};
+struct drm_i915_gem_wait {
+ /** Handle of BO we shall wait on */
+ __u32 bo_handle;
+ __u32 flags;
+ /** Number of nanoseconds to wait, Returns time remaining. */
+ __s64 timeout_ns;
+};
+
#endif /* _I915_DRM_H_ */
--
1.7.10.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] intel: wait render timeout implementation
int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
This should bump the libdrm version. We're waiting for context support
so we can do both features in one bump.
v2: don't return remaining timeout amount
use get param and fallback for older kernels
v3: only doing getparam at init
prototypes now have a signed input value
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
intel/intel_bufmgr.h |1 +
intel/intel_bufmgr_gem.c | 30 ++
2 files changed, 31 insertions(+)
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index c197abc..fa6c4dd 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -184,6 +184,7 @@ int drm_intel_get_pipe_from_crtc_id(drm_intel_bufmgr
*bufmgr, int crtc_id);
int drm_intel_get_aperture_sizes(int fd, size_t *mappable, size_t *total);
int drm_intel_bufmgr_gem_get_devid(drm_intel_bufmgr *bufmgr);
+int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns);
/* drm_intel_bufmgr_fake.c */
drm_intel_bufmgr *drm_intel_bufmgr_fake_init(int fd,
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index b776d2f..048fca7 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -119,6 +119,7 @@ typedef struct _drm_intel_bufmgr_gem {
unsigned int has_blt : 1;
unsigned int has_relaxed_fencing : 1;
unsigned int has_llc : 1;
+ unsigned int has_wait_timeout : 1;
unsigned int bo_reuse : 1;
unsigned int no_exec : 1;
bool fenced_relocs;
@@ -1479,6 +1480,31 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
}
/**
+ * Same as drm_intel_gem_bo_wait_rendering except a timeout parameter allows
the
+ * operation to give up after a certain amount of time.
+ *
+ * A 0 return value implies that the wait was successful. Otherwise some
+ * negative return value describes the error.
+ */
+int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns)
+{
+ drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo-bufmgr;
+ drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+ struct drm_i915_gem_wait wait;
+ int ret;
+
+ if (!bufmgr_gem-has_wait_timeout) {
+ drm_intel_gem_bo_wait_rendering(bo);
+ return 0;
+ }
+
+ wait.bo_handle = bo_gem-gem_handle;
+ wait.timeout_ns = timeout_ns;
+ wait.flags = 0;
+ return drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GEM_WAIT, wait);
+}
+
+/**
* Sets the object to the GTT read and possibly write domain, used by the X
* 2D driver in the absence of kernel support to do drm_intel_gem_bo_map_gtt().
*
@@ -2898,6 +2924,10 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
bufmgr_gem-has_relaxed_fencing = ret == 0;
+ gp.param = I915_PARAM_HAS_WAIT_TIMEOUT;
+ ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
+ bufmgr_gem-has_wait_timeout = ret == 0;
+
gp.param = I915_PARAM_HAS_LLC;
ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
if (ret != 0) {
--
1.7.10.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: fix loop_variable_state-var_hash leak
On 06/05/2012 02:49 PM, Marcin Slusarz wrote:
---
src/glsl/loop_analysis.cpp |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/glsl/loop_analysis.cpp b/src/glsl/loop_analysis.cpp
index 6a0e4da..6548e15 100644
--- a/src/glsl/loop_analysis.cpp
+++ b/src/glsl/loop_analysis.cpp
@@ -42,8 +42,14 @@ loop_state::loop_state()
}
+static void destroy_loop_var_state(const void *key, void *data, void
*closure)
+{
+ delete (loop_variable_state *)data;
+}
+
loop_state::~loop_state()
{
+ hash_table_call_foreach(this-ht, destroy_loop_var_state, NULL);
hash_table_dtor(this-ht);
ralloc_free(this-mem_ctx);
}
This makes me nervous. They're allocated via ralloc:
loop_variable_state *ls = new(this-mem_ctx) loop_variable_state;
which internally uses malloc/calloc and friends, not new/delete.
~loop_state() already calls ralloc_free(this-mem_ctx), which frees all
the loop_variable_state objects. However, the loop_variable_state
destructor isn't hooked up, so hash_table_dtor(this-var_hash) is never
getting called.
I'll reply in a moment with a patch to use ralloc invoke the destructor.
It may be possible to rework ralloc such that C++ destructors just work.
I'll have to think about that.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Hook up loop_variable_state destructor to plug a memory leak.
While ~loop_state() is already freeing the loop_variable_state objects
via ralloc_free(this-mem_ctx), the ~loop_variable_state() destructor
was never getting called, so the hash table inside loop_variable_state
was never getting destroyed.
Fixes a memory leak in any shader with loops.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/glsl/loop_analysis.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/src/glsl/loop_analysis.h b/src/glsl/loop_analysis.h
index 8bed1db..05c982f 100644
--- a/src/glsl/loop_analysis.h
+++ b/src/glsl/loop_analysis.h
@@ -140,6 +140,23 @@ public:
{
hash_table_dtor(this-var_hash);
}
+
+ static void* operator new(size_t size, void *ctx)
+ {
+ void *lvs = ralloc_size(ctx, size);
+ assert(lvs != NULL);
+
+ ralloc_set_destructor(lvs, (void (*)(void*)) destructor);
+
+ return lvs;
+ }
+
+private:
+ static void
+ destructor(loop_variable_state *lvs)
+ {
+ lvs-~loop_variable_state();
+ }
};
--
1.7.10.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] mesa: consolidate internal glTexImage1/2/3D code
On 06/05/2012 03:35 PM, Brian Paul wrote: The functions for handling 1D, 2D and 3D texture images were nearly identical. This folds them all together. --- src/mesa/drivers/common/driverfuncs.c |4 +- src/mesa/drivers/dri/intel/intel_tex_image.c | 60 ++ src/mesa/drivers/dri/nouveau/nouveau_texture.c | 43 +++--- src/mesa/drivers/dri/radeon/radeon_texture.c | 41 ++-- src/mesa/main/dd.h | 44 +++-- src/mesa/main/teximage.c | 36 ++- src/mesa/main/texobj.c | 28 +--- src/mesa/main/texstore.c | 78 src/mesa/main/texstore.h | 31 ++--- src/mesa/state_tracker/st_cb_texture.c | 51 +++- 10 files changed, 73 insertions(+), 343 deletions(-) Looks great. I haven't tested it, but I read through all of them carefully. Nice attention to detail making sure 1 got passed in instead of 0 (so it doesn't return doing nothing), and adding the dims != 2, dims == 3 checks in driver specific upload code. For the series: Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/25] i915 HW context support
On 06/04/2012 02:42 PM, Ben Widawsky wrote: Setting myself up for a late night crying session once again. Most of the people reading this probably know the history and reasons for the patches. If not, you can search the intel-gfx mailing list to try to learn more. I won't recap the whole thing here, and instead let the patches speak for themselves. Instead a brief review of what's here, and what's happened. Mostly, these badly need testing and review. I've carried these around for so long now, and seen so many different failures, I'm quite paranoid they still aren't perfect. Also, I've spent almost all of the time working on this in the kernel, so there is bound to be simple errors in the other stuff. I've run these on various workloads and saw nothing worth mentioning. 0-16: kernel patches 17-21: libdrm patches (wait render patch is temporary) Patches 17-21 look fine. Reviewed-by: Kenneth Graunke kenn...@whitecape.org 22-24: intel-gpu-tools 25: mesa Patch 25 looks fine too. Feel free to apply some combination of: Reviewed-by: Kenneth Graunke kenn...@whitecape.org Signed-off-by: Kenneth Graunke kenn...@whitecape.org I do like Paul's comment updates, so I suggest merging those. kernel git://people.freedesktop.org/~bwidawsk/drm-intel context_support_rev2 libdrm git://people.freedesktop.org/~bwidawsk/drm context_support_rev2 i-g-t git://people.freedesktop.org/~bwidawsk/intel-gpu-tools context_support ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
On 5 June 2012 14:42, Ian Romanick i...@freedesktop.org wrote: On 06/04/2012 03:23 PM, Paul Berry wrote: On 4 June 2012 14:50, Ian Romanick i...@freedesktop.org mailto:i...@freedesktop.org wrote: On 06/04/2012 01:31 PM, Olivier Galibert wrote: On Mon, Jun 04, 2012 at 01:11:13PM -0700, Ian Romanick wrote: From: Ian Romanickian.d.romanick@intel.**__com mailto:ian.d.romanick@intel.**com ian.d.roman...@intel.com In single precision, 1.5707963 becomes 1.5707962513 tel:1.5707962513 which is too small. However, 1.5707964 becomes 1.5707963705 tel:1.5707963705 which is just right. The value 1.5707964 is already used in asin.ir http://asin.ir . NOTE: This is a candidate for stable release branches. If piglit stops bitching on that partical problem thanks to such a small change, it's just beautiful. It does fix the acos issue in piglit. The closed-source test suite that we use still isn't happy, but I think that just means we need better approximations for acos and asin. asin(vec4(.2, .6, .8, 1.)) has an absolute error of (0.105351 0.0001987219 0.0001262426 0.003576). The results for .6 and .8 are especially bad, but even the .2 result should be better. The closed-source test suite wants an absolute error of 1e-5 for asin and acos. Do we have any quantitative information about how much accuracy is really needed for asin? Of course, an error of 1.9e-4 would be embarrassingly bad for scientific use, but are you sure that it isn't adequate for graphics purposes? I'd hate to spend a lot of effort The test expects an absolute error not more than 1e-5, and other desktop implementations achieve that. I don't think we should be significantly less precise than other implementations. Ok, the fact that other desktop implementations achieve 1e-5 is enough to convince me. implementing a more accurate asin, only to find that the only user-visible effect is for shaders to run slower because we're doing more accurate math. As fun as it is to numerically approximate trig functions (I'm not even kidding--I love this stuff and I'm jealous that I didn't think for even a fraction of a second that you were kidding. :) I don't have time to work on it right now) I'm not convinced it's worth it yet. Having said that, I *do* think it's worth making sure the asin function is well-behaved enough near zero that derivatives won't do unexpected things. If you do wind up working on this, I hope you'll keep the improvements I made last july (**d4c80f5f85c749df3fc091ff07b60e** f4989fa6d9) where I made the first two terms of the approximation pi/2 and pi/4-1. If these terms aren't exact, then asin behaves poorly near zero. Right. I've been trying to think of a good way to test this, but I keep coming up empty handed. The best idea I've got so far would be a shader_runner test with a fragment shader that computes dFdx(asin(x)), compares it to the theoretical closed form derivative of asin(x) (which is 1/sqrt(1-x^2)), and draws red pixels if the result is outside a certain error tolerance. We'd probably want to use a relative error (since the derivative of asin(x) can get quite large) and stop a bit shy of the endpoints where it goes to infinity. Do we need a better precision atan, or should piglit just be told to shutup? The shutup patch has been sent it ages ago, but I can't do the more precision one if that's what's wanted. I think we need a better atan. The result that it produces is not very good. I plan to look into that more tonight. FYI, our formulas for atan and acos are exact trig identities in terms of asin, so probably any improvement made to asin will carry over to the others, at least until you reach the realm of rounding errors (which I'm guessing you won't reach if your target is 1e-5). That's a good point. Starting with asin may bear fruit more quickly than starting with atan. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 50754] New: Building 32 bit mesa on 64 bit OS fails since change for automake
https://bugs.freedesktop.org/show_bug.cgi?id=50754 Bug #: 50754 Summary: Building 32 bit mesa on 64 bit OS fails since change for automake Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: All Status: NEW Severity: major Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: alexandre.f.dem...@gmail.com Since the last couple of days, I'm unable to build mesa. It appeared after the automake move. I can't bisect since another automake bug was in the way, but I'm sure it is related to this move. I'm using git 17e047242e82111859eb8220369c601c79a26350. The files ld is looking for exist under /usr/lib32 and /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/32/. make[3]: Entering directory `/home/dema1701/projects/display/mesa/src/mesa/libdricore' CXXLDlibdricore.la /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/libstdc++.so when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/libstdc++.a when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/../lib/libstdc++.so when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/../lib/libstdc++.a when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../libstdc++.so when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../libstdc++.a when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/libm.a when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/../lib/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/../lib/libm.a when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../libm.a when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/libc.a when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.a when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../libc.a when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: skipping incompatible /usr/lib/../lib/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../libgcc_s.so when searching for -lgcc_s /usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/crti.o' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/crtbeginS.o' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/crtendS.o' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/crtn.o' is incompatible with i386 output collect2: error: ld returned 1 exit status make[3]: *** [libdricore.la] Error 1 make[3]: Leaving directory `/home/dema1701/projects/display/mesa/src/mesa/libdricore' make[2]: *** [dricore] Error 2 make[2]: Leaving directory `/home/dema1701/projects/display/mesa/src/mesa' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/dema1701/projects/display/mesa/src' make: *** [default] Error 1 -- 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 50754] Building 32 bit mesa on 64 bit OS fails since change for automake
https://bugs.freedesktop.org/show_bug.cgi?id=50754 Kenneth Graunke kenn...@whitecape.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Kenneth Graunke kenn...@whitecape.org 2012-06-05 21:46:43 PDT --- One change is that the --enable-32-bit configure option doesn't propagate -m32 to all the right places anymore. I was able to successfully build Mesa master with: CFLAGS='-m32' CXXFLAGS='-m32' ./autogen.sh --enable-32-bit --enable-gles2 --enable-gles1 --disable-glu --with-gallium-drivers= --with-dri-drivers=swrast,i965 --enable-texture-float --enable-debug --enable-shared-glapi --enable-glx-tls I'm going to assume you didn't specify CFLAGS/CXXFLAGS and close the bug, but feel free to reopen if that doesn't work for you. -- 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 50754] Building 32 bit mesa on 64 bit OS fails since change for automake
https://bugs.freedesktop.org/show_bug.cgi?id=50754 --- Comment #2 from Tapani Pälli lem...@gmail.com 2012-06-05 22:34:48 PDT --- I'm hitting this issue in linking phase as well, I've tried to hunt down where it all fails and my main suspect is libtool, either its usage of '-nostdlib' or maybe its hitting this one : https://projects.coin-or.org/BuildTools/ticket/13 Quote from the bug : The problem is (at least for -m32 on x86_84) that libtool sets sys_lib_search_path_spec incorrectly. If the GNU compiler is used, it gets the value from gcc -print-search-dirs, which doesn't give the correct values for compilation with the -m32 flag. -- 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
