Re: [Mesa3d-dev] [PATCH 0/4] Handle both ARB and NV programs in glProgramStringARB and glLoadProgramNV

[Keith Whitwell]

On Mon, 2009-11-02 at 19:32 -0800, Brian Paul wrote:
> On Mon, Nov 2, 2009 at 3:20 PM, Ian Romanick  wrote:
> > This patch series enables glProgramStringARB to handle NV vertex and
> > fragment programs when the appropriate extensions are supported.  It
> > also enables glLoadProgramNV to handle ARB vertex and fragment
> > programs.  This behavior is described in the "Interactions with"
> > sections of ARB_vertex_program and NV_fragment_program.
> 
> Did someone's app hit this functionality?

Yes, do tell...

I'm fine with these going in too.

Keith


--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH] mesa/st: fix crash when drawing stencil pixels outside the drawbuffer

[Marek Olšák]

Hi Brian,

I tried your patch and it solves the buffer-mapping issue.

I attached a new patch that fixes the clipping issue. Please, review/push.

Best regards
Marek Olšák


On Mon, Nov 2, 2009 at 6:12 PM, Brian Paul  wrote:

> Marek Olšák wrote:
>
>> Hi,
>>
>> the attached patch fixes a possible crash in function draw_stencil_pixels
>> in mesa/state_tracker. I've also updated the list of formats we read from to
>> prevent an assertion failing later in the code.
>>
>> This makes glean/depthStencil work on r300g and softpipe.
>>
>> Best regards
>> Marek Olšák
>>
>>
> diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
> b/src/mesa/state_tracker/st_cb_drawpixels.c
> index 0a6bfcd..0699404 100644
> --- a/src/mesa/state_tracker/st_cb_drawpixels.c
> +++ b/src/mesa/state_tracker/st_cb_drawpixels.c
> @@ -669,6 +669,12 @@ draw_stencil_pixels(GLcontext *ctx, GLint x, GLint y,
>strb = st_renderbuffer(ctx->DrawBuffer->
>   Attachment[BUFFER_STENCIL].Renderbuffer);
>
> +   /* Do not draw outside the drawbuffer */
> +   if (x + width > ctx->DrawBuffer->Width)
> +  width = ctx->DrawBuffer->Width - x;
> +   if (y + height > ctx->DrawBuffer->Height)
> +  height = ctx->DrawBuffer->Height - y;
>
> I think you can use _mesa_clip_drawpixels() here instead.  See swrast or
> other drivers for example usage.
>
>
> The second change should be a totally separate patch since it's independent
> of the drawpixels clipping issue.
>
>
> diff --git a/src/mesa/state_tracker/st_cb_texture.c
> b/src/mesa/state_tracker/st_cb_texture.c
> index 878a40f..6f287ff 100644
> --- a/src/mesa/state_tracker/st_cb_texture.c
> +++ b/src/mesa/state_tracker/st_cb_texture.c
> @@ -1309,7 +1309,8 @@ fallback_copy_texsubimage(GLcontext *ctx, GLenum
> target, GLint level,
>   srcX, srcY,
>   width, height);
>
> -   if (baseFormat == GL_DEPTH_COMPONENT &&
> +   if ((baseFormat == GL_DEPTH_COMPONENT ||
> +baseFormat == GL_DEPTH24_STENCIL8) &&
>pf_is_depth_and_stencil(stImage->pt->format))
>   transfer_usage = PIPE_TRANSFER_READ_WRITE;
>else
>
>
> I think there's a few things wrong with the depth/stencil path in this
> code.  Can you try the attached patch?
>
> I also suspec that util_blit_pixels_writemask() isn't working properly when
> blitting depth/stencil pixels.
>
> -Brian
>
> diff --git a/src/mesa/state_tracker/st_cb_texture.c
> b/src/mesa/state_tracker/st_cb_texture.c
> index 878a40f..00a0e4c 100644
> --- a/src/mesa/state_tracker/st_cb_texture.c
> +++ b/src/mesa/state_tracker/st_cb_texture.c
> @@ -1309,7 +1309,8 @@ fallback_copy_texsubimage(GLcontext *ctx, GLenum
> target, GLint level,
>   srcX, srcY,
>   width, height);
>
> -   if (baseFormat == GL_DEPTH_COMPONENT &&
> +   if ((baseFormat == GL_DEPTH_COMPONENT ||
> +baseFormat == GL_DEPTH_STENCIL) &&
>pf_is_depth_and_stencil(stImage->pt->format))
>   transfer_usage = PIPE_TRANSFER_READ_WRITE;
>else
> @@ -1322,7 +1323,7 @@ fallback_copy_texsubimage(GLcontext *ctx, GLenum
> target, GLint level,
>   destX, destY, width, height);
>
>if (baseFormat == GL_DEPTH_COMPONENT ||
> -   baseFormat == GL_DEPTH24_STENCIL8) {
> +   baseFormat == GL_DEPTH_STENCIL) {
>   const GLboolean scaleOrBias = (ctx->Pixel.DepthScale != 1.0F ||
>  ctx->Pixel.DepthBias != 0.0F);
>   GLint row, yStep;
> @@ -1455,7 +1456,7 @@ st_copy_texsubimage(GLcontext *ctx,
>struct gl_texture_image *texImage =
>   _mesa_select_tex_image(ctx, texObj, target, level);
>struct st_texture_image *stImage = st_texture_image(texImage);
> -   const GLenum texBaseFormat = texImage->InternalFormat;
> +   const GLenum texBaseFormat = texImage->_BaseFormat;
>struct gl_framebuffer *fb = ctx->ReadBuffer;
>struct st_renderbuffer *strb;
>struct pipe_context *pipe = ctx->st->pipe;
> @@ -1476,12 +1477,9 @@ st_copy_texsubimage(GLcontext *ctx,
>
>/* determine if copying depth or color data */
>if (texBaseFormat == GL_DEPTH_COMPONENT ||
> -   texBaseFormat == GL_DEPTH24_STENCIL8) {
> +   texBaseFormat == GL_DEPTH_STENCIL) {
>   strb = st_renderbuffer(fb->_DepthBuffer);
>}
> -   else if (texBaseFormat == GL_DEPTH_STENCIL_EXT) {
> -  strb = st_renderbuffer(fb->_StencilBuffer);
> -   }
>else {
>   /* texBaseFormat == GL_RGB, GL_RGBA, GL_ALPHA, etc */
>   strb = st_renderbuffer(fb->_ColorReadBuffer);
>
>
From 23a8a4fdc2848be822c9884d2b758909287e9a6e Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Tue, 3 Nov 2009 16:16:05 +0100
Subject: [PATCH] mesa/st: clip pixels in draw_stencil_pixels to avoid crash

---
 src/mesa/state_tracker/st_cb_drawpixels.c |   20 +++-
 1 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/s

Re: [Mesa3d-dev] [PATCH 0/12] OpenGL ES try2

[Chia-I Wu]

On Fri, Oct 30, 2009 at 2:32 PM, Chia-I Wu  wrote:

> On Fri, Oct 30, 2009 at 12:44:35PM +0800, Chia-I Wu wrote:
> > It has been a month and several weeks since my last try.  Comparing to
> > the last try, the number of patches goes down from 34 to 12.  Most of
> > them have gone into the master.  Due to the size, the patch series is
> > uploaded elsewhere
> > http://0xlab.org/~olv/mesa-es-try2/or
> > http://0xlab.org/~olv/mesa-es-try2.tar.gz
> I screwed up while merging/rebasing the patches.  Please use
> http://0xlab.org/~olv/mesa-es-try2-v2/or
> http://0xlab.org/~olv/mesa-es-try2-v2.tar.gz
> Sorry for the inconvenience.
>
Any comment?  If there is any concern/question, please let me know.
I am willing to fix it or discuss more about the design choices.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH 0/4] Handle both ARB and NV programs in glProgramStringARB and glLoadProgramNV

[Ian Romanick]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian Paul wrote:
> On Mon, Nov 2, 2009 at 3:20 PM, Ian Romanick  wrote:
>> This patch series enables glProgramStringARB to handle NV vertex and
>> fragment programs when the appropriate extensions are supported.  It
>> also enables glLoadProgramNV to handle ARB vertex and fragment
>> programs.  This behavior is described in the "Interactions with"
>> sections of ARB_vertex_program and NV_fragment_program.
> 
> Did someone's app hit this functionality?

I recently modified piglit's vpfp-generic test to use the ARB functions
for both ARB and NV vertex programs.  It worked fine on Nvidia binary
drivers, but it failed on Mesa.

>> These are the least intrusive patches for the 7.6 release branch.
>> Ideally the ARB parser would be extended to handle the NV programs,
>> and a lot of the existing NV handling code would be refactored.  This
>> seems too intrusive for the stable branch, especially since we don't
>> have a good parser test suite for the NV programs.
>>
>> One quirk that bothers me about the existing code:  glLoadProgramNV
>> doesn't call Driver.ProgramStringNotify.  Is this intentional?
> 
> Probably an oversight.  Driver.ProgramStringNotify() is used to tell
> the driver that a vertex/fragment program has been changed.

Do you think I should modify LoadProgramNV to be like ProgramStringARB?
 I'll probably do some additional refactoring in the master after these
patches hit the stable branch.

> I didn't test your patches but they look OK to me.

All of the piglit asmparser tests pass.  I haven't run them through our
oglconform yet.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrwfJEACgkQX1gOwKyEAw+wZQCeJLsGIpG4hJkhJpgmiqfI+f6K
NY8AoIvACdJuzmgC3OxE9P8Wk/zEwPsV
=gZ/F
-END PGP SIGNATURE-

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [RFC] Proposed Mesa 7.7 / 7.6.1 release schedule

[tom fogal]

Ian Romanick  writes:
> As promised, I'm sending out a proposed release schedule before the
> 11th hour.

[snip -- final 12/21]

> Does this sound good to everyone?

Works for me.  Thanks for the notice; it's very useful for those of us
on the fringes of development.

-tom

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [Bug 24650] Visual Studio takes over 30 minutes to compile Mesa core

[Karl Schultz]

Yeah, I'm preparing a set of changes to allow Mesa 7.6 to build on Visual
Studio.  Right now, the 7.6 tarballs do not build.

And I'm sitting here watching the image code compile for a LONG time.

I think I can put this at the top of the file:

#if _MSC_VER == 1400
#pragma optimize("", off)
#endif

This may also work and only turns off global optimizations, which I am
guessing is the issue here.  I'll have to experiment.

#if _MSC_VER == 1400
#pragma optimize("g", off)
#endif

and that should not be too horrible.  But I do hate putting MSFT hacks like
this in the source.

I don't see a good way to turn off the optimization for this file by using
only the build files (Visual Studio project files).  We ship VC8 (the 2005
compiler) project files.  People with VC9 (the 2008 compiler) convert the
VC8 files to VC9 when they load them.  This lets us maintain only one
version to support 2005 and 2008.  If we moved to shipping separate VC8 and
VC9 project files, we could turn off the optimizer in the mesa Project file
for the file(s) in question, but that would be the only difference between
the two versions.  I'm not sure that is worth doing because it is hard
enough keeping one set of project files up to date.

I'll work on it a bit more and submit the appropriate patches.

Karl


On Mon, Nov 2, 2009 at 11:06 AM,  wrote:

> http://bugs.freedesktop.org/show_bug.cgi?id=24650
>
>
>
>
>
> --- Comment #7 from Ian Romanick   2009-11-02
> 10:06:31 PST ---
> (In reply to comment #6)
> > I've seen the older (2005) compilers take a long time to compile one the
> > files, image.c I think, in 32-bit Release mode.  I think that this source
> > code file used a lot of macros that expanded out to a lot of code.  And
> this
> > code's size or structure caused the optimizer to take a long time to
> build
> > it.
> >
> > I worked around it in the 2005 studio by turning off optimization just
> for
> > that one file.  I have not noticed the problem with the 2008 tools.
>
> Perhaps we could use some #ifdef to detect Visual Studio 2005 and disable
> optimization via a #pragma?
>
>
> --
> Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are the assignee for the bug.
>
>
> --
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [Bug 24650] Visual Studio takes over 30 minutes to compile Mesa core

[bugzilla-daemon]

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





--- Comment #10 from Karl Schultz   2009-11-03 
15:07:05 PST ---
Hi Tom,

Sorry about the duplicate posts.  Thanks for the info.

I played with this for awhile and didn't get any result I am happy with.
When the optimizer is on, the compiler seems to compile a handful of files
at once and generates code for all of them at the same time.  This makes it
hard to figure out which files are slowing things down.  Adding the pragma
didn't seem to help for the files I tried.  And no, the global optimization
options are not turned on.  The build also seemed slow for files in addition
to image.c.  Part of the problem may be caused by the thing chewing on so
many files at once, and I could not find a way to stop that other than
disabling optimizations completely.

Since this problem is for an old compiler (2005), 2008 (express) is free,
available and does not have this problem, and 2010 is in beta, I'm inclined
to punt and just say that if you want an optimized build, it may take
awhile.  Ideally, most people are only going to compile it that way once.
There may be a SP for 2005; I don't think I have it - I really do not use
Windows much for this sort of thing.

scons - I think that there's another window driver over in the gallium area
and they build it with scons.  We're just doing the visual studio files
because some people like them and simply aren't using scons or similar
systems.

in-source annotations vs build system changes- I see your point, but one can
argue it either way.

Karl


On Tue, Nov 3, 2009 at 1:48 PM,  wrote:

> http://bugs.freedesktop.org/show_bug.cgi?id=24650
>
>
>
>
>
> --- Comment #9 from Tom Fogal   2009-11-03 12:48:22
> PST ---
> bugzilla-dae...@freedesktop.org writes:
> > --- Comment #8 from Karl Schultz   2009-11-03
> 12:20
> > :32 PST ---
> > I think I can put this at the top of the file:
> >
> > #if _MSC_VER == 1400
> > #pragma optimize("", off)
> > #endif
> [snip -- or variation]
> > and that should not be too horrible.  But I do hate putting MSFT
> > hacks like this in the source.
>
> FWIW, I like the in-the-source annotations better than build system
> changes, because build systems (particularly VS) are decoupled from
> source code.  It makes lifting subsets of a tree difficult.
>
> > We ship VC8 (the 2005 compiler) project files.  People with VC9 (the
> > 2008 compiler) convert the VC8 files to VC9 when they load them. [.
> > . .] If we moved to shipping separate VC8 and VC9 project files, we
> > could [make this work, but] I'm not sure that is worth doing because
> > it is hard enough keeping one set of project files up to date.
>
> What about a makefile generator?  There's some (out of date?) scons
> files in the tree, IIRC.  Not that I care for scons in particular,
> but some type of abstracted representation of the build seems to
> workaround this issue, and presumably allows one to script builds, even
> on windows.
>
> OT, but btw, the default assignee is the mesa dev list; no need to CC
> the list on replies unless that's been changed for the bug (your reply
> came through twice).
>
>
> --
> Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are the assignee for the bug.
>
>
> --
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>


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

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [Bug 24650] Visual Studio takes over 30 minutes to compile Mesa core

[bugzilla-daemon]

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





--- Comment #8 from Karl Schultz   2009-11-03 
12:20:32 PST ---
Yeah, I'm preparing a set of changes to allow Mesa 7.6 to build on Visual
Studio.  Right now, the 7.6 tarballs do not build.

And I'm sitting here watching the image code compile for a LONG time.

I think I can put this at the top of the file:

#if _MSC_VER == 1400
#pragma optimize("", off)
#endif

This may also work and only turns off global optimizations, which I am
guessing is the issue here.  I'll have to experiment.

#if _MSC_VER == 1400
#pragma optimize("g", off)
#endif

and that should not be too horrible.  But I do hate putting MSFT hacks like
this in the source.

I don't see a good way to turn off the optimization for this file by using
only the build files (Visual Studio project files).  We ship VC8 (the 2005
compiler) project files.  People with VC9 (the 2008 compiler) convert the
VC8 files to VC9 when they load them.  This lets us maintain only one
version to support 2005 and 2008.  If we moved to shipping separate VC8 and
VC9 project files, we could turn off the optimizer in the mesa Project file
for the file(s) in question, but that would be the only difference between
the two versions.  I'm not sure that is worth doing because it is hard
enough keeping one set of project files up to date.

I'll work on it a bit more and submit the appropriate patches.

Karl


On Mon, Nov 2, 2009 at 11:06 AM,  wrote:

> http://bugs.freedesktop.org/show_bug.cgi?id=24650
>
>
>
>
>
> --- Comment #7 from Ian Romanick   2009-11-02
> 10:06:31 PST ---
> (In reply to comment #6)
> > I've seen the older (2005) compilers take a long time to compile one the
> > files, image.c I think, in 32-bit Release mode.  I think that this source
> > code file used a lot of macros that expanded out to a lot of code.  And
> this
> > code's size or structure caused the optimizer to take a long time to
> build
> > it.
> >
> > I worked around it in the 2005 studio by turning off optimization just
> for
> > that one file.  I have not noticed the problem with the 2008 tools.
>
> Perhaps we could use some #ifdef to detect Visual Studio 2005 and disable
> optimization via a #pragma?
>
>
> --
> Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are the assignee for the bug.
>
>
> --
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>


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

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH 0/4] Handle both ARB and NV programs in glProgramStringARB and glLoadProgramNV

[Brian Paul]

Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Brian Paul wrote:
>> On Mon, Nov 2, 2009 at 3:20 PM, Ian Romanick  wrote:
>>> This patch series enables glProgramStringARB to handle NV vertex and
>>> fragment programs when the appropriate extensions are supported.  It
>>> also enables glLoadProgramNV to handle ARB vertex and fragment
>>> programs.  This behavior is described in the "Interactions with"
>>> sections of ARB_vertex_program and NV_fragment_program.
>> Did someone's app hit this functionality?
> 
> I recently modified piglit's vpfp-generic test to use the ARB functions
> for both ARB and NV vertex programs.  It worked fine on Nvidia binary
> drivers, but it failed on Mesa.
> 
>>> These are the least intrusive patches for the 7.6 release branch.
>>> Ideally the ARB parser would be extended to handle the NV programs,
>>> and a lot of the existing NV handling code would be refactored.  This
>>> seems too intrusive for the stable branch, especially since we don't
>>> have a good parser test suite for the NV programs.
>>>
>>> One quirk that bothers me about the existing code:  glLoadProgramNV
>>> doesn't call Driver.ProgramStringNotify.  Is this intentional?
>> Probably an oversight.  Driver.ProgramStringNotify() is used to tell
>> the driver that a vertex/fragment program has been changed.
> 
> Do you think I should modify LoadProgramNV to be like ProgramStringARB?

If you mean call ctx->Driver.ProgramStringNotify(), yes.


>  I'll probably do some additional refactoring in the master after these
> patches hit the stable branch.

OK.

-Brian

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [RFC] Proposed Mesa 7.7 / 7.6.1 release schedule

[Brian Paul]

Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> As promised, I'm sending out a proposed release schedule before the 11th
> hour.  Doing a simultaneous x.y.z and x.y+1 release worked out pretty
> well last time, so I propose to do the same thing again.  The RC and
> final dates below are for both 7.7 and 7.6.1.
> 
> The RC1 date is pretty important as it aligns with at least one distro's
> release schedule.
> 
> Create mesa_7_7_branch11/19
> RC1   11/30
> RC2   12/7
> RC3   12/14
> final 12/21
> 
> The goal is for RC3 and final to be the identical with the exception of
> version strings and repository tags.
> 
> Does this sound good to everyone?  Does anyone have an alternate proposal?

The basic plans sounds good.  I don't think we have to commit to 
specific dates but we can try to be close.

-Brian

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH 0/3] Allow real and fake GLX to be built at the same time

[Chia-I Wu]

On Mon, Oct 26, 2009 at 11:52 PM, Brian Paul  wrote:

> Following the remap table patch series, this patch series allows, say,
>> src/glx/x11/ and src/mesa/drivers/x11/ to be compiled at the same time.
>> It is now possible to switch into any directory and build the
>> libraries/drivers in it.  It should make testing across multiple
>> libGL.so or test building mesa easier.
>>
> Looks OK to me and seems to build/run alright.  However, I'd like Ian to
> take a look also to see if he has any concerns.
> Ian?
>
Any comment?
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [Bug 24650] Visual Studio takes over 30 minutes to compile Mesa core

[bugzilla-daemon]

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


DigitalGibs  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




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

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [Bug 24650] Visual Studio takes over 30 minutes to compile Mesa core

[bugzilla-daemon]

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





--- Comment #9 from Tom Fogal   2009-11-03 12:48:22 PST 
---
bugzilla-dae...@freedesktop.org writes:
> --- Comment #8 from Karl Schultz   2009-11-03 12:20
> :32 PST ---
> I think I can put this at the top of the file:
> 
> #if _MSC_VER == 1400
> #pragma optimize("", off)
> #endif
[snip -- or variation]
> and that should not be too horrible.  But I do hate putting MSFT
> hacks like this in the source.

FWIW, I like the in-the-source annotations better than build system
changes, because build systems (particularly VS) are decoupled from
source code.  It makes lifting subsets of a tree difficult.

> We ship VC8 (the 2005 compiler) project files.  People with VC9 (the
> 2008 compiler) convert the VC8 files to VC9 when they load them. [.
> . .] If we moved to shipping separate VC8 and VC9 project files, we
> could [make this work, but] I'm not sure that is worth doing because
> it is hard enough keeping one set of project files up to date.

What about a makefile generator?  There's some (out of date?) scons
files in the tree, IIRC.  Not that I care for scons in particular,
but some type of abstracted representation of the build seems to
workaround this issue, and presumably allows one to script builds, even
on windows.

OT, but btw, the default assignee is the mesa dev list; no need to CC
the list on replies unless that's been changed for the bug (your reply
came through twice).


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

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [RFC] Proposed Mesa 7.7 / 7.6.1 release schedule

[Ian Romanick]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As promised, I'm sending out a proposed release schedule before the 11th
hour.  Doing a simultaneous x.y.z and x.y+1 release worked out pretty
well last time, so I propose to do the same thing again.  The RC and
final dates below are for both 7.7 and 7.6.1.

The RC1 date is pretty important as it aligns with at least one distro's
release schedule.

Create mesa_7_7_branch11/19
RC1   11/30
RC2   12/7
RC3   12/14
final 12/21

The goal is for RC3 and final to be the identical with the exception of
version strings and repository tags.

Does this sound good to everyone?  Does anyone have an alternate proposal?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrwf2wACgkQX1gOwKyEAw8SZwCeI5Gq/TUKGT7PNrta6wgIyO/w
PfIAn2BEn1R9hHlnfD6oPaW7hieJ5yx9
=hwtf
-END PGP SIGNATURE-

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Mesa (master): intel: Use GTT mapping when available for swrast.

[Eric Anholt]

On Fri, 2009-10-30 at 19:10 -0600, Brian Paul wrote:
> Eric Anholt wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 7c8bed62e0165a0be3363f7abf81bf9e30341e00
> > URL:
> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=7c8bed62e0165a0be3363f7abf81bf9e30341e00
> > 
> > Author: Eric Anholt 
> > Date:   Fri Oct 30 15:33:11 2009 -0700
> > 
> > intel: Use GTT mapping when available for swrast.
> > 
> > This improves piglit quick.tests runtime from 19:33 minutes to 6:06 on
> > my GM45.  It should also hide most of the A17 swizzling issues, though
> > they'll still exist when swapping occurs (which is the kernel's problem
> > either way).
> 
> Eric, I'm getting a bus error with this change (at least I think it's 
> this commit).
> 
> progs/demos/readpix (press 'f' to read from front color buffer).

Works here.

-- 
Eric Anholt
e...@anholt.net eric.anh...@intel.com




signature.asc
Description: This is a digitally signed message part
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev