Re: [Mesa-dev] [PATCH] egl_dri2: Fix out of tree builds with the wayland backend enabled
On 2012-05-03 02:31 +0200, Kenneth Graunke wrote: On 05/02/2012 04:04 PM, Robert Hooker wrote: Otherwise it fails like so: CC egl_dri2.lo In file included from egl_dri2.h:40:0, from egl_dri2.c:42: ../../../../../../src/egl/wayland/wayland-drm/wayland-drm.h:8:41: fatal error: wayland-drm-server-protocol.h: No such file or directory compilation terminated. --- src/egl/drivers/dri2/Makefile.am |1 + 1 file changed, 1 insertion(+) diff --git a/src/egl/drivers/dri2/Makefile.am b/src/egl/drivers/dri2/Makefile.am index e4d4abb..49ec06b 100644 --- a/src/egl/drivers/dri2/Makefile.am +++ b/src/egl/drivers/dri2/Makefile.am @@ -26,6 +26,7 @@ AM_CFLAGS = \ -I$(top_srcdir)/src/gbm/backends/dri \ -I$(top_srcdir)/src/egl/wayland/wayland-egl \ -I$(top_srcdir)/src/egl/wayland/wayland-drm \ +-I$(top_builddir)/src/egl/wayland/wayland-drm \ $(DEFINES) \ $(LIBDRM_CFLAGS) \ $(LIBUDEV_CFLAGS) \ Is $(top_srcdir)/src/egl/wayland/wayland-drm still necessary? Apparently not. Cheers, Sven ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Cannot build mesa with wayland from the 0.85 branch
Hi folks, Building the wayland backend in mesa with wayland from the 0.85 branch fails: , | make[5]: Entering directory `/usr/local/src/deb-src/mesa/mesa/build/dri/src/gallium/state_trackers/egl' | gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/egl/main -I../../../../src/egl/wayland/wayland-drm/ -I../../../../include -I../../../../src/gallium/winsys -I../../../../src/egl/wayland/wayland-egl -I../../../../src/egl/wayland/wayland-drm -I/usr/include/libdrm -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DIN_DRI_DRIVER -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_LLVM=0x0209 -DHAVE_WAYLAND_BACKEND -Wall -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -Wall -g -O2 -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DIN_DRI_DRIVER -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTH READS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_LLVM=0x0209 -DHAVE_WAYLAND_BACKEND -fvisibility=hidden wayland/native_shm.c -o wayland/native_shm.o | wayland/native_shm.c: In function 'wayland_create_shm_buffer': | wayland/native_shm.c:109:4: error: implicit declaration of function 'wl_shm_create_pool' [-Werror=implicit-function-declaration] | wayland/native_shm.c:109:9: warning: assignment makes pointer from integer without a cast [enabled by default] | wayland/native_shm.c:110:4: error: implicit declaration of function 'wl_shm_pool_create_buffer' [-Werror=implicit-function-declaration] | wayland/native_shm.c:110:11: warning: assignment makes pointer from integer without a cast [enabled by default] | wayland/native_shm.c:112:4: error: implicit declaration of function 'wl_shm_pool_destroy' [-Werror=implicit-function-declaration] | cc1: some warnings being treated as errors | make[5]: *** [wayland/native_shm.o] Error 1 ` The reason for this is commit 9ba3cecaa (st/egl: Update to the new wl_shm_pool interface), the interface in question only exist in wayland master. Is building mesa with wayland from the 0.85 branch still supported? Cheers, Sven ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] libGL.so.* are not installed when configured with --enable-xlib-glx
When configuring mesa git master with --enable-xlib-glx, the GL library does not get installed. I configured mesa like this: , | % ./configure --enable-xlib-glx --without-gallium-drivers \ | --without-dri-drivers --disable-egl --prefix=/tmp/mesa ` and after running make, have the following files in lib: , | % ls -1 lib | libGL.so | libGL.so.1 | libGL.so.1.5.08000 | libGLU.so | libGLU.so.1 | libGLU.so.1.3.08000 | libdricore.so | libglsl.so ` However, the libGL.so* files do not get installed: , | % ls -1R /tmp/mesa/lib | /tmp/mesa/lib: | dri | libGLU.so | libGLU.so.1 | libGLU.so.1.3.08000 | pkgconfig | | /tmp/mesa/lib/dri: | libdricore.so | libglsl.so | | /tmp/mesa/lib/pkgconfig: | dri.pc | gl.pc | glu.pc ` What went wrong? Cheers, Sven ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
On Thu, May 3, 2012 at 3:32 AM, Chad Versace chad.vers...@linux.intel.com wrote: (FYI, if I understand the gallium code, the only drivers that currently enable both are Intel, swrast, and OSMesa). Gallium also enables both if packed depth-stencil textures are supported (which is the case with most, if not all, drivers). Otherwise, it only enables the EXT variant. 2. Create separate entry points: - _mesa_BindFramebufferEXT, which implements - glBindFramebufferEXT - glBindFramebufferOES - glBindFramebuffer in GLES2 - _mesa_BindFramebufferARB, which implements - glBindFramebufferARB - glBindFramebuffer in GL 3.x Any opinions? (I slightly prefer 2). FWIW, 2 seems to be a good plan to me too. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gbm: Add gbm_bo_write entry point
I did a simple test here and the patch worked. I have just a couple of
comments.
On 05/02/2012 10:32 PM, Kristian Høgsberg wrote:
This new gbm entry point allows writing data into a gbm bo. The bo has
to be created with the GBM_BO_USE_WRITE flag, and it's only required to
work for GBM_BO_USE_CURSOR_64X64 bos.
The gbm API is designed to be the glue layer between EGL and KMS, but there
was never a mechanism initialize a buffer suitable for use with KMS
hw cursors. The hw cursor bo is typically not compatible with anything EGL
can render to, and thus there's no way to get data into such a bo.
gbm_bo_write() fills that gap while staying out of the efficient
cpu-gpu pixel transfer business.
---
include/GL/internal/dri_interface.h | 10 +-
src/gbm/backends/dri/gbm_dri.c| 18 ++
src/gbm/main/gbm.c| 19 +++
src/gbm/main/gbm.h|9 +
src/gbm/main/gbmint.h |1 +
src/mesa/drivers/dri/intel/intel_screen.c | 24 ++--
6 files changed, 78 insertions(+), 3 deletions(-)
[...]
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 9db5606..e945d14 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -305,6 +305,11 @@ intel_create_image(__DRIscreen *screen,
tiling = I915_TILING_NONE;
}
+ /* 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;
+
Shouldn't we have a similar check in intel_validate_usage()?
image = CALLOC(sizeof *image);
if (image == NULL)
return NULL;
@@ -411,15 +416,30 @@ intel_validate_usage(__DRIimage *image, unsigned int use)
return GL_TRUE;
}
+static int
+intel_image_write(__DRIimage *image, const void *buf, size_t count)
+{
+ if (image-region-map_refcount)
+ return -1;
+ /* if use != WRITE || region-map_refcount; return -1; */
Did you intend to check for write usage here?
Other than this,
Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gbm: Add gbm_bo_write entry point
Hi Kristian,
s/gbm_bo_write/gbm_bo_write_to_cursor/g and make fail on anything
other then cursors and I'm happy. Not making it just happen
to work on some hardware really sucks for those that it doesn't
work on because people will expect it to work.
Cheers, Jakob.
- Original Message -
This new gbm entry point allows writing data into a gbm bo. The bo
has to be created with the GBM_BO_USE_WRITE flag, and it's only
required to work for GBM_BO_USE_CURSOR_64X64 bos.
The gbm API is designed to be the glue layer between EGL and KMS, but
there was never a mechanism initialize a buffer suitable for use with
KMS hw cursors. The hw cursor bo is typically not compatible with
anything EGL can render to, and thus there's no way to get data into
such a bo.
gbm_bo_write() fills that gap while staying out of the efficient
cpu-gpu pixel transfer business.
---
include/GL/internal/dri_interface.h | 10 +-
src/gbm/backends/dri/gbm_dri.c| 18 ++
src/gbm/main/gbm.c| 19 +++
src/gbm/main/gbm.h|9 +
src/gbm/main/gbmint.h |1 +
src/mesa/drivers/dri/intel/intel_screen.c | 24
++--
6 files changed, 78 insertions(+), 3 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index eafbe10..e37917e 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -894,7 +894,7 @@ struct __DRIdri2ExtensionRec {
* extensions.
*/
#define __DRI_IMAGE DRI_IMAGE
-#define __DRI_IMAGE_VERSION 3
+#define __DRI_IMAGE_VERSION 4
/**
* These formats correspond to the similarly named MESA_FORMAT_*
@@ -911,6 +911,7 @@ struct __DRIdri2ExtensionRec {
#define __DRI_IMAGE_USE_SHARE0x0001
#define __DRI_IMAGE_USE_SCANOUT 0x0002
#define __DRI_IMAGE_USE_CURSOR 0x0004
+#define __DRI_IMAGE_USE_WRITE0x0008
/**
* queryImage attributes
@@ -955,6 +956,13 @@ struct __DRIimageExtensionRec {
* \since 2
*/
GLboolean (*validateUsage)(__DRIimage *image, unsigned int use);
+
+ /**
+* Write data into image.
+*
+* \since 4
+*/
+ int (*write)(__DRIimage *image, const void *buf, size_t count);
};
diff --git a/src/gbm/backends/dri/gbm_dri.c
b/src/gbm/backends/dri/gbm_dri.c
index 4df6e8f..e5ddfb6 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -291,6 +291,18 @@ gbm_dri_is_format_supported(struct gbm_device
*gbm,
return 1;
}
+static int
+gbm_dri_bo_write(struct gbm_bo *_bo, const void *buf, size_t count)
+{
+ struct gbm_dri_device *dri = gbm_dri_device(_bo-gbm);
+ struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
+
+ if (dri-image-base.version 4)
+ return -1;
+
+ return dri-image-write(bo-image, buf, count);
+}
+
static void
gbm_dri_bo_destroy(struct gbm_bo *_bo)
{
@@ -390,6 +402,9 @@ gbm_dri_bo_create(struct gbm_device *gbm,
int dri_format;
unsigned dri_use = 0;
+ if (dri-image-base.version 4 (usage GBM_BO_USE_WRITE))
+ return NULL;
+
bo = calloc(1, sizeof *bo);
if (bo == NULL)
return NULL;
@@ -421,6 +436,8 @@ gbm_dri_bo_create(struct gbm_device *gbm,
dri_use |= __DRI_IMAGE_USE_SCANOUT;
if (usage GBM_BO_USE_CURSOR_64X64)
dri_use |= __DRI_IMAGE_USE_CURSOR;
+ if (usage GBM_BO_USE_WRITE)
+ dri_use |= __DRI_IMAGE_USE_WRITE;
bo-image =
dri-image-createImage(dri-screen,
@@ -491,6 +508,7 @@ dri_device_create(int fd)
dri-base.base.bo_create = gbm_dri_bo_create;
dri-base.base.bo_create_from_egl_image =
gbm_dri_bo_create_from_egl_image;
dri-base.base.is_format_supported = gbm_dri_is_format_supported;
+ dri-base.base.bo_write = gbm_dri_bo_write;
dri-base.base.bo_destroy = gbm_dri_bo_destroy;
dri-base.base.destroy = dri_destroy;
dri-base.base.surface_create = gbm_dri_surface_create;
diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 987e965..3994f86 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -231,6 +231,25 @@ gbm_bo_get_handle(struct gbm_bo *bo)
return bo-handle;
}
+/** Write data into the buffer object
+ *
+ * If the buffer object was created with the GBM_BO_USE_WRITE flag,
+ * this function can used to write data into the buffer object. The
+ * data is copied directly into the object and it's the
responsiblity
+ * of the caller to make sure the data represents valid pixel data,
+ * according to the width, height, stride and format of the buffer
object.
+ *
+ * \param bo The buffer object
+ * \param buf The data to write
+ * \param count The number of bytes to write
+ * \return Returns -1 on error, 0 otherwise
+ */
+GBM_EXPORT int
+gbm_bo_write(struct gbm_bo *bo, const void *buf, size_t count)
+{
Re: [Mesa-dev] Cannot build mesa with wayland from the 0.85 branch
On 2012-05-03 07:20 +0200, Sven Joachim wrote: Building the wayland backend in mesa with wayland from the 0.85 branch fails: , | make[5]: Entering directory `/usr/local/src/deb-src/mesa/mesa/build/dri/src/gallium/state_trackers/egl' | gcc -c -I. -I../../../../src/gallium/include | -I../../../../src/gallium/auxiliary -I../../../../src/egl/main | -I../../../../src/egl/wayland/wayland-drm/ -I../../../../include | -I../../../../src/gallium/winsys | -I../../../../src/egl/wayland/wayland-egl | -I../../../../src/egl/wayland/wayland-drm -I/usr/include/libdrm | -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED | -DHAVE_POSIX_MEMALIGN -DIN_DRI_DRIVER -DUSE_XCB | -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS | -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS | -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_LLVM=0x0209 | -DHAVE_WAYLAND_BACKEND -Wall -g -O2 -Wall -std=c99 | -Werror=implicit-function-declaration -Werror=missing-prototypes | -fno-strict-aliasing -fno-builtin-memcmp -Wall -g -O2 -fPIC | -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM | -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED | -DHAVE_POSIX_MEMALIGN -DIN_DRI_DRIVER -DUSE_XCB | -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS | -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS | -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_LLVM=0x0209 | -DHAVE_WAYLAND_BACKEND -fvisibility=hidden wayland/native_shm.c -o | wayland/native_shm.o | wayland/native_shm.c: In function 'wayland_create_shm_buffer': | wayland/native_shm.c:109:4: error: implicit declaration of function | wl_shm_create_pool' [-Werror=implicit-function-declaration] | wayland/native_shm.c:109:9: warning: assignment makes pointer from integer without a cast [enabled by default] | wayland/native_shm.c:110:4: error: implicit declaration of function | wl_shm_pool_create_buffer' [-Werror=implicit-function-declaration] | wayland/native_shm.c:110:11: warning: assignment makes pointer from integer without a cast [enabled by default] | wayland/native_shm.c:112:4: error: implicit declaration of function | wl_shm_pool_destroy' [-Werror=implicit-function-declaration] | cc1: some warnings being treated as errors | make[5]: *** [wayland/native_shm.o] Error 1 ` The reason for this is commit 9ba3cecaa (st/egl: Update to the new wl_shm_pool interface), the interface in question only exist in wayland master. After reverting commit 9ba3cecaa the build succeeded. Cheers, Sven ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gbm: Add gbm_bo_write entry point
On Thu, May 3, 2012 at 7:05 AM, Ander Conselvan de Oliveira
conselv...@gmail.com wrote:
I did a simple test here and the patch worked. I have just a couple of
comments.
Good points, patch updated.
Kristian
On 05/02/2012 10:32 PM, Kristian Høgsberg wrote:
This new gbm entry point allows writing data into a gbm bo. The bo has
to be created with the GBM_BO_USE_WRITE flag, and it's only required to
work for GBM_BO_USE_CURSOR_64X64 bos.
The gbm API is designed to be the glue layer between EGL and KMS, but
there
was never a mechanism initialize a buffer suitable for use with KMS
hw cursors. The hw cursor bo is typically not compatible with anything
EGL
can render to, and thus there's no way to get data into such a bo.
gbm_bo_write() fills that gap while staying out of the efficient
cpu-gpu pixel transfer business.
---
include/GL/internal/dri_interface.h | 10 +-
src/gbm/backends/dri/gbm_dri.c | 18 ++
src/gbm/main/gbm.c | 19 +++
src/gbm/main/gbm.h | 9 +
src/gbm/main/gbmint.h | 1 +
src/mesa/drivers/dri/intel/intel_screen.c | 24 ++--
6 files changed, 78 insertions(+), 3 deletions(-)
[...]
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 9db5606..e945d14 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -305,6 +305,11 @@ intel_create_image(__DRIscreen *screen,
tiling = I915_TILING_NONE;
}
+ /* 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;
+
Shouldn't we have a similar check in intel_validate_usage()?
image = CALLOC(sizeof *image);
if (image == NULL)
return NULL;
@@ -411,15 +416,30 @@ intel_validate_usage(__DRIimage *image, unsigned int
use)
return GL_TRUE;
}
+static int
+intel_image_write(__DRIimage *image, const void *buf, size_t count)
+{
+ if (image-region-map_refcount)
+ return -1;
+ /* if use != WRITE || region-map_refcount; return -1; */
Did you intend to check for write usage here?
Other than this,
Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gbm: Add gbm_bo_write entry point
On Thu, May 3, 2012 at 7:47 AM, Jakob Bornecrantz ja...@vmware.com wrote:
Hi Kristian,
s/gbm_bo_write/gbm_bo_write_to_cursor/g and make fail on anything
other then cursors and I'm happy. Not making it just happen
to work on some hardware really sucks for those that it doesn't
work on because people will expect it to work.
I think we have a good compromise the way the patch is. I don't want
to restrict the write entrypoint to only cursors. Not because I think
it should work with generic gbm bos, but becase I don't want to
preclude gbm_bo_write from working with a future similar restricted,
special case bo type.
Kristian
Cheers, Jakob.
- Original Message -
This new gbm entry point allows writing data into a gbm bo. The bo
has to be created with the GBM_BO_USE_WRITE flag, and it's only
required to work for GBM_BO_USE_CURSOR_64X64 bos.
The gbm API is designed to be the glue layer between EGL and KMS, but
there was never a mechanism initialize a buffer suitable for use with
KMS hw cursors. The hw cursor bo is typically not compatible with
anything EGL can render to, and thus there's no way to get data into
such a bo.
gbm_bo_write() fills that gap while staying out of the efficient
cpu-gpu pixel transfer business.
---
include/GL/internal/dri_interface.h | 10 +-
src/gbm/backends/dri/gbm_dri.c | 18 ++
src/gbm/main/gbm.c | 19 +++
src/gbm/main/gbm.h | 9 +
src/gbm/main/gbmint.h | 1 +
src/mesa/drivers/dri/intel/intel_screen.c | 24
++--
6 files changed, 78 insertions(+), 3 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index eafbe10..e37917e 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -894,7 +894,7 @@ struct __DRIdri2ExtensionRec {
* extensions.
*/
#define __DRI_IMAGE DRI_IMAGE
-#define __DRI_IMAGE_VERSION 3
+#define __DRI_IMAGE_VERSION 4
/**
* These formats correspond to the similarly named MESA_FORMAT_*
@@ -911,6 +911,7 @@ struct __DRIdri2ExtensionRec {
#define __DRI_IMAGE_USE_SHARE 0x0001
#define __DRI_IMAGE_USE_SCANOUT 0x0002
#define __DRI_IMAGE_USE_CURSOR 0x0004
+#define __DRI_IMAGE_USE_WRITE 0x0008
/**
* queryImage attributes
@@ -955,6 +956,13 @@ struct __DRIimageExtensionRec {
* \since 2
*/
GLboolean (*validateUsage)(__DRIimage *image, unsigned int use);
+
+ /**
+ * Write data into image.
+ *
+ * \since 4
+ */
+ int (*write)(__DRIimage *image, const void *buf, size_t count);
};
diff --git a/src/gbm/backends/dri/gbm_dri.c
b/src/gbm/backends/dri/gbm_dri.c
index 4df6e8f..e5ddfb6 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -291,6 +291,18 @@ gbm_dri_is_format_supported(struct gbm_device
*gbm,
return 1;
}
+static int
+gbm_dri_bo_write(struct gbm_bo *_bo, const void *buf, size_t count)
+{
+ struct gbm_dri_device *dri = gbm_dri_device(_bo-gbm);
+ struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
+
+ if (dri-image-base.version 4)
+ return -1;
+
+ return dri-image-write(bo-image, buf, count);
+}
+
static void
gbm_dri_bo_destroy(struct gbm_bo *_bo)
{
@@ -390,6 +402,9 @@ gbm_dri_bo_create(struct gbm_device *gbm,
int dri_format;
unsigned dri_use = 0;
+ if (dri-image-base.version 4 (usage GBM_BO_USE_WRITE))
+ return NULL;
+
bo = calloc(1, sizeof *bo);
if (bo == NULL)
return NULL;
@@ -421,6 +436,8 @@ gbm_dri_bo_create(struct gbm_device *gbm,
dri_use |= __DRI_IMAGE_USE_SCANOUT;
if (usage GBM_BO_USE_CURSOR_64X64)
dri_use |= __DRI_IMAGE_USE_CURSOR;
+ if (usage GBM_BO_USE_WRITE)
+ dri_use |= __DRI_IMAGE_USE_WRITE;
bo-image =
dri-image-createImage(dri-screen,
@@ -491,6 +508,7 @@ dri_device_create(int fd)
dri-base.base.bo_create = gbm_dri_bo_create;
dri-base.base.bo_create_from_egl_image =
gbm_dri_bo_create_from_egl_image;
dri-base.base.is_format_supported = gbm_dri_is_format_supported;
+ dri-base.base.bo_write = gbm_dri_bo_write;
dri-base.base.bo_destroy = gbm_dri_bo_destroy;
dri-base.base.destroy = dri_destroy;
dri-base.base.surface_create = gbm_dri_surface_create;
diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 987e965..3994f86 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -231,6 +231,25 @@ gbm_bo_get_handle(struct gbm_bo *bo)
return bo-handle;
}
+/** Write data into the buffer object
+ *
+ * If the buffer object was created with the GBM_BO_USE_WRITE flag,
+ * this function can used to write data into the buffer object. The
+ * data is copied directly into the object and it's the
responsiblity
+ * of the caller to make sure the
Re: [Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
On 05/02/2012 06:32 PM, Chad Versace wrote: Mesa has problems in the way it implements glBindFramebuffer and glBindFramebufferEXT due to both being implemented by an overloaded _mesa_BindFramebufferEXT. This problem causes an Android app [1] to crash, and I want your opinion on how we should fix it. The problem is that in the five specs in the subject line, the specified behavior of glBindFramebuffer falls into two incompatible categories. Mesa implements the wrong behavior for OES_fbo, EXT_fbo, and GLES2 when ARB_fbo is internally enabled. [1] Pauli and Charles (CC'd) have more details about this crash, including an apitrace, if you're curious. Behavior in Category A: ARB_fbo and GL3.0 - The behavior in these specs can be summarized as: 1a. glBindFramebuffer may be called only on fb names produced by glGenFramebuffers. 2a. glBindFramebuffer may not be called on an fb name previously deleted with glDeleteFramebuffers. Below is the pertinent quote from the ARB_fbo spec. The language in the GL 3.0 spec is nearly identical. A framebuffer object is created by binding a name returned by GenFramebuffers (see below) to DRAW_FRAMEBUFFER or READ_FRAMEBUFFER. The binding is effected by calling void BindFramebuffer(enum target, uint framebuffer); [...] BindFramebuffer fails and an INVALID_OPERATION error is generated if framebuffer is not zero or a name returned from a previous call to GenFramebuffers, or if such a name has since been deleted with DeleteFramebuffers. Behavior in Category B: EXT/OES_fbo and GLES2 -- The behavior in these specs can be summarized as below. This behavior is incompatible with points 1a and 2a. 1b. glBindFramebuffer may be called on any unused fb name. 2b. glBindFramebuffers may be called on an fb name previously deleted with glDeleteFramebuffers because, according to these specs, deletion marks a name as unused. Below is the pertininent quote from the EXT_fbo spec. The language of the GLES 2 spec is nearly identical, but without the EXT suffix. The OES_fbo spec refers to the EXT_fbo spec. The namespace for framebuffer objects is the unsigned integers, with zero reserved by the GL to refer to the default framebuffer. A framebuffer object is created by binding an unused name to the target FRAMEBUFFER_EXT. The binding is effected by calling void BindFramebufferEXT(enum target, uint framebuffer); [...] Framebuffer objects are deleted by calling void DeleteFramebuffersEXT(sizei n, uint *framebuffers); framebuffers containsn names of framebuffer objects to be deleted. After a framebuffer object is deleted, [...], and its name is again unused. The Crashing App We have an Android app that does this: glGenFramebuffers(1,fb); glBindFramebuffer(GL_FRAMEBUFFER, fb); // render render render... glDeleteFramebuffers(1,fb); // go do other stuff... glBindFramebuffer(GL_FRAMEBUFFER, fb); // This bind unexpectedly failed, and the app panics. So... the app is expecting this to create a fresh FBO? The call to glBindFramebuffer fails because, in GLES1 and GLES2 contexts, the Intel drivers internally enables both ARB_fbo and EXT_fbo. In _mesa_BindFramebufferEXT, the ARB_fbo behavior wins. Solutions for core Mesa --- As for fixing _mesa_BindFramebufferEXT, I have two ideas. 1. Enforce in _mesa_BindFramebufferEXT that no more than one of ARB_fbo and EXT_fbo is enabled, then clean up its validation logic. This is a big hammer, and, if done right, can eliminate any ambiguities in behavior. (FYI, if I understand the gallium code, the only drivers that currently enable both are Intel, swrast, and OSMesa). I'm not a fan of this. We only redact functionality that don't believe anyone uses. I'm fairly sure there are still apps that will use EXT_fbo. 2. Create separate entry points: - _mesa_BindFramebufferEXT, which implements - glBindFramebufferEXT - glBindFramebufferOES - glBindFramebuffer in GLES2 - _mesa_BindFramebufferARB, which implements - glBindFramebufferARB - glBindFramebuffer in GL 3.x This is my preference. I believe vertex array objects work like this. See src/mesa/main/arrayobj.c. Any opinions? (I slightly prefer 2). Quick Solution for the Intel drivers A quick solution may be as simple as removing ARB_fbo from the Intel drivers' GLES1/2 extension lists. Do you see any problem in doing this? Charles, you have experimented with disabling ARB_fbo from GLES1/2 contexts. Did you observe any negative consequences? ___ mesa-dev mailing list
Re: [Mesa-dev] [PATCH] egl_dri2: Fix out of tree builds with the wayland backend enabled
On Wed, May 02, 2012 at 07:04:57PM -0400, Robert Hooker wrote: Otherwise it fails like so: CC egl_dri2.lo In file included from egl_dri2.h:40:0, from egl_dri2.c:42: ../../../../../../src/egl/wayland/wayland-drm/wayland-drm.h:8:41: fatal error: wayland-drm-server-protocol.h: No such file or directory compilation terminated. Thanks, applied. Kristian --- src/egl/drivers/dri2/Makefile.am |1 + 1 file changed, 1 insertion(+) diff --git a/src/egl/drivers/dri2/Makefile.am b/src/egl/drivers/dri2/Makefile.am index e4d4abb..49ec06b 100644 --- a/src/egl/drivers/dri2/Makefile.am +++ b/src/egl/drivers/dri2/Makefile.am @@ -26,6 +26,7 @@ AM_CFLAGS = \ -I$(top_srcdir)/src/gbm/backends/dri \ -I$(top_srcdir)/src/egl/wayland/wayland-egl \ -I$(top_srcdir)/src/egl/wayland/wayland-drm \ + -I$(top_builddir)/src/egl/wayland/wayland-drm \ $(DEFINES) \ $(LIBDRM_CFLAGS) \ $(LIBUDEV_CFLAGS) \ -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] Scaffolding for ARB_shader_bit_encoding.
On 05/02/2012 02:42 PM, Olivier Galibert wrote:
On Wed, May 02, 2012 at 02:17:31PM -0700, Ian Romanick wrote:
I've been trying to keep this list alphabetized.
Ok.
+ if (ctx-Const.NativeIntegers) {
+ ctx-Extensions.ARB_shader_bit_encoding = GL_TRUE;
+ }
+
Is this actually true? It seems like there's some GL 3.x hardware that
can't do this. Though, I may be mistaken.
It's doubtful. Registers tend to be untyped, only the operators are
typed. Bitwise conversion is a very fancy way of saying nop,
gpu-wise :-)
The problem is whether or not registers are untyped. The (potential)
problem is that this spec requires that floating point numbers are
stored as IEEE single precision. In any case, I did a bit of searching
through my archives, and it looks like all GL3 GPUs should be able to do
this. It appears this is why this small subset of functionality was
split out from GL_ARB_gpu_shader5.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gbm: Add gbm_bo_write entry point
- Ursprungligt meddelande -
On Thu, May 3, 2012 at 7:47 AM, Jakob Bornecrantz ja...@vmware.com
wrote:
Hi Kristian,
s/gbm_bo_write/gbm_bo_write_to_cursor/g and make fail on anything
other then cursors and I'm happy. Not making it just happen
to work on some hardware really sucks for those that it doesn't
work on because people will expect it to work.
I think we have a good compromise the way the patch is. I don't want
to restrict the write entrypoint to only cursors. Not because I
think
it should work with generic gbm bos, but becase I don't want to
preclude gbm_bo_write from working with a future similar restricted,
special case bo type.
Fair enough.
Can you put the if use != WRITE return -1; snippet in the
gbm_bo_write function or all the drivers supposed to validate the args?
Cheers, Jakob.
Kristian
Cheers, Jakob.
- Original Message -
This new gbm entry point allows writing data into a gbm bo. The
bo
has to be created with the GBM_BO_USE_WRITE flag, and it's only
required to work for GBM_BO_USE_CURSOR_64X64 bos.
The gbm API is designed to be the glue layer between EGL and KMS,
but
there was never a mechanism initialize a buffer suitable for use
with
KMS hw cursors. The hw cursor bo is typically not compatible with
anything EGL can render to, and thus there's no way to get data
into
such a bo.
gbm_bo_write() fills that gap while staying out of the efficient
cpu-gpu pixel transfer business.
---
include/GL/internal/dri_interface.h | 10 +-
src/gbm/backends/dri/gbm_dri.c | 18
++
src/gbm/main/gbm.c | 19
+++
src/gbm/main/gbm.h | 9 +
src/gbm/main/gbmint.h | 1 +
src/mesa/drivers/dri/intel/intel_screen.c | 24
++--
6 files changed, 78 insertions(+), 3 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index eafbe10..e37917e 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -894,7 +894,7 @@ struct __DRIdri2ExtensionRec {
* extensions.
*/
#define __DRI_IMAGE DRI_IMAGE
-#define __DRI_IMAGE_VERSION 3
+#define __DRI_IMAGE_VERSION 4
/**
* These formats correspond to the similarly named MESA_FORMAT_*
@@ -911,6 +911,7 @@ struct __DRIdri2ExtensionRec {
#define __DRI_IMAGE_USE_SHARE 0x0001
#define __DRI_IMAGE_USE_SCANOUT 0x0002
#define __DRI_IMAGE_USE_CURSOR 0x0004
+#define __DRI_IMAGE_USE_WRITE 0x0008
/**
* queryImage attributes
@@ -955,6 +956,13 @@ struct __DRIimageExtensionRec {
* \since 2
*/
GLboolean (*validateUsage)(__DRIimage *image, unsigned int
use);
+
+ /**
+ * Write data into image.
+ *
+ * \since 4
+ */
+ int (*write)(__DRIimage *image, const void *buf, size_t
count);
};
diff --git a/src/gbm/backends/dri/gbm_dri.c
b/src/gbm/backends/dri/gbm_dri.c
index 4df6e8f..e5ddfb6 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -291,6 +291,18 @@ gbm_dri_is_format_supported(struct gbm_device
*gbm,
return 1;
}
+static int
+gbm_dri_bo_write(struct gbm_bo *_bo, const void *buf, size_t
count)
+{
+ struct gbm_dri_device *dri = gbm_dri_device(_bo-gbm);
+ struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
+
+ if (dri-image-base.version 4)
+ return -1;
+
+ return dri-image-write(bo-image, buf, count);
+}
+
static void
gbm_dri_bo_destroy(struct gbm_bo *_bo)
{
@@ -390,6 +402,9 @@ gbm_dri_bo_create(struct gbm_device *gbm,
int dri_format;
unsigned dri_use = 0;
+ if (dri-image-base.version 4 (usage
GBM_BO_USE_WRITE))
+ return NULL;
+
bo = calloc(1, sizeof *bo);
if (bo == NULL)
return NULL;
@@ -421,6 +436,8 @@ gbm_dri_bo_create(struct gbm_device *gbm,
dri_use |= __DRI_IMAGE_USE_SCANOUT;
if (usage GBM_BO_USE_CURSOR_64X64)
dri_use |= __DRI_IMAGE_USE_CURSOR;
+ if (usage GBM_BO_USE_WRITE)
+ dri_use |= __DRI_IMAGE_USE_WRITE;
bo-image =
dri-image-createImage(dri-screen,
@@ -491,6 +508,7 @@ dri_device_create(int fd)
dri-base.base.bo_create = gbm_dri_bo_create;
dri-base.base.bo_create_from_egl_image =
gbm_dri_bo_create_from_egl_image;
dri-base.base.is_format_supported =
gbm_dri_is_format_supported;
+ dri-base.base.bo_write = gbm_dri_bo_write;
dri-base.base.bo_destroy = gbm_dri_bo_destroy;
dri-base.base.destroy = dri_destroy;
dri-base.base.surface_create = gbm_dri_surface_create;
diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 987e965..3994f86 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -231,6
Re: [Mesa-dev] [PATCH] gbm: Add gbm_bo_write entry point
- Ursprungligt meddelande - This new gbm entry point allows writing data into a gbm bo. The bo has to be created with the GBM_BO_USE_WRITE flag, and it's only required to work for GBM_BO_USE_CURSOR_64X64 bos. The gbm API is designed to be the glue layer between EGL and KMS, but there was never a mechanism initialize a buffer suitable for use with KMS hw cursors. The hw cursor bo is typically not compatible with anything EGL can render to, and thus there's no way to get data into such a bo. gbm_bo_write() fills that gap while staying out of the efficient cpu-gpu pixel transfer business. Actually I was thinking of libkms when reviewing this patch. Sorry but I'm going to strongly NAK this patch, if you had done the gallium part of this you would have known why. The reason is that there is no way to upload data to a buffer in Gallium without a context and there is a big chance that the context will try to get into the efficient cpu-gpu business whether you like it or not. This all means that the gbm_device is a rendering context and if we ever want to do something better of synchronizing between context then the FIFO approach we have now we all of a sudden need to add fences to gbm. And I'm strongly opposed to this. Can we work out something else for this? Cheers, Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
On Wed, 02 May 2012 18:32:01 -0700, Chad Versace chad.vers...@linux.intel.com
wrote:
Solutions for core Mesa
---
As for fixing _mesa_BindFramebufferEXT, I have two ideas.
1. Enforce in _mesa_BindFramebufferEXT that no more than one of ARB_fbo
and EXT_fbo is enabled, then clean up its validation logic. This is
a big hammer, and, if done right, can eliminate any ambiguities in
behavior.
(FYI, if I understand the gallium code, the only drivers that currently
enable both are Intel, swrast, and OSMesa).
2. Create separate entry points:
- _mesa_BindFramebufferEXT, which implements
- glBindFramebufferEXT
- glBindFramebufferOES
- glBindFramebuffer in GLES2
- _mesa_BindFramebufferARB, which implements
- glBindFramebufferARB
- glBindFramebuffer in GL 3.x
3. Just change this hunk of _msea_BindFramebufferEXT:
else if (!newDrawFb ctx-Extensions.ARB_framebuffer_object) {
/* All FBO IDs must be Gen'd */
_mesa_error(ctx, GL_INVALID_OPERATION, glBindFramebuffer(buffer));
return;
}
to just not throw the error if EXT_fbo or if the API is ES2?
pgpwcLkijtE6P.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/03/2012 10:33 AM, Eric Anholt wrote:
On Wed, 02 May 2012 18:32:01 -0700, Chad Versace
chad.vers...@linux.intel.com wrote:
Solutions for core Mesa
---
As for fixing _mesa_BindFramebufferEXT, I have two ideas.
1. Enforce in _mesa_BindFramebufferEXT that no more than one of ARB_fbo
and EXT_fbo is enabled, then clean up its validation logic. This is
a big hammer, and, if done right, can eliminate any ambiguities in
behavior.
(FYI, if I understand the gallium code, the only drivers that currently
enable both are Intel, swrast, and OSMesa).
2. Create separate entry points:
- _mesa_BindFramebufferEXT, which implements
- glBindFramebufferEXT
- glBindFramebufferOES
- glBindFramebuffer in GLES2
- _mesa_BindFramebufferARB, which implements
- glBindFramebufferARB
- glBindFramebuffer in GL 3.x
3. Just change this hunk of _msea_BindFramebufferEXT:
else if (!newDrawFb ctx-Extensions.ARB_framebuffer_object) {
/* All FBO IDs must be Gen'd */
_mesa_error(ctx, GL_INVALID_OPERATION, glBindFramebuffer(buffer));
return;
}
to just not throw the error if EXT_fbo or if the API is ES2?
I don't believe 3 will work.
Suppose we are in a GL3.x context with EXT_fbo advertised.
Once the execution path has entered _mesa_BindFramebufferEXT, it is not
possible to know
if the client called glBindFramebuffer (which has ARB_fbo semantics) or called
glBindFramebufferEXT, yet the two functions have different behavior. As far as
I can tell,
the only way to give the functions different behavior is create separate API
entry points.
-
Chad Versace
chad.vers...@linux.intel.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJPos58AAoJEAIvNt057x8ier0P/363zaXqqMaF5QN1qJXnBteg
Sz45Kn4yseubOHQ+Hrsx4PVoRI6UtpR1wlVnD9/vSiVU9u/uA8jBLDMd//oZ73xA
hVXy+UfiFv/d/yJqXMIR1gvli0mtThOdpZD8LVN7whAVYILyZQdBQE66OBd5RNY4
MEUVYpCbIuLUN6k0Zq7KP8V0j8yk5OmbxBKT71finxYUsq0HNjNQ5UaCZLVtrL06
wiz5Y07P3G8QOrbLLXSVNvBglj58llEkF6BjrKb13/tRnKs40UEnN5tTZ8A1T2F9
EI0yZga8B/ZLciox7F38ByW/5sJZPSCqs7A18dab/Lzj8W7fBeoE1Grky+xhzbnu
M9OAwf0yIQbS3MdH8y15h35M1wyFkAUq3NdPm1D5PfYX9BlHZxqpOkWG/P1/T1Hf
5N+Qhl8Tc9ghqPcOMM2453tWF7AoK9Qs5BdXTHRB3Bi1q/NhCVzEFsuOYTbtpPOI
Zlu2OnpidKMsUR+X+zUjXq5nEh9T0j7Zubvr0YJde/Nok375MLLKAIhhiFy3RTIX
DT4WYsItFo3rAOgcTvKUpFqOQZEjzwyi2bo2+438oZXz7I3tbP8CJH17KrtvJvsr
70M3ix2j+TJC8yKyR1eAiWLFluf3ZNgdqD3wevQv6wHmuZKJ5PC9nXvnm0WpsmzL
AgqLaYiIJkHsKVo2Syyp
=V13D
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] i965: Fix mipmap offsets for HiZ and separate stencil buffers.
On 05/02/2012 02:48 PM, Paul Berry wrote: When rendering to a miplevel other than 0 within a color, depth, stencil, or HiZ buffer, we need to tell the GPU to render to an offset within the buffer, so that the data is written into the correct miplevel. We do this using a coarse offset (in pages), and a fine adjustment (the so-called tile_x and tile_y values, which are measured in pixels). We have always computed the coarse offset and fine adjustment using intel_renderbuffer_tile_offsets() function. This worked fine for color and combined depth/stencil buffers, but failed to work properly when HiZ and separate stencil were in use. It failed to work because there is only one set of fine adjustment controls shared by the HiZ, depth, and stencil buffers, so we need to choose tile_x and tile_y values that are compatible with the tiling of all three buffers, and then compute separate coarse offsets for each buffer. This patch fixes the HiZ and separate stencil case by replacing the call to intel_renderbuffer_tile_offsets() with calls to two functions: intel_region_get_tile_masks(), which determines how much of the adjustment can be performed using offsets and how much can be performed using tile_x and tile_y, and intel_region_get_aligned_offset(), which computes the coarse offset. intel_region_get_tile_offsets() is still used for color renderbuffers, so to avoid code duplication, I've re-worked it to use intel_region_get_tile_masks() and intel_region_get_aligned_offset(). On i965 Gen6, fixes piglit tests texturing/depthstencil-render-miplevels 1024 X where X is one of (depth, depth_and_stencil, depth_stencil_single_binding, depth_x, depth_x_and_stencil, stencil, stencil_and_depth, stencil_and_depth_x). On i965 Gen7, the variants of texturing/depthstencil-render-miplevels that contain a stencil buffer still fail, due to another problem: Gen7 seems to ignore the 3 LSB's of the tile_y adjustment (and possibly also tile_x). v2: Removed spurious comments. Added assertions to check preconditions of intel_region_get_aligned_offset(). I think this is right. I see what you're doing and it seems like a good idea. Since it fixes things and allows you to merge your other patch which fixes GPU hangs, I'm going to give it an: Acked-by: Kenneth Graunke kenn...@whitecape.org That said, I'm displeased with the fact that a lot of complicated code has been cut pasted between brw_misc_state, gen7_misc_state, gen6_hiz, and gen7_hiz. I'd rather coalesce it. Plus, the existing emit_depthbuffer code was already quite hairy and in need of refactoring... I'll look into that I guess. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
On 05/03/2012 08:42 AM, Ian Romanick wrote: On 05/02/2012 06:32 PM, Chad Versace wrote: Quick Solution for the Intel drivers A quick solution may be as simple as removing ARB_fbo from the Intel drivers' GLES1/2 extension lists. Do you see any problem in doing this? Charles, you have experimented with disabling ARB_fbo from GLES1/2 contexts. Did you observe any negative consequences? Ian, Do you think its safe for us to remove ARB_fbo from the GLES1 and GLES2 extension lists in intel_extensions_es.c? The lists have included ARB_fbo since day one, added at commit a5107b0a5cb1ac9f112aa498f57c13580bd56cb3 Author: Kristian Høgsberg k...@bitplanet.net Date: Tue Apr 27 14:57:51 2010 -0400 intel: Only register ES2 extensions for ES2 contexts I think it's safe because 1. ARB_fbo is not exposed in the extension string of ES contexts, so no ES app explicitly relies on that extension. 2. The ARB_fbo extension, according to the spec, is an amalgamation of EXT_framebuffer_object EXT_framebuffer_blit EXT_packed_depth_stencil EXT_framebuffer_multisample The first three are already enabled in intel_extensions_es.c, and functionality of the last, EXT_fb_multisample, isn't exposed in ES. Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
On 05/03/2012 11:49 AM, Chad Versace wrote: On 05/03/2012 08:42 AM, Ian Romanick wrote: On 05/02/2012 06:32 PM, Chad Versace wrote: Quick Solution for the Intel drivers A quick solution may be as simple as removing ARB_fbo from the Intel drivers' GLES1/2 extension lists. Do you see any problem in doing this? Charles, you have experimented with disabling ARB_fbo from GLES1/2 contexts. Did you observe any negative consequences? Ian, Do you think its safe for us to remove ARB_fbo from the GLES1 and GLES2 extension lists in intel_extensions_es.c? The lists have included I'm ambivalent. Ultimately, I'd like to see this partitioning go away. The driver should enable the features that it supports, and core Mesa should advertise the appropriate functionality. Having two sets of extension lists is annoying and error prone. ARB_fbo since day one, added at commit a5107b0a5cb1ac9f112aa498f57c13580bd56cb3 Author: Kristian Høgsbergk...@bitplanet.net Date: Tue Apr 27 14:57:51 2010 -0400 intel: Only register ES2 extensions for ES2 contexts I think it's safe because 1. ARB_fbo is not exposed in the extension string of ES contexts, so no ES app explicitly relies on that extension. 2. The ARB_fbo extension, according to the spec, is an amalgamation of EXT_framebuffer_object EXT_framebuffer_blit EXT_packed_depth_stencil EXT_framebuffer_multisample The first three are already enabled in intel_extensions_es.c, and functionality of the last, EXT_fb_multisample, isn't exposed in ES. Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Upcoming Mesa releases
To keep in the habit of doing regular releases, I'd like to propose the following set of release dates. We had previously discussed doing stable releases monthly and feature releases every six months. This set of dates basically reflects that. I should be able to package up most of these, but I will be on vacation in June. Perhaps Jakob can handle that one. :) I've listed the February 2013 release as 8.2. I think there's a good chance we'll have OpenGL 3.1 by then, so it may end up being 9.0. 5/18: Mesa 8.0.3 6/15: Mesa 8.0.4 7/20: Mesa 8.0.5 8/17: Mesa 8.1 / Mesa 8.0.6 9/21: Mesa 8.1.1 10/19: Mesa 8.1.2 11/16: Mesa 8.1.3 12/14: Mesa 8.1.4 1/18: Mesa 8.1.5 2/15: Mesa 8.2 (9.0?) / Mesa 8.1.6 Does this sound like a reasonable plan? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gbm: Add gbm_bo_write entry point
On Thu, May 3, 2012 at 5:08 PM, Mandeep Baines mandeep.bai...@gmail.com wrote:
2012/5/2 Kristian Høgsberg k...@bitplanet.net:
This new gbm entry point allows writing data into a gbm bo. The bo has
to be created with the GBM_BO_USE_WRITE flag, and it's only required to
work for GBM_BO_USE_CURSOR_64X64 bos.
The gbm API is designed to be the glue layer between EGL and KMS, but there
was never a mechanism initialize a buffer suitable for use with KMS
hw cursors. The hw cursor bo is typically not compatible with anything EGL
can render to, and thus there's no way to get data into such a bo.
Hi Kristian,
What is the advantage of this approach over just using dumb buffers
via DRM_IOCTL_MODE_CREATE_DUMB and
DRM_IOCTL_MODE_MAP_DUMB?
Those are DRM ioctls. gbm is a drm independent API and can work for
non-drm/mesa EGL stacks.
Kristian
Regards,
Mandeep
gbm_bo_write() fills that gap while staying out of the efficient
cpu-gpu pixel transfer business.
---
include/GL/internal/dri_interface.h | 10 +-
src/gbm/backends/dri/gbm_dri.c | 18 ++
src/gbm/main/gbm.c | 19 +++
src/gbm/main/gbm.h | 9 +
src/gbm/main/gbmint.h | 1 +
src/mesa/drivers/dri/intel/intel_screen.c | 24 ++--
6 files changed, 78 insertions(+), 3 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index eafbe10..e37917e 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -894,7 +894,7 @@ struct __DRIdri2ExtensionRec {
* extensions.
*/
#define __DRI_IMAGE DRI_IMAGE
-#define __DRI_IMAGE_VERSION 3
+#define __DRI_IMAGE_VERSION 4
/**
* These formats correspond to the similarly named MESA_FORMAT_*
@@ -911,6 +911,7 @@ struct __DRIdri2ExtensionRec {
#define __DRI_IMAGE_USE_SHARE 0x0001
#define __DRI_IMAGE_USE_SCANOUT 0x0002
#define __DRI_IMAGE_USE_CURSOR 0x0004
+#define __DRI_IMAGE_USE_WRITE 0x0008
/**
* queryImage attributes
@@ -955,6 +956,13 @@ struct __DRIimageExtensionRec {
* \since 2
*/
GLboolean (*validateUsage)(__DRIimage *image, unsigned int use);
+
+ /**
+ * Write data into image.
+ *
+ * \since 4
+ */
+ int (*write)(__DRIimage *image, const void *buf, size_t count);
};
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 4df6e8f..e5ddfb6 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -291,6 +291,18 @@ gbm_dri_is_format_supported(struct gbm_device *gbm,
return 1;
}
+static int
+gbm_dri_bo_write(struct gbm_bo *_bo, const void *buf, size_t count)
+{
+ struct gbm_dri_device *dri = gbm_dri_device(_bo-gbm);
+ struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
+
+ if (dri-image-base.version 4)
+ return -1;
+
+ return dri-image-write(bo-image, buf, count);
+}
+
static void
gbm_dri_bo_destroy(struct gbm_bo *_bo)
{
@@ -390,6 +402,9 @@ gbm_dri_bo_create(struct gbm_device *gbm,
int dri_format;
unsigned dri_use = 0;
+ if (dri-image-base.version 4 (usage GBM_BO_USE_WRITE))
+ return NULL;
+
bo = calloc(1, sizeof *bo);
if (bo == NULL)
return NULL;
@@ -421,6 +436,8 @@ gbm_dri_bo_create(struct gbm_device *gbm,
dri_use |= __DRI_IMAGE_USE_SCANOUT;
if (usage GBM_BO_USE_CURSOR_64X64)
dri_use |= __DRI_IMAGE_USE_CURSOR;
+ if (usage GBM_BO_USE_WRITE)
+ dri_use |= __DRI_IMAGE_USE_WRITE;
bo-image =
dri-image-createImage(dri-screen,
@@ -491,6 +508,7 @@ dri_device_create(int fd)
dri-base.base.bo_create = gbm_dri_bo_create;
dri-base.base.bo_create_from_egl_image =
gbm_dri_bo_create_from_egl_image;
dri-base.base.is_format_supported = gbm_dri_is_format_supported;
+ dri-base.base.bo_write = gbm_dri_bo_write;
dri-base.base.bo_destroy = gbm_dri_bo_destroy;
dri-base.base.destroy = dri_destroy;
dri-base.base.surface_create = gbm_dri_surface_create;
diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 987e965..3994f86 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -231,6 +231,25 @@ gbm_bo_get_handle(struct gbm_bo *bo)
return bo-handle;
}
+/** Write data into the buffer object
+ *
+ * If the buffer object was created with the GBM_BO_USE_WRITE flag,
+ * this function can used to write data into the buffer object. The
+ * data is copied directly into the object and it's the responsiblity
+ * of the caller to make sure the data represents valid pixel data,
+ * according to the width, height, stride and format of the buffer object.
+ *
+ * \param bo The buffer object
+ * \param buf The data to write
+ * \param count The number of bytes to write
+ * \return Returns -1 on error, 0 otherwise
+ */
+GBM_EXPORT int
+gbm_bo_write(struct gbm_bo *bo,
Re: [Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
On 05/02/2012 06:32 PM, Chad Versace wrote: Mesa has problems in the way it implements glBindFramebuffer and glBindFramebufferEXT due to both being implemented by an overloaded _mesa_BindFramebufferEXT. This problem causes an Android app [1] to crash, and I want your opinion on how we should fix it. The problem is that in the five specs in the subject line, the specified behavior of glBindFramebuffer falls into two incompatible categories. Mesa implements the wrong behavior for OES_fbo, EXT_fbo, and GLES2 when ARB_fbo is internally enabled. [snip] Solutions for core Mesa --- As for fixing _mesa_BindFramebufferEXT, I have two ideas. [snip] 2. Create separate entry points: - _mesa_BindFramebufferEXT, which implements - glBindFramebufferEXT - glBindFramebufferOES - glBindFramebuffer in GLES2 - _mesa_BindFramebufferARB, which implements - glBindFramebufferARB - glBindFramebuffer in GL 3.x Quick Solution for the Intel drivers A quick solution may be as simple as removing ARB_fbo from the Intel drivers' GLES1/2 extension lists. Thanks for everyone's feedback. Based on the discussion, I plan to 1. Submit a patch that disables ARB_fbo in Intel ES contexts. 2. Write some Piglit tests to probe the expected behavior in different extensions and APIs. 3. Start working to separate the API entry points. Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel: Disable ARB_framebuffer_object in ES contexts
This patch removes ARB_framebuffer_object from the GLES1 and GLES2
extension lists in intel_extensions_es.c.
Fixes a crash in the Android browser on Ice Cream Sandwich.
The Android browser crashed because it did the following, which is legal
in GLES2 but not in ARB_framebuffer_object.
glGenFramebuffers(1, fb);
glBindFramebuffer(GL_FRAMEBUFFER, fb);
// render render render...
glDeleteFramebuffers(1, fb);
// go do other stuff...
glBindFramebuffer(GL_FRAMEBUFFER, fb);
// This bind unexpectedly failed, and the app panics.
The semantics of glBindFramebuffer specified by ARB_framebuffer_object (a
desktop GL extension) and GLES2 specs are incompatible. The ideal solution
to fix this is to create separate API entry points for glBindFramebuffer,
one for GL and the other for GLES2. But, until that work is complete,
disabling ARB_framebuffer_object in GLES2 contexts safely fixes the problem.
Likewise, the semantics of glBindFramebuffer in ARB_framebuffer_object and
of glBindFramebufferOES in OES_framebuffer_object (a GLES1 extension) are
incompatible. Even though the functions have different names, the semantic
difference still results in a bug because both API calls are implemented
by a single function, _mesa_BindFramebufferEXT, which handles the semantic
difference incorrectly. Again, disabling ARB_framebuffer_object in GLES1
contexts safely fixes this problem.
According to the ARB_framebuffer_object spec, the extension is an
amalgamation of
EXT_framebuffer_object
EXT_framebuffer_blit
EXT_packed_depth_stencil
EXT_framebuffer_multisample
By disabling this extension, however, no functionality is removed from
GLES1 and GLES2 contexts because 1) the first three extensions are
explicitly enabled in Intel's ES extension lists and 2) no functionality
of the last extension is exposed in an ES context.
See-also:
http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg21006.html
CC: Ian Romanick i...@freedesktop.org
CC: Charles Johnson charles.f.john...@intel.com
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/mesa/drivers/dri/intel/intel_extensions_es.c |2 --
1 file changed, 2 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_extensions_es.c
b/src/mesa/drivers/dri/intel/intel_extensions_es.c
index 29eb8ea..b42907c 100644
--- a/src/mesa/drivers/dri/intel/intel_extensions_es.c
+++ b/src/mesa/drivers/dri/intel/intel_extensions_es.c
@@ -66,7 +66,6 @@ static const char *es1_extensions[] = {
GL_EXT_blend_func_separate,
GL_EXT_blend_subtract,
GL_OES_draw_texture,
- GL_ARB_framebuffer_object,
GL_EXT_framebuffer_object,
GL_ARB_point_sprite,
GL_EXT_stencil_wrap,
@@ -92,7 +91,6 @@ static const char *es2_extensions[] = {
GL_NV_blend_square,
/* Optional GLES2 */
- GL_ARB_framebuffer_object,
GL_ARB_depth_texture,
GL_EXT_framebuffer_object,
--
1.7.10
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
