date:20120222

Re: [Mesa-dev] [PATCH] gbm: track buffer format through DRI drivers

2012-02-22 Thread Kristian Hoegsberg

On Tue, Feb 21, 2012 at 12:56:11PM -0800, Jesse Barnes wrote:
> GBM needs the buffer format in order to communicate with DRM and clients
> for things like scanout.
> 
> So track the DRI format requested in the various back ends and use it to
> return the DRI format back to GBM when requested.  GBM will then map
> this into the GBM surface type (which is in turn based on the DRM fb
> format list).

Yes, that looks good now.  Just one thing left that I can see: we need
to bump the versions of the __DRI_IMAGE extension in the drivers so
that they advertise 3 if they support the format attribute.

Kristian
 
> Signed-off-by: Jesse Barnes 
> ---
>  include/GL/internal/dri_interface.h   |3 +-
>  src/gallium/state_trackers/dri/drm/dri2.c |6 +
>  src/gallium/winsys/sw/wayland/wayland_sw_winsys.h |1 +
>  src/gbm/backends/dri/gbm_dri.c|   45 -
>  src/gbm/main/gbm.c|   13 +++
>  src/gbm/main/gbm.h|  110 
> -
>  src/gbm/main/gbmint.h |1 +
>  src/mesa/drivers/dri/intel/intel_regions.h|1 +
>  src/mesa/drivers/dri/intel/intel_screen.c |4 +
>  src/mesa/drivers/dri/radeon/radeon_screen.c   |2 +
>  src/mesa/drivers/dri/radeon/radeon_screen.h   |1 +
>  11 files changed, 181 insertions(+), 6 deletions(-)
> 
> diff --git a/include/GL/internal/dri_interface.h 
> b/include/GL/internal/dri_interface.h
> index 701e83e..da83666 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 2
> +#define __DRI_IMAGE_VERSION 3
>  
>  /**
>   * These formats correspond to the similarly named MESA_FORMAT_*
> @@ -918,6 +918,7 @@ struct __DRIdri2ExtensionRec {
>  #define __DRI_IMAGE_ATTRIB_STRIDE0x2000
>  #define __DRI_IMAGE_ATTRIB_HANDLE0x2001
>  #define __DRI_IMAGE_ATTRIB_NAME  0x2002
> +#define __DRI_IMAGE_ATTRIB_FORMAT0x2003 /* available in versions 3+ */
>  
>  typedef struct __DRIimageRec  __DRIimage;
>  typedef struct __DRIimageExtensionRec __DRIimageExtension;
> diff --git a/src/gallium/state_trackers/dri/drm/dri2.c 
> b/src/gallium/state_trackers/dri/drm/dri2.c
> index 4c08a02..32cb077 100644
> --- a/src/gallium/state_trackers/dri/drm/dri2.c
> +++ b/src/gallium/state_trackers/dri/drm/dri2.c
> @@ -477,6 +477,7 @@ dri2_create_image_from_name(__DRIscreen *_screen,
> memset(&whandle, 0, sizeof(whandle));
> whandle.handle = name;
> whandle.stride = pitch * util_format_get_blocksize(pf);
> +   whandle.dri_format = format;
>  
> img->texture = 
> screen->base.screen->resource_from_handle(screen->base.screen,
>   &templ, &whandle);
> @@ -527,6 +528,8 @@ dri2_create_image(__DRIscreen *_screen,
>tex_usage |= PIPE_BIND_CURSOR;
> }
>  
> +   img->dri_format = format;
> +
> switch (format) {
> case __DRI_IMAGE_FORMAT_RGB565:
>pf = PIPE_FORMAT_B5G6R5_UNORM;
> @@ -598,6 +601,9 @@ dri2_query_image(__DRIimage *image, int attrib, int 
> *value)
>   image->texture, &whandle);
>*value = whandle.handle;
>return GL_TRUE;
> +   case __DRI_IMAGE_ATTRIB_FORMAT:
> +  *value = image->dri_format;
> +  return GL_TRUE;
> default:
>return GL_FALSE;
> }
> diff --git a/src/gallium/winsys/sw/wayland/wayland_sw_winsys.h 
> b/src/gallium/winsys/sw/wayland/wayland_sw_winsys.h
> index bedd240..8e6f329 100644
> --- a/src/gallium/winsys/sw/wayland/wayland_sw_winsys.h
> +++ b/src/gallium/winsys/sw/wayland/wayland_sw_winsys.h
> @@ -32,6 +32,7 @@ struct wl_display;
>  struct winsys_handle {
> int fd;
> unsigned stride;
> +   uint32_t dri_format;
>  };
>  
>  struct sw_winsys *
> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
> index ddd153a..34f07de 100644
> --- a/src/gbm/backends/dri/gbm_dri.c
> +++ b/src/gbm/backends/dri/gbm_dri.c
> @@ -216,13 +216,15 @@ free_screen:
>  
>  static int
>  gbm_dri_is_format_supported(struct gbm_device *gbm,
> -enum gbm_bo_format format,
> +uint32_t format,
>  uint32_t usage)
>  {
> switch (format) {
> case GBM_BO_FORMAT_XRGB:
> +   case GBM_FORMAT_XRGB:
>break;
> case GBM_BO_FORMAT_ARGB:
> +   case GBM_FORMAT_ARGB:
>if (usage & GBM_BO_USE_SCANOUT)
>   return 0;
>break;
> @@ -247,6 +249,32 @@ gbm_dri_bo_destroy(struct gbm_bo *_bo)
> free(bo);
>  }
>  
> +static uint32_t
> +gbm_dri_to_gbm_format(uint32_t dri_format)
> +{
> +   uint32_t ret = 0;
> +
> +   switch (dri_format) {
> +   case __DRI_IMAGE_FORMAT_RGB565:
> +  ret = GBM_FORMAT_RGB565;
> +  break;
> +   case __DRI_IMAGE_FORMAT_XRGB:
> +  ret = GBM_FORMAT_XRGB;
> +

Re: [Mesa-dev] [PATCH 2/2] i965: handle gl_PointCoord for Gen4 and Gen5 platform

2012-02-22 Thread Yuanhan Liu

On Tue, Feb 21, 2012 at 11:59:17AM -0800, Eric Anholt wrote:
> On Sun, 19 Feb 2012 13:31:33 +0800, Liu Aleaxander  
> wrote:
> > On Sun, Feb 19, 2012 at 8:54 AM, Eric Anholt  wrote:
> > > On Sat, 18 Feb 2012 23:07:32 +0800, Liu Aleaxander  
> > > wrote:
> > >> +   /*
> > >> +    * gl_PointCoord is a FS instead of VS builtin variable, thus is not
> > >> +    * included in c->nr_setup_regs. But FS need SF do the interpolation,
> > >> +    * so that here padding the interpolation for gl_PointCoord in last.
> > >> +    */
> > >> +   if (c->key.do_point_coord)
> > >> +      c->nr_setup_regs++;
> > >
> > > So you're writing an extra attribute of setup, but you haven't increased
> > > the size of the URB entry.  If the URB full except for pointcoord, you'd
> > > end up writing over the next URB entry and probably hanging the GPU.  If
> > > you correctly allocate the URB size and that gets reflected in
> > > urb_read_length, you should be able to read your new attribute.
> > 
> > That's maybe the place I don't understand quite well so far. Say, you
> > write attributes into URB from SF thread to FS. I did increase the
> > urb_read_length in wm_state. Is that the allocation you mean? Should
> > I, say, allocate size for extra attributes just for FS in SF stage? If
> > so, would you please tell me how? Since if I understand correctly, the
> > urb_read_length in SF_STATE is counted from the attributes from VF
> > stage. Thus at least urb_read_length in SF stage is not the right
> > place for me to touch, right?
> 
> urb_entry_size in the SF is the size of what the SF outputs and is what
> determines how much space is allocated by brw_urb.c

Thanks for the info.

Well, I was trying to figure out why this patch doesn't work when the
urb read lenght per each attribute is set to 2 at calculate_urb_setup(),
but it does work when set to 4. I may not quite understand the urb
layout now; and I'm trying to figure it out.

Thanks,
Yuanhan Liu 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] i915: fix wrong rendering of gl_PointSize on Pineview

2012-02-22 Thread Yuanhan Liu

The current code would ignore the point size specified by gl_PointSize
builtin variable in vertex shader on Pineview. This patch servers as
fixing that.

This patch fixes the following issues on Pineview:
webglc: 
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/rendering/point-size.html
piglit: glsl-vs-point-size

NOTE: This is a candidate for stable release branches.

v2: pick Eric's nice tip for fixing this issue in hardware rendering.

Signed-off-by: Yuanhan Liu 
---
 src/mesa/drivers/dri/i915/i915_fragprog.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c 
b/src/mesa/drivers/dri/i915/i915_fragprog.c
index 4f016a3..2d60523 100644
--- a/src/mesa/drivers/dri/i915/i915_fragprog.c
+++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
@@ -1361,6 +1361,10 @@ i915ValidateFragmentProgram(struct i915_context *i915)
   EMIT_ATTR(_TNL_ATTRIB_POS, EMIT_3F_VIEWPORT, S4_VFMT_XYZ, 12);
}
 
+   /* Handle gl_PointSize builtin var here */
+   if (ctx->Point._Attenuated || ctx->VertexProgram.PointSizeEnabled)
+  EMIT_ATTR(_TNL_ATTRIB_POINTSIZE, EMIT_1F, S4_VFMT_POINT_WIDTH, 1);
+
if (inputsRead & FRAG_BIT_COL0) {
   intel->coloroffset = offset / 4;
   EMIT_ATTR(_TNL_ATTRIB_COLOR0, EMIT_4UB_4F_BGRA, S4_VFMT_COLOR, 4);
-- 
1.7.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] tnl: let _TNL_ATTRIB_POINTSIZE do not depend on ctx->VertexProgram._Enabled

2012-02-22 Thread Yuanhan Liu

We may specify the point size in a glsl vertex shader.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46311
piglit: glsl-vs-point-size

NOTE: This is a candidate for stable release branches.

Signed-off-by: Yuanhan Liu 
---
 src/mesa/tnl/t_context.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/src/mesa/tnl/t_context.c b/src/mesa/tnl/t_context.c
index 1ded44c..e38c0a3 100644
--- a/src/mesa/tnl/t_context.c
+++ b/src/mesa/tnl/t_context.c
@@ -151,8 +151,7 @@ _tnl_InvalidateState( struct gl_context *ctx, GLuint 
new_state )
if (ctx->RenderMode == GL_FEEDBACK)
   tnl->render_inputs_bitset |= BITFIELD64_BIT(_TNL_ATTRIB_TEX0);
 
-   if (ctx->Point._Attenuated ||
-   (ctx->VertexProgram._Enabled && ctx->VertexProgram.PointSizeEnabled))
+   if (ctx->Point._Attenuated || ctx->VertexProgram.PointSizeEnabled)
   tnl->render_inputs_bitset |= BITFIELD64_BIT(_TNL_ATTRIB_POINTSIZE);
 
/* check for varying vars which are written by the vertex program */
-- 
1.7.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i915: fallback to swrast when gl_PointSize met

2012-02-22 Thread Yuanhan Liu

On Wed, Feb 22, 2012 at 12:24:11PM -0800, Eric Anholt wrote:
> On Tue, 21 Feb 2012 23:21:07 +0800, Liu Aleaxander  
> wrote:
> > This patch(the way to fix this issue) is a little weird, as we already
> > fallbacked to swrast when handling gl_PointSize(in vertex shader).
> > Sounds that we didn't fallback enough;) This patch servers as fixing the
> > gl_PointSize issue on Pineview platform.
> > 
> > Since the patch is a little weird, I thought a while for another fix:
> > get the point size at intelRenderStart() (or somewhere else before
> > vtbl.emit_state()) by reading the vertex program output. This is so
> > tricky that I droped this fix.
> > 
> > Any better thoughts(or even fixes) are welcome and appreciate.
> > 
> > This patch would fix piglit glsl-vs-point-size on Pineview(when the GL
> > version 2.0 requirement is removed).
> 
> It looks like to do this right in hardware, you just need to emit
> _TNL_ATTRIB_PSZ with S4_VFMT_POINT_WIDTH in i915ValidateFragmentProgram
> just before COLOR0.

I tried it and it worked. This is so *cool*!

Thanks for the nice tip. Will make a patch for that.

Thanks,
Yuanhan Liu
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r300g: Use automake to generate Makefile v2

2012-02-22 Thread Matt Turner

First off, it doesn't build for me --

mklib: Making Linux shared library:  r300_dri.so.tmp
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/../../../../x86_64-pc-linux-gnu/bin/ld:
../../../../src/gallium/drivers/r300/libr300.a(r300_screen.o):
relocation R_X86_64_32 against `.rodata.str1.1' can not be used when
making a shared object; recompile with -fPIC
../../../../src/gallium/drivers/r300/libr300.a: could not read
symbols: Bad value
collect2: ld returned 1 exit status

I think we'll have to hack it and add -fPIC to the local CFLAGS until
the rest is converted.

On Wed, Feb 22, 2012 at 8:14 PM, Tom Stellard  wrote:
> v2:
>  - s/$(top_builddir)/$(top_srcdir)/
>  - Always generate Makefile.in
> ---
>  configure.ac                                       |    1 +
>  src/gallium/drivers/r300/.gitignore                |    5 ++
>  src/gallium/drivers/r300/Makefile                  |   25 -
>  src/gallium/drivers/r300/Makefile.am               |   38 ++
>  src/gallium/drivers/r300/compiler/tests/.gitignore |    1 -
>  src/gallium/drivers/r300/compiler/tests/Makefile   |   53 
> 
>  6 files changed, 44 insertions(+), 79 deletions(-)
>  create mode 100644 src/gallium/drivers/r300/.gitignore
>  delete mode 100644 src/gallium/drivers/r300/Makefile
>  create mode 100644 src/gallium/drivers/r300/Makefile.am
>  delete mode 100644 src/gallium/drivers/r300/compiler/tests/.gitignore
>  delete mode 100644 src/gallium/drivers/r300/compiler/tests/Makefile
>
> diff --git a/configure.ac b/configure.ac
> index 846b623..c8850cf 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1932,6 +1932,7 @@ CXXFLAGS="$CXXFLAGS $USER_CXXFLAGS"
>
>  dnl Substitute the config
>  AC_CONFIG_FILES([configs/autoconf
> +               src/gallium/drivers/r300/Makefile
>                src/gbm/Makefile
>                src/gbm/main/gbm.pc
>                src/egl/wayland/Makefile
> diff --git a/src/gallium/drivers/r300/.gitignore 
> b/src/gallium/drivers/r300/.gitignore
> new file mode 100644
> index 000..5e510eb
> --- /dev/null
> +++ b/src/gallium/drivers/r300/.gitignore
> @@ -0,0 +1,5 @@
> +Makefile
> +Makefile.in
> +radeon_compiler_util_tests
> +.libs/
> +.deps/
> diff --git a/src/gallium/drivers/r300/Makefile 
> b/src/gallium/drivers/r300/Makefile
> deleted file mode 100644
> index 2af1913..000
> --- a/src/gallium/drivers/r300/Makefile
> +++ /dev/null
> @@ -1,25 +0,0 @@
> -TOP = ../../../..
> -include $(TOP)/configs/current
> -
> -LIBNAME = r300
> -
> -# get C_SOURCES
> -include Makefile.sources
> -
> -# needed to build non-libmesagallium.a targets
> -C_SOURCES += \
> -       $(TOP)/src/glsl/ralloc.c \
> -       $(TOP)/src/mesa/program/register_allocate.c
> -
> -#This is for libdrm inlude path
> -CFLAGS+=$(RADEON_CFLAGS)
> -
> -LIBRARY_INCLUDES = \
> -       -I$(TOP)/include \
> -       -I$(TOP)/src/mesa \
> -       -I$(TOP)/src/glsl
> -
> -include ../../Makefile.template
> -
> -test: default
> -       @$(MAKE) -s -C compiler/tests/
> diff --git a/src/gallium/drivers/r300/Makefile.am 
> b/src/gallium/drivers/r300/Makefile.am
> new file mode 100644
> index 000..298aa40
> --- /dev/null
> +++ b/src/gallium/drivers/r300/Makefile.am
> @@ -0,0 +1,38 @@
> +include Makefile.sources
> +
> +noinst_LIBRARIES = libr300.a
> +noinst_PROGRAMS = radeon_compiler_util_tests

This should be check_PROGRAMS = radeon_compiler_util_tests unless we
actually want to build this during `make` and not specifically `make
check`

> +testdir=compiler/tests
> +
> +AM_CFLAGS = \
> +       -I$(top_srcdir)/src/gallium/include \
> +       -I$(top_srcdir)/src/gallium/auxiliary \
> +       -I$(top_srcdir)/src/gallium/drivers \
> +       -I$(top_srcdir)/include \
> +       -I$(top_srcdir)/src/mesa \
> +       -I$(top_srcdir)/src/glsl \
> +       -I$(top_srcdir)/src/mapi \
> +       $(LLVM_CFLAGS) \
> +       $(RADEON_CFLAGS)
> +
> +libr300_a_SOURCES = \
> +       $(C_SOURCES) \
> +       $(top_srcdir)/src/glsl/ralloc.c \
> +       $(top_srcdir)/src/mesa/program/register_allocate.c
> +
> +test_LDADD = libr300.a
> +test_SOURCES = \
> +       $(testdir)/rc_test_helpers.c \
> +       $(testdir)/unit_test.c
> +test_CFLAGS = -I$(top_srcdir)/src/gallium/drivers/r300/compiler
> +
> +radeon_compiler_util_tests_LDADD = $(test_LDADD)
> +radeon_compiler_util_tests_CFLAGS = $(test_CFLAGS)
> +radeon_compiler_util_tests_SOURCES = \
> +       $(test_SOURCES) \
> +       $(testdir)/radeon_compiler_util_tests.c
>

I don't understand the indirection with the test_* variables. I think
we should just remove it.

> +default: libr300.a
> +

I see that the rest of the build system wants to `make default` in
r300/. Let's add a note to remove this when the rest of the system is
converted.

> +test: $(noinst_PROGRAMS)
> +       $(foreach test, $^, @./$(test))

We can just use automake's TESTS variable to do this. If `make test`
is called by some other makefile, then just add 'test: check'.

With the attached patch squashed in, I think it's good to go.
diff --git a/

[Mesa-dev] [Bug 42128] Crash when visiting a site with Firefox

2012-02-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=42128

--- Comment #13 from Benoit Jacob  2012-02-22 19:23:50 PST 
---
Alright, patch under review @moz to block opengl 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] [Patch 2] wayland-drm: export wayland-drm-client-protocol.h for installation (enable libva over wayland)

2012-02-22 Thread Zhao, Halley

Resend the patch, it is required to enable libva over wayland.

== patch description ==
Besides graphics, other modules (like video/camera) also depends on drm for 
buffer management.
So wayland drm protocol header file should be installed.

Libva related changes are here for your reference: 
https://gitorious.org/libva-wayland/libva-wayland/commits/wayland
It bases on Benjamin's work to enable libva for wayland: 
http://cgit.freedesktop.org/~bnf/libva/log/?h=wayland

With this patch, we can avoid the hack to copy wayland-drm.xml from mesa to 
libva.

== patch details ==
src/egl/wayland/wayland-drm/Makefile.am |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/src/egl/wayland/wayland-drm/Makefile.am 
b/src/egl/wayland/wayland-drm/Makefile.am
index cf15eda..2e68ac4 100644
--- a/src/egl/wayland/wayland-drm/Makefile.am
+++ b/src/egl/wayland/wayland-drm/Makefile.am
@@ -7,8 +7,9 @@ noinst_LTLIBRARIES = libwayland-drm.la
libwayland_drm_la_SOURCES = wayland-drm.c wayland-drm-protocol.c
noinst_HEADERS = wayland-drm.h

+include_HEADERS = wayland-drm-client-protocol.h
+
BUILT_SOURCES = wayland-drm-protocol.c \
- wayland-drm-client-protocol.h \
   wayland-drm-server-protocol.h
CLEANFILES = $(BUILT_SOURCES)

--
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] wayland-egl: Add api to get window/pixmap attributes (enable libva over wayland)

2012-02-22 Thread Zhao, Halley

Resend the patch, it is required to enable libva over wayland.

Ian/Eric:
Could you help to review this patch?

== patch description ==:
wl_egl_window/wl_egl_pixmap are implemented in mesa, however these drawables 
can also be update in video/camera modules.
An example is that libva also manage buffer object for it, so the attributes of 
the drawable should be accessed outside of mesa.
With this patch, we can remove the hack to copy wayland-egl-priv.h from mesa to 
libva.

Libva related changes are here for your reference: 
https://gitorious.org/libva-wayland/libva-wayland/commits/wayland
It bases on Benjamin's work to enable libva for wayland: 
http://cgit.freedesktop.org/~bnf/libva/log/?h=wayland

== patch details ==:

src/egl/wayland/wayland-egl/wayland-egl.c |   29 +
1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/src/egl/wayland/wayland-egl/wayland-egl.c 
b/src/egl/wayland/wayland-egl/wayland-egl.c
index e950b4a..b7efab8 100644
--- a/src/egl/wayland/wayland-egl/wayland-egl.c
+++ b/src/egl/wayland/wayland-egl/wayland-egl.c
@@ -81,3 +81,32 @@ wl_egl_pixmap_create_buffer(struct wl_egl_pixmap *egl_pixmap)
{
   return egl_pixmap->buffer;
}
+
+WL_EGL_EXPORT void
+wl_egl_window_get_size(struct wl_egl_window *egl_window,
+   int *width, int *height)
+{
+   if (width)
+*width = egl_window->width;
+   if (height)
+*height = egl_window->height;
+}
+
+WL_EGL_EXPORT struct wl_surface*
+wl_egl_window_get_surface(struct wl_egl_window *win)
+{
+if (win)
+return win->surface;
+else
+return NULL;
+}
+
+WL_EGL_EXPORT void
+wl_egl_pixmap_get_size(struct wl_egl_pixmap *egl_pixmap,
+   int *width, int *height)
+{
+   if (width)
+*width = egl_pixmap->width;
+   if (height)
+*height = egl_pixmap->height;
+}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600g: Fix build when libdrm is installed to non-standard dir.

2012-02-22 Thread Tom Stellard

Pushed, thanks.

-Tom

On Mon, Feb 20, 2012 at 01:17:56AM -0500, Satyajit Sarangi wrote:
> From: Satyajit Sarangi 
> 
> Signed-off-by: Satyajit Sarangi
> ---
>  src/gallium/drivers/r600/Makefile |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/src/gallium/drivers/r600/Makefile 
> b/src/gallium/drivers/r600/Makefile
> index 80f8cbf..62e760c 100644
> --- a/src/gallium/drivers/r600/Makefile
> +++ b/src/gallium/drivers/r600/Makefile
> @@ -3,6 +3,9 @@ include $(TOP)/configs/current
>  
>  LIBNAME = r600
>  
> +#This is for libdrm include path
> +CFLAGS+=$(RADEON_CFLAGS)
> +
>  LIBRARY_INCLUDES = -I$(TOP)/include
>  
>  # get C_SOURCES
> -- 
> 1.7.5.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 46458] Guest screen is corrupted after host screen locked

2012-02-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=46458

Jakob Bornecrantz  changed:

   What|Removed |Added

 AssignedTo|mesa-dev@lists.freedesktop. |ja...@vmware.com
   |org |

-- 
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 46458] Guest screen is corrupted after host screen locked

2012-02-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=46458

Jakob Bornecrantz  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #1 from Jakob Bornecrantz  2012-02-22 17:35:08 
PST ---
This is a known bug and is in the host. The problem is that the host discards
the guest screen contents when the window is hidden, and has no way to tell the
guest to redraw it.

There is one thing that is a bit weird, the fact that it works "enable_fbdev"
(2), are you sure that fbcon is running? Is the guest window size 800x600 or is
the VGA mode as seen in (1)?

Cheers, Jakob.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] r300g: Use automake to generate Makefile v2

2012-02-22 Thread Tom Stellard

v2:
  - s/$(top_builddir)/$(top_srcdir)/
  - Always generate Makefile.in
---
 configure.ac   |1 +
 src/gallium/drivers/r300/.gitignore|5 ++
 src/gallium/drivers/r300/Makefile  |   25 -
 src/gallium/drivers/r300/Makefile.am   |   38 ++
 src/gallium/drivers/r300/compiler/tests/.gitignore |1 -
 src/gallium/drivers/r300/compiler/tests/Makefile   |   53 
 6 files changed, 44 insertions(+), 79 deletions(-)
 create mode 100644 src/gallium/drivers/r300/.gitignore
 delete mode 100644 src/gallium/drivers/r300/Makefile
 create mode 100644 src/gallium/drivers/r300/Makefile.am
 delete mode 100644 src/gallium/drivers/r300/compiler/tests/.gitignore
 delete mode 100644 src/gallium/drivers/r300/compiler/tests/Makefile

diff --git a/configure.ac b/configure.ac
index 846b623..c8850cf 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1932,6 +1932,7 @@ CXXFLAGS="$CXXFLAGS $USER_CXXFLAGS"
 
 dnl Substitute the config
 AC_CONFIG_FILES([configs/autoconf
+   src/gallium/drivers/r300/Makefile
src/gbm/Makefile
src/gbm/main/gbm.pc
src/egl/wayland/Makefile
diff --git a/src/gallium/drivers/r300/.gitignore 
b/src/gallium/drivers/r300/.gitignore
new file mode 100644
index 000..5e510eb
--- /dev/null
+++ b/src/gallium/drivers/r300/.gitignore
@@ -0,0 +1,5 @@
+Makefile
+Makefile.in
+radeon_compiler_util_tests
+.libs/
+.deps/
diff --git a/src/gallium/drivers/r300/Makefile 
b/src/gallium/drivers/r300/Makefile
deleted file mode 100644
index 2af1913..000
--- a/src/gallium/drivers/r300/Makefile
+++ /dev/null
@@ -1,25 +0,0 @@
-TOP = ../../../..
-include $(TOP)/configs/current
-
-LIBNAME = r300
-
-# get C_SOURCES
-include Makefile.sources
-
-# needed to build non-libmesagallium.a targets
-C_SOURCES += \
-   $(TOP)/src/glsl/ralloc.c \
-   $(TOP)/src/mesa/program/register_allocate.c
-
-#This is for libdrm inlude path
-CFLAGS+=$(RADEON_CFLAGS)
-
-LIBRARY_INCLUDES = \
-   -I$(TOP)/include \
-   -I$(TOP)/src/mesa \
-   -I$(TOP)/src/glsl
-
-include ../../Makefile.template
-
-test: default
-   @$(MAKE) -s -C compiler/tests/
diff --git a/src/gallium/drivers/r300/Makefile.am 
b/src/gallium/drivers/r300/Makefile.am
new file mode 100644
index 000..298aa40
--- /dev/null
+++ b/src/gallium/drivers/r300/Makefile.am
@@ -0,0 +1,38 @@
+include Makefile.sources
+
+noinst_LIBRARIES = libr300.a
+noinst_PROGRAMS = radeon_compiler_util_tests
+testdir=compiler/tests
+
+AM_CFLAGS = \
+   -I$(top_srcdir)/src/gallium/include \
+   -I$(top_srcdir)/src/gallium/auxiliary \
+   -I$(top_srcdir)/src/gallium/drivers \
+   -I$(top_srcdir)/include \
+   -I$(top_srcdir)/src/mesa \
+   -I$(top_srcdir)/src/glsl \
+   -I$(top_srcdir)/src/mapi \
+   $(LLVM_CFLAGS) \
+   $(RADEON_CFLAGS)
+
+libr300_a_SOURCES = \
+   $(C_SOURCES) \
+   $(top_srcdir)/src/glsl/ralloc.c \
+   $(top_srcdir)/src/mesa/program/register_allocate.c
+
+test_LDADD = libr300.a
+test_SOURCES = \
+   $(testdir)/rc_test_helpers.c \
+   $(testdir)/unit_test.c
+test_CFLAGS = -I$(top_srcdir)/src/gallium/drivers/r300/compiler
+
+radeon_compiler_util_tests_LDADD = $(test_LDADD)
+radeon_compiler_util_tests_CFLAGS = $(test_CFLAGS)
+radeon_compiler_util_tests_SOURCES = \
+   $(test_SOURCES) \
+   $(testdir)/radeon_compiler_util_tests.c
+
+default: libr300.a
+
+test: $(noinst_PROGRAMS)
+   $(foreach test, $^, @./$(test))
diff --git a/src/gallium/drivers/r300/compiler/tests/.gitignore 
b/src/gallium/drivers/r300/compiler/tests/.gitignore
deleted file mode 100644
index 85672fe..000
--- a/src/gallium/drivers/r300/compiler/tests/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-radeon_compiler_util_tests
diff --git a/src/gallium/drivers/r300/compiler/tests/Makefile 
b/src/gallium/drivers/r300/compiler/tests/Makefile
deleted file mode 100644
index 6eda34a..000
--- a/src/gallium/drivers/r300/compiler/tests/Makefile
+++ /dev/null
@@ -1,53 +0,0 @@
-TOP = ../../../../../..
-include $(TOP)/configs/current
-
-CFLAGS += -Wall -Werror
-
-### Basic defines ###
-TESTS =radeon_compiler_util_tests
-
-TEST_SOURCES := $(TESTS:=.c)
-
-SHARED_SOURCES =   \
-   rc_test_helpers.c   \
-   unit_test.c
-
-C_SOURCES = $(SHARED_SOURCES) $(TEST_SOURCES)
-
-INCLUDES = \
-   -I. \
-   -I..
-
-COMPILER_LIB = ../../libr300.a
-
-# TARGETS #
-
-default: depend run_tests
-
-depend: $(C_SOURCES)
-   rm -f depend
-   touch depend
-   $(MKDEP) $(MKDEP_OPTIONS) $(INCLUDES) $^ 2> /dev/null
-
-# Remove .o and backup files
-clean:
-   rm -f $(TESTS) depend depend.bak
-
-$(TESTS): $(TESTS:=.o) $(SHARED_SOURCES:.c=.o) $(COMPILER_LIB)
-   $(APP_CC) -o $@ $^
-
-run_tests: $(TESTS)
-   @echo "RUNNING TESTS:"
-   @echo ""
-   $(foreach test, $^, @./$(test))
-
-.PHONY: $(COMPILER_LIB)
-$(COMPILER_LIB):
-   $(M

Re: [Mesa-dev] [PATCH] glapi: Fix incorrect enum value.

2012-02-22 Thread Chad Versace

On 02/22/2012 04:29 PM, Kenneth Graunke wrote:
> On 02/22/2012 04:06 PM, Chad Versace wrote:
>> On 02/22/2012 02:22 PM, Ian Romanick wrote:
>>> On 02/22/2012 02:17 PM, Paul Berry wrote:
 On 22 February 2012 13:52, Ian Romanick>>> >  wrote:

  On 02/22/2012 01:41 PM, Paul Berry wrote:

From
  http://www.opengl.org/__registry/specs/ARB/seamless___cube_map.txt
  :

   Accepted by the   parameter of Enable, Disable and
  IsEnabled,
   and by the   parameter of GetBooleanv, GetIntegerv,
  GetFloatv
   and GetDoublev:

   TEXTURE_CUBE_MAP_SEAMLESS   0x884F


  Oops.  That was my typo.  You'll also have to regenerate the various
  files that depend on the XML definitions.  I think this change
  should only cause changes in src/mesa/main/enums.c.

  Reviewed-by: Ian Romanick>>>  >


 Oops.  I didn't realize that those files weren't built automatically.
 I'll send an updated patch.
>>>
>>> Dear god, no!  The patch will be huge.
>>
 Is there any good reason why we don't automatically generate files like
 enum.c as part of the mesa build process?  The comment at the top of
 src/mapi/glapi/gen/Makefile says "This file isn't used during a normal
 compilation since we don't want to require Python in order to compile
 Mesa."  But I don't think that makes sense anymore, because Python is
 required to build files like src/mapi/es2api/glapi_mapi_tmp.h, as well
 as some files in src/glsl.

 In point of fact, it seems really strange that a file like
 src/mapi/es2api/glapi_mapi_tmp.h is autogenerated during the build
 process, but src/mesa/main/enums.c isn't, since both files are built
 from the same set of xml sources.
>>>
>>> A couple reasons:
>>
>> I really want to see all *build* artifacts removed from Mesa's *source* 
>> control. I recall the
>> pain of having the bison and flex output managed by git, and I don't like 
>> continuing that fallacy.
>>
>>> 1. The generated files really, really, really should be in git so that 
>>> accidental changes will be noticed.  This has bitten us a couple times.
>>
>> Wouldn't `git log *.xml *.py` also alert you that the generated headers have 
>> changed?
> 
> Not if you remove them from git...

Since the generated headers are exclusively generated by the xml and python 
scripts in src/mapi, I insist that
`git log *.xml *.py` is a very good indicator that the generated headers have 
changed.

>>> 2. Changes to the XML files frequently precipitate changes to files in the 
>>> xserver.  There's no way to automatically handle that.
>>
>> I don't understand how 2 affects this discussion. Is it that the xserver 
>> build relies on these generated headers? If so, then
>> we can move the generated headers to the xserver repo and merrily remove 
>> these build artifacts from Mesa's source control.
>> Afterwards, it would be the xserver's devs responsibility to manually update 
>> their headers, or fix their makefiles to gen them
>> at build time.
> 
> I'll let Ian explain it, but essentially two things are generated from these 
> XML files:
> 
> 1. Mesa headers/code
> 2. X server headers/code
> 
> So if you change them, you still need to manually regenerate the X server 
> code and commit those to the xserver repository.  In other words, integrating 
> this into the build system doesn't eliminate manual steps (and perhaps gives 
> you the illusion that everything happens automatically).
> 
> It would be nice to solve this problem, but I'm not sure how.

I don't understand your rebuttal to my point 2. Actually, it seems that you 
agree with my proposal.
To "manually regenerate the X server code and commit those to the xserver 
repository" is exactly what I suggested.
Is there any reason why this proposal is unacceptable? It just moves the burden 
of manually updating the headers
to the project that will consume those headers.
 
>>> 3. Several of the scripts take a really, really long time to run.  I'm not 
>>> eager to add a few minutes to my clean-build times.
>>
>> $ cd src/mapi/glapi/gen
>> $ make mesa
>> real0m5.634s
>>
>> I don't think an adding 5 seconds to a clean build is cause for concern if 
>> the addition allows us
>> to remove build artifacts from source control.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glapi: Fix incorrect enum value.

2012-02-22 Thread Kenneth Graunke


On 02/22/2012 04:06 PM, Chad Versace wrote:

On 02/22/2012 02:22 PM, Ian Romanick wrote:

On 02/22/2012 02:17 PM, Paul Berry wrote:

On 22 February 2012 13:52, Ian Romanickmailto:i...@freedesktop.org>>  wrote:

 On 02/22/2012 01:41 PM, Paul Berry wrote:

   From
 http://www.opengl.org/__registry/specs/ARB/seamless___cube_map.txt
 :

  Accepted by the   parameter of Enable, Disable and
 IsEnabled,
  and by the   parameter of GetBooleanv, GetIntegerv,
 GetFloatv
  and GetDoublev:

  TEXTURE_CUBE_MAP_SEAMLESS   0x884F


 Oops.  That was my typo.  You'll also have to regenerate the various
 files that depend on the XML definitions.  I think this change
 should only cause changes in src/mesa/main/enums.c.

 Reviewed-by: Ian Romanickmailto:ian.d.roman...@intel.com>>


Oops.  I didn't realize that those files weren't built automatically.
I'll send an updated patch.


Dear god, no!  The patch will be huge.



Is there any good reason why we don't automatically generate files like
enum.c as part of the mesa build process?  The comment at the top of
src/mapi/glapi/gen/Makefile says "This file isn't used during a normal
compilation since we don't want to require Python in order to compile
Mesa."  But I don't think that makes sense anymore, because Python is
required to build files like src/mapi/es2api/glapi_mapi_tmp.h, as well
as some files in src/glsl.

In point of fact, it seems really strange that a file like
src/mapi/es2api/glapi_mapi_tmp.h is autogenerated during the build
process, but src/mesa/main/enums.c isn't, since both files are built
from the same set of xml sources.


A couple reasons:


I really want to see all *build* artifacts removed from Mesa's *source* 
control. I recall the
pain of having the bison and flex output managed by git, and I don't like 
continuing that fallacy.


1. The generated files really, really, really should be in git so that 
accidental changes will be noticed.  This has bitten us a couple times.


Wouldn't `git log *.xml *.py` also alert you that the generated headers have 
changed?


Not if you remove them from git...


2. Changes to the XML files frequently precipitate changes to files in the 
xserver.  There's no way to automatically handle that.


I don't understand how 2 affects this discussion. Is it that the xserver build 
relies on these generated headers? If so, then
we can move the generated headers to the xserver repo and merrily remove these 
build artifacts from Mesa's source control.
Afterwards, it would be the xserver's devs responsibility to manually update 
their headers, or fix their makefiles to gen them
at build time.


I'll let Ian explain it, but essentially two things are generated from 
these XML files:


1. Mesa headers/code
2. X server headers/code

So if you change them, you still need to manually regenerate the X 
server code and commit those to the xserver repository.  In other words, 
integrating this into the build system doesn't eliminate manual steps 
(and perhaps gives you the illusion that everything happens automatically).


It would be nice to solve this problem, but I'm not sure how.


3. Several of the scripts take a really, really long time to run.  I'm not 
eager to add a few minutes to my clean-build times.


$ cd src/mapi/glapi/gen
$ make mesa
real0m5.634s

I don't think an adding 5 seconds to a clean build is cause for concern if the 
addition allows us
to remove build artifacts from source control.


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 mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glapi: Fix incorrect enum value.

2012-02-22 Thread Paul Berry

On 22 February 2012 14:22, Ian Romanick  wrote:

> On 02/22/2012 02:17 PM, Paul Berry wrote:
>
>> On 22 February 2012 13:52, Ian Romanick > > wrote:
>>
>>On 02/22/2012 01:41 PM, Paul Berry wrote:
>>
>>  From
>>http://www.opengl.org/__**registry/specs/ARB/seamless___**
>> cube_map.txt
>>
>>> cube_map.txt
>> >:
>>
>> Accepted by the  parameter of Enable, Disable and
>>IsEnabled,
>> and by the  parameter of GetBooleanv, GetIntegerv,
>>GetFloatv
>> and GetDoublev:
>>
>> TEXTURE_CUBE_MAP_SEAMLESS   0x884F
>>
>>
>>Oops.  That was my typo.  You'll also have to regenerate the various
>>files that depend on the XML definitions.  I think this change
>>should only cause changes in src/mesa/main/enums.c.
>>
>>Reviewed-by: Ian Romanick >>
>>
>>
>>
>> Oops.  I didn't realize that those files weren't built automatically.
>> I'll send an updated patch.
>>
>
> Dear god, no!  The patch will be huge.


Actually, it's pretty tiny since it didn't change any enum names (and hence
didn't move around the offsets in all_enums).  But I can see why the patch
would be huge in most cases.  All the same, the diff is not very
informative, so I will spare you having to look at it :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glapi: Fix incorrect enum value.

2012-02-22 Thread Paul Berry

On 22 February 2012 16:06, Chad Versace wrote:

> On 02/22/2012 02:22 PM, Ian Romanick wrote:
> > On 02/22/2012 02:17 PM, Paul Berry wrote:
> >> On 22 February 2012 13:52, Ian Romanick  >> > wrote:
> >>
> >> On 02/22/2012 01:41 PM, Paul Berry wrote:
> >>
> >>   From
> >>
> http://www.opengl.org/__registry/specs/ARB/seamless___cube_map.txt
> >>  >:
> >>
> >>  Accepted by the  parameter of Enable, Disable and
> >> IsEnabled,
> >>  and by the  parameter of GetBooleanv, GetIntegerv,
> >> GetFloatv
> >>  and GetDoublev:
> >>
> >>  TEXTURE_CUBE_MAP_SEAMLESS   0x884F
> >>
> >>
> >> Oops.  That was my typo.  You'll also have to regenerate the various
> >> files that depend on the XML definitions.  I think this change
> >> should only cause changes in src/mesa/main/enums.c.
> >>
> >> Reviewed-by: Ian Romanick  >> >
> >>
> >>
> >> Oops.  I didn't realize that those files weren't built automatically.
> >> I'll send an updated patch.
> >
> > Dear god, no!  The patch will be huge.
>
> >> Is there any good reason why we don't automatically generate files like
> >> enum.c as part of the mesa build process?  The comment at the top of
> >> src/mapi/glapi/gen/Makefile says "This file isn't used during a normal
> >> compilation since we don't want to require Python in order to compile
> >> Mesa."  But I don't think that makes sense anymore, because Python is
> >> required to build files like src/mapi/es2api/glapi_mapi_tmp.h, as well
> >> as some files in src/glsl.
> >>
> >> In point of fact, it seems really strange that a file like
> >> src/mapi/es2api/glapi_mapi_tmp.h is autogenerated during the build
> >> process, but src/mesa/main/enums.c isn't, since both files are built
> >> from the same set of xml sources.
> >
> > A couple reasons:
>
> I really want to see all *build* artifacts removed from Mesa's *source*
> control. I recall the
> pain of having the bison and flex output managed by git, and I don't like
> continuing that fallacy.
>
> > 1. The generated files really, really, really should be in git so that
> accidental changes will be noticed.  This has bitten us a couple times.
>
> Wouldn't `git log *.xml *.py` also alert you that the generated headers
> have changed?
> >
> > 2. Changes to the XML files frequently precipitate changes to files in
> the xserver.  There's no way to automatically handle that.
>
> I don't understand how 2 affects this discussion. Is it that the xserver
> build relies on these generated headers? If so, then
> we can move the generated headers to the xserver repo and merrily remove
> these build artifacts from Mesa's source control.
> Afterwards, it would be the xserver's devs responsibility to manually
> update their headers, or fix their makefiles to gen them
> at build time.
>
> > 3. Several of the scripts take a really, really long time to run.  I'm
> not eager to add a few minutes to my clean-build times.
>
> $ cd src/mapi/glapi/gen
> $ make mesa
> real0m5.634s
>
> I don't think an adding 5 seconds to a clean build is cause for concern if
> the addition allows us
> to remove build artifacts from source control.
>

I agree with this.  In my experience, including build outputs in source
control is nearly always a mistake; as a rule, I'd rather exclude build
artifacts from source control except in situations where there is no
feasible alternative.  IMHO this doesn't seem like one of those situations.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glapi: Fix incorrect enum value.

2012-02-22 Thread Chad Versace

On 02/22/2012 02:22 PM, Ian Romanick wrote:
> On 02/22/2012 02:17 PM, Paul Berry wrote:
>> On 22 February 2012 13:52, Ian Romanick > > wrote:
>>
>> On 02/22/2012 01:41 PM, Paul Berry wrote:
>>
>>   From
>> http://www.opengl.org/__registry/specs/ARB/seamless___cube_map.txt
>> :
>>
>>  Accepted by the  parameter of Enable, Disable and
>> IsEnabled,
>>  and by the  parameter of GetBooleanv, GetIntegerv,
>> GetFloatv
>>  and GetDoublev:
>>
>>  TEXTURE_CUBE_MAP_SEAMLESS   0x884F
>>
>>
>> Oops.  That was my typo.  You'll also have to regenerate the various
>> files that depend on the XML definitions.  I think this change
>> should only cause changes in src/mesa/main/enums.c.
>>
>> Reviewed-by: Ian Romanick > >
>>
>>
>> Oops.  I didn't realize that those files weren't built automatically.
>> I'll send an updated patch.
> 
> Dear god, no!  The patch will be huge.
 
>> Is there any good reason why we don't automatically generate files like
>> enum.c as part of the mesa build process?  The comment at the top of
>> src/mapi/glapi/gen/Makefile says "This file isn't used during a normal
>> compilation since we don't want to require Python in order to compile
>> Mesa."  But I don't think that makes sense anymore, because Python is
>> required to build files like src/mapi/es2api/glapi_mapi_tmp.h, as well
>> as some files in src/glsl.
>>
>> In point of fact, it seems really strange that a file like
>> src/mapi/es2api/glapi_mapi_tmp.h is autogenerated during the build
>> process, but src/mesa/main/enums.c isn't, since both files are built
>> from the same set of xml sources.
> 
> A couple reasons:

I really want to see all *build* artifacts removed from Mesa's *source* 
control. I recall the
pain of having the bison and flex output managed by git, and I don't like 
continuing that fallacy.

> 1. The generated files really, really, really should be in git so that 
> accidental changes will be noticed.  This has bitten us a couple times.

Wouldn't `git log *.xml *.py` also alert you that the generated headers have 
changed?
> 
> 2. Changes to the XML files frequently precipitate changes to files in the 
> xserver.  There's no way to automatically handle that.

I don't understand how 2 affects this discussion. Is it that the xserver build 
relies on these generated headers? If so, then
we can move the generated headers to the xserver repo and merrily remove these 
build artifacts from Mesa's source control.
Afterwards, it would be the xserver's devs responsibility to manually update 
their headers, or fix their makefiles to gen them
at build time.

> 3. Several of the scripts take a really, really long time to run.  I'm not 
> eager to add a few minutes to my clean-build times.

$ cd src/mapi/glapi/gen
$ make mesa
real0m5.634s

I don't think an adding 5 seconds to a clean build is cause for concern if the 
addition allows us
to remove build artifacts from source control.


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] [Bug 42128] Crash when visiting a site with Firefox

2012-02-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=42128

--- Comment #12 from Benoit Jacob  2012-02-22 16:00:47 PST 
---
OK, indeed we should not attempt to do WebGL on OpenGL 1.

But the stack trace in https://bugzilla.mozilla.org/show_bug.cgi?id=696636#c11
also shows that there is a driver bug here.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glapi: Fix incorrect enum value.

2012-02-22 Thread Corbin Simpson

On Wed, Feb 22, 2012 at 2:22 PM, Ian Romanick  wrote:
> 3. Several of the scripts take a really, really long time to run.  I'm not
> eager to add a few minutes to my clean-build times.

Someday, when I have time, I'll fix this. Maybe during PyCon. I really
regret having been too busy with work to keep hacking Mesa.

But yeah, in an ideal world, those scripts really should only take a
few seconds, not a few minutes.

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glapi: Fix incorrect enum value.

2012-02-22 Thread Ian Romanick


On 02/22/2012 02:17 PM, Paul Berry wrote:

On 22 February 2012 13:52, Ian Romanick mailto:i...@freedesktop.org>> wrote:

On 02/22/2012 01:41 PM, Paul Berry wrote:

  From
http://www.opengl.org/__registry/specs/ARB/seamless___cube_map.txt
:

 Accepted by the  parameter of Enable, Disable and
IsEnabled,
 and by the  parameter of GetBooleanv, GetIntegerv,
GetFloatv
 and GetDoublev:

 TEXTURE_CUBE_MAP_SEAMLESS   0x884F


Oops.  That was my typo.  You'll also have to regenerate the various
files that depend on the XML definitions.  I think this change
should only cause changes in src/mesa/main/enums.c.

Reviewed-by: Ian Romanick mailto:ian.d.roman...@intel.com>>


Oops.  I didn't realize that those files weren't built automatically.
I'll send an updated patch.


Dear god, no!  The patch will be huge.


Is there any good reason why we don't automatically generate files like
enum.c as part of the mesa build process?  The comment at the top of
src/mapi/glapi/gen/Makefile says "This file isn't used during a normal
compilation since we don't want to require Python in order to compile
Mesa."  But I don't think that makes sense anymore, because Python is
required to build files like src/mapi/es2api/glapi_mapi_tmp.h, as well
as some files in src/glsl.

In point of fact, it seems really strange that a file like
src/mapi/es2api/glapi_mapi_tmp.h is autogenerated during the build
process, but src/mesa/main/enums.c isn't, since both files are built
from the same set of xml sources.


A couple reasons:

1. The generated files really, really, really should be in git so that 
accidental changes will be noticed.  This has bitten us a couple times.


2. Changes to the XML files frequently precipitate changes to files in 
the xserver.  There's no way to automatically handle that.


3. Several of the scripts take a really, really long time to run.  I'm 
not eager to add a few minutes to my clean-build times.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glapi: Fix incorrect enum value.

2012-02-22 Thread Paul Berry

On 22 February 2012 13:52, Ian Romanick  wrote:

> On 02/22/2012 01:41 PM, Paul Berry wrote:
>
>>  From 
>> http://www.opengl.org/**registry/specs/ARB/seamless_**cube_map.txt
>> :
>>
>> Accepted by the  parameter of Enable, Disable and IsEnabled,
>> and by the  parameter of GetBooleanv, GetIntegerv, GetFloatv
>> and GetDoublev:
>>
>> TEXTURE_CUBE_MAP_SEAMLESS   0x884F
>>
>
> Oops.  That was my typo.  You'll also have to regenerate the various files
> that depend on the XML definitions.  I think this change should only cause
> changes in src/mesa/main/enums.c.
>
> Reviewed-by: Ian Romanick 

Oops.  I didn't realize that those files weren't built automatically.  I'll
send an updated patch.

Is there any good reason why we don't automatically generate files like
enum.c as part of the mesa build process?  The comment at the top of
src/mapi/glapi/gen/Makefile says "This file isn't used during a normal
compilation since we don't want to require Python in order to compile
Mesa."  But I don't think that makes sense anymore, because Python is
required to build files like src/mapi/es2api/glapi_mapi_tmp.h, as well as
some files in src/glsl.

In point of fact, it seems really strange that a file like
src/mapi/es2api/glapi_mapi_tmp.h is autogenerated during the build process,
but src/mesa/main/enums.c isn't, since both files are built from the same
set of xml sources.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 42128] Crash when visiting a site with Firefox

2012-02-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=42128

--- Comment #11 from Ian Romanick  2012-02-22 14:13:30 
PST ---
(In reply to comment #10)
> I get the crash with this error too (865G):
> 
> $  firefox
> Mesa 8.1-devel implementation error: unexpected format GL_DEPTH_COMPONENT24 in
> _mesa_choose_tex_format()

Can you set a breakpoint a _mesa_problem and collect a backtrace?

> Please report at bugs.freedesktop.org
> firefox: main/formats.c:1556: _mesa_get_format_bytes: Assertion
> `info->BytesPerBlock' failed.
> 
> A Firefox developer said this is a bug in mesa
> https://bugzilla.mozilla.org/show_bug.cgi?id=696636#c12
> 
> 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated 
> Graphics
> Controller (rev 02)
> mesa 8.1-git  6e738d35c5c88769ececbadd5f4ac14d36647168
> intel 2.17-git 66cc9c69657ac2703f2c7fc3c2c50f06bf5daa99
> libdrm 2.4.31-git 9b3ad51ae5fd9654df8ef75de845a519015150bb
> linux 3.2.6

The bigger question is why is Firefox even trying to use this driver to provide
WebGL support?  This hardware cannot possibly handle it.  At all.  WebGL
requires either OpenGL ES 2.0 or desktop GL with ARB_fragment_shader.  As you
can see from the glxinfo output, this hardware has none of the above.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glapi: Fix incorrect enum value.

2012-02-22 Thread Ian Romanick


On 02/22/2012 01:41 PM, Paul Berry wrote:

 From http://www.opengl.org/registry/specs/ARB/seamless_cube_map.txt:

 Accepted by the  parameter of Enable, Disable and IsEnabled,
 and by the  parameter of GetBooleanv, GetIntegerv, GetFloatv
 and GetDoublev:

 TEXTURE_CUBE_MAP_SEAMLESS   0x884F


Oops.  That was my typo.  You'll also have to regenerate the various 
files that depend on the XML definitions.  I think this change should 
only cause changes in src/mesa/main/enums.c.


Reviewed-by: Ian Romanick 


---
  src/mapi/glapi/gen/ARB_seamless_cube_map.xml |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/mapi/glapi/gen/ARB_seamless_cube_map.xml 
b/src/mapi/glapi/gen/ARB_seamless_cube_map.xml
index 8dc827c..84e8aa8 100644
--- a/src/mapi/glapi/gen/ARB_seamless_cube_map.xml
+++ b/src/mapi/glapi/gen/ARB_seamless_cube_map.xml
@@ -4,7 +4,7 @@
  

  
-
+
  
  
  

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] ralloc: Make rewrite_tail increase "start" by the new text's length.

2012-02-22 Thread Ian Romanick


On 02/21/2012 01:38 PM, Kenneth Graunke wrote:

Both callers of rewrite_tail immediately compute the new total string
length by adding the (known) length of the existing string plus the
length of the newly appended text.  Unfortunately, callers generally
won't know the length of the new text, as it's printf-formatted.

Since ralloc already computes this length, it makes sense to add it in
and save the caller the effort.  This simplifies both existing callers,
but more importantly, will allow for cheap-appending in the next commit.

Signed-off-by: Kenneth Graunke


The series is

Reviewed-by: Ian Romanick 


---
  src/glsl/link_uniforms.cpp |   14 +-
  src/glsl/linker.h  |2 +-
  src/glsl/ralloc.c  |   11 ++-
  src/glsl/ralloc.h  |6 --
  4 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index d51850c..aca6dc0 100644
--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -67,7 +67,7 @@ uniform_field_visitor::process(ir_variable *var)

  void
  uniform_field_visitor::recursion(const glsl_type *t, char **name,
-unsigned name_length)
+size_t name_length)
  {
 /* Records need to have each field processed individually.
  *
@@ -80,20 +80,16 @@ uniform_field_visitor::recursion(const glsl_type *t, char 
**name,
 const char *field = t->fields.structure[i].name;

 /* Append '.field' to the current uniform name. */
-ralloc_asprintf_rewrite_tail(name, name_length, ".%s", field);
+ralloc_asprintf_rewrite_tail(name,&name_length, ".%s", field);

-recursion(t->fields.structure[i].type, name,
-  name_length + 1 + strlen(field));
+recursion(t->fields.structure[i].type, name, name_length);
}
 } else if (t->is_array()&&  t->fields.array->is_record()) {
for (unsigned i = 0; i<  t->length; i++) {
-char subscript[13];
-
 /* Append the subscript to the current uniform name */
-const unsigned subscript_length = snprintf(subscript, 13, "[%u]", i);
-ralloc_asprintf_rewrite_tail(name, name_length, "%s", subscript);
+ralloc_asprintf_rewrite_tail(name,&name_length, "[%u]", i);

-recursion(t->fields.array, name, name_length + subscript_length);
+recursion(t->fields.array, name, name_length);
}
 } else {
this->visit_field(t, *name);
diff --git a/src/glsl/linker.h b/src/glsl/linker.h
index 433c63b..0b4c001 100644
--- a/src/glsl/linker.h
+++ b/src/glsl/linker.h
@@ -76,7 +76,7 @@ private:
  * \param name_length  Length of the current name \b not including the
  * terminating \c NUL character.
  */
-   void recursion(const glsl_type *t, char **name, unsigned name_length);
+   void recursion(const glsl_type *t, char **name, size_t name_length);
  };

  #endif /* GLSL_LINKER_H */
diff --git a/src/glsl/ralloc.c b/src/glsl/ralloc.c
index 91e4bab..2f93dcd 100644
--- a/src/glsl/ralloc.c
+++ b/src/glsl/ralloc.c
@@ -448,11 +448,11 @@ ralloc_vasprintf_append(char **str, const char *fmt, 
va_list args)
 size_t existing_length;
 assert(str != NULL);
 existing_length = *str ? strlen(*str) : 0;
-   return ralloc_vasprintf_rewrite_tail(str, existing_length, fmt, args);
+   return ralloc_vasprintf_rewrite_tail(str,&existing_length, fmt, args);
  }

  bool
-ralloc_asprintf_rewrite_tail(char **str, size_t start, const char *fmt, ...)
+ralloc_asprintf_rewrite_tail(char **str, size_t *start, const char *fmt, ...)
  {
 bool success;
 va_list args;
@@ -463,7 +463,7 @@ ralloc_asprintf_rewrite_tail(char **str, size_t start, 
const char *fmt, ...)
  }

  bool
-ralloc_vasprintf_rewrite_tail(char **str, size_t start, const char *fmt,
+ralloc_vasprintf_rewrite_tail(char **str, size_t *start, const char *fmt,
  va_list args)
  {
 size_t new_length;
@@ -479,11 +479,12 @@ ralloc_vasprintf_rewrite_tail(char **str, size_t start, 
const char *fmt,

 new_length = printf_length(fmt, args);

-   ptr = resize(*str, start + new_length + 1);
+   ptr = resize(*str, *start + new_length + 1);
 if (unlikely(ptr == NULL))
return false;

-   vsnprintf(ptr + start, new_length + 1, fmt, args);
+   vsnprintf(ptr + *start, new_length + 1, fmt, args);
 *str = ptr;
+   *start += new_length;
 return true;
  }
diff --git a/src/glsl/ralloc.h b/src/glsl/ralloc.h
index 1324f34..86306b1 100644
--- a/src/glsl/ralloc.h
+++ b/src/glsl/ralloc.h
@@ -329,10 +329,11 @@ char *ralloc_vasprintf(const void *ctx, const char *fmt, 
va_list args);
   * \param fmt   A printf-style formatting string
   *
   * \p str will be updated to the new pointer unless allocation fails.
+ * \p start will be increased by the length of the newly formatted text.
   *
   * \return True unless allocation failed.
   */
-bool ralloc_asprintf_rewrite_tail(char **

Re: [Mesa-dev] [PATCH 00/12] R600g: cleanups and rework of queries

2012-02-22 Thread Marek Olšák

On Wed, Feb 22, 2012 at 6:29 PM, Jerome Glisse  wrote:
> On Tue, Feb 21, 2012 at 7:55 PM, Marek Olšák  wrote:
>>
>> Hi everyone,
>>
>> Besides the cleanups, there are fixes for create_context fail paths and
>> rework of queries. The rework is the most important, because it eliminates
>> buffer_map calls (and therefore buffer_wait) in begin_query.
>>
>> There are no piglit regressions on Evergreen.
>>
>> Please review.
>>
>
> Reviewed.
>
> Do you test with 2d tiling on or off ?

I guess it's off (my kernel doesn't have the patches for 2D tiling).

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glapi: Fix incorrect enum value.

2012-02-22 Thread Paul Berry

>From http://www.opengl.org/registry/specs/ARB/seamless_cube_map.txt:

Accepted by the  parameter of Enable, Disable and IsEnabled,
and by the  parameter of GetBooleanv, GetIntegerv, GetFloatv
and GetDoublev:

TEXTURE_CUBE_MAP_SEAMLESS   0x884F
---
 src/mapi/glapi/gen/ARB_seamless_cube_map.xml |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/mapi/glapi/gen/ARB_seamless_cube_map.xml 
b/src/mapi/glapi/gen/ARB_seamless_cube_map.xml
index 8dc827c..84e8aa8 100644
--- a/src/mapi/glapi/gen/ARB_seamless_cube_map.xml
+++ b/src/mapi/glapi/gen/ARB_seamless_cube_map.xml
@@ -4,7 +4,7 @@
 
 
 
-
+
 
 
 
-- 
1.7.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i915: fallback to swrast when gl_PointSize met

2012-02-22 Thread Eric Anholt

On Tue, 21 Feb 2012 23:21:07 +0800, Liu Aleaxander  wrote:
> This patch(the way to fix this issue) is a little weird, as we already
> fallbacked to swrast when handling gl_PointSize(in vertex shader).
> Sounds that we didn't fallback enough;) This patch servers as fixing the
> gl_PointSize issue on Pineview platform.
> 
> Since the patch is a little weird, I thought a while for another fix:
> get the point size at intelRenderStart() (or somewhere else before
> vtbl.emit_state()) by reading the vertex program output. This is so
> tricky that I droped this fix.
> 
> Any better thoughts(or even fixes) are welcome and appreciate.
> 
> This patch would fix piglit glsl-vs-point-size on Pineview(when the GL
> version 2.0 requirement is removed).

It looks like to do this right in hardware, you just need to emit
_TNL_ATTRIB_PSZ with S4_VFMT_POINT_WIDTH in i915ValidateFragmentProgram
just before COLOR0.


pgpdVqU6FJCjB.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 00/12] R600g: cleanups and rework of queries

2012-02-22 Thread Alex Deucher

On Tue, Feb 21, 2012 at 7:55 PM, Marek Olšák  wrote:
> Hi everyone,
>
> Besides the cleanups, there are fixes for create_context fail paths and 
> rework of queries. The rework is the most important, because it eliminates 
> buffer_map calls (and therefore buffer_wait) in begin_query.
>
> There are no piglit regressions on Evergreen.
>
> Please review.

Reviewed-by: Alex Deucher 

>
> Marek Olšák (12):
>      r600g: define GROUP_FORCE_NEW_BLOCK in common header
>      r600g: consolidate common context init code
>      r600g: fix possible crashes in destroy_context when failing in 
> create_context
>      gallium/u_slab: fix possible crash in util_slab_destroy
>      r600g: simplify fail paths in create_context
>      r600g: fixup name of evergreen-specific function
>      r600g: remove duplicated function r600_state_sampler_init
>      r600g: remove duplicated set_xx_resource functions
>      r600g: remove duplicated evergreen_context_pipe_state_set_sampler
>      r600g: remove duplicated evergreen_context_ps_partial_flush
>      r600g: cleanup magic numbers in set_xx_sampler
>      r600g: rework queries
>
>  src/gallium/auxiliary/util/u_slab.c             |    8 +-
>  src/gallium/drivers/r600/evergreen_hw_context.c |  115 +-
>  src/gallium/drivers/r600/evergreen_state.c      |   16 +-
>  src/gallium/drivers/r600/r600.h                 |   38 ++--
>  src/gallium/drivers/r600/r600_hw_context.c      |  286 
> ---
>  src/gallium/drivers/r600/r600_hw_context_priv.h |    5 +
>  src/gallium/drivers/r600/r600_pipe.c            |   68 --
>  src/gallium/drivers/r600/r600_query.c           |   38 +++-
>  src/gallium/drivers/r600/r600_state_common.c    |   21 +--
>  9 files changed, 273 insertions(+), 322 deletions(-)
>
> Marek
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] gallivm: add integer and unsigned mod arit functions.

2012-02-22 Thread Tom Stellard

On Mon, Feb 20, 2012 at 01:50:43PM -0800, Jose Fonseca wrote:
> 
> 
> - Original Message -
> > 
> > 
> > - Original Message -
> > > On Sat, Feb 18, 2012 at 4:20 AM, Jose Fonseca 
> > > wrote:
> > > > - Original Message -
> > > >> On Fri, Feb 17, 2012 at 9:46 PM, Jose Fonseca
> > > >> 
> > > >> wrote:
> > > >> > Dave,
> > > >> >
> > > >> > Ideally there should be only one lp_build_mod() which will
> > > >> > invoke
> > > >> > LLVMBuildSRem or LLVMBuildURem depending on the value of
> > > >> > bld->type.sign.  The point being that this allows the same
> > > >> > code
> > > >> > generation logic to seemingly target any type without having
> > > >> > to
> > > >> > worry too much which target it is targeting.
> > > >>
> > > >> Yeah I agree with this for now, but I'm starting to think a lot
> > > >> of
> > > >> this stuff is redunant once I looked at what Tom has done.
> > > >>
> > > >> The thing is TGSI doesn't have that many crazy options where you
> > > >> are
> > > >> going to be targetting instructions at the wrong type, and
> > > >> wrapping
> > > >> all the basic llvm interfaces with an extra type layer seems to
> > > >> me
> > > >> long term like a waste of time.
> > > >
> > > > So far llvmpipe's TGSI->LLVM IR has only been targetting floating
> > > > point SIMD instructions.
> > > >
> > > > But truth is that many simple fragment shaders can be partially
> > > > done with 8bit and 16bit SIMD integers, if values are represented
> > > > in 8bit unorm and 16 bit unorms. The throughput for these will be
> > > > much higher, as not only we can squeeze more elements, they take
> > > > less cycles, and the hardware has several arithmetic units.
> > > >
> > > > The point of those lp_build_xxx functions is to handle this
> > > > transparently. See, e.g., how lp_build_mul handles fixed point.
> > > > Currently this is only used for blending, but the hope is to
> > > > eventually use it on TGSI translation of simple fragment shaders.
> > > >
> > > > Maybe not the case for the desktop GPUs, but I also heard that
> > > > some
> > > > low powered devices have shader engines w/ 8bit unorms.
> > > >
> > > > But of course, not all opcodes can be done correctly: and
> > > > URem/SRem
> > > > might not be one we care.
> > > >
> > > >> I'm happy for now to finish the integer support in the same
> > > >> style
> > > >> as
> > > >> the current code, but I think moving forward afterwards it might
> > > >> be
> > > >> worth investigating a more direct instruction emission scheme.
> > > >
> > > > If you wanna invoke LLVMBuildURem/LLVMBuildSRem directly from
> > > > tgsi
> > > > translation I'm fine with it. We can always generalize
> > > >
> > > >> Perhaps
> > > >> Tom can comment also from his experience.
> > > >
> > > > BTW, Tom, I just now noticed that there are two action versions
> > > > for
> > > > add:
> > > >
> > > > /* TGSI_OPCODE_ADD (CPU Only) */
> > > > static void
> > > > add_emit_cpu(
> > > >   const struct lp_build_tgsi_action * action,
> > > >   struct lp_build_tgsi_context * bld_base,
> > > >   struct lp_build_emit_data * emit_data)
> > > > {
> > > >   emit_data->output[emit_data->chan] =
> > > >   lp_build_add(&bld_base->base,
> > > >                                   emit_data->args[0],
> > > >                                   emit_data->args[1]);
> > > > }
> > > >
> > > > /* TGSI_OPCODE_ADD */
> > > > static void
> > > > add_emit(
> > > >   const struct lp_build_tgsi_action * action,
> > > >   struct lp_build_tgsi_context * bld_base,
> > > >   struct lp_build_emit_data * emit_data)
> > > > {
> > > >   emit_data->output[emit_data->chan] = LLVMBuildFAdd(
> > > >                                bld_base->base.gallivm->builder,
> > > >                                emit_data->args[0],
> > > >                                emit_data->args[1], "");
> > > > }
> > > >
> > > > Why is this necessary? lp_build_add will already call
> > > > LLVMBuildFAdd
> > > > internally as appropriate.
> > > >
> > > > Is this because some of the functions in lp_bld_arit.c will emit
> > > > x86 intrinsics? If so then a "no-x86-intrinsic" flag in the build
> > > > context would achieve the same effect with less code duplication.
> > > >
> > > > If possible I'd prefer a single version of these actions. If not,
> > > > then I'd prefer have them split: lp_build_action_cpu.c and
> > > > lp_build_action_gpu.
> > > 
> > > Yes, this is why a split them up.  I can add that flag and merge
> > > the
> > > actions together.
> > 
> > That would be nice. Thanks.
> 
> Tom, actually I've been looking more at the code, thinking about this, and 
> I'm not so sure what's best anymore.
> 
> I'd appreciate your honest answer: do you think the stuff in lp_bld_arit.[ch] 
> of any use for GPUs in general (or AMD's in particular), or is it just an 
> hinderance?
> 
> As I said before, for CPUs, this abstraction is useful, to allow to convert 
> TGSI (and other fixed function state) -> fixed point SIMD instructions, which 
> yield the

[Mesa-dev] [Bug 44405] Spring RTS crashes using r600g (5670, Redwood), kernel rejects relocations

2012-02-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=44405

Jerome Glisse  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #10 from Jerome Glisse  2012-02-22 10:13:29 
PST ---
Still an issue with more recent r600g/mesa ?

-- 
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] gbm: track buffer format through DRI drivers

