>
> 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 chang
From: Owen W. Taylor
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, th
> 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 thi
On Fri, Apr 30, 2010 at 7:39 PM, Alex Deucher wrote:
> On Fri, Apr 30, 2010 at 12:59 AM, Dave Airlie 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 ne
On Fri, Apr 30, 2010 at 12:59 AM, Dave Airlie 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 an
https://bugs.freedesktop.org/show_bug.cgi?id=27841
--- Comment #5 from Ian Romanick 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,
On Fri, 30 Apr 2010 14:59:09 +1000
Dave Airlie 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 sophisticat
scons couldn't build nv50 as it uses -Werror=pointer-arith by default.
Signed-off-by: Xavier Chantry
---
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_pu
https://bugs.freedesktop.org/show_bug.cgi?id=27841
--- Comment #4 from b...@o-hand.com 2010-04-30 15:32:24 PDT
---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > There is a mechanism, but we have not implemented it in Mesa yet. I think
> > > GL_EXT_discar
> Brian Paul
...
> 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
On Mon, 2010-04-26 at 11:19 -0700, Jesse Barnes wrote:
> - /* FIXME: if DRI2 version supports it... */
> - __glXEnableDirectExtension(psc, "INTEL_swap_event");
> + if (dri2_major == 1 && dri2_minor >= 2) {
> + __glXEnableDirectExtension(psc, "GLX_SGI_video_sync");
> + __glX
On Thu, 29 Apr 2010 22:16:51 -0600, Brian Paul wrote:
> Dave Airlie wrote:
> """because if I add a new feature to my mainline
> branch then happen to notice a bug fix along the way, then I have to
> stop what I'm doing, check out stable, run a test suite, fix the bug
> in stable, run another
Bridgman, John wrote:
From: ... Brian Paul
Sent: Friday, April 30, 2010 12:17 AM
To: Dave Airlie
Cc: mesa-dev@lists.freedesktop.org
...
If you're concerned about producing a stable driver, why
aren't you making more fixes to the 7.8/stable branch,
whether by cherry picking or whatever? That's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bridgman, John wrote:
> Dave's comments implied that there is a policy against fixing bugs in
> master then cherry picking 'em to stable; your comments implied
> master-first plus cherry pick is OK but you feel that fixing in
> stable and merging back
Dave Airlie wrote:
>>
>> Dave,
>>
>> I'm sorry you're frustrated, but let's see if we can at least come
to a
>> better understanding of where we're each coming from.
>>
>> Your message seems to boil down to "cherry-pick fixes from master back
>> to the stable branch" vs. "fix bugs in the stable
Corbin Simpson wrote:
[...]
I think the big problem is the disconnect between VMWare and the rest
of the developers in terms of communication. We all are on IRC
extensively but at least Brian, Keith, Jose, and Vinson are not.
I tried IRC years ago but it was too much of a distraction. If it wa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Airlie wrote:
> Also committing any fixes
> directly to a stable branch is something I've never really heard of as
> a standard. I would assume the expectation is that nobody willing
> introduces regressions, but lots of people accidentally do, a
On Fri, 30 Apr 2010 12:13:23 +1000, Dave Airlie wrote:
> So in the spirit of being less of a dickhead,
>
> Lets have a development model discussion. Can anyone who has an
> interest in the development model please answer the two questions
> below in their view/opinion.
>
> a) what are the goals
"Bridgman, John" writes:
> re: the overall development model, my main question would be whether
> continuing work on a release branch after the initial release is
> really still require d now that we have quarterly major releases for
> all the major components.
FWIW, the frequency of Mesa release
> From: ... Brian Paul
> Sent: Friday, April 30, 2010 12:17 AM
> To: Dave Airlie
> Cc: mesa-dev@lists.freedesktop.org
...
> If you're concerned about producing a stable driver, why
> aren't you making more fixes to the 7.8/stable branch,
> whether by cherry picking or whatever? That's the whole
On Fri, Apr 30, 2010 at 6:42 PM, Corbin Simpson
wrote:
>
> I think the big problem is the disconnect between VMWare and the rest
> of the developers in terms of communication. We all are on IRC
> extensively but at least Brian, Keith, Jose, and Vinson are not.
> Coincidentally, these are the peopl
On Fri, Apr 30, 2010 at 7:44 PM, Marek Olšák wrote:
> BTW in cases when both a vertex attrib offset and stride are not a multiple
> of 4, we simply align the formats e.g. R8G8 -> R8G8X8X8 (xy01).
>
Ooops, this is incorrect. It should be "when both a vertex attrib offset and
stride are a multiple
Sorry about the first part of my last email, it shouldn't have been there..
On Fri, Apr 30, 2010 at 6:15 PM, José Fonseca wrote:
> I agree that deriving coarse grained caps from fine grained sounds
> better.
>
> Anyway, I'll apply this on until we have better caps system inplace, as
> it's bette
On Fri, 2010-04-30 at 09:42 -0700, Corbin Simpson wrote:
> On Fri, Apr 30, 2010 at 6:54 AM, Keith Whitwell
> wrote:
> >> I happen to do mesa development work on about 10 different machines,
> >> so yes I generally keep one mesa tree on each as close to master as I
> >> can get. Again you are devel
On Fri, Apr 30, 2010 at 9:15 AM, José Fonseca wrote:
> I agree that deriving coarse grained caps from fine grained sounds
> better.
>
> Anyway, I'll apply this on until we have better caps system inplace, as
> it's better than nothing.
>
> One more question, having the design of these new fine cap
On Fri, Apr 30, 2010 at 6:54 AM, Keith Whitwell
wrote:
>> I happen to do mesa development work on about 10 different machines,
>> so yes I generally keep one mesa tree on each as close to master as I
>> can get. Again you are developing for swrast or for vmware. Try
>> developing for something lik
On 2010-04-29 18.23, Jakob Bornecrantz wrote:
On 2010-04-29 17.11, Keith Whitwell wrote:
Jakob,
A couple of these are a bit misleading - DX10& DX11 aren't fully
supportable without further changes& extensions to gallium, so it seems
misleading to have these ever return true - at least until
I agree that deriving coarse grained caps from fine grained sounds
better.
Anyway, I'll apply this on until we have better caps system inplace, as
it's better than nothing.
One more question, having the design of these new fine caps in mind, are
the gl_program_constants sufficient?
MaxNativeIn
On Thu, 2010-04-29 at 14:47 -0700, Brian Paul wrote:
> If there aren't any comments/concerns about this patch I'll probably
> commit it tomorrow.
>
> -Brian
I didn't see any problem.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http:
> I happen to do mesa development work on about 10 different machines,
> so yes I generally keep one mesa tree on each as close to master as I
> can get. Again you are developing for swrast or for vmware. Try
> developing for something like radeon and intel on different days, I
> have to keep a num
> Lets have a development model discussion. Can anyone who has an
> interest in the development model please answer the two questions
> below in their view/opinion.
>
> a) what are the goals of the mesa project and development model?
>
> to produce drivers for graphics hardware.
>
> to produce so
2010/4/30 Michel Dänzer :
> On Fre, 2010-04-30 at 14:59 +1000, Dave Airlie wrote:
>> >
>> > I think you exagerate how many testing steps you have to do for each
>> > and every fix. Absolutely, there are times when thorough testing is
>> > needed. But lots of simple bug fixes/changes in 7.8 can be
33 matches
Mail list logo
