Re: [Mesa3d-dev] [PATCH 0/4] Handle both ARB and NV programs in glProgramStringARB and glLoadProgramNV
On Mon, 2009-11-02 at 19:32 -0800, Brian Paul wrote: On Mon, Nov 2, 2009 at 3:20 PM, Ian Romanick i...@freedesktop.org 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
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 bri...@vmware.com 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?= mar...@gmail.com
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/src/mesa/state_tracker/st_cb_drawpixels.c b/src/mesa/state_tracker/st_cb_drawpixels.c
index 0a6bfcd..1d33e81 100644
---
Re: [Mesa3d-dev] [PATCH 0/12] OpenGL ES try2
On Fri, Oct 30, 2009 at 2:32 PM, Chia-I Wu olva...@gmail.com 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/http://0xlab.org/%7Eolv/mesa-es-try2/or http://0xlab.org/~olv/mesa-es-try2.tar.gzhttp://0xlab.org/%7Eolv/mesa-es-try2.tar.gz I screwed up while merging/rebasing the patches. Please use http://0xlab.org/~olv/mesa-es-try2-v2/http://0xlab.org/%7Eolv/mesa-es-try2-v2/or http://0xlab.org/~olv/mesa-es-try2-v2.tar.gzhttp://0xlab.org/%7Eolv/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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: On Mon, Nov 2, 2009 at 3:20 PM, Ian Romanick i...@freedesktop.org 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
Ian Romanick i...@freedesktop.org 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
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, bugzilla-dae...@freedesktop.org wrote: http://bugs.freedesktop.org/show_bug.cgi?id=24650 --- Comment #7 from Ian Romanick i...@freedesktop.org 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
http://bugs.freedesktop.org/show_bug.cgi?id=24650 --- Comment #10 from Karl Schultz karl.w.schu...@gmail.com 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, bugzilla-dae...@freedesktop.org wrote: http://bugs.freedesktop.org/show_bug.cgi?id=24650 --- Comment #9 from Tom Fogal tfo...@alumni.unh.edu 2009-11-03 12:48:22 PST --- bugzilla-dae...@freedesktop.org writes: --- Comment #8 from Karl Schultz karl.w.schu...@gmail.com 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
http://bugs.freedesktop.org/show_bug.cgi?id=24650 --- Comment #8 from Karl Schultz karl.w.schu...@gmail.com 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, bugzilla-dae...@freedesktop.org wrote: http://bugs.freedesktop.org/show_bug.cgi?id=24650 --- Comment #7 from Ian Romanick i...@freedesktop.org 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
Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: On Mon, Nov 2, 2009 at 3:20 PM, Ian Romanick i...@freedesktop.org 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] [PATCH 0/3] Allow real and fake GLX to be built at the same time
On Mon, Oct 26, 2009 at 11:52 PM, Brian Paul bri...@vmware.com 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
http://bugs.freedesktop.org/show_bug.cgi?id=24650 DigitalGibs s...@inlandstudios.com 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
http://bugs.freedesktop.org/show_bug.cgi?id=24650 --- Comment #9 from Tom Fogal tfo...@alumni.unh.edu 2009-11-03 12:48:22 PST --- bugzilla-dae...@freedesktop.org writes: --- Comment #8 from Karl Schultz karl.w.schu...@gmail.com 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
-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.
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 e...@anholt.net 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
