Re: [Mesa-dev] explaining update_arrays
On 06/22/2011 04:18 AM, Dave Airlie wrote: I don't suppose anyone could contribute a comment on why somethings check ctx-VertexProgram._Current, and others check ctx-VertexProgram._Enabled The former may point to a GLSL shader/program, a GL_NV/ARB_vertex_program program or a shader derived from fixed-function state. The later will only be true when a GL_NV/ARB_vertex_program program is enabled and valid (GL_VERTEX_PROGRAM_ARB is enabled and the user's program compiled successfully). I haven't looked at all the places where _Enabled or _Current is used, but there is a difference in what they mean. By the looks of it the 0/POS attrib + the overlapping/16-31 ones check _Current and the others all check _Enabled, to me it would make some sense at least if 0 was consistent with the others, but maybe someone knows what is correct. The confusion probably goes all the way back to the ARB's unfortunate inability to reconcile NV's vs. ATI's different handling of generic vertex arrays. NV used aliasing while ATI didn't so the ARB extension made it optional (a mess). Plus, I think there was some minor difference in GL_ARB_vertex_program vs. GL_ARB_vertex_shaders w.r.t. generic vertex arrays. Do you suspect a bug here? I'd have to go back and re-read all the specs to remember the details. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error building on Windows with SCons
- Original Message - Jose, I don't understand your reply, - Is there some way to add the def file or some way to generate them? - Is building with scons on MingW with windows something that is supposed to work? - Is this issue going to be fixed or is this configuration unsupported? - Is there some way to build with MingW on windows with make? - You reference makefiles however I don't think these are used for scons builds. What I'm trying to say is, the official Mesa source tarballs are missing many files necessary for windows builds. Please try the git source code, or, if you prefer, a tarball with all the source in git, e.g. http://cgit.freedesktop.org/mesa/mesa/snapshot/mesa-7.10.3.zip Or perhaps a better question is is it possible at the moment to build mesa on windows? What are known working configurations? Known working configurations (from git!) are: - mingw crosscompilation from linux (x86 only) - MSVC 2008 (requires cygwin flex bison in the PATH), x86 or x64 I have these continuously running on Jenkins (previously known as Hudson) from git. I haven't tried Mingw on Windows. But it should work without problems with MSYS. I tried with scons because the docs suggest using scons on mesa's page. Yep. There's no other way to build for windows besides scons. - Campbell Jose On Mon, Jun 20, 2011 at 1:18 PM, Jose Fonseca jfons...@vmware.com wrote: Probably it's missing the .def files too... I think that instead of manually listing source files in mesa/Makefile we should invoke 'git ls-files' (and maybe manually list any exclusions). Splitting out Mesa GLUT from the source tree would make things much easier. Which is probably a sensible thing to do anyway, given that there are no glut dependencies in Mesa, and most people are using freeglut anyway. Would anybody see any problem with that? Jose - Original Message - Hi There, Im trying to build Mesa so we can distribute it with Blender3D on Windows (we already do this on Linux). But I have have been unsable to build mesa 7.10.3 (Latest MingW XP, tested python 2.5, 2.7) Simply running 'm;\python25\Scripts\scons.bat' I always get this error: # --- snip scons: Reading SConscript files ... scons: warning: Ignoring missing SConscript 'build\windows-x86-debug\glut\glx\SConscript' File M:\Mesa-7.10.3\src\SConscript, line 13, in module warning: LLVM disabled: not building llvmpipe scons: done reading SConscript files. scons: Building targets ... scons: *** [build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll] Source `src\gallium\state_trackers\wgl\opengl32.def' not found, needed by target `build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll'. scons: building terminated because of errors. # --- snip So I copied: src\mesa\drivers\windows\gldirect\opengl32.def But then I get this error: # --- snip scons: Reading SConscript files ... warning: LLVM disabled: not building llvmpipe scons: done reading SConscript files. scons: Building targets ... link /nologo /fixed:no /incremental:no /dll /out:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll build\windows-x86-debug\gallium\state_trackers\wgl\wgl.lib build\windows-x86-debug\gallium\winsys\sw\gdi\ws_gdi.lib build\windows-x86-debug\mapi\glapi\glapi.lib build\windows-x86-debug\mesa\mesa.lib build\windows-x86-debug\gallium\drivers\softpipe\softpipe.lib build\windows-x86-debug\gallium\drivers\trace\trace.lib build\windows-x86-debug\gallium\drivers\rbug\rbug.lib build\windows-x86-debug\gallium\auxiliary\gallium.lib build\windows-x86-debug\glsl\glsl.lib gdi32.lib user32.lib kernel32.lib ws2_32.lib /PDB:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.pdb /DEBUG build\windows-x86-debug\gallium\targets\libgl-gdi\libgl_gdi.obj /def:src\gallium\state_trackers\wgl\opengl32.def src\gallium\state_trackers\wgl\opengl32.def(37) : warning LNK4017: DESCRIPTION statement not supported for the target platform; ignored opengl32.def : error LNK2001: unresolved external symbol glColorSubTableEXT build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.lib : fatal error LNK1120: 1 unresolved externals scons: building terminated because of errors. # --- snip Any hints on how to resolve these problems? -- - Campbell ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] explaining update_arrays
On 06/22/2011 08:20 AM, Roland Scheidegger wrote: Am 22.06.2011 16:11, schrieb Brian Paul: On 06/22/2011 04:18 AM, Dave Airlie wrote: I don't suppose anyone could contribute a comment on why somethings check ctx-VertexProgram._Current, and others check ctx-VertexProgram._Enabled The former may point to a GLSL shader/program, a GL_NV/ARB_vertex_program program or a shader derived from fixed-function state. The later will only be true when a GL_NV/ARB_vertex_program program is enabled and valid (GL_VERTEX_PROGRAM_ARB is enabled and the user's program compiled successfully). I haven't looked at all the places where _Enabled or _Current is used, but there is a difference in what they mean. By the looks of it the 0/POS attrib + the overlapping/16-31 ones check _Current and the others all check _Enabled, to me it would make some sense at least if 0 was consistent with the others, but maybe someone knows what is correct. The confusion probably goes all the way back to the ARB's unfortunate inability to reconcile NV's vs. ATI's different handling of generic vertex arrays. NV used aliasing while ATI didn't so the ARB extension made it optional (a mess). Plus, I think there was some minor difference in GL_ARB_vertex_program vs. GL_ARB_vertex_shaders w.r.t. generic vertex arrays. Wasn't the difference just that ARB_vertex_shader made it non-aliasing instead of undefined aliasing, or was there more to it... That's true, but then generic array[0] seems special. It's not truly generic because it seems to override the legacy GL_VERTEX_ARRAY pointer. But the spec seems to only indicate this in the ArrayElement() pseudo code. The spec does explicitly say that glVertexAttrib(0,foo) is equivalent to glVertex(foo). -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] explaining update_arrays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/22/2011 07:11 AM, Brian Paul wrote: On 06/22/2011 04:18 AM, Dave Airlie wrote: I don't suppose anyone could contribute a comment on why somethings check ctx-VertexProgram._Current, and others check ctx-VertexProgram._Enabled The former may point to a GLSL shader/program, a GL_NV/ARB_vertex_program program or a shader derived from fixed-function state. The later will only be true when a GL_NV/ARB_vertex_program program is enabled and valid (GL_VERTEX_PROGRAM_ARB is enabled and the user's program compiled successfully). I haven't looked at all the places where _Enabled or _Current is used, but there is a difference in what they mean. By the looks of it the 0/POS attrib + the overlapping/16-31 ones check _Current and the others all check _Enabled, to me it would make some sense at least if 0 was consistent with the others, but maybe someone knows what is correct. The confusion probably goes all the way back to the ARB's unfortunate inability to reconcile NV's vs. ATI's different handling of generic vertex arrays. NV used aliasing while ATI didn't so the ARB extension made it optional (a mess). Plus, I think there was some minor difference in GL_ARB_vertex_program vs. GL_ARB_vertex_shaders w.r.t. generic vertex arrays. In GLSL, only attribute 0 / glVertexArray alias. The other non-generic arrays can only be accessed via the named built-in variables (e.g., gl_Color). Do you suspect a bug here? I'd have to go back and re-read all the specs to remember the details. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4CLO8ACgkQX1gOwKyEAw+XiQCePgPOdtT6VC/M8wS7iy9zAdOG mg0An3JeD0IMvXQEf456jx8CKNlx0bjF =rXOl -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] i965: Don't bother telling swrast_setup about state updates until fallback.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/21/2011 06:34 PM, Eric Anholt wrote:
---
src/mesa/drivers/dri/i915/i830_vtbl.c |2 ++
src/mesa/drivers/dri/i915/i915_vtbl.c |2 ++
src/mesa/drivers/dri/intel/intel_context.c |1 -
3 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i830_vtbl.c
b/src/mesa/drivers/dri/i915/i830_vtbl.c
index 16c7aca..584df82 100644
--- a/src/mesa/drivers/dri/i915/i830_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i830_vtbl.c
@@ -34,6 +34,7 @@
#include tnl/tnl.h
#include tnl/t_context.h
#include tnl/t_vertex.h
+#include swrast_setup/swrast_setup.h
#define FILE_DEBUG_FLAG DEBUG_STATE
@@ -718,6 +719,7 @@ i830_invalidate_state(struct intel_context *intel, GLuint
new_state)
{
struct gl_context *ctx = intel-ctx;
+ _swsetup_InvalidateState(ctx, new_state);
_tnl_InvalidateState(ctx, new_state);
_tnl_invalidate_vertex_state(ctx, new_state);
diff --git a/src/mesa/drivers/dri/i915/i915_vtbl.c
b/src/mesa/drivers/dri/i915/i915_vtbl.c
index 6383cda..9721a1c 100644
--- a/src/mesa/drivers/dri/i915/i915_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i915_vtbl.c
@@ -36,6 +36,7 @@
#include tnl/tnl.h
#include tnl/t_context.h
#include tnl/t_vertex.h
+#include swrast_setup/swrast_setup.h
#include intel_batchbuffer.h
#include intel_regions.h
@@ -709,6 +710,7 @@ i915_invalidate_state(struct intel_context *intel, GLuint
new_state)
{
struct gl_context *ctx = intel-ctx;
+ _swsetup_InvalidateState(ctx, new_state);
_tnl_InvalidateState(ctx, new_state);
_tnl_invalidate_vertex_state(ctx, new_state);
}
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 8b95444..70aee52 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -504,7 +504,6 @@ intelInvalidateState(struct gl_context * ctx, GLuint
new_state)
struct intel_context *intel = intel_context(ctx);
_swrast_InvalidateState(ctx, new_state);
Should this also get moved? I guess I'm not sure what these two
functions do, so this may be a spurious comment.
- _swsetup_InvalidateState(ctx, new_state);
_vbo_InvalidateState(ctx, new_state);
intel-NewGLState |= new_state;
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk4CLYkACgkQX1gOwKyEAw+XfwCeOhS/nmOZPhtXcpR6jDiiZ55q
Xg0AniKKUb1T2ljv9dd+PE7P+BJp7k0X
=DOW0
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Fix depth unbalancing problem in if-statement flattening
From: Ian Romanick ian.d.roman...@intel.com
Previously, if max_depth were 1, the following code would see the
first if-statement (correctly) not get flattened, but the second
if-statement would (incorrectly) get flattened:
void main()
{
if (a)
gl_Position = vec4(0);
if (b)
gl_Position = vec4(1);
}
This is because the visit_leave(ir_if*) method would not decrement the
depth before returning on the first if-statement.
NOTE: This is a candidate for the 7.10 branch.
---
src/glsl/lower_if_to_cond_assign.cpp |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/src/glsl/lower_if_to_cond_assign.cpp
b/src/glsl/lower_if_to_cond_assign.cpp
index e3a1065..b637eb4 100644
--- a/src/glsl/lower_if_to_cond_assign.cpp
+++ b/src/glsl/lower_if_to_cond_assign.cpp
@@ -149,11 +149,9 @@ ir_visitor_status
ir_if_to_cond_assign_visitor::visit_leave(ir_if *ir)
{
/* Only flatten when beyond the GPU's maximum supported nesting depth. */
- if (this-depth = this-max_depth)
+ if (this-depth-- = this-max_depth)
return visit_continue;
- this-depth--;
-
bool found_control_flow = false;
ir_variable *cond_var;
ir_assignment *assign;
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure.ac: Make --without-gallium-drivers work as expected
From: Ian Romanick ian.d.roman...@intel.com --- configure.ac |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index c9dd8a7..76736c0 100644 --- a/configure.ac +++ b/configure.ac @@ -562,6 +562,12 @@ AC_ARG_WITH([gallium-drivers], [with_gallium_drivers=$withval], [with_gallium_drivers=$GALLIUM_DRIVERS_DEFAULT]) +# Doing '--without-gallium-drivers' will set this variable to 'no'. Clear it +# here so that the script doesn't choke on an unknown driver name later. +if test x$with_gallium_drivers = xno; then + with_gallium_drivers='' +fi + if test x$enable_opengl = xno -a \ x$enable_gles1 = xno -a \ x$enable_gles2 = xno -a \ -- 1.7.5.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] i965: Don't bother telling swrast_setup about state updates until fallback.
On Wed, 22 Jun 2011 10:59:37 -0700, Ian Romanick i...@freedesktop.org wrote: diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c index 8b95444..70aee52 100644 --- a/src/mesa/drivers/dri/intel/intel_context.c +++ b/src/mesa/drivers/dri/intel/intel_context.c @@ -504,7 +504,6 @@ intelInvalidateState(struct gl_context * ctx, GLuint new_state) struct intel_context *intel = intel_context(ctx); _swrast_InvalidateState(ctx, new_state); Should this also get moved? I guess I'm not sure what these two functions do, so this may be a spurious comment. swrast has some internal stuff to mitigate the statechange overhead (if you haven't swrasted in a while, it replaces its function pointer with a stub, and when you go to use it it notices that it's been stubbed out and assumes all state has changed). Because of that, swrast_InvalidateState ended up being .1% CPU usage. It's tempting to move it out even still, but I think if we do then we'd need to _swrast_Wakeup anywhere that we call into swrast. pgp81CwiyWXJb.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] i965: Don't bother telling swrast_setup about state updates until fallback.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/22/2011 11:53 AM, Eric Anholt wrote: On Wed, 22 Jun 2011 10:59:37 -0700, Ian Romanick i...@freedesktop.org wrote: diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c index 8b95444..70aee52 100644 --- a/src/mesa/drivers/dri/intel/intel_context.c +++ b/src/mesa/drivers/dri/intel/intel_context.c @@ -504,7 +504,6 @@ intelInvalidateState(struct gl_context * ctx, GLuint new_state) struct intel_context *intel = intel_context(ctx); _swrast_InvalidateState(ctx, new_state); Should this also get moved? I guess I'm not sure what these two functions do, so this may be a spurious comment. swrast has some internal stuff to mitigate the statechange overhead (if you haven't swrasted in a while, it replaces its function pointer with a stub, and when you go to use it it notices that it's been stubbed out and assumes all state has changed). Because of that, swrast_InvalidateState ended up being .1% CPU usage. It's tempting to move it out even still, but I think if we do then we'd need to _swrast_Wakeup anywhere that we call into swrast. That makes sense. For the series: Reviewed-by: Ian Romanick ian.d.roman...@intel.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4CO8gACgkQX1gOwKyEAw+ZOQCeLR7GTmwNB8JaSq8Tz0AgB3U7 gjgAn07vHoNq/Yc99brndnwSp+aa0BIj =E2KO -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Make --without-gallium-drivers work as expected
On Wed, Jun 22, 2011 at 11:38 AM, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com --- configure.ac | 6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index c9dd8a7..76736c0 100644 --- a/configure.ac +++ b/configure.ac @@ -562,6 +562,12 @@ AC_ARG_WITH([gallium-drivers], [with_gallium_drivers=$withval], [with_gallium_drivers=$GALLIUM_DRIVERS_DEFAULT]) +# Doing '--without-gallium-drivers' will set this variable to 'no'. Clear it +# here so that the script doesn't choke on an unknown driver name later. +if test x$with_gallium_drivers = xno; then + with_gallium_drivers='' +fi Nitpicky, but the other thing that would be nice is if bare --with-gallium-drivers becomes $GALLIUM_DRIVERS_DEFAULT. Could be: case $with_gallium_drivers in yes) with_gallium_drivers=$GALLIUM_DRIVERS_DEFAULT ;; no) with_gallium_drivers='' ;; esac Either way, good to catch this case. Reviewed-by: Dan Nicholson dbn.li...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Make --without-gallium-drivers work as expected
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/22/2011 12:55 PM, Dan Nicholson wrote: On Wed, Jun 22, 2011 at 11:38 AM, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com --- configure.ac |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index c9dd8a7..76736c0 100644 --- a/configure.ac +++ b/configure.ac @@ -562,6 +562,12 @@ AC_ARG_WITH([gallium-drivers], [with_gallium_drivers=$withval], [with_gallium_drivers=$GALLIUM_DRIVERS_DEFAULT]) +# Doing '--without-gallium-drivers' will set this variable to 'no'. Clear it +# here so that the script doesn't choke on an unknown driver name later. +if test x$with_gallium_drivers = xno; then + with_gallium_drivers='' +fi Nitpicky, but the other thing that would be nice is if bare --with-gallium-drivers becomes $GALLIUM_DRIVERS_DEFAULT. Could be: case $with_gallium_drivers in yes) with_gallium_drivers=$GALLIUM_DRIVERS_DEFAULT ;; no) with_gallium_drivers='' ;; esac Either way, good to catch this case. I like that better. Reviewed-by: Dan Nicholson dbn.li...@gmail.com When I take your change, I'll make this S-o-b, okay? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4CT34ACgkQX1gOwKyEAw+YIgCcCx5q6ZQtxb9ZiDJqQlCG8BxT ZJ4An1XQHar9yFL6kNk8NGdDbLYpN6wM =TXc0 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] explaining update_arrays
By the looks of it the 0/POS attrib + the overlapping/16-31 ones check _Current and the others all check _Enabled, to me it would make some sense at least if 0 was consistent with the others, but maybe someone knows what is correct. The confusion probably goes all the way back to the ARB's unfortunate inability to reconcile NV's vs. ATI's different handling of generic vertex arrays. NV used aliasing while ATI didn't so the ARB extension made it optional (a mess). Plus, I think there was some minor difference in GL_ARB_vertex_program vs. GL_ARB_vertex_shaders w.r.t. generic vertex arrays. In GLSL, only attribute 0 / glVertexArray alias. The other non-generic arrays can only be accessed via the named built-in variables (e.g., gl_Color). Ah that makes sense, thanks guys, Do you suspect a bug here? No but this codepath is a real dog on profiles, and I'm guessing 90% of it useless in 90% of profiles, like in an app that doesn't use VBOs it pretty much could end up as min = 2*1000*1000*1000; but to figure that out it has a lot overhead. I'm guessing we should probably push working out the array max closer to the edges and not in this path if we can. So I had to make sure I understood it before I try to change it. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] explaining update_arrays
On 06/22/2011 02:36 PM, Dave Airlie wrote: By the looks of it the 0/POS attrib + the overlapping/16-31 ones check _Current and the others all check _Enabled, to me it would make some sense at least if 0 was consistent with the others, but maybe someone knows what is correct. The confusion probably goes all the way back to the ARB's unfortunate inability to reconcile NV's vs. ATI's different handling of generic vertex arrays. NV used aliasing while ATI didn't so the ARB extension made it optional (a mess). Plus, I think there was some minor difference in GL_ARB_vertex_program vs. GL_ARB_vertex_shaders w.r.t. generic vertex arrays. In GLSL, only attribute 0 / glVertexArray alias. The other non-generic arrays can only be accessed via the named built-in variables (e.g., gl_Color). Ah that makes sense, thanks guys, Do you suspect a bug here? No but this codepath is a real dog on profiles, and I'm guessing 90% of it useless in 90% of profiles, like in an app that doesn't use VBOs it pretty much could end up as min = 2*1000*1000*1000; but to figure that out it has a lot overhead. I'm guessing we should probably push working out the array max closer to the edges and not in this path if we can. Agreed. I'd like to get rid of that code. If we can push the responsbility of not fetching vertex data from out of bounds down into the drivers, that would simplify core Mesa. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] multiple versions in version string
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/21/2011 10:58 AM, tom fogal wrote: Michel Dänzer mic...@daenzer.net writes: On Die, 2011-06-21 at 10:34 -0600, tom fogal wrote:=20 On 06/21/2011 10:23 AM, Michel D=C3=A4nzer wrote: On Die, 2011-06-21 at 10:10 -0600, tom fogal wrote: On 06/21/2011 01:06 AM, Michel D=C3=A4nzer wrote: On Mon, 2011-06-20 at 13:46 -0600, tom fogal wrote: Nathan Kiddnathan...@spicycrypto.ca writes: On 11-06-20 02:55 PM, tom fogal wrote: You are correct, rendering is indirect! Of course, for indirect rendering every glFoo() function call needs to be mapped to (GL)X protocol. Protocol exists up to OpenGL 1.4. I can always fall back to OSMesa, I suppose :( Or a software rasterizer libGL / driver which uses direct rendering. Preferably using llvmpipe for performance. It was hidden in another part of the thread, but I actually don't care (much) about performance, as this is for a regression testing system. Then you have free choice between llvmpipe or just softpipe (can be chosen at runtime), or even classic swrast. Yep. I have used swrast with great effect in the past. Gallium and OSMesa currently don't mix, though Brian has mentioned once or twice that it wouldn't be /too/ hard to bring up. Does GLX indirect rendering 'mix' with OSMesa at all? If not, why are you bringing this up? :) No; OSMesa stands in place of GLX, of course. I mentioned they don't mix because you implied I could try using llvmpipe or softpipe. In reality, the only option for a standalone RTS that needs GL2.0 is swrast/OSMesa. It should work fine with Xvfb or any other X server, using any kind of display connection. This thread started because Xvfb isn't offering what I need: GL 2.0. Because you're using indirect rendering. Yes. That's the point, I /can't/ get direct rendering with Xvfb. What Michel means is you can build a software version of Mesa that just draws into a pixmap. It's not indirect GLX, and it's not direct rendering either. This is --with-driver=xlib, IIRC. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4CdAwACgkQX1gOwKyEAw+/DACfd278qm5plyLbPK9Hhn7QAJ1t xnsAnRVoncK6GSz8LyTBVvrduvUSl+6I =TTDp -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error building on Windows with SCons
Thanks Jose, Mesa builds without trouble for me on Linux and windows (in a VM), Would be good if this was mentioned in windows build instructions, or mesa files updated to be a full GIT export, nevertheless its great to have this working. On Wed, Jun 22, 2011 at 2:15 PM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - Jose, I don't understand your reply, - Is there some way to add the def file or some way to generate them? - Is building with scons on MingW with windows something that is supposed to work? - Is this issue going to be fixed or is this configuration unsupported? - Is there some way to build with MingW on windows with make? - You reference makefiles however I don't think these are used for scons builds. What I'm trying to say is, the official Mesa source tarballs are missing many files necessary for windows builds. Please try the git source code, or, if you prefer, a tarball with all the source in git, e.g. http://cgit.freedesktop.org/mesa/mesa/snapshot/mesa-7.10.3.zip Or perhaps a better question is is it possible at the moment to build mesa on windows? What are known working configurations? Known working configurations (from git!) are: - mingw crosscompilation from linux (x86 only) - MSVC 2008 (requires cygwin flex bison in the PATH), x86 or x64 I have these continuously running on Jenkins (previously known as Hudson) from git. I haven't tried Mingw on Windows. But it should work without problems with MSYS. I tried with scons because the docs suggest using scons on mesa's page. Yep. There's no other way to build for windows besides scons. - Campbell Jose On Mon, Jun 20, 2011 at 1:18 PM, Jose Fonseca jfons...@vmware.com wrote: Probably it's missing the .def files too... I think that instead of manually listing source files in mesa/Makefile we should invoke 'git ls-files' (and maybe manually list any exclusions). Splitting out Mesa GLUT from the source tree would make things much easier. Which is probably a sensible thing to do anyway, given that there are no glut dependencies in Mesa, and most people are using freeglut anyway. Would anybody see any problem with that? Jose - Original Message - Hi There, Im trying to build Mesa so we can distribute it with Blender3D on Windows (we already do this on Linux). But I have have been unsable to build mesa 7.10.3 (Latest MingW XP, tested python 2.5, 2.7) Simply running 'm;\python25\Scripts\scons.bat' I always get this error: # --- snip scons: Reading SConscript files ... scons: warning: Ignoring missing SConscript 'build\windows-x86-debug\glut\glx\SConscript' File M:\Mesa-7.10.3\src\SConscript, line 13, in module warning: LLVM disabled: not building llvmpipe scons: done reading SConscript files. scons: Building targets ... scons: *** [build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll] Source `src\gallium\state_trackers\wgl\opengl32.def' not found, needed by target `build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll'. scons: building terminated because of errors. # --- snip So I copied: src\mesa\drivers\windows\gldirect\opengl32.def But then I get this error: # --- snip scons: Reading SConscript files ... warning: LLVM disabled: not building llvmpipe scons: done reading SConscript files. scons: Building targets ... link /nologo /fixed:no /incremental:no /dll /out:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll build\windows-x86-debug\gallium\state_trackers\wgl\wgl.lib build\windows-x86-debug\gallium\winsys\sw\gdi\ws_gdi.lib build\windows-x86-debug\mapi\glapi\glapi.lib build\windows-x86-debug\mesa\mesa.lib build\windows-x86-debug\gallium\drivers\softpipe\softpipe.lib build\windows-x86-debug\gallium\drivers\trace\trace.lib build\windows-x86-debug\gallium\drivers\rbug\rbug.lib build\windows-x86-debug\gallium\auxiliary\gallium.lib build\windows-x86-debug\glsl\glsl.lib gdi32.lib user32.lib kernel32.lib ws2_32.lib /PDB:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.pdb /DEBUG build\windows-x86-debug\gallium\targets\libgl-gdi\libgl_gdi.obj /def:src\gallium\state_trackers\wgl\opengl32.def src\gallium\state_trackers\wgl\opengl32.def(37) : warning LNK4017: DESCRIPTION statement not supported for the target platform; ignored opengl32.def : error LNK2001: unresolved external symbol glColorSubTableEXT build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.lib : fatal error LNK1120: 1 unresolved externals scons: building terminated because of errors. # --- snip Any hints on how to resolve these problems? -- - Campbell ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- - Campbell ___ mesa-dev mailing
Re: [Mesa-dev] [PATCH 0/8] GBM Graphics Buffer Manager
On Wed, Jun 22, 2011 at 10:30 PM, Benjamin Franzke benjaminfran...@googlemail.com wrote: Hi List, This series adds a graphics buffer management library which is targeted to be used as native (drm) platform for egl on kms or openwfd, and thus replaces the current mechanism of using a fd as EGLNativeDisplay and EGL_MESA_drm_image to create buffers. GBM uses the mesas internal dri interface or acts as a gallium state tracker. The mapping to EGL types is: gbm_device - EGLNativeDisplayType gbm_bo - EGLNativePixmapType / EGL_NATIVE_PIXMAP_KHR This integrates better with the idea of EGL, which assumes there is some kind of native library thats responsible for allocating buffers. We wanted to use libkms, but since that's explicitly designed to no support hw renderable buffers we have to go a different route. The idea looks good to me in general. But would it make sense to replace st/gbm and targets/gdm by another backend that uses st/xa, which is supposed to have a stable ABI, instead (currently only on xa_branch)? Benjamin Franzke (8): dri: Add dupImage to DRIimageExtension intel: Implement DRIimageExtension::dupImage st/dri: Implement DRIimageExtension::dupImage Add gbm (generic/graphics buffer manager) gbm: Add dri backend gbm: Add gallium (drm) backend egl_dri2: Hookup gbm as drm platform st/egl: Hookup gbm for drm backend Makefile | 11 + configs/autoconf.in | 10 +- configs/default | 14 +- configure.ac | 70 include/EGL/eglplatform.h | 6 + include/GL/internal/dri_interface.h | 2 + src/egl/drivers/dri2/Makefile | 2 + src/egl/drivers/dri2/egl_dri2.c | 76 +++-- src/egl/drivers/dri2/egl_dri2.h | 11 + src/egl/drivers/dri2/platform_drm.c | 99 -- src/egl/main/Makefile | 4 + src/gallium/state_trackers/dri/drm/dri2.c | 19 + src/gallium/state_trackers/egl/Makefile | 3 +- src/gallium/state_trackers/egl/common/egl_g3d.c | 18 +- src/gallium/state_trackers/egl/common/native.h | 3 + src/gallium/state_trackers/egl/drm/modeset.c | 36 ++ src/gallium/state_trackers/egl/drm/native_drm.c | 77 ++--- src/gallium/state_trackers/egl/drm/native_drm.h | 4 + src/gallium/state_trackers/gbm/Makefile | 46 +++ src/gallium/state_trackers/gbm/gbm_drm.c | 225 .../state_trackers/gbm/gbm_gallium_drmint.h | 74 src/gallium/targets/egl/Makefile | 2 +- src/gallium/targets/gbm/Makefile | 32 ++ src/gallium/targets/gbm/gbm.c | 61 src/gallium/targets/gbm/pipe_loader.c | 192 ++ src/gallium/targets/gbm/pipe_loader.h | 48 +++ src/gbm/Makefile | 14 + src/gbm/backends/Makefile | 14 + src/gbm/backends/Makefile.template | 65 src/gbm/backends/dri/Makefile | 22 ++ src/gbm/backends/dri/driver_name.c | 89 + src/gbm/backends/dri/gbm_dri.c | 377 src/gbm/backends/dri/gbm_driint.h | 78 src/gbm/main/Makefile | 90 + src/gbm/main/backend.c | 128 +++ src/gbm/main/backend.h | 36 ++ src/gbm/main/common.c | 88 + src/gbm/main/common.h | 42 +++ src/gbm/main/common_drm.h | 48 +++ src/gbm/main/gbm.c | 189 ++ src/gbm/main/gbm.h | 99 + src/gbm/main/gbm.pc.in | 12 + src/gbm/main/gbmint.h | 81 + src/mesa/drivers/dri/intel/intel_screen.c | 27 ++- 44 files changed, 2536 insertions(+), 108 deletions(-) create mode 100644 src/gallium/state_trackers/gbm/Makefile create mode 100644 src/gallium/state_trackers/gbm/gbm_drm.c create mode 100644 src/gallium/state_trackers/gbm/gbm_gallium_drmint.h create mode 100644 src/gallium/targets/gbm/Makefile create mode 100644 src/gallium/targets/gbm/gbm.c create mode 100644 src/gallium/targets/gbm/pipe_loader.c create mode 100644 src/gallium/targets/gbm/pipe_loader.h create mode 100644 src/gbm/Makefile create mode 100644 src/gbm/backends/Makefile create mode 100644 src/gbm/backends/Makefile.template create mode 100644 src/gbm/backends/dri/Makefile create mode 100644 src/gbm/backends/dri/driver_name.c create mode 100644
Re: [Mesa-dev] [PATCH] linker: Reject shaders that use too many varyings
On Wed, Jun 22, 2011 at 10:12 PM, Roland Scheidegger srol...@vmware.com wrote: Am 21.06.2011 20:59, schrieb Sven Arvidsson: This change broke a whole lot of stuff on r600g, for example Unigine Heaven: shader uses too many varying components (36 32) It looks like the r600g driver claims to only support 10 varyings, which the state tracker reduces to 8 (as it subtracts the supposedly included color varyings). At first sight I can't quite see why it's limited to 10, all r600 chips should be able to handle 32 (dx10 requirement) but of course the driver might not (mesa itself is limited to 16 it seems). If it worked just fine before that suggests it indeed works just fine with more... Someone more familiar with the driver should be able to tell if it's safe to increase the limit to 32 (the state tracker will cap it to 16). The hardware definitely supports 32. I'm not sure why it's currently set to 10; I don't see any limitations in the code off hand. Alex Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of the GLSL-TGSI translator
On 06/16/2011 12:43 PM, Brian Paul wrote: On 06/16/2011 10:34 AM, Bryan Cain wrote: On Thu, Jun 16, 2011 at 9:08 AM, Brian Paul bri...@vmware.com mailto:bri...@vmware.com wrote: Looks like nice work, Bryan. Just a few minor questions/comments for now: 1. The st_fragment/vertex/geometry_program structs now have a glsl_to_tgsi field. I did a grep, but I couldn't find where that field is assigned. Can you clue me in? It's assigned at the end of the get_mesa_program function in st_glsl_to_tgsi.cpp. Thanks. I was using grep glsl_to_tgsi *.[ch] Duh. 2. The above mentioned program structs contains an old Mesa instruction program AND/OR(?) a GLSL IR. Do both types of representations co-exist sometimes? Perhaps you could update the comments on those structs to explain that. They used to co-exist, because after my first commit, st_glsl_to_tgsi still generated Mesa IR in addition to TGSI. But I removed the Mesa IR generation in st/mesa: stop generating Mesa IR in st_glsl_to_tgsi, so now it has either one or the other - glsl_to_tgsi_visitor for GLSL shaders, Mesa IR programs for everything else. OK, can you update the comments with this info? 3. Kind of a follow-on: for glDrawPixels and glBitmap we take the original program code (in Mesa form) and prepend extra instructions for fetching the fragment color or doing the fragment kill. Do we always have the Mesa instructions for this? It seems we don't normally want to generate Mesa instructions all the time but we still need them sometimes. No, I didn't realize Mesa did that, and we don't have the Mesa instructions for GLSL programs anymore. I'm not sure what the right way to handle that is. How hard would it be to edit the IR to insert the extra operations? For glBitmaps it's basically sample a texture and then do a conditional fragment kill. For glDrawPixels we need to sample the texture representing the image, then apply the pixel transfer ops (scale/bias, table lookup, etc). We generate the code for that in st_atom_pixeltransfer.c. That program is then concatenated with the current fragment program with _mesa_combine_program(). If we ever propogate GLSL IR through the gallium interface there's lots of places where we'll need to do other kinds of IR editing. -Brian I've been working on this for the last few days, but there are some things I still haven't figured out yet. I've written a function to generate the shader for glDrawPixels/glCopyPixels in the form of glsl_to_tgsi_instructions, and I doubt I'll have any problems writing the code to merge those instructions with an existing shader.However, for the shader to work correctly, I need to set stfp-glsl_to_tgsi in st_fragment_program, but all of the fragment program variables in st_atom_pixeltransfer.c and st_cb_drawpixels.c have the type gl_program or gl_fragment_program. When do these become st_fragment_program so they can be processed in st_program.c? Will I need to move the glsl_to_tgsi attribute into gl_fragment program and give it a name not specific to the state tracker? My other question is that if I don't have this part done before the merge window closes, would it still be possible to merge the GLSL-TGSI translator for 7.11 tomorrow or Friday, and for me to fix the glBitmap/glDrawPixels/glCopyPixels issue in the stable branch before Mesa 7.11 is released? It's the only remaining issue I know of with the GLSL-TGSI translator, and even it's something of a corner case. -Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/test/trivial: make it build
Signed-off-by: Alon Levy al...@redhat.com --- src/gallium/tests/trivial/Makefile |9 +++-- src/gallium/tests/trivial/quad-tex.c |4 ++-- src/gallium/tests/trivial/tri.c |4 ++-- 3 files changed, 11 insertions(+), 6 deletions(-) diff --git a/src/gallium/tests/trivial/Makefile b/src/gallium/tests/trivial/Makefile index 2ed6341..e82 100644 --- a/src/gallium/tests/trivial/Makefile +++ b/src/gallium/tests/trivial/Makefile @@ -11,7 +11,12 @@ INCLUDES = \ -I$(TOP)/src/gallium/winsys \ $(PROG_INCLUDES) -LINKS = \ +ifeq ($(MESA_LLVM),1) +LINKS = $(TOP)/src/gallium/drivers/llvmpipe/libllvmpipe.a +LDFLAGS += $(LLVM_LDFLAGS) +endif + +LINKS += \ $(TOP)/src/gallium/drivers/rbug/librbug.a \ $(TOP)/src/gallium/drivers/trace/libtrace.a \ $(TOP)/src/gallium/drivers/galahad/libgalahad.a \ @@ -46,4 +51,4 @@ $(OBJECTS): %.o: %.c $(CC) -c $(INCLUDES) $(CFLAGS) $(DEFINES) $(PROG_DEFINES) $ -o $@ $(PROGS): %: %.o $(LINKS) - $(CC) $(LDFLAGS) $ $(LINKS) -lm -lpthread -ldl -o $@ + $(CC) $(LDFLAGS) $ $(LINKS) $(LLVM_LIBS) -lm -lpthread -ldl -o $@ diff --git a/src/gallium/tests/trivial/quad-tex.c b/src/gallium/tests/trivial/quad-tex.c index 3a64b1c..6c38b10 100644 --- a/src/gallium/tests/trivial/quad-tex.c +++ b/src/gallium/tests/trivial/quad-tex.c @@ -212,7 +212,7 @@ static void init_prog(struct program *p) p-sampler.mag_img_filter = PIPE_TEX_MIPFILTER_LINEAR; p-sampler.normalized_coords = 1; - surf_tmpl.format = templat.format; + surf_tmpl.format = PIPE_FORMAT_B8G8R8A8_UNORM; /* All drivers support this */ surf_tmpl.usage = PIPE_BIND_RENDER_TARGET; surf_tmpl.u.tex.level = 0; surf_tmpl.u.tex.first_layer = 0; @@ -329,7 +329,7 @@ static void draw(struct program *p) /* vertex element data */ cso_set_vertex_elements(p-cso, 2, p-velem); - util_draw_vertex_buffer(p-pipe, + util_draw_vertex_buffer(p-pipe, p-cso, p-vbuf, 0, PIPE_PRIM_QUADS, 4, /* verts */ diff --git a/src/gallium/tests/trivial/tri.c b/src/gallium/tests/trivial/tri.c index bfd2f3c..656e92e 100644 --- a/src/gallium/tests/trivial/tri.c +++ b/src/gallium/tests/trivial/tri.c @@ -153,7 +153,7 @@ static void init_prog(struct program *p) p-rasterizer.cull_face = PIPE_FACE_NONE; p-rasterizer.gl_rasterization_rules = 1; - surf_tmpl.format = templat.format; + surf_tmpl.format = PIPE_FORMAT_B8G8R8A8_UNORM; surf_tmpl.usage = PIPE_BIND_RENDER_TARGET; surf_tmpl.u.tex.level = 0; surf_tmpl.u.tex.first_layer = 0; @@ -258,7 +258,7 @@ static void draw(struct program *p) /* vertex element data */ cso_set_vertex_elements(p-cso, 2, p-velem); - util_draw_vertex_buffer(p-pipe, + util_draw_vertex_buffer(p-pipe, p-cso, p-vbuf, 0, PIPE_PRIM_TRIANGLES, 3, /* verts */ -- 1.7.5.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
