[PATCH] nv50: fixed other void pointer arithmetic errors

scons couldn't build nv50 as it uses -Werror=pointer-arith by default.

Signed-off-by: Xavier Chantry <chantry.xavier <at> gmail.com>
---
 src/gallium/drivers/nv50/nv50_push.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/nv50/nv50_push.c b/src/gallium/drivers/nv50/nv50_push.c
index 244242b..6ebea54 100644
--- a/src/gallium/drivers/nv50/nv50_push.c
+++ b/src/gallium/drivers/nv50/nv50_push.c
 <at>  <at>  -108,7 +108,7  <at>  <at>  emit_vertex(struct push_context *ctx, unsigned n)
    int i;

    if (ctx->edgeflag_attr < 16) {
-      float *edgeflag = ctx->attr[ctx->edgeflag_attr].map +
+      float *edgeflag = (uint8_t *)ctx->attr[ctx->edgeflag_attr].map +
                         ctx->attr[ctx->edgeflag_attr].stride * n;

       if (*edgeflag != ctx->edgeflag) {
 <at>  <at>  -120,7 +120,7  <at>  <at>  emit_vertex(struct push_context *ctx, unsigned n)

    BEGIN_RING_NI(chan, tesla, NV50TCL_VERTEX_DATA, ctx->vtx_size);
    for (i = 0; i < ctx->attr_nr; i++)
-      ctx->attr[i].push(chan, ctx->attr[i].map + ctx->attr[i].stride * n);
+      ctx->attr[i].push(chan, (uint8_t *)ctx->attr[i].map + ctx->attr[i].stride * n);
 }

 static void
 <at>  <at>  -243,14 +243,14  <at>  <at>  nv50_push_elements_instanced(struct pipe_context *pipe,

Re: so the development model is working?

On Fri, 30 Apr 2010 14:59:09 +1000
Dave Airlie <airlied <at> gmail.com> wrote:

> > Jesse Barnes        4                     0  
> - some good DRI2 fixes, I'll allow Jesse to reveal his own opinions on
> getting those in.

Fixing in master and cherry picking is easier for my work flow; I don't
have a setup as sophisticated as what Brian and Keith mention, even
though I test/build on 6 or so machines regularly.

Plus I think it makes more sense; I don't like to merge changes to the
stable branch unless they've been tested a bit, since causing
regressions is so easy.  Committing to stable first increases the
chance that the stable branch will be broken regularly, imo.  It also
makes it much easier to just commit fixes as you go when developing a
new feature or doing testing, without interrupting, switching to
another directory or whatever, and potentially changing out some other
components due to feature mismatch (e.g. X server due to protocol or
interface changes).

For better or worse (based on the rest of this thread), it sounds like
stable is missing a lot of fixes and development it would otherwise
get, due to the development model we have today.

Jesse

[Bug 27841] Implement GL_EXT_discard_framebuffer

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

--- Comment #5 from Ian Romanick <idr <at> freedesktop.org> 2010-04-30 16:33:45 PDT ---
(In reply to comment #3)
> What about discarding other aux buffers (stencil, depth etc)?

GL_EXT_discard_framebuffer can already do that:

const GLenum attachments[] = { GL_COLOR_EXT, GL_DEPTH_EXT, GL_STENCIL_EXT };
glDiscardFramebufferEXT(GL_FRAMEBUFFER, attachments, 3);

It sounds like we want GL_EXT_discard_framebuffer and some other extension that
enables multiple sub-buffer copy behavior.

--

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

Re: so the development model is working?

On Fri, Apr 30, 2010 at 12:59 AM, Dave Airlie <airlied <at> gmail.com> wrote:

>> Alex Deucher        2                     0
> - pci ids

My development pattern also favors work on master with cherry-picks to
stable.  Usually I notice bugs when working on new code, then have to
go back and apply to stable.  I also try and backport fixes from
master when I see them, but that means cherry-picking.  I'd prefer
master with cherry-picks to stable.

Alex

Re: so the development model is working?

On Fri, Apr 30, 2010 at 7:39 PM, Alex Deucher <alexdeucher <at> gmail.com> wrote:
> On Fri, Apr 30, 2010 at 12:59 AM, Dave Airlie <airlied <at> gmail.com> wrote:
>
>>> Alex Deucher        2                     0
>> - pci ids
>
> My development pattern also favors work on master with cherry-picks to
> stable.  Usually I notice bugs when working on new code, then have to
> go back and apply to stable.  I also try and backport fixes from
> master when I see them, but that means cherry-picking.  I'd prefer
> master with cherry-picks to stable.

Let me just add a me-too here.  For me it's not so much the workflow
of checking out stable to commit the patch, after all, to cherry pick
the patch, I would have to check it out anyway (I usually only use one
checkout of mesa).  The problem for me is that I really don't want to
merge all of 7.8 into master. I just don't know what's in there or who
comitted what's there and I can't vouch for it.  When cherry-picking,
I pick just the commit that I did and understand, not a branch of
potential unrelated fixes.

The other thing, which I haven't seen brought up so far, is that a bug
sometimes requires different fixes for master and for a stable branch.
 For the stable branch you often want to take a more conservative
approach, that avoids affecting too much other code, or maybe even
back out the feature that's broken.  On the master branch, you
typically want to fix the root cause and fix it the right way however.
 In that case you simply can't merge the stable branch into master,
since you'll have two conflicting approaches to fixing the bug.

Re: so the development model is working?

Kristian Høgsberg wrote:

> I guess I've never understood what the merging policy is supposed to
> acheive?  Are we trying to avoid dropping fixes or is there something
> else going on?  It sure seems like we're dropping/losing more fixes
> the way things work now...

I don't think we're losing more now, but we do seem to be losing a lot.
 Before we changed to this model, Brian and I were basically the only
ones that cherry-picked stuff back.  It was difficult to figure out
which changes from three months ago should be brought from master to
stable.  I'll point out that we basically had *no* process, and anything
is an improvement over nothing.

Through the course of this discussion I've begun to wonder whether it's
maybe time to move to a subsystem maintainer model.  A lot of the
problems seem to root from the inability for any one person to be on top
of everything.

Dunno.  Just thinking out loud...

Re: so the development model is working?

> idr wrote :
>  Before we changed to this model, Brian and I were basically 
> the only ones that cherry-picked stuff back.  It was 
> difficult to figure out which changes from three months ago 
> should be brought from master to stable.  I'll point out that 
> we basically had *no* process, and anything is an improvement 
> over nothing.

I think everyone would agree that the problem you describe needed a solution - the only debate seems to be
about whether branch-first submission is the best solution for everyone. 

How about something simple like the following ?

1. fixes go in master first

2. developer who submits a fix to master also decides if it should be cherry-picked to one or more release
branches, and does so either immediately or (ideally) after a day in master, long enough for obvious
problems to get noticed  

3. if developer doesn't have time to cherry-pick immediately then a tag is used to make sure the fix doesn't
get lost

4. if developer isn't sure whether fix should go to a release branch then email the list

5. changes specific to release branch (update of release #s, docco etc.) go directly to release branch and
don't get merged back to master

[PATCH] Mark MESA_swap_control and SGI_video_sync as not "direct only"

From: Owen W. Taylor <otaylor <at> fishsoup.net>

With DRI2, MESA_swap_control and SGI_video_sync are done on the
X server side, so shouldn't be marked direct_only - they only
can be supported if the server supports them.

This fix is not completely right because with DRI1, which is still
supported in some of the drivers, these are in fact direct_only
extensions and could conceivably not be advertised by the server.
---
 src/glx/glxextensions.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/glx/glxextensions.c b/src/glx/glxextensions.c
index e58c296..56239e5 100644
--- a/src/glx/glxextensions.c
+++ b/src/glx/glxextensions.c
 <at>  <at>  -98,7 +98,7  <at>  <at>  static const struct extension_info known_glx_extensions[] = {
    { GLX(MESA_swap_control),           VER(0,0), N, N, N, N },
    { GLX(MESA_swap_frame_usage),       VER(0,0), N, N, N, N },
 #else
-   { GLX(MESA_swap_control),           VER(0,0), Y, N, N, Y },
+   { GLX(MESA_swap_control),           VER(0,0), Y, N, N, N },
    { GLX(MESA_swap_frame_usage),       VER(0,0), Y, N, N, Y },
 #endif
    { GLX(NV_float_buffer),             VER(0,0), N, N, N, N },
 <at>  <at>  -117,7 +117,7  <at>  <at>  static const struct extension_info known_glx_extensions[] = {
    { GLX(OML_sync_control),            VER(0,0), Y, N, N, Y },
    { GLX(SGI_make_current_read),       VER(1,3), Y, N, N, N },
    { GLX(SGI_swap_control),            VER(0,0), Y, N, N, N },

Re: so the development model is working?

>
> I develop on multiple machines too, FWIW.  I do lots of ssh stuff like
> Keith described.
>
> BTW, your last sentence can go either way.  From my point of view
> it's: "Its a lot easier to just fix bugs on the 7.8 branch on those
> machines, and when you get around to it later merging the changes back
> into master, and dedicating a day to retesting master on as many
> configurations as you think require it for you to be happy with the
> work done."

The thing is breaking master by accident or temporarily isn't near as
bad as screwing up on the stable branch. I really want stable branch
to be something I can pull a diff from at any point without worrying
its broken stuff. I don't think we are good enough to stabilise a
single driver or piece of mesa on the stable branch without causing
collateral damage or unknown side effects in other drivers or parts of
the codebase. Bugs are a natural side effect of any development, and
if there are more people using master for development there is a
chance of someone else tripping over the bugs, before hitting stable.

>
>
>>> I'm usually working on master.  If I think I've found a bug (or
>>> someone reports a bug in 7.8, for example) I just change terminal tabs
>>> and start debugging in my 7.8 directory.  I don't have to save my work
>>> on master or check out a different branch, etc.  Just switch to a
>>> different terminal and fire up emacs.  After I fix the bug, I commit
>>> it to the 7.8 branch and document it in the release notes file (I'm
>>> practically the _only_ person who bothers to do that, btw!).  If I

EXT_tetxure_swizzle and BGRA textures : glean test enhancement

In looking at adding EXT_texture_swizzle I'm a bit confused about what
exactly should happen with BGRA textures, as on r300 we use the
texture swizzling to do BGRA, so we would have some interaction at
that point.

To make sure we test for this I've made the following enhancments to
the glean test (in piglit tree - but I'll resubmit against glean tree
if correct).

Can someone with a clue make sure this is a sane test, it passes
against swrast..

Dave.

_______________________________________________
mesa-dev mailing list
mesa-dev <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev