Mesa implements this extension but we don't really do anything special
for it (it's a no-op). I'd like to remove it. Any objections?
-Brian
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
The 3rd release candidate can be found at http://www.mesa3d.org/beta/
Since rc2 there have been assorted bug fixes and build fixes.
-Brian
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
Maciej Cencora wrote:
Dnia poniedziałek, 8 czerwca 2009 o 09:28:25 Ian Romanick napisał(a):
Maciej Cencora wrote:
Hi,
this patch brings few EXT_vertex_array_bgra fixes:
1) Pass the correct format when calling update_array in
_mesa_VertexAttribPointerARB.
2) glVertexAttribPointerNV accepts
Corbin Simpson wrote:
Keith Whitwell wrote:
On Fri, 2009-06-05 at 15:12 -0700, Brian Paul wrote:
Mesa implements this extension but we don't really do anything special
for it (it's a no-op). I'd like to remove it. Any objections?
We *could* do something with it -- minimally it could
Patrice Mandin wrote:
Le Tue, 02 Jun 2009 15:32:07 +0200
Roland Scheidegger srol...@vmware.com a écrit:
If there are other chipsets that cannot do true separate alpha blend, we
can always use PIPE_CAP to let Mesa know, and Mesa can do the fragment
program alteration itself. (r3xx and r4xx
I've been working on these two extensions in my spare time.
Each is on a temporary/feature branch in git: ext-provoking-vertex
and arb_map_buffer_range
Both are implemented for swrast and gallium.
If you're interested in either or both take a look at the branches and
let me know if there's any
Brian Paul wrote:
I've been working on these two extensions in my spare time.
Each is on a temporary/feature branch in git: ext-provoking-vertex
and arb_map_buffer_range
Both are implemented for swrast and gallium.
If you're interested in either or both take a look at the branches
Maciej Cencora wrote:
Hi,
here's a an excerpt from ARB_occlusion_query specification:
Will polling a query without a Flush possibly cause an infinite loop?
RESOLVED: No. An infinite loop was possible in the original
NV_occlusion_query spec if an application did not
Dave Airlie wrote:
I think we've gone as far as we can with radeon-rewrite, it was starting
to outshine master in a few areas mainly thanks to Maciej (osiris) work,
We've lost support for a couple of things (hyperz/texture tiling)
temporarily but they will return once we can figure out how
tom fogal wrote:
tom fogal tfo...@alumni.unh.edu writes:
Compilation is broken on OS X 10.5.7 using master's HEAD [1]:
[snip]
mklib: Making Darwin shared library: libOSMesa.7.6.dylib
Undefined symbols:
_glCopyBufferSubData, referenced from:
_static_functions in
Maciej Cencora wrote:
Hi,
d7ea9ddf5824556e47decac7ba200f37cf1e552f mesa: use
_mesa_reference_buffer_object() in a few places introduced a regression.
I've attached backtrace from crashing wine/d3d9 test.
This patches also causes a segfault when running sauerbraten and ut2004 games.
I've
Shuang He wrote:
fb backing regions should be released when destroy buffer, or there will
be memory leaks.
Committed. Thanks!
-Brian
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new
Ian Romanick wrote:
I've been combing over the list of commits in Mesa master that are not in
mesa_7_5_branch. There are a few that appear to be good candidates for cherry
picking. If folks could review this list and offer any comments, that would
be
very helpful.
I've been pretty
José Fonseca wrote:
On Fri, 2009-06-19 at 11:19 -0700, Brian Paul wrote:
Module: Mesa
Branch: master
Commit: 9d029e0e200eb97993c1b9fb8ab9046172e703e8
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=9d029e0e200eb97993c1b9fb8ab9046172e703e8
Author: Brian Paul bri...@vmware.com
Date
Roland Scheidegger wrote:
I was just wondering, is it really necessary that this demo requires
FBO? It's quite useful to debug cube textures even on drivers which
don't support FBOs and I wonder if there's a good reason to not just use
automipmapping instead (I think pretty much any known
Chia-I Wu wrote:
While studying the code, I found there are some issues with region/pbo COW.
However, they seem not to cause any problem with real applications. I have to
modify the driver so that pbo always uses sys_buffer to verify my fixes.
Mesa 7.4.3 can be downloaded from
https://sourceforge.net/project/showfiles.php?group_id=3
This is a bug-fix release. See the release notes for details.
This will probably be the last release in the 7.4.x series.
-Brian
Nir Radian wrote:
Hello all,
I’m attempting to run Humus’s alpha2coverage demo – I
understand that there is no multisample buffer, but still while
analyzing the result coming from the fragment shader I noticed that
the shader doesn’t use the FetchTexelDeriv although I’m
RALOVICH wrote:
Hi,
running valgrind --leak-check=full --show-reachable=yes glxgears shows e.g.:
==24009== 97,960 (94,400 direct, 3,560 indirect) bytes in 1 blocks are
definitely lost in loss record 55 of 55
==24009==at 0x4C216F4: calloc (vg_replace_malloc.c:397)
==24009==by
Jakob Bornecrantz wrote:
Hi Brian and Eric
Can one or both of you do a merge of the 7_5_branch there are some
conflicts and I don't want to mess up code I don't know anything
about. That would be most kind, thanks.
Will do. Hold on...
-Brian
Jakob Bornecrantz wrote:
On 24 jun 2009, at 16.40, Brian Paul wrote:
Jakob Bornecrantz wrote:
Hi Brian and Eric
Can one or both of you do a merge of the 7_5_branch there are some
conflicts and I don't want to mess up code I don't know anything
about. That would be most kind, thanks
Available at http://www.mesa3d.org/beta/
MD5 checksums:
68d4994087863a88ef46b0f19ee35a23 MesaLib-7.5-rc4.tar.gz
38ade09207802576f2716b85fe01e4ca MesaLib-7.5-rc4.zip
5adaaa884026e89c9ed7494c35835843 MesaDemos-7.5-rc4.tar.gz
984b4ca8666bcd5ae6edde86b4d41815 MesaDemos-7.5-rc4.zip
Nicolas Cadio wrote:
Hi
I want to test the demo glsync (...\progs\xdemos\glsync.c) with the
option -s b to use the verticale sync.
The problem is when the function glXSwapBuffer calls the function
GetGLXDRIDrawable(dpy, drawable, NULL), GetGLXDRIDrawable returns a
pointer(pdraw) which
RALOVICH wrote:
From 2049767654da280b24754b8807757f88a5f3fd73 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?RALOVICH,=20Krist=C3=B3f?= tad...@freemail.hu
Date: Tue, 30 Jun 2009 00:46:36 +0200
Subject: [PATCH 3/3] glx: plug a leak
Swrast was missing a free for the culmination of driConcatConfigs.
RALOVICH wrote:
See attached patch.
Please review and apply.
Applied.
-Brian
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors
Eric Anholt wrote:
On Thu, 2009-07-02 at 22:20 -0700, Vinson Lee wrote:
I believe there's a bug in the piglit vbo-map-remap.c test. The test
fails for me with a GL_INVALID_ENUM error that comes from
glEnable(GL_VERTEX_ARRAY). GL_VERTEX_ARRAY is a client-side capability
so the error seems
Chen Rabiner wrote:
I'm trying to software render Humus softshadows
http://www.humus.name/index.php?page=3DID=51
And i'm getting holes in the wood and in other places in the scene.
The holes are created because of triangle snapping with 4 bits of accuracy
and this creates gaps in the
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chia-I Wu wrote:
There is a possbile race that _glapi_Context is reset by another thread
after it is tested in GET_CURRENT_CONTEXT but before it is returned. To
avoid the race in a lockless fashion, no threads should reset
Chia-I Wu wrote:
This patch series fix several races in non-TLS thread support, and add
xeglthreads, which is EGL version of glthreads. With them applied, I do
not get crashes any more during my limited testing.
However, I am a little uneasy with the 3rd patch. It makes
The glean exactRGBA test has always failed with Mesa (with sw
rendering at least). The failures come from a sequence of
int-float-int conversions which don't meet the GL spec.
In particular, when glColor4us() or glColor4ui() are used to set the
drawing color, the N-bit integer frame buffer
Is there any objection to changing exactRGBA to be more lenient? I'd
be just as happy to do that.
I can imagine cases in which it would be important to the user to be
able to write a precise RGBA value into the framebuffer. For an
8-bit/channel framebuffer, glColor4ub() is the natural
The attached patch relaxes the error tolerance for the exactRGBA test.
This test fails with many (all?) GL implementations because the most
signficant M bits of values passed to glColor4us() and glColor4ui()
don't always match the M bits found in the framebuffer. There's
typically a 1-bit
José Fonseca wrote:
The python gallium state tracker is an excellent debugging tool, but one
drawback I noticed on people around me is that it is quite hard to setup
and use. The only thing that the python state tracker needs to be told
is how to create a pipe_screen/pipe_context for the
Luca Barbieri wrote:
Softpipe currently does not saturate colors after add/subtract
blending. This violates the OpenGL specification leading to incorrect
rendering in some cases.
This patch fixes this in the obvious way.
Looks good. I'll commit it.
Note that saturation should also happen
Corbin Simpson wrote:
On 07/15/2009 08:04 AM, Brian Paul wrote:
The attached patch relaxes the error tolerance for the exactRGBA test.
This test fails with many (all?) GL implementations because the most
signficant M bits of values passed to glColor4us() and glColor4ui()
don't always match
Chia-I Wu wrote:
Hi all,
This patch series add per-thread info support to libEGL and fix resource
releasing on display termination.
The first two patches introduce per-thread info and per-api current context
respectively. It uses TLS or pthread if available.
The next two patches
Chia-I Wu wrote:
EGL contexts and surfaces are resources of displays. They should be
managed by displays. This commit adds a bunch of functions to
egldisplay.c to help establish the links between contexts/surfaces and
displays. How links are established is considered opaque outside
Keith Whitwell wrote:
On Fri, 2009-07-17 at 08:13 -0700, Brian Paul wrote:
Michel Dänzer wrote:
On Fri, 2009-07-17 at 10:25 +0100, José Fonseca wrote:
Sorry for the delay. I attempted to test this, but your patches are
pasted inline in the email body, and I don't know an easy way to extract
No. There's no real connection between Mesa and X.org releases.
-Brian
Uros Nedic wrote:
Does it mean we could expect X11R7.5 soon?
Uros
Date: Fri, 17 Jul 2009 09:35:01 -0600
From: bri...@vmware.com
To: Mesa3d-dev@lists.sourceforge.net
Subject: [Mesa3d-dev] Mesa 7.5 release today
I
Brian Paul wrote:
Chia-I Wu wrote:
On Fri, Jul 17, 2009 at 09:13:22AM -0600, Brian Paul wrote:
Sorry for the delay. I attempted to test this, but your patches are
pasted inline in the email body, and I don't know an easy way to
extract
them from evolution without copying and pasting
Mesa 7.5 has been released. Release notes are at
http://mesa3d.org/relnotes-7.5.html
Tarballs are here: http://sourceforge.net/projects/mesa3d/files/
-Brian
--
Enter the BlackBerry Developer Challenge
This is your
I'll take a look at your patch tomorrow (still on vacation). The
glBitmap path shouldn't need any changes. The bitmap cache/texture
should already be a POT size.
-Brian
On Sat, Jul 25, 2009 at 5:07 PM, Patrice Mandinmandin.patr...@orange.fr wrote:
Le Sat, 25 Jul 2009 21:09:40 +0200
Patrice
RALOVICH wrote:
Hi,
I would like to nominate the following patches from master for
inclusion in the 7.5 branch:
ddef7dc87b2001fbe117ee5f24a0c645ee95a03c - this fixes the intel
driver context leak
6d66f23c50ebe8f973757b6fd1b81c9b7920c447 - probably this too, but
definitely
RALOVICH wrote:
On Sat, Jul 18, 2009 at 20:37, RALOVICH,
Kristófkristof.ralov...@gmail.com wrote:
Hi,
I have been going through the GLX sources and found some usages of
USE_XTHREADS.
After grepping the whole tree including the configs directory I have
found some other references too, but
Patrice Mandin wrote:
Le Sun, 26 Jul 2009 10:53:29 -0500
Brian Paul brian.e.p...@gmail.com a écrit:
I'll take a look at your patch tomorrow (still on vacation). The
glBitmap path shouldn't need any changes. The bitmap cache/texture
should already be a POT size.
Yep, just checked
Chia-I Wu wrote:
This silences a compiler warning.
Signed-off-by: Chia-I Wu olva...@gmail.com
I've committed this one.
-Brian
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial.
Nicolai Hähnle wrote:
Am Monday 27 July 2009 02:28:00 schrieb Brian Paul:
The GLSL compiler uses a similar memory allocator. See slang_mem.c.
We should probably lift this code up into src/mesa/main/ and rename
the functions to make it re-usable in drivers, etc.
Ah, cool, I missed
José Fonseca wrote:
On Tue, 2009-07-28 at 08:30 -0700, Brian Paul wrote:
Michał Król wrote:
José Fonseca pisze:
I found one other problem in the way we use 4 x 8bit color formats:
sometimes we interpret them as arithmetically coded in an unsigned (e.g
src/gallium/auxiliary/util/u_tile.c when
Christoph Bumiller wrote:
Michel Dänzer schrieb:
On Tue, 2009-07-28 at 16:47 -0700, Ben Skeggs wrote:
Module: Mesa
Branch: master
Commit: d1b9183e64e819d389688074c3db338bd0d2d80e
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=d1b9183e64e819d389688074c3db338bd0d2d80e
Author:
Chia-I Wu wrote:
On Wed, Jul 29, 2009 at 09:21:15AM -0600, tom fogal wrote:
-#if defined(_MSC_VER)
+#if defined(__STDC_VERSION__) __STDC_VERSION__ = 199901L
+# include stdint.h
+#elif defined(_MSC_VER)
typedef __int8 int8_t;
typedef unsigned __int8uint8_t;
On Thu, Jul 30, 2009 at 10:35 AM, Ian Romanicki...@freedesktop.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
On Wed, Jul 29, 2009 at 7:34 PM, Ian Romanicki...@freedesktop.org wrote:
I've noticed an odd behavior in Mesa's current shader assembler. Given
Pauli Nieminen wrote:
---
.../drivers/dri/radeon/radeon_common_context.h |1 -
src/mesa/drivers/dri/radeon/radeon_lock.c |4 +---
2 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/radeon/radeon_common_context.h
Chia-I Wu wrote:
On Thu, Jul 30, 2009 at 10:37:15AM -0600, Brian Paul wrote:
Chia-I Wu wrote:
On Wed, Jul 29, 2009 at 09:21:15AM -0600, tom fogal wrote:
-#if defined(_MSC_VER)
+#if defined(__STDC_VERSION__) __STDC_VERSION__ = 199901L
+# include stdint.h
+#elif defined(_MSC_VER
Patrice Mandin wrote:
Le Mon, 27 Jul 2009 15:55:26 -0600
Brian Paul bri...@vmware.com a écrit:
Yep, just checked that. There must be another cause why I do not have
any text rendered in progs/samples/blendeq with nouveau backend.
Have you implemented the TGSI_OPCODE_KIL instruction? That's
Bridgman, John wrote:
While testing the r600 mesa driver I noticed that glxgears had
recently started segfaulting on exit. Looks like commit
e87320b5e033...
(July 30 14:22:57 GMT) seems to be where the problem starts.
Is anyone else seeing this behaviour ?
Program received signal
Pauli Nieminen wrote:
This fixes the problem that first frame would report bogus usage values.
Problem was caused because get_frame_usage returned data from previous buffer
swap.
Committed. Thanks.
-Brian
--
Let
Ben, I don't know if you've seen, but I've written Glean tests for
texture swizzle, provoking vertex, etc. in the past few months. I
think they're in the piglit tree already.
-Brian
--
Let Crystal Reports handle the
correctly with i965.
-Brian
/**
* Test OpenGL 2.0 vertex/fragment shaders.
* Brian Paul
* 1 November 2006
*
* Based on ARB version by:
* Michal Krol
* 20 February 2006
*
* Based on the original demo by:
* Brian Paul
* 17 April 2003
*/
#include assert.h
#include string.h
#include stdio.h
On Fri, Aug 7, 2009 at 4:37 PM, Corbin Simpsonmostawesomed...@gmail.com wrote:
So, somebody pointed out that the TG page on Gallium is a bit dated.
I recently moved and updated the Gallium wiki pages which were on the
TG site to freedesktop.org:
http://www.freedesktop.org/wiki/Software/gallium
Chia-I Wu wrote:
This patch series aims to improve resource management of EGL. There are
two things it wants to improve
* Do not assume that eglGetDisplay is the first function called and
various management code is initialized
* Free per-thread info and display when thread or process
Eric Anholt wrote:
This saves mapping the index buffer to get a bounds on the indices that
drivers just drop on the floor in the VBO case (cache win), saves a bonus
walk of the indices in the CheckArrayBounds case, and other miscellaneous
validation. On intel it's a particularly a large win
Committed. Thanks.
-Brian
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application
Pauli Nieminen wrote:
This patch series predicts sizes of emit for next rendering operation. Which
prevents flush while emiting rendering commands.
Improved prediction gives mesa chance to use larger part of ring buffer before
flushing. This should give small performance boost when rendering
Chia-I Wu wrote:
Hi,
This patch series tries to clarify the roles of EGLDriver and
EGLDisplay. It was also mentioned in another thread, and depend on the
driver API overhaul.
The rationale behind the change is every driver provides only a single
EGLDriver instance. That instance is
Chia-I Wu wrote:
Hi,
This patch series updates and combines the 3 series I sent last Friday.
It is sent in a tarball because the first patch alone exceeds the size
limit of the mailing list, and I want to avoid flooding the list again.
They should solve all the concerns in last revision and
Cooper Yuan wrote:
I got it, thanks! Actually, in function st_init_clear(), if I set
bypass_vs_clip_and_viewport as 0, things get better.
Another question is about the function clear_with_quad() provided by
state tracker, this function can clear color/depth buffer through a
quad, but
Tom wrote:
Hello people,
After the merge of the vbo_clean I got a big performance boost when
using VBOs (on my RV515). However, all this improvement disappeared with
this commit, which i isolated with git bisect:
commit f9b8562f32b77a27c872d4c70a86995032541107
Author: Pauli Nieminen
Chia-I Wu wrote:
Hi,
I was playing with the OpenGL ES state tracker in opengl-es branch.
After digging a little into how it is built, I noticed that the dispatch
table is gone. Instead of going through a dispatch table, every call to
OpenGL ES API calls _mesa_XxxxXxxx directly after some
Chia-I Wu wrote:
The first two patches fix two segfaults. One is in core, and the other
is in egl_softpipe.
The 3rd patches removes libX11 dependency. The mechanism depending on
libX11 does not work on newer kernel, and no working driver uses it.
The last patch does a minor refactoring
Chia-I Wu wrote:
On Thu, Aug 20, 2009 at 08:24:52AM -0600, Brian Paul wrote:
IMHO, dispatch table is a good paradigm to deal with such issues because
it is very clear. It dispatches to different sets of functions
depending on the state of current context.
Yes, the dispatch table should go
Dou, Justin wrote:
Hi, All,
When we tried to fix one issue of Conformance Test Suite (zbfunc.c), we
found there was a mismatched bitmap cache with the z-buffer. This cache
is used for bitmap drawn, and it keeps the drawn info such as
positions/width/height. If the next drawn task with the
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
In the next couple hours I'm planning to merge the asm-shader-rework-1
branch to master. In my testing I have found that it passes at least as
many (and in a couple cases more) tests than the current code. One of
Chia-I Wu wrote:
Hi,
This patch series was sent about 1 month ago. It went through several
iterations, and should have resolved all concerns. The patches were
scattered in that thread.
This mail resends the series, with updated commit logs. It fixes random
crashes at initialization
Chia-I Wu wrote:
While overhauling the driver api, one of the goals is to make it
possible that a _EGLDriver can drive multiple _EGLDisplay.
Most drivers still store per-display data in _EGLDriver. This patch
series moves per-display data to where they should be, _EGLDisplay.
Along the
Chia-I Wu wrote:
On Wed, Aug 26, 2009 at 06:34:00AM -0700, Dan Nicholson wrote:
On Tue, Aug 25, 2009 at 10:23 PM, Chia-I Wuolva...@gmail.com wrote:
This patch makes EGL/X progs link to libX11. Originally, libEGL linked
to libX11 and thus there was no need for progs to link to libX11.
On Thu, Aug 27, 2009 at 8:53 AM, marvi...@gmx.de wrote:
From: root r...@fb07-iapwap2.physik.uni-giessen.de
---
src/mesa/shader/prog_print.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
Committed (with one additional stdout-stderr) to the mesa_7_5_branch.
I'll
Chia-I Wu wrote:
On Tue, Aug 25, 2009 at 03:54:14PM +0800, Chia-I Wu wrote:
I use the dispatch table in eagle, it's pretty easy to hook up. I put
all the dispatch table related files under glapi/ and there's a
makefile target (import-glapi) to import the files from mesa.
Great. But I think
On Sat, Aug 29, 2009 at 1:01 PM, Marc Dietrichmarvi...@gmx.de wrote:
updates tgsi opcodes and fixes an assertion
Committed. Thanks.
-Brian
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
Eric Anholt wrote:
On Sat, 2009-08-29 at 11:24 -0700, Jose Fonseca wrote:
Eric,
This change broke softpipe on master (eg. terrain), and probably all gallium
based drivers. I'm pretty sure the vbo module was working correctly without
it, so there might be a different in the interpretation
Marc Dietrich wrote:
When cross compiling on a 64bit machine, gen_matypes.c is build
for the host machine (64bit) but must generates code for the target
machine (32bit). This causes wrong offsets all over the place and
crashes googleearth on my machine. Solution is to add -m32 when
cross
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I just pushed a branch that implements the new GL_ARB_sync extension.
It is currently only supported for the software rasterizer, but I
believe the Eric and I will be able to add support to the Intel drivers
(that use GEM)
Unfortunately gcc (version 4.3.2 anyway) warns on this:
main/texenvprogram.c:87: warning: type of bit-field ‘Source’ is a GCC
extension
main/texenvprogram.c:88: warning: type of bit-field ‘Operand’ is a GCC
extension
I'm trying to find a #pragma or something to silence the warning...
-Brian
Chris Wilson wrote:
Only use the active part of the state key and ignore all the texture units
beyond Const.MaxTextureUnits. For instance on my i915, this reduces
sizeof(struct state_key) from 196 to 100 bytes.
Actually, we can do better than that. If we use key-nr_enabled_units
instead of
José Fonseca wrote:
On Wed, 2009-09-02 at 07:48 -0700, Brian Paul wrote:
Module: Mesa
Branch: master
Commit: 83e4470d9a3367883b3fe699629f1d8648459a89
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=83e4470d9a3367883b3fe699629f1d8648459a89
Author: Brian Paul bri...@vmware.com
Gary Wong wrote:
On Wed, Sep 02, 2009, Brian Paul wrote:
Unfortunately gcc (version 4.3.2 anyway) warns on this:
main/texenvprogram.c:87: warning: type of bit-field ‘Source’ is a GCC
extension
main/texenvprogram.c:88: warning: type of bit-field ‘Operand’ is a GCC
extension
I'm trying
Keith Whitwell wrote:
On Wed, 2009-09-02 at 09:12 -0700, Brian Paul wrote:
Module: Mesa
Branch: master
Commit: 4b08e7498230eac30eea1721f33994b30999acd4
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=4b08e7498230eac30eea1721f33994b30999acd4
Author: Brian Paul bri...@vmware.com
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Wilson wrote:
By rearranging the bitfields within the key we can reduce the size
of the key from 644 to 196 bytes, reducing the cost of both the
hashing and equality tests.
How did you arrive at these numbers? Is
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chia-I Wu wrote:
This RFC patch series tries to bring OpenGL ES support to master. It is
based on the work of opengl-es branch. The patch series is too large to
send to the list. It is available here
I'll try to look
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
I'm intending to create a mesa_7_6_branch tomorrow (Friday) morning. As
usual, this branch is intended for bug fixes leading to a 7.6 release.
I'm open to discussion, but my preference is that the branch be used in
Mesa 7.5.1 is now available. This is a bug-fix release. For details,
see the release notes at http://www.mesa3d.org/relnotes-7.5.1.html
Download site: ftp://ftp.freedesktop.org/pub/mesa/7.5.1/
The tarballs are now on the freedesktop.org server rather than
SourceForge. SourceForge changed
Michel Dänzer wrote:
On Thu, 2009-09-03 at 14:43 -0700, Ian Romanick wrote:
2. It becomes increasing difficult to merge (as opposed to cherry-pick)
from one branch to the other as the branches diverge. Michel has run
into this.
At least in the case I assume you're referring to, it would
Keith Whitwell wrote:
On Thu, 2009-09-03 at 15:13 -0700, Michel Dänzer wrote:
On Thu, 2009-09-03 at 14:43 -0700, Ian Romanick wrote:
2. It becomes increasing difficult to merge (as opposed to cherry-pick)
from one branch to the other as the branches diverge. Michel has run
into this.
At
michal wrote:
C:\src\mesascons platform=windows debug=1
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
Compiling src\mesa\shader\program_parse.tab.c ...
program_parse.tab.c
program_parse.tab.c(254) : error C2365: 'POINT' :
Hugh Fisher wrote:
This is my attempt at explaining the top level structure
of the Mesa3D source code:
http://cs.anu.edu.au/~Hugh.Fisher/mesa3d/topLevelMap.html
If anyone thinks it would be useful, feel free to take a
copy and do what you like with it. (If you find any serious
errors,
Dimitar Kodjabachev wrote:
Hello,
I sent this to mesa3d-dev, which was probably not the right place.
mesa3d-dev is OK since there may be a bug in the Mesa wgl code. I'm
cc'ing mesa3d-dev.
I have the following situation (pseudocode) with Mesa 7.4.4:
hglrc1 = wglCreateContext(hdc1)
These new tests look fine, but maybe someone (Nicolai?) should set up
a piglit mailing list. Plus a list for piglit git commits.
-Brian
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
Jakob Bornecrantz wrote:
Hi Eric
It looks like commit b4922b53 mesa: Add support for ARB_depth_clamp.
breaks gallium drivers, this is because you are calling init_c_cliprects
from src/mesa/main/enable.c and in gallium math/m_xform.c is not
included in the build so I get a undefine symbol
2009/9/5 Artur Wyszynski aljen-mli...@o2.pl:
Hey, attached patch adds support for HaikuOS
Regards, Artur Wyszynski
Committed. Thanks!
-Brian
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
Thomas Jose, I think you are most familiar with this code...
The attached patch fixes a bug I found with softpipe and
glDrawPixels(GL_STENCIL_INDEX).
The failing case was basically:
glClear(GL_STENCIL_BUFFER_BIT);
...
glDrawPixels(GL_STENCIL_INDEX).
Drawing stencil images is done by mapping
Brian Paul wrote:
Thomas Jose, I think you are most familiar with this code...
The attached patch fixes a bug I found with softpipe and
glDrawPixels(GL_STENCIL_INDEX).
The failing case was basically:
glClear(GL_STENCIL_BUFFER_BIT);
...
glDrawPixels(GL_STENCIL_INDEX).
Drawing stencil
601 - 700 of 1059 matches
Mail list logo
