[Mesa-dev] Mesa demos release & version number

2010-06-18 Thread Jerome Glisse
Hi,

Some distribution (like Fedora) are thinking about making
new package for mesa demos but so far there is no release
for it.

Another issue is the versioning of mesa demos, i expect
that mesa demos will be more stable than mesa thus i don't
think we should follow mesa versioning but let it have
it's own versioning (should we start with version 1.0 ?)

If we can agree on versioning i can try to see if my kung-fu
is good enough to do a release of mesa demo :)

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


[Mesa-dev] [PATCH] Introduce platform displays internally

2010-06-18 Thread Chia-I Wu
Hi Krisitian,

While working on the multiple EGL libraries idea, it turns out there is one
internal change that is beneficial for all approaches on the table.  You can
find the change as a patch in the attachment.

The patch is basically a rewrite of the internal change you did for
EGL_MESA_typed_display.  It introduces a new notion: platform displays.  A
platform display is exactly a typed display in EGL_MESA_typed_display, except
that it is entirely internal.  In the patch, a driver is updated to always deal
with a platform display.  A native display, whose type is EGLNativeDisplayType,
is now treated as a platform display whose platform is determined at compile
time.  When eglCreateWindowSurface is called with a non-native platform
display, EGL_NO_SURFACE is returned and EGL_BAD_NATIVE_WINDOW is set.

The patch does not add any new public functions or tokens to specify a
non-native platform display.  However, it makes EGL ready to support
EGL_MESA_typed_display or the more specific eglGetDRMDisplay.  It also allows
me to support multiple EGL libraries without going into Makefile hell.  As a
result, I've created two branches

  http://cgit.freedesktop.org/~olv/mesa/log/?h=egl-drm-display
  (for eglGetDRMDisplay)

  http://cgit.freedesktop.org/~olv/mesa/log/?h=multi-egl
  (for multiple EGL libraries)

The interesting commit in multi-egl branch is the last one

  "egl: Build one library for each platform."

It installs multiple libEGL.so's and .pc files.  The .pc files for non-X11
platform defines macros so that apps pick the correct platform (correct native
types, no Xlib headers) from eglplatform.h.

Both approaches look fine to me.  I seriously do not have a preference here.
But I would like to know if it is fine to land the patch first, or to rebase
your work on it.  The patch allows me to do some cleanups to st/egl.  What do
you think?

-- 
o...@lunarg.com
From 312d1d2526174277f1cd937b3d1a65d7329557eb Mon Sep 17 00:00:00 2001
From: Chia-I Wu 
Date: Thu, 17 Jun 2010 17:14:03 +0800
Subject: [PATCH 1/3] egl: Introduce platform displays internally.

This commit introduces type-safe platform displays internally.  A
platform display consists of a generic pointer and an enum that
specifies the platform.

An EGLDisplay is created from a platform display.  Native displays
become platform displays whose platform is determined by
_eglGetNativePlatform().  Platform windows and pixmaps may also be
introduced if needed.
---
 src/egl/drivers/dri2/egl_dri2.c|   11 +++
 src/egl/drivers/glx/egl_glx.c  |   14 +-
 src/egl/main/Makefile  |   13 +
 src/egl/main/SConscript|3 ++-
 src/egl/main/eglapi.c  |9 -
 src/egl/main/egldisplay.c  |   10 +++---
 src/egl/main/egldisplay.h  |   19 ---
 src/egl/main/egldriver.c   |   10 ++
 src/egl/main/egldriver.h   |5 +
 src/gallium/state_trackers/egl/common/egl_g3d.c|8 
 src/gallium/state_trackers/egl/common/native.h |3 +--
 .../state_trackers/egl/common/native_probe.h   |4 ++--
 .../state_trackers/egl/fbdev/native_fbdev.c|9 -
 src/gallium/state_trackers/egl/gdi/native_gdi.c|5 ++---
 src/gallium/state_trackers/egl/kms/native_kms.c|5 ++---
 src/gallium/state_trackers/egl/x11/native_dri2.c   |2 +-
 src/gallium/state_trackers/egl/x11/native_x11.c|9 -
 src/gallium/state_trackers/egl/x11/native_x11.h|4 ++--
 src/gallium/state_trackers/egl/x11/native_ximage.c |2 +-
 19 files changed, 100 insertions(+), 45 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index aa384cb..5a5e43b 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -702,15 +702,18 @@ dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp,
struct dri2_egl_display *dri2_dpy;
unsigned int api_mask;
 
+   if (disp->Platform != _EGL_PLATFORM_X11)
+  return EGL_FALSE;
+
dri2_dpy = malloc(sizeof *dri2_dpy);
if (!dri2_dpy)
   return _eglError(EGL_BAD_ALLOC, "eglInitialize");
 
disp->DriverData = (void *) dri2_dpy;
-   if (disp->NativeDisplay == NULL) {
+   if (disp->PlatformDisplay == NULL) {
   dri2_dpy->conn = xcb_connect(0, 0);
} else {
-  dri2_dpy->conn = XGetXCBConnection(disp->NativeDisplay);
+  dri2_dpy->conn = XGetXCBConnection((Display *) disp->PlatformDisplay);
}
 
if (xcb_connection_has_error(dri2_dpy->conn)) {
@@ -815,7 +818,7 @@ dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp,
  cleanup_driver:
dlclose(dri2_dpy->driver);
  cleanup_conn:
-   if (disp->NativeDisplay == NULL)
+   if (disp->PlatformDisplay == NULL)
   xcb_disconnect(dri2_dpy->conn);
  cleanup_dpy:
free(dri2_dpy);
@@ -837,7 +840,

Re: [Mesa-dev] Mesa demos release & version number

2010-06-18 Thread Dan Nicholson
On Fri, Jun 18, 2010 at 9:00 AM, Jerome Glisse  wrote:
> Hi,
>
> Some distribution (like Fedora) are thinking about making
> new package for mesa demos but so far there is no release
> for it.
>
> Another issue is the versioning of mesa demos, i expect
> that mesa demos will be more stable than mesa thus i don't
> think we should follow mesa versioning but let it have
> it's own versioning (should we start with version 1.0 ?)
>
> If we can agree on versioning i can try to see if my kung-fu
> is good enough to do a release of mesa demo :)

Well, if you start with the current mesa version, distro demo packages
won't have to bump their epochs to upgrade.

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


[Mesa-dev] RFC: Hardware branching for r500

2010-06-18 Thread Tom Stellard
Hi,

I have just pushed a branch to my git repository that enables hardware
loops and branching for r500 cards.  The branch name is r500-loops and
my git repo is git://anongit.freedesktop.org/~tstellar/mesa

The subject pretty much sums up all the changes in this branch, but I
will say I decided not to use the LOOP and ENDLOOP hw instructions for
loops, and instead I implemented them using JUMP instructions.  I did
this because it is not clear to me how the LOOP and ENDLOOP instructions
are supposed to behave, and I could never get them to do what I wanted.
The JUMP instruction seems to work fine, but I won't rule out using LOOP
and ENDLOOP some time in the future.

If you're interested, take a look and test it out.  Comments are always
appreciated.

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