#x27;t actually rely on any such functionality, so this
is going to be okay for us.
Acked-by: Tom Fogal
Thanks,
-tom
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 02/16/2012 01:57 AM, Zhigang Gong wrote:
-Original Message-
From: tf (mobile) [mailto:tfo...@sci.utah.edu]
Sent: Wednesday, February 15, 2012 8:53 PM
To: zhigang.g...@linux.intel.com
Cc: dbn.li...@gmail.com; nob...@dreamwidth.org;
mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev]
On 02/15/2012 05:15 PM, Matt Turner wrote:
On Wed, Feb 15, 2012 at 7:52 AM, tf (mobile) wrote:
Even if the system supports tls, the x server may not have been built with it.
As i recall, there is an issue with mismatching tls between x and drivers...
Can a non-tls server load a tls driver?
On 11/11/2011 02:54 PM, Ian Romanick wrote:
On 11/02/2011 12:48 PM, Ian Romanick wrote:
On 11/02/2011 12:04 PM, tom fogal wrote:
It's been three months since 7.11 came out. Have there been any
thoughts on a 7.11.1 release date?
"Soon." After the last big round of cherry pic
Kenneth Graunke writes:
> On 11/02/2011 11:14 AM, tom fogal wrote:
> > Ping?
>
> You'll probably want to open a bug report on this just so it doesn't
> get lost.
Okay.
https://bugs.freedesktop.org/show_bug.cgi?id=42538
> Sorry it's been taking so long.
No
It's been three months since 7.11 came out. Have there been any
thoughts on a 7.11.1 release date?
Also, any qualms about me cherry-picking the 'NormalMatrix' fix below
into 7.11?
Thanks,
-tom
commit cc4ddc3a1e4bbe5fccd03b39b3590368be8c172f
Author: Eric Anholt
Date: Tue Oct 18 17:17:28 2011
Ping?
-tom
tom fogal writes:
> Hi all,
>
> Our application has a render mode which is causing a
> Sandybridge-based system to hang for a second with Mesa master. In
> dmesg I see:
>
> [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
> [
Hi all,
Our application has a render mode which is causing a Sandybridge-based
system to hang for a second with Mesa master. In dmesg I see:
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[drm:i915:do_wait_request] *ERROR* i915_do_wait_request returns -11 (awaiting
I had a colleague hitting issues compiling with an old gcc3.2
system. These patches got them through.
---
include/GL/gl.h |2 +-
src/mesa/main/compiler.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/GL/gl.h b/include/GL/gl.h
index 998a83a..e65e1bc
Not sure this needs it, but LGTM. You might want to add yourself to the
"Authors" comment, but *shrug*.
-tom
On 10/18/2011 06:33 PM, Eric Anholt wrote:
From: tom fogal
v2: lots of hacking by anholt to make it look more like a normal
piglit test and make all results visib
*ping*. Anything to be done on my end? -tom
tom fogal writes:
> --- =_aa0
> Content-Type: text/plain; charset="us-ascii"
> Content-ID: <27394.131845620...@shigeru.sci.utah.edu>
>
> Hi Ian, Kenneth,
>
> Ian Romanick writes:
> > On 10/1
Hi Ian, Kenneth,
Ian Romanick writes:
> On 10/10/2011 03:30 PM, tom fogal wrote:
> > One of our programs which relies on shaders heavily is having
> > issues, and I have tracked it down to unexpected values in
> > gl_NormalMatrix within the fragment shader.
>
> I
*ping* any review?
Dan, I think you're probably the best to review this, if you have a
minute.
-tom
tfo...@sci.utah.edu writes:
> From: Tom Fogal
>
> In addition to setting up the flags correctly, this renames the
> generated libraries to ensure they get 'Mangled'
Ian Romanick writes:
> On 10/10/2011 03:30 PM, tom fogal wrote:
> > One of our programs which relies on shaders heavily is having
> > issues, and I have tracked it down to unexpected values in
> > gl_NormalMatrix within the fragment shader.
> >
> > Using th
dge Desktop GEM 20100330 DEVELOPMENT
GL_VERSION: 2.1 Mesa 7.10.2
>From 'dmesg', I gather the GPU is an i915.
Is this a known issue? Any workarounds available? Anything else I
could do to help debug?
Thanks,
-tom
From c4b3d54e4d0ca991b8d76a4391d9c820fbb22747 Mon Sep 17 00:00:00 200
> char* ext = glGetString(GL_VENDOR);
>
> doesn't require a cast on IRIX, while the same code would require a cast
> using other compilers due to the aforementioned problem.
>
> Patrick
>
>
> On Tue, Jul 19, 2011 at 1:44 PM, Allen Akin wrote:
>
> > On T
Hi all,
This isn't quite the right place for this question, but I've searched
through old standards and googled without any luck, so hopefully
somebody here knows the history behind GLubyte*.
glGetString and gluErrorString, plus maybe some other functions, return
GLubyte pointers instead of simpl
Ian Romanick writes:
> On 06/21/2011 10:58 AM, tom fogal wrote:
> > Michel D=C3=A4nzer writes:
> >>>> It should work fine with Xvfb or any other X server, using any
> >>>> kind of display connection.
> >>>
> >>> This threa
Michel Dänzer 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:
> > >&g
On 06/21/2011 10:23 AM, Michel Dänzer wrote:
On Die, 2011-06-21 at 10:10 -0600, tom fogal wrote:
On 06/21/2011 01:06 AM, Michel Dänzer wrote:
On Mon, 2011-06-20 at 13:46 -0600, tom fogal wrote:
Nathan Kidd writes:
On 11-06-20 02:55 PM, tom fogal wrote:
Nathan Kiddwrites:
[snip]
You
On 06/21/2011 01:06 AM, Michel Dänzer wrote:
On Mon, 2011-06-20 at 13:46 -0600, tom fogal wrote:
Nathan Kidd writes:
On 11-06-20 02:55 PM, tom fogal wrote:
Nathan Kidd writes:
[snip]
You are correct, rendering is indirect!
Of course, for indirect rendering every glFoo() function call
Nathan Kidd writes:
> On 11-06-20 02:55 PM, tom fogal wrote:
> > Nathan Kidd writes:
[snip]
> > You are correct, rendering is indirect! I was unaware that direct
> > vs. indirect limited *GL* features. Why is that the case, and what
> > can be done?
>
> Of cou
, maybe softpipe in the future;
I'm obviously not concerned with speed, I just need something that
supports some extensions for use in a regression testing system.
Thanks,
-tom
> 2011/6/20 tom fogal :
> > I am trying to get some regression tests to run in Xvfb. =C2=A0On my
> &g
Nathan Kidd writes:
> On 11-06-20 01:22 PM, tom fogal wrote:
> > I am trying to get some regression tests to run in Xvfb. On my
> > workstation, the GL_VERSION string from this is:
> >
> >1.4 (2.1 Mesa 7.7.1)
[snip]
> > In any case, the above version strin
I am trying to get some regression tests to run in Xvfb. On my
workstation, the GL_VERSION string from this is:
1.4 (2.1 Mesa 7.7.1)
according to glxinfo. The extensions fairly clearly show 2.x features.
Is it perhaps the case that 2.1 features were available in 7.7.1, but
not /all/ 2.1 featu
On 04/26/2011 06:00 AM, Jon TURNEY wrote:
Looking at this bit of autofoolery, I notice that at the moment it is just
checking if CC supports -fvisibility=hidden twice
We use visibility=hidden for *both* C and C++ code, no?
Is the issue that the Cygwin C compiler supports hidden visibility, and
On 04/18/2011 05:48 PM, tom fogal wrote:
Anyway, libxml2 is a bit arduous for us because it's not installed by
default on Linux or Mac.
... Windows or Mac, of course.
-tom
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
Hey all,
We recently became more aware of a dependency on python's libxml2 for
building Mesa. We're not as proactive as we should be, but tend to
upgrade Mesa every few releases; I think this was a jump from 7.8 to 7.10.
Anyway, libxml2 is a bit arduous for us because it's not installed by
Nobody has one. I don't think there are many java users in this
community. You should probably query the jogl community.
Otherwise, I think you're stuck hooking it up yourself.
-tom
On 03/25/2011 06:34 AM, Morris Ford wrote:
I am looking for assistance in getting a java jogl app set up to u
Kenneth Graunke writes:
> On Thursday, March 10, 2011 01:17:04 PM Alexander Neundorf wrote:
> > While at it (sorry for newbie questions), do I need gallium (maybe
> > swrast) when I want only osmesa rendering into a software buffer ?
>
> I don't think OSMesa requires Gallium, but I've never used i
Chia-I Wu writes:
> On Mon, Feb 21, 2011 at 8:12 PM, Tom Fogal wrote:
> > From: Tom Fogal
> >
> > Without this, we do not actually respect the request for TLS.
>
> What is your setup?
./configure \
CFLAGS="-g -DUSE_MGL_NAM
From: Tom Fogal
Without this, we do not actually respect the request for TLS.
---
src/mapi/glapi/Makefile |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/mapi/glapi/Makefile b/src/mapi/glapi/Makefile
index bb4ed65..60b0963 100644
--- a/src/mapi/glapi/Makefile
Andy Furniss writes:
> I've just had to rm -r and re-clone because I couldn't find how to
> distclean :-).
"git clean -df" makes things pretty clean ;)
I don't think I know how to distclean in cmake either... the workaround
for cmake is to just use out of source builds. Then "clean... no, i
*me
Magnus Granberg writes:
> This patch add new configure options to enable readonly text segments
> for x86 For any apps that use any libGL with writeble text segments
> on x86 with a Grsec/PaX/Selinux enable kernel get killed with cannot
> make segment writable for relocation: Permission denied. Th
Benoit Jacob writes:
>
> - Original Message -
> > Benoit Jacob wrote:
> > > - Original Message -
> > >> On Thu, Feb 3, 2011 at 4:37 PM, Benoit Jacob
> > >> wrote:
> > >>> I'm trying to see how to implement selective
> > >>> whitelisting/blacklisting of driver versions on X11 (my
Benoit Jacob wrote:
- Original Message -
On Thu, Feb 3, 2011 at 4:37 PM, Benoit Jacob
wrote:
I'm trying to see how to implement selective
whitelisting/blacklisting of driver versions on X11 (my use case is
to whitelist drivers for Firefox). The naive approach consists in
creating an Op
Tobias Jakobi wrote:
Some further testing shows that the LDFLAGS seem to cause the problem.
More specifically the '--as-needed' which is passed to the linker.
As needed should probably be removed from the link line when we're
linking with g++.
Last I looked into such issues, I found that the
Dan Nicholson writes:
> On Sun, Jan 9, 2011 at 2:32 PM, tom fogal wrote:
> > Ping!
> >
> > No NAKs in ~5 days and one explicit request (on xorg-devel):
> >
> > =C2=A0http://permalink.gmane.org/gmane.comp.freedesktop.xorg.devel/17570
> >
> > Okay for
Ping!
No NAKs in ~5 days and one explicit request (on xorg-devel):
http://permalink.gmane.org/gmane.comp.freedesktop.xorg.devel/17570
Okay for master, and (after settling) 7.10?
-tom
tfo...@sci.utah.edu wrote:
From: Tom Fogal
If nothing else, this would be useful for debugging TLS
Alan Coopersmith writes:
> On 12/30/10 09:27 AM, tom fogal wrote:
> > Alan Coopersmith writes:
> >> -GLEW_CFLAGS=""
> >> -GLEW_LIBS="-lGLEW"
> >> dnl Include a fallback path for GLEW for the moment while not all distros
> >> dnl
Alan Coopersmith writes:
> configure --help says that builders can set those variables to override
> pkgconfig settings, but configure.ac was overwriting those before calling
> PKG_CHECK_MODULES
>
> Signed-off-by: Alan Coopersmith
> ---
> configure.ac |8 +++-
> 1 files changed, 3 inser
Dan Nicholson writes:
> On Wed, Dec 22, 2010 at 3:18 PM, tom fogal wrote:
> > Alan Coopersmith writes:
> >> On 12/22/10 02:30 PM, tom fogal wrote:
> >>
> >> We generally don't copy macros from the autoconf-archive into
> >> xorg-macros, [.
Alan Coopersmith writes:
> On 12/22/10 02:30 PM, tom fogal wrote:
>
> We generally don't copy macros from the autoconf-archive into
> xorg-macros, we just use them as is - adding *.m4 files to
> packages that need them (especially when it's just one or two
> packa
00:00 2001
From: Tom Fogal
Date: Wed, 22 Dec 2010 14:34:55 -0700
Subject: [PATCH] Add macro for detecting thread local storage support.
This adds an XORG_TLS macro which attempts to identify if the
underlying compiler/platform supports thread local storage (TLS).
It also increases the package ver
Jose Fonseca writes:
> I can remove python2.6 dependency as you suggest, but although this
> new string formatting method is seldom used it actually makes the
> code much more readable and I was hoping to spread its use, so I'd
> like you to try one thing first before giving it up:
I agree that i
Hi José,
José Fonseca wrote:
FYI, I've extended my apitrace project to be able not only to show a
list of GL calls, but also replay them.
Neat!
The idea is to facilitate reproduction of bugs, help finding
regressions, and do it across different platforms.
Code is in
http://cgit.freedesktop
Eric Anholt writes:
> On Sun, 05 Dec 2010 18:04:54 -0700, tom fogal wrote:
> > More background:
> >
> > http://www.mail-archive.com/mesa3d-...@lists.sourceforge.net/msg12473.html
> > http://lists.x.org/archives/xorg-devel/2009-November/003411.html
> >
>
ep 17 00:00:00 2001
From: Tom Fogal
Date: Sun, 5 Dec 2010 17:58:32 -0700
Subject: [PATCH] Export TLS support in gl.pc.
X server will want to know if the driver is TLS-enabled.
---
configs/autoconf.in |1 +
configure.ac|8 +++-
src/mesa/Makefile |1 +
src/mesa/gl.pc.in |
Brian Paul writes:
> Have you tried 7.9? If there are rasterization or other issues w/
> 7.9 can you file bug reports?
Seems to basically work. Our test suite hung 20% of the way through
last night, and about half the tests that did run crashed. The ones
that ran okay do not seem to have pixel
tom fogal writes:
> Brian Paul writes:
> > On 08/23/2010 10:12 AM, tom fogal wrote:
> > > Anyway the point of this mail is that I'd like to push whomever
> > > does these things (Ian?) to create a 7.8.3 release.
> >
> > Tom, I'll merge your bran
Ian Romanick writes:
> Brian Paul wrote:
> > On 10/12/2010 07:49 PM, Ian Romanick wrote:
> >> Brian Paul wrote:
> -
> +#include
> >>>
> >>> Ian, could we stick with GLboolean/GL_TRUE/GL_FALSE in core Mesa to be
> >>> consistent?
> >>
> >> If possible, I'd prefer not. [. . .]
> >
> > My
José Fonseca writes:
> What you guys feel about anonymous unions?
>
> I happened to committed some code with anonymous unions, but it
> caused gcc to choke when -std=c99 option is specified, which is only
> specified with automake but scons.
>
> After some search, it looks like anonymous unions a
Tom Stellard wrote:
On Sat, Oct 02, 2010 at 11:01:49AM -0700, Ian Romanick wrote:
Vinson Lee wrote:
Author: Vinson Lee
Date: Wed Sep 29 13:30:34 2010 -0700
r300/compiler: Move declaration before code.
Fixes these GCC warning on linux-x86 build.
radeon_optimize.c: In function constant_fol
Kenneth Graunke writes:
> On Thursday 30 September 2010 12:22:37 tom fogal wrote:
> > Jos=C3=A9 Fonseca writes:
> > > I didn't test but looks fine to me. Please commit.
> >
> > Thanks.
> >
> > The merge of 7.8 into master was complex at best,
José Fonseca writes:
> I didn't test but looks fine to me. Please commit.
Thanks.
The merge of 7.8 into master was complex at best, so I pushed 7.8 and
then cherry-picked the commits to master. Hope that's okay..
-tom
> On Wed, 2010-09-29 at 12:37 -0700, tom fogal
ping?
-tom
tom fogal writes:
> A friend of mine had trouble building 7.8.2 on an old gcc3.3 system
> (no gcc intrinsics). I put together this patch and he said his build
> worked. Our software doesn't thread so it's not really verified
> otherwise.
>
> I was a
son_of_the_osi...@interia.pl writes:
> >Older nvidia cards implement GL_EXT_paletted_texture in hw. I just
> started to
> >playing with this on nv11
>
> So when we could play with GL_EXT_paletted_texure and
> GL_ARB/EXT_texture_cube_maps ??? vdrift dont work with the current
> nouveau driver
Uhh.. also, were we not using the intrinsics on x86 before?
Attached checks intrinsics before x86 and the new x86_64 block, so
that the latter are fallbacks if intrinsics aren't available.
-tom
tom fogal writes:
> A friend of mine had trouble building 7.8.2 on an old gcc3.3 system
&
4.
Maybe that's needed in general, but just not in swrast / under Mesa w/
our particular option set?
Anyway, okay for 7.8 and master?
-tom
From cc32ff741c5d32a66531a586b1f9268b94846c58 Mon Sep 17 00:00:00 2001
From: Tom Fogal
Date: Sun, 26 Sep 2010 18:57:59 -0600
Subject: [PATCH] Implemen
"C. Comren" writes:
> Unasked for events from GLX are bugging me. It was fixed in
>
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=f8d81c31cee30821da3aab331a57
> f484f6a07a5d
>
> However, this commit seems to be missing from 7.8.3
> Is this correct?
It cherry-picks fine and builds in the co
José Fonseca writes:
> There were also some native ports of bison/flex, but I haven't
> researched on that recently.
I'm partial to the gnuwin32 packages:
http://gnuwin32.sourceforge.net/
I've not tried to use bison/flex on windows yet, but I use it for grep
and gawk and it's wonderful. Ver
keith whitwell writes:
> On Wed, Sep 1, 2010 at 8:34 PM, tom fogal wrote:
> > Luca Barbieri writes:
> >> Note that this totally destroys the ability to use llvmpipe for
> >> high dynamic range rendering, which fundamentally depends on the
> >> ability to
Luca Barbieri writes:
> > It's an impressive amount of work you did here. I'll comment only
> > on the llvmpipe of the changes for now.
>
> Thanks for your feedback!
While we're on the topic: yes, this is great to see Luca. Thank you!
> > So instead of going through a lot of work to support mul
tom fogal writes:
> tom fogal writes:
> > Brian Paul writes:
> > > On 08/23/2010 10:12 AM, tom fogal wrote:
> > > > Anyway the point of this mail is that I'd like to push whomever
> > > > does these things (Ian?) to create a 7.8.3 release.
> &
tom fogal writes:
> Brian Paul writes:
> > On 08/23/2010 10:12 AM, tom fogal wrote:
> > > Anyway the point of this mail is that I'd like to push whomever
> > > does these things (Ian?) to create a 7.8.3 release.
> >
> > Tom, I'll merge your bran
Ian Molton writes:
> Sadly, however, it appears that there are many more similar looking
> bugs in Mesa. Has anyone actually used Mesa to render to glxPixmaps?
> are there patches available to make this stuff work?
FBOs are a (much) better way to achieve what you want: they are cross
platform and
Brian Paul writes:
> On 08/23/2010 10:12 AM, tom fogal wrote:
> > Anyway the point of this mail is that I'd like to push whomever
> > does these things (Ian?) to create a 7.8.3 release.
>
> Tom, I'll merge your branch and do some testing here.
>
> I'd
p out w/ it, I'd be happy to do
so.
Thanks,
-tom
[1]
commit 75181e974c20677e411b4260b4b790ca7459157e
Author: Tom Fogal
Date: Mon Aug 23 10:01:39 2010 -0600
Add release notes for recent bug fixes.
docs/relnotes-7.8.3.html |3 +++
1 files changed, 3 inserti
ast_function.cpp seems to be mixing spaces and tabs.
attached 'fixes' a method I was interested in to use only spaces. might
be a better idea to just run indent on this stuff though.
-tom
diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index f85b308..f022a66 100644
--- a/src/g
Kenneth Graunke writes:
> Hi Tom!
>
> We built a new standalone compiler as part of glsl2 - it should be
> built as src/glsl/glsl_compiler. You might want to take a look at
> that.
Ahh, okay, I see it.
> If you want to run piglit's glslparsertest using the standalone
> compiler,
[snip]
Thanks
tom fogal writes:
> I'm trying to build the compiler standalone for use with piglit, but
> getting a slew of undefined references.
[snip]
Attached diff fixes them.
.. Just needed to look at the actual errors. I guess I was just
surprised I had to at all, because I would have
Henri Verbeet writes:
> Should it ever be valid to destroy a bo that's still mapped in the
> first place though?
In 2.9.2:
If a buffer object is deleted while it is bound, all bindings to
that object in the current context (i.e. in the thread that called
DeleteBuffers) are reset to zero.
Luca Barbieri writes:
> I just discovered that Microsoft wisely decided to use their own
> calling convention on Win64...
>
> This hasn't actually been tested on Win64 though.
Does mingw or cygwin support win64? I don't know if it's just MS that
uses a new calling convention, or all win64 code,
Dan Nicholson writes:
[snip]
> A possible compromise here would be to put glX* stubs in OSMesa, but
> _that_ seems perverse, too.
That would be wonderful for us, though ;)
Can we go the other way? Put OSMesa symbols in libGL?
That feels an iota less gross to me. Still, some day I'd like to pa
"Kevin H. Hobbs" writes:
> On 08/11/2010 05:18 PM, tom fogal wrote:
> > Right. This is exactly why Mesa's name mangling exists.
> > You mean you haven't been mangling this whole time? I guess I haven't
> > been reading these mails closely enough.
&
Dan Nicholson writes:
[snip]
> So, sorry for not reading the whole thread, but is GL being linked
> because it's needed by the app, because pkg-config said so, or
> because the linker added it?
It's needed by the app. Not really, it's not used at runtime, but
needed at link time because the app
"Kevin H. Hobbs" writes:
> When I do :
>
> ./autogen.sh --with-driver=xlib --disable-gallium --enable-debug
>
> I get for example :
>
> $ nm lib/libGL.so | grep glDepthFunc
> 0020ce30 T glDepthFunc
> $ nm lib/libOSMesa.so | grep glDepthFunc
> 001ca760 T glDepthFunc
>
> As I und
"Kevin H. Hobbs" writes:
> On 08/10/2010 02:47 PM, Kevin H. Hobbs wrote:
> With VTK_USE_X:BOOL=OFF the test also passes with libGL.so and
> libOSMesa.so switched that is
>
> VTK_USE_X:BOOL=OFF
> OPENGL_gl_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libOSMesa.so
> OSMESA_LIBRARY:FILEPATH=/home/kevin/mes
"Kevin H. Hobbs" writes:
> On 08/06/2010 03:15 PM, tom fogal wrote:
> > If you could build VTK with just a single GL library -- i.e. with
> > just libOSMesa or just libGL, but not both -- and could reproduce
> > the crash,= that would rule out my symbol collision
tom fogal writes:
> tom fogal writes:
> > the branch is at:
> >
> > git://people.freedesktop.org/~tfogal/mesa
> > http://cgit.freedesktop.org/~tfogal/mesa/log/?h=7.8
>
> I'd like to push this to 'origin' tomorrow, if there are no
> complai
"Kevin H. Hobbs" writes:
> On 08/05/2010 07:07 PM, tom fogal wrote:
> > Brian Paul writes:
> >> My other hunch is something is duplicated in the libOSMesa and libGL
> >> libraries that's causing things to blow up in general.
> >>
> &g
"Kevin H. Hobbs" writes:
> On 08/05/2010 06:30 PM, tom fogal wrote:
> > Is your test multithreaded, by any chance?
>
> I can't really answer this : it's VTK's test.
>
> When I run the test in gdb it tells me :
>
> [Thread debugging using
Brian Paul writes:
[snip]
> My other hunch is something is duplicated in the libOSMesa and libGL
> libraries that's causing things to blow up in general.
This is a good hunch.
I don't know how closely you've been following the thread, Brian, but
previously I brought up how it was important that
"Kevin H. Hobbs" writes:
> On 08/04/2010 05:58 PM, tom fogal wrote:
> > If you can find the commit that started the trouble (using git
> > bisect), that might shed some light.
>
> With my script adjusted to only report when the test started
&
Alex Deucher writes:
> On Thu, Aug 5, 2010 at 3:45 PM, tom fogal wrote:
> >> > > Â git://people.freedesktop.org/~tfogal/mesa
> >> > > Â http://cgit.freedesktop.org/~tfogal/mesa/log/?h=7.8
>
> Can you revert 66ad60399ae005084ad8c07569a1c9a461c39ec9?
>
Marek Olšák writes:
> On Thu, Aug 5, 2010 at 8:00 PM, tom fogal wrote:
>
> > tom fogal writes:
> > > git://people.freedesktop.org/~tfogal/mesa
> > > http://cgit.freedesktop.org/~tfogal/mesa/log/?h=7.8
> > >
> > &
tom fogal writes:
> the branch is at:
>
> git://people.freedesktop.org/~tfogal/mesa
> http://cgit.freedesktop.org/~tfogal/mesa/log/?h=7.8
[snip]
I force-pushed an update w/ Acks.
The only aspect I haven't heard back from is:
> 4fd39a8d69cade6db5c4a0295a5f5f3014
"Kevin H. Hobbs" writes:
> On 08/04/2010 04:21 PM, tom fogal wrote:
> >
> > Can you try valgrind? Perhaps somehow the generated dispatch
> > code is jumping into lalaland and somehow magically ends up in
> > vbo_exec_EvalCoord1fv (pretty far-f
"Kevin H. Hobbs" writes:
> On 08/04/2010 03:01 PM, tom fogal wrote:
> >
> > 3) Doesn't seem likely that ::OpenGLInit calls
> > vbo_exec_EvalCoord1fv :) Are you missing debug symbols in Mesa?
> > Could you get a stack trace w/ full debug symbols?
"Kevin H. Hobbs" writes:
> On 08/04/2010 03:01 PM, tom fogal wrote:
> > 2) Make sure to switch the Mesa libraries in VTK's CMake step. The
> > critical component is that your link lines must put "OSMesa" and
> > "MesaGL" in the 'correc
"Kevin H. Hobbs" writes:
> building mesa with:
>
> ./autogen.sh \
> --with-driver=3Dxlib \
> --disable-gallium \
> --without-demos
> make
No "--enable-gl-osmesa" ?
> It was also at this time that libOSMesa went from being linked
> against libGL to being linked to mesa internal static li
Brian Paul writes:
> On 08/03/2010 01:32 PM, tom fogal wrote:
> > I prepared another 7.8 branch.
> >
> > Again, the branch is at:
> >
> >git://people.freedesktop.org/~tfogal/mesa
> >http://cgit.freedesktop.org/~tfogal/mesa/log/?h=7.8
> >
[snip
I prepared another 7.8 branch.
* Used '-x' when cherry-picking
* Grabbed a few more commits mentioned during discussion
* Manually applied some patches
I'm hopeful that there's no commits which aren't either in the set now
or mentioned below, but please correct me if I'm wrong. Again, the
Hi all,
I needed a fix to 7.8.2 which was only on master, so I scanned master
for all applicable commits and attempted to cherry-pick them to 7.8:
git://people.freedesktop.org/~tfogal/mesa
http://cgit.freedesktop.org/~tfogal/mesa/log/?h=7.8
If a commit didn't cherry-pick automagically, it wa
tom fogal writes:
> Brian Paul writes:
> > On 07/15/2010 03:22 AM, Dave Airlie wrote:
> > > On Thu, Jul 15, 2010 at 6:48 PM, Dan Nicholson wrot
> e:
[snip]
> > >> I don't have a chance to fix this for another week or so, but it
> > >> needs
Brian Paul writes:
> On 07/15/2010 03:22 AM, Dave Airlie wrote:
> > On Thu, Jul 15, 2010 at 6:48 PM, Dan Nicholson wrote:
> >> On Tue, Jul 13, 2010 at 7:42 AM, Brian Paul wrote:
> >>> On 07/13/2010 08:07 AM, Brian Paul wrote:
>
> I'm setting up the Mesa demos repo on a new system. auto
Are the demos supposed to be usable without Mesa?
The 7.8.2 tarball seems to be missing progs/util. In particular,
this means it is missing progs/util/shaderutil*, and thus many of the
progs/glsl programs cannot compile.
-tom
___
mesa-dev mailing list
Jeremy Huddleston writes:
>
> On Jun 16, 2010, at 16:25, Dan Nicholson wrote:
>
> > On Wed, Jun 16, 2010 at 4:20 PM, Jeremy Huddleston
> > wrote:
> >> Hey Tom,
> >>
> >> What version of OSX do you have? I hadn't pulled changes into my
> >> tree (http://cgit.freedesktop.org/~jeremyhu/mesa/log/
For master, 7.8's fine.
-tom
From 0e27861f54462dd96231364ef33d3435716b9440 Mon Sep 17 00:00:00 2001
From: Tom Fogal
Date: Thu, 17 Jun 2010 09:23:53 -0600
Subject: [PATCH] Fix compilation error on darwin.
malloc/NULL needs stdlib.
---
src/mapi/mapi/u_execmem.c |1 +
1 files chang
Dan Nicholson writes:
> On Tue, Jun 15, 2010 at 4:26 PM, Dan Nicholson wrote:
> >>> I have a patch I was working on but haven't tested. I'll try
> >>> to wrap it up tonight and shoot it over to you for a test. I'm
> >>> attaching what I have right now if you want to play around with
> >>> it.
> >
1 - 100 of 115 matches
Mail list logo
