date:20100112

Re: [Mesa3d-dev] [PATCH 3/4] [egl_g3d] Revalidate based on sequence number

2010-01-12 Thread Chia-I Wu

On Tue, Jan 12, 2010 at 5:03 PM, Chia-I Wu olva...@gmail.com wrote:
 Semantically, the validate call asks for nothing but the specified textures of
 the native surface _at the moment_.  There are some properties
 * It can be called repeatedly without any ill effect
 * It may return entirely different textures between two calls, without any
  knowledge in advance
 As such, splitting the call into get sequence number and validate is not
 possible.
 For optimization, some artifacts are added (and documented)
 * The argument textures may be NULL.  Since there will be no way to return
  the textures to the caller, the native display may skip the creation of the
  textures.
 * (NEW) A sequence number is returned to indicate which moment the textures
  belong to (even when the argument textures is NULL)
 Using these artifacts, EGL is capable to
 * validate the native surface with textures set to NULL to get the sequence
  number
 * if the sequence number differs from what EGLSurface knows (which rarely
  happens), validate is called again to retrieve the textures
 The force_validate is used to indicate that the first validate call is very
 likely to return a different sequence number, and it may call to retrieve
 the textures directly.
The attached patch is what's on my mind.  I only does a quick test and
it seems to work.
From a276ba00280bfe145f7af962424879e34fc61cba Mon Sep 17 00:00:00 2001
From: Chia-I Wu olva...@gmail.com
Date: Tue, 12 Jan 2010 18:08:02 +0800
Subject: [PATCH] st/egl_g3d: Use a sequence number to decide if validation is required.

It is not safe to assume that the native surface has not changed since
the last validation by checking the geometry alone.  Add a sequence
number to validate callback so that the native display can notify us.

Signed-off-by: Chia-I Wu olva...@gmail.com
---
 .../state_trackers/egl_g3d/common/egl_g3d.c|   35 +---
 .../state_trackers/egl_g3d/common/egl_g3d.h|1 +
 src/gallium/state_trackers/egl_g3d/common/native.h |7 ++--
 .../state_trackers/egl_g3d/kms/native_kms.c|9 -
 .../state_trackers/egl_g3d/kms/native_kms.h|1 +
 .../state_trackers/egl_g3d/x11/native_dri2.c   |   20 +--
 .../state_trackers/egl_g3d/x11/native_ximage.c |   14 +++-
 7 files changed, 66 insertions(+), 21 deletions(-)

diff --git a/src/gallium/state_trackers/egl_g3d/common/egl_g3d.c b/src/gallium/state_trackers/egl_g3d/common/egl_g3d.c
index 741e5b4..60fce03 100644
--- a/src/gallium/state_trackers/egl_g3d/common/egl_g3d.c
+++ b/src/gallium/state_trackers/egl_g3d/common/egl_g3d.c
@@ -63,22 +63,19 @@ egl_g3d_validate_context(_EGLDisplay *dpy, _EGLContext *ctx)
   }
 
   if (!gctx-force_validate) {
- EGLint cur_w, cur_h;
+ unsigned int seq_num;
 
- cur_w = gsurf-base.Width;
- cur_h = gsurf-base.Height;
  gsurf-native-validate(gsurf-native,
gbuf-native_atts, gbuf-num_atts,
-   NULL,
-   gsurf-base.Width, gsurf-base.Height);
- /* validate only when the geometry changed */
- if (gsurf-base.Width == cur_w  gsurf-base.Height == cur_h)
+   seq_num, NULL, NULL, NULL);
+ /* skip validation */
+ if (gsurf-sequence_number == seq_num)
 continue;
   }
 
   gsurf-native-validate(gsurf-native,
 gbuf-native_atts, gbuf-num_atts,
-(struct pipe_texture **) textures,
+gsurf-sequence_number, (struct pipe_texture **) textures,
 gsurf-base.Width, gsurf-base.Height);
   for (i = 0; i  gbuf-num_atts; i++) {
  struct pipe_texture *pt = textures[i];
@@ -599,6 +596,16 @@ egl_g3d_destroy_context(_EGLDriver *drv, _EGLDisplay *dpy, _EGLContext *ctx)
return EGL_TRUE;
 }
 
+static EGLBoolean
+init_surface_geometry(_EGLSurface *surf)
+{
+   struct egl_g3d_surface *gsurf = egl_g3d_surface(surf);
+
+   return gsurf-native-validate(gsurf-native, NULL, 0,
+ gsurf-sequence_number, NULL,
+ gsurf-base.Width, gsurf-base.Height);
+}
+
 static _EGLSurface *
 egl_g3d_create_window_surface(_EGLDriver *drv, _EGLDisplay *dpy,
   _EGLConfig *conf, EGLNativeWindowType win,
@@ -626,8 +633,7 @@ egl_g3d_create_window_surface(_EGLDriver *drv, _EGLDisplay *dpy,
   return NULL;
}
 
-   if (!gsurf-native-validate(gsurf-native, NULL, 0, NULL,
-gsurf-base.Width, gsurf-base.Height)) {
+   if (!init_surface_geometry(gsurf-base)) {
   gsurf-native-destroy(gsurf-native);
   free(gsurf);
   return NULL;
@@ -667,8 +673,7 @@ egl_g3d_create_pixmap_surface(_EGLDriver *drv, _EGLDisplay *dpy,
   return NULL;
}
 
-   if (!gsurf-native-validate(gsurf-native, NULL, 0, NULL,
-gsurf-base.Width, gsurf-base.Height)) {
+   if (!init_surface_geometry(gsurf-base)) {
   gsurf-native-destroy(gsurf-native);
   free(gsurf);
   return NULL;
@@ -706,6 +711,12 @@

Re: [Mesa3d-dev] Plans for EGL

2010-01-12 Thread Keith Whitwell

On Mon, 2010-01-11 at 20:23 -0800, Chia-I Wu wrote:
 Hi all,
 
 I just pushed a new EGL driver (egl_g3d) to master.  The new driver is located
 at src/gallium/state_trackers/egl_g3d/.  When built, it provides .a archives
 that are later linked to by src/gallium/winsys/drm/hw/egl_g3d/ to provide 
 the
 final EGL drivers loadable by libEGL.
 
 This new driver supports mixed client APIs (OpenGL, OpenVG, and OpenGL ES).  
 It
 supports both HW/SW rendering on X11 and supports EGL_MESA_screen_surface on
 bare KMS.  The goal of this driver is to provide _the_ EGL driver for Gallium
 architecture.
 
 I am working on merging opengl-es-v2 branch.  When that is done, I plan to 
 work
 on preparing EGL for easy/wide adoption.  The specific items I have right now
 are
 
 * Write up documentation
 * Remove unused/non-working EGL drivers
 * Remove drivers that are deprecated by egl_g3d
 * Automatic driver selection (like DRI)
 * Re-organize EGL demos
 
 The drivers to be removed are
 
 * Unused
   * src/egl/drivers/demo/
   * src/egl/drivers/xdri/
 * Non-working
   * src/egl/drivers/dri/
   * src/mesa/drivers/dri/fb/fb_egl.c
   * src/mesa/drivers/dri/radeon/server/radeon_egl.c
   * src/mesa/drivers/dri/r600/server/radeon_egl.c
   * src/mesa/drivers/dri/r300/server/radeon_egl.c
   * src/mesa/drivers/dri/r200/server/radeon_egl.c
 * Deprecated by egl_g3d
   * src/gallium/state_trackers/egl/
   * src/gallium/winsys/egl_xlib/
 
 If anyone has any concern or is actively using any of the driver listed above,
 please let me konw.  The removal, especially of those in the last category, is
 still a plan, and is supposed to be several weeks away.  If anyone has any
 trouble using/testing egl_g3d, please let me know too.
 
 As for the re-organization, I want to move various demos using EGL to
 progs/egl/.  The directory structure will be like
 
 progs/egl/opengl
 progs/egl/opengles1
 progs/egl/opengles2
 progs/egl/openvg
 
 There will be simple window-system glue code that the demos may use.  Simple
 demos who use the glue code will be able to run on multiple window systems 
 like
 X11 and bare KMS.
 
 There are also plans for new features and internal cleanups.  But I want to
 start with attracting new users/developers first, as EGL is almost ready to
 shine.

This all sounds great to me.  I'm looking forward to seeing this happen.

Keith


--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [PATH] Add double opcodes to TGSI Revision 2

2010-01-12 Thread Igor Oliveira

These patches add support to double opcodes as discussed in mail list.
The opcodes create are: movd, ddiv, dadd, dseq, dmax, dmin, dmul,
dmuladd, drcp and dslt.
They are used like suggested by Zack:

MOVD A.xy, C.xy, c.xy

where x is the lsb and y is the msb.

There are still missing some opcodes being implemented(i will send the
code soon), they are:
dfrac, dfracexp, dldexp and convert between float and double.

Revision 2 update:

In revision 2 we remove the create_double function it is not used,
change the MULADD opcode to DMAD and add a documentation to new
opcodes.

Michal: i am seeing the double opcode branch i can move the opcode
codes to use the exec_double_binary/unary

Igor
From 83f895a235e76d8d556411fd0154650a2598acd0 Mon Sep 17 00:00:00 2001
From: Igor Oliveira igor.olive...@openbossa.org
Date: Tue, 12 Jan 2010 07:40:50 -0400
Subject: [PATCH 1/3] tgsi: add double opcodes

---
 src/gallium/include/pipe/p_shader_tokens.h |   13 -
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/src/gallium/include/pipe/p_shader_tokens.h b/src/gallium/include/pipe/p_shader_tokens.h
index 550e2ab..789edaa 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -319,7 +319,18 @@ struct tgsi_property_data {
 #define TGSI_OPCODE_CASE142
 #define TGSI_OPCODE_DEFAULT 143
 #define TGSI_OPCODE_ENDSWITCH   144
-#define TGSI_OPCODE_LAST145
+
+#define TGSI_OPCODE_MOVD145
+#define TGSI_OPCODE_DDIV146
+#define TGSI_OPCODE_DADD147
+#define TGSI_OPCODE_DSEQ148
+#define TGSI_OPCODE_DMAX149
+#define TGSI_OPCODE_DMIN150
+#define TGSI_OPCODE_DMUL151
+#define TGSI_OPCODE_DMAD152
+#define TGSI_OPCODE_DRCP153
+#define TGSI_OPCODE_DSLT154
+#define TGSI_OPCODE_LAST155
 
 #define TGSI_SAT_NONE0  /* do not saturate */
 #define TGSI_SAT_ZERO_ONE1  /* clamp to [0,1] */
-- 
1.6.3.3

From 91d50bdbd6f35af9a0e342c46c8ee5fbe0910421 Mon Sep 17 00:00:00 2001
From: Igor Oliveira igor.olive...@openbossa.org
Date: Tue, 12 Jan 2010 07:41:08 -0400
Subject: [PATCH 2/3] tgsi: implement double opcodes

---
 src/gallium/auxiliary/tgsi/tgsi_exec.c   |  230 +-
 src/gallium/auxiliary/tgsi/tgsi_info.c   |   10 +
 src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h |   11 +-
 3 files changed, 249 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index f43233b..4f2b29c 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -69,6 +69,15 @@
 #define TILE_BOTTOM_LEFT  2
 #define TILE_BOTTOM_RIGHT 3
 
+union tgsi_double {
+   struct int_double {
+  int lsb;
+  int msb;
+  double d;
+   } id;
+   double d;
+};
+
 static void
 micro_abs(union tgsi_exec_channel *dst,
   const union tgsi_exec_channel *src)
@@ -380,6 +389,184 @@ micro_trunc(union tgsi_exec_channel *dst,
dst-f[3] = (float)(int)src-f[3];
 }
 
+static void
+micro_movd(union tgsi_exec_channel *dst,
+   const union tgsi_exec_channel *src)
+{
+   union tgsi_double dsrc, ddst;
+
+   dsrc.id.lsb = src-u[0];
+   dsrc.id.msb = src-u[1];
+
+   ddst.d = dsrc.d;
+
+   dst-u[0] = ddst.id.lsb;
+   dst-u[1] = ddst.id.msb;
+}
+
+static void
+micro_dadd(union tgsi_exec_channel *dst,
+   const union tgsi_exec_channel *src)
+{
+   union tgsi_double dsrc0, dsrc1, ddst;
+
+   dsrc0.id.lsb = src[0].u[0];
+   dsrc0.id.msb = src[0].u[1];
+
+   dsrc1.id.lsb = src[1].u[0];
+   dsrc1.id.msb = src[1].u[1];
+
+   ddst.d = dsrc0.d * dsrc1.d;
+
+   dst-u[0] = ddst.id.lsb;
+   dst-u[1] = ddst.id.msb;
+}
+
+static void
+micro_ddiv(union tgsi_exec_channel *dst,
+   const union tgsi_exec_channel *src)
+{
+   union tgsi_double dsrc0, dsrc1, ddst;
+
+   dsrc0.id.lsb = src[0].u[0];
+   dsrc0.id.msb = src[0].u[1];
+
+   dsrc1.id.lsb = src[1].u[0];
+   dsrc1.id.msb = src[1].u[1];
+
+   if (dsrc1.d != 0) {
+  ddst.d = dsrc0.d/dsrc1.d;
+  dst-u[0] = ddst.id.lsb;
+  dst-u[1] = ddst.id.msb;
+   }
+}
+
+static void
+micro_dseq(union tgsi_exec_channel *dst,
+   const union tgsi_exec_channel *src)
+{
+   union tgsi_double dsrc0, dsrc1, ddst;
+
+   dsrc0.id.lsb = src[0].u[0];
+   dsrc0.id.msb = src[0].u[1];
+
+   dsrc1.id.lsb = src[1].u[0];
+   dsrc1.id.msb = src[1].u[1];
+
+   ddst.d = dsrc0.d == dsrc1.d ? 1.0F : 0.0F;
+
+   dst-u[0] = ddst.id.lsb;
+   dst-u[1] = ddst.id.msb;
+}
+
+static void
+micro_dslt(union tgsi_exec_channel *dst,
+  const union tgsi_exec_channel *src)
+{
+   union tgsi_double dsrc0, dsrc1, ddst;
+
+   dsrc0.id.lsb = src[0].u[0];
+   dsrc0.id.msb = src[0].u[1];
+
+   dsrc1.id.lsb = src[1].u[0];
+   dsrc1.id.msb = src[1].u[1];
+
+   ddst.d = dsrc0.d  dsrc1.d ? 1.0F : 0.0F;
+
+   dst-u[0] =

Re: [Mesa3d-dev] [PATH] Add double opcodes to TGSI Revision 2

2010-01-12 Thread michal

Igor Oliveira wrote on 2010-01-12 12:52:
 Michal: i am seeing the double opcode branch i can move the opcode
 codes to use the exec_double_binary/unary
   
Igor,

Yes, that was my intention.

It would be great if you looked at what has been done in that branch and 
for each new opcode provide reference implementation in tgsi_exec.c, 
document it in gallium/docs/source/tgsi.rst and it would super cool if 
you could add a unit test in python/tests/regress/fragment-shader.

Thanks.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [Bug 26003] New: incorrect rendering in celestia; unsupported opcode 13

2010-01-12 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=26003

   Summary: incorrect rendering in celestia; unsupported opcode 13
   Product: Mesa
   Version: 7.6
  Platform: All
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa3d-dev@lists.sourceforge.net
ReportedBy: s...@robots.org.uk


The rendering of the planet Earth in Celestia is incorrect; see the attached
screenshot.

The following message is produced:

Mesa 7.6.1 implementation error: Unsupported opcode 13 (CMP) in vertex shader
Please report at bugzilla.freedesktop.org

I'm using intel 2.9.1, xserver 7.4, drm 2.4.15.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [Bug 26003] incorrect rendering in celestia; unsupported opcode 13

2010-01-12 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=26003





--- Comment #1 from Sam Morris s...@robots.org.uk  2010-01-12 04:24:26 PST ---
Created an attachment (id=32584)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=32584)
screenshot from celestia


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [Bug 26003] incorrect rendering in celestia; unsupported opcode 13

2010-01-12 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=26003





--- Comment #2 from Sam Morris s...@robots.org.uk  2010-01-12 04:24:53 PST ---
Created an attachment (id=32585)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=32585)
xorg log


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [Bug 26003] incorrect rendering in celestia; unsupported opcode 13

2010-01-12 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=26003





--- Comment #3 from Sam Morris s...@robots.org.uk  2010-01-12 06:02:26 PST ---
Created an attachment (id=32590)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=32590)
comparison screenshot with SW rendering

looks better, though it's still missing clouds


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [Bug 26003] incorrect rendering in celestia; unsupported opcode 13

2010-01-12 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=26003





--- Comment #4 from Sam Morris s...@robots.org.uk  2010-01-12 06:18:18 PST ---
This is resolved with 7.7. The clouds are still missing, however.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [Bug 26003] incorrect rendering in celestia; unsupported opcode 13

2010-01-12 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=26003


Sam Morris s...@robots.org.uk changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Comment #5 from Sam Morris s...@robots.org.uk  2010-01-12 06:23:02 PST ---
Ignore my last command. Clouds were disabled. Sorry for the noise!


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Gallium feature levels

2010-01-12 Thread Roland Scheidegger

On 11.01.2010 22:03, Zack Rusin wrote:
 On Monday 11 January 2010 15:17:00 Roland Scheidegger wrote:
 - extra mirror wrap modes - i don't think mirror repeat was ever
 supported and mirror clamp was removed in d3d10 but it seems that some
 hardware kept support for those
 Mirror repeat is a core feature in GL since 1.4 hence we can't just drop
 it. 
 
 I wasn't suggesting that. I was just pointing out what happens with it from 
 the D3D side.
 
 I think all hardware we'd ever care about would support it. mirror
 clamp / mirror clamp to edge are only an extension, though
 (ATI_texture_mirror_once). (I think the dx mirror once definition is
 probably mirror_clamp_to_edge in opengl parlance).
 
 That's possible. As mentioned I'm not really sure what to do with this 
 feature.
 
 - shadow maps - it's more of an researched guess since it's largely
 based on a format support, but as far as i can tell all d3d10 hardware
 supports it, earlier it varies (e.g. nvidia did it for ages)
 Required for GL 1.4. I thought it was pretty much required for d3d
 sm2.0, though you're right you could probably just not support the
 texture format there. Anyway, most hardware should support it, I believe
 even those which didn't really supported it at DX9 SM 2.0 time supported
 it (chips like radeon r300 lacked the hw to do the comparison in the
 texture unit, but it can be more or less easily implemented in the pixel
 shader, though the implementation will suck as it certainly won't do PCF
 just use some point sampling version - unless you're willing to do a
 much more complex implementation in the pixel shader, but then on this
 generation of hardware you might exceed maximum shader length). I
 believe all hardware supporting SM 2.0 could at least do some sampling
 of depth textures, though possibly only 16 bit and I'm not sure
 filtering worked in all cases.
 
 Yes, but the issue is that I'm not sure how to represent it from a feature 
 level case. Are you saying we should just enable it for all feature levels? 
 That'd be nice.
Hmm, maybe.

 
 I think the other stuff is acceptable. Take a look at the docs and let me
 know what you think.
 What is feature level 1 useful for? I thought we'd really wanted DX9
 level functionality as a bare minimum. GL2.x certainly needs cards
 supporting shader model 2 (and that is a cheat, in reality it would be
 shader model 3).
 
 The main issue was having something without hardware vs in the feature 
 levels. 
 It was supposed to be whatever the current i915 driver currently supports, 
 but 
 yea, I think it doesn't make sense and level 2 should be minumum.
 
 Also, I don't quite get the shader model levels. I thought there were
 mainly two different DX9 versions, one with sm 2.0 the other with 3.0,
 with noone caring about other differences (as most stuff was cappable
 anyway). However, you've got 3 and all of them have 2.0 shader model?
 
 As mentioned this is based on the D3D feature level concept. It's the first 
 link I put in the the references:
 http://msdn.microsoft.com/en-us/library/ee422086(VS.85).aspx#Overview
 It's there because that's what Microsoft defined as feature level and I'm 
 assuming it's because they had a good need for it :)
Ah, that's why it doesn't make much sense :-).
I'm not sure what requirements got them to these levels. I definitely
think those 3 dx9 levels are very odd and don't even make sense for d3d
only, much less for gallium. For example, requires at least max aniso
16? You got to be kidding, aniso spec is so fuzzy you can pass any cheap
point filter as compliant (well almost) anyway, so it doesn't make any
sense (plus, this only really enhances filtering quality, it makes
absolutely zero difference for writing applications).
I think the retrofit of 9_1, 9_2, 9_3 to some arbitrary DX9 versions
doesn't match hardware really neither. The most distinguishable feature
of DX9.0c (which was the last version IIRC) was definitely SM 3.0, but
of course like everything else (multiple render targets, etc.) it was
optional. I think for gallium it would make way more sense to expose
only 2 feature levels - basically drop 9_1, and additionally bump 9_3 to
include SM 3.0 (I wonder if that's not just a typo there, after all the
model is called ps_4_0_level_9_3 unlike the others which are called
9_1 only).
Though granted nv20/25 can't do separate alpha blend (but it can't do
fragment shaders neither really so I don't know how well that driver is
ever going to work), i915 may not be able to do occlusion queries (not
sure if hw can't do it but the current driver doesn't implement it),
everybody (I think) can do mirror_once, and I don't know what
overlapping vertex elements are.

 
 More comments below.

 +static const enum pipe_feature_level
 +i915_feature_level(struct pipe_screen *screen)
 +{
 +   return PIPE_FEATURE_LEVEL_1;
 +}
 What's the reason this is not feature level 2?
 
 Yea, I was winging it for all the drivers because I couldn't be bothered to 
 do 
 a

Re: [Mesa3d-dev] Plans for EGL

2010-01-12 Thread Jakob Bornecrantz

On 12 jan 2010, at 04.23, Chia-I Wu wrote:
 Hi all,

 I just pushed a new EGL driver (egl_g3d) to master.  The new driver  
 is located at src/gallium/state_trackers/egl_g3d/.  When built, it  
 provides .a archives that are later linked to by src/gallium/winsys/ 
 drm/hw/egl_g3d/ to provide the final EGL drivers loadable by libEGL.

 This new driver supports mixed client APIs (OpenGL, OpenVG, and  
 OpenGL ES).  It supports both HW/SW rendering on X11 and supports  
 EGL_MESA_screen_surface on bare KMS.  The goal of this driver is to  
 provide _the_ EGL driver for Gallium architecture.

 I am working on merging opengl-es-v2 branch.  When that is done, I  
 plan to work on preparing EGL for easy/wide adoption.  The specific  
 items I have right now are

 * Write up documentation
 * Remove unused/non-working EGL drivers
 * Remove drivers that are deprecated by egl_g3d
 * Automatic driver selection (like DRI)
 * Re-organize EGL demos

 The drivers to be removed are

 * Unused
  * src/egl/drivers/demo/
  * src/egl/drivers/xdri/

I think that at least demo should remain if for nothing more then to  
serve as a empty skeleton for anybody wishing to make their own driver.

 * Non-working
  * src/egl/drivers/dri/

Having the dri driver working would be desirable since it allows you  
to use none gallium drivers standalone.

  * src/mesa/drivers/dri/fb/fb_egl.c
  * src/mesa/drivers/dri/radeon/server/radeon_egl.c
  * src/mesa/drivers/dri/r600/server/radeon_egl.c
  * src/mesa/drivers/dri/r300/server/radeon_egl.c
  * src/mesa/drivers/dri/r200/server/radeon_egl.c
 * Deprecated by egl_g3d
  * src/gallium/state_trackers/egl/
  * src/gallium/winsys/egl_xlib/

 If anyone has any concern or is actively using any of the driver  
 listed above,
 please let me konw.  The removal, especially of those in the last  
 category, is
 still a plan, and is supposed to be several weeks away.  If anyone  
 has any
 trouble using/testing egl_g3d, please let me know too.


I'm okay with removing s/g/st/egl and moving egl_g3d to s/g/st/egl.  
Actually I'm more then okay with the move since I'm not a big fan of  
the name name egl_g3d.


 As for the re-organization, I want to move various demos using EGL to
 progs/egl/.  The directory structure will be like

 progs/egl/opengl
 progs/egl/opengles1
 progs/egl/opengles2
 progs/egl/openvg

Also progs/egl/interop once we get inter API communication working.


 There will be simple window-system glue code that the demos may  
 use.  Simple
 demos who use the glue code will be able to run on multiple window  
 systems like
 X11 and bare KMS.

 There are also plans for new features and internal cleanups.  But I  
 want to
 start with attracting new users/developers first, as EGL is almost  
 ready to
 shine.

Nice work!

Can you write down a list of what drivers that the new code produce?

Cheers Jakob.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access

2010-01-12 Thread Chia-I Wu

I will reply to the parts that I am more familiar with.

On Tue, Jan 12, 2010 at 12:23 PM, Luca Barbieri l...@luca-barbieri.com wrote:
 Regardless of my personal preference as expressed, there are some minor 
 issues
 in the EGL part of the patch.  One is that, it lifts certain restrictions
 required by EGL 1.4 by commenting out the code (e.g. in eglSwapBuffers).  It
 should check if EGL_MESA_gallium is supported and decide what to do.
 Is that restriction (the surface being swapped by eglSwapBuffers must
 be bound to the current context) actually in the spec?

 The man page at
 http://www.khronos.org/opengles/documentation/opengles1_0/html/eglSwapBuffers.html
 doesn't talk about contexts at all, and GLX doesn't have that
 restriction.

 As far as merging my patches, great, but there is some complexity
 involved, since there are various versions of them.

 First of all, the Gallium framework/programs code is now independent
 of the extensions as it contains its own main loop with DRI2 and KMS
 support, and can thus be merged now, independently of the extension
 and/or egl_g3d.
 This is quite useful for writing Gallium demos/tool in C: you call its
 init_and_render function passing a draw function pointer, and it
 calls back draw with a pipe_context and pipe_framebuffer_state you can
 use for drawing.
 Using it from Python would however require some adaptations.

 As for the extension, this is the current situation:
 1. The orginal GLX and EGL patches. There are based on egl_glx,
 egl_softpipe and the GLX/DRI stack.
 They implement a GetGalliumSurfaces call which pulls surfaces out of
 an st_framebuffer.
 This makes them somewhat invasive and is inelegant since there is a
 dependency on the state tracker.
 2. The EGL patch based on egl_g3d. This patch is much cleaner, thanks
 to egl_g3d's design, which is much better than the existing one as it
 separates the API implementation (in egl_g3d.c) from the abstraction
 of the underlying rendering system (the
 native_display/native_surface/native_config classes).
 This allows a very simple implementation of the Gallium extension.
 However, the patch I posted depends on changes to native_surface which
 I think are beneficial, but I'm not sure if Chia-I Wu likes.
The sequence number change?  I think we can work it out soon in the other
thread.
 Note that this actually changes the extension interface, which now has
 a GetGalliumTextures function instead of GetGalliumSurfaces, that
 mimics Chia-I Wu's design of native_surface-validate, which I believe
 is superior to my initial interface design.
I am ok with EGL_MESA_gallium you proposed.  My proposal is also easy to
implement, but since I am not working on it, I don't want to hinder your work
(which is promising!).  Regarding the patches, I would like to see

* the extension be compile time (#ifdef EGL_MESA_gallium) or runtime
  checked (dpy-Extensions.MESA_gallium)
* all new types are prefixed by EGL and suffixed by Mesa.  E.g.,
  EGLg3dContextMesa.

The naming rule is according to
http://www.khronos.org/registry/gles/extensions/OES/OES_EGL_image.txt
 3. A new GLX implementation based on the egl_g3d native core,
 including a GLX_MESA
 I sent a preview of this to Chia-I Wu and have since made it work with
 all applications except single-buffered ones (due to egl_g3d dropping
 single-buffered visuals: this should be asily fixable), including
 compiz.
 I'll post a patch to the list soon with the code.
 Using this means however replacing (in actual use, not in the
 repository, of course) all the GLX/DRI stack with a new Gallium-only
 GLX implementation.
My suggestion for this is still
http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg10541.html

I don't think egl_g3d can replace the stock libGL because, at least, it lacks
indirect rendering.  Longer term, you might consider revive the Xegl project.
 Thus, of all the code involved, my new Gallium programs code and
 Chia-I Wu's egl_g3d can be merged now, as they have no dependencies
 and don't affect the existing code.

 As for the extensions, they somewhat depend on whether we decide to go
 with egl_g3d or not.
 If egl_g3d becomes the default EGL and GLX layer for Gallium drivers,
 then the egl_g3d versions of the extensions and the overall codebase
 are much cleaner.
 Otherwise, it's easy to add glXGetGalliumScreen and
 glXCreateGalliumContext on top of the existing code but getting
 surfaces/textures is a bit more ugly. Also, it may be a good idea to
 update the old patches to expose the new glXGetGalliumTextures with
 user-specified attachments rather than the old and uglier
 GetGaliumSurfaces interface.

 What do you think?


--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to

Re: [Mesa3d-dev] Gallium feature levels

2010-01-12 Thread Younes Manton

On Tue, Jan 12, 2010 at 9:44 AM, Keith Whitwell kei...@vmware.com wrote:
 On Tue, 2010-01-12 at 06:33 -0800, Roland Scheidegger wrote:
 
  Profile 7 (2009)6 (2008)
 5
  (2006)4 (2004)3 (2003)2 (2002) 1
 (2000)
  Fragment Shader Yes Yes
 Yes
Yes Yes Yes  Yes
  DX 7 didn't have any shader model IIRC. DX8/8.1 introduced shader
 models
  1.0-1.3/1.4.
 
  Yea, that level should be gone.
 Though thinking about this, maybe we should keep a level below lowest
 dx9 feature level, since gallium drivers exist which are pretty low on
 the feature scale (like the nv04/10/20). I don't know how well they'll
 ever going to work, since they'd need the fixed function fragment
 operations out of tgsi, but maybe we shouldn't prevent it by forcing
 them to announce support of fragment shaders.

 The base level of gallium functionality included fragment shaders from
 the start, these early nv drivers don't really change that.

 In my view these are a speculative bet that with a lot of effort it is
 possible to turn shaders back into fixed-function, but supporting that
 isn't a design goal for gallium as a whole.

 Keith

Just my opinion,

I wouldn't count on nv04-nv20 actually staying in gallium. At some
point we wanted to experiment with shaders on fixed func, but I don't
think anyone is really motivated or optimistic that it will turn out
well. They're already rotting as it is. Francisco Jerez is working on
a classic Mesa driver for these and if/when they're worth pushing to
master I'd expect the gallium drivers to be axed.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Plans for EGL

2010-01-12 Thread Chia-I Wu

On Tue, Jan 12, 2010 at 10:52 PM, Jakob Bornecrantz ja...@vmware.com wrote:
 On 12 jan 2010, at 04.23, Chia-I Wu wrote:
 * Write up documentation
 * Remove unused/non-working EGL drivers
 * Remove drivers that are deprecated by egl_g3d
 * Automatic driver selection (like DRI)
 * Re-organize EGL demos

 The drivers to be removed are

 * Unused
  * src/egl/drivers/demo/
  * src/egl/drivers/xdri/
 I think that at least demo should remain if for nothing more then to serve
 as a empty skeleton for anybody wishing to make their own driver.
The idea is that src/egl/drivers/glx/ has already provided a simple EGL driver
that works.  The demo driver, though compiles, is outdated or may outdate over
time since it is not a working driver that can be verified.
 * Non-working
  * src/egl/drivers/dri/
 Having the dri driver working would be desirable since it allows you to use
 none gallium drivers standalone.
The only problem with the dri driver is that no one is maintaining it.  I agree
that there might still interests in loading DRI drivers from EGL drivers.  I
wrote one for Android.

How about we keep the xdri driver and leave dri driver in the git history?  The
xdri driver

* dlopen()s DRI1/DRI2 drivers
* talks with the X server using DRI1/DRI2 (the protocol) to implement
  functions like getBuffersWithFormat
* works well

The first point is the key idea shared by both dri and xdri drivers.
  * src/mesa/drivers/dri/fb/fb_egl.c
  * src/mesa/drivers/dri/radeon/server/radeon_egl.c
  * src/mesa/drivers/dri/r600/server/radeon_egl.c
  * src/mesa/drivers/dri/r300/server/radeon_egl.c
  * src/mesa/drivers/dri/r200/server/radeon_egl.c
 * Deprecated by egl_g3d
  * src/gallium/state_trackers/egl/
  * src/gallium/winsys/egl_xlib/

 If anyone has any concern or is actively using any of the driver listed
 above,
 please let me konw.  The removal, especially of those in the last
 category, is
 still a plan, and is supposed to be several weeks away.  If anyone has any
 trouble using/testing egl_g3d, please let me know too.
 I'm okay with removing s/g/st/egl and moving egl_g3d to s/g/st/egl. Actually
 I'm more then okay with the move since I'm not a big fan of the name name
 egl_g3d.
Thanks.  I will do the rename after the removal :P

 As for the re-organization, I want to move various demos using EGL to
 progs/egl/.  The directory structure will be like

 progs/egl/opengl
 progs/egl/opengles1
 progs/egl/opengles2
 progs/egl/openvg
 Also progs/egl/interop once we get inter API communication working.
Yes.  Actually, inter API communication should be working with egl_g3d.  It
just lacks demos.

 There will be simple window-system glue code that the demos may use.
  Simple
 demos who use the glue code will be able to run on multiple window systems
 like
 X11 and bare KMS.

 There are also plans for new features and internal cleanups.  But I want
 to
 start with attracting new users/developers first, as EGL is almost ready
 to
 shine.
 Nice work!
 Can you write down a list of what drivers that the new code produce?
When configured with --egl-native-displays=x11,kms, egl_g3d will give
libeglx11.a and libeglkms.a.  They are used by winsys/drm/ to give

  egl_x11_i965.so
  egl_x11_i915.so
  egl_x11_nouveau.so
  egl_x11_r300.so
  egl_x11_vmwgfx.so
  egl_kms_i965.so
  egl_kms_i915.so
  egl_kms_nouveau.so
  egl_kms_r300.so
  egl_kms_vmwgfx.so

I only tested the i915 ones.  Luca reported success with nouveau ones.  The
others are only compile tested.  Automatic driver selection is also part of the
plan.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [RFC] instanced-arrays branch

2010-01-12 Thread michal

Keith,

I would like to merge this branch to master soon.

It adds new entrypoints to pipe_context -- draw_arrays_instanced() and 
draw_elements_instanced(). A new system value is introduced to TGSI that 
allows vertex shaders to access current instance ID.

The new entrypoints are implemented in draw module, and softpipe driver 
has been properly adjusted for that.

There is no capability bit defined for that -- I wasn't sure whether we 
still want to go this route.

Please review, thanks.



--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [git] Support for new DRI2 protocol

2010-01-12 Thread Jesse Barnes

On Fri, 8 Jan 2010 12:00:47 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:

 DRI2 now has support for swapbuffers, OML_sync_control and events.
 There's a git tree at git://people.freedesktop.org/~jbarnes/mesa with
 support for the new requests that I'd like to push into Mesa master.
 
 Can people take a look at make sure I don't have anything horribly
 wrong?  I've tested it against both old and new X servers (that is,
 servers with and w/o support for the new requests) and things seem
 solid, so I think it's ready to go.
 
 Building does require current dri2proto bits (all of which are in
 dri2proto master); I should probably spin a release of that just to
 make things easy.

I pushed into master after Jakob and Kristian had a look yesterday.

I had to push a small fix afterward: mesa's autoconf wasn't checking
for the glproto version, but now that we require 1.4.11 to build I
added a check for it.  The pull also included a check for dri2proto
2.2, which is required as well.

-- 
Jesse Barnes, Intel Open Source Technology Center

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH] New GLX API implementation for Gallium over egl_g3d

2010-01-12 Thread Luca Barbieri

As far as end user benefits, currently there is the ability to
switch between the DRM Gallium driver and softpipe with an environment
variable (the DRI stack has a similar feature, but with swrast), and a
reduction of X server usage/roundtrips as it doesn't make any GLX
calls except for initialization.

On the developer side, it's a cleaner and simpler design than the
existing DRI stack for the case of Gallium drivers, and can replace
state_trackers/glx/xlib.
It also serves as a second user, other than EGL, for egl_g3d's display
abstraction.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access

2010-01-12 Thread Luca Barbieri

 Using this means however replacing (in actual use, not in the
 repository, of course) all the GLX/DRI stack with a new Gallium-only
 GLX implementation.
 My suggestion for this is still
 http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg10541.html

 I don't think egl_g3d can replace the stock libGL because, at least, it lacks
 indirect rendering.  Longer term, you might consider revive the Xegl project.

This can be solved by making libGL load a GLX driver.
One of them would be egl_g3d, and another the existing code for
indirect rendering and legacy DRI.
Or possibly some newly written XCB-based indirect rendering GLX
driver, if anyone wants to do that.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Plans for EGL

2010-01-12 Thread Jakob Bornecrantz

On 12 jan 2010, at 16.16, Chia-I Wu wrote:
 On Tue, Jan 12, 2010 at 10:52 PM, Jakob Bornecrantz  
 ja...@vmware.com wrote:
 On 12 jan 2010, at 04.23, Chia-I Wu wrote:
 * Write up documentation
 * Remove unused/non-working EGL drivers
 * Remove drivers that are deprecated by egl_g3d
 * Automatic driver selection (like DRI)
 * Re-organize EGL demos

 The drivers to be removed are

 * Unused
  * src/egl/drivers/demo/
  * src/egl/drivers/xdri/
 I think that at least demo should remain if for nothing more then  
 to serve
 as a empty skeleton for anybody wishing to make their own driver.
 The idea is that src/egl/drivers/glx/ has already provided a simple  
 EGL driver
 that works.  The demo driver, though compiles, is outdated or may  
 outdate over
 time since it is not a working driver that can be verified.

Hmm, maybe you are right. But it doesn't cost anything to keep it  
around.

 * Non-working
  * src/egl/drivers/dri/
 Having the dri driver working would be desirable since it allows  
 you to use
 none gallium drivers standalone.
 The only problem with the dri driver is that no one is maintaining  
 it.  I agree
 that there might still interests in loading DRI drivers from EGL  
 drivers.  I
 wrote one for Android.

 How about we keep the xdri driver and leave dri driver in the git  
 history?  The
 xdri driver

 * dlopen()s DRI1/DRI2 drivers
 * talks with the X server using DRI1/DRI2 (the protocol) to implement
  functions like getBuffersWithFormat
 * works well

 The first point is the key idea shared by both dri and xdri drivers.

The xdri driver is pretty much deprecated by the glx driver as it does  
pretty much the same thing. The dri is more interesting then the xdri  
driver since it is standalone from X.

  * src/mesa/drivers/dri/fb/fb_egl.c
  * src/mesa/drivers/dri/radeon/server/radeon_egl.c
  * src/mesa/drivers/dri/r600/server/radeon_egl.c
  * src/mesa/drivers/dri/r300/server/radeon_egl.c
  * src/mesa/drivers/dri/r200/server/radeon_egl.c
 * Deprecated by egl_g3d
  * src/gallium/state_trackers/egl/
  * src/gallium/winsys/egl_xlib/

 If anyone has any concern or is actively using any of the driver  
 listed
 above,
 please let me konw.  The removal, especially of those in the last
 category, is
 still a plan, and is supposed to be several weeks away.  If anyone  
 has any
 trouble using/testing egl_g3d, please let me know too.
 I'm okay with removing s/g/st/egl and moving egl_g3d to s/g/st/egl.  
 Actually
 I'm more then okay with the move since I'm not a big fan of the  
 name name
 egl_g3d.
 Thanks.  I will do the rename after the removal :P

 As for the re-organization, I want to move various demos using EGL  
 to
 progs/egl/.  The directory structure will be like

 progs/egl/opengl
 progs/egl/opengles1
 progs/egl/opengles2
 progs/egl/openvg
 Also progs/egl/interop once we get inter API communication working.
 Yes.  Actually, inter API communication should be working with  
 egl_g3d.  It
 just lacks demos.

Ah cool, I'm looking forwards to when we get EGLImage.


 There will be simple window-system glue code that the demos may use.
  Simple
 demos who use the glue code will be able to run on multiple window  
 systems
 like
 X11 and bare KMS.

 There are also plans for new features and internal cleanups.  But  
 I want
 to
 start with attracting new users/developers first, as EGL is almost  
 ready
 to
 shine.
 Nice work!
 Can you write down a list of what drivers that the new code produce?
 When configured with --egl-native-displays=x11,kms, egl_g3d will give
 libeglx11.a and libeglkms.a.  They are used by winsys/drm/ to give

Just a nitpick --egl-native-displays should be somehow marked as being  
gallium only as the native display interface is dependent on gallium,  
also why do you have to include egl_g3d there shouldn't that just be  
common?


  egl_x11_i965.so
  egl_x11_i915.so
  egl_x11_nouveau.so
  egl_x11_r300.so
  egl_x11_vmwgfx.so
  egl_kms_i965.so
  egl_kms_i915.so
  egl_kms_nouveau.so
  egl_kms_r300.so
  egl_kms_vmwgfx.so

 I only tested the i915 ones.  Luca reported success with nouveau  
 ones.  The
 others are only compile tested.  Automatic driver selection is also  
 part of the
 plan.

Ok cool stuff.

Cheers Jakob.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Mesa (glsl-pp-rework-2): scons: Get GLSL code building correctly when cross compiling.

2010-01-12 Thread José Fonseca

On Mon, 2010-01-11 at 15:28 -0800, Stephan Raue wrote:
 Hi all,
 
 Am 10.12.2009 17:36, schrieb José Fonseca:
  On Thu, 2009-12-10 at 08:31 -0800, Jose Fonseca wrote:
 
  Module: Mesa
  Branch: glsl-pp-rework-2
  Commit: 491f384c3958067e6c4c994041f5d8d413b806bc
  URL:
  http://cgit.freedesktop.org/mesa/mesa/commit/?id=491f384c3958067e6c4c994041f5d8d413b806bc
 
  Author: José Fonsecajfons...@vmware.com
  Date:   Thu Dec 10 16:29:04 2009 +
 
  scons: Get GLSL code building correctly when cross compiling.
 
  This is quite messy. GLSL code has to be built twice: one for the
  host OS, another for the target OS.
   
 
 is there also an solution for building without scons?
 
 i am get the follow when i am crosscompile for x86_64 target with i386 host:
 
 gmake[3]: Entering directory 
 `/home/stephan/projects/openelec/build.OpenELEC-intel_x64.x86_64.devel/Mesa-master-20100108/src/mesa/shader/slang/library'
 ../../../../../src/glsl/apps/compile fragment slang_common_builtin.gc 
 slang_common_builtin_gc.h
 ../../../../../src/glsl/apps/compile: 
 ../../../../../src/glsl/apps/compile: cannot execute binary file
 gmake[3]: *** [slang_common_builtin_gc.h] Error 126
 gmake[3]: Leaving directory 
 `/home/stephan/projects/openelec/build.OpenELEC-intel_x64.x86_64.devel/Mesa-master-20100108/src/mesa/shader/slang/library'
 gmake[2]: *** [glsl_builtin] Error 1
 gmake[2]: Leaving directory 
 `/home/stephan/projects/openelec/build.OpenELEC-intel_x64.x86_64.devel/Mesa-master-20100108/src/mesa'
 make[1]: *** [subdirs] Error 1
 make[1]: Leaving directory 
 `/home/stephan/projects/openelec/build.OpenELEC-intel_x64.x86_64.devel/Mesa-master-20100108/src'
 make: *** [default] Error 1

Nope, and I don't think it will be easy, since Mesa's makefile system
doesn't support building stuff on a separate dir.

Jose


--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH 3/4] [egl_g3d] Revalidate based on sequence number

2010-01-12 Thread Luca Barbieri

Doesn't this make two DRI2GetBuffers protocol calls, in case of a resize?

A way to avoid this would be to have the first call update the
sequence number and store the buffer names (also destroying textures
whose names have changed), and the second call actually creating
textures for these names.

The cleanest way seems to me to split validate into an update part
(with only a sequence number and dimensions output)s and a get
textures part (with only a textures output). Or alternatively taking
the sequence number as input as I did.

Something like:
dri2_surface_update(struct native_surface *nsurf,
  const enum native_attachment *natts,
  unsigned num_natts,
 unsigned int *seq_num,
  int *width, int *height);

dri2_surface_get_textures(struct native_surface *nsurf,
  const enum native_attachment *natts,
  unsigned num_natts, struct pipe_texture
**textures);

The alternative is to have validate not call DRI2GetBuffers if
textures is not null or when given an additional flag, but that seems
more hacky.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Mesa (glsl-pp-rework-2): scons: Get GLSL code building correctly when cross compiling.

2010-01-12 Thread michal

José Fonseca wrote on 2010-01-12 19:51:
 On Mon, 2010-01-11 at 15:28 -0800, Stephan Raue wrote:
   
 Hi all,

 Am 10.12.2009 17:36, schrieb José Fonseca:
 
 On Thu, 2009-12-10 at 08:31 -0800, Jose Fonseca wrote:

   
 Module: Mesa
 Branch: glsl-pp-rework-2
 Commit: 491f384c3958067e6c4c994041f5d8d413b806bc
 URL:
 http://cgit.freedesktop.org/mesa/mesa/commit/?id=491f384c3958067e6c4c994041f5d8d413b806bc

 Author: José Fonsecajfons...@vmware.com
 Date:   Thu Dec 10 16:29:04 2009 +

 scons: Get GLSL code building correctly when cross compiling.

 This is quite messy. GLSL code has to be built twice: one for the
 host OS, another for the target OS.
  
 

   
 is there also an solution for building without scons?

 i am get the follow when i am crosscompile for x86_64 target with i386 host:

 gmake[3]: Entering directory 
 `/home/stephan/projects/openelec/build.OpenELEC-intel_x64.x86_64.devel/Mesa-master-20100108/src/mesa/shader/slang/library'
 ../../../../../src/glsl/apps/compile fragment slang_common_builtin.gc 
 slang_common_builtin_gc.h
 ../../../../../src/glsl/apps/compile: 
 ../../../../../src/glsl/apps/compile: cannot execute binary file
 gmake[3]: *** [slang_common_builtin_gc.h] Error 126
 gmake[3]: Leaving directory 
 `/home/stephan/projects/openelec/build.OpenELEC-intel_x64.x86_64.devel/Mesa-master-20100108/src/mesa/shader/slang/library'
 gmake[2]: *** [glsl_builtin] Error 1
 gmake[2]: Leaving directory 
 `/home/stephan/projects/openelec/build.OpenELEC-intel_x64.x86_64.devel/Mesa-master-20100108/src/mesa'
 make[1]: *** [subdirs] Error 1
 make[1]: Leaving directory 
 `/home/stephan/projects/openelec/build.OpenELEC-intel_x64.x86_64.devel/Mesa-master-20100108/src'
 make: *** [default] Error 1
 

 Nope, and I don't think it will be easy, since Mesa's makefile system
 doesn't support building stuff on a separate dir.

   
Yes, and that's a good reason to go back to how it was before -- 
regenerating the files and checking them in by a developer that made a 
change to input files.

I will do the necessary changes.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Build failure of Mesa 7.7 with SCons on Windows

2010-01-12 Thread José Fonseca

Hi,

I never tried to build with MinGW on windows. Only with cross
compilation.

MSVC linker works around limitations in the command line length by using
tempfiles.

gnu ld also allows to do the same. So it should be a matter of enabling
doing the same trick in SCons/Tool/mingw.py that is done in
SCons/Tool/mslink.py, like:

  env['LINKCOM'] = '${TEMPFILE($LINK $LINKFLAGS /OUT:$TARGET.windows 
$_LIBDIRFLAGS $_LIBFLAGS $_PDB $SOURCES.windows)}'

It's kind of an advanced thing to do. I'd like to help you but I'm quite
busy so it will take a while until I get back to you.

Alternatively, if you're confortable with linux, cross compiling to
MinGW on linux works perfectly well.

Jose

On Sun, 2010-01-10 at 09:32 -0800, Sir Gallantmon wrote:
 Hello,
 
 
 I was trying to build Mesa 7.7 with SCons on Windows using TDM-GCC
 MinGW 4.4.1-tdm-2 with the following output:
 
 
 C:\projects\mesa_7_7scons platform=windows machine=x86
 statetrackers=mesa drivers=softpipe,trace winsys=gdi
 scons: Reading SConscript files ...
 scons: done reading SConscript files.
 scons: Building targets ...
   Compiling src\gallium\auxiliary\cso_cache\cso_cache.c ...
   Compiling src\gallium\auxiliary\cso_cache\cso_context.c ...
   Compiling src\gallium\auxiliary\cso_cache\cso_hash.c ...
   Compiling src\gallium\auxiliary\draw\draw_context.c ...
   Compiling src\gallium\auxiliary\draw\draw_pipe.c ...
   Compiling src\gallium\auxiliary\draw\draw_pipe_aaline.c ...
   Compiling src\gallium\auxiliary\draw\draw_pipe_aapoint.c ...
   Archiving build\windows-x86\gallium\auxiliary\cso_cache
 \libcso_cache.a ...
   Compiling src\gallium\auxiliary\draw\draw_pipe_clip.c ...
   Indexing build\windows-x86\gallium\auxiliary\cso_cache
 \libcso_cache.a ...
   Compiling src\gallium\auxiliary\draw\draw_pipe_cull.c ...
   Compiling src\gallium\auxiliary\draw\draw_pipe_flatshade.c ...
   Compiling src\gallium\auxiliary\draw\draw_pipe_offset.c ...
   Compiling src\gallium\auxiliary\draw\draw_pipe_pstipple.c ...
   Compiling src\gallium\auxiliary\draw\draw_pipe_stipple.c ...
   Compiling src\gallium\auxiliary\draw\draw_pipe_twoside.c ...
   Compiling src\gallium\auxiliary\draw\draw_pipe_unfilled.c ...
   Compiling src\gallium\auxiliary\draw\draw_pipe_util.c ...
   Compiling src\gallium\auxiliary\draw\draw_pipe_validate.c ...
   Compiling src\gallium\auxiliary\draw\draw_pipe_vbuf.c ...
   Compiling src\gallium\auxiliary\draw\draw_pipe_wide_line.c ...
   Compiling src\gallium\auxiliary\draw\draw_pipe_wide_point.c ...
   Compiling src\gallium\auxiliary\draw\draw_pt.c ...
   Compiling src\gallium\auxiliary\draw\draw_pt_elts.c ...
   Compiling src\gallium\auxiliary\draw\draw_pt_emit.c ...
   Compiling src\gallium\auxiliary\draw\draw_pt_fetch.c ...
   Compiling src\gallium\auxiliary\draw\draw_pt_fetch_emit.c ...
   Compiling src\gallium\auxiliary\draw\draw_pt_fetch_shade_emit.c ...
   Compiling src\gallium\auxiliary\draw
 \draw_pt_fetch_shade_pipeline.c ...
   Compiling src\gallium\auxiliary\draw\draw_pt_post_vs.c ...
   Compiling src\gallium\auxiliary\draw\draw_pt_util.c ...
   Compiling src\gallium\auxiliary\draw\draw_pt_varray.c ...
   Compiling src\gallium\auxiliary\draw\draw_pt_vcache.c ...
   Compiling src\gallium\auxiliary\draw\draw_vertex.c ...
   Compiling src\gallium\auxiliary\draw\draw_vs.c ...
   Compiling src\gallium\auxiliary\draw\draw_vs_aos.c ...
   Compiling src\gallium\auxiliary\draw\draw_vs_aos_io.c ...
   Compiling src\gallium\auxiliary\draw\draw_vs_aos_machine.c ...
   Compiling src\gallium\auxiliary\draw\draw_vs_exec.c ...
   Compiling src\gallium\auxiliary\draw\draw_vs_llvm.c ...
   Compiling src\gallium\auxiliary\draw\draw_vs_ppc.c ...
   Compiling src\gallium\auxiliary\draw\draw_vs_sse.c ...
   Compiling src\gallium\auxiliary\draw\draw_vs_varient.c ...
 C:\Python26_w32\Scripts\..\python.exe src\gallium\auxiliary\indices
 \u_indices_gen.py  build\windows-x86\gallium\auxilia
 ry\indices\u_indices_gen.c
   Compiling build\windows-x86\gallium\auxiliary\indices
 \u_indices_gen.c ...
 C:\Python26_w32\Scripts\..\python.exe src\gallium\auxiliary\indices
 \u_unfilled_gen.py  build\windows-x86\gallium\auxili
 ary\indices\u_unfilled_gen.c
   Compiling src\gallium\auxiliary\pipebuffer\pb_buffer_fenced.c ...
   Compiling build\windows-x86\gallium\auxiliary\indices
 \u_unfilled_gen.c ...
   Archiving build\windows-x86\gallium\auxiliary\draw\libdraw.a ...
   Indexing build\windows-x86\gallium\auxiliary\draw\libdraw.a ...
   Compiling src\gallium\auxiliary\pipebuffer\pb_buffer_malloc.c ...
   Compiling src\gallium\auxiliary\pipebuffer\pb_bufmgr_alt.c ...
   Compiling src\gallium\auxiliary\pipebuffer\pb_bufmgr_cache.c ...
   Compiling src\gallium\auxiliary\pipebuffer\pb_bufmgr_debug.c ...
   Compiling src\gallium\auxiliary\pipebuffer\pb_bufmgr_fenced.c ...
   Compiling src\gallium\auxiliary\pipebuffer\pb_bufmgr_mm.c ...
   Compiling src\gallium\auxiliary\pipebuffer\pb_bufmgr_ondemand.c ...
   Compiling src\gallium\auxiliary\pipebuffer\pb_bufmgr_pool.c ...

Re: [Mesa3d-dev] Plans for EGL

2010-01-12 Thread Chia-I Wu

On Wed, Jan 13, 2010 at 2:46 AM, Jakob Bornecrantz ja...@vmware.com wrote:
 On 12 jan 2010, at 16.16, Chia-I Wu wrote:

 On Tue, Jan 12, 2010 at 10:52 PM, Jakob Bornecrantz ja...@vmware.com
 wrote:

 On 12 jan 2010, at 04.23, Chia-I Wu wrote:

 * Write up documentation
 * Remove unused/non-working EGL drivers
 * Remove drivers that are deprecated by egl_g3d
 * Automatic driver selection (like DRI)
 * Re-organize EGL demos

 The drivers to be removed are

 * Unused
  * src/egl/drivers/demo/
  * src/egl/drivers/xdri/

 I think that at least demo should remain if for nothing more then to
 serve
 as a empty skeleton for anybody wishing to make their own driver.

 The idea is that src/egl/drivers/glx/ has already provided a simple EGL
 driver
 that works.  The demo driver, though compiles, is outdated or may outdate
 over
 time since it is not a working driver that can be verified.
 Hmm, maybe you are right. But it doesn't cost anything to keep it around.
The demo driver does not free resources at eglTerminate.  It does not
initialize surfaces with _eglInitSurface.  There may be more, which makes it a
bad demo driver.

It may be updated, but since the driver won't run, it is hard to find if
anything is missing there.
 * Non-working
  * src/egl/drivers/dri/

 Having the dri driver working would be desirable since it allows you to
 use
 none gallium drivers standalone.

 The only problem with the dri driver is that no one is maintaining it.  I
 agree
 that there might still interests in loading DRI drivers from EGL drivers.
  I
 wrote one for Android.

 How about we keep the xdri driver and leave dri driver in the git history?
  The
 xdri driver

 * dlopen()s DRI1/DRI2 drivers
 * talks with the X server using DRI1/DRI2 (the protocol) to implement
  functions like getBuffersWithFormat
 * works well

 The first point is the key idea shared by both dri and xdri drivers.
 The xdri driver is pretty much deprecated by the glx driver as it does
 pretty much the same thing. The dri is more interesting then the xdri driver
 since it is standalone from X.
However, it lacks maintenance.  Th
  * src/mesa/drivers/dri/fb/fb_egl.c
  * src/mesa/drivers/dri/radeon/server/radeon_egl.c
  * src/mesa/drivers/dri/r600/server/radeon_egl.c
  * src/mesa/drivers/dri/r300/server/radeon_egl.c
  * src/mesa/drivers/dri/r200/server/radeon_egl.c
 * Deprecated by egl_g3d
  * src/gallium/state_trackers/egl/
  * src/gallium/winsys/egl_xlib/

 If anyone has any concern or is actively using any of the driver listed
 above,
 please let me konw.  The removal, especially of those in the last
 category, is
 still a plan, and is supposed to be several weeks away.  If anyone has
 any
 trouble using/testing egl_g3d, please let me know too.

 I'm okay with removing s/g/st/egl and moving egl_g3d to s/g/st/egl.
 Actually
 I'm more then okay with the move since I'm not a big fan of the name name
 egl_g3d.

 Thanks.  I will do the rename after the removal :P

 As for the re-organization, I want to move various demos using EGL to
 progs/egl/.  The directory structure will be like

 progs/egl/opengl
 progs/egl/opengles1
 progs/egl/opengles2
 progs/egl/openvg

 Also progs/egl/interop once we get inter API communication working.

 Yes.  Actually, inter API communication should be working with egl_g3d.
  It
 just lacks demos.

 Ah cool, I'm looking forwards to when we get EGLImage.


 There will be simple window-system glue code that the demos may use.
  Simple
 demos who use the glue code will be able to run on multiple window
 systems
 like
 X11 and bare KMS.

 There are also plans for new features and internal cleanups.  But I want
 to
 start with attracting new users/developers first, as EGL is almost ready
 to
 shine.

 Nice work!
 Can you write down a list of what drivers that the new code produce?

 When configured with --egl-native-displays=x11,kms, egl_g3d will give
 libeglx11.a and libeglkms.a.  They are used by winsys/drm/ to give

 Just a nitpick --egl-native-displays should be somehow marked as being
 gallium only as the native display interface is dependent on gallium, also
 why do you have to include egl_g3d there shouldn't that just be common?


  egl_x11_i965.so
  egl_x11_i915.so
  egl_x11_nouveau.so
  egl_x11_r300.so
  egl_x11_vmwgfx.so
  egl_kms_i965.so
  egl_kms_i915.so
  egl_kms_nouveau.so
  egl_kms_r300.so
  egl_kms_vmwgfx.so

 I only tested the i915 ones.  Luca reported success with nouveau ones.
  The
 others are only compile tested.  Automatic driver selection is also part
 of the
 plan.

 Ok cool stuff.

 Cheers Jakob.


--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev

Re: [Mesa3d-dev] [git] Support for new DRI2 protocol

2010-01-12 Thread Jesse Barnes

On Tue, 12 Jan 2010 17:37:35 -0800
Dan Nicholson dbn.li...@gmail.com wrote:

 On Tue, Jan 12, 2010 at 10:21 AM, Jesse Barnes
 jbar...@virtuousgeek.org wrote:
  On Fri, 8 Jan 2010 12:00:47 -0800
  Jesse Barnes jbar...@virtuousgeek.org wrote:
 
  DRI2 now has support for swapbuffers, OML_sync_control and events.
  There's a git tree at git://people.freedesktop.org/~jbarnes/mesa
  with support for the new requests that I'd like to push into Mesa
  master.
 
  Can people take a look at make sure I don't have anything horribly
  wrong?  I've tested it against both old and new X servers (that is,
  servers with and w/o support for the new requests) and things seem
  solid, so I think it's ready to go.
 
  Building does require current dri2proto bits (all of which are in
  dri2proto master); I should probably spin a release of that just to
  make things easy.
 
  I pushed into master after Jakob and Kristian had a look yesterday.
 
  I had to push a small fix afterward: mesa's autoconf wasn't checking
  for the glproto version, but now that we require 1.4.11 to build I
  added a check for it.  The pull also included a check for dri2proto
  2.2, which is required as well.
 
 Jesse, for the glproto check, I think it should be folded into the
 DRI2PROTO pkg-config check so that the CFLAGS get pulled in correctly
 when building. As it is, we check for the correct glproto, but don't
 actually use the returned CFLAGS anywhere. I can make the change
 later, but I don't have access to my box that's actually set up right
 now.

Oh yeah good point.  I can try to make that change too unless you beat
me to it (I won't have time until tomorrow).

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [git] Support for new DRI2 protocol

2010-01-12 Thread Dan Nicholson

On Tue, Jan 12, 2010 at 10:21 AM, Jesse Barnes jbar...@virtuousgeek.org wrote:
 On Fri, 8 Jan 2010 12:00:47 -0800
 Jesse Barnes jbar...@virtuousgeek.org wrote:

 DRI2 now has support for swapbuffers, OML_sync_control and events.
 There's a git tree at git://people.freedesktop.org/~jbarnes/mesa with
 support for the new requests that I'd like to push into Mesa master.

 Can people take a look at make sure I don't have anything horribly
 wrong?  I've tested it against both old and new X servers (that is,
 servers with and w/o support for the new requests) and things seem
 solid, so I think it's ready to go.

 Building does require current dri2proto bits (all of which are in
 dri2proto master); I should probably spin a release of that just to
 make things easy.

 I pushed into master after Jakob and Kristian had a look yesterday.

 I had to push a small fix afterward: mesa's autoconf wasn't checking
 for the glproto version, but now that we require 1.4.11 to build I
 added a check for it.  The pull also included a check for dri2proto
 2.2, which is required as well.

Jesse, for the glproto check, I think it should be folded into the
DRI2PROTO pkg-config check so that the CFLAGS get pulled in correctly
when building. As it is, we check for the correct glproto, but don't
actually use the returned CFLAGS anywhere. I can make the change
later, but I don't have access to my box that's actually set up right
now.

--
Dan

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Plans for EGL

2010-01-12 Thread Chia-I Wu

Sorry, I pressed the wrong button and sent it prematurely.

On Wed, Jan 13, 2010 at 8:41 AM, Chia-I Wu olva...@gmail.com wrote:
 On Wed, Jan 13, 2010 at 2:46 AM, Jakob Bornecrantz ja...@vmware.com wrote:
 On 12 jan 2010, at 16.16, Chia-I Wu wrote:

 On Tue, Jan 12, 2010 at 10:52 PM, Jakob Bornecrantz ja...@vmware.com
 wrote:

 On 12 jan 2010, at 04.23, Chia-I Wu wrote:

 * Write up documentation
 * Remove unused/non-working EGL drivers
 * Remove drivers that are deprecated by egl_g3d
 * Automatic driver selection (like DRI)
 * Re-organize EGL demos

 The drivers to be removed are

 * Unused
  * src/egl/drivers/demo/
  * src/egl/drivers/xdri/

 I think that at least demo should remain if for nothing more then to
 serve
 as a empty skeleton for anybody wishing to make their own driver.

 The idea is that src/egl/drivers/glx/ has already provided a simple EGL
 driver
 that works.  The demo driver, though compiles, is outdated or may outdate
 over
 time since it is not a working driver that can be verified.
 Hmm, maybe you are right. But it doesn't cost anything to keep it around.
 The demo driver does not free resources at eglTerminate.  It does not
 initialize surfaces with _eglInitSurface.  There may be more, which makes it a
 bad demo driver.

 It may be updated, but since the driver won't run, it is hard to find if
 anything is missing there.
 * Non-working
  * src/egl/drivers/dri/

 Having the dri driver working would be desirable since it allows you to
 use
 none gallium drivers standalone.

 The only problem with the dri driver is that no one is maintaining it.  I
 agree
 that there might still interests in loading DRI drivers from EGL drivers.
  I
 wrote one for Android.

 How about we keep the xdri driver and leave dri driver in the git history?
  The
 xdri driver

 * dlopen()s DRI1/DRI2 drivers
 * talks with the X server using DRI1/DRI2 (the protocol) to implement
  functions like getBuffersWithFormat
 * works well

 The first point is the key idea shared by both dri and xdri drivers.
 The xdri driver is pretty much deprecated by the glx driver as it does
 pretty much the same thing. The dri is more interesting then the xdri driver
 since it is standalone from X.
 However, it lacks maintenance.  Th
