date:20100126

Re: [Mesa3d-dev] mesa_7_7_branch - master merges

2010-01-26 Thread Michel Dänzer

On Mon, 2010-01-25 at 18:14 +, José Fonseca wrote: 
 
 But automated infrastructures aside, my worry with reviewing merges is
 the actual constraints that git has. For example, let's suppose the
 following scenario:
 
 1) Developer A merges a stable branch into master.
 2) After spending a bunch of time fixing conflicts the best he can, he
 emails the patch to mesa3d-dev for peer review.
 3) Developer B checks in a change into master.
 4) Developer A takes feedback from list, updates the code, and commits.
 5) Developer A cannot push because remote head has moved.
 
 So what can Developer A do now?
 
 a) Redo the merge, using the new master head.

FWIW, having rerere.enabled set in the Git configuration (see the
git-rerere manpage) should help somewhat with this - at least Developer
A shouldn't need to resolve the same conflicts over and over again.

 b) Rebase the merge on top of the new head (I'm not sure it works, or
 that it preserves branch history)

Probably not, IME merge commits lose their merge characteristics on
modification.

 c) Double merge, i.e., merge its local head with the new master head.

Which would be mostly a cosmetic problem for the revision history?

 Note that this problem is not specific to reviews -- pushing merges can
 always lead to this same situation --, but reviews of merges increase
 the probability of this problem from unlikely to guaranteed.

Agreed, seems like more trouble than it's worth.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH] hack around commas in macro argument

2010-01-26 Thread Marvin


Jose, Brian,

 Marc,
 
 Why is this necessary? It has been working fine so far. Which gcc version
  are you using? What commas are you referring to?

the PIPE_ALIGN_TYPE macro is so far only used in the cell driver in 
src/gallium/drivers/cell/spu/spu_main.c  (this is probably why no one noticed 
it).

The marco takes a type, a stuct in this case, which can include commas:

PIPE_ALIGN_TYPE(16,
struct spu_framebuffer
{
   void *color_start;  /** addr of color surface in main memory */
   void *depth_start;  /** addr of depth surface in main memory */
   enum pipe_format color_format;
   enum pipe_format depth_format;
   uint width, height; /** size in pixels */
^^^

   uint width_tiles, height_tiles; /** width and height in tiles */
  ^^^

   uint color_clear_value;
   uint depth_clear_value;

   uint zsize; /** 0, 2 or 4 bytes per Z */
   float zscale;   /** 65535.0, 2^24-1 or 2^32-1 */
});

This will cause a problem, as the macro will thread each comma as an argument 
seperator and thus the number of arguments is larger than 2.

 Variadic macros aren't portable. This change would break MSVC build.

As it is only used by cell for now, the msvc macro does not need to be changed. 
But 
there should be some portable solution.

 It seems that there is some code that's trying to pass more than 2 args to
  PIPE_ALIGN_TYPE. That sounds wrong. And making PIPE_ALIGN_TYPE take a
  variable number of args just a bandaid for a deeper problem.

I was looking for the least invasive solution and found this (I'm not a C 
coder).
The other method would be to concatenate the struct first by a second macro 
to a 
single argument, but I don't know how to do this.

I read that variadic macros are part of ISO C99, but the form I used is 
probably a 
gcc extension. Maybe

#define PIPE_ALIGN_TYPE(_alignment,
...) __VA_ARGS__ __attribute__((aligned(_alignment)))

is more portable.

Marc

 Jose
 
 
 From: Brian Paul [bri...@vmware.com]
 Sent: Tuesday, January 26, 2010 0:05
 To: Marc Dietrich
 Cc: mesa3d-dev@lists.sourceforge.net
 Subject: Re: [Mesa3d-dev] [PATCH] hack around commas in macro argument
 
 Marc Dietrich wrote:
  this is needed at least for gcc. dunno about the other compilers.
  ---
   src/gallium/include/pipe/p_compiler.h |6 +++---
   1 files changed, 3 insertions(+), 3 deletions(-)
 
  diff --git a/src/gallium/include/pipe/p_compiler.h
  b/src/gallium/include/pipe/p_compiler.h index 272d030..cdda20c 100644
  --- a/src/gallium/include/pipe/p_compiler.h
  +++ b/src/gallium/include/pipe/p_compiler.h
  @@ -144,7 +144,7 @@ typedef unsigned char boolean;
   #if defined(__GNUC__) || (defined(__SUNPRO_C)  (__SUNPRO_C = 0x590))
 
   /* See http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Type-Attributes.html
  */ -#define PIPE_ALIGN_TYPE(_alignment, _type) _type
  __attribute__((aligned(_alignment))) +#define PIPE_ALIGN_TYPE(_alignment,
  _type...) _type __attribute__((aligned(_alignment)))
 
   /* See
  http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Variable-Attributes.html */
  #define PIPE_ALIGN_VAR(_alignment) __attribute__((aligned(_alignment)))
  @@ -158,14 +158,14 @@ typedef unsigned char boolean;
   #elif defined(_MSC_VER)
 
   /* See http://msdn.microsoft.com/en-us/library/83ythb65.aspx */
  -#define PIPE_ALIGN_TYPE(_alignment, _type) __declspec(align(_alignment))
  _type +#define PIPE_ALIGN_TYPE(_alignment, _type...)
  __declspec(align(_alignment)) _type #define PIPE_ALIGN_VAR(_alignment)
  __declspec(align(_alignment))
 
   #define PIPE_ALIGN_STACK
 
   #elif defined(SWIG)
 
  -#define PIPE_ALIGN_TYPE(_alignment, _type) _type
  +#define PIPE_ALIGN_TYPE(_alignment, _type...) _type
   #define PIPE_ALIGN_VAR(_alignment)
 
   #define PIPE_ALIGN_STACK
 
 With your patch I'm seeing new warnings that I didn't get before:
 
 ../../src/gallium/include/pipe/p_compiler.h:147:42: warning: ISO C
 does not permit named variadic macros
 
 I'm using gcc 4.3.2
 
 Also, if you didn't test other compilers, the patch probably should
 not change PIPE_ALIGN_TYPE for MSVC or SWIG, right?
 
 -Brian
 
 ---
 --- The Planet: dedicated and managed hosting, cloud storage, colocation
  Stay online with enterprise data centers and the best network in the
  business Choose flexible plans and management services without long-term
  contracts Personal 24x7 support from experience hosting pros just a phone
  call away. http://p.sf.net/sfu/theplanet-com
 ___
 Mesa3d-dev mailing list
 Mesa3d-dev@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
 

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business

[Mesa3d-dev] gallium: ARB_half_float_vertex

2010-01-26 Thread Dave Airlie


Since the whole patent mess can't apply to floating vertices here are some 
gallium patches.

First adds a new screen interface for is_vertex_format_supported and also
we seems to have some GPUs with a single R16 and some with R16X16 so allow 
or this.

second is just i965g patch.

If these are okay, I can look at softpipe support via translate. Not sure 
exposing this extension always and using translate always makes sense as 
it defeats the purpose of this extension.

Dave.
From b8ea9848a61fe2469ae87bdc8ba44ea40b25b8ef Mon Sep 17 00:00:00 2001
From: Dave Airlie airl...@linux.ie
Date: Tue, 26 Jan 2010 19:12:36 +1000
Subject: [PATCH 2/2] i965g: add support for ARB_half_float_vertex

This adds the format bits to the 965g vertex emission. Untested
due to 965g appearing to smash my GPU currently.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 src/gallium/drivers/i965/brw_draw_upload.c |9 +
 src/gallium/drivers/i965/brw_screen.c  |   21 +
 2 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/src/gallium/drivers/i965/brw_draw_upload.c b/src/gallium/drivers/i965/brw_draw_upload.c
index a27da5f..4ca75e0 100644
--- a/src/gallium/drivers/i965/brw_draw_upload.c
+++ b/src/gallium/drivers/i965/brw_draw_upload.c
@@ -170,6 +170,15 @@ static unsigned brw_translate_surface_format( unsigned id )
case PIPE_FORMAT_R8G8B8A8_SSCALED:
   return BRW_SURFACEFORMAT_R8G8B8A8_SSCALED;
 
+   case PIPE_FORMAT_R16_FLOAT:
+  return BRW_SURFACEFORMAT_R16_FLOAT;
+   case PIPE_FORMAT_R16G16_FLOAT:
+  return BRW_SURFACEFORMAT_R16G16_FLOAT;
+   case PIPE_FORMAT_R16G16B16X16_FLOAT:
+  return BRW_SURFACEFORMAT_R16G16B16X16_FLOAT;
+   case PIPE_FORMAT_R16G16B16A16_FLOAT:
+  return BRW_SURFACEFORMAT_R16G16B16A16_FLOAT;
+
default:
   assert(0);
   return 0;
diff --git a/src/gallium/drivers/i965/brw_screen.c b/src/gallium/drivers/i965/brw_screen.c
index 0ecacac..d3505cb 100644
--- a/src/gallium/drivers/i965/brw_screen.c
+++ b/src/gallium/drivers/i965/brw_screen.c
@@ -203,6 +203,26 @@ brw_get_paramf(struct pipe_screen *screen, int param)
 }
 
 static boolean
+brw_is_vertex_format_supported(struct pipe_screen *screen,
+			   enum pipe_format format)
+{
+   static const GLuint pipe_format_extra[] = {
+  PIPE_FORMAT_R16_FLOAT,
+  PIPE_FORMAT_R16G16_FLOAT,
+  PIPE_FORMAT_R16G16B16X16_FLOAT,
+  PIPE_FORMAT_R16G16B16A16_FLOAT,
+  PIPE_FORMAT_NONE,
+   };
+   int i;
+
+   for (i = 0; pipe_format_extra[i] != PIPE_FORMAT_NONE; i++) {
+  if (pipe_format_extra[i] == format)
+	 return TRUE;
+   }
+   return FALSE;
+}
+
+static boolean
 brw_is_format_supported(struct pipe_screen *screen,
  enum pipe_format format, 
  enum pipe_texture_target target,
@@ -387,6 +407,7 @@ brw_create_screen(struct brw_winsys_screen *sws, uint pci_id)
bscreen-base.get_vendor = brw_get_vendor;
bscreen-base.get_param = brw_get_param;
bscreen-base.get_paramf = brw_get_paramf;
+   bscreen-base.is_vertex_format_supported = brw_is_vertex_format_supported;
bscreen-base.is_format_supported = brw_is_format_supported;
bscreen-base.fence_reference = brw_fence_reference;
bscreen-base.fence_signalled = brw_fence_signalled;
-- 
1.6.5.2

From 0b0624f0530c9825f72bf1e1af1993d2749c5ce5 Mon Sep 17 00:00:00 2001
From: Dave Airlie airl...@linux.ie
Date: Tue, 26 Jan 2010 19:10:06 +1000
Subject: [PATCH 1/2] gallium: add support for ARB_half_float_vertex

This adds a new screen interface, is_vertex_format_supported which we
used to query for the different half float vertex types, from Luca's reading
of NV30 docs it appears we need an R16X16 as well as R16.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 src/gallium/include/pipe/p_format.h|6 ++
 src/gallium/include/pipe/p_screen.h|9 +
 src/mesa/state_tracker/st_draw.c   |   14 +-
 src/mesa/state_tracker/st_draw.h   |2 ++
 src/mesa/state_tracker/st_extensions.c |   13 +
 5 files changed, 43 insertions(+), 1 deletions(-)

diff --git a/src/gallium/include/pipe/p_format.h b/src/gallium/include/pipe/p_format.h
index 6bfff1c..d3af65a 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -166,6 +166,12 @@ enum pipe_format {
PIPE_FORMAT_DXT3_SRGBA= 108,
PIPE_FORMAT_DXT5_SRGBA= 109,
 
+   /* based on DX formats + R16X16 for nv30 */
+   PIPE_FORMAT_R16_FLOAT = 110,
+   PIPE_FORMAT_R16X16_FLOAT  = 111,
+   PIPE_FORMAT_R16G16_FLOAT  = 112,
+   PIPE_FORMAT_R16G16B16X16_FLOAT= 113,
+   PIPE_FORMAT_R16G16B16A16_FLOAT= 114,
PIPE_FORMAT_COUNT
 };
 
diff --git a/src/gallium/include/pipe/p_screen.h b/src/gallium/include/pipe/p_screen.h
index b8e001a..887d527 100644
--- a/src/gallium/include/pipe/p_screen.h
+++ b/src/gallium/include/pipe/p_screen.h
@@ -87,6 +87,15 @@ struct pipe_screen {
float (*get_paramf)(

Re: [Mesa3d-dev] gallium docs

2010-01-26 Thread Uros Nedic

In fact most of my interaction with you seems based around you getting a
job from some company, this is not how you enter a community and I've felt
you've at least to me come across with all the wrong reasons for wanting
to do this.
I really do not want to waste my time on topics like this. I spent lot ofenergy
for nothing. I just would like to stress this:
* I fitted very well into OpenSolaris community* I fitted very well into
NetBeans community* I fitted very well into GNOME community
On all those three communities I contributed code on a voluntary basis.(as you
could see I do not use @company_name email but @public_email_name)Another thing
that is important for me is that I started to learn XWinSysand Gallium and
found very little documentation about that.
Only persons that wanted to help me were SUN engineers. Then I started todig
who is actually contributing something into source code base and I sawthat
majority (more than 95%!) of email are @some_company. I started tothink that
I'm only person on this world who is spending my spare time tocontribute
something without demanding anything for that. Even some personsasked me on IRC
if I work for SUN (!?). If you remember when I contacted youvia IRC I asked you
mostly how to develop radeon drivers and about overallDRI architecture. We
chatted about two hours and that was all.
After that you just did not want to spend time giving me hints. Then Irealized
that maybe the best option is to ask you for job or any othercompany. In that
case, maybe I'll receive more information since I'd workon some specific
project. Obviously, it was mistake. I'll not discuss onthis topic anymore.
All I could say - ok guys stay close and I wish you best!
Uros

To work on 3D drivers and Gallium, the main entry point I think nearly
everyone who works on the codebase shares is fixing bugs on a system they
have access to. So if you have Intel hw, trying to pick up i965g driver
and fixing the bugs in it, or similiar for radeon/nouveau with thier
gallium drivers. Most of the drivers also maintain TODO lists. Also there
are Mesa GL3.0 todo lists for gallium, I recently added
GL_ARB_half_float_vertex that was a pretty simple entry level, I haven't
done the gallium suppor tfor this yet.

Dave.

_
Windows Live: Keep your friends up to date with what you do online.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

43 matches

Mail list logo