Brian Paul wrote:
Brian Paul wrote:
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've noticed some odd bugs when accessing data packets sent via batch
buffers from the PPE to SPE. Every now and then one of the pointers
sent would be NULL or similar, low value. I
Erkin Bahceci wrote:
Hi,
Is there any chance for the glClipPlane fix to make it into Mesa 7.0.3?
The bug report is here:
http://bugs.freedesktop.org/show_bug.cgi?id=9871
I suppose the fix consists of these 2 commits:
Erkin Bahceci wrote:
On Feb 5, 2008 9:18 AM, Brian Paul [EMAIL PROTECTED] wrote:
Erkin Bahceci wrote:
Hi,
Is there any chance for the glClipPlane fix to make it into Mesa 7.0.3?
The bug report is here:
http://bugs.freedesktop.org/show_bug.cgi?id=9871
I suppose the fix consists of these 2
Just a heads up- I'm changing this function to operate like the constant
state object functions.
Old:
void (*texture_create)(struct pipe_context *pipe,
struct pipe_texture **pt);
New:
struct pipe_texture * (*texture_create)(struct pipe_context *pipe,
José Fonseca wrote:
Microsoft compilers don't support C99 syntax. The only native windows
compilers that support C99 syntax are mingw32-gcc and Intel C/C++
compiler, but we can't seriously support windows platform by targeting
these compilers alone and leave msvc out.
So there is no point
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ever since commit bfd5916eafb9a97ad10f1d4a8738e7dcb02e04f4 the
architecture specific makefile builds (at least linux-x86 and
linux-cell) are completely broken. Jose, could you please fix this?
Since it is becoming obvious
Brian Paul wrote:
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ever since commit bfd5916eafb9a97ad10f1d4a8738e7dcb02e04f4 the
architecture specific makefile builds (at least linux-x86 and
linux-cell) are completely broken. Jose, could you please fix this?
Since
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There is an obvious need for some sort of data cache on the SPEs in the
Cell driver. I've done some research on the subject, and I think I've
got a plan. I wanted to bounce it off folks before I move too far on an
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
| Ian Romanick wrote:
|
| There is an obvious need for some sort of data cache on the SPEs in the
| Cell driver. I've done some research on the subject, and I think I've
| got a plan. I wanted to bounce
I've put a 2nd release candidate of 7.0.3 at http://www.mesa3d.org/beta/
Though, the mesa3d.org server seems a bit overloaded today.
Among the bugs fixed since rc1:
Fixed GLX indirect vertex array rendering bug (14197)
Fixed crash when deleting framebuffer objects (bugs 13507, 14293)
On 2/21/08, Ian Romanick [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
| Ian Romanick wrote:
| Suggestions?
|
| demos/texcyl.c is the one texturing test that pretty much works as
| expected. Use the right mouse button for the options menu
[resending - yesterday's message seemed to have been lost]
I've put a second release candidate of 7.0.3 at http://www.mesa3d.org/beta
Fixes since the first release candidate:
glTexImage3D(GL_PROXY_TEXTURE_3D) mis-set teximage depth field
Fixed GLX indirect vertex array rendering bug (14197)
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
| Brian Paul wrote:
| On 2/21/08, Ian Romanick [EMAIL PROTECTED] wrote:
| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA1
|
| Brian Paul wrote:
| | Ian Romanick wrote:
|
| | Suggestions
[EMAIL PROTECTED] wrote:
Hi,
I tried the gallium branch on my ps3. Unfortunately, all opengl programs
segfault. I'm not sure, but I remember that SDK 3.0 (on fc8) was not
supported - is this still the case?
Here is some strace output I got running glxinfo:
...
Is there something I
Brian Paul wrote:
[EMAIL PROTECTED] wrote:
Hi,
I tried the gallium branch on my ps3. Unfortunately, all opengl
programs segfault. I'm not sure, but I remember that SDK 3.0 (on fc8)
was not supported - is this still the case?
Here is some strace output I got running glxinfo
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
| I tried the gallium branch on my ps3. Unfortunately, all opengl
programs segfault. I'm not sure, but I remember that SDK 3.0 (on fc8)
was not supported - is this still the case?
To build with
[EMAIL PROTECTED] wrote:
Hello Ian,
Am Donnerstag 28 Februar 2008 01:40:40 schrieb Ian Romanick:
[EMAIL PROTECTED] wrote:
| I tried the gallium branch on my ps3. Unfortunately, all opengl
programs segfault. I'm not sure, but I remember that SDK 3.0 (on fc8)
was not supported - is this
Markus Amsler wrote:
I found no documentation for this behaviour. But tests with nvidia's
drivers show that only GL_UNSIGNED_BYTE gets normalized.
Wow depends on this behaviour if GL_NV_vertex_program is present.
Committed.
-Brian
Markus Amsler wrote:
I found no documentation for this. Tests show ati inits weight with
(1,0,0,0), but nvidia with (1,0,0,1).
If vertex_blend is not supported nvidia assigns vertex.weight to
vertex.generic1.
Wow depends on weight=(1,0,0,0) or vertex.weight=vertex.generic1 in its
vertex
Dan Nicholson wrote:
On Fri, Mar 7, 2008 at 3:03 PM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Friday, March 07, 2008 12:24 pm Dan Nicholson wrote:
The defacto method to rebuild the autotools and run the generated
configure is an autogen.sh script. It is much more discoverable than the
Oliver McFadden wrote:
I just had a quick look through the ARB_vertex_program extension
documentation,
but it's a bit hard to interpret...
If a vertex attribute binding matches vertex.weight or
vertex.weight[n], the x, y, z, and w components of the vertex
attribute variable are filled
Dan Nicholson wrote:
On Mon, Mar 10, 2008 at 2:15 PM, Kristian Høgsberg [EMAIL PROTECTED] wrote:
On Mon, Mar 10, 2008 at 2:32 PM, Dan Nicholson [EMAIL PROTECTED] wrote:
Kristian,
Unfortunately, moving the libGL install target to src/glx breaks all
the non-glx targets since libGL
Hanno Böck wrote:
Hi,
Currently, the gallium-0.1 branch fails when doing make install, attached
patch adds (like in glx dir) an empty install target to the gallium Makefile,
which will avoid this.
Please apply
Committed. Though, you're probably the first/only person to try a 'make
Ian's probably the most familiar with recent GLX extension code.
I'd take a look but I'm just too busy with other things, sorry.
-Brian
Keith Whitwell wrote:
Maybe Brian and Ian?? And KRH too, I suspect...
In any case, the answer is that this lies in the 'rough edges' Thomas was
talking
Jerome Glisse wrote:
On Sat, 15 Mar 2008 14:55:18 +0100
Markus Amsler [EMAIL PROTECTED] wrote:
Well, I know its the same patch for the third time. I still think its
the correct fix if there are unused ATTRIB declarations
in the program. Dropping them here relieves the drivers of the
Keith Whitwell wrote:
- Commits ---
commit 8dd90ee19d97c4b032c2b057d96b3e674be3e1fd
Author: Brian
Date: Thu Mar 20 09:15:24 2008 -0600
gallium: temporarily disable the memcmp() in cso_set_framebuffer()
The memcmp() fails to detect
malc wrote:
I accidentally stumbled upon this
http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commitdiff;h=35a1ec53a7728311de22124c14b93dbbdee2ce90;hp=17b234ae3319d8a36afc44d0cceb30fea6b42d67
If new_size old_size wouldn't memcpy corrupt the memory?
Yes. I'll fix it. Thanks.
-Brian
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm trying to add XSHM support for the xlib winsys driver in Gallium,
and I'm having some difficulties. I primarily want to check some of my
assumptions, but any pointers would be welcome.
DISCLAIMER: I'm not really that
Sorry for the problems caused by my commit. The arbprogparse.c code was
diverging a fair bit between master and gallium-0.1 and I thought it
would be good to sync them up. The driver fix is/was simple though.
-Brian
Oliver McFadden wrote:
Oh, I forgot to change r300_fragprog.c. I've pushed
Ian,
I've started added support for multi-texture so I can do some perf
measurements.
Here's a question. In one_time_init() we call invalidate_tex_cache().
Since we have no textures yet, the address we're passing to
spu_dcache_mark_dirty() is NULL. Is that OK?
Also, when texture state
Roland Scheidegger wrote:
Ben Skeggs wrote:
Hey,
Current git ignores the IsPositionInvariant vertex program flag.
Attached is a patch to fix the issue. Tested with
progs/tests/arbvptorus on Nouveau/NV40.
Cheers,
Ben.
Note that there's still the issue of user clip planes which isn't
The 7.0.3 release is overdue and I'd like to wrap it up soon, even if
there are various outstanding bugs.
A 3rd release candidate is at http://www.mesa3d.org/beta
Please test and report any issues ASAP. Thanks.
-Brian
-
C.W. Betts wrote:
Is there anywhere I could find some MPW makefiles for older versions of Mesa,
such as version 3.4.2?
I'm kinda interested in making an OpenGL Passthrough for SheepShaver, but I
don't know enough about Mac Classic Programming (or programming in general)
to get started.
On Thu, Apr 3, 2008 at 7:11 AM, ruediger janecke
[EMAIL PROTECTED] wrote:
Hallo everybody,
there was a known problem
Known problems:
- NURBS or evaluator surfaces inside display lists don't always work
in Mesa 3.4.1,
which I believe, I encountered using Mesa 7.0 - see attached
7.0.3 may be downloaded from sourceforge at
http://sourceforge.net/project/showfiles.php?group_id=3
See the release notes for a list of bug fixes, etc.
-Brian
-
This SF.net email is sponsored by the 2008 JavaOne(SM)
Hasso Tepper wrote:
The attached patches add support for DragonFly BSD. dragonfly-mesa70.patch
is applicable to both 7.0 branch and master,
dragonfly-mesa-autoconf.patch just adds autoconf support for master only.
7.0 branch is fully tested, master isn't due to need for too many stuff
In the patch below, I'd suggest replacing the exit() with something less
drastic. Maybe propogate up a GL error, or issue a warning.
-Brian
Markus Amsler wrote:
Fixes Bug 15447
---
src/mesa/drivers/dri/r300/r300_vertprog.c | 30
+++-
1 files changed, 16
David Flynn wrote:
With mesa 7.0.3-rc2 (debian build), attempting to compile a GLSL shader
containing the following preprocessor directive fails:
#extension GL_ARB_texture_rectangle : require
With:
Error: GL_ARB_texture_rectangle: required extension is not supported.
I note that the
Anatolij Shkodin wrote:
There are some programs on FreeBSD that require static MesaGL libraries.
However, freebsd-static is unavailable in Makefile.
Compiling linux-static works well, but then hangs during make install (I
didn't save the exact line on which it does, sorry. But it was the
Berk Geveci wrote:
One of our VTK memory check (valgrind) tests is following the attached
memory leak from the debug build of 7.0.3
(http://www.cdash.org/CDash/viewDynamicAnalysisFile.php?id=17869)
Berk Geveci
Kitware Inc.
==29361== Memcheck, a memory error detector.
==29361== Copyright
Jesse Barnes wrote:
Brian, do you have any plans for a 7.1 release at some point? It would be
nice to get something out there that includes Kristian's DRI2 work, along
with some of the other changes that have happened recently, like the i915
driver unification, build work, etc.
Yeah, we
Chris Rankin wrote:
Hi,
I think there's a problem with Mesa git. This was with a clean rebuild:
*** glibc detected *** glxgears: double free or corruption (!prev):
0x08444bc0 ***
=== Backtrace: =
/lib/libc.so.6[0x42718ac1]
/lib/libc.so.6(cfree+0x90)[0x4271c0f0]
Brian Paul wrote:
Chris Rankin wrote:
Hi,
I think there's a problem with Mesa git. This was with a clean rebuild:
*** glibc detected *** glxgears: double free or corruption (!prev):
0x08444bc0 ***
=== Backtrace: =
/lib/libc.so.6[0x42718ac1]
/lib/libc.so.6(cfree+0x90
Dave Rigby wrote:
Greetings,
I'm currently trying to migrate an old in-house app (which no longer
have the source for) to a new Linux box. Previously this app ran on a
RH6.2 box, and I've noticed some strange behaviour in how this app
uses Mesa, specifically the glXUseXFont()
David Cole wrote:
If you look at the nightly VTK dashboard results for these two builds...:
http://www.cdash.org/CDash/viewTest.php?onlyfailedbuildid=74530
http://www.cdash.org/CDash/viewTest.php?onlyfailedbuildid=74530
http://www.cdash.org/CDash/viewTest.php?onlyfailedbuildid=74372
Brad King wrote:
Brian Paul wrote:
David Cole wrote:
Would you suspect a bug in mesa itself or might we be using something in
VTK in an unexpected fashion...?
I recently improved the vert/frag program reference counting to fix
another issue. Looks like there's still a bug or two.
Could
Sorry I broke the build. Until git is back, here's a trivial patch that
should allow the i965 driver to work again. Though, the way
instruction-Sampler is used in the i965 driver isn't totally clear to
me and I'll have to revisit it later.
-Brian
diff --git
Yes, I saw the first message.
I've checked in the fix to my local git tree. I'll push to master when
the repo is back on line.
-Brian
Shunichi Fuji wrote:
I was going to post here ...
---
Begin forwarded message:
Date: Fri, 16 May 2008 10:45:21 +0900
From: Shunichi Fuji [EMAIL
Brad King wrote:
Brian Paul wrote:
Brad King wrote:
This was broken again by 'ade5083'. A stack trace is below (as of
'fd59f19').
-Brad
#0 fetch_texel_lod (ctx=0x689450, texcoord=0x7fff16a0a8e0, lambda=0,
unit=2, color=0x7fff16a0a910) at swrast/s_fragprog.c:47
#1 0x2ad796a76992
The first release candidate of Mesa 7.1 (new development release) can be
grabbed from http://www.mesa3d.org/beta
This has been tagged in git as mesa_7_1_rc1
There's a lot of new code, the new auto-conf build system, etc. so it's
important that people grab these tarballs and test.
-Brian
From my checkins one can see I've been working on some EGL things on
the gallium-0.1 branch.
As a first step I've got an EGL interface working with the gallium
softpipe driver.
To build:
1. do a normal linux or linux-debug build as you would for softpipe
2. cd src/egl/ ; make
3. cd
Philipp Klaus Krause wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul schrieb:
The first release candidate of Mesa 7.1 (new development release) can be
grabbed from http://www.mesa3d.org/beta
This has been tagged in git as mesa_7_1_rc1
There's a lot of new code, the new
packadal wrote:
Hello,
As a college project, I had to developp a portable application using
openGL.
We used an open-source library (nui2, https://gna.org/projects/ngl/) and
as a part of our project we had to run valgrind on our code to make sure
there was no memory leaks.
After we fixed
Nicolai Hähnle wrote:
[Same story as the patch I just sent a minute ago, really]
This memory leak is identical to the earlier one in texenvprogram.
Fixed by not creating an additional reference to new programs in cache_item.
On top of that, remove some duplicated state setting.
This
I've checked in some changes to the build system. Namely, I've pushed
some of the stuff in src/mesa/Makefile down into new
src/mesa/drivers/osmesa/Makefile and src/mesa/drivers/x11/Makefile
makefiles.
If I've broken anything, let me know.
With a little more work, the remaining special-case
Eric Anholt wrote:
On Fri, 2008-06-06 at 09:45 +0200, Tomas Carnecky wrote:
Some fragment shaders don't work right on i965. For example if I enable
the 'neg' compiz plugin, all windows turn gray. And I tried my own
plugin that does: MOV output.r, 1.0; and all windows turned red (or was
it
On Sun, Jun 8, 2008 at 10:56 AM, Nicolai Hähnle [EMAIL PROTECTED] wrote:
Hi,
building stand-alone Mesa (--with-driver=xlib) fails on current Git.
Oops, realglx.c was mistakenly added to the new Makefile. I've fixed that.
The
following patch fixes it for me, but I'm not sure whether
Brad King wrote:
Hi,
Since 2b84b22 I've been getting linker errors when linking to libGL.so:
$ make linux-x86-64
[snip]
gcc -I../../include -Wall -Wmissing-prototypes -O3 -g -fPIC -m64
-D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE
-D_GNU_SOURCE -DPTHREADS
Timo Jyrinki wrote:
2008/6/12 Keith Whitwell [EMAIL PROTECTED]:
In reality, what has happened is that most of this has already
occurred -- whatever 3d driver-related traffic that hasn't been sucked
into IRC is now occurring on the Mesa lists.
Right. I now rearranged DRI wiki's mailing list
seventh guardian wrote:
Hello,
I'm running a 64 bit kernel and using the gallium branch from the
nouveau repository. It's being kept mostly synchronized with your
gallium branch, so this problem should also apply.
Everything works (mostly) fine with 64 bits apps, but for 32 bit apps
H. Verbeet wrote:
This patch and the next one fix some failures in Wine's D3D9
fog_with_shader_test() unit test when run with Mesa's swrast. I
suppose it could have some impact on the other drivers as well.
There's a problem with the _tnl_allow_vertex/pixel_fog() functions even
without your
Brian Paul wrote:
H. Verbeet wrote:
This patch and the next one fix some failures in Wine's D3D9
fog_with_shader_test() unit test when run with Mesa's swrast. I
suppose it could have some impact on the other drivers as well.
There's a problem with the _tnl_allow_vertex/pixel_fog() functions
H. Verbeet wrote:
Vertex programs replace fog coord generation, but not vertex fog application.
This also means the fog stage should be run after the vertex program stage.
Hmmm, can you point me to where this is
Nicolai Hähnle wrote:
Hi everybody,
as you may have noticed, I committed a refactoring of how our r300 DRI driver
compiles fragment programs, and Corbin Simpson gets credit for adapting those
changes for r500 fragment programs as well.
My changes use an intermediate representation that
H. Verbeet wrote:
2008/6/16 Brian Paul [EMAIL PROTECTED]:
With the fog bugs fixed, there are two issues I run into when running
Wine's D3D unit tests with Mesa's swrast. The first issue is that by
default Mesa doesn't report any visuals / FBConfigs with an alpha
channel in the colorbuffer
Roland Scheidegger wrote:
On 16.06.2008 18:17, H. Verbeet wrote:
2008/6/16 Brian Paul [EMAIL PROTECTED]:
H. Verbeet wrote:
Vertex programs replace fog coord generation, but not vertex fog
application. This also means
seventh guardian wrote:
On Mon, Jun 16, 2008 at 4:17 PM, Brian Paul
[EMAIL PROTECTED] wrote:
seventh guardian wrote:
Hello,
I'm running a 64 bit kernel and using the gallium branch from the
nouveau repository. It's being kept mostly synchronized with your
gallium branch, so this problem
Corbin Simpson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Nicolai Hähnle wrote:
Hi everybody,
as you may have noticed, I committed a refactoring of how our r300 DRI
driver
compiles fragment programs, and Corbin Simpson gets credit for adapting
those
Alan Coopersmith wrote:
I needed to apply the attached patches to git master to be able to build
on Solaris using the autoconf support and the Sun compilers - can they be
included for the 7.1 release?
There were two big portability problems I worked around instead of fixing:
- Use of
OK by me. In general, if there's no feedback to a patch it's most
likely silence consensus.
-Brian
Dan Nicholson wrote:
Any issues with this patch? I'll probably push it if there are no objections.
On Wed, Jun 4, 2008 at 1:26 PM, Dan Nicholson [EMAIL PROTECTED] wrote:
Rather than just
Paul Bender wrote:
Fatih Aşıcı wrote:
01 Tem 2008 Sal tarihinde, Dave Airlie şunları yazmıştı:
Update libdrm to 2.3.1.
These archives do not include xf86mm.h ?
I noticed that is well, but it appears to be correct. I found that I
needed to patch Mesa 7.1.0 with two commits from trunk:
... can be downloaded from http://www.mesa3d.org/beta/
md5 checksums:
db67dd7d433f97c6267e9e2c13172afc MesaLib-7.1-rc2.tar.gz
afac02be5cd803f9ad0a6ea6c8b2e41b MesaLib-7.1-rc2.zip
fa3aad25c4603e04dad7f8a1710ba409 MesaDemos-7.1-rc2.tar.gz
d088536d1bf7b7e111841079b30226af MesaDemos-7.1-rc2.zip
Donnie Berkholz wrote:
On 15:19 Tue 08 Jul , Brian Paul wrote:
I'm hoping to wrap this up soon, so timely feedback would be
appreciated. Thanks.
src/mesa/drivers/Makefile isn't in the tarball, so it doesn't build.
Should there be some sort of distcheck equivalent? Other than that, my
OK, rc2 had problems. Sorry about that.
rc3 is now at http://www.mesa3d.org/beta/
md5 checksums:
3a3cb6e3f09bf28650483b0d43ab8d88 MesaLib-7.1-rc3.tar.gz
46a32a37af0cc7e97a09621bf588d751 MesaLib-7.1-rc3.zip
b4ec33e6167eec33c6857569dedb20a6 MesaDemos-7.1-rc3.tar.gz
Timo Jyrinki wrote:
2008/7/9 Jin, Gordon [EMAIL PROTECTED]:
I don't understand why the release happens on master not a stable branch
(like mesa_7_0_branch). Will there be a stable branch for the next
release?
Mesa 7.1 will be a (relatively stable) development version, 7.2 will
be the
Michel Dänzer wrote:
On Tue, 2008-07-08 at 15:19 -0600, Brian Paul wrote:
I'm hoping to wrap this up soon, so timely feedback would be
appreciated. Thanks.
What would people think about using tracker/blocker bugzilla entries, as
is done for X.Org releases (e.g.
https
Roland Scheidegger wrote:
On 16.07.2008 16:55, Maciej Cencora wrote:
Hi,
I tried implementing GL_ATI_separate_stencil in r300 driver, but I
faced a problem. With my simple patch http://pastebin.com/m524d1ae7
r300 driver supports 2 stencil extensions (GL_ATI_separate_stencil and
Brad King wrote:
Hello,
Since 3bfedb7ed4a35cfcc7187bc22314833ef1d96ec9 I've been getting this
error when building:
gcc -c -O3 -g -fPIC -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L
-D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_XSHM
-DHAVE_POSIX_MEMALIGN -DUSE_X86_ASM
Andreas Micheler wrote:
Hallo Mesa Developers,
I'm trying to make run a little test program with Mesa.
It runs smoothly with the Windows OpenGL system driver.
But I have problems implementing wglShareLists,
because I don't know much about the inner structures of Mesa.
I saw there is
Xiang, Haihao wrote:
Hi, Brian
inst-TexSrcUnit is used as a sampler unit for a GLSL program since
the commit ade508312c701ce89d3c2cd717994dbbabb4f207, however it is still
used as a source texture unit for an internal program. So a DRI driver
(such as i965) doesn't know inst-TexSrcUnit is
Joshua Stratton wrote:
Is there an easy way to use the GLSL code in the current git
repository to allow a fragment shader to be processed individually--as
in one fragment shader is compiled, some loop sends a data structure
to it, and it gets back gl_FragData without using the core render
Xiang, Haihao wrote:
On Thu, 2008-07-31 at 13:34 +0800, Xiang, Haihao wrote:
Hi, Brian
Currently the counter used for temporaries doesn't include all
intermediate results when emitting program instructions, however a
device driver needs to allocate hardware registers for these
Xiang, Haihao wrote:
On Tue, 2008-08-05 at 08:45 -0600, Brian Paul wrote:
Xiang, Haihao wrote:
On Thu, 2008-07-31 at 13:34 +0800, Xiang, Haihao wrote:
Hi, Brian
Currently the counter used for temporaries doesn't include all
intermediate results when emitting program instructions, however
Svilen wrote:
Hi,
This is second time I'm trying to get your attention guys.
Shall I flag it as a bug? Or it is not a DRI problem. I know at least a
couple of similar platforms with the same trouble.
If this is not a right place to ask the question, I'll appreciate if you
point me
Owain Ainsworth wrote:
swizzle_copy() in src/mesa/main/texstore.c almost always accesses memory
out of bounds since it does COPY_4UBV() while stepping through an array
when there's less than 4 elements left, only the srcComponents == 4 case
is safe. Discovered on OpenBSD with mplayer -vo gl2
Hanno Böck wrote:
Any problem with that patch? Shouldn't hurt.
Am Sonntag 27 Juli 2008 schrieb Hanno Böck:
Some makefiles in the gallium-0.1 branch are missing the DESTDIR-variable
for installation.
Attached patch fixes that, please apply.
Done. Thanks.
-Brian
Corbin Simpson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- From 1f80772f964bd2253a2d569eea4d93fe7a1baa1f Mon Sep 17 00:00:00 2001
From: Corbin Simpson [EMAIL PROTECTED]
Date: Sat, 16 Aug 2008 08:22:53 -0700
Subject: [PATCH] Fix GLSL detection
Look for extensions instead of OGL
Yet another Mesa 7.1 release candidate is at http://www.mesa3d.org/beta/
This includes the latest GLSL fixes/features plus other assorted fixes
from the past 2-3 weeks.
Hoping to wrap up 7.1 pretty soon...
-Brian
-
This
Mesa 7.0.4 can be downloaded from
http://sourceforge.net/project/showfiles.php?group_id=3
See the docs/relnotes-7.0.4.html file for changes.
7.0.4 just contains bug fixes since the 7.0.3 release. Distros should
be able to make 7.0.4 packages that are drop-in updates for 7.0.3 packages.
This
Vitaliy Ivanov wrote:
On Mon, 2008-08-18 at 17:17, Brian Paul wrote:
/Vitaliy Ivanov wrote:
On Fri, 2008-08-15 at 17:45, Vitaliy Ivanov wrote:
Hello list,
I'm experiencing the following issue:
appname: symbol lookup error: applib.so: undefined symbol:
glwMDrawingAreaWidgetClass
Dave Airlie wrote:
On Sun, Aug 17, 2008 at 12:23:06 +0200, Stefan Dirsch wrote:
Looks like dri_bufmgr.h/intel_bufmgr.h are missing in the
tarball. Could this be?
See my other reply on mesa3d-dev, they're from libdrm git master.
So I see a couple of ways to resolve this,
1) Back out
Ralovich, Kristóf wrote:
This patch is at
http://cgit.freedesktop.org/~tade/mesa/commit/?h=xcb-integrationid=45737d791ca91fc33a8f6bfb2514c28409548c73
. This leak was only exposed when LIBGL_ALWAYS_INDIRECT is set.
Kristof
From 45737d791ca91fc33a8f6bfb2514c28409548c73 Mon Sep 17 00:00:00
Ralovich, Kristóf wrote:
This patch is at
http://cgit.freedesktop.org/~tade/mesa/commit/?h=xcb-integrationid=18deb0897ede0d1406bcfc7419b12654ceddf6af
.
Kristof
From 18deb0897ede0d1406bcfc7419b12654ceddf6af Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Ralovich,=20Krist=C3=B3f?= [EMAIL
Ralovich, Kristóf wrote:
This patch is at
http://cgit.freedesktop.org/~tade/mesa/commit/?h=xcb-integrationid=20e634059e02b41d061149a45e53dd4933c39953
.
Kristof
From 20e634059e02b41d061149a45e53dd4933c39953 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Ralovich,=20Krist=C3=B3f?= [EMAIL
Ralovich, Kristóf wrote:
This patch is at
http://cgit.freedesktop.org/~tade/mesa/commit/?h=xcb-integrationid=fe0c68634ade8dafda2e8decaab077e50fea99e1
.
Kristof
From fe0c68634ade8dafda2e8decaab077e50fea99e1 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Ralovich,=20Krist=C3=B3f?= [EMAIL
Ralovich, Kristóf wrote:
This patch is at
http://cgit.freedesktop.org/~tade/mesa/diff/?h=xcb-integrationid=0e78c256e9fd9a2bab5acb4b639c5240357129f7
. I am sure this #include is not elegant, but it works.
Kristof
From 0e78c256e9fd9a2bab5acb4b639c5240357129f7 Mon Sep 17 00:00:00 2001
From:
Eric Anholt wrote:
On Tue, 2008-08-19 at 18:20 -0600, Brian Paul wrote:
Dave Airlie wrote:
On Sun, Aug 17, 2008 at 12:23:06 +0200, Stefan Dirsch wrote:
Looks like dri_bufmgr.h/intel_bufmgr.h are missing in the
tarball. Could this be?
See my other reply on mesa3d-dev, they're from libdrm
Stephane Marchesin wrote:
On Wed, Aug 20, 2008 at 2:20 AM, Brian Paul
[EMAIL PROTECTED] wrote:
Dave Airlie wrote:
On Sun, Aug 17, 2008 at 12:23:06 +0200, Stefan Dirsch wrote:
Looks like dri_bufmgr.h/intel_bufmgr.h are missing in the
tarball. Could this be?
See my other reply on mesa3d-dev
Timo Jyrinki wrote:
2008/8/20 Brian Paul [EMAIL PROTECTED]:
What I'd probably do then is create a mesa-7.2 branch, based on 7.1,
which will be a stable, bug-fix branch without GEM.
Then, designate mesa/master as the new-feature / GEM / 7.3 development
area. I'd also consider merging gallium
Dave Airlie wrote:
the GEM code. I have a feeling it might be easier for you to back-out
the GEM code, make a branch, then re-add GEM on master. Besides, your
git-fu is probably much better than mine.
The branch should be called mesa_7_2_branch. I'll make a 7.1 release
off that
301 - 400 of 1059 matches
Mail list logo