I tried to fix it once, but I gave up soon.  Because the fix to it is not
trivial and even if that is done, the egl dri driver supports only DRI1, which
is fading out.  egl_xdri is doing what egl_glx is doing, but in an interesting
and different way.  With direct access to DRI drivers, it is capable of doing
what egl_glx can't (e.g. eglBindTexImage requires pbuffer but
GLX_EXT_texture_from_pixmap supports only pixmaps).

My concern with keeping these drivers is that, when I first came to EGL in
Mesa, there were 4 drivers under egl/drivers/.  Three of them did not work, and
two of them even didn't compile.  It confused me.

There are two EGL implementations I know of that load DRI(2) drivers and
support non-X window system.  One is egl_android.  The other is libeagle for
Wayland.  egl_android works great but it uses a different build system
(Android.mk).  libeagle is a standalone library, but it is more promising.  I
do have some interests in porting it to egl_eagle and have Wayland use standard
libEGL, but I haven't found the time.

It would be great if someone is willing to help port libeagle.  Otherwise, I
prefer egl_xdri over egl_dri, or removing both.  What do you think?
  * src/mesa/drivers/dri/fb/fb_egl.c
  * src/mesa/drivers/dri/radeon/server/radeon_egl.c
  * src/mesa/drivers/dri/r600/server/radeon_egl.c
  * src/mesa/drivers/dri/r300/server/radeon_egl.c
  * src/mesa/drivers/dri/r200/server/radeon_egl.c
 * Deprecated by egl_g3d
  * src/gallium/state_trackers/egl/
  * src/gallium/winsys/egl_xlib/

 If anyone has any concern or is actively using any of the driver listed
 above,
 please let me konw.  The removal, especially of those in the last
 category, is
 still a plan, and is supposed to be several weeks away.  If anyone has
 any
 trouble using/testing egl_g3d, please let me know too.

 I'm okay with removing s/g/st/egl and moving egl_g3d to s/g/st/egl.
 Actually
 I'm more then okay with the move since I'm not a big fan of the name name
 egl_g3d.

 Thanks.  I will do the rename after the removal :P

 As for the re-organization, I want to move various demos using EGL to
 progs/egl/.  The directory structure will be like

 progs/egl/opengl
 progs/egl/opengles1
 progs/egl/opengles2
 progs/egl/openvg

 Also progs/egl/interop once we get inter API communication working.

 Yes.  Actually, inter API communication should be working with egl_g3d.
  It
 just lacks demos.

 Ah cool, I'm looking forwards to when we get EGLImage.
There is working EGLImage support in egl_android, which uses DRI.  st_public.h
is not enough to support EGLImage and its family.  I plan to add it to egl_g3d
after reworking st_public.h.


 There will be simple window-system glue code that the demos may use.
  Simple
 demos who use

Re: [Mesa3d-dev] [PATCH 3/4] [egl_g3d] Revalidate based on sequence number

2010-01-12 Thread Chia-I Wu

On Wed, Jan 13, 2010 at 2:52 AM, Luca Barbieri l...@luca-barbieri.com wrote:
 Doesn't this make two DRI2GetBuffers protocol calls, in case of a resize?
I expect resizing happens rarely.

Plus, I want to hook winsys-update_buffer.  It is called when the user calls
glViewport.  It will set force_validate and avoid the first call.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH 1/4] [egl_g3d] DRI2 support for depth/stencil and right buffers

2010-01-12 Thread Chia-I Wu

On Tue, Jan 12, 2010 at 7:31 PM, Keith Whitwell kei...@vmware.com wrote:
 On Mon, 2010-01-11 at 22:30 -0800, Luca Barbieri wrote:
  I left out depth/stencil attachment because I could not think of a good 
  reason
  for it.  Do you have an example that it is better to ask the display 
  server for
  a depth/stencil buffer than asking the pipe driver?
 I'm not sure about this. I mostly added it just because the old driver
 stack asks DRI2 for it.
 On second thought, it may be better to do it with the pipe driver.
 This would prevent sharing the depth buffer with other application,
 but I don't think any compositor/application uses this.
 Theoretically an application could create a direct and indirect context
 targetting the same window.  Under those circumstances, there should be
 only a single depth buffer shared between the contexts.
I guess I will leave out depth/stencil attachment for now.  The interface does
not imply direct or indirect rendering, but all native displays use direct
rendering right now.  It should be easy to add depth/stencil attachment if
there is a new native display that needs it.  (Actually, in my early work,
there was a depth/stencil attachment.  It was removed and there is a comment
saying that only color attachments are included intentionally.)
 There are other ways to achieve the same result, basically sharing a
 depth buffer between processes.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Gallium feature levels

2010-01-12 Thread Ben Skeggs

On Tue, 2010-01-12 at 11:01 -0500, Younes Manton wrote:
 On Tue, Jan 12, 2010 at 9:44 AM, Keith Whitwell kei...@vmware.com wrote:
  On Tue, 2010-01-12 at 06:33 -0800, Roland Scheidegger wrote:
  
   Profile 7 (2009)6 (2008)
  5
   (2006)4 (2004)3 (2003)2 (2002) 1
  (2000)
   Fragment Shader Yes Yes
  Yes
 Yes Yes Yes  Yes
   DX 7 didn't have any shader model IIRC. DX8/8.1 introduced shader
  models
   1.0-1.3/1.4.
  
   Yea, that level should be gone.
  Though thinking about this, maybe we should keep a level below lowest
  dx9 feature level, since gallium drivers exist which are pretty low on
  the feature scale (like the nv04/10/20). I don't know how well they'll
  ever going to work, since they'd need the fixed function fragment
  operations out of tgsi, but maybe we shouldn't prevent it by forcing
  them to announce support of fragment shaders.
 
  The base level of gallium functionality included fragment shaders from
  the start, these early nv drivers don't really change that.
 
  In my view these are a speculative bet that with a lot of effort it is
  possible to turn shaders back into fixed-function, but supporting that
  isn't a design goal for gallium as a whole.
 
  Keith
 
 Just my opinion,
 
 I wouldn't count on nv04-nv20 actually staying in gallium. At some
 point we wanted to experiment with shaders on fixed func, but I don't
 think anyone is really motivated or optimistic that it will turn out
 well. They're already rotting as it is. Francisco Jerez is working on
 a classic Mesa driver for these and if/when they're worth pushing to
 master I'd expect the gallium drivers to be axed.
Agreed.  IMO they could be removed now, I don't see them ever being
done, and Francisco's drivers are shaping up quite nicely already.

Ben.
 
 --
 This SF.Net email is sponsored by the Verizon Developer Community
 Take advantage of Verizon's best-in-class app development support
 A streamlined, 14 day to market process makes app distribution fast and easy
 Join now and get one step closer to millions of Verizon customers
 http://p.sf.net/sfu/verizon-dev2dev 
 ___
 Mesa3d-dev mailing list
 Mesa3d-dev@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mesa3d-dev



--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH 3/4] [egl_g3d] Revalidate based on sequence number

Re: [Mesa3d-dev] Plans for EGL

[Mesa3d-dev] [PATH] Add double opcodes to TGSI Revision 2

Re: [Mesa3d-dev] [PATH] Add double opcodes to TGSI Revision 2

[Mesa3d-dev] [Bug 26003] New: incorrect rendering in celestia; unsupported opcode 13

[Mesa3d-dev] [Bug 26003] incorrect rendering in celestia; unsupported opcode 13

[Mesa3d-dev] [Bug 26003] incorrect rendering in celestia; unsupported opcode 13

[Mesa3d-dev] [Bug 26003] incorrect rendering in celestia; unsupported opcode 13

[Mesa3d-dev] [Bug 26003] incorrect rendering in celestia; unsupported opcode 13

[Mesa3d-dev] [Bug 26003] incorrect rendering in celestia; unsupported opcode 13

Re: [Mesa3d-dev] Gallium feature levels

Re: [Mesa3d-dev] Plans for EGL

Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access

Re: [Mesa3d-dev] Gallium feature levels

Re: [Mesa3d-dev] Plans for EGL

[Mesa3d-dev] [RFC] instanced-arrays branch

Re: [Mesa3d-dev] [git] Support for new DRI2 protocol

Re: [Mesa3d-dev] [PATCH] New GLX API implementation for Gallium over egl_g3d

Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access

Re: [Mesa3d-dev] Plans for EGL

Re: [Mesa3d-dev] Mesa (glsl-pp-rework-2): scons: Get GLSL code building correctly when cross compiling.

Re: [Mesa3d-dev] [PATCH 3/4] [egl_g3d] Revalidate based on sequence number

Re: [Mesa3d-dev] Mesa (glsl-pp-rework-2): scons: Get GLSL code building correctly when cross compiling.

Re: [Mesa3d-dev] Build failure of Mesa 7.7 with SCons on Windows

Re: [Mesa3d-dev] Plans for EGL

Re: [Mesa3d-dev] [git] Support for new DRI2 protocol

Re: [Mesa3d-dev] [git] Support for new DRI2 protocol

Re: [Mesa3d-dev] Plans for EGL

Re: [Mesa3d-dev] [PATCH 3/4] [egl_g3d] Revalidate based on sequence number

Re: [Mesa3d-dev] [PATCH 1/4] [egl_g3d] DRI2 support for depth/stencil and right buffers

Re: [Mesa3d-dev] Gallium feature levels

31 matches

Site Navigation

Mail list logo

Footer information