Re: [Mesa-dev] [PATCH 5/5] automake: add src/glsl and src/glsl/glcpp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11-12-23 08:51 PM, Matt Turner wrote:
> On Fri, Dec 23, 2011 at 8:37 PM, Kenneth Graunke
wrote:
>> On 12/23/2011 04:21 PM, Matt Turner wrote:
>>> # Flex and Bison for GLSL compiler
>>> -FLEX = @FLEX@
>>> -BISON = @BISON@
>>> +FLEX = @LEX@
>>> +BISON = @YACC@
This will set FLEX to any lex program found by autconf. This is not
good, but not any worse than it is now. It simply follows the current
assumption that flex/bison is always available at checkout out time on
all platforms.
I am assuming it has not been a problem so far as not al platforms build
mesa. Note that the configuration can be "created" (./autogen.sh) on a
platform with flex/bison. The tarball would be created (make dist) with
the lex/yacc code generated. The tarball can then be moved and
configured (./configure) on the target platform where no lex/yacc exists
and build successfully.
>>>
>>
>> Question about this: will this still require Flex and Bison, or accept
>> any Lex and Yacc? The GLSL compiler actually relies upon Flex/Bison
>> extensions to pass line locations and other things, so it won't work
>> with ordinary lex/yacc.
>
> I believe it will actually accept any yacc/lex. Strangely, there
> aren't AC_PROG macros for bison and flex, although many projects
> require these implementations.
>
> We run into this in Gentoo a lot, and it's surprising that there isn't
> (to my knowledge) an autoconfig macro for bison/flex.
Probably for the same reasons there are no macros for each brand of
compiler.
>
>
> I use AC_PROG_{LEX,YACC} below since they define $YACC and $LEX, which
> are what automake knows to use for .y/.l files. If there's a better
> way to handle this, I'm okay with it.
If only FLEX/BISON works, then you have to write your own macros to test
for the presence of the tool and write the makefile rules. If a platform
does not have flex and bison, then you cannot create the mesa autotools
configuration.
To make mesa code more portable, one would have to look at a different
implementation of the GLSL compiler to remove such a dependency. If that
is not possible, configure.ac should do a "feature test" for the
flex/bison and abort if not found. This would be preferable to having a
GLSL compiler failing in a hard to diagnose way.
>
>>> # Library names (base name)
>>> GL_LIB = @GL_LIB@
>>> diff --git a/configure.ac b/configure.ac
>>> index 0d75353..7aea0b5 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -17,6 +17,12 @@ AC_INIT([Mesa],[mesa_version],
>>> AC_CONFIG_AUX_DIR([bin])
>>> AC_CANONICAL_HOST
>>>
>>> +# Initialize Automake
>>> +AM_INIT_AUTOMAKE([foreign dist-bzip2])
>>> +
>>> +# Initialize libtool
>>> +AC_PROG_LIBTOOL
>>> +
>>> dnl Save user CFLAGS and CXXFLAGS so one can override the default ones
>>> USER_CFLAGS="$CFLAGS"
>>> USER_CXXFLAGS="$CXXFLAGS"
>>> @@ -44,11 +50,14 @@ if test "x$MKDEP" = "x"; then
>>> AC_MSG_ERROR([makedepend is required to build Mesa])
>>> fi
>>>
>>> -AC_PATH_PROG([FLEX], [flex])
>>> -test "x$FLEX" = "x" && AC_MSG_ERROR([flex is needed to build Mesa])
>>> -
>>> -AC_PATH_PROG([BISON], [bison])
>>> -test "x$BISON" = "x" && AC_MSG_ERROR([bison is needed to build Mesa])
>>> +AC_PROG_YACC
>>> +AC_PATH_PROG([YACC_INST], $YACC)
>>> +if test ! -f "$srcdir/gram.c"; then
>>> + if test -z "$YACC_INST"; then
>>> + AC_MSG_ERROR([yacc not found - unable to compile gram.y])
>>> + fi
>>> +fi
>>
>> Isn't AC_PROG_YACC a strong enough guarantee? I'm a little confused by
>> the asymmetry between the LEX and YACC checks here.
It's a workaround to AC_PROG_YACC. When it cannot find any yacc program,
it just sets the YACC variable to 'yacc" regardless of whether it is on
disk or not. The extra AC_PATH_PROG ensures that whatever AC_PROG_YACC
finds is in fact really there.
>>
>
> I wondered the same thing myself during the last go-around. Gaetan to
> the rescue again!
>
> http://lists.freedesktop.org/archives/mesa-dev/2011-September/012658.html
>
>>> +AC_PROG_LEX
>>>
>>> dnl Our fallback install-sh is a symlink to minstall. Use the existing
>>> dnl configuration in that case.
>>> @@ -996,10 +1005,10 @@ if test "x$enable_dri" = xyes ; then
>>> AC_MSG_WARN([Shared dricore requires GCC-compatible rpath handling.
Disabling shared dricore])
>>> enable_dricore=no
>>> else
>>> - DRICORE_GLSL_LIBS='$(TOP)/$(LIB_DIR)/libglsl.so'
>>> + DRICORE_GLSL_LIBS='$(TOP)/src/glsl/libglsl.la'
>>> DRICORE_LIBS='$(TOP)/$(LIB_DIR)/libdricore.so'
>>> - DRICORE_LIB_DEPS='-L$(TOP)/$(LIB_DIR)
-Wl,-R$(DRI_DRIVER_INSTALL_DIR) -lglsl'
>>> - DRI_LIB_DEPS='-L$(TOP)/$(LIB_DIR) -Wl,-R$(DRI_DRIVER_INSTALL_DIR)
-ldricore -lglsl'
>>> + DRICORE_LIB_DEPS='-L$(TOP)/$(LIB_DIR)
-Wl,-R$(DRI_DRIVER_INSTALL_DIR) $(TOP)/src/glsl/.libs/libglsl.so'
>>> + DRI_LIB_DEPS='-L$(TOP)/$(LIB_DIR) -Wl,-R$(DRI_DRIVER_INSTALL_DIR)
-ldricore $(TOP)/src/glsl/.libs/libglsl.so'
>>> DRI_CFLAGS='$(CFLAGS_NOVISIBILITY) -DUSE_DRICORE'
>>> DRI_CXXFLAGS='$(CXXFLAGS_NOVISIBILITY) -DUSE_DRICORE'
>>> MESA_MODULES='$(DRICORE_LIBS) $(DRICORE
[Mesa-dev] [PATCH 3/6] glsl: always define data_end union as we always use it on line 369
--- src/glsl/link_uniforms.cpp |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp index c7de480..fc1c1f7 100644 --- a/src/glsl/link_uniforms.cpp +++ b/src/glsl/link_uniforms.cpp @@ -336,9 +336,7 @@ link_assign_uniform_locations(struct gl_shader_program *prog) rzalloc_array(prog, struct gl_uniform_storage, num_user_uniforms); union gl_constant_value *data = rzalloc_array(uniforms, union gl_constant_value, num_data_slots); -#ifndef NDEBUG union gl_constant_value *data_end = &data[num_data_slots]; -#endif parcel_out_uniform_storage parcel(prog->UniformHash, uniforms, data); -- 1.7.7.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/6] mklib: tab cleanup, no functional change
---
bin/mklib |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/bin/mklib b/bin/mklib
index 510ac91..56e0b36 100755
--- a/bin/mklib
+++ b/bin/mklib
@@ -986,7 +986,7 @@ case $ARCH in
# remove temporary extracted .o files
rm -rf ${LIBNAME}.obj
-else
+ else
LIBNAME="lib${LIBNAME}.so" # prefix with "lib", suffix with
".so"
OPTS="-shared"
--
1.7.7.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/5] configure.ac: bump AC_PREREQ to 2.60
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-12-23 08:09 PM, Matt Turner wrote: > On Fri, Dec 23, 2011 at 8:06 PM, Kenneth Graunke wrote: >> On 12/23/2011 04:21 PM, Matt Turner wrote: >>> --- >>> configure.ac | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/configure.ac b/configure.ac >>> index c0d6882..0d75353 100644 >>> --- a/configure.ac >>> +++ b/configure.ac >>> @@ -1,6 +1,6 @@ >>> dnl Process this file with autoconf to create configure. >>> >>> -AC_PREREQ([2.59]) >>> +AC_PREREQ([2.60]) >>> >>> dnl Versioning - scrape the version from configs/default >>> m4_define([mesa_version], >> >> I'm not opposed to this, but presumably you had some reason for doing >> it. Care to explain in the commit message? > > Truthfully, I do not know. Gaetan said it should be so when I sent the > my first iteration of the automake patch back in September: All xorg modules require minimum 2.60 (2006). Given mesa is usually compiled from source, it makes sense to align this version with xorg. If mesa is compiled by itself or with projects other than xorg which require an older version of autoconf, then it can remain at 2.59 (2003), provided that someone can test that it really does configure at that level. I doubt very much as there were big changes during this three year gap. Note than autoconf and automake come as a "range of pairs". Some later versions of automake will not install if autoconf is too old. If the code uses features from a later version of automake, the code won't build with older version of automake. So the version of automake also influences the level of autoconf needed. All builds are done with much more recent versions of autoconf. When the older version ceases to work because the code uses new autoconf features, no one notices. That's my assumption. I try to document these things here: http://www.x.org/wiki/NewModuleGuidelines#configure.ac > > http://lists.freedesktop.org/archives/mesa-dev/2011-September/012656.html > > Matt > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk71LRoACgkQubv1WfueyfxRjACdHIEutRQ1kfNljFwx93xq91Qp O6AAn0tlyKy4nqtY35zHs6SND9XHSLkh =3UJ6 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] mesa: fpclassify is available on Haiku
--- src/mesa/main/querymatrix.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/main/querymatrix.c b/src/mesa/main/querymatrix.c index eaedf7c..2843d55 100644 --- a/src/mesa/main/querymatrix.c +++ b/src/mesa/main/querymatrix.c @@ -73,7 +73,7 @@ fpclassify(double x) #elif defined(__APPLE__) || defined(__CYGWIN__) || defined(__FreeBSD__) || \ defined(__OpenBSD__) || defined(__NetBSD__) || defined(__DragonFly__) || \ (defined(__sun) && defined(__C99FEATURES__)) || defined(__MINGW32__) || \ - (defined(__sun) && defined(__GNUC__)) || defined(ANDROID) + (defined(__sun) && defined(__GNUC__)) || defined(ANDROID) || defined(__HAIKU__) /* fpclassify is available. */ -- 1.7.7.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] gallium: include mapi headers which are utilized. fixes no-makedepend Haiku build
On Tue, Dec 27, 2011 at 8:40 AM, Alexander von Gluck wrote: > > --- > src/gallium/drivers/r300/Makefile | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/src/gallium/drivers/r300/Makefile > b/src/gallium/drivers/r300/Makefile > index 5f56fc4..3e3a765 100644 > --- a/src/gallium/drivers/r300/Makefile > +++ b/src/gallium/drivers/r300/Makefile > @@ -15,6 +15,7 @@ C_SOURCES += \ > LIBRARY_INCLUDES = \ > -I$(TOP)/include \ > -I$(TOP)/src/mesa \ > + -I$(TOP)/src/mapi \ > -I$(TOP)/src/glsl > > include ../../Makefile.template > -- That file no longer exists in Mesa/master. Are you sure you're patching against the latest sources from git? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] gallium: use Mesa pthread_barrier_t on Haiku, as it is incomplete under Haiku
--- src/gallium/auxiliary/os/os_thread.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/gallium/auxiliary/os/os_thread.h b/src/gallium/auxiliary/os/os_thread.h index d830129..3e1c273 100644 --- a/src/gallium/auxiliary/os/os_thread.h +++ b/src/gallium/auxiliary/os/os_thread.h @@ -314,7 +314,7 @@ typedef int64_t pipe_condvar; * pipe_barrier */ -#if (defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS) || defined(PIPE_OS_HAIKU)) && !defined(PIPE_OS_ANDROID) +#if (defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS)) && !defined(PIPE_OS_ANDROID) typedef pthread_barrier_t pipe_barrier; -- 1.7.7.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/6] glu: remove BeOS define as BeOS is not longer a target platform
On Tue, Dec 27, 2011 at 8:42 AM, Alexander von Gluck
wrote:
>
> ---
> src/glu/sgi/Makefile | 7 +--
> 1 files changed, 1 insertions(+), 6 deletions(-)
>
> diff --git a/src/glu/sgi/Makefile b/src/glu/sgi/Makefile
> index c8b29ed..94427e2 100644
> --- a/src/glu/sgi/Makefile
> +++ b/src/glu/sgi/Makefile
> @@ -124,12 +124,7 @@ OBJECTS = $(C_OBJECTS) $(CC_OBJECTS)
> # TARGETS #
>
> default:
> - @if [ "${CONFIG_NAME}" = "beos" ] ; then \
> - echo "$(GLU_LIB_NAME) not build under BeOS, but integrated
> into ${GL_LIB_NAME}." ; \
> - exit 0 ; \
> - else \
> - $(MAKE) $(TOP)/$(LIB_DIR)/$(GLU_LIB_NAME) || exit 1 ; \
> - fi
> + $(MAKE) $(TOP)/$(LIB_DIR)/$(GLU_LIB_NAME) || exit 1 ; \
>
> $(TOP)/$(LIB_DIR):
> -mkdir $(TOP)/$(LIB_DIR)
The remaining command doesn't need the "|| exit 1; \" part at the end.
I'll fix that and commit the patch.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] mesa: fpclassify is available on Haiku
On Tue, Dec 27, 2011 at 8:43 AM, Alexander von Gluck wrote: > > --- > src/mesa/main/querymatrix.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/mesa/main/querymatrix.c b/src/mesa/main/querymatrix.c > index eaedf7c..2843d55 100644 > --- a/src/mesa/main/querymatrix.c > +++ b/src/mesa/main/querymatrix.c > @@ -73,7 +73,7 @@ fpclassify(double x) > #elif defined(__APPLE__) || defined(__CYGWIN__) || defined(__FreeBSD__) || > \ > defined(__OpenBSD__) || defined(__NetBSD__) || defined(__DragonFly__) > || \ > (defined(__sun) && defined(__C99FEATURES__)) || defined(__MINGW32__) || > \ > - (defined(__sun) && defined(__GNUC__)) || defined(ANDROID) > + (defined(__sun) && defined(__GNUC__)) || defined(ANDROID) || > defined(__HAIKU__) > > /* fpclassify is available. */ > I'll push this soon. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/6] mklib: tab cleanup, no functional change
On Tue, Dec 27, 2011 at 8:43 AM, Alexander von Gluck
wrote:
>
> ---
> bin/mklib | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/bin/mklib b/bin/mklib
> index 510ac91..56e0b36 100755
> --- a/bin/mklib
> +++ b/bin/mklib
> @@ -986,7 +986,7 @@ case $ARCH in
>
> # remove temporary extracted .o files
> rm -rf ${LIBNAME}.obj
> - else
> + else
> LIBNAME="lib${LIBNAME}.so" # prefix with "lib",
> suffix with ".so"
> OPTS="-shared"
>
Pushed. Thanks.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] gallium: use Mesa pthread_barrier_t on Haiku, as it is incomplete under Haiku
On Tue, Dec 27, 2011 at 8:39 AM, Alexander von Gluck wrote: > > --- > src/gallium/auxiliary/os/os_thread.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/gallium/auxiliary/os/os_thread.h > b/src/gallium/auxiliary/os/os_thread.h > index d830129..3e1c273 100644 > --- a/src/gallium/auxiliary/os/os_thread.h > +++ b/src/gallium/auxiliary/os/os_thread.h > @@ -314,7 +314,7 @@ typedef int64_t pipe_condvar; > * pipe_barrier > */ > > -#if (defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || > defined(PIPE_OS_SOLARIS) || defined(PIPE_OS_HAIKU)) && > !defined(PIPE_OS_ANDROID) > +#if (defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || > defined(PIPE_OS_SOLARIS)) && !defined(PIPE_OS_ANDROID) > > typedef pthread_barrier_t pipe_barrier; > > -- Looks good. Will push soon. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Replace RENDERINPUTS with direct GLbitfield64 usage.
2011/12/27 Mathias Fröhlich : > > Hi, > > On Tuesday, December 27, 2011 00:37:13 Brian Paul wrote: >> For the series: >> Reviewed-by: Brian Paul > Thanks. > > What is your preference to do with the remaining bitset.h header? > * Remove this as ununsed? > * Remove the 64 bit bitset implementation as this could be better done with > GLbitfield64 and leave the unlimited bitset there? > * Keep it as a whole? If bitset.h is no longer used let's just remove it. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vbo: Clean up recalculate_input_bindings.
2011/12/27 Mathias Fröhlich : > > Hi, > > On Tuesday, December 27, 2011 00:17:09 Brian Paul wrote: >> LGTM. I presume you've done a piglit run and tested with a few other >> things? > I have run piglit quick with classic swrast an piglit r600g on gallium rv670 > with this change. Also I am pretty sure that I have started osgviewer and > probably flightgear on this. The full piglit runs are just too heavy running > with valgrind. I never had the patience to wait for that to finish. > > So, I have leared from the past series that classic swrast serves as a good > testbed for tnl drivers like the intel one - where I do not have hardware at > hand. I did not do this in former times. > In this case the swrast test is probably my best bet to catch changes in the > classic paths anyway. > > When we are at this, what tests would you recommend? It sounds like you ran enough of piglit to catch any likely regression. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/6] glsl: always define data_end union as we always use it on line 369
On Tue, Dec 27, 2011 at 8:41 AM, Alexander von Gluck
wrote:
>
> ---
> src/glsl/link_uniforms.cpp | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
> index c7de480..fc1c1f7 100644
> --- a/src/glsl/link_uniforms.cpp
> +++ b/src/glsl/link_uniforms.cpp
> @@ -336,9 +336,7 @@ link_assign_uniform_locations(struct gl_shader_program
> *prog)
> rzalloc_array(prog, struct gl_uniform_storage, num_user_uniforms);
> union gl_constant_value *data =
> rzalloc_array(uniforms, union gl_constant_value, num_data_slots);
> -#ifndef NDEBUG
> union gl_constant_value *data_end = &data[num_data_slots];
> -#endif
>
> parcel_out_uniform_storage parcel(prog->UniformHash, uniforms, data);
>
How about moving the assert that uses data_end into the #ifndef NDEBUG
test seen above it?
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index c7de480..b331db7 100644
--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -365,9 +365,9 @@ link_assign_uniform_locations(struct gl_shader_program *prog
for (unsigned i = 0; i < num_user_uniforms; i++) {
assert(uniforms[i].storage != NULL);
}
-#endif
assert(parcel.values == data_end);
+#endif
prog->NumUserUniformStorage = num_user_uniforms;
prog->UniformStorage = uniforms;
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/6] glu: remove BeOS define as BeOS is not longer a target platform
---
src/glu/sgi/Makefile |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/src/glu/sgi/Makefile b/src/glu/sgi/Makefile
index c8b29ed..94427e2 100644
--- a/src/glu/sgi/Makefile
+++ b/src/glu/sgi/Makefile
@@ -124,12 +124,7 @@ OBJECTS = $(C_OBJECTS) $(CC_OBJECTS)
# TARGETS #
default:
- @if [ "${CONFIG_NAME}" = "beos" ] ; then \
- echo "$(GLU_LIB_NAME) not build under BeOS, but integrated into
${GL_LIB_NAME}." ; \
- exit 0 ; \
- else \
- $(MAKE) $(TOP)/$(LIB_DIR)/$(GLU_LIB_NAME) || exit 1 ; \
- fi
+ $(MAKE) $(TOP)/$(LIB_DIR)/$(GLU_LIB_NAME) || exit 1 ; \
$(TOP)/$(LIB_DIR):
-mkdir $(TOP)/$(LIB_DIR)
--
1.7.7.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] gallium: include mapi headers which are utilized. fixes no-makedepend Haiku build
--- src/gallium/drivers/r300/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/gallium/drivers/r300/Makefile b/src/gallium/drivers/r300/Makefile index 5f56fc4..3e3a765 100644 --- a/src/gallium/drivers/r300/Makefile +++ b/src/gallium/drivers/r300/Makefile @@ -15,6 +15,7 @@ C_SOURCES += \ LIBRARY_INCLUDES = \ -I$(TOP)/include \ -I$(TOP)/src/mesa \ + -I$(TOP)/src/mapi \ -I$(TOP)/src/glsl include ../../Makefile.template -- 1.7.7.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Replace RENDERINPUTS with direct GLbitfield64 usage.
Hi, On Tuesday, December 27, 2011 00:37:13 Brian Paul wrote: > For the series: > Reviewed-by: Brian Paul Thanks. What is your preference to do with the remaining bitset.h header? * Remove this as ununsed? * Remove the 64 bit bitset implementation as this could be better done with GLbitfield64 and leave the unlimited bitset there? * Keep it as a whole? Greetings Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Help required in configuring mesa 3d in non X environment.
Hi, As per my project requirement (Safety critical DO-178B), i have a box HPCN8641D (ppc) fitted with PCI-E radeon gpu e4690. I have already back ported kernel DRM module from 2.6.35.3 to 2.6.23 (Pre-installed in machine). I wanted to run mesa 3D application in it. While trying to compile mesa 3d with config linux-fbdev (kernel 3d acceleration enabled), it bails out giving X server libraries/header dependency. Is it possible to compile mesa without X server libraries/header ? If yes, can you please name the configuration to be used ? I tried to follow the steps mentioned in below link. But i guess the config (linux-solo) was removed in later mesa3d release. http://www.mesa3d.org/fbdev-dri.html Any help appreciated. Thanks Sanjoy ::DISCLAIMER:: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. --- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] mesa: simplify Driver.TexSubImage() parameters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/26/2011 03:09 PM, Brian Paul wrote: > From: Brian Paul > > There's no need to pass the target, level and texObj parameters since > they can be easily obtained from the texImage pointer. > --- > src/mesa/drivers/common/meta.c | 18 +- > src/mesa/drivers/dri/intel/intel_tex_subimage.c | 31 ++-- > src/mesa/drivers/dri/nouveau/nouveau_texture.c | 45 > +++ > src/mesa/main/dd.h | 44 > +++ > src/mesa/main/mipmap.c |5 +-- > src/mesa/main/teximage.c| 15 +++- > src/mesa/main/texstore.c| 21 +-- > src/mesa/main/texstore.h| 21 +-- > 8 files changed, 89 insertions(+), 111 deletions(-) I didn't review everything, since much of the change was mechanical. A clean build with the patches applied didn't generate additional warnings, so I assume all is good with this series. For the series, Reviewed-by: Chad Versace - Chad Versace chad.vers...@linux.intel.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJO+gfpAAoJEAIvNt057x8ioioP/2Gl1GgpZXZ1bvwYOTEBMsgo hyoOPYaXKbY97HJWMCglqdLUSB6WVQREa/HFErT1G+0TW77PaM3ypnuONTKB15gZ XyWwqV/TrEsda1Ibydu+fI2wduGy2Pac18MASsWD6vIIJuSKdcS5mjnyFagtJ+BH eTevdwBXX635siStp46kmIalRZ2xWTRMalzDD6RANB/JaZ4giEB6q3YSbMlW8TKw g03J1K53njltEq0IYjgjOynmsJhnu1AK98511ttLQxwKxuG5tuSrBkU4ncDkWlJF QoT7pRBN84zIrUCHPrrUOVnzN0ec8ieuIFlsJOFone8CfJs28sDKdWOl8Ou39Sl0 RQPhAriwHrEYUvXUWnVxVAUPUC0c9VkQGzFVAQqUvAJn6FEAxQmyXk0DS+GOm6kk 5q3W5kxwh0hx+MMRpKjt4X/w/B177WbVa2DMFWzlXy536ignPESJm2bzBMUFEkd7 gNYOHIIo+s0KBdG8dEHFSlGiMDyxTPaODKJG1PgWjcQ71r9OgrfjClxfvx8C0CMC N43INvqSD4BCFGuPYdXITncd2oshJtTQiTYdRYALiqgjs24VoGXLS3o0M9l7RKHt 3UCG05jcJxuZOZS+qd4yZloayealzsrn1qJz753RCgo+R6w2GZSs13TaT1TbFTYN njLC4flMlHVJxmScKU93 =+MGV -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel: Fix memory leak in intel_miptree_create()
On failure, intel_miptree_create() needs to *release* the miptree, not
just free it, so that the stencil_mt gets released too.
CC: Eric Anholt
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index e0f9632..00a81ca 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -204,7 +204,7 @@ intel_miptree_create(struct intel_context *intel,
* pitch == 0 || height == 0 indicates the null texture
*/
if (!mt || !mt->total_width || !mt->total_height) {
- free(mt);
+ intel_miptree_release(&mt);
return NULL;
}
@@ -216,7 +216,7 @@ intel_miptree_create(struct intel_context *intel,
expect_accelerated_upload);
if (!mt->region) {
- free(mt);
+ intel_miptree_release(&mt);
return NULL;
}
--
1.7.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] gallium: include mapi headers which are utilized. fixes no-makedepend Haiku build
On 27.12.2011 10:31, Brian Paul wrote: On Tue, Dec 27, 2011 at 8:40 AM, Alexander von Gluck wrote: --- src/gallium/drivers/r300/Makefile | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/gallium/drivers/r300/Makefile b/src/gallium/drivers/r300/Makefile index 5f56fc4..3e3a765 100644 --- a/src/gallium/drivers/r300/Makefile +++ b/src/gallium/drivers/r300/Makefile @@ -15,6 +15,7 @@ C_SOURCES += \ LIBRARY_INCLUDES = \ -I$(TOP)/include \ -I$(TOP)/src/mesa \ + -I$(TOP)/src/mapi \ -I$(TOP)/src/glsl include ../../Makefile.template -- That file no longer exists in Mesa/master. Are you sure you're patching against the latest sources from git? I checked and can confirm this issue still exists in master.. gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -I../../../../include -I../../../../src/mesa -I../../../../src/glsl -Wall -Wno-multichar -DBEOS_THREADS -DGNU_ASSEMBLER -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -fno-strict-aliasing -std=c99 -O3 ../../../../src/mesa/program/register_allocate.c -o ../../../../src/mesa/program/register_allocate.o In file included from ../../../../src/mesa/program/register_allocate.c:77:0: ../../../../src/mesa/main/mtypes.h:40:25: fatal error: glapi/glapi.h: No such file or directory compilation terminated. make[5]: *** [../../../../src/mesa/program/register_allocate.o] Error 1 make[5]: Leaving directory `/Data/mesa/src/gallium/drivers/r300' make[4]: *** [default] Error 1 make[4]: Leaving directory `/Data/mesa/src/gallium/drivers' make[3]: *** [default] Error 1 make[3]: Leaving directory `/Data/mesa/src/gallium' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/Data/mesa/src' make[1]: *** [default] Error 1 make[1]: Leaving directory `/Data/mesa' make: *** [haiku] Error 2 The r300 driver builds ../../../../src/mesa/program/register_allocate.c which needs it. Thanks! -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Fix memory leak in intel_miptree_create()
On Tue, 27 Dec 2011 10:16:05 -0800, Chad Versace wrote: > On failure, intel_miptree_create() needs to *release* the miptree, not > just free it, so that the stencil_mt gets released too. Reviewed-by: Eric Anholt pgp08hQgpuu1T.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] vbo: count min/max_index before vbo->draw_prims
On Sun, 25 Dec 2011 12:26:25 +0800, Liu Aleaxander wrote:
> On Sun, Dec 25, 2011 at 8:03 AM, Eric Anholt wrote:
> > On Thu, 22 Dec 2011 18:55:50 +0800, Yuanhan Liu
> > wrote:
> >> For the case that index data is stored in element array buffer object,
> >> and user called glMultiDrawElements, count the min/max_index before
> >> calling vbo->draw_prims. vbo_get_minmax_index() isn't friendly to this
> >> case. So do it while building the prim info.
> >>
> >> Signed-off-by: Yuanhan Liu
> >
> > I'm really failing to understand what this commit is for. Does it fix
> > some testcase?
>
> Sorry, my bad. I should note something more about this issue. And
> yes, it does fixes something. Say for following case:
>
> GLubyte indices_data[] = {0, 1, 2, 3, 4, 5, 6,1, 7, 8, 9, 10, 11};
> GLsizei count[] = {7, 6}
> GLvoid * indices_off[2] = {0, 7};
>
> /* here copy the indices data into Element Array Buffer Object */
> .glBind..glBufferData
>
> /* Here call glMulitDrawElements */
> glMultiDrawElements(GL_LINE_STRIP, count,
> GL_UNSIGNED_BYTE,
> indices_off, 2);
>
> The current code in brw_draw.c would just count the min_index
> and max_index of the first prim, thus got a min_index of 0, and
> max_index of 6. This is not right, thus the second prim(and any
> later, if you have more than 2 prim to render) rendered incorrectly.
>
> I found it's a little ugly to add those code similar in this patch at
> brw_draw_prims(), then I figured out a way to add it at the caller,
> vbo_validated_multidrawelements(). I guess it's reasonable, since
> the prim info is built at there.
What about when the next caller that does multiple primitives comes
along. Would you add workaround code to it too? Please fix the actual
broken code in brw_draw.c instead.
This would be a good time to check for the same breakage in other
callers of vbo_get_minmax_index(), and see if we want a function that
does this multi-primitive vbo_get_minmax_index() logic.
pgp1kdCclQUBa.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 1/3] i965/vs: Fix incorrect subscript when resetting copy propagation records.
On Fri, 23 Dec 2011 20:57:46 -0800, Kenneth Graunke wrote: > In this code, 'i' loops over the number of virtual GRFs, while 'j' loops > over the number of vector components (0 <= j <= 3). > > It can't possibly be correct to see if bit 'i' is set in the destination > writemask, as it will have values much larger than 3. Clearly this is > supposed to be 'j'. > > Found by inspection. Yeah, making a runtime test for this one would suck. Reviewed-by: Eric Anholt pgpDUd5Ti1Lqq.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 1/4] mesa: simplify Driver.TexSubImage() parameters
On Mon, 26 Dec 2011 16:09:35 -0700, Brian Paul wrote: > From: Brian Paul > > There's no need to pass the target, level and texObj parameters since > they can be easily obtained from the texImage pointer. This series is: Reviewed-by: Eric Anholt pgpgksR1zxWzi.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] New gallium-clip-state branch
Hi everyone, There is a new branch gallium-clip-state in the main Mesa repository. It implements the changes we agreed upon, i.e. moving state enables from clip_state into rasterizer_state. A nice cleanup comes with it: cso_save_clip and cso_restore_clip are no longer needed anywhere. There is one regression in Draw which I haven't been able to find a fix for yet. There's more info here: http://cgit.freedesktop.org/mesa/mesa/commit/?h=gallium-clip-state&id=e37465327c79a01112f15f6278d9accc5bf3103f Other than that, there should be no regression in the drivers which have been adapted to the new interface already. I have tested softpipe, llvmpipe, and r300g with and without HWTCL. I'll test r600g when I get back to my machine with an r600. The only unported drivers are the Nouveau ones. I assume Christoph will want to do that. If not, I'll do it. Once it's done, the branch will be squash-merged into master. Feel free to review and raise concerns. Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43317] swrast: glean basic sanity fails
https://bugs.freedesktop.org/show_bug.cgi?id=43317 --- Comment #3 from Nicholas Miell 2011-12-27 18:43:03 PST --- This appears to be a piglit/glean bug -- it's calling XDestroyWindow on the window currently bound to the GLX context and the subsequent glXMakeCurrent call is calling XPutImage on a window that no longer exists. I suppose glXMakeCurrent should be generating a GLXBadCurrentWindow error here. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] vbo: introduce vbo_sizeof_ib_type() function
introduce vbo_sizeof_ib_type() function to return the index data type
size. I see some place use switch(ib->type) to get the index data type,
which is sort of duplicate.
Signed-off-by: Yuanhan Liu
---
src/mesa/state_tracker/st_draw.c | 15 +
src/mesa/state_tracker/st_draw_feedback.c | 17 ++
src/mesa/tnl/t_draw.c | 20 +--
src/mesa/vbo/vbo.h|4 ++
src/mesa/vbo/vbo_exec_array.c | 52 ++--
5 files changed, 29 insertions(+), 79 deletions(-)
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index 87a9978..954f15a 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -584,20 +584,7 @@ setup_index_buffer(struct gl_context *ctx,
if (ib) {
struct gl_buffer_object *bufobj = ib->obj;
- switch (ib->type) {
- case GL_UNSIGNED_INT:
- ibuffer->index_size = 4;
- break;
- case GL_UNSIGNED_SHORT:
- ibuffer->index_size = 2;
- break;
- case GL_UNSIGNED_BYTE:
- ibuffer->index_size = 1;
- break;
- default:
- assert(0);
-return;
- }
+ ibuffer->index_size = vbo_sizeof_ib_type(ib->type);
/* get/create the index buffer object */
if (_mesa_is_bufferobj(bufobj)) {
diff --git a/src/mesa/state_tracker/st_draw_feedback.c
b/src/mesa/state_tracker/st_draw_feedback.c
index 4c1e674..a99eb2b 100644
--- a/src/mesa/state_tracker/st_draw_feedback.c
+++ b/src/mesa/state_tracker/st_draw_feedback.c
@@ -218,20 +218,9 @@ st_feedback_draw_vbo(struct gl_context *ctx,
if (ib) {
struct gl_buffer_object *bufobj = ib->obj;
- switch (ib->type) {
- case GL_UNSIGNED_INT:
- ibuffer.index_size = 4;
- break;
- case GL_UNSIGNED_SHORT:
- ibuffer.index_size = 2;
- break;
- case GL_UNSIGNED_BYTE:
- ibuffer.index_size = 1;
- break;
- default:
- assert(0);
-goto out_unref_vertex;
- }
+ ibuffer.index_size = vbo_sizeof_ib_type(ib->type);
+ if (ibuffer.index_size == 0)
+ goto out_unref_vertex;
if (bufobj && bufobj->Name) {
struct st_buffer_object *stobj = st_buffer_object(bufobj);
diff --git a/src/mesa/tnl/t_draw.c b/src/mesa/tnl/t_draw.c
index 83ded19..f949c34 100644
--- a/src/mesa/tnl/t_draw.c
+++ b/src/mesa/tnl/t_draw.c
@@ -349,26 +349,10 @@ static void bind_indices( struct gl_context *ctx,
if (_mesa_is_bufferobj(ib->obj) && !_mesa_bufferobj_mapped(ib->obj)) {
/* if the buffer object isn't mapped yet, map it now */
- unsigned map_size;
-
- switch (ib->type) {
- case GL_UNSIGNED_BYTE:
-map_size = ib->count * sizeof(GLubyte);
-break;
- case GL_UNSIGNED_SHORT:
-map_size = ib->count * sizeof(GLushort);
-break;
- case GL_UNSIGNED_INT:
-map_size = ib->count * sizeof(GLuint);
-break;
- default:
-assert(0);
-map_size = 0;
- }
-
bo[*nr_bo] = ib->obj;
(*nr_bo)++;
- ptr = ctx->Driver.MapBufferRange(ctx, (GLsizeiptr) ib->ptr, map_size,
+ ptr = ctx->Driver.MapBufferRange(ctx, (GLsizeiptr) ib->ptr,
+ ib->count *
vbo_sizeof_ib_type(ib->type),
GL_MAP_READ_BIT, ib->obj);
assert(ib->obj->Pointer);
} else {
diff --git a/src/mesa/vbo/vbo.h b/src/mesa/vbo/vbo.h
index 7384790..ed8fc17 100644
--- a/src/mesa/vbo/vbo.h
+++ b/src/mesa/vbo/vbo.h
@@ -122,6 +122,10 @@ void vbo_rebase_prims( struct gl_context *ctx,
GLuint min_index,
GLuint max_index,
vbo_draw_func draw );
+
+int
+vbo_sizeof_ib_type(GLenum type);
+
void
vbo_get_minmax_index(struct gl_context *ctx, const struct _mesa_prim *prim,
const struct _mesa_index_buffer *ib,
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 2db85e2..fec49d3 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -75,6 +75,22 @@ vbo_check_buffers_are_unmapped(struct gl_context *ctx)
assert(!_mesa_bufferobj_mapped(exec->vtx.bufferobj));
}
+int
+vbo_sizeof_ib_type(GLenum type)
+{
+ switch (type) {
+ case GL_UNSIGNED_INT:
+ return sizeof(GLuint);
+ case GL_UNSIGNED_SHORT:
+ return sizeof(GLushort);
+ case GL_UNSIGNED_BYTE:
+ return sizeof(GLubyte);
+ default:
+ assert(!"unsupported index data type");
+ /* In case assert is turned off */
+ return 0;
+ }
+}
/**
@@ -96,24 +112,8 @@ vbo_get_minmax_index(struct gl_context *ctx,
GLuint i;
if (_mesa_is_bufferobj(ib->obj)) {
- unsigned map_size;
-
- switch (ib->type) {
- case GL_UNSIGNED_INT:
-map_size = count * sizeof(GLuint);
-break;
- case GL_UNSIGNED_SHORT:
-map_size = count * sizeof(
[Mesa-dev] [PATCH 2/2] i965: fix the wrong min/max_index for nr_prims > 1
The current code would just calculate min/max_index for the first prim
unconditionally, which is wrong if nr_prims > 1.
This would some cases like that the index is stored in element array
buffer object and drawing by glMultiDrawEelements. Thus it fixes some
intel oglc primbuff test cases.
Signed-off-by: Yuanhan Liu
---
src/mesa/drivers/dri/i965/brw_draw.c | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index 621195d..3d0cc7c 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -585,8 +585,22 @@ void brw_draw_prims( struct gl_context *ctx,
return;
if (!vbo_all_varyings_in_vbos(arrays)) {
- if (!index_bounds_valid)
-vbo_get_minmax_index(ctx, prim, ib, &min_index, &max_index);
+ if (!index_bounds_valid) {
+ struct _mesa_index_buffer tmp_ib;
+ GLuint tmp_min, tmp_max;
+ int i;
+
+ min_index = ~0;
+ max_index = 0;
+ tmp_ib = *ib;
+
+ for (i = 0; i < nr_prims; i++) {
+ tmp_ib.ptr = ib->ptr + prim[i].start *
vbo_sizeof_ib_type(ib->type);
+ vbo_get_minmax_index(ctx, &prim[i], &tmp_ib, &tmp_min, &tmp_max);
+ min_index = MIN2(min_index, tmp_min);
+ max_index = MAX2(max_index, tmp_max);
+ }
+ }
/* Decide if we want to rebase. If so we end up recursing once
* only into this function.
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vbo: count min/max_index before vbo->draw_prims
On Tue, Dec 27, 2011 at 11:15:42AM -0800, Eric Anholt wrote:
> On Sun, 25 Dec 2011 12:26:25 +0800, Liu Aleaxander
> wrote:
> > On Sun, Dec 25, 2011 at 8:03 AM, Eric Anholt wrote:
> > > On Thu, 22 Dec 2011 18:55:50 +0800, Yuanhan Liu
> > > wrote:
> > >> For the case that index data is stored in element array buffer object,
> > >> and user called glMultiDrawElements, count the min/max_index before
> > >> calling vbo->draw_prims. vbo_get_minmax_index() isn't friendly to this
> > >> case. So do it while building the prim info.
> > >>
> > >> Signed-off-by: Yuanhan Liu
> > >
> > > I'm really failing to understand what this commit is for. Does it fix
> > > some testcase?
> >
> > Sorry, my bad. I should note something more about this issue. And
> > yes, it does fixes something. Say for following case:
> >
> > GLubyte indices_data[] = {0, 1, 2, 3, 4, 5, 6,1, 7, 8, 9, 10, 11};
> > GLsizei count[] = {7, 6}
> > GLvoid * indices_off[2] = {0, 7};
> >
> > /* here copy the indices data into Element Array Buffer Object */
> > .glBind..glBufferData
> >
> > /* Here call glMulitDrawElements */
> > glMultiDrawElements(GL_LINE_STRIP, count,
> > GL_UNSIGNED_BYTE,
> > indices_off, 2);
> >
> > The current code in brw_draw.c would just count the min_index
> > and max_index of the first prim, thus got a min_index of 0, and
> > max_index of 6. This is not right, thus the second prim(and any
> > later, if you have more than 2 prim to render) rendered incorrectly.
> >
> > I found it's a little ugly to add those code similar in this patch at
> > brw_draw_prims(), then I figured out a way to add it at the caller,
> > vbo_validated_multidrawelements(). I guess it's reasonable, since
> > the prim info is built at there.
>
> What about when the next caller that does multiple primitives comes
> along.
We don't have the next caller besides glMultiDrawElements* _for_now_ , right?
> Would you add workaround code to it too? Please fix the actual
> broken code in brw_draw.c instead.
Yes, anyway, you are right. I sent out a patch to fix this issue in
brw_draw_prims(). And I found it isn't that ugly to fix it at there as I
tought. ;)
Thanks,
Yuanhan Liu
>
> This would be a good time to check for the same breakage in other
> callers of vbo_get_minmax_index(), and see if we want a function that
> does this multi-primitive vbo_get_minmax_index() logic.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