2012-02-22 Thread Jesse Barnes

On Wed, 22 Feb 2012 12:42:59 -0500
Kristian Hoegsberg  wrote:

> On Tue, Feb 21, 2012 at 12:56:11PM -0800, Jesse Barnes wrote:
> > GBM needs the buffer format in order to communicate with DRM and clients
> > for things like scanout.
> > 
> > So track the DRI format requested in the various back ends and use it to
> > return the DRI format back to GBM when requested.  GBM will then map
> > this into the GBM surface type (which is in turn based on the DRM fb
> > format list).
> 
> Yes, that looks good now.  Just one thing left that I can see: we need
> to bump the versions of the __DRI_IMAGE extension in the drivers so
> that they advertise 3 if they support the format attribute.

Yeah, just bumped it for Intel, but radeon and gallium only support
version 1, which means they need other work to go to version 3 (the
query format support should be there though, so I think they just need
validateUsage support).

-- 
Jesse Barnes, Intel Open Source Technology Center


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/12] R600g: cleanups and rework of queries

2012-02-22 Thread Jerome Glisse

On Tue, Feb 21, 2012 at 7:55 PM, Marek Olšák  wrote:

> Hi everyone,
>
> Besides the cleanups, there are fixes for create_context fail paths and
> rework of queries. The rework is the most important, because it eliminates
> buffer_map calls (and therefore buffer_wait) in begin_query.
>
> There are no piglit regressions on Evergreen.
>
> Please review.
>
>
Reviewed.

Do you test with 2d tiling on or off ?

Cheers,
Jerome
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 46458] Guest screen is corrupted after host screen locked

2012-02-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=46458

Viktor Ostashevskyi  changed:

   What|Removed |Added

   Platform|Other   |x86 (IA32)
 OS/Version|All |Linux (All)
   Severity|normal  |major
   Priority|medium  |high

-- 
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 46458] New: Guest screen is corrupted after host screen locked

2012-02-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=46458

 Bug #: 46458
   Summary: Guest screen is corrupted after host screen locked
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: ost...@ostash.kiev.ua


I'm running Gentoo Linux under VMware Player 4.0.2 build-591240 on Windows XP.

Guest is running:

kernel 3.2.5 (provides vmwgfx 2.3.0.0)
mesa-8.0 (build with gallium and xatracker enabled)
xf86-video-vmware from today git (so I got xatracker-based driver)
xorg-server-1.11.4

Everything works perfectly and I'm able to get accelerated OpenGL.

However, if I lock host screen (Win+L) and unlock it, I got guest screen
corrupted and unusable.

I've checked following situations:

1) vmwgfx kenel module loaded, Xorg isn't started - works fine
2) vmwgfx kenel module loaded with enable_fbdev, Xorg isn't started - works
fine
3) vmwgfx kenel module loaded, Xorg is working and is on screen - FAIL
4) vmwgfx kenel module loaded, Xorg is working and VT on screen - FAIL
5) vmwgfx kenel module loaded with enable_fbdev, Xorg is working and is on
screen - FAIL
6) vmwgfx kenel module loaded with enable_fbdev, Xorg is working and VT on
screen - FAIL

So for me look like something isn't reinitialized correctly in xorg driver
after host screen is unlocked.

Only possible way to fix screen corruption is to shutdown/kill X server. VT is
redrawn correctly in few seconds.

I'll be glad to provide any other information/backtraces/debug outputs if
needed.

-- 
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] scons: Don't build the assembly sources on Mac OS X.

2012-02-22 Thread Jose Fonseca

Looks good. It doesn't look like the makefiles build assembly on MacOSX neither.

Jose

- Original Message -
> This patch allows the Mac OS X SCons build to complete. The assembly
> sources contain psuedo-ops that not are supported on Mac OS X.
> 
> Signed-off-by: Vinson Lee 
> ---
>  src/mapi/glapi/SConscript |2 +-
>  src/mesa/SConscript   |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mapi/glapi/SConscript b/src/mapi/glapi/SConscript
> index 9882806..4097a7f 100644
> --- a/src/mapi/glapi/SConscript
> +++ b/src/mapi/glapi/SConscript
> @@ -46,7 +46,7 @@ for s in mapi_sources:
>  #
>  # Assembly sources
>  #
> -if env['gcc'] and env['platform'] != 'windows':
> +if env['gcc'] and env['platform'] not in ('darwin', 'windows'):
>  if env['machine'] == 'x86':
>  env.Append(CPPDEFINES = [
>  'USE_X86_ASM',
> diff --git a/src/mesa/SConscript b/src/mesa/SConscript
> index e9b1f6a..10a0468 100644
> --- a/src/mesa/SConscript
> +++ b/src/mesa/SConscript
> @@ -384,7 +384,7 @@ if env['gles']:
>  #
>  # Assembly sources
>  #
> -if env['gcc'] and env['platform'] != 'windows':
> +if env['gcc'] and env['platform'] not in ('darwin', 'windows'):
>  if env['machine'] == 'x86':
>  env.Append(CPPDEFINES = [
>  'USE_X86_ASM',
> --
> 1.7.8.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] glcpp: Don't strlen() the output for every token being printed.

2012-02-22 Thread Jose Fonseca

- Original Message -
> The ralloc string appending functions were originally intended for
> simple, non-hot-path uses like printing to an info log.
> 
> Cuts Unigine Tropics load time by around 20% (6 seconds).
> 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/glsl/glcpp/glcpp-parse.y |   48
>  ++---
>  src/glsl/glcpp/glcpp.h   |2 +
>  2 files changed, 28 insertions(+), 22 deletions(-)
> 
> It would be far nicer if we had a string class that stored the length
> and
> had asprintf_append-style methods.  Like csString in Crystal Space.
>  But
> that's a more invasive change, I think.  STL has the ostringstream
> class
> for this exact purpose, but that would require rewriting everything
> to use
> C++ style IO, and I'm loathe to do that (mostly because we don't use
> it
> anywhere else).

Yes, while C++ style IO allows one to seemingly print user defined types just 
as easily as basic types, when one wants precise formatting for basic types, it 
is much more inconvenient and verbose than printf-like format specificiers.

FWIW, I wrote a small class that wraps std::vector, provides std::string like 
methods, and allows printf-like specifiers to aid manipulating paths in 
apitrace, on 
https://github.com/apitrace/apitrace/blob/master/common/os_string.hpp , and as 
you can see it doesn't take much.  But I think that in this particular the 
route you took of using ralloc_asprintf_rewrite_tail seems a more natural 
choice.

I noticed that many of the arguments are constant strings. I think it might be 
worth to try splitting the implementation of these functions such that the 
strlen() call happens in an inline function in src/glsl/ralloc.h, allowing the 
strlen() of constant strings to be determined at compile time.


BTW, your previous patch seems a good cleanup too.


Jose

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

37 matches

Mail list logo