I see the tarballs, but there doesn't seem to be a mesa-7.11-rc3 tag in
git and 7.11 branch doesn't seem to have had a version bump commit.
Has someone forgotten to push?
signature.asc
Description: This is a digitally signed message part
___
mesa-dev m
On Jul 25, 2011, at 8:02 PM, Ian Romanick wrote:
>
>> Can we please get a 7.10.4 release with this fixed? It's not a bug
>> in libarchive; you just get lucky that gnutar doesn't complain (which
>> I think *is* a bug in gnutar).
>
> Does this still occur in the 7.11-rc3 tarballs?
It's the same
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/25/2011 09:26 AM, Jeremy Huddleston wrote:
> Can we please get a 7.10.4 release with this fixed? It's not a bug
> in libarchive; you just get lucky that gnutar doesn't complain (which
> I think *is* a bug in gnutar).
Does this still occur in th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mesa 7.11-rc3 has been released. This is a release candidate for the
7.11 development release.
The tag in the GIT repository for Mesa 7.11-rc3 is 'mesa-7.11-rc3'.
Mesa 7.11-rc3 is available for download at
ftp://freedesktop.org/pub/mesa/7.11/
md5su
On Mon, 25 Jul 2011 17:07:09 -0700, Kenneth Graunke
wrote:
> According to the documentation for 3DSTATE_DEPTH_BUFFER (G45 and
> beyond), the 3 LSBs of "Depth Coordinate Offset X" (and Y) must be 0.
>
> Detect this and apply the Gen4 miptree hack for working around
> unsupported offsets.
>
> Fix
On Tue, 26 Jul 2011 01:30:44 +0200, Henri Verbeet wrote:
> On 26 July 2011 01:02, Eric Anholt wrote:
> > I don't see that, because the while (buf < MaxDrawBuffers) loop would
> > notice the change from COLOR1 -> NONE.
> That loop doesn't happen because n == 1 for {COLOR0} (as opposed to
> {COLOR0
On Mon, Jul 25, 2011 at 7:53 PM, Ian Romanick wrote:
> v2 fixes a spelling mistake in 3/3 noticed by Henri Verbeet. It also fixes
> the GL_COMPRESSED_RED and GL_COMPRESSED_RG base types, as pointed out by Brian
> Paul.
>
> Although these patches are going to miss the RC3 cut-off, I'd like to see
This was done in the old codegen path, but not the new one.
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
in
From: Ian Romanick
The implementation deviated slightly from the GL_EXT_texture_sRGB spec
and from other implementations. A giant comment block was added to
justify the somewhat odd behavior of this function.
In addition, the interface had unnecessary cruft. The 'all' parameter
was false at al
From: Ian Romanick
If an application requests a generic compressed format for a texture
and the driver does not pick a specific compressed format, return the
generic base format (e.g., GL_RGBA) for the GL_TEXTURE_INTERNAL_FORMAT
query.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=3165
From: Ian Romanick
---
src/mesa/main/texcompress.c | 88 +++
src/mesa/main/texcompress.h |3 +
2 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/texcompress.c b/src/mesa/main/texcompress.c
index d820ae9..040be94 100644
---
v2 fixes a spelling mistake in 3/3 noticed by Henri Verbeet. It also fixes
the GL_COMPRESSED_RED and GL_COMPRESSED_RG base types, as pointed out by Brian
Paul.
Although these patches are going to miss the RC3 cut-off, I'd like to see them
included in 7.11. They are pretty low impact. Opinions?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/25/2011 03:39 PM, Eric Anholt wrote:
> This appears in our instruction stream as a result of the
> brw_vs_constval.c handling.
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 43
> ++
> src/mesa/drivers/dri/i965
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/25/2011 01:23 PM, Henri Verbeet wrote:
> Without this we'd miss an update when doing a sequence like {COLOR0, COLOR1},
> {COLOR0}, {COLOR0, COLOR1}.
Is there a piglit test to reproduce this failure?
> NOTE: This is a candidate for the 7.10 and
According to the documentation for 3DSTATE_DEPTH_BUFFER (G45 and
beyond), the 3 LSBs of "Depth Coordinate Offset X" (and Y) must be 0.
Detect this and apply the Gen4 miptree hack for working around
unsupported offsets.
Fixes piglit test fbo-clear-formats for GL_ARB_depth_texture and
GL_EXT_packed
The apitrace dump in bug #34009 managed to fool the draw_offset check
into thinking that we were tile aligned when we weren't. This led to an
assertion failure in brw_update_renderbuffer_surface with tile_y != 0.
Simply compute tile_x and tile_y and check those, as that way both
places are checki
(Strange thought sent that before - mail client going crazy...)
> Resolving color buffers is pretty well defined (for standard msaa at
> least). I have no idea how that's supposed to be defined for depth
> and stencil values. Frankly I'm not sure what glBlitFramebuffer is
> supposed to do here, ma
On 26 July 2011 01:02, Eric Anholt wrote:
> I don't see that, because the while (buf < MaxDrawBuffers) loop would
> notice the change from COLOR1 -> NONE.
That loop doesn't happen because n == 1 for {COLOR0} (as opposed to
{COLOR0, NONE}). Perhaps we should always explicitly set any remaining
buff
Hi,
sorry for the late reply. I have just sent a patch to ML which should
fix this. See:
http://lists.freedesktop.org/archives/mesa-dev/2011-July/009867.html
Please let me know if that works for you.
Marek
On Mon, Jul 18, 2011 at 2:45 PM, Jon TURNEY wrote:
> On 14/07/2011 02:05, Marek Olšák w
On 07/25/2011 09:13 PM, Kenneth Graunke wrote:
> The apitrace dump in bug #34009 managed to fool the draw_offset check
> into thinking that we were tile aligned when we weren't. This led to an
> assertion failure in brw_update_renderbuffer_surface with tile_y != 0.
>
> Simply compute tile_x and t
Otherwise xlib-based llvmpipe fails to link.
NOTE: This is a candidate for the 7.11 branch.
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 40924a9..1b1823a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -951,7 +951,7 @
---
configure.ac | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5c832e6..40924a9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1936,11 +1936,12 @@ if test "x$with_gallium_drivers" != x; then
gallium_check_st "no
On Mon, 25 Jul 2011 22:23:47 +0200, Henri Verbeet wrote:
> Without this we'd miss an update when doing a sequence like {COLOR0, COLOR1},
> {COLOR0}, {COLOR0, COLOR1}.
I don't see that, because the while (buf < MaxDrawBuffers) loop would
notice the change from COLOR1 -> NONE. And on transition ba
On Mon, 25 Jul 2011 21:13:42 -0700, Kenneth Graunke
wrote:
> The apitrace dump in bug #34009 managed to fool the draw_offset check
> into thinking that we were tile aligned when we weren't. This led to an
> assertion failure in brw_update_renderbuffer_surface with tile_y != 0.
>
> Simply comput
The FF VS generation happens just after the FF FS generation in
state.c, so the ctx->VP._Current value is for the previous state
update's vertex shader, not the one that will be chosen as a result of
this state update. The vertexShader and vertexProgram variables
should be accurately telling us wh
---
src/mesa/drivers/dri/i965/brw_fs_emit.cpp |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
b/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
index 1d89b8f..eecfc92 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
+++ b/src/me
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 7e9ce04..6d91668 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drive
We have to make it through this loop processing the color multiple
times, so we can't go overwriting it on our first color buffer.
---
src/gallium/drivers/softpipe/sp_quad_blend.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/softpipe/
This reverts commit 3412069e23b7fa5656262f3dd1aa86f66980594d. We're
about to start using it in fragment shaders to handle avoiding
projection for fixed function.
---
src/mesa/drivers/dri/i965/brw_vs_constval.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/sr
Removes 0.8% of the fragment shader instructions on Unigine Tropics.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 24 ++--
1 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index d072e22
This is part of fixing a ~1% performance regression in OpenArena when
changing the fixed function fragment shader to using the new backend.
Right now this just avoids the LINTERP of the projector, not the math
using it.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 18 +++---
1 files ch
This appears in our instruction stream as a result of the
brw_vs_constval.c handling.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 43 ++
src/mesa/drivers/dri/i965/brw_fs.h |1 +
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/
> On 07/25/2011 10:43 PM, Roland Scheidegger wrote:
> >>
> >> On 07/25/2011 09:03 PM, Roland Scheidegger wrote:
> On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
> >> Resolve via glBlitFramebuffer allows resolving a sub-region of
> >> a
> >> renderbuffer to a different location i
On 07/25/2011 10:43 PM, Roland Scheidegger wrote:
>>
>> On 07/25/2011 09:03 PM, Roland Scheidegger wrote:
On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
>> Resolve via glBlitFramebuffer allows resolving a sub-region of a
>> renderbuffer to a different location in any mipmap level of
>
> On 07/25/2011 09:03 PM, Roland Scheidegger wrote:
> >> On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
> Resolve via glBlitFramebuffer allows resolving a sub-region of a
> renderbuffer to a different location in any mipmap level of some
> other texture, therefore location and
On 07/25/2011 09:03 PM, Roland Scheidegger wrote:
>> On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
Resolve via glBlitFramebuffer allows resolving a sub-region of a
renderbuffer to a different location in any mipmap level of some
other texture, therefore location and size paramete
Without this we'd miss an update when doing a sequence like {COLOR0, COLOR1},
{COLOR0}, {COLOR0, COLOR1}.
NOTE: This is a candidate for the 7.10 and 7.11 branches.
Signed-off-by: Henri Verbeet
---
src/mesa/main/buffers.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git
> On Mon, Jul 25, 2011 at 7:54 PM, Roland Scheidegger
> wrote:
> > You cannot resolve depth and stencil buffers in d3d10/11 and I'm
> > not convinced it even makes a whole lot of sense (especially for
> > the stencil buffer). Some hw will potentially be unable to do this
> > (I don't know how defe
> On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
> >> Resolve via glBlitFramebuffer allows resolving a sub-region of a
> >> renderbuffer to a different location in any mipmap level of some
> >> other texture, therefore location and size parameters are needed.
> >>
> >> The mask parameter was add
The previous commit removed the last use of this field.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/intel/intel_fbo.c |1 -
src/mesa/drivers/dri/intel/intel_fbo.h |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
Perhaps this should be squashed with patch 1?
diff --git
The apitrace dump in bug #34009 managed to fool the draw_offset check
into thinking that we were tile aligned when we weren't. This led to an
assertion failure in brw_update_renderbuffer_surface with tile_y != 0.
Simply compute tile_x and tile_y and check those, as that way both
places are checki
On Mon, Jul 25, 2011 at 7:54 PM, Roland Scheidegger wrote:
> You cannot resolve depth and stencil buffers in d3d10/11 and I'm not
> convinced it even makes a whole lot of sense (especially for the stencil
> buffer). Some hw will potentially be unable to do this (I don't know how
> deferred rend
I have no objection FWIW.
Jose
- Original Message -
> This is a revised version of my previous patches. Patch 1
> incorporates
> Brian's feedback, and patch 2 is unchanged from before. I did test
> patch 2
> without patch 1, and found that both patches are neeeded for
> force_s3tc_enabl
NOTE: This is a candidate for the 7.10 and 7.11 branches.
---
src/gallium/auxiliary/util/u_format_s3tc.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_format_s3tc.c
b/src/gallium/auxiliary/util/u_format_s3tc.c
index bb989c2..d8a7c0
NOTE: This is a candidate for the 7.10 and 7.11 branches.
---
src/mesa/state_tracker/st_extensions.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 99b231d..b5f6d35 100644
--
This is a revised version of my previous patches. Patch 1 incorporates
Brian's feedback, and patch 2 is unchanged from before. I did test patch 2
without patch 1, and found that both patches are neeeded for force_s3tc_enable
to work.
Both of these are candidates for 7.10 and 7.11, since games su
On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
>> Resolve via glBlitFramebuffer allows resolving a sub-region of a
>> renderbuffer to a different location in any mipmap level of some
>> other texture, therefore location and size parameters are needed.
>>
>> The mask parameter was added because r
Signed-off-by: Tobias Droste
Acked-by: Jakob Bornecrantz
Reviewed-by: Marek Olšák
---
src/gallium/targets/egl-static/Makefile | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/gallium/targets/egl-static/Makefile
b/src/gallium/targets/egl-static/Makefile
in
> Resolve via glBlitFramebuffer allows resolving a sub-region of a
> renderbuffer to a different location in any mipmap level of some
> other texture, therefore location and size parameters are needed.
>
> The mask parameter was added because resolving only depth or only
> stencil of a combined bu
https://bugs.freedesktop.org/show_bug.cgi?id=39307
Christian König changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
> This only checks power of 2 sample counts for now, but maybe we would
> like to probe the values in between too ...
Looks good to me. I don't think anyone ever supported odd sample counts (and no
quincunx doesn't count...) though pre-r600 radeons supported 2,4,6. In any case
if someone wants t
Can we please get a 7.10.4 release with this fixed? It's not a bug in
libarchive; you just get lucky that gnutar doesn't complain (which I think *is*
a bug in gnutar).
Some users are running into problems using gnutar with this archive, so that's
not really a great fallback either:
https://tra
https://bugs.freedesktop.org/show_bug.cgi?id=39515
Dave Witbrodt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 07/25/2011 02:47 PM, Christoph Bumiller wrote:
> Resolve via glBlitFramebuffer allows resolving a sub-region of a
> renderbuffer to a different location in any mipmap level of some
> other texture, therefore location and size parameters are needed.
>
> The mask parameter was added because resol
https://bugs.freedesktop.org/show_bug.cgi?id=39527
--- Comment #1 from Marek Olšák 2011-07-25 07:00:20 PDT ---
Please attach an apitrace file.
Apitrace can record and replay opengl commands. You can get it here:
https://github.com/apitrace/apitrace
--
Configure bugmail: https://bugs.freedeskto
https://bugs.freedesktop.org/show_bug.cgi?id=39527
Summary: 3D Driving-School - missing textures
Product: Mesa
Version: git
Platform: All
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
...
>From 3a63ebc31e91d7bf927c55c7fca9fe190984b16c Mon Sep 17 00:00:00 2001
From: Christoph Bumiller
Date: Mon, 25 Jul 2011 14:21:29 +0200
Subject: [PATCH 6/6] nv50: implement resource_resolve with custom blit
---
src/gallium/drivers/nv50/nv50_context.h|3 +-
src/gallium/drivers/nv50
...
>From 2d57a1ee06b9d370bae6f9b8d8e59de180d2584a Mon Sep 17 00:00:00 2001
From: Christoph Bumiller
Date: Mon, 25 Jul 2011 14:14:01 +0200
Subject: [PATCH 5/6] st/mesa: implement multisample resolve via BlitFramebuffer
---
src/gallium/auxiliary/util/u_box.h | 25 +
src/mesa/state_trac
Resolve via glBlitFramebuffer allows resolving a sub-region of a
renderbuffer to a different location in any mipmap level of some
other texture, therefore location and size parameters are needed.
The mask parameter was added because resolving only depth or only
stencil of a combined buffer is poss
This only checks power of 2 sample counts for now, but maybe we would
like to probe the values in between too ...
nv50 for example can store 12 "coverage samples" in a depth surface, but
they have to be used in a hardware specific way together with
multisampled colour surfaces (which are always po
https://bugs.freedesktop.org/show_bug.cgi?id=39307
--- Comment #4 from Andy Furniss 2011-07-25
05:00:05 PDT ---
(In reply to comment #2)
> Mhm, Emeric you patch looks quite right to me.
>
> But honestly, I couldn't find an MPEG1 to test it.Emeric you patch looks quite
> right to me.
>
> But ho
Christian König wrote:
Hi,
sorry for the late reply, have been in Canada on a team meeting.
Did you got it working Andy or do you need some more help?
It's OK, now thanks.
I have started setting LDFLAGS as Dan suggested.
I think the overall situation with finding libraries in the mesa
mak
https://bugs.freedesktop.org/show_bug.cgi?id=39307
--- Comment #3 from almos 2011-07-25 01:46:15 PDT ---
(In reply to comment #2)
> Mhm, Emeric you patch looks quite right to me.
>
> But honestly, I couldn't find an MPEG1 to test it.Emeric you patch looks quite
> right to me.
>
> But honestly,
https://bugs.freedesktop.org/show_bug.cgi?id=39515
--- Comment #1 from Benjamin Franzke
2011-07-25 00:52:24 PDT ---
Thanks, should be fixes by 42cdf4074e0f7d561b03a86255fa8f916f906bf6.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mai
64 matches
Mail list logo
