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
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,
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 #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
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
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
...
>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
...
>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
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
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
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=39515
Dave Witbrodt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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
> 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
https://bugs.freedesktop.org/show_bug.cgi?id=39307
Christian König changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
> 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
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
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
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
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
--
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
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
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
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
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
> 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
> 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
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 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
>
> 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 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 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
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/
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
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 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
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/
---
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
---
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
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
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
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
---
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
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 @
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
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 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
(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
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
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
-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
-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
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?
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
---
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
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
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
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
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, 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
-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
-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
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
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
64 matches
Mail list logo
