https://bugs.freedesktop.org/show_bug.cgi?id=87886
--- Comment #4 from Kenneth Graunke ---
And it turns out we can eliminate the rest of them pretty easily too:
http://lists.freedesktop.org/archives/mesa-dev/2014-December/073490.html
http://lists.freedesktop.org/archives/mesa-dev/2014-December/07
Valve games use GL_SRGB8 textures. Instead of supporting that properly,
we fell back to MESA_FORMAT_R8G8B8A8_SRGB (with an alpha channel), which
meant that we had to use texture swizzling to override the alpha to 1.0
when sampling. This meant shader recompiles on Gen < 7.5 platforms.
By supporti
The logic in brw_blorp_surface_info::set uses brw_format_for_mesa_format
for source surfaces, and brw->render_target_format[] for destination
surfaces. We should do the same in the sRGB MSAA overrides.
Currently, this isn't a problem, since SRGB MSAA buffers are all RGBA.
The next commit will int
Fold MAD dst, src0, immed, src2 (or src0/immed swapped) when
- immed = 0 -> MOV dst, src2
- immed = +/- 1 -> ADD dst, src0, src2
These types of MAD pattersn were observed in some st/nine shaders.
Signed-off-by: Ilia Mirkin
---
Haven't tested this enough to push yet, but thought I'd get it out
Nice! Both are
Reviewed-by: Chris Forbes
On Jan 1, 2015 5:04 PM, "Kenneth Graunke" wrote:
> Gen7.5+ platforms that support the "Shader Channel Select" feature leave
> key->tex.swizzles[i] as SWIZZLE_NOOP except when GL_DEPTH_TEXTURE_MODE
> is GL_ALPHA (which is really uncommon). So, the precom
On Wed, Dec 31, 2014 at 8:04 PM, Kenneth Graunke wrote:
> ir_to_mesa does this - apparently we just forgot or something.
>
> Without this, we'll guess the wrong texture swizzle (XYZW for color
> instead of XXX1 for depth) when doing precompiles.
>
> This cuts 26 shader recompiles in a time demo of
https://bugs.freedesktop.org/show_bug.cgi?id=87886
--- Comment #3 from Kenneth Graunke ---
I discovered a bug in the i965 driver: the precompile was guessing the texture
swizzle incorrectly.
These two patches should cut around 40% of the recompiles:
http://lists.freedesktop.org/archives/mesa-dev
Gen7.5+ platforms that support the "Shader Channel Select" feature leave
key->tex.swizzles[i] as SWIZZLE_NOOP except when GL_DEPTH_TEXTURE_MODE
is GL_ALPHA (which is really uncommon). So, the precompile should leave
them as SWIZZLE_NOOP (aka SWIZZLE_XYZW) as well.
We didn't notice this because pr
ir_to_mesa does this - apparently we just forgot or something.
Without this, we'll guess the wrong texture swizzle (XYZW for color
instead of XXX1 for depth) when doing precompiles.
This cuts 26 shader recompiles in a time demo of "Counter Strike:
Global Offensive" (58 -> 32) on Sandybridge. Has
https://bugs.freedesktop.org/show_bug.cgi?id=52465
Vinson Lee changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=79471
Vinson Lee changed:
What|Removed |Added
CC||bri...@vmware.com,
|
https://bugs.freedesktop.org/show_bug.cgi?id=87926
Bug ID: 87926
Summary: [softpipe] SIGSEGV
draw/draw_pt_fetch_shade_pipeline.c:161
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
On Tue, Dec 16, 2014 at 10:59 AM, Laura Ekstrand wrote:
> This happens almost everywhere. I prefer to call _mesa_error(ctx,
> "glTex%sStorage" rather than _mesa_error(ctx, "%s" because it's
> more obvious when reading the code which API function you're in (texture
> storage rather than c
On Wed, Dec 31, 2014 at 5:26 PM, Laura Ekstrand wrote:
> ---
> src/mesa/main/texobj.c | 23 ++-
> src/mesa/main/texobj.h | 4
> 2 files changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
> index 126b523..82d52c5 100
On Wed, Dec 31, 2014 at 4:42 PM, Laura Ekstrand wrote:
> I began adding to my comment as you suggested, but found out that cube
> completeness only applies to the base level of a cube map. So I had to
> modify this patch to check for cube completeness of an arbitrary level. I
> will be sending o
This is part of a potential solution to Khronos Bug 13223. Cube completeness
is a concept from glGenerateMipmap, but it seems reasonable to check for it in
GetTextureImage when the target is GL_TEXTURE_CUBE_MAP.
---
src/mesa/main/texgetimage.c | 41 +
1 fil
---
src/mesa/main/texobj.c | 23 ++-
src/mesa/main/texobj.h | 4
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index 126b523..82d52c5 100644
--- a/src/mesa/main/texobj.c
+++ b/src/mesa/main/texobj.c
@@ -806
This is part of a potential solution to Khronos Bug 13223. Cube completeness
is a concept from glGenerateMipmap, but it seems reasonable to check for it in
TextureSubImage when target=GL_TEXTURE_CUBE_MAP.
---
src/mesa/main/teximage.c | 42 +-
1 file changed
When trying to address Anuj Phogat's comment on Patch 40/41 of my direct state
access textures patch series, I realized that the concept of cube completeness
only checks the base level of a cube map for consistency among formats and
sizes. This series checks an arbitrary level of a cube map for co
On Wed, Dec 31, 2014 at 4:59 PM, Kenneth Graunke wrote:
> Hardcoding stderr is wrong; INTEL_DEBUG=optimizer uses other files.
Whoops! Thanks Ken. Both are
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.f
https://bugs.freedesktop.org/show_bug.cgi?id=87886
--- Comment #2 from Kenneth Graunke ---
(In reply to Eero Tamminen from comment #1)
> (I haven't seen anything like that on HSW in those games.)
You won't - all of the reporter's recompiles are due to EXT_texture_swizzle or
DEPTH_TEXTURE_MODE sw
https://bugs.freedesktop.org/show_bug.cgi?id=79706
Bug 79706 depends on bug 85529, which changed state.
Bug 85529 Summary: Surfaces not drawn in Unvanquished
https://bugs.freedesktop.org/show_bug.cgi?id=85529
What|Removed |Added
-
Hardcoding stderr is wrong; INTEL_DEBUG=optimizer uses other files.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4.cpp | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
In order to support calling opt_vector_float() inside a condition, this
patch makes OPT() a statement expression:
https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
We've used that elsewhere already.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 20 ++
I began adding to my comment as you suggested, but found out that cube
completeness only applies to the base level of a cube map. So I had to
modify this patch to check for cube completeness of an arbitrary level. I
will be sending out a new patch "Checking for cube completeness in
GetTextureImag
* More gallium-like
* Leverage stamps properly and don't call mesa functions
---
src/gallium/state_trackers/hgl/hgl.c | 338 +++-
src/gallium/state_trackers/hgl/hgl_context.h | 13 +-
.../targets/haiku-softpipe/GalliumContext.cpp | 59 +++--
.../target
---
src/mapi/glapi/gen/gl_API.xml | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index e1b1246..d7d0627 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@ -8247,7 +8247,11 @@
h
---
src/glsl/glcpp/glcpp-parse.y| 3 +++
src/glsl/glsl_parser_extras.cpp | 1 +
src/glsl/glsl_parser_extras.h | 2 ++
src/mesa/main/extensions.c | 1 +
src/mesa/main/mtypes.h | 1 +
5 files changed, 8 insertions(+)
diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glc
On Mon, Dec 15, 2014 at 5:22 PM, Laura Ekstrand wrote:
> This is part of a potential solution to Khronos Bug 13223. Cube completeness
> is a concept from glGenerateMipmap, but it seems reasonable to check for it in
> GetTextureImage when the target is GL_TEXTURE_CUBE_MAP.
Add this to the comment
On Wed, Dec 31, 2014 at 3:03 PM, Eric Anholt wrote:
> Ilia Mirkin writes:
>
>> Signed-off-by: Ilia Mirkin
>
> VC4 doesn't support this, so it shouldn't be enabled by default.
VC4 also doesn't support core contexts. The extension is supposed to
only be enabled for GL3.3+, which I've approximated
Use shorter commit messages in present tense:
"main: Fix texObj->Immutable flag update in _mesa_texture_image_multisample"
On Mon, Dec 15, 2014 at 5:22 PM, Laura Ekstrand wrote:
> ---
> src/mesa/main/teximage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/mai
Ilia Mirkin writes:
> Signed-off-by: Ilia Mirkin
VC4 doesn't support this, so it shouldn't be enabled by default.
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/
On Mon, Dec 15, 2014 at 5:22 PM, Laura Ekstrand wrote:
> ---
> src/mapi/glapi/gen/ARB_direct_state_access.xml | 4 ++
> src/mesa/main/genmipmap.c | 73
> +++---
> src/mesa/main/genmipmap.h | 6 +++
> 3 files changed, 64 insertions(+
On Wed, Dec 31, 2014 at 11:21 AM, Anuj Phogat wrote:
> On Mon, Dec 15, 2014 at 5:22 PM, Laura Ekstrand wrote:
>> ---
>> src/mapi/glapi/gen/ARB_direct_state_access.xml | 9 +
>> src/mesa/main/texgetimage.c| 315
>> +++--
>> src/mesa/main/texgetimage.h
On Mon, Dec 15, 2014 at 5:22 PM, Laura Ekstrand wrote:
> ---
> src/mapi/glapi/gen/ARB_direct_state_access.xml | 7 +
> src/mesa/main/texgetimage.c| 169
> ++---
> src/mesa/main/texgetimage.h| 12 ++
> 3 files changed, 143 insertions(
On Mon, Dec 15, 2014 at 5:22 PM, Laura Ekstrand wrote:
> ---
> src/mapi/glapi/gen/ARB_direct_state_access.xml | 9 +
> src/mesa/main/texgetimage.c| 315
> +++--
> src/mesa/main/texgetimage.h| 9 +
> 3 files changed, 267 insertions(+
Seems reasonable to me.
Reviewed-by: Chris Forbes
On Fri, Dec 19, 2014 at 1:45 AM, Kenneth Graunke wrote:
> This is a partial revert of c89306983c07e5a88c0d636267e5ccf263cb4213.
> It split the {start,base}_vertex_location handling into several steps:
>
> 1. Set brw->draw.start_vertex_location =
On Mon, Dec 15, 2014 at 5:22 PM, Laura Ekstrand wrote:
> In implementing ARB_DIRECT_STATE_ACCESS functions, it is often necessary to
> abstract the functionality of a traditional GL API function into a backend
> that both the traditional and dsa API functions can share. For instance,
> glTexParam
From: Leonid Shatz
The "normal" detection (querying clflush size) already made sure it is
non-zero, however another method did not. This lead to crashes if this
value happened to be zero (apparently can happen in virtualized environments
at least).
This fixes https://bugs.freedesktop.org/show_bug
From: Roland Scheidegger
The code used PIPE_ALIGN_VAR for the variable used by fxsave, however this
does not work if the stack isn't aligned. Hence use PIPE_ALIGN_STACK function
decoration to fix the segfault which can happen if stack alignment is only
4 bytes.
This fixes https://bugs.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=87913
--- Comment #3 from Roland Scheidegger ---
I'm wondering if we actually should use this detection method if the other one
(which queries clflush size in fact) is also available. I guess though there's
some (amd) cpus where the other method isn't
https://bugs.freedesktop.org/show_bug.cgi?id=87658
--- Comment #21 from Roland Scheidegger ---
(In reply to Chris Paulson-Ellis from comment #20)
> (In reply to Roland Scheidegger from comment #19)
> > Maybe using
> > PIPE_ALIGN_STACK static INLINE boolean sse2_has_daz(void)
> > would do the tric
https://bugs.freedesktop.org/show_bug.cgi?id=87913
--- Comment #2 from Leonid Shatz ---
Sorry, the correct code would be something like:
if (regs[0] >= 0x8006) {
cpuid(0x8006, regs2);
+ if ((regs2[2] & 0xFF) > 0)
util_cpu_caps.cacheline = regs2[2] & 0xFF;
https://bugs.freedesktop.org/show_bug.cgi?id=87913
Leonid Shatz changed:
What|Removed |Added
CC||leonid.shatz@ravellosystems
https://bugs.freedesktop.org/show_bug.cgi?id=87913
Bug ID: 87913
Summary: CPU cacheline size of 0 can be returned by CPUID leaf
0x8006 in some virtual machines
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=87886
Eero Tamminen changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1 from Eero Tammin
https://bugs.freedesktop.org/show_bug.cgi?id=86651
Chris Wilson changed:
What|Removed |Added
Component|GLX |tests
Assignee|mesa-dev@lists.f
47 matches
Mail list logo
