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
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
*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'
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*. 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
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
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
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
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
> [
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
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
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
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
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
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
, 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 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
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
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
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
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
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
> 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
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 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]
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.
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
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
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
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
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
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
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
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.
> &
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
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
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
"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
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
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
&
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
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
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
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,
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
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
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
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
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
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 |
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
> >
>
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
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
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
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
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:
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Brian Paul writes:
> Is there any way that the rendering can be checked for correctness
> without relying on an exact image comparison?
http://pdiff.sourceforge.net/
haven't used it myself, but I'd like to try it for our regression
tests, someday.
-tom
Aaron Plattner writes:
> I looked into why Mesa's libGL wasn't working with our (NVIDIA's) GLX
> extensi on, and tracked down a couple of bugs in Mesa's handling of
> GLX visuals and fbconfigs.
Am I missing something, or does your 2/2 undo your 1/2 (what's the
point, if so?)?
-tom
__
"Bridgman, John" writes:
> re: the overall development model, my main question would be whether
> continuing work on a release branch after the initial release is
> really still require d now that we have quarterly major releases for
> all the major components.
FWIW, the frequency of Mesa release
Jakob Bornecrantz writes:
> A half backed idea would be to have to run a opt in slightly unstable
> branch, instead of going full multi-branch development model. Where
> bug-fixes can go in freely, small features can go in after a review
> of the changes by the module maintainer. What that means i
"Kevin H. Hobbs" writes:
> I deleted my mesa directory and re-cloned the repository and tried to
> build but the build stopped here :
[snip]
> In file included from nv50_context.h:19,
> from nv50_clear.c:28:
> =2E./../../../src/gallium/drivers/nouveau/nouveau_stateobj.h: In functi
"Kevin H. Hobbs" writes:
> On 05/10/2010 11:56 AM, tom fogal wrote:
> >=20
> > I recommend you check out the "build_mesa" function in:
> >=20
> > http://portal.nersc.gov/svn/visit/trunk/src/svn_bin/build_visit
> >=20
> > There's a
Dan Nicholson writes:
> On Mon, May 10, 2010 at 10:08 AM, Kevin H. Hobbs wrote:
> > All I really want is Mesa with OSMesa from the development
> > repository as the "reference" library for my VTK and ParaView
> > nightly test builds.
>
> ./configure --with-driver=xlib ? That will link libOSMesa
Dan Nicholson writes:
> On Mon, May 10, 2010 at 10:08 AM, Kevin H. Hobbs wrote:
> > All I really want is Mesa with OSMesa from the development
> > repository as the "reference" library for my VTK and ParaView
> > nightly test builds.
>
> ./configure --with-driver=xlib ? That will link libOSMesa t
Dan Nicholson writes:
> On Mon, May 10, 2010 at 6:54 PM, tom fogal wrote:
> > Dan Nicholson writes:
> >> On Mon, May 10, 2010 at 10:08 AM, Kevin H. Hobbs wrote:
> >> > All I really want is Mesa with OSMesa from the development
> >> > repository
"Kevin H. Hobbs" writes:
> Today, I plan to try to :
[snip]
> 2. Try surrounding the declarations of the hidden symbols needed by
> OSMesa with "#pragma GCC visibility push(default)" and "#pragma GCC
> visibility pop" or marking them with "__attribute__
> ((visibility("default")))" whichever I'm t
Brian Paul writes:
> Kevin H. Hobbs wrote:
> > On 05/14/2010 08:51 AM, Dan Nicholson wrote:
> >> On Thu, May 13, 2010 at 7:40 AM, Kevin H. Hobbs wrote:
> >>> I tried it and it tests as well with VTK as any recent build.
> >> Thanks. Well, you and Tom use a standalone osmesa. The only distro I
> >
I'm using the classic (OS)Mesa driver w/ GLSL.
I see from:
http://www.mesa3d.org/shading.html
that gl_ClipVertex is unsupported, which probably explains why I'm
getting such strange results when I use it :)
I might be interested in taking a stab at this, or perhaps just skip
ClipVertex entire
Hi, since this hasn't received a reply I figured I'd step in.
marvi...@gmx.de writes:
> patches below add some memory debuging functions to the r600 driver.
There was some recent effort to *remove* similar functions throughout
the Mesa tree. The justification was that they were useful a while
ba
Ian Romanick writes:
> > If there are no objections, I will clean up the release notes and
> > make the release tomorrow (Wednesday) morning. It looks like a
> > few things got cherry-picked in the last week, so I'm assuming
> > everything is in that people care about.
OSMesa, which appears to g
Dan Nicholson writes:
> On Tue, Jun 15, 2010 at 12:55 PM, tom fogal wrote:
> > Ian Romanick writes:
> >> > If there are no objections, I will clean up the release notes and
> >> > make the release tomorrow (Wednesday) morning. =C2=A0It looks like a
> >
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.
> >
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
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/
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
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
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
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
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
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
"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
"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:
> 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 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
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
1 - 100 of 115 matches
Mail list logo
