Re: [Mesa-dev] [PATCH] Revert radeon/llvm: enable unsafe math for graphics shaders
On 18.02.2015 16:52, Grigori Goronzy wrote:
Hi,
AFAIR not enabling this makes LLVM generate really slow code in some
common cases. Maybe this is just a bug in LLVM/R600 triggered by unsafe
FP math optimization or some optimization is too eager. Other drivers do
fine with these types of optimization.
It can be enabled again after fixing the problem exposed by The Talos
Principle.
What's the impact on performance with unsafe FP math disabled at this time?
I don't know. Correctness trumps performance.
On 17.02.2015 09:15, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
This reverts commit 0e9cdedd2e3943bdb7f3543a3508b883b167e427.
It caused the grass to disappear in The Talos Principle.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89069
Signed-off-by: Michel Dänzer mic...@daenzer.net
---
src/gallium/drivers/radeon/radeon_llvm_emit.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.c
b/src/gallium/drivers/radeon/radeon_llvm_emit.c
index 0f9dbab..624077c 100644
--- a/src/gallium/drivers/radeon/radeon_llvm_emit.c
+++ b/src/gallium/drivers/radeon/radeon_llvm_emit.c
@@ -80,10 +80,6 @@ void radeon_llvm_shader_type(LLVMValueRef F, unsigned
type)
sprintf(Str, %1d, llvm_type);
LLVMAddTargetDependentFunctionAttr(F, ShaderType, Str);
-
-if (type != TGSI_PROCESSOR_COMPUTE) {
-LLVMAddTargetDependentFunctionAttr(F, unsafe-fp-math, true);
-}
}
static void init_r600_target()
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Prefer Meta over the BLT for BlitFramebuffer.
On Tue, Feb 17, 2015 at 05:39:33PM -0800, Kenneth Graunke wrote:
There's some debate about whether we should use Meta or BLORP,
but either should run circles around the BLT engine.
In particular, this means that Gen8+ will use the 3D engine for blits,
like we do on Gen6-7.
Improves performance in copypixrate -blit -back (from Mesa demos)
by 232.037% +/- 3.15795% (n=10) on Broadwell GT3e.
I've been also experimenting with the same test by disabling blorp for
fb-blits on IVB. I'm a little confused since even without your patch the blit
goes through meta instead of the BLT engine. It is the test for scissor
that prevents intel_blit_framebuffer_with_blitter() from doing the blit:
...
/* If the source and destination are the same size with no mirroring,
* the rectangles are within the size of the texture and there is no
* scissor, then we can probably use the blit engine.
*/
if (!(srcX0 - srcX1 == dstX0 - dstX1
srcY0 - srcY1 == dstY0 - dstY1
srcX1 = srcX0
srcY1 = srcY0
srcX0 = 0 srcX1 = readFb-Width
srcY0 = 0 srcY1 = readFb-Height
dstX0 = 0 dstX1 = drawFb-Width
dstY0 = 0 dstY1 = drawFb-Height
!(ctx-Scissor.EnableFlags))) {
perf_debug(glBlitFramebuffer(): non-1:1 blit.
Falling back to software rendering.\n);
...
I wonder where the performance difference actually comes from, could it
be the intel_prepare_render() that intel_blit_framebuffer_with_blitter()
calls before bailing out. With your patch that won't get called anymore.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert radeon/llvm: enable unsafe math for graphics shaders
Hi,
AFAIR not enabling this makes LLVM generate really slow code in some
common cases. Maybe this is just a bug in LLVM/R600 triggered by unsafe
FP math optimization or some optimization is too eager. Other drivers do
fine with these types of optimization.
What's the impact on performance with unsafe FP math disabled at this time?
Best regards
Grigori
On 17.02.2015 09:15, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
This reverts commit 0e9cdedd2e3943bdb7f3543a3508b883b167e427.
It caused the grass to disappear in The Talos Principle.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89069
Signed-off-by: Michel Dänzer mic...@daenzer.net
---
src/gallium/drivers/radeon/radeon_llvm_emit.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.c
b/src/gallium/drivers/radeon/radeon_llvm_emit.c
index 0f9dbab..624077c 100644
--- a/src/gallium/drivers/radeon/radeon_llvm_emit.c
+++ b/src/gallium/drivers/radeon/radeon_llvm_emit.c
@@ -80,10 +80,6 @@ void radeon_llvm_shader_type(LLVMValueRef F, unsigned type)
sprintf(Str, %1d, llvm_type);
LLVMAddTargetDependentFunctionAttr(F, ShaderType, Str);
-
- if (type != TGSI_PROCESSOR_COMPUTE) {
- LLVMAddTargetDependentFunctionAttr(F, unsafe-fp-math, true);
- }
}
static void init_r600_target()
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert radeon/llvm: enable unsafe math for graphics shaders
On 18.02.2015 17:13, Michel Dänzer wrote: On 18.02.2015 16:52, Grigori Goronzy wrote: What's the impact on performance with unsafe FP math disabled at this time? I don't know. Correctness trumps performance. FWIW, I couldn't seem to measure any significant difference with Unigine Valley, which recently got a ~10% boost from enabling the LLVM machine scheduler. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert radeon/llvm: enable unsafe math for graphics shaders
Am 2015-02-18 09:13, schrieb Michel Dänzer:
On 18.02.2015 16:52, Grigori Goronzy wrote:
Hi,
AFAIR not enabling this makes LLVM generate really slow code in some
common cases. Maybe this is just a bug in LLVM/R600 triggered by
unsafe
FP math optimization or some optimization is too eager. Other drivers
do
fine with these types of optimization.
It can be enabled again after fixing the problem exposed by The Talos
Principle.
Right. I just want to avoid the situation that this workaround gets
committed and then forgotten about. I guess it's up to me then. :)
On 17.02.2015 09:15, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
This reverts commit 0e9cdedd2e3943bdb7f3543a3508b883b167e427.
It caused the grass to disappear in The Talos Principle.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89069
Signed-off-by: Michel Dänzer mic...@daenzer.net
---
src/gallium/drivers/radeon/radeon_llvm_emit.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.c
b/src/gallium/drivers/radeon/radeon_llvm_emit.c
index 0f9dbab..624077c 100644
--- a/src/gallium/drivers/radeon/radeon_llvm_emit.c
+++ b/src/gallium/drivers/radeon/radeon_llvm_emit.c
@@ -80,10 +80,6 @@ void radeon_llvm_shader_type(LLVMValueRef F,
unsigned type)
sprintf(Str, %1d, llvm_type);
LLVMAddTargetDependentFunctionAttr(F, ShaderType, Str);
-
- if (type != TGSI_PROCESSOR_COMPUTE) {
- LLVMAddTargetDependentFunctionAttr(F, unsafe-fp-math, true);
- }
}
static void init_r600_target()
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH libdrm] add support for imx-drm in tests
From: Philipp Zabel p.za...@pengutronix.de
Since imx-drm has graduated from staging it seems to be a good idea to
recognize it by default in the libdrm tests.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Signed-off-by: Lucas Stach l.st...@pengutronix.de
---
lst: added commit message + rebase to master
---
tests/kmstest/main.c | 1 +
tests/modetest/modetest.c | 2 +-
tests/vbltest/vbltest.c | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/tests/kmstest/main.c b/tests/kmstest/main.c
index 449d75f6a880..2c87b1c1b1c0 100644
--- a/tests/kmstest/main.c
+++ b/tests/kmstest/main.c
@@ -62,6 +62,7 @@ char *drivers[] = {
nouveau,
vmwgfx,
exynos,
+ imx-drm,
NULL
};
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 4b9cf2f5b439..425e5287b107 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -1453,7 +1453,7 @@ int main(int argc, char **argv)
int drop_master = 0;
int test_vsync = 0;
int test_cursor = 0;
- const char *modules[] = { i915, radeon, nouveau, vmwgfx,
omapdrm, exynos, tilcdc, msm, sti, tegra };
+ const char *modules[] = { i915, radeon, nouveau, vmwgfx,
omapdrm, exynos, tilcdc, msm, sti, tegra, imx-drm };
char *device = NULL;
char *module = NULL;
unsigned int i;
diff --git a/tests/vbltest/vbltest.c b/tests/vbltest/vbltest.c
index 6e13c57c6e38..916d494635b2 100644
--- a/tests/vbltest/vbltest.c
+++ b/tests/vbltest/vbltest.c
@@ -106,7 +106,7 @@ int main(int argc, char **argv)
{
unsigned i;
int c, fd, ret;
- char *modules[] = { i915, radeon, nouveau, vmwgfx, exynos,
omapdrm, tilcdc, msm, tegra };
+ char *modules[] = { i915, radeon, nouveau, vmwgfx, exynos,
omapdrm, tilcdc, msm, tegra, imx-drm };
drmVBlank vbl;
drmEventContext evctx;
struct vbl_info handler_info;
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] add visibility hidden to tls entry points
Am Dienstag, 17. Februar 2015, 21:21:18 schrieb Matt Turner:
On Mon, Feb 16, 2015 at 10:25 AM, Matt Turner matts...@gmail.com wrote:
On Mon, Feb 16, 2015 at 1:36 AM, Marc Dietrich marvi...@gmx.de wrote:
Avoid redefined symbol errors in clang. Based on a suggestion from
Rafael à vila de EspÃndola rafael.espind...@gmail.com in
http://llvm.org/bugs/show_bug.cgi?id=19778.
Signed-off-by: Marc Dietrich marvi...@gmx.de
---
src/mapi/entry_x86-64_tls.h | 3 ++-
src/mapi/entry_x86_tls.h| 5 +++--
src/mapi/entry_x86_tsd.h| 5 +++--
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/src/mapi/entry_x86-64_tls.h b/src/mapi/entry_x86-64_tls.h
index 71e9d60..d36556c 100644
--- a/src/mapi/entry_x86-64_tls.h
+++ b/src/mapi/entry_x86-64_tls.h
@@ -26,6 +26,7 @@
*/
#include u_macros.h
+#include ../util/macros.h
Let's add -I$(top_srcdir)src/util to src/mapi/Makefile.am's
AM_CPPFLAGS and include util/macros.h. Occurs again in this patch.
__asm__(.text\n
.balign 32\n
@@ -62,7 +63,7 @@ entry_patch_public(void)
{
}
-static char
+extern char HIDDEN
So, reading the bug report... adding extern HIDDEN is kind of a hack.
I have some patches in a wip branch that attempt to make LTO work, and
one of them replaces the __asm__ seen at the end of the previous hunk
with
static void
__attribute__((__used__))
x86_64_entry_start()
{
}
and just removes this char[] declaration. It /seems/ to work. I
suspect we'd also want to use aligned function attribute (and use
macros for the attributes).
Interested in giving that a try?
I see that you've resent these patches, but I don't see that you've
seen this comment?
right, I somehow missed it. Good part is that I tried your suggestion, but it
doesn't work becuase gcc will create an empty function x86_64_entry_start()
which will alter the start of the dispatch table.
so I tried something like this:
--- a/src/mapi/entry_x86-64_tls.h
+++ b/src/mapi/entry_x86-64_tls.h
@@ -28,9 +28,7 @@
#include macros.h
#include u_macros.h
-__asm__(.text\n
-.balign 32\n
-x86_64_entry_start:);
+extern void shared_dispatch_stub_0();
#define STUB_ASM_ENTRY(func) \
.globl func \n \
@@ -63,12 +61,10 @@ entry_patch_public(void)
{
}
-extern const char HIDDEN x86_64_entry_start[];
-
mapi_func
entry_get_public(int slot)
{
- return (mapi_func) (x86_64_entry_start + slot * 32);
+ return (mapi_func) (shared_dispatch_stub_0 + slot * 32);
}
void
which oddly seems to work, but is similar hackish, especially because the
table should be wrong for ES1 and ES2 dispatcher (but somehow it still works).
I'm not skilled enough to understand all this dispatching stuff, so either we
could use the original patch (using HIDDEN) or do something else, e.g. find a
way to create an empty label.
Marc
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert radeon/llvm: enable unsafe math for graphics shaders
On Feb 17, 2015, at 11:52 PM, Grigori Goronzy g...@chown.ath.cx wrote: Hi, AFAIR not enabling this makes LLVM generate really slow code in some common cases. Maybe this is just a bug in LLVM/R600 triggered by unsafe FP math optimization or some optimization is too eager. Other drivers do fine with these types of optimization. What's the impact on performance with unsafe FP math disabled at this time? Best regards Grigori The exact reason should be found, since this should be OK. Also, this should be setting no-nans-fp-math / no-infs-fp-math and whatever others there are. unsafe-fp-math should just be controlling other algebraic kinds of optimizations ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 88618] opengles2: fix building without X11
https://bugs.freedesktop.org/show_bug.cgi?id=88618 Emil Velikov emil.l.veli...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Emil Velikov emil.l.veli...@gmail.com --- Thanks for the patch Michael. Committed to the master branch. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert radeon/llvm: enable unsafe math for graphics shaders
On Feb 18, 2015, at 1:15 AM, Michel Dänzer mic...@daenzer.net wrote: On 18.02.2015 17:13, Michel Dänzer wrote: On 18.02.2015 16:52, Grigori Goronzy wrote: What's the impact on performance with unsafe FP math disabled at this time? I don't know. Correctness trumps performance. FWIW, I couldn't seem to measure any significant difference with Unigine Valley, which recently got a ~10% boost from enabling the LLVM machine scheduler. There are a couple of problems right now that mean the fast math option isn’t really doing anything. I just realized this patch is only setting the attribute, which will only effect codegen. The IR emission should be also be annotating the individual instructions with the fast math flags, which would enable the better math optimizations in the parts of the optimizer that are supposed to handle this. Even with the fast math flags, the current graphics pass pipeline is problematic. Much of what the fast math flags accomplish is done in instcombine, which isn’t run now. It really should be, it’s the basic canonicalization and peephole pass pretty much everything else expects it to have cleaned up the IR. The standard pass pipeline runs it several times. -Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 86944] glsl_parser_extras.cpp, line 1455: Error: Badly formed expression. (Oracle Studio)
https://bugs.freedesktop.org/show_bug.cgi?id=86944 Ian Romanick i...@freedesktop.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Ian Romanick i...@freedesktop.org --- Should be fixed by: commit 4671dca0eecf7dbf3e0d0a13111813756722d57d Author: Alan Coopersmith alan.coopersm...@oracle.com Date: Sun Feb 15 16:19:06 2015 -0800 Use __typeof instead of typeof with Solaris Studio compilers While the C compiler accepts typeof, C++ requires __typeof. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86944 Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com Cc: 10.5 mesa-sta...@lists.freedesktop.org Reviewed-by: Emil Velikov emil.l.veli...@gmail.com Reviewed-by: Brian Paul bri...@vmware.com Please reopen if it is still a problem. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 79706] [TRACKER] Mesa regression tracker
https://bugs.freedesktop.org/show_bug.cgi?id=79706 Bug 79706 depends on bug 86944, which changed state. Bug 86944 Summary: glsl_parser_extras.cpp, line 1455: Error: Badly formed expression. (Oracle Studio) https://bugs.freedesktop.org/show_bug.cgi?id=86944 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/23] main: Add entry point for TextureBufferRange.
On 02/17/2015 07:59 AM, Martin Peres wrote:
Hey Laura,
Thanks for this code. I'll be sending reviews throughout the week :)
On 12/02/15 04:05, Laura Ekstrand wrote:
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 336feff..ce6f446 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -5197,6 +5197,96 @@ _mesa_TextureBuffer(GLuint texture, GLenum
internalFormat, GLuint buffer)
bufObj, 0, buffer ? -1 : 0, false, true);
}
+void GLAPIENTRY
+_mesa_TextureBufferRange(GLuint texture, GLenum internalFormat,
GLuint buffer,
+ GLintptr offset, GLsizeiptr size)
+{
+ struct gl_texture_object *texObj;
+ struct gl_buffer_object *bufObj;
+
+ GET_CURRENT_CONTEXT(ctx);
+
+ /* NOTE: ARB_texture_buffer_object has interactions with
+* the compatibility profile that are not implemented.
+*/
+ if (!(ctx-API == API_OPENGL_CORE
+ ctx-Extensions.ARB_texture_buffer_object)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glTextureBufferRange(ARB_texture_buffer_object is
not
+ implemented for the compatibility profile));
+ return;
+ }
Can you point me to the relevant part of the spec that explains the
interaction?
In compatibility profile, TexBos can support luminance, luminance-alpha,
and intensity textures. Intel hardware doesn't support that, and none
of the TexBo common code supports it either.
But... at least for glTexBuffer and glTexBufferRange there is (almost) a
better way to do this. We should change the GL API generator code so
that we can omit functions from compatibility profile. We can already
do this for core profile (look for the deprecated='3.1' bits in
src/mapi/glapi/gen).
Due to previously mentioned issues with libraries like GLEW, we may not
be able to do this with DSA functions that are core-only if we're going
to expose DSA on compatibility profile.
Did you simply took this code out of _mesa_TexBufferRange?
+
+ bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ if (bufObj) {
+ /* OpenGL 4.5 core spec (30.10.2014) says in Section 8.9 Buffer
+ * Textures:
+ *An INVALID_VALUE error is generated if offset is
negative, if
+ *size is less than or equal to zero, or if offset + size
is greater
+ *than the value of BUFFER_SIZE for the buffer bound to
target.
+ */
+ if (offset 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glTextureBufferRange(offset %d 0), (int)
offset);
+ return;
+ }
+
+ if (size = 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glTextureBufferRange(size %d = 0), (int) size);
+ return;
+ }
+
+ if (offset + size bufObj-Size) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glTextureBufferRange(
+ offset %d + size %d buffer_size %d), (int)
offset,
+ (int) size, (int) bufObj-Size);
+ return;
+ }
+
+ /* OpenGL 4.5 core spec (30.10.2014) says in Section 8.9 Buffer
+ * Textures:
+ *An INVALID_VALUE error is generated if offset is not an
integer
+ *multiple of the value of TEXTURE_BUFFER_OFFSET_ALIGNMENT.
+ */
+ if (offset % ctx-Const.TextureBufferOffsetAlignment) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glTextureBufferRange(invalid offset alignment));
+ return;
+ }
+ } else if (buffer) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glTextureBufferRange(unrecognized buffer %u),
buffer);
+ return;
+ } else {
+
+ /* OpenGL 4.5 core spec (30.10.2014) says in Section 8.9 Buffer
+ * Textures:
+ *If buffer is zero, then any buffer object attached to
the buffer
+ *texture is detached, the values offset and size are
ignored and
+ *the state for offset and size for the buffer texture are
reset to
+ *zero.
+ */
+ offset = 0;
+ size = 0;
+ }
+
+ /* Get the texture object by Name. */
+ texObj = _mesa_lookup_texture_err(ctx, texture,
glTextureBufferRange);
+ if (!texObj)
+ return;
This should return INVALID_OPERATION:
An INVALID_OPERATION error is generated by TextureBufferRange if
texture is not the name of an existing texture object.
+
+ if (texObj-Target != GL_TEXTURE_BUFFER_ARB) {
+ _mesa_error(ctx, GL_INVALID_ENUM, glTextureBufferRange(texture
target
+ is not GL_TEXTURE_BUFFER));
+ return;
+ }
What are you trying to do here? First, I see no mention of this in the
spec (but I am quite possibly wrong).
Secondly, you are checking the target before calling
_mesa_texture_buffer_range which does not care about the target.
Is it a copy/paste from
Re: [Mesa-dev] [PATCH] ra: Disable round-robin strategy for optimistically colorable nodes.
On Wed, Feb 18, 2015 at 8:31 AM, Francisco Jerez curroje...@riseup.net wrote:
Connor Abbott cwabbo...@gmail.com writes:
On Tue, Feb 17, 2015 at 3:04 PM, Francisco Jerez curroje...@riseup.net
wrote:
Jason Ekstrand ja...@jlekstrand.net writes:
On Mon, Feb 16, 2015 at 11:39 AM, Francisco Jerez curroje...@riseup.net
wrote:
The round-robin allocation strategy is expected to decrease the amount
of false dependencies created by the register allocator and give the
post-RA scheduling pass more freedom to move instructions around. On
the other hand it has the disadvantage of increasing fragmentation and
decreasing the number of equally-colored nearby nodes, what increases
the likelihood of failure in presence of optimistically colorable
nodes.
This patch disables the round-robin strategy for optimistically
colorable nodes. These typically arise in situations of high register
pressure or for registers with large live intervals, in both cases the
task of the instruction scheduler shouldn't be constrained excessively
by the dense packing of those nodes, and a spill (or on Intel hardware
a fall-back to SIMD8 mode) is invariably worse than a slightly less
optimal scheduling.
Shader-db results on the i965 driver:
total instructions in shared programs: 5488539 - 5488489 (-0.00%)
instructions in affected programs: 1121 - 1071 (-4.46%)
helped:1
HURT: 0
GAINED:49
LOST: 5
---
src/util/register_allocate.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/src/util/register_allocate.c b/src/util/register_allocate.c
index af7a20c..d63d8eb 100644
--- a/src/util/register_allocate.c
+++ b/src/util/register_allocate.c
@@ -168,6 +168,12 @@ struct ra_graph {
unsigned int *stack;
unsigned int stack_count;
+
+ /**
+* Tracks the start of the set of optimistically-colored registers in
the
+* stack.
+*/
+ unsigned int stack_optimistic_start;
};
/**
@@ -454,6 +460,7 @@ static void
ra_simplify(struct ra_graph *g)
{
bool progress = true;
+ unsigned int stack_optimistic_start = ~0;
UINT_MAX would be clearer than ~0
Sure, either works as identity for MIN2. Do you want me to send a v3
for this or should I fix it locally and add your R-b?
int i;
while (progress) {
@@ -483,12 +490,16 @@ ra_simplify(struct ra_graph *g)
if (!progress best_optimistic_node != ~0U) {
I guess we're using ~0 other places... oh well...
decrement_q(g, best_optimistic_node);
+ stack_optimistic_start =
+MIN2(stack_optimistic_start, g-stack_count);
It might be clearer to explicitly use an if here instead of the MIN2
because what this really means is if (stack_optimistic_start == ~0)
stack_optimistic_start = g-stack_count;
What I really meant to calculate here is the minimum of the indices of
all optimistic nodes inserted into the stack. What you say works too
because we happen to be growing the stack monotonically. How can using
MIN2 possibly obscure the meaning of taking the minimum?
Because you're finding stack_optimistic_*start*, i.e. the *first*
thing on the stack that's optimistic. It's a pretty common idiom in C,
when you're going through a bunch of stuff and you want to record the
first thing that satisfies some property, to do:
result = some_default_value (NULL, UINT_MAX, etc.)
for_each_thing {
...
if (has_the_property(thing) result == some_default_value) {
result = thing;
}
}
so if you do what Jason suggested, people will see the pattern and go
ah, it's recording the first thing we pushed optimistically, that
makes sense as opposed to thinking about what the minimum is doing;
it's not obvious at first that after the first MIN2
stack_optimistic_start is never going to change.
Yeah, I completely agree with your argumentation, actually it's funny
that this was precisely the reason that led me to intentionally write
MIN2() rather than your open-coded equivalent. I consider the way how
something is going to change or not along your incidental control flow a
distraction from its formal definition. But I'm not going spend a
single second more of my time in this discussion because it is a matter
of personal taste and there's no objectively better or worse choice,
there's no point in being categorical here. If you insist in stressing
the how over the what and cannot tolerate somebody else's personal
inclination I'm just going to do as you say because this has long
crossed the line of bike-shedding.
Did you actually intend to review this patch? And if so do you want a
resend with the trivial codestyle changes?
Sorry if I came off as too argumentative there -- it's really not a
big deal, and I've spent too much time arguing about it. Feel free to
change the codestyle or not,
Re: [Mesa-dev] [PATCH 2/2] i965/skl: Layout a 1D miptree horizontally
On 02/17/2015 06:03 AM, Neil Roberts wrote:
On Gen9+ the 1D miptree is laid out with all of the mipmap levels in a
horizontal line.
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 71
--
1 file changed, 68 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
b/src/mesa/drivers/dri/i965/brw_tex_layout.c
index 0e2841f..abf532a 100644
--- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
+++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
@@ -158,6 +158,42 @@ intel_vertical_texture_alignment_unit(struct brw_context
*brw,
}
static void
+gen9_miptree_layout_1d(struct intel_mipmap_tree *mt)
+{
+ unsigned x = 0;
+ unsigned width = mt-physical_width0;
+ unsigned depth = mt-physical_depth0; /* number of array layers. */
Blank line here.
+ /* When this layout is used the horizontal alignment is fixed at 64 and
the
+* hardware ignores the value given in the surface state
+*/
+ const unsigned int align_w = 64;
+
+ mt-total_height = mt-physical_height0;
+
+ if (mt-compressed) {
+ mt-total_height = ALIGN(mt-physical_height0, mt-align_h);
+ }
There aren't any compressed formats that support 1D textures, so I don't
think this can occur. Does the bspec say anything about compressed 1D
textures?
+
+ mt-total_width = 0;
+
+ for (unsigned level = mt-first_level; level = mt-last_level; level++) {
+ unsigned img_width;
+
+ intel_miptree_set_level_info(mt, level, x, 0, depth);
+
+ img_width = ALIGN(width, align_w);
+ if (mt-compressed)
+ img_width /= align_w;
Same comment here about mt-compressed.
+
+ mt-total_width = MAX2(mt-total_width, x + img_width);
+
+ x += img_width;
+
+ width = minify(width, 1);
+ }
+}
+
+static void
brw_miptree_layout_2d(struct intel_mipmap_tree *mt)
{
unsigned x = 0;
@@ -239,23 +275,49 @@ align_cube(struct intel_mipmap_tree *mt)
mt-total_height += 2;
}
+static bool
+use_linear_1d_layout(struct brw_context *brw,
+ struct intel_mipmap_tree *mt)
+{
+ /* On Gen9+ the mipmap levels of a 1D surface are all laid out in a
+* horizontal line. This isn't done for depth/stencil buffers however
+* because those will be using a tiled layout
+*/
+
Delete this blank line.
+ if (brw-gen = 9
+ (mt-target == GL_TEXTURE_1D ||
+mt-target == GL_TEXTURE_1D_ARRAY)) {
+ GLenum base_format = _mesa_get_format_base_format(mt-format);
+
+ if (base_format != GL_DEPTH_COMPONENT
+ base_format != GL_DEPTH_STENCIL)
+ return true;
+ }
+
+ return false;
+}
+
static void
brw_miptree_layout_texture_array(struct brw_context *brw,
struct intel_mipmap_tree *mt)
{
int h0, h1;
unsigned height = mt-physical_height0;
+ bool layout_1d = use_linear_1d_layout(brw, mt);
h0 = ALIGN(mt-physical_height0, mt-align_h);
h1 = ALIGN(minify(mt-physical_height0, 1), mt-align_h);
- if (mt-array_layout == ALL_SLICES_AT_EACH_LOD)
+ if (mt-array_layout == ALL_SLICES_AT_EACH_LOD || layout_1d)
mt-qpitch = h0;
else
mt-qpitch = (h0 + h1 + (brw-gen = 7 ? 12 : 11) * mt-align_h);
int physical_qpitch = mt-compressed ? mt-qpitch / 4 : mt-qpitch;
- brw_miptree_layout_2d(mt);
+ if (layout_1d)
+ gen9_miptree_layout_1d(mt);
+ else
+ brw_miptree_layout_2d(mt);
for (unsigned level = mt-first_level; level = mt-last_level; level++) {
unsigned img_height;
@@ -386,7 +448,10 @@ brw_miptree_layout(struct brw_context *brw, struct
intel_mipmap_tree *mt)
break;
case INTEL_MSAA_LAYOUT_NONE:
case INTEL_MSAA_LAYOUT_IMS:
- brw_miptree_layout_2d(mt);
+ if (use_linear_1d_layout(brw, mt))
+gen9_miptree_layout_1d(mt);
+ else
+brw_miptree_layout_2d(mt);
break;
}
break;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: fix sampler view reference counting bug in glDraw/CopyPixels
Use pipe_sampler_view_reference() instead of ordinary assignment.
Also add a new sanity check assertion.
Fixes piglit gl-1.0-drawpixels-color-index test crash. But note
that the test still fails.
Cc: 10.4, 10.5 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_cb_drawpixels.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
b/src/mesa/state_tracker/st_cb_drawpixels.c
index 939fc20..3d13b5c 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -1154,8 +1154,10 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
color = NULL;
if (st-pixel_xfer.pixelmap_enabled) {
- sv[1] = st-pixel_xfer.pixelmap_sampler_view;
- num_sampler_view++;
+ sv[1] = NULL;
+ pipe_sampler_view_reference(sv[1],
+ st-pixel_xfer.pixelmap_sampler_view);
+ num_sampler_view++;
}
}
@@ -1176,7 +1178,8 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
if (write_stencil) {
enum pipe_format stencil_format =
util_format_stencil_only(pt-format);
-
+ /* we should not be doing pixel map/transfer (see above) */
+ assert(num_sampler_view == 1);
sv[1] = st_create_texture_sampler_view_format(st-pipe, pt,
stencil_format);
num_sampler_view++;
@@ -1516,7 +1519,9 @@ st_CopyPixels(struct gl_context *ctx, GLint srcx, GLint
srcy,
driver_vp = make_passthrough_vertex_shader(st, GL_FALSE);
if (st-pixel_xfer.pixelmap_enabled) {
- sv[1] = st-pixel_xfer.pixelmap_sampler_view;
+ sv[1] = NULL;
+ pipe_sampler_view_reference(sv[1],
+ st-pixel_xfer.pixelmap_sampler_view);
num_sampler_view++;
}
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Implement GLX_EXT_buffer_age for DRI2
Hi, On 20 January 2015 at 21:49, Dave Airlie airl...@gmail.com wrote: On 19 January 2015 at 21:00, Chris Wilson ch...@chris-wilson.co.uk wrote: In order to suport GLX_EXT_buffer_age in DRI2, we need to pass back the last swap buffer count that the back buffer was defined for. For simplicity, we can reuse an existing field in the DRI2GetBuffers reply that is not used by current drivers, the flags. Since we change the interpretation of this flag, we also declare the semantic change with a DRI2 parameter and depend upon the DDX to enable the change responsibility (which is just a matter of reviewing whether the flags field has ever been used for a non-zero value). This is just missing the why do we need to add this to DRI2 when we have DRI3/Present that should be solving it. Doesn't dri3 already do this? DRI3/Present still seem to be pretty unstable and break a bunch of stuff, and buffer_age is definitely a useful optimisation for non-TBDR platforms, so I don't see why not. Cheers, Daniel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/23] main: Tex[ture]Buffer[Range] functions now use _mesa_lookup_bufferobj_err.
On 02/17/2015 08:03 AM, Martin Peres wrote:
Hey,
Why not move these two patches before the one introducing BufferRange?
Also, I wouldn't mind seeing them squashed together since the previous
patch
alone does not change any behaviour.
I was going to suggest the same thing. Specifically:
- Squash the _mesa_TexBuffer changes into the previous patch. I'll
preemptively give the resulting patch 'Reviewed-by: Ian Romanick
ian.d.roman...@intel.com'
- Move the previous patch before main: Add entry point for
TextureBufferRange.
- Squash the remaining changes from this patch into main: Add entry
point for TextureBufferRange.
On 12/02/15 04:05, Laura Ekstrand wrote:
---
src/mesa/main/teximage.c | 46
+-
1 file changed, 25 insertions(+), 21 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index ce6f446..d17f15e 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -5091,11 +5091,13 @@ _mesa_TexBuffer(GLenum target, GLenum
internalFormat, GLuint buffer)
return;
}
- bufObj = _mesa_lookup_bufferobj(ctx, buffer);
- if (!bufObj buffer) {
- _mesa_error(ctx, GL_INVALID_OPERATION, glTexBuffer(buffer
%u), buffer);
- return;
+ if (buffer) {
+ bufObj = _mesa_lookup_bufferobj_err(ctx, buffer, glTexBuffer);
+ if (!bufObj)
+ return;
}
+ else
+ bufObj = NULL;
texObj = _mesa_get_current_tex_object(ctx, target);
if (!texObj)
@@ -5128,8 +5130,11 @@ _mesa_TexBufferRange(GLenum target, GLenum
internalFormat, GLuint buffer,
return;
}
- bufObj = _mesa_lookup_bufferobj(ctx, buffer);
- if (bufObj) {
+ if (buffer) {
+ bufObj = _mesa_lookup_bufferobj_err(ctx, buffer,
glTexBufferRange);
+ if (!bufObj)
+ return;
+
if (offset 0 ||
size = 0 ||
(offset + size) bufObj-Size) {
@@ -5141,13 +5146,10 @@ _mesa_TexBufferRange(GLenum target, GLenum
internalFormat, GLuint buffer,
glTexBufferRange(invalid offset alignment));
return;
}
- } else if (buffer) {
- _mesa_error(ctx, GL_INVALID_OPERATION, glTexBufferRange(buffer
%u),
- buffer);
- return;
} else {
offset = 0;
size = 0;
+ bufObj = NULL;
}
texObj = _mesa_get_current_tex_object(ctx, target);
@@ -5175,12 +5177,13 @@ _mesa_TextureBuffer(GLuint texture, GLenum
internalFormat, GLuint buffer)
return;
}
- bufObj = _mesa_lookup_bufferobj(ctx, buffer);
- if (!bufObj buffer) {
- _mesa_error(ctx, GL_INVALID_OPERATION, glTextureBuffer(buffer
%u),
- buffer);
- return;
+ if (buffer) {
+ bufObj = _mesa_lookup_bufferobj_err(ctx, buffer,
glTextureBuffer);
+ if (!bufObj)
+ return;
}
+ else
+ bufObj = NULL;
/* Get the texture object by Name. */
texObj = _mesa_lookup_texture_err(ctx, texture,
@@ -5217,8 +5220,12 @@ _mesa_TextureBufferRange(GLuint texture, GLenum
internalFormat, GLuint buffer,
return;
}
- bufObj = _mesa_lookup_bufferobj(ctx, buffer);
- if (bufObj) {
+ if (buffer) {
+ bufObj = _mesa_lookup_bufferobj_err(ctx, buffer,
+ glTextureBufferRange);
+ if (!bufObj)
+ return;
+
/* OpenGL 4.5 core spec (30.10.2014) says in Section 8.9 Buffer
* Textures:
*An INVALID_VALUE error is generated if offset is
negative, if
@@ -5255,10 +5262,6 @@ _mesa_TextureBufferRange(GLuint texture, GLenum
internalFormat, GLuint buffer,
glTextureBufferRange(invalid offset alignment));
return;
}
- } else if (buffer) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
- glTextureBufferRange(unrecognized buffer %u),
buffer);
- return;
} else {
/* OpenGL 4.5 core spec (30.10.2014) says in Section 8.9 Buffer
@@ -5270,6 +5273,7 @@ _mesa_TextureBufferRange(GLuint texture, GLenum
internalFormat, GLuint buffer,
*/
offset = 0;
size = 0;
+ bufObj = NULL;
}
/* Get the texture object by Name. */
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/23] main: Add entry point for TextureBufferRange.
On 02/11/2015 06:05 PM, Laura Ekstrand wrote:
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 8 +++
src/mesa/main/tests/dispatch_sanity.cpp| 1 +
src/mesa/main/teximage.c | 90
++
src/mesa/main/teximage.h | 4 ++
4 files changed, 103 insertions(+)
diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index 2fe1638..86c00f9 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -21,6 +21,14 @@
param name=buffer type=GLuint /
/function
+ function name=TextureBufferRange offset=assign
+ param name=texture type=GLuint /
+ param name=internalformat type=GLenum /
+ param name=buffer type=GLuint /
+ param name=offset type=GLintptr /
+ param name=size type=GLsizeiptr /
+ /function
+
function name=TextureStorage1D offset=assign
param name=texture type=GLuint /
param name=levels type=GLsizei /
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index 1f1a3a8..b78c1ce 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -987,6 +987,7 @@ const struct function gl_core_functions_possible[] = {
{ glTextureStorage2DMultisample, 45, -1 },
{ glTextureStorage3DMultisample, 45, -1 },
{ glTextureBuffer, 45, -1 },
+ { glTextureBufferRange, 45, -1 },
/* GL_EXT_polygon_offset_clamp */
{ glPolygonOffsetClampEXT, 11, -1 },
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 336feff..ce6f446 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -5197,6 +5197,96 @@ _mesa_TextureBuffer(GLuint texture, GLenum
internalFormat, GLuint buffer)
bufObj, 0, buffer ? -1 : 0, false, true);
}
+void GLAPIENTRY
+_mesa_TextureBufferRange(GLuint texture, GLenum internalFormat, GLuint
buffer,
+ GLintptr offset, GLsizeiptr size)
+{
+ struct gl_texture_object *texObj;
+ struct gl_buffer_object *bufObj;
+
+ GET_CURRENT_CONTEXT(ctx);
+
+ /* NOTE: ARB_texture_buffer_object has interactions with
+* the compatibility profile that are not implemented.
+*/
+ if (!(ctx-API == API_OPENGL_CORE
+ ctx-Extensions.ARB_texture_buffer_object)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glTextureBufferRange(ARB_texture_buffer_object is not
+ implemented for the compatibility profile));
+ return;
+ }
+
+ bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ if (bufObj) {
+ /* OpenGL 4.5 core spec (30.10.2014) says in Section 8.9 Buffer
+ * Textures:
+ *An INVALID_VALUE error is generated if offset is negative, if
+ *size is less than or equal to zero, or if offset + size is
greater
+ *than the value of BUFFER_SIZE for the buffer bound to target.
+ */
+ if (offset 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glTextureBufferRange(offset %d 0), (int) offset);
+ return;
+ }
+
+ if (size = 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glTextureBufferRange(size %d = 0), (int) size);
+ return;
+ }
+
+ if (offset + size bufObj-Size) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glTextureBufferRange(
+ offset %d + size %d buffer_size %d), (int) offset,
+ (int) size, (int) bufObj-Size);
+ return;
+ }
+
+ /* OpenGL 4.5 core spec (30.10.2014) says in Section 8.9 Buffer
+ * Textures:
+ *An INVALID_VALUE error is generated if offset is not an integer
+ *multiple of the value of TEXTURE_BUFFER_OFFSET_ALIGNMENT.
+ */
+ if (offset % ctx-Const.TextureBufferOffsetAlignment) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glTextureBufferRange(invalid offset alignment));
+ return;
+ }
+ } else if (buffer) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glTextureBufferRange(unrecognized buffer %u), buffer);
+ return;
+ } else {
+
+ /* OpenGL 4.5 core spec (30.10.2014) says in Section 8.9 Buffer
+ * Textures:
+ *If buffer is zero, then any buffer object attached to the buffer
+ *texture is detached, the values offset and size are ignored and
+ *the state for offset and size for the buffer texture are reset to
+ *zero.
+ */
+ offset = 0;
+ size = 0;
+ }
We usually try to keep flow control for error checking more flat. It
makes it easier to follow. For example, the above block would be much
better as
struct gl_buffer_object *bufObj =
Re: [Mesa-dev] [PATCH] i965/vec4: Calculate register allocation q values manually.
This patch fixes a performance regression that causes our piglit CI
system to slow by 50%. If anyone has time to take a look at this and
provide a RB, it will improve the rate at which you get your piglit
results.
-Mark
Francisco Jerez curroje...@riseup.net writes:
This fixes a regression in the running time of Piglit introduced by
commit 78e9043475d4bed8b50f7e413963c960fa0935bb, which increased the
number of register allocation classes set up by the VEC4 back-end
from 2 to 16. The algorithm used by ra_set_finalize() to calculate
them is unnecessarily expensive, do it manually like the FS back-end
does.
Reported-by: Mark Janes mark.a.ja...@intel.com
---
src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
index 46f0bfd..a286f8a 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
@@ -129,10 +129,13 @@ brw_vec4_alloc_reg_set(struct intel_screen *screen)
* between them and the base GRF registers (and also each other).
*/
int reg = 0;
+ unsigned *q_values[MAX_VGRF_SIZE];
for (int i = 0; i class_count; i++) {
int class_reg_count = base_reg_count - (class_sizes[i] - 1);
screen-vec4_reg_set.classes[i] =
ra_alloc_reg_class(screen-vec4_reg_set.regs);
+ q_values[i] = new unsigned[MAX_VGRF_SIZE];
+
for (int j = 0; j class_reg_count; j++) {
ra_class_add_reg(screen-vec4_reg_set.regs,
screen-vec4_reg_set.classes[i], reg);
@@ -146,10 +149,23 @@ brw_vec4_alloc_reg_set(struct intel_screen *screen)
reg++;
}
+
+ for (int j = 0; j class_count; j++) {
+ /* Calculate the q values manually because the algorithm used by
+ * ra_set_finalize() to do it has higher complexity affecting the
+ * start-up time of some applications. q(i, j) is just the maximum
+ * number of registers from class i a register from class j can
+ * conflict with.
+ */
+ q_values[i][j] = class_sizes[i] + class_sizes[j] - 1;
+ }
}
assert(reg == ra_reg_count);
- ra_set_finalize(screen-vec4_reg_set.regs, NULL);
+ ra_set_finalize(screen-vec4_reg_set.regs, q_values);
+
+ for (int i = 0; i MAX_VGRF_SIZE; i++)
+ delete[] q_values[i];
}
void
--
2.1.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/vec4: Calculate register allocation q values manually.
Reviewed-by: Matt Turner matts...@gmail.com Thanks Curro! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: don't allow invariant qualifiers for interface blocks
On Tue, Dec 9, 2014 at 2:52 AM, Eduardo Lima Mitev el...@igalia.com wrote: From: Samuel Iglesias Gonsalvez sigles...@igalia.com GLSL 1.50 and GLSL 4.40 specs, they both say the same in Interface Blocks section: If no optional qualifier is used in a member-declaration, the qualification of the member includes all in, out, patch, uniform, or buffer as determined by interface-qualifier. If optional qualifiers are used, they can include interpolation qualifiers, auxiliary storage qualifiers, and storage qualifiers and they must declare an input, output, or uniform member consistent with the interface qualifier of the block From GLSL ES 3.0, chapter 4.3.7 Interface Blocks, page 38: GLSL ES 3.0 does not support interface blocks for shader inputs or outputs. and from GLSL ES 3.0, chapter 4.6.1 The invariant qualifier, page 52. Only variables output from a shader can be candidates for invariance. This includes user-defined output variables and the built-in output variables. As only outputs can be declared as invariant, an invariant output from one shader stage will still match an input of a subsequent stage without the input being declared as invariant. From GLSL ES 1.0, chapter 4.6.1 The invariant qualifier, page 37. Only the following variables may be declared as invariant: * Built-in special variables output from the vertex shader * Varying variables output from the vertex shader * Built-in special variables input to the fragment shader * Varying variables input to the fragment shader * Built-in special variables output from the fragment shader. This patch fixes the following dEQP tests: dEQP-GLES3.functional.shaders.declarations.invalid_declarations.invariant_uniform_block_2_vertex dEQP-GLES3.functional.shaders.declarations.invalid_declarations.invariant_uniform_block_2_fragment No piglit regressions. Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com v2: - Enable this check for GLSL. Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com --- src/glsl/glsl_parser.yy | 35 +++ 1 file changed, 35 insertions(+) diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index 7fb8c38..9f2a0a3 100644 --- a/src/glsl/glsl_parser.yy +++ b/src/glsl/glsl_parser.yy @@ -2539,6 +2539,41 @@ basic_interface_block: interface block member does not match the interface block); } + /* From GLSL ES 3.0, chapter 4.3.7 Interface Blocks, page 38: + * + * GLSL ES 3.0 does not support interface blocks for shader inputs or + * outputs. + * + * And from GLSL ES 3.0, chapter 4.6.1 The invariant qualifier, page 52. + * + * Only variables output from a shader can be candidates for + * invariance. I'd snip the rest of the quote after this. I don't think it makes the point clearer, and actually just makes it harder to see the important bit. This includes user-defined output variables and the + * built-in output variables. As only outputs can be declared as + * invariant, an invariant output from one shader stage will + * still match an input of a subsequent stage without the input being + * declared as invariant. + * + * From GLSL ES 1.0, chapter 4.6.1 The invariant qualifier, page 37. + * + * Only the following variables may be declared as invariant: + * * Built-in special variables output from the vertex shader + * * Varying variables output from the vertex shader + * * Built-in special variables input to the fragment shader + * * Varying variables input to the fragment shader + * * Built-in special variables output from the fragment shader. + * + * From GLSL 4.40 and GLSL 1.50, section Interface Blocks: + * + * If no optional qualifier is used in a member-declaration, the + * qualification of the member includes all in, out, patch, uniform, + * or buffer as determined by interface-qualifier. I'd snip the quote before this. If optional + * qualifiers are used, they can include interpolation qualifiers, + * auxiliary storage qualifiers, and storage qualifiers and they must + * declare an input, output, or uniform member consistent with the + * interface qualifier of the block + */ + if (qualifier.flags.q.invariant) +_mesa_glsl_error(@1, state, invariant qualifiers cannot be used with interface blocks members); Try to line wrap this. With those comments fixed: Reviewed-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965/skl: Upload qpitch in pixels for 1D textures
Ben Widawsky b...@bwidawsk.net writes: I promise to look at this again in more detail tomorrow when I am more awake, but meanwhile, I'd be very much in favor of just setting mt-qpith for all miptree layout types. I'm not sure what you mean. Do you mean that we should just always set mt-qpitch to the actual value that we're going to upload? Yes, that seems like a good idea. I was originally worried about that because I had thought that other bits of code were looking at the qpitch to work out some offsets but that is not the case. The qpitch seems to also be broken for 3D textures and compressed textures so I think it might be a good idea to squash this patch into a general patch which fixes everything. I made a start on that as part of fixing the copyteximage test for 3D textures here: https://github.com/bpeel/mesa/commit/fc95546c49f0e5c5805139712c51a0d13b2183c3 I don't want to post the patch to the mailing list yet because it doesn't fix the test for the GL_RGBA32 format with 3D textures and I'd like to work out why first. Regards, - Neil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/23] main: Fix whitespace in teximage.c.
This patch is Reviewed-by: Ian Romanick ian.d.roman...@intel.com On 02/11/2015 06:05 PM, Laura Ekstrand wrote: --- src/mesa/main/teximage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c index 29c325b..336feff 100644 --- a/src/mesa/main/teximage.c +++ b/src/mesa/main/teximage.c @@ -5031,7 +5031,7 @@ _mesa_validate_texbuffer_format(const struct gl_context *ctx, void _mesa_texture_buffer_range(struct gl_context *ctx, - struct gl_texture_object *texObj, GLenum target, + struct gl_texture_object *texObj, GLenum target, GLenum internalFormat, struct gl_buffer_object *bufObj, GLintptr offset, GLsizeiptr size, bool range, ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/vec4: Calculate register allocation q values manually.
On 02/18/2015 10:57 AM, Mark Janes wrote:
This patch fixes a performance regression that causes our piglit CI
system to slow by 50%. If anyone has time to take a look at this and
provide a RB, it will improve the rate at which you get your piglit
results.
When you send a message like this, you should also say
Tested-by: Mark Janes mark.a.ja...@intel.com
:)
-Mark
Francisco Jerez curroje...@riseup.net writes:
This fixes a regression in the running time of Piglit introduced by
commit 78e9043475d4bed8b50f7e413963c960fa0935bb, which increased the
number of register allocation classes set up by the VEC4 back-end
from 2 to 16. The algorithm used by ra_set_finalize() to calculate
them is unnecessarily expensive, do it manually like the FS back-end
does.
Reported-by: Mark Janes mark.a.ja...@intel.com
---
src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
index 46f0bfd..a286f8a 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
@@ -129,10 +129,13 @@ brw_vec4_alloc_reg_set(struct intel_screen *screen)
* between them and the base GRF registers (and also each other).
*/
int reg = 0;
+ unsigned *q_values[MAX_VGRF_SIZE];
for (int i = 0; i class_count; i++) {
int class_reg_count = base_reg_count - (class_sizes[i] - 1);
screen-vec4_reg_set.classes[i] =
ra_alloc_reg_class(screen-vec4_reg_set.regs);
+ q_values[i] = new unsigned[MAX_VGRF_SIZE];
+
for (int j = 0; j class_reg_count; j++) {
ra_class_add_reg(screen-vec4_reg_set.regs,
screen-vec4_reg_set.classes[i], reg);
@@ -146,10 +149,23 @@ brw_vec4_alloc_reg_set(struct intel_screen *screen)
reg++;
}
+
+ for (int j = 0; j class_count; j++) {
+ /* Calculate the q values manually because the algorithm used by
+ * ra_set_finalize() to do it has higher complexity affecting the
+ * start-up time of some applications. q(i, j) is just the maximum
+ * number of registers from class i a register from class j can
+ * conflict with.
+ */
+ q_values[i][j] = class_sizes[i] + class_sizes[j] - 1;
+ }
}
assert(reg == ra_reg_count);
- ra_set_finalize(screen-vec4_reg_set.regs, NULL);
+ ra_set_finalize(screen-vec4_reg_set.regs, q_values);
+
+ for (int i = 0; i MAX_VGRF_SIZE; i++)
+ delete[] q_values[i];
}
void
--
2.1.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [xorg 2/3] dri2: Pass swap-interval=0 ScheduleSwap requests to the ddx
On Monday 19 January 2015, Chris Wilson wrote:
Allow the DDXes to opt-in and handle swap-interval=0 requests for
themselves, for example by using asynchronous pageflips, rather than
forcing a blit. This has the important side-effect of also
disambiguating CopyRegion calls to always be client requests.
References: http://lists.x.org/archives/xorg-devel/2011-June/023102.html
References: http://lists.x.org/archives/xorg-devel/2012-February/029336.html
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
hw/xfree86/dri2/dri2.c | 14 ++
hw/xfree86/dri2/dri2.h | 5 -
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index f9f594d..2c0367e 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -114,6 +114,7 @@ typedef struct _DRI2Screen {
int fd;
unsigned int lastSequence;
int prime_id;
+int scheduleSwap0;
DRI2CreateBufferProcPtr CreateBuffer;
DRI2DestroyBufferProcPtr DestroyBuffer;
@@ -1116,8 +1117,8 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw,
CARD64 target_msc,
return BadDrawable;
}
-/* Old DDX or no swap interval, just blit */
-if (!ds-ScheduleSwap || !pPriv-swap_interval || pPriv-prime_id) {
+/* Old DDX or PRIME, just blit */
+if (!ds-scheduleSwap0 || pPriv-prime_id) {
I've been testing these patches with the radeon driver, and happened to
notice that it never pageflips. I think this line needs to be changed to
something along the lines of:
if (!ds-ScheduleSwap || (pPriv-swap_interval == 0 !ds-scheduleSwap0) ||
pPriv-prime_id)
BoxRec box;
RegionRec region;
@@ -1139,7 +1140,9 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw,
CARD64 target_msc,
* In the simple glXSwapBuffers case, all params will be 0, and we just
* need to schedule a swap for the last swap target + the swap interval.
*/
-if (target_msc == 0 divisor == 0 remainder == 0) {
+if (pPriv-swap_interval == 0) {
+ target_msc = 0;
+} else if (target_msc == 0 divisor == 0 remainder == 0) {
/* If the current vblank count of the drawable's crtc is lower
* than the count stored in last_swap_target from a previous swap
* then reinitialize last_swap_target to the current crtc's msc,
@@ -1162,7 +1165,6 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw,
CARD64 target_msc,
* number of pending swaps.
*/
target_msc = pPriv-last_swap_target + pPriv-swap_interval;
-
}
pPriv-swapsPending++;
@@ -1558,6 +1560,10 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
ds-CopyRegion2 = info-CopyRegion2;
}
+if (info-version = 10) {
+ds-scheduleSwap0 = info-scheduleSwap0;
+}
+
/*
* if the driver doesn't provide an AuthMagic function or the info struct
* version is too low, call through LegacyAuthMagic
diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
index 1e7afdd..1cf4288 100644
--- a/hw/xfree86/dri2/dri2.h
+++ b/hw/xfree86/dri2/dri2.h
@@ -205,7 +205,7 @@ typedef int (*DRI2GetParamProcPtr) (ClientPtr client,
/**
* Version of the DRI2InfoRec structure defined in this header
*/
-#define DRI2INFOREC_VERSION 9
+#define DRI2INFOREC_VERSION 10
typedef struct {
unsigned int version; /** Version of this struct */
@@ -252,6 +252,9 @@ typedef struct {
DRI2CreateBuffer2ProcPtr CreateBuffer2;
DRI2DestroyBuffer2ProcPtr DestroyBuffer2;
DRI2CopyRegion2ProcPtr CopyRegion2;
+
+/* added in version 10 */
+int scheduleSwap0;
} DRI2InfoRec, *DRI2InfoPtr;
extern _X_EXPORT Bool DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] mesa: Check first that draw buffers are valid for glDrawBuffers on GLES3
On Tue, Jan 13, 2015 at 3:29 AM, Eduardo Lima Mitev el...@igalia.com wrote: This patch was updated and is pending review. I think we're waiting on a new version with Tapani's comment addressed. The patch looks right, FWIW. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/16] More fixes for dEQP failing tests
On 01/22/2015 10:06 AM, Emil Velikov wrote: On 15/12/14 12:08, Eduardo Lima Mitev wrote: On 12/15/2014 12:21 PM, Emil Velikov wrote: Above you've mentioned test failures were gathered ... against 10.3.3, which brings the question: Should we include those in either one of the 10.3 and 10.4 stable branches ? Or are they so insignificant/trivial that we don't expect (m)any programs to hit them ? Hi Emil, We are probably not the right people to answer this, so I will let the reviewers take the call. That said, there are a few patches from these series that fix concrete functionality that has an impact on rendering results, so I suppose these will be interesting to port to stable branches. From a quick skim at the commit summaries I cannot pick the rendering fixes. Can you kindly list them out and I'll gladly chase the relevant people. There are many others that just improve spec compliance and has little or no practical impact on functionality, and probably are not worth porting. I guess the spec compliance depends on how many users there are flexing those code-paths. That aside I do share your view. I think these are find candidates for 10.5, but I'm not concerned about getting them into earlier release series. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Adds check for integer internal formal and num samples in glRenderbufferStorageMultisample
Reviewed-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Returns correct error values from gl(Get)SamplerParameter*() on GL-ES 3.0+
Reviewed-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/10] glsl: A shader cannot redefine or overload built-in functions in GLSL ES 3.00
On Mon, Dec 1, 2014 at 5:04 AM, Eduardo Lima Mitev el...@igalia.com wrote:
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
Create a new search function to look for matching built-in functions by name
and use it for built-in function redefinition or overload in GLSL ES 3.00.
GLSL ES 3.0 spec, chapter 6.1 Function Definitions, page 71
A shader cannot redefine or overload built-in functions.
In case of GLSL ES 1.0 spec, chapter 6.1 Function Definitions, page 54
Function names can be overloaded. This allows the same function name to be
used for multiple functions, as long as the argument list types differ. If
functions’ names and argument types match, then their return type and
parameter qualifiers must also match. Function signature matching is based on
parameter type only, no qualifiers are used. Overloading is used heavily in
the
built-in functions. When overloaded functions (or indeed any functions) are
resolved, an exact match for the function's signature is sought. This includes
exact match of array size as well. No promotion or demotion of the return type
or input argument types is done. All expected combination of inputs and
outputs must be defined as separate functions.
So this check is specific to GLSL ES 3.00.
This patch fixes the following dEQP tests:
dEQP-GLES3.functional.shaders.functions.invalid.overload_builtin_function_vertex
dEQP-GLES3.functional.shaders.functions.invalid.overload_builtin_function_fragment
dEQP-GLES3.functional.shaders.functions.invalid.redefine_builtin_function_vertex
dEQP-GLES3.functional.shaders.functions.invalid.redefine_builtin_function_fragment
No piglit regressions.
Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
---
src/glsl/ast_to_hir.cpp| 22 ++
src/glsl/builtin_functions.cpp | 11 +++
src/glsl/ir.h | 4
3 files changed, 37 insertions(+)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index fe1e129..b7074bc 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4167,6 +4167,28 @@ ast_function::hir(exec_list *instructions,
return NULL;
}
}
+ } else {
+ /* From GLSL ES 3.0 spec, chapter 6.1 Function Definitions, page
71:
+ *
+ * A shader cannot redefine or overload built-in functions.
+ *
+ * While in GLSL ES 1.0 spec, chapter 6.1 Function Definitions,
page
+ * 54, this is allowed:
+ *
+ * Function names can be overloaded. [...] Overloading is used
heavily
+ * in the built-in functions.
I don't think that quote is really explicitly saying that you can
overload built-in functions. It's just saying that built-in functions
contain many overloads.
It doesn't, however, prohibit the user from adding overloads of their own.
I'd probably replace the spec citation with just a statement that the
GLSL ES 1.0 spec doesn't prohibit overloading built-in functions,
since it really doesn't say anything explicitly about the topic.
+ *
+ */
+ if (state-es_shader state-language_version = 300) {
+/* Local shader has no exact candidates; check the built-ins. */
+_mesa_glsl_initialize_builtin_functions();
+if (_mesa_glsl_find_builtin_function_by_name(state, name)) {
+ YYLTYPE loc = this-get_location();
+ _mesa_glsl_error( loc, state,
+A shader cannot redefine or overload
built-in
+function `%s' in GLSL ES 3.00, name);
+}
+ }
}
}
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index bb7fbcd..f5052d3 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -4618,6 +4618,17 @@
_mesa_glsl_find_builtin_function(_mesa_glsl_parse_state *state,
return s;
}
+ir_function *
+_mesa_glsl_find_builtin_function_by_name(_mesa_glsl_parse_state *state,
+ const char *name)
+{
+ ir_function * f;
Remove the space after the *.
As far as I can tell, this patch looks correct. Confirmation from Ken
would be nice as well.
(This behavior should have been the default in all versions of GLSL as
far as I'm concerned)
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glapi: add GL_ARB_program_interface_query skeleton
On 02/17/2015 03:27 AM, Tapani Pälli wrote: Signed-off-by: Tapani Pälli tapani.pa...@intel.com --- src/mapi/glapi/gen/ARB_program_interface_query.xml | 109 + src/mapi/glapi/gen/gl_API.xml | 2 + src/mapi/glapi/gen/gl_genexec.py | 1 + src/mesa/Makefile.sources | 2 + src/mesa/main/program_resource.c | 70 + src/mesa/main/program_resource.h | 59 +++ 6 files changed, 243 insertions(+) create mode 100644 src/mapi/glapi/gen/ARB_program_interface_query.xml create mode 100644 src/mesa/main/program_resource.c create mode 100644 src/mesa/main/program_resource.h diff --git a/src/mapi/glapi/gen/ARB_program_interface_query.xml b/src/mapi/glapi/gen/ARB_program_interface_query.xml new file mode 100644 index 000..c042dbd --- /dev/null +++ b/src/mapi/glapi/gen/ARB_program_interface_query.xml @@ -0,0 +1,109 @@ +?xml version=1.0? +!DOCTYPE OpenGLAPI SYSTEM gl_API.dtd + +OpenGLAPI + +category name=GL_ARB_program_interface_query number=134 + +enum name=UNIFORM value=0x92E1/ +enum name=UNIFORM_BLOCK value=0x92E2/ +enum name=PROGRAM_INPUT value=0x92E3/ +enum name=PROGRAM_OUTPUT value=0x92E4/ +enum name=BUFFER_VARIABLE value=0x92E5/ +enum name=SHADER_STORAGE_BLOCK value=0x92E6/ +enum name=ATOMIC_COUNTER_BUFFER value=0x92C0/ +enum name=VERTEX_SUBROUTINE value=0x92E8/ +enum name=TESS_CONTROL_SUBROUTINE value=0x92E9/ +enum name=TESS_EVALUATION_SUBROUTINE value=0x92EA/ +enum name=GEOMETRY_SUBROUTINE value=0x92EB/ +enum name=FRAGMENT_SUBROUTINE value=0x92EC/ +enum name=COMPUTE_SUBROUTINE value=0x92ED/ +enum name=VERTEX_SUBROUTINE_UNIFORM value=0x92EE/ +enum name=TESS_CONTROL_SUBROUTINE_UNIFORM value=0x92EF/ +enum name=TESS_EVALUATION_SUBROUTINE_UNIFORM value=0x92F0/ +enum name=GEOMETRY_SUBROUTINE_UNIFORM value=0x92F1/ +enum name=FRAGMENT_SUBROUTINE_UNIFORM value=0x92F2/ +enum name=COMPUTE_SUBROUTINE_UNIFORM value=0x92F3/ +enum name=TRANSFORM_FEEDBACK_VARYING value=0x92F4/ +enum name=ACTIVE_RESOURCES value=0x92F5/ +enum name=MAX_NAME_LENGTH value=0x92F6/ +enum name=MAX_NUM_ACTIVE_VARIABLES value=0x92F7/ +enum name=MAX_NUM_COMPATIBLE_SUBROUTINES value=0x92F8/ +enum name=NAME_LENGTH value=0x92F9/ +enum name=TYPE value=0x92FA/ +enum name=ARRAY_SIZE value=0x92FB/ +enum name=OFFSET value=0x92FC/ +enum name=BLOCK_INDEX value=0x92FD/ +enum name=ARRAY_STRIDE value=0x92FE/ +enum name=MATRIX_STRIDE value=0x92FF/ +enum name=IS_ROW_MAJOR value=0x9300/ +enum name=ATOMIC_COUNTER_BUFFER_INDEX value=0x9301/ +enum name=BUFFER_BINDING value=0x9302/ +enum name=BUFFER_DATA_SIZE value=0x9303/ +enum name=NUM_ACTIVE_VARIABLES value=0x9304/ +enum name=ACTIVE_VARIABLES value=0x9305/ +enum name=REFERENCED_BY_VERTEX_SHADER value=0x9306/ +enum name=REFERENCED_BY_TESS_CONTROL_SHADER value=0x9307/ +enum name=REFERENCED_BY_TESS_EVALUATION_SHADER value=0x9308/ +enum name=REFERENCED_BY_GEOMETRY_SHADER value=0x9309/ +enum name=REFERENCED_BY_FRAGMENT_SHADER value=0x930A/ +enum name=REFERENCED_BY_COMPUTE_SHADER value=0x930B/ +enum name=TOP_LEVEL_ARRAY_SIZE value=0x930C/ +enum name=TOP_LEVEL_ARRAY_STRIDE value=0x930D/ +enum name=LOCATION value=0x930E/ +enum name=LOCATION_INDEX value=0x930F/ +enum name=IS_PER_PATCH value=0x92E7/ +enum
Re: [Mesa-dev] [PATCH 0/2] GL_ARB_program_interface_query
On 02/17/2015 10:23 AM, Matt Turner wrote: On Tue, Feb 17, 2015 at 3:27 AM, Tapani Pälli tapani.pa...@intel.com wrote: Here is a skeleton for the GL_ARB_program_interface_query API functions. Adding the enum values makes it possible to start introducing changes in the current shader query functions using these values. Plan is to build a resource list during program linking which contains pointers to the required data. First refactor matching existing query functions to use resource list and then introduce new api functionality. We usually only commit vertical slices of functionality -- i.e., whole implementations of a single feature. Should we commit these two patches as is? Is this feature different than most others? It's probably okay to update GL3.txt. :) We should wait to land the other patch until there's at least some meat behind it. GL_ARB_program_interface_query is one of those extensions that is going to be a lot of typing. It will be much like DSA in that respect. To save rebase woes, I think it will be okay to land some parts of it before other parts are ready. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: Minor fixes to PBO uploads and downloads.
On Wed, Feb 18, 2015 at 5:45 PM, Laura Ekstrand la...@jlekstrand.net
wrote:
Fixes all of the failures in
arb_direct_state_access/gettextureimage-targets
except for GL_TEXTURE_1D_ARRAY PBO. Previously, the miptree for meta pbo
uploads and downloads was not getting initialized correctly.
---
src/mesa/drivers/common/meta_tex_subimage.c | 8 ++--
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 2 +-
src/mesa/drivers/dri/i965/intel_tex.c | 3 ++-
src/mesa/main/dd.h| 1 +
4 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/common/meta_tex_subimage.c
b/src/mesa/drivers/common/meta_tex_subimage.c
index 68c8273..6196283 100644
--- a/src/mesa/drivers/common/meta_tex_subimage.c
+++ b/src/mesa/drivers/common/meta_tex_subimage.c
@@ -51,7 +51,7 @@ create_texture_for_pbo(struct gl_context *ctx, bool
create_pbo,
{
uint32_t pbo_format;
GLenum internal_format;
- unsigned row_stride;
+ unsigned row_stride, image_stride;
struct gl_buffer_object *buffer_obj;
struct gl_texture_object *tex_obj;
struct gl_texture_image *tex_image;
@@ -74,6 +74,8 @@ create_texture_for_pbo(struct gl_context *ctx, bool
create_pbo,
pixels = _mesa_image_address3d(packing, pixels,
width, height, format, type, 0, 0, 0);
row_stride = _mesa_image_row_stride(packing, width, format, type);
+ image_stride = _mesa_image_image_stride(packing, width, height, format,
+ type);
if (_mesa_is_bufferobj(packing-BufferObj)) {
*tmp_pbo = 0;
@@ -100,8 +102,9 @@ create_texture_for_pbo(struct gl_context *ctx, bool
create_pbo,
_mesa_GenTextures(1, tmp_tex);
tex_obj = _mesa_lookup_texture(ctx, *tmp_tex);
tex_obj-Target = depth 1 ? GL_TEXTURE_2D_ARRAY : GL_TEXTURE_2D;
+ _mesa_initialize_texture_object(ctx, tex_obj, *tmp_tex,
tex_obj-Target);
tex_obj-Immutable = GL_TRUE;
- _mesa_initialize_texture_object(ctx, tex_obj, *tmp_tex, GL_TEXTURE_2D);
+ tex_obj-NumLayers = 1;
Why are you setting NumLayers to 1? If this is the number of array slices,
shouldn't it be set to depth or something?
internal_format = _mesa_get_format_base_format(pbo_format);
@@ -114,6 +117,7 @@ create_texture_for_pbo(struct gl_context *ctx, bool
create_pbo,
buffer_obj,
(intptr_t)pixels,
row_stride,
+ image_stride,
read_only)) {
_mesa_DeleteTextures(1, tmp_tex);
_mesa_DeleteBuffers(1, tmp_pbo);
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 0e3888f..b46532d 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -724,7 +724,7 @@ intel_miptree_create_for_bo(struct brw_context *brw,
mt = intel_miptree_create_layout(brw, target, format,
0, 0,
width, height, depth,
-true, 0, false);
+true, 0, true);
It's not at all obvious from the commit message that this is happening or
what it is. Since it lives inside intel_miptree_create_bo, it should
probably be its own commit with its own commit message.
if (!mt) {
free(mt);
return mt;
diff --git a/src/mesa/drivers/dri/i965/intel_tex.c
b/src/mesa/drivers/dri/i965/intel_tex.c
index 2d3009a..3a0c09a 100644
--- a/src/mesa/drivers/dri/i965/intel_tex.c
+++ b/src/mesa/drivers/dri/i965/intel_tex.c
@@ -305,6 +305,7 @@ intel_set_texture_storage_for_buffer_object(struct
gl_context *ctx,
struct gl_buffer_object
*buffer_obj,
uint32_t buffer_offset,
uint32_t row_stride,
+uint32_t image_stride,
bool read_only)
{
struct brw_context *brw = brw_context(ctx);
@@ -334,7 +335,7 @@ intel_set_texture_storage_for_buffer_object(struct
gl_context *ctx,
drm_intel_bo *bo = intel_bufferobj_buffer(brw, intel_buffer_obj,
buffer_offset,
- row_stride * image-Height);
+ image_stride * image-Depth);
intel_texobj-mt =
intel_miptree_create_for_bo(brw, bo,
image-TexFormat,
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index ec8662b..9de08e2 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -429,6
[Mesa-dev] [PATCH 8/9] i965/vec4: Replace debug_flag with debug_enabled.
backend_visitor now handles this, so we can delete the vec4_visitor
specific code.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vec4.h | 3 ---
src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp| 4 +---
src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp | 2 +-
src/mesa/drivers/dri/i965/test_vec4_copy_propagation.cpp | 2 +-
src/mesa/drivers/dri/i965/test_vec4_register_coalesce.cpp | 2 +-
6 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/mesa/drivers/dri/i965/brw_vec4.h
index e4d0cb7..a24f843 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -84,7 +84,6 @@ public:
struct gl_shader_program *shader_prog,
gl_shader_stage stage,
void *mem_ctx,
-bool debug_flag,
bool no_spills,
shader_time_shader_type st_base,
shader_time_shader_type st_written,
@@ -398,8 +397,6 @@ protected:
virtual vec4_instruction *emit_urb_write_opcode(bool complete) = 0;
virtual int compute_array_stride(ir_dereference_array *ir);
- const bool debug_flag;
-
private:
/**
* If true, then register allocation should fail instead of spilling.
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
index 7a0ea3c..2002ffd 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
@@ -41,7 +41,7 @@ vec4_gs_visitor::vec4_gs_visitor(struct brw_context *brw,
bool no_spills)
: vec4_visitor(brw, c-base, c-gp-program.Base, c-key.base,
c-prog_data.base, prog, MESA_SHADER_GEOMETRY, mem_ctx,
- INTEL_DEBUG DEBUG_GS, no_spills,
+ no_spills,
ST_GS, ST_GS_WRITTEN, ST_GS_RESET),
c(c)
{
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index faae2c9..4f66b62 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -3588,7 +3588,6 @@ vec4_visitor::vec4_visitor(struct brw_context *brw,
struct gl_shader_program *shader_prog,
gl_shader_stage stage,
void *mem_ctx,
- bool debug_flag,
bool no_spills,
shader_time_shader_type st_base,
shader_time_shader_type st_written,
@@ -3601,7 +3600,6 @@ vec4_visitor::vec4_visitor(struct brw_context *brw,
fail_msg(NULL),
first_non_payload_grf(0),
need_all_constants_in_pull_buffer(false),
- debug_flag(debug_flag),
no_spills(no_spills),
st_base(st_base),
st_written(st_written),
@@ -3662,7 +3660,7 @@ vec4_visitor::fail(const char *format, ...)
this-fail_msg = msg;
- if (debug_flag) {
+ if (debug_enabled) {
fprintf(stderr, %s, msg);
}
}
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
index 72b6ef0..129c2db 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
@@ -220,7 +220,7 @@ vec4_vs_visitor::vec4_vs_visitor(struct brw_context *brw,
: vec4_visitor(brw, vs_compile-base, vs_compile-vp-program.Base,
vs_compile-key.base, vs_prog_data-base, prog,
MESA_SHADER_VERTEX,
- mem_ctx, INTEL_DEBUG DEBUG_VS, false /* no_spills */,
+ mem_ctx, false /* no_spills */,
ST_VS, ST_VS_WRITTEN, ST_VS_RESET),
vs_compile(vs_compile),
vs_prog_data(vs_prog_data)
diff --git a/src/mesa/drivers/dri/i965/test_vec4_copy_propagation.cpp
b/src/mesa/drivers/dri/i965/test_vec4_copy_propagation.cpp
index 992cb60..f9e4ce1 100644
--- a/src/mesa/drivers/dri/i965/test_vec4_copy_propagation.cpp
+++ b/src/mesa/drivers/dri/i965/test_vec4_copy_propagation.cpp
@@ -47,7 +47,7 @@ public:
struct gl_shader_program *shader_prog)
: vec4_visitor(brw, NULL, NULL, NULL, NULL, shader_prog,
MESA_SHADER_VERTEX, NULL,
- false, false /* no_spills */,
+ false /* no_spills */,
ST_NONE, ST_NONE, ST_NONE)
{
}
diff --git a/src/mesa/drivers/dri/i965/test_vec4_register_coalesce.cpp
b/src/mesa/drivers/dri/i965/test_vec4_register_coalesce.cpp
index 3c03f83..0c27162 100644
--- a/src/mesa/drivers/dri/i965/test_vec4_register_coalesce.cpp
+++ b/src/mesa/drivers/dri/i965/test_vec4_register_coalesce.cpp
@@ -50,7 +50,7 @@ public:
[Mesa-dev] [PATCH 3/9] glsl: Create a _mesa_shader_stage_to_abbrev() function.
This is similar to _mesa_shader_stage_to_string(), but returns VS
instead of vertex.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/glsl/glsl_parser_extras.cpp | 17 +
src/glsl/glsl_parser_extras.h | 3 +++
2 files changed, 20 insertions(+)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index ccdf031..0334e4a 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -376,6 +376,23 @@ _mesa_shader_stage_to_string(unsigned stage)
return unknown;
}
+/**
+ * Translate a gl_shader_stage to a shader stage abbreviation (VS, GS, FS)
+ * for debug printouts and error messages.
+ */
+const char *
+_mesa_shader_stage_to_abbrev(unsigned stage)
+{
+ switch (stage) {
+ case MESA_SHADER_VERTEX: return VS;
+ case MESA_SHADER_FRAGMENT: return FS;
+ case MESA_SHADER_GEOMETRY: return GS;
+ }
+
+ assert(!Should not get here.);
+ return unknown;
+}
+
/* This helper function will append the given message to the shader's
info log and report it via GL_ARB_debug_output. Per that extension,
'type' is one of the enum values classifying the message, and
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index 843fdae..6861fac 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -576,6 +576,9 @@ extern C {
extern const char *
_mesa_shader_stage_to_string(unsigned stage);
+extern const char *
+_mesa_shader_stage_to_abbrev(unsigned stage);
+
extern int glcpp_preprocess(void *ctx, const char **shader, char **info_log,
const struct gl_extensions *extensions, struct
gl_context *gl_ctx);
--
2.2.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/9] i965: Create backend_visitor fields for debugging messages.
We introduce three new fields in backend_visitor:
- debug_enabled: whether or not INTEL_DEBUG DEBUG_stage flag
- stage_name: vertex, fragment, etc. for use in messages
- stage_abbrev: VS, FS, etc. for use in messages
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 3 +++
src/mesa/drivers/dri/i965/brw_shader.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 5781c6b..71146c5 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -709,6 +709,9 @@ backend_visitor::backend_visitor(struct brw_context *brw,
cfg(NULL),
stage(stage)
{
+ debug_enabled = INTEL_DEBUG intel_debug_flag_for_shader_stage(stage);
+ stage_name = _mesa_shader_stage_to_string(stage);
+ stage_abbrev = _mesa_shader_stage_to_abbrev(stage);
}
bool
diff --git a/src/mesa/drivers/dri/i965/brw_shader.h
b/src/mesa/drivers/dri/i965/brw_shader.h
index 7bff186..5c95355 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.h
+++ b/src/mesa/drivers/dri/i965/brw_shader.h
@@ -185,6 +185,9 @@ public:
cfg_t *cfg;
gl_shader_stage stage;
+ bool debug_enabled;
+ const char *stage_name;
+ const char *stage_abbrev;
brw::simple_allocator alloc;
--
2.2.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/9] i965/fs: Remove type parameter from emit_vs_system_value().
Every VS system value has type D. We can always add this back if that
changes, but for now, it's extra typing.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs.h | 2 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 7 +++
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index a2e6192..9375412 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -259,7 +259,7 @@ public:
glsl_interp_qualifier interpolation_mode,
int location, bool mod_centroid,
bool mod_sample);
- fs_reg *emit_vs_system_value(enum brw_reg_type type, int location);
+ fs_reg *emit_vs_system_value(int location);
void emit_interpolation_setup_gen4();
void emit_interpolation_setup_gen6();
void compute_sample_position(fs_reg dst, fs_reg int_sample_pos);
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 24cc118..a2343c6 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -51,10 +51,10 @@ extern C {
fs_reg *
-fs_visitor::emit_vs_system_value(enum brw_reg_type type, int location)
+fs_visitor::emit_vs_system_value(int location)
{
fs_reg *reg = new(this-mem_ctx)
- fs_reg(ATTR, VERT_ATTRIB_MAX, type);
+ fs_reg(ATTR, VERT_ATTRIB_MAX, BRW_REGISTER_TYPE_D);
brw_vs_prog_data *vs_prog_data = (brw_vs_prog_data *) prog_data;
switch (location) {
@@ -191,8 +191,7 @@ fs_visitor::visit(ir_variable *ir)
case SYSTEM_VALUE_VERTEX_ID:
case SYSTEM_VALUE_VERTEX_ID_ZERO_BASE:
case SYSTEM_VALUE_INSTANCE_ID:
- reg = emit_vs_system_value(brw_type_for_base_type(ir-type),
-ir-data.location);
+ reg = emit_vs_system_value(ir-data.location);
break;
case SYSTEM_VALUE_SAMPLE_POS:
reg = emit_samplepos_setup();
--
2.2.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/9] i965/fs: Use VARYING_SLOT checks rather than strcmp().
Comparing the location field is equivalent and more efficient.
We'll also need this when we start using NIR for ARB programs, as our
NIR converter will set the location field correctly, but probably won't
use the GLSL names for these concepts.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index 850f132..2123829 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
@@ -195,7 +195,7 @@ fs_visitor::nir_setup_inputs(nir_shader *shader)
fs_reg varying = offset(nir_inputs, var-data.driver_location);
fs_reg reg;
- if (!strcmp(var-name, gl_FragCoord)) {
+ if (var-data.location == VARYING_SLOT_POS) {
reg = *emit_fragcoord_interpolation(var-data.pixel_center_integer,
var-data.origin_upper_left);
emit_percomp(MOV(varying, reg), 0xF);
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index a2343c6..04e0f9a 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -92,10 +92,10 @@ fs_visitor::visit(ir_variable *ir)
reg = new(this-mem_ctx)
fs_reg(ATTR, ir-data.location,
brw_type_for_base_type(ir-type-get_scalar_type()));
- } else if (!strcmp(ir-name, gl_FragCoord)) {
+ } else if (ir-data.location == VARYING_SLOT_POS) {
reg = emit_fragcoord_interpolation(ir-data.pixel_center_integer,
ir-data.origin_upper_left);
- } else if (!strcmp(ir-name, gl_FrontFacing)) {
+ } else if (ir-data.location == VARYING_SLOT_FACE) {
reg = emit_frontfacing_interpolation();
} else {
reg = new(this-mem_ctx) fs_reg(vgrf(ir-type));
--
2.2.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89218] lower_instructions.cpp:648:48: error: invalid suffix 'd' on floating constant
https://bugs.freedesktop.org/show_bug.cgi?id=89218 Bug ID: 89218 Summary: lower_instructions.cpp:648:48: error: invalid suffix 'd' on floating constant Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: All Status: NEW Keywords: bisected, regression Severity: blocker Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: v...@freedesktop.org QA Contact: mesa-dev@lists.freedesktop.org CC: airl...@freedesktop.org, imir...@alum.mit.edu mesa: de798bb93708cebdedecefebdc96a82d9481f2aa (master 10.6.0-devel) Compiling src/glsl/lower_instructions.cpp ... src/glsl/lower_instructions.cpp:648:45: error: invalid suffix d on floating constant src/glsl/lower_instructions.cpp:720:45: error: invalid suffix d on floating constant 2e7e7b8af6cb9055204e196db9902ec9991cd538 is the first bad commit commit 2e7e7b8af6cb9055204e196db9902ec9991cd538 Author: Ilia Mirkin imir...@alum.mit.edu Date: Thu Jul 17 17:59:32 2014 -0400 glsl: add a lowering pass for frexp/ldexp with double arguments Signed-off-by: Ilia Mirkin imir...@alum.mit.edu Reviewed-by: Dave Airlie airl...@redhat.com :04 04 fa27b7bf59bf78d757b5dc16b047bdbd21bcda2c cbc878cb1e925c9085c29f29ad2009881775dc2f Msrc bisect run success -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/10] glsl: A shader cannot redefine or overload built-in functions in GLSL ES 3.00
On Wednesday 18 February 2015 15:08:19 Kenneth Graunke wrote:
On Wednesday, February 18, 2015 12:00:39 PM Matt Turner wrote:
On Mon, Dec 1, 2014 at 5:04 AM, Eduardo Lima Mitev el...@igalia.com
wrote:
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
Create a new search function to look for matching built-in functions by
name and use it for built-in function redefinition or overload in GLSL
ES 3.00.
GLSL ES 3.0 spec, chapter 6.1 Function Definitions, page 71
A shader cannot redefine or overload built-in functions.
In case of GLSL ES 1.0 spec, chapter 6.1 Function Definitions, page 54
Function names can be overloaded. This allows the same function name to
be
used for multiple functions, as long as the argument list types differ.
If
functions’ names and argument types match, then their return type and
parameter qualifiers must also match. Function signature matching is
based on parameter type only, no qualifiers are used. Overloading is
used heavily in the built-in functions. When overloaded functions (or
indeed any functions) are resolved, an exact match for the function's
signature is sought. This includes exact match of array size as well.
No promotion or demotion of the return type or input argument types is
done. All expected combination of inputs and outputs must be defined as
separate functions.
So this check is specific to GLSL ES 3.00.
This patch fixes the following dEQP tests:
dEQP-GLES3.functional.shaders.functions.invalid.overload_builtin_functio
n_vertex
dEQP-GLES3.functional.shaders.functions.invalid.overload_builtin_functi
on_fragment
dEQP-GLES3.functional.shaders.functions.invalid.redefine_builtin_functi
on_vertex
dEQP-GLES3.functional.shaders.functions.invalid.redefine_builtin_functi
on_fragment
No piglit regressions.
Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
---
src/glsl/ast_to_hir.cpp| 22 ++
src/glsl/builtin_functions.cpp | 11 +++
src/glsl/ir.h | 4
3 files changed, 37 insertions(+)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index fe1e129..b7074bc 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4167,6 +4167,28 @@ ast_function::hir(exec_list *instructions,
return NULL;
}
}
+ } else {
+ /* From GLSL ES 3.0 spec, chapter 6.1 Function Definitions,
page 71: + *
+ * A shader cannot redefine or overload built-in functions.
+ *
+ * While in GLSL ES 1.0 spec, chapter 6.1 Function
Definitions, page + * 54, this is allowed:
+ *
+ * Function names can be overloaded. [...] Overloading is
used heavily + * in the built-in functions.
I don't think that quote is really explicitly saying that you can
overload built-in functions. It's just saying that built-in functions
contain many overloads.
It doesn't, however, prohibit the user from adding overloads of their own.
I'd probably replace the spec citation with just a statement that the
GLSL ES 1.0 spec doesn't prohibit overloading built-in functions,
since it really doesn't say anything explicitly about the topic.
The GLSL ES 1.0 specification actually very explicitly allows
overloading of built-in functions:
From the GLSL ES 1.0 specification, section 4.2.6:
User defined functions may overload built-in functions.
and chapter 8:
User code can overload the built-in functions but cannot redefine
them.
This is indeed different than GLSL ES 3.00, which prohibits both,
and different than desktop GLSL, which has entirely different rules.
+ *
+ */
+ if (state-es_shader state-language_version = 300) {
+/* Local shader has no exact candidates; check the
built-ins. */ +_mesa_glsl_initialize_builtin_functions();
+if (_mesa_glsl_find_builtin_function_by_name(state, name))
{
+ YYLTYPE loc = this-get_location();
+ _mesa_glsl_error( loc, state,
+A shader cannot redefine or overload
built-in +function `%s' in GLSL ES
3.00, name); +}
+ }
This code looks good, but there's one subtle issue with where you've
placed it. Namely, it allows this to compile:
#version 300 es
precision highp float;
out vec4 color;
void main()
{
color = vec4(sin(0.5));
}
float sin(float x);
When handling that prototype, it will take the existing
exact_matching_signature != NULL path (since your code is the else to
that block), which sees it as a harmless redundant prototype, and allows
it.
I would advise simply moving this
[Mesa-dev] [PATCH 9/9] i965/vec4: Print VS or GS when compiles fail, not vec4.
This is now trivial to do right. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp index 4f66b62..562fc30 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp @@ -3656,7 +3656,7 @@ vec4_visitor::fail(const char *format, ...) va_start(va, format); msg = ralloc_vasprintf(mem_ctx, format, va); va_end(va); - msg = ralloc_asprintf(mem_ctx, vec4 compile failed: %s\n, msg); + msg = ralloc_asprintf(mem_ctx, %s compile failed: %s\n, stage_abbrev, msg); this-fail_msg = msg; -- 2.2.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/9] i965: Add a function to translate MESA_SHADER_* into DEBUG_* enums.
When compiling, we have a gl_shader_stage (MESA_SHADER_*) enum, and want
to know whether debugging is enabled for that stage. This allows us to
easily translate it into the corresponding debug flag.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/intel_debug.c | 13 +
src/mesa/drivers/dri/i965/intel_debug.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_debug.c
b/src/mesa/drivers/dri/i965/intel_debug.c
index 013602c..0cb7aef 100644
--- a/src/mesa/drivers/dri/i965/intel_debug.c
+++ b/src/mesa/drivers/dri/i965/intel_debug.c
@@ -72,6 +72,19 @@ static const struct dri_debug_control debug_control[] = {
{ NULL,0 }
};
+uint64_t
+intel_debug_flag_for_shader_stage(gl_shader_stage stage)
+{
+ int flags[] = {
+ [MESA_SHADER_VERTEX] = DEBUG_VS,
+ [MESA_SHADER_GEOMETRY] = DEBUG_GS,
+ [MESA_SHADER_FRAGMENT] = DEBUG_WM,
+ [MESA_SHADER_COMPUTE] = 0, /* no debug flag yet */
+ };
+ STATIC_ASSERT(MESA_SHADER_STAGES == 4);
+ return flags[stage];
+}
+
void
brw_process_intel_debug_variable(struct brw_context *brw)
{
diff --git a/src/mesa/drivers/dri/i965/intel_debug.h
b/src/mesa/drivers/dri/i965/intel_debug.h
index 01b4dcf..ed879ab 100644
--- a/src/mesa/drivers/dri/i965/intel_debug.h
+++ b/src/mesa/drivers/dri/i965/intel_debug.h
@@ -110,6 +110,8 @@ extern uint64_t INTEL_DEBUG;
}\
} while (0)
+extern uint64_t intel_debug_flag_for_shader_stage(gl_shader_stage stage);
+
struct brw_context;
extern void brw_process_intel_debug_variable(struct brw_context *brw);
--
2.2.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/9] i965: Make scheduler cycle estimates use the proper stage name.
Previously, the vec4 backend labeled shaders as vec4 - now it uses the
specific names VS and GS.
The FS backend now correctly prints VS for vertex shaders (rather than
fs). It also prints FS instead of fs for fragment shaders;
preserving that behavior didn't seem essential.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
index 24075bd..56f69ea 100644
--- a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
+++ b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
@@ -1517,9 +1517,9 @@
fs_visitor::schedule_instructions(instruction_scheduler_mode mode)
fs_instruction_scheduler sched(this, grf_count, mode);
sched.run(cfg);
- if (unlikely(INTEL_DEBUG DEBUG_WM) mode == SCHEDULE_POST) {
- fprintf(stderr, fs%d estimated execution time: %d cycles\n,
- dispatch_width, sched.time);
+ if (unlikely(debug_enabled) mode == SCHEDULE_POST) {
+ fprintf(stderr, %s%d estimated execution time: %d cycles\n,
+ stage_abbrev, dispatch_width, sched.time);
}
invalidate_live_intervals();
@@ -1531,8 +1531,9 @@ vec4_visitor::opt_schedule_instructions()
vec4_instruction_scheduler sched(this, prog_data-total_grf);
sched.run(cfg);
- if (unlikely(debug_flag)) {
- fprintf(stderr, vec4 estimated execution time: %d cycles\n,
sched.time);
+ if (unlikely(debug_enabled)) {
+ fprintf(stderr, %s estimated execution time: %d cycles\n,
+ stage_abbrev, sched.time);
}
invalidate_live_intervals();
--
2.2.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/9] i965/fs: Un-hardcode DEBUG_WM, FS, and fragment.
These code paths can (or will) be used for other shader stages.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 4 ++--
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 11 ++-
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index c46e1d7..a562b8a 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -810,11 +810,11 @@ fs_visitor::vfail(const char *format, va_list va)
failed = true;
msg = ralloc_vasprintf(mem_ctx, format, va);
- msg = ralloc_asprintf(mem_ctx, FS compile failed: %s\n, msg);
+ msg = ralloc_asprintf(mem_ctx, %s compile failed: %s\n, stage_abbrev,
msg);
this-fail_msg = msg;
- if (INTEL_DEBUG DEBUG_WM) {
+ if (debug_enabled) {
fprintf(stderr, %s, msg);
}
}
diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index 2123829..90eecae 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
@@ -124,8 +124,8 @@ fs_visitor::emit_nir_code()
nir_copy_prop(nir);
nir_validate_shader(nir);
- if (INTEL_DEBUG DEBUG_WM) {
- fprintf(stderr, NIR (SSA form) for fragment shader:\n);
+ if (unlikely(debug_enabled)) {
+ fprintf(stderr, NIR (SSA form) for %s shader:\n, stage_name);
nir_print_shader(nir, stderr);
}
@@ -135,7 +135,8 @@ fs_visitor::emit_nir_code()
MESA_DEBUG_SOURCE_SHADER_COMPILER,
MESA_DEBUG_TYPE_OTHER,
MESA_DEBUG_SEVERITY_NOTIFICATION,
- FS NIR shader: %d inst\n,
+ %s NIR shader: %d inst\n,
+ stage_abbrev,
count_nir_instrs(nir));
}
@@ -178,8 +179,8 @@ fs_visitor::emit_nir_code()
nir_emit_impl(overload-impl);
}
- if (INTEL_DEBUG DEBUG_WM) {
- fprintf(stderr, NIR (final form) for fragment shader:\n);
+ if (unlikely(debug_enabled)) {
+ fprintf(stderr, NIR (final form) for %s shader:\n, stage_name);
nir_print_shader(nir, stderr);
}
--
2.2.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/10] glsl: A shader cannot redefine or overload built-in functions in GLSL ES 3.00
On Wednesday 18 February 2015 12:00:39 Matt Turner wrote:
On Mon, Dec 1, 2014 at 5:04 AM, Eduardo Lima Mitev el...@igalia.com wrote:
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
Create a new search function to look for matching built-in functions by
name and use it for built-in function redefinition or overload in GLSL ES
3.00.
GLSL ES 3.0 spec, chapter 6.1 Function Definitions, page 71
A shader cannot redefine or overload built-in functions.
In case of GLSL ES 1.0 spec, chapter 6.1 Function Definitions, page 54
Function names can be overloaded. This allows the same function name to
be
used for multiple functions, as long as the argument list types differ. If
functions’ names and argument types match, then their return type and
parameter qualifiers must also match. Function signature matching is based
on parameter type only, no qualifiers are used. Overloading is used
heavily in the built-in functions. When overloaded functions (or indeed
any functions) are resolved, an exact match for the function's signature
is sought. This includes exact match of array size as well. No promotion
or demotion of the return type or input argument types is done. All
expected combination of inputs and outputs must be defined as separate
functions.
So this check is specific to GLSL ES 3.00.
This patch fixes the following dEQP tests:
dEQP-GLES3.functional.shaders.functions.invalid.overload_builtin_function_
vertex
dEQP-GLES3.functional.shaders.functions.invalid.overload_builtin_function
_fragment
dEQP-GLES3.functional.shaders.functions.invalid.redefine_builtin_function
_vertex
dEQP-GLES3.functional.shaders.functions.invalid.redefine_builtin_function
_fragment
No piglit regressions.
Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
---
src/glsl/ast_to_hir.cpp| 22 ++
src/glsl/builtin_functions.cpp | 11 +++
src/glsl/ir.h | 4
3 files changed, 37 insertions(+)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index fe1e129..b7074bc 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4167,6 +4167,28 @@ ast_function::hir(exec_list *instructions,
return NULL;
}
}
+ } else {
+ /* From GLSL ES 3.0 spec, chapter 6.1 Function Definitions,
page 71: + *
+ * A shader cannot redefine or overload built-in functions.
+ *
+ * While in GLSL ES 1.0 spec, chapter 6.1 Function
Definitions, page + * 54, this is allowed:
+ *
+ * Function names can be overloaded. [...] Overloading is used
heavily + * in the built-in functions.
I don't think that quote is really explicitly saying that you can
overload built-in functions. It's just saying that built-in functions
contain many overloads.
It doesn't, however, prohibit the user from adding overloads of their own.
I'd probably replace the spec citation with just a statement that the
GLSL ES 1.0 spec doesn't prohibit overloading built-in functions,
since it really doesn't say anything explicitly about the topic.
+ *
+ */
+ if (state-es_shader state-language_version = 300) {
+/* Local shader has no exact candidates; check the built-ins.
*/ +_mesa_glsl_initialize_builtin_functions();
+if (_mesa_glsl_find_builtin_function_by_name(state, name)) {
+ YYLTYPE loc = this-get_location();
+ _mesa_glsl_error( loc, state,
+A shader cannot redefine or overload
built-in +function `%s' in GLSL ES
3.00, name); +}
+ }
}
}
diff --git a/src/glsl/builtin_functions.cpp
b/src/glsl/builtin_functions.cpp index bb7fbcd..f5052d3 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -4618,6 +4618,17 @@
_mesa_glsl_find_builtin_function(_mesa_glsl_parse_state *state,
return s;
}
+ir_function *
+_mesa_glsl_find_builtin_function_by_name(_mesa_glsl_parse_state *state,
+ const char *name)
+{
+ ir_function * f;
Remove the space after the *.
As far as I can tell, this patch looks correct. Confirmation from Ken
would be nice as well.
(This behavior should have been the default in all versions of GLSL as
far as I'm concerned)
Reviewed-by: Matt Turner matts...@gmail.com
Following Kenneth's comments, I will send an updated version of it for review.
Also, I will modify the GLSL ES 1.0 spec citation following what Kenneth says
in his reply.
Because of these changes, I am not going to add your R-b yet.
Thanks for your review!
Sam
signature.asc
Description: This is a
Re: [Mesa-dev] [PATCH 9/9] i965/vec4: Print VS or GS when compiles fail, not vec4.
Series is Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com On Feb 18, 2015 9:00 PM, Kenneth Graunke kenn...@whitecape.org wrote: This is now trivial to do right. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp index 4f66b62..562fc30 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp @@ -3656,7 +3656,7 @@ vec4_visitor::fail(const char *format, ...) va_start(va, format); msg = ralloc_vasprintf(mem_ctx, format, va); va_end(va); - msg = ralloc_asprintf(mem_ctx, vec4 compile failed: %s\n, msg); + msg = ralloc_asprintf(mem_ctx, %s compile failed: %s\n, stage_abbrev, msg); this-fail_msg = msg; -- 2.2.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89218] lower_instructions.cpp:648:48: error: invalid suffix 'd' on floating constant
https://bugs.freedesktop.org/show_bug.cgi?id=89218 Ilia Mirkin imir...@alum.mit.edu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Ilia Mirkin imir...@alum.mit.edu --- commit e8e22cf65fc8b9b0c0355540985b073a03c69a51 Author: Ilia Mirkin imir...@alum.mit.edu Date: Thu Feb 19 01:44:44 2015 -0500 glsl: remove bogus 'd' constant qualifiers 0.0 is a double anyways. Apparently my version of gcc was happy with 0.0d as well, but this is not true of all compilers. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89218 Signed-off-by: Ilia Mirkin imir...@alum.mit.edu -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89203] Mesa 10.4.3 and up causes stuttering and frame drops in a particular game
https://bugs.freedesktop.org/show_bug.cgi?id=89203 Bug ID: 89203 Summary: Mesa 10.4.3 and up causes stuttering and frame drops in a particular game Product: Mesa Version: 10.4 Hardware: Other OS: All Status: NEW Severity: minor Priority: medium Component: GLX Assignee: mesa-dev@lists.freedesktop.org Reporter: andre35...@yahoo.com QA Contact: mesa-dev@lists.freedesktop.org Created attachment 113614 -- https://bugs.freedesktop.org/attachment.cgi?id=113614action=edit Xorg.0.log I hope I selected the right component for this bug report as I am unsure. Essentially, ever since upgrading past Mesa 10.3 to 10.4.3 or 10.4.4 I get constant stuttering and frame drops in a proprietary game called Minecraft (runs on java 7). The stuttering and frame drops occur whenever I move my character around and new chunks start to load. So that seems to be the issue, low frame rates when things are loading. This constant stuttering and frame drops did not occur when on 10.3. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89203] Mesa 10.4.3 and up causes stuttering and frame drops in a particular game
https://bugs.freedesktop.org/show_bug.cgi?id=89203 Alex Deucher alexdeuc...@gmail.com changed: What|Removed |Added Component|GLX |Drivers/Gallium/radeonsi Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org --- Comment #2 from Alex Deucher alexdeuc...@gmail.com --- Can you bisect? -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ra: Disable round-robin strategy for optimistically colorable nodes.
Connor Abbott cwabbo...@gmail.com writes:
On Tue, Feb 17, 2015 at 3:04 PM, Francisco Jerez curroje...@riseup.net
wrote:
Jason Ekstrand ja...@jlekstrand.net writes:
On Mon, Feb 16, 2015 at 11:39 AM, Francisco Jerez curroje...@riseup.net
wrote:
The round-robin allocation strategy is expected to decrease the amount
of false dependencies created by the register allocator and give the
post-RA scheduling pass more freedom to move instructions around. On
the other hand it has the disadvantage of increasing fragmentation and
decreasing the number of equally-colored nearby nodes, what increases
the likelihood of failure in presence of optimistically colorable
nodes.
This patch disables the round-robin strategy for optimistically
colorable nodes. These typically arise in situations of high register
pressure or for registers with large live intervals, in both cases the
task of the instruction scheduler shouldn't be constrained excessively
by the dense packing of those nodes, and a spill (or on Intel hardware
a fall-back to SIMD8 mode) is invariably worse than a slightly less
optimal scheduling.
Shader-db results on the i965 driver:
total instructions in shared programs: 5488539 - 5488489 (-0.00%)
instructions in affected programs: 1121 - 1071 (-4.46%)
helped:1
HURT: 0
GAINED:49
LOST: 5
---
src/util/register_allocate.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/src/util/register_allocate.c b/src/util/register_allocate.c
index af7a20c..d63d8eb 100644
--- a/src/util/register_allocate.c
+++ b/src/util/register_allocate.c
@@ -168,6 +168,12 @@ struct ra_graph {
unsigned int *stack;
unsigned int stack_count;
+
+ /**
+* Tracks the start of the set of optimistically-colored registers in
the
+* stack.
+*/
+ unsigned int stack_optimistic_start;
};
/**
@@ -454,6 +460,7 @@ static void
ra_simplify(struct ra_graph *g)
{
bool progress = true;
+ unsigned int stack_optimistic_start = ~0;
UINT_MAX would be clearer than ~0
Sure, either works as identity for MIN2. Do you want me to send a v3
for this or should I fix it locally and add your R-b?
int i;
while (progress) {
@@ -483,12 +490,16 @@ ra_simplify(struct ra_graph *g)
if (!progress best_optimistic_node != ~0U) {
I guess we're using ~0 other places... oh well...
decrement_q(g, best_optimistic_node);
+ stack_optimistic_start =
+MIN2(stack_optimistic_start, g-stack_count);
It might be clearer to explicitly use an if here instead of the MIN2
because what this really means is if (stack_optimistic_start == ~0)
stack_optimistic_start = g-stack_count;
What I really meant to calculate here is the minimum of the indices of
all optimistic nodes inserted into the stack. What you say works too
because we happen to be growing the stack monotonically. How can using
MIN2 possibly obscure the meaning of taking the minimum?
Because you're finding stack_optimistic_*start*, i.e. the *first*
thing on the stack that's optimistic. It's a pretty common idiom in C,
when you're going through a bunch of stuff and you want to record the
first thing that satisfies some property, to do:
result = some_default_value (NULL, UINT_MAX, etc.)
for_each_thing {
...
if (has_the_property(thing) result == some_default_value) {
result = thing;
}
}
so if you do what Jason suggested, people will see the pattern and go
ah, it's recording the first thing we pushed optimistically, that
makes sense as opposed to thinking about what the minimum is doing;
it's not obvious at first that after the first MIN2
stack_optimistic_start is never going to change.
Yeah, I completely agree with your argumentation, actually it's funny
that this was precisely the reason that led me to intentionally write
MIN2() rather than your open-coded equivalent. I consider the way how
something is going to change or not along your incidental control flow a
distraction from its formal definition. But I'm not going spend a
single second more of my time in this discussion because it is a matter
of personal taste and there's no objectively better or worse choice,
there's no point in being categorical here. If you insist in stressing
the how over the what and cannot tolerate somebody else's personal
inclination I'm just going to do as you say because this has long
crossed the line of bike-shedding.
Did you actually intend to review this patch? And if so do you want a
resend with the trivial codestyle changes?
Other than that (and connor's comment), it looks fine to me.
--Jason
g-stack[g-stack_count] = best_optimistic_node;
g-stack_count++;
g-nodes[best_optimistic_node].in_stack = true;
progress = true;
}
[Mesa-dev] [Bug 89203] Mesa 10.4.3 and up causes stuttering and frame drops in a particular game
https://bugs.freedesktop.org/show_bug.cgi?id=89203 --- Comment #1 from andre35...@yahoo.com --- Created attachment 113615 -- https://bugs.freedesktop.org/attachment.cgi?id=113615action=edit dmesg -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 07/23] main: Add entry point for NamedBufferData.
On 12/02/15 04:05, Laura Ekstrand wrote:
v2: review from Ian Romanick
- Fix space in ARB_direct_state_access.xml.
- Remove _mesa from the name of buffer_data static fallback.
- Restore VBO_DEBUG and BOUNDS_CHECK.
- Fix beginning of comment to start on same line as /*
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 7 +++
src/mesa/main/bufferobj.c | 67 ++
src/mesa/main/bufferobj.h | 13 -
src/mesa/main/tests/dispatch_sanity.cpp| 1 +
4 files changed, 67 insertions(+), 21 deletions(-)
diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index ff81c21..7779262 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -21,6 +21,13 @@
param name=flags type=GLbitfield /
/function
+ function name=NamedBufferData offset=assign
+ param name=buffer type=GLuint /
+ param name=size type=GLsizeiptr /
+ param name=data type=const GLvoid * /
+ param name=usage type=GLenum /
+ /function
+
!-- Texture object functions --
function name=CreateTextures offset=assign
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 6259db1..ac8eed1 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -556,9 +556,9 @@ _mesa_total_buffer_object_memory(struct gl_context *ctx)
* \sa glBufferDataARB, dd_function_table::BufferData.
*/
static GLboolean
-_mesa_buffer_data( struct gl_context *ctx, GLenum target, GLsizeiptrARB size,
- const GLvoid * data, GLenum usage, GLenum storageFlags,
- struct gl_buffer_object * bufObj )
+buffer_data_fallback(struct gl_context *ctx, GLenum target, GLsizeiptr size,
+ const GLvoid *data, GLenum usage, GLenum storageFlags,
+ struct gl_buffer_object *bufObj)
{
void * new_data;
@@ -1112,7 +1112,7 @@ _mesa_init_buffer_object_functions(struct dd_function_table *driver)
/* GL_ARB_vertex/pixel_buffer_object */
driver-NewBufferObject = _mesa_new_buffer_object;
driver-DeleteBuffer = _mesa_delete_buffer_object;
- driver-BufferData = _mesa_buffer_data;
+ driver-BufferData = buffer_data_fallback;
driver-BufferSubData = _mesa_buffer_subdata;
driver-GetBufferSubData = _mesa_buffer_get_subdata;
driver-UnmapBuffer = _mesa_buffer_unmap;
@@ -1474,23 +1474,22 @@ _mesa_NamedBufferStorage(GLuint buffer, GLsizeiptr
size, const GLvoid *data,
}
-
-void GLAPIENTRY
-_mesa_BufferData(GLenum target, GLsizeiptrARB size,
-const GLvoid * data, GLenum usage)
+void
+_mesa_buffer_data(struct gl_context *ctx, struct gl_buffer_object *bufObj,
+ GLenum target, GLsizeiptr size, const GLvoid *data,
+ GLenum usage, const char *func)
{
- GET_CURRENT_CONTEXT(ctx);
- struct gl_buffer_object *bufObj;
bool valid_usage;
if (MESA_VERBOSE VERBOSE_API)
- _mesa_debug(ctx, glBufferData(%s, %ld, %p, %s)\n,
+ _mesa_debug(ctx, %s(%s, %ld, %p, %s)\n,
Func could be on this line but I really don't care.
+ func,
_mesa_lookup_enum_by_nr(target),
(long int) size, data,
_mesa_lookup_enum_by_nr(usage));
if (size 0) {
- _mesa_error(ctx, GL_INVALID_VALUE, glBufferDataARB(size 0));
+ _mesa_error(ctx, GL_INVALID_VALUE, %s(size 0), func);
return;
}
@@ -1519,16 +1518,13 @@ _mesa_BufferData(GLenum target, GLsizeiptrARB size,
}
if (!valid_usage) {
- _mesa_error(ctx, GL_INVALID_ENUM, glBufferData(usage));
+ _mesa_error(ctx, GL_INVALID_ENUM, %s(invalid usage: %s), func,
+ _mesa_lookup_enum_by_nr(usage));
return;
}
- bufObj = get_buffer(ctx, glBufferDataARB, target, GL_INVALID_OPERATION);
- if (!bufObj)
- return;
-
if (bufObj-Immutable) {
- _mesa_error(ctx, GL_INVALID_OPERATION, glBufferData(immutable));
+ _mesa_error(ctx, GL_INVALID_OPERATION, %s(immutable), func);
return;
}
@@ -1554,10 +1550,43 @@ _mesa_BufferData(GLenum target, GLsizeiptrARB size,
GL_MAP_WRITE_BIT |
GL_DYNAMIC_STORAGE_BIT,
bufObj)) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, glBufferDataARB());
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, %s, func);
}
}
+void GLAPIENTRY
+_mesa_BufferData(GLenum target, GLsizeiptr size,
+ const GLvoid *data, GLenum usage)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ struct gl_buffer_object *bufObj;
+
+ bufObj = get_buffer(ctx, glBufferData, target, GL_INVALID_OPERATION);
+ if (!bufObj)
+ return;
+
+ _mesa_buffer_data(ctx, bufObj, target, size, data, usage,
+ glBufferData);
+}
+
+void
Re: [Mesa-dev] [PATCH] i965/simd8vs: Fix SIMD8 atomics (read-only)
Jordan Justen jordan.l.jus...@intel.com writes:
An *untested* update for d9cd982d556be560af3bcbcdaf62b6b93eb934a5.
A similar change was needed for CS to allow the piglit test
tests/spec/arb_compute_shader/execution/simple-barrier-atomics.shader_test
to pass.
I think the previous change will fix cases that write atomics, such as
atomicCounterIncrement, and this change will fix cases than only read
atomics, such as atomicCounter.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Cc: Ben Widawsky b...@bwidawsk.net
Cc: Francisco Jerez curroje...@riseup.net
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index c7f321f..951c0ba 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -3042,9 +3042,6 @@ void
fs_visitor::emit_untyped_surface_read(unsigned surf_index, fs_reg dst,
fs_reg offset)
{
- bool uses_kill =
- (stage == MESA_SHADER_FRAGMENT)
- ((brw_wm_prog_data*) this-prog_data)-uses_kill;
int reg_width = dispatch_width / 8;
fs_reg *sources = ralloc_array(mem_ctx, fs_reg, 2);
@@ -3054,13 +3051,24 @@ fs_visitor::emit_untyped_surface_read(unsigned
surf_index, fs_reg dst,
emit(MOV(sources[0], fs_reg(0u)))
-force_writemask_all = true;
- if (uses_kill) {
- emit(MOV(component(sources[0], 7), brw_flag_reg(0, 1)))
- -force_writemask_all = true;
+ if (stage == MESA_SHADER_FRAGMENT) {
+ if (((brw_wm_prog_data*)this-prog_data)-uses_kill) {
+ emit(MOV(component(sources[0], 7), brw_flag_reg(0, 1)))
+-force_writemask_all = true;
+ } else {
+ emit(MOV(component(sources[0], 7),
+ retype(brw_vec1_grf(1, 7), BRW_REGISTER_TYPE_UD)))
+-force_writemask_all = true;
+ }
} else {
+ /* The execution mask is part of the side-band information sent
together with
+ * the message payload to the data port. It's implicitly ANDed with
the sample
+ * mask sent in the header to compute the actual set of channels that
execute
+ * the atomic operation.
+ */
+ assert(stage == MESA_SHADER_VERTEX);
emit(MOV(component(sources[0], 7),
- retype(brw_vec1_grf(1, 7), BRW_REGISTER_TYPE_UD)))
- -force_writemask_all = true;
+ brw_imm_ud(0xff)))-force_writemask_all = true;
}
/* Set the surface read offset. */
--
2.1.4
Looks OK to me,
Reviewed-by: Francisco Jerez curroje...@riseup.net
pgp7tIjTdNFwd.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/23] main: Add entry point for CreateBuffers.
looks good to me.
Reviewed-by: Martin Peres martin.pe...@linux.intel.com
On 12/02/15 04:05, Laura Ekstrand wrote:
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 7 +++
src/mesa/main/bufferobj.c | 65 --
src/mesa/main/bufferobj.h | 5 +-
src/mesa/main/tests/dispatch_sanity.cpp| 1 +
4 files changed, 64 insertions(+), 14 deletions(-)
diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index 86c00f9..6c9d0e8 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -7,6 +7,13 @@
enum name=QUERY_TARGETvalue=0x82EA/
enum name=TEXTURE_BINDING value=0x82EB/
+ !-- Buffer object functions --
+
+ function name=CreateBuffers offset=assign
+ param name=n type=GLsizei /
+ param name=buffers type=GLuint * /
+ /function
+
!-- Texture object functions --
function name=CreateTextures offset=assign
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index b7dce0e..785f0ff 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -1283,27 +1283,29 @@ _mesa_DeleteBuffers(GLsizei n, const GLuint *ids)
/**
- * Generate a set of unique buffer object IDs and store them in \c buffer.
- *
- * \param n Number of IDs to generate.
- * \param buffer Array of \c n locations to store the IDs.
+ * This is the implementation for glGenBuffers and glCreateBuffers. It is not
+ * exposed to the rest of Mesa to encourage the use of nameless buffers in
+ * driver internals.
*/
-void GLAPIENTRY
-_mesa_GenBuffers(GLsizei n, GLuint *buffer)
+static void
+create_buffers(GLsizei n, GLuint *buffers, bool dsa)
{
GET_CURRENT_CONTEXT(ctx);
GLuint first;
GLint i;
+ struct gl_buffer_object *buf;
+
+ const char *func = dsa ? glCreateBuffers : glGenBuffers;
if (MESA_VERBOSE VERBOSE_API)
- _mesa_debug(ctx, glGenBuffers(%d)\n, n);
+ _mesa_debug(ctx, %s(%d)\n, func, n);
if (n 0) {
- _mesa_error(ctx, GL_INVALID_VALUE, glGenBuffersARB);
+ _mesa_error(ctx, GL_INVALID_VALUE, %s(n %d 0), func, n);
return;
}
- if (!buffer) {
+ if (!buffers) {
return;
}
@@ -1314,16 +1316,53 @@ _mesa_GenBuffers(GLsizei n, GLuint *buffer)
first = _mesa_HashFindFreeKeyBlock(ctx-Shared-BufferObjects, n);
- /* Insert the ID and pointer to dummy buffer object into hash table */
+ /* Insert the ID and pointer into the hash table. If non-DSA, insert a
+* DummyBufferObject. Otherwise, create a new buffer object and insert
+* it.
+*/
for (i = 0; i n; i++) {
- _mesa_HashInsert(ctx-Shared-BufferObjects, first + i,
- DummyBufferObject);
- buffer[i] = first + i;
+ buffers[i] = first + i;
+ if (dsa) {
+ ASSERT(ctx-Driver.NewBufferObject);
+ buf = ctx-Driver.NewBufferObject(ctx, buffers[i]);
+ if (!buf) {
+_mesa_error(ctx, GL_OUT_OF_MEMORY, %s, func);
+return;
+ }
+ }
+ else
+ buf = DummyBufferObject;
+
+ _mesa_HashInsert(ctx-Shared-BufferObjects, buffers[i], buf);
}
mtx_unlock(ctx-Shared-Mutex);
}
+/**
+ * Generate a set of unique buffer object IDs and store them in \c buffers.
+ *
+ * \param nNumber of IDs to generate.
+ * \param buffers Array of \c n locations to store the IDs.
+ */
+void GLAPIENTRY
+_mesa_GenBuffers(GLsizei n, GLuint *buffers)
+{
+ create_buffers(n, buffers, false);
+}
+
+/**
+ * Create a set of buffer objects and store their unique IDs in \c buffers.
+ *
+ * \param nNumber of IDs to generate.
+ * \param buffers Array of \c n locations to store the IDs.
+ */
+void GLAPIENTRY
+_mesa_CreateBuffers(GLsizei n, GLuint *buffers)
+{
+ create_buffers(n, buffers, true);
+}
+
/**
* Determine if ID is the name of a buffer object.
diff --git a/src/mesa/main/bufferobj.h b/src/mesa/main/bufferobj.h
index 8e53bfd..48d253b 100644
--- a/src/mesa/main/bufferobj.h
+++ b/src/mesa/main/bufferobj.h
@@ -150,7 +150,10 @@ void GLAPIENTRY
_mesa_DeleteBuffers(GLsizei n, const GLuint * buffer);
void GLAPIENTRY
-_mesa_GenBuffers(GLsizei n, GLuint * buffer);
+_mesa_GenBuffers(GLsizei n, GLuint *buffers);
+
+void GLAPIENTRY
+_mesa_CreateBuffers(GLsizei n, GLuint *buffers);
GLboolean GLAPIENTRY
_mesa_IsBuffer(GLuint buffer);
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index b78c1ce..aa33702 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -955,6 +955,7 @@ const struct function gl_core_functions_possible[] = {
{ glClipControl, 45, -1 },
/* GL_ARB_direct_state_access */
+ { glCreateBuffers, 45, -1 },
{ glCreateTextures, 45, -1 },
{ glTextureStorage1D, 45, -1 },
Re: [Mesa-dev] [Piglit] DSA for core profile only? (was Re: [PATCH 2/2] arb_direct_state_access: New test for GetCompressedTextureImage.)
On 18 February 2015 at 00:46, Ilia Mirkin imir...@alum.mit.edu wrote: Wine maybe? (They're compat-only for now, although some work is being done to support core, but that might only be for their D3D10+ layer.) The current plan for Wine is just to add support for core profiles. There may be a case for hardware that can't do core profiles, but I somewhat doubt that any performance difference from DSA will be large enough to justify the effort. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/23] main: Add entry point for NamedBufferStorage.
On 12/02/15 04:05, Laura Ekstrand wrote:
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 7 +++
src/mesa/main/bufferobj.c | 63 +++---
src/mesa/main/bufferobj.h | 9
src/mesa/main/tests/dispatch_sanity.cpp| 1 +
4 files changed, 64 insertions(+), 16 deletions(-)
diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index 6c9d0e8..ff81c21 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -14,6 +14,13 @@
param name=buffers type=GLuint * /
/function
+ function name=NamedBufferStorage offset=assign
+ param name=buffer type=GLuint /
+ param name=size type=GLsizeiptr /
+ param name=data type=const GLvoid * /
+ param name=flags type=GLbitfield /
Isn't this supposed to be an enum? Here is the prototype found in core 4.5:
void NamedBufferData( uint buffer, sizeiptr size, const void *data, enum
usage );
Other than that, this looks good to me.
Reviewed-by: Martin Peres martin.pe...@linux.intel.com
+ /function
+
!-- Texture object functions --
function name=CreateTextures offset=assign
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 785f0ff..6259db1 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -1386,15 +1386,13 @@ _mesa_IsBuffer(GLuint id)
}
-void GLAPIENTRY
-_mesa_BufferStorage(GLenum target, GLsizeiptr size, const GLvoid *data,
-GLbitfield flags)
+void
+_mesa_buffer_storage(struct gl_context *ctx, struct gl_buffer_object *bufObj,
+ GLenum target, GLsizeiptr size, const GLvoid *data,
+ GLbitfield flags, const char *func)
{
- GET_CURRENT_CONTEXT(ctx);
- struct gl_buffer_object *bufObj;
-
if (size = 0) {
- _mesa_error(ctx, GL_INVALID_VALUE, glBufferStorage(size = 0));
+ _mesa_error(ctx, GL_INVALID_VALUE, %s(size = 0), func);
return;
}
@@ -1404,27 +1402,25 @@ _mesa_BufferStorage(GLenum target, GLsizeiptr size, const GLvoid *data,
GL_MAP_COHERENT_BIT |
GL_DYNAMIC_STORAGE_BIT |
GL_CLIENT_STORAGE_BIT)) {
- _mesa_error(ctx, GL_INVALID_VALUE, glBufferStorage(flags));
+ _mesa_error(ctx, GL_INVALID_VALUE, %s(invalid flag bits set), func);
return;
}
if (flags GL_MAP_PERSISTENT_BIT
!(flags (GL_MAP_READ_BIT | GL_MAP_WRITE_BIT))) {
- _mesa_error(ctx, GL_INVALID_VALUE, glBufferStorage(flags!=READ/WRITE));
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ %s(PERSISTENT and flags!=READ/WRITE), func);
return;
}
if (flags GL_MAP_COHERENT_BIT !(flags GL_MAP_PERSISTENT_BIT)) {
- _mesa_error(ctx, GL_INVALID_VALUE, glBufferStorage(flags!=PERSISTENT));
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ %s(COHERENT and flags!=PERSISTENT), func);
return;
}
- bufObj = get_buffer(ctx, glBufferStorage, target, GL_INVALID_OPERATION);
- if (!bufObj)
- return;
-
if (bufObj-Immutable) {
- _mesa_error(ctx, GL_INVALID_OPERATION, glBufferStorage(immutable));
+ _mesa_error(ctx, GL_INVALID_OPERATION, %s(immutable), func);
return;
}
@@ -1439,10 +1435,45 @@ _mesa_BufferStorage(GLenum target, GLsizeiptr size, const GLvoid *data,
ASSERT(ctx-Driver.BufferData);
if (!ctx-Driver.BufferData(ctx, target, size, data, GL_DYNAMIC_DRAW,
flags, bufObj)) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, glBufferStorage());
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, %s(), func);
}
}
+void GLAPIENTRY
+_mesa_BufferStorage(GLenum target, GLsizeiptr size, const GLvoid *data,
+GLbitfield flags)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ struct gl_buffer_object *bufObj;
+
+ bufObj = get_buffer(ctx, glBufferStorage, target, GL_INVALID_OPERATION);
+ if (!bufObj)
+ return;
+
+ _mesa_buffer_storage(ctx, bufObj, target, size, data, flags,
+glBufferStorage);
+}
+
+void GLAPIENTRY
+_mesa_NamedBufferStorage(GLuint buffer, GLsizeiptr size, const GLvoid *data,
+ GLbitfield flags)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ struct gl_buffer_object *bufObj;
+
+ bufObj = _mesa_lookup_bufferobj_err(ctx, buffer, glNamedBufferStorage);
+ if (!bufObj)
+ return;
+
+ /*
+* In direct state access, buffer objects have an unspecified target since
+* they are not required to be bound.
+*/
+ _mesa_buffer_storage(ctx, bufObj, GL_NONE, size, data, flags,
+glNamedBufferStorage);
+}
+
+
void GLAPIENTRY
_mesa_BufferData(GLenum target, GLsizeiptrARB size,
diff --git a/src/mesa/main/bufferobj.h b/src/mesa/main/bufferobj.h
index 48d253b..3c337aa 100644
--- a/src/mesa/main/bufferobj.h
+++
[Mesa-dev] New stable-branch 10.4 candidate pushed
Hello list,
A candidate for the Mesa 10.4.5 release is now available. The current
patch queue is as follows:
- 17 queued
- 7 nominated (outstanding)
- and 0 rejected (obsolete) patches
In a nut shell this gives us Darwin build fixes and a few driver specific
patches - nouveau (nvc0), radeonsi and i965.
Take a look at section Mesa stable queue for more information.
Testing
---
The following results are against piglit a68d27e7254.
Changes - classic i965(snb)
---
None.
Changes - swrast classic
Fixes
- NV_fragment_program_option/fp-condition_codes-01 - fail pass
Changes - gallium softpipe
-
Fixes
- ARB_fragment_program/fp-long-alu - crash pass
Regressions
- OpenGL 1.4/triangle-rasterization-overdraw - pass fail
Changes - gallium llvmpipe
-
None.
Testing reports/general approval
Any testing reports (or general approval of the state of the branch)
will be greatly appreciated.
Trivial merge conflicts
---
Here are the commits where I manually merged conflicts, (so these might
merit additional review):
commit 53041aecef1bf41ca5f0eeab0d1504f24d7b1c81
Author: Marek Olšák marek.ol...@amd.com
radeonsi: small fix in SPI state
(cherry picked from commit a27b74819ad375e8c0bc88e13f42c951d2b5cd6a)
The plan is to have 10.4.5 this Friday(18th February).
If you have any questions or comments that you would like to share
before the release, please go ahead.
Cheers,
Emil
Mesa stable queue
-
Nominated (7)
=
Andreas Boll (2):
mesa: Redefine GLX_CONTEXT_{CORE|COMPATIBILITY}_PROFILE_BIT_ARB
dri/common: Fix returned value of __DRI2_RENDERER_PREFERRED_PROFILE
Brian Paul (3):
configure: don't try to build gallium DRI drivers if --disable-dri is set
swrast: fix multiple color buffer writing
st/mesa: fix sampler view reference counting bug in glDraw/CopyPixels
Mario Kleiner (1):
glx: Handle out-of-sequence swap completion events correctly.
Marius Predut (1):
Fixing an x86 FPU bug.
Queued (17)
===
Carl Worth (1):
Revert use of Mesa IR optimizer for ARB_fragment_programs
Ilia Mirkin (3):
nvc0: bail out of 2d blits with non-A8_UNORM alpha formats
st/mesa: treat resource-less xfb buffers as if they weren't there
nvc0: allow holes in xfb target lists
Jeremy Huddleston Sequoia (2):
darwin: build fix
darwin: build fix
Kenneth Graunke (4):
i965: Override swizzles for integer luminance formats.
i965: Use a gl_color_union for sampler border color.
i965: Fix integer border color on Haswell.
glsl: Reduce memory consumption of copy propagation passes.
Laura Ekstrand (1):
main: Fixed _mesa_GetCompressedTexImage_sw to copy slices correctly.
Marek Olšák (5):
r600g,radeonsi: don't append to streamout buffers that haven't been used
yet
radeonsi: fix instanced arrays with non-zero start instance
radeonsi: small fix in SPI state
mesa: fix AtomicBuffer typo in _mesa_DeleteBuffers
radeonsi: fix a crash if a stencil ref state is set before a DSA state
Michel Dänzer (2):
st/mesa: Don't use PIPE_USAGE_STREAM for GL_PIXEL_UNPACK_BUFFER_ARB
Revert radeon/llvm: enable unsafe math for graphics shaders
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/10] glsl: A shader cannot redefine or overload built-in functions in GLSL ES 3.00
On Wednesday, February 18, 2015 12:00:39 PM Matt Turner wrote:
On Mon, Dec 1, 2014 at 5:04 AM, Eduardo Lima Mitev el...@igalia.com wrote:
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
Create a new search function to look for matching built-in functions by name
and use it for built-in function redefinition or overload in GLSL ES 3.00.
GLSL ES 3.0 spec, chapter 6.1 Function Definitions, page 71
A shader cannot redefine or overload built-in functions.
In case of GLSL ES 1.0 spec, chapter 6.1 Function Definitions, page 54
Function names can be overloaded. This allows the same function name to be
used for multiple functions, as long as the argument list types differ. If
functions’ names and argument types match, then their return type and
parameter qualifiers must also match. Function signature matching is based
on
parameter type only, no qualifiers are used. Overloading is used heavily in
the
built-in functions. When overloaded functions (or indeed any functions) are
resolved, an exact match for the function's signature is sought. This
includes
exact match of array size as well. No promotion or demotion of the return
type
or input argument types is done. All expected combination of inputs and
outputs must be defined as separate functions.
So this check is specific to GLSL ES 3.00.
This patch fixes the following dEQP tests:
dEQP-GLES3.functional.shaders.functions.invalid.overload_builtin_function_vertex
dEQP-GLES3.functional.shaders.functions.invalid.overload_builtin_function_fragment
dEQP-GLES3.functional.shaders.functions.invalid.redefine_builtin_function_vertex
dEQP-GLES3.functional.shaders.functions.invalid.redefine_builtin_function_fragment
No piglit regressions.
Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
---
src/glsl/ast_to_hir.cpp| 22 ++
src/glsl/builtin_functions.cpp | 11 +++
src/glsl/ir.h | 4
3 files changed, 37 insertions(+)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index fe1e129..b7074bc 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4167,6 +4167,28 @@ ast_function::hir(exec_list *instructions,
return NULL;
}
}
+ } else {
+ /* From GLSL ES 3.0 spec, chapter 6.1 Function Definitions,
page 71:
+ *
+ * A shader cannot redefine or overload built-in functions.
+ *
+ * While in GLSL ES 1.0 spec, chapter 6.1 Function Definitions,
page
+ * 54, this is allowed:
+ *
+ * Function names can be overloaded. [...] Overloading is used
heavily
+ * in the built-in functions.
I don't think that quote is really explicitly saying that you can
overload built-in functions. It's just saying that built-in functions
contain many overloads.
It doesn't, however, prohibit the user from adding overloads of their own.
I'd probably replace the spec citation with just a statement that the
GLSL ES 1.0 spec doesn't prohibit overloading built-in functions,
since it really doesn't say anything explicitly about the topic.
The GLSL ES 1.0 specification actually very explicitly allows
overloading of built-in functions:
From the GLSL ES 1.0 specification, section 4.2.6:
User defined functions may overload built-in functions.
and chapter 8:
User code can overload the built-in functions but cannot redefine
them.
This is indeed different than GLSL ES 3.00, which prohibits both,
and different than desktop GLSL, which has entirely different rules.
+ *
+ */
+ if (state-es_shader state-language_version = 300) {
+/* Local shader has no exact candidates; check the built-ins.
*/
+_mesa_glsl_initialize_builtin_functions();
+if (_mesa_glsl_find_builtin_function_by_name(state, name)) {
+ YYLTYPE loc = this-get_location();
+ _mesa_glsl_error( loc, state,
+A shader cannot redefine or overload
built-in
+function `%s' in GLSL ES 3.00, name);
+}
+ }
This code looks good, but there's one subtle issue with where you've
placed it. Namely, it allows this to compile:
#version 300 es
precision highp float;
out vec4 color;
void main()
{
color = vec4(sin(0.5));
}
float sin(float x);
When handling that prototype, it will take the existing
exact_matching_signature != NULL path (since your code is the else to
that block), which sees it as a harmless redundant prototype, and allows
it.
I would advise simply moving this code out a level and up:
if (state-es_shader state-language_version = 300) {
/* Do your code here */
return NULL;
}
if (state-es_shader || f-has_user_signature()) {
/* Do the old code here */
}
Please submit an updated
[Mesa-dev] [Bug 89199] u_math.h:591:4: error: implicit declaration of function 'ffsll'
https://bugs.freedesktop.org/show_bug.cgi?id=89199 Vinson Lee v...@freedesktop.org changed: What|Removed |Added Keywords||bisected CC||bri...@vmware.com, ||glenn.kenn...@gmail.com, ||mar...@gmail.com --- Comment #1 from Vinson Lee v...@freedesktop.org --- Introduced in 10.5.0-devel by this commit. 50433ea526942dbeac75cc415becadea157e5d33 is the first bad commit commit 50433ea526942dbeac75cc415becadea157e5d33 Author: Marek Olšák marek.ol...@amd.com Date: Sat Jan 31 17:15:16 2015 +0100 gallium/util: add u_bit_scan64 Same as u_bit_scan, but for uint64_t. Reviewed-by: Glenn Kennard glenn.kenn...@gmail.com Reviewed-by: Brian Paul bri...@vmware.com :04 04 4eb1909ac455e690d7de4dbea87cb21b8678ed4b a1d1419d9af472fc2b366764bf8b2a772d11849d M src bisect run success -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965/skl: Layout a 1D miptree horizontally
On Wed, Feb 18, 2015 at 6:02 PM, Ian Romanick i...@freedesktop.org wrote:
On 02/17/2015 06:03 AM, Neil Roberts wrote:
+ /* When this layout is used the horizontal alignment is fixed at 64 and
the
+* hardware ignores the value given in the surface state
+*/
+ const unsigned int align_w = 64;
+
+ mt-total_height = mt-physical_height0;
+
+ if (mt-compressed) {
+ mt-total_height = ALIGN(mt-physical_height0, mt-align_h);
+ }
There aren't any compressed formats that support 1D textures, so I don't
think this can occur. Does the bspec say anything about compressed 1D
textures?
This might not be valid for this hardware generation, but ASTC
supports compressed 1D textures...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v7] nir: Add an ALU op builder kind of like ir_builder.h
v2: Rebase on the nir_opcodes.h python code generation support.
v3: Use SSA values, and set an appropriate writemask on dot products.
v4: Make the arguments be SSA references as well. This lets you stack up
expressions in the arguments of other expressions, at the cost of
having to insert a fmov/imov if you want to swizzle. Also, add
the generated file to NIR_GENERATED_FILES.
v5: Use more pythonish style for iterating the list.
v6: Infer the size of the dest from the size of the srcs, and auto-swizzle
a single small src out to the appropriate size.
v7: Add little helpers for initializing the struct, add a typedef for the
struct like other nir types have.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org (v6)
---
src/glsl/Makefile.am | 5 ++
src/glsl/Makefile.sources | 1 +
src/glsl/nir/.gitignore | 1 +
src/glsl/nir/nir_builder.h| 130 ++
src/glsl/nir/nir_builder_opcodes_h.py | 38 ++
5 files changed, 175 insertions(+)
create mode 100644 src/glsl/nir/nir_builder.h
create mode 100644 src/glsl/nir/nir_builder_opcodes_h.py
diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
index 1e4d98f..5d5cacc 100644
--- a/src/glsl/Makefile.am
+++ b/src/glsl/Makefile.am
@@ -216,6 +216,7 @@ BUILT_SOURCES =
\
glsl_lexer.cpp \
glcpp/glcpp-parse.c \
glcpp/glcpp-lex.c \
+ nir/nir_builder_opcodes.h \
nir/nir_constant_expressions.c \
nir/nir_opcodes.c \
nir/nir_opcodes.h \
@@ -232,6 +233,10 @@ dist-hook:
$(RM) glcpp/tests/*.out
$(RM) glcpp/tests/subtest*/*.out
+nir/nir_builder_opcodes.h: nir/nir_opcodes.py nir/nir_builder_opcodes_h.py
+ $(MKDIR_P) nir; \
+ $(PYTHON2) $(PYTHON_FLAGS) $(srcdir)/nir/nir_builder_opcodes_h.py $@
+
nir/nir_constant_expressions.c: nir/nir_opcodes.py
nir/nir_constant_expressions.py nir/nir_constant_expressions.h
$(MKDIR_P) nir; \
$(PYTHON2) $(PYTHON_FLAGS) $(srcdir)/nir/nir_constant_expressions.py
$@
diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
index 7e66e91..3157d9a 100644
--- a/src/glsl/Makefile.sources
+++ b/src/glsl/Makefile.sources
@@ -11,6 +11,7 @@ LIBGLCPP_GENERATED_FILES = \
glcpp/glcpp-parse.c
NIR_GENERATED_FILES = \
+ nir/nir_builder_opcodes.h \
nir/nir_constant_expressions.c \
nir/nir_opcodes.c \
nir/nir_opcodes.h \
diff --git a/src/glsl/nir/.gitignore b/src/glsl/nir/.gitignore
index 261f64f..64828eb 100644
--- a/src/glsl/nir/.gitignore
+++ b/src/glsl/nir/.gitignore
@@ -1,3 +1,4 @@
+nir_builder_opcodes.h
nir_opt_algebraic.c
nir_opcodes.c
nir_opcodes.h
diff --git a/src/glsl/nir/nir_builder.h b/src/glsl/nir/nir_builder.h
new file mode 100644
index 000..7c4f7fd
--- /dev/null
+++ b/src/glsl/nir/nir_builder.h
@@ -0,0 +1,130 @@
+/*
+ * Copyright © 2014-2015 Broadcom
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef NIR_BUILDER_H
+#define NIR_BUILDER_H
+
+struct exec_list;
+
+typedef struct nir_builder {
+ struct exec_list *cf_node_list;
+ nir_shader *shader;
+ nir_function_impl *impl;
+} nir_builder;
+
+static inline void
+nir_builder_init(nir_builder *build, nir_function_impl *impl)
+{
+ memset(build, 0, sizeof(*build));
+ build-impl = impl;
+ build-shader = impl-overload-function-shader;
+}
+
+static inline void
+nir_builder_insert_after_cf_list(nir_builder *build,
+ struct exec_list *cf_node_list)
+{
+ build-cf_node_list = cf_node_list;
+}
+
+
[Mesa-dev] [PATCH 1/7 v2] mesa: Add gallium include dirs to more parts of the tree.
v2: Try to patch up the scons bits.
---
src/glsl/Makefile.am | 2 ++
src/glsl/SConscript | 2 ++
src/mesa/SConscript | 2 ++
src/mesa/drivers/dri/common/Makefile.am | 2 ++
src/mesa/drivers/dri/i915/Makefile.am| 2 ++
src/mesa/drivers/dri/i965/Makefile.am| 2 ++
src/mesa/drivers/dri/nouveau/Makefile.am | 2 ++
src/mesa/drivers/dri/r200/Makefile.am| 2 ++
src/mesa/drivers/dri/radeon/Makefile.am | 2 ++
src/mesa/drivers/dri/swrast/Makefile.am | 2 ++
src/util/Makefile.am | 2 ++
src/util/SConscript | 2 ++
12 files changed, 24 insertions(+)
diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
index 1e4d98f..67e9fef 100644
--- a/src/glsl/Makefile.am
+++ b/src/glsl/Makefile.am
@@ -26,6 +26,8 @@ AM_CPPFLAGS = \
-I$(top_srcdir)/src \
-I$(top_srcdir)/src/mapi \
-I$(top_srcdir)/src/mesa/ \
+ -I$(top_srcdir)/src/gallium/include \
+ -I$(top_srcdir)/src/gallium/auxiliary \
-I$(top_srcdir)/src/glsl/glcpp \
-I$(top_srcdir)/src/glsl/nir \
-I$(top_srcdir)/src/gtest/include \
diff --git a/src/glsl/SConscript b/src/glsl/SConscript
index 847e962..21c8266 100644
--- a/src/glsl/SConscript
+++ b/src/glsl/SConscript
@@ -11,6 +11,8 @@ env.Prepend(CPPPATH = [
'#src',
'#src/mapi',
'#src/mesa',
+'#src/gallium/include',
+'#src/gallium/auxiliary',
'#src/glsl',
'#src/glsl/glcpp',
])
diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index 1ad5f26..62e81ce 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -15,6 +15,8 @@ env.Append(CPPPATH = [
'#/src/mapi',
'#/src/glsl',
'#/src/mesa',
+'#/src/gallium/include',
+'#/src/gallium/auxiliary',
Dir('../mapi'), # src/mapi build path
Dir('.'), # src/mesa build path
])
diff --git a/src/mesa/drivers/dri/common/Makefile.am
b/src/mesa/drivers/dri/common/Makefile.am
index af6f742..da8f97a 100644
--- a/src/mesa/drivers/dri/common/Makefile.am
+++ b/src/mesa/drivers/dri/common/Makefile.am
@@ -30,6 +30,8 @@ AM_CFLAGS = \
-I$(top_srcdir)/src/ \
-I$(top_srcdir)/src/mapi \
-I$(top_srcdir)/src/mesa/ \
+ -I$(top_srcdir)/src/gallium/include \
+ -I$(top_srcdir)/src/gallium/auxiliary \
$(DEFINES) \
$(EXPAT_CFLAGS) \
$(VISIBILITY_CFLAGS)
diff --git a/src/mesa/drivers/dri/i915/Makefile.am
b/src/mesa/drivers/dri/i915/Makefile.am
index ac49360..822f74c 100644
--- a/src/mesa/drivers/dri/i915/Makefile.am
+++ b/src/mesa/drivers/dri/i915/Makefile.am
@@ -28,6 +28,8 @@ AM_CFLAGS = \
-I$(top_srcdir)/src/ \
-I$(top_srcdir)/src/mapi \
-I$(top_srcdir)/src/mesa/ \
+ -I$(top_srcdir)/src/gallium/include \
+ -I$(top_srcdir)/src/gallium/auxiliary \
-I$(top_srcdir)/src/mesa/drivers/dri/common \
-I$(top_srcdir)/src/mesa/drivers/dri/intel/server \
-I$(top_builddir)/src/mesa/drivers/dri/common \
diff --git a/src/mesa/drivers/dri/i965/Makefile.am
b/src/mesa/drivers/dri/i965/Makefile.am
index 07eefce..5d33159 100644
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/mesa/drivers/dri/i965/Makefile.am
@@ -28,6 +28,8 @@ AM_CFLAGS = \
-I$(top_srcdir)/src/ \
-I$(top_srcdir)/src/mapi \
-I$(top_srcdir)/src/mesa/ \
+ -I$(top_srcdir)/src/gallium/include \
+ -I$(top_srcdir)/src/gallium/auxiliary \
-I$(top_srcdir)/src/mesa/drivers/dri/common \
-I$(top_srcdir)/src/mesa/drivers/dri/intel/server \
-I$(top_srcdir)/src/gtest/include \
diff --git a/src/mesa/drivers/dri/nouveau/Makefile.am
b/src/mesa/drivers/dri/nouveau/Makefile.am
index f302864..61af95a 100644
--- a/src/mesa/drivers/dri/nouveau/Makefile.am
+++ b/src/mesa/drivers/dri/nouveau/Makefile.am
@@ -33,6 +33,8 @@ AM_CFLAGS = \
-I$(top_srcdir)/src/ \
-I$(top_srcdir)/src/mapi \
-I$(top_srcdir)/src/mesa/ \
+ -I$(top_srcdir)/src/gallium/include \
+ -I$(top_srcdir)/src/gallium/auxiliary \
-I$(top_srcdir)/src/mesa/drivers/dri/common \
$(DEFINES) \
$(VISIBILITY_CFLAGS) \
diff --git a/src/mesa/drivers/dri/r200/Makefile.am
b/src/mesa/drivers/dri/r200/Makefile.am
index a156728..137d3c8 100644
--- a/src/mesa/drivers/dri/r200/Makefile.am
+++ b/src/mesa/drivers/dri/r200/Makefile.am
@@ -32,6 +32,8 @@ AM_CFLAGS = \
-I$(top_srcdir)/src/ \
-I$(top_srcdir)/src/mapi \
-I$(top_srcdir)/src/mesa/ \
+ -I$(top_srcdir)/src/gallium/include \
+ -I$(top_srcdir)/src/gallium/auxiliary \
-I$(top_srcdir)/src/mesa/drivers/dri/common \
-I$(top_srcdir)/src/mesa/drivers/dri/r200/server \
-I$(top_builddir)/src/mesa/drivers/dri/common \
diff --git a/src/mesa/drivers/dri/radeon/Makefile.am
b/src/mesa/drivers/dri/radeon/Makefile.am
index 25c4884..b236aa6 100644
--- a/src/mesa/drivers/dri/radeon/Makefile.am
+++ b/src/mesa/drivers/dri/radeon/Makefile.am
@@ -33,6 +33,8 @@
[Mesa-dev] [PATCH 1/2] i965: Minor fixes to PBO uploads and downloads.
Fixes all of the failures in arb_direct_state_access/gettextureimage-targets
except for GL_TEXTURE_1D_ARRAY PBO. Previously, the miptree for meta pbo
uploads and downloads was not getting initialized correctly.
---
src/mesa/drivers/common/meta_tex_subimage.c | 8 ++--
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 2 +-
src/mesa/drivers/dri/i965/intel_tex.c | 3 ++-
src/mesa/main/dd.h| 1 +
4 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/common/meta_tex_subimage.c
b/src/mesa/drivers/common/meta_tex_subimage.c
index 68c8273..6196283 100644
--- a/src/mesa/drivers/common/meta_tex_subimage.c
+++ b/src/mesa/drivers/common/meta_tex_subimage.c
@@ -51,7 +51,7 @@ create_texture_for_pbo(struct gl_context *ctx, bool
create_pbo,
{
uint32_t pbo_format;
GLenum internal_format;
- unsigned row_stride;
+ unsigned row_stride, image_stride;
struct gl_buffer_object *buffer_obj;
struct gl_texture_object *tex_obj;
struct gl_texture_image *tex_image;
@@ -74,6 +74,8 @@ create_texture_for_pbo(struct gl_context *ctx, bool
create_pbo,
pixels = _mesa_image_address3d(packing, pixels,
width, height, format, type, 0, 0, 0);
row_stride = _mesa_image_row_stride(packing, width, format, type);
+ image_stride = _mesa_image_image_stride(packing, width, height, format,
+ type);
if (_mesa_is_bufferobj(packing-BufferObj)) {
*tmp_pbo = 0;
@@ -100,8 +102,9 @@ create_texture_for_pbo(struct gl_context *ctx, bool
create_pbo,
_mesa_GenTextures(1, tmp_tex);
tex_obj = _mesa_lookup_texture(ctx, *tmp_tex);
tex_obj-Target = depth 1 ? GL_TEXTURE_2D_ARRAY : GL_TEXTURE_2D;
+ _mesa_initialize_texture_object(ctx, tex_obj, *tmp_tex, tex_obj-Target);
tex_obj-Immutable = GL_TRUE;
- _mesa_initialize_texture_object(ctx, tex_obj, *tmp_tex, GL_TEXTURE_2D);
+ tex_obj-NumLayers = 1;
internal_format = _mesa_get_format_base_format(pbo_format);
@@ -114,6 +117,7 @@ create_texture_for_pbo(struct gl_context *ctx, bool
create_pbo,
buffer_obj,
(intptr_t)pixels,
row_stride,
+ image_stride,
read_only)) {
_mesa_DeleteTextures(1, tmp_tex);
_mesa_DeleteBuffers(1, tmp_pbo);
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 0e3888f..b46532d 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -724,7 +724,7 @@ intel_miptree_create_for_bo(struct brw_context *brw,
mt = intel_miptree_create_layout(brw, target, format,
0, 0,
width, height, depth,
-true, 0, false);
+true, 0, true);
if (!mt) {
free(mt);
return mt;
diff --git a/src/mesa/drivers/dri/i965/intel_tex.c
b/src/mesa/drivers/dri/i965/intel_tex.c
index 2d3009a..3a0c09a 100644
--- a/src/mesa/drivers/dri/i965/intel_tex.c
+++ b/src/mesa/drivers/dri/i965/intel_tex.c
@@ -305,6 +305,7 @@ intel_set_texture_storage_for_buffer_object(struct
gl_context *ctx,
struct gl_buffer_object
*buffer_obj,
uint32_t buffer_offset,
uint32_t row_stride,
+uint32_t image_stride,
bool read_only)
{
struct brw_context *brw = brw_context(ctx);
@@ -334,7 +335,7 @@ intel_set_texture_storage_for_buffer_object(struct
gl_context *ctx,
drm_intel_bo *bo = intel_bufferobj_buffer(brw, intel_buffer_obj,
buffer_offset,
- row_stride * image-Height);
+ image_stride * image-Depth);
intel_texobj-mt =
intel_miptree_create_for_bo(brw, bo,
image-TexFormat,
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index ec8662b..9de08e2 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -429,6 +429,7 @@ struct dd_function_table {
struct gl_buffer_object *bufferObj,
uint32_t buffer_offset,
uint32_t row_stride,
+uint32_t image_stride,
bool read_only);
/**
--
2.1.0
___
mesa-dev mailing list
[Mesa-dev] [PATCH 2/2] common: Fix PBOs for 1D_ARRAY.
Corrects the way that _mesa_meta_pbo_TexSubImage and
_mesa_meta_pbo_GetTexSubImage handle 1D_ARRAY textures. Fixes a failure in
the Piglit arb_direct_state_access/gettextureimage-targets test.
---
src/mesa/drivers/common/meta_tex_subimage.c | 60 -
1 file changed, 34 insertions(+), 26 deletions(-)
diff --git a/src/mesa/drivers/common/meta_tex_subimage.c
b/src/mesa/drivers/common/meta_tex_subimage.c
index 6196283..1ed39ab 100644
--- a/src/mesa/drivers/common/meta_tex_subimage.c
+++ b/src/mesa/drivers/common/meta_tex_subimage.c
@@ -140,7 +140,7 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx, GLuint
dims,
struct gl_texture_image *pbo_tex_image;
GLenum status;
bool success = false;
- int z;
+ int z, iters;
/* XXX: This should probably be passed in from somewhere */
const char *where = _mesa_meta_pbo_TexSubImage;
@@ -188,12 +188,6 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx, GLuint
dims,
_mesa_BindFramebuffer(GL_READ_FRAMEBUFFER, fbos[0]);
_mesa_BindFramebuffer(GL_DRAW_FRAMEBUFFER, fbos[1]);
- if (tex_image-TexObject-Target == GL_TEXTURE_1D_ARRAY) {
- assert(depth == 1);
- depth = height;
- height = 1;
- }
-
_mesa_meta_bind_fbo_image(GL_READ_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,
pbo_tex_image, 0);
/* If this passes on the first layer it should pass on the others */
@@ -217,7 +211,10 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx, GLuint
dims,
GL_COLOR_BUFFER_BIT, GL_NEAREST))
goto fail;
- for (z = 1; z depth; z++) {
+ iters = tex_image-TexObject-Target == GL_TEXTURE_1D_ARRAY ?
+ height : depth;
+
+ for (z = 1; z iters; z++) {
_mesa_meta_bind_fbo_image(GL_READ_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,
pbo_tex_image, z);
_mesa_meta_bind_fbo_image(GL_DRAW_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,
@@ -225,11 +222,18 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx, GLuint
dims,
_mesa_update_state(ctx);
- _mesa_meta_BlitFramebuffer(ctx, ctx-ReadBuffer, ctx-DrawBuffer,
- 0, 0, width, height,
- xoffset, yoffset,
- xoffset + width, yoffset + height,
- GL_COLOR_BUFFER_BIT, GL_NEAREST);
+ if (tex_image-TexObject-Target == GL_TEXTURE_1D_ARRAY)
+ _mesa_meta_BlitFramebuffer(ctx, ctx-ReadBuffer, ctx-DrawBuffer,
+0, z, width, z + 1,
+xoffset, yoffset,
+xoffset + width, yoffset + 1,
+GL_COLOR_BUFFER_BIT, GL_NEAREST);
+ else
+ _mesa_meta_BlitFramebuffer(ctx, ctx-ReadBuffer, ctx-DrawBuffer,
+0, 0, width, height,
+xoffset, yoffset,
+xoffset + width, yoffset + height,
+GL_COLOR_BUFFER_BIT, GL_NEAREST);
}
success = true;
@@ -256,7 +260,7 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx,
GLuint dims,
struct gl_texture_image *pbo_tex_image;
GLenum status;
bool success = false;
- int z;
+ int z, iters;
/* XXX: This should probably be passed in from somewhere */
const char *where = _mesa_meta_pbo_GetTexSubImage;
@@ -298,12 +302,6 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx,
GLuint dims,
_mesa_GenFramebuffers(2, fbos);
- if (tex_image tex_image-TexObject-Target == GL_TEXTURE_1D_ARRAY) {
- assert(depth == 1);
- depth = height;
- height = 1;
- }
-
/* If we were given a texture, bind it to the read framebuffer. If not,
* we're doing a ReadPixels and we should just use whatever framebuffer
* the client has bound.
@@ -337,7 +335,10 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx,
GLuint dims,
GL_COLOR_BUFFER_BIT, GL_NEAREST))
goto fail;
- for (z = 1; z depth; z++) {
+ iters = tex_image-TexObject-Target == GL_TEXTURE_1D_ARRAY ?
+ height : depth;
+
+ for (z = 1; z iters; z++) {
_mesa_meta_bind_fbo_image(GL_READ_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,
tex_image, zoffset + z);
_mesa_meta_bind_fbo_image(GL_DRAW_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,
@@ -345,11 +346,18 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx,
GLuint dims,
_mesa_update_state(ctx);
- _mesa_meta_BlitFramebuffer(ctx, ctx-ReadBuffer, ctx-DrawBuffer,
- xoffset, yoffset,
- xoffset + width, yoffset + height,
- 0, 0, width, height,
- GL_COLOR_BUFFER_BIT, GL_NEAREST);
+ if (tex_image-TexObject-Target == GL_TEXTURE_1D_ARRAY)
+
Re: [Mesa-dev] [PATCH 1/2] i965/skl: Upload qpitch in pixels for 1D textures
On Wed, Feb 18, 2015 at 07:13:54PM +, Neil Roberts wrote: Ben Widawsky b...@bwidawsk.net writes: I promise to look at this again in more detail tomorrow when I am more awake, but meanwhile, I'd be very much in favor of just setting mt-qpith for all miptree layout types. I'm not sure what you mean. Do you mean that we should just always set mt-qpitch to the actual value that we're going to upload? Yes, that seems like a good idea. I was originally worried about that because I had thought that other bits of code were looking at the qpitch to work out some offsets but that is not the case. That was what I meant - it was very poorly stated. The qpitch seems to also be broken for 3D textures and compressed textures so I think it might be a good idea to squash this patch into a general patch which fixes everything. I made a start on that as part of fixing the copyteximage test for 3D textures here: https://github.com/bpeel/mesa/commit/fc95546c49f0e5c5805139712c51a0d13b2183c3 I don't want to post the patch to the mailing list yet because it doesn't fix the test for the GL_RGBA32 format with 3D textures and I'd like to work out why first. Regards, - Neil Okay. I got distracted today trying to help Chris debug TS anyway. A squash sounds good to me, but I presume it's still worth reviewing these anyway - which I will do ASAP. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965/skl: Layout a 1D miptree horizontally
On Wed, Feb 18, 2015 at 3:34 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Wed, Feb 18, 2015 at 6:02 PM, Ian Romanick i...@freedesktop.org wrote:
On 02/17/2015 06:03 AM, Neil Roberts wrote:
+ /* When this layout is used the horizontal alignment is fixed at 64 and
the
+* hardware ignores the value given in the surface state
+*/
+ const unsigned int align_w = 64;
+
+ mt-total_height = mt-physical_height0;
+
+ if (mt-compressed) {
+ mt-total_height = ALIGN(mt-physical_height0, mt-align_h);
+ }
There aren't any compressed formats that support 1D textures, so I don't
think this can occur. Does the bspec say anything about compressed 1D
textures?
This might not be valid for this hardware generation, but ASTC
supports compressed 1D textures...
I don't see that. It [0] mentions TexImage1D in an area that explains
what regular GL 4.2 allows but the next paragraph explains that it
doesn't apply to ASTC. I don't see text anywhere else that indicates
that 1D is supported. Am I looking at the wrong extension or missing
something?
[0] https://www.opengl.org/registry/specs/KHR/texture_compression_astc_hdr.txt
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v7] nir: Add an ALU op builder kind of like ir_builder.h
On Wed, Feb 18, 2015 at 6:43 PM, Eric Anholt e...@anholt.net wrote:
v2: Rebase on the nir_opcodes.h python code generation support.
v3: Use SSA values, and set an appropriate writemask on dot products.
v4: Make the arguments be SSA references as well. This lets you stack up
expressions in the arguments of other expressions, at the cost of
having to insert a fmov/imov if you want to swizzle. Also, add
the generated file to NIR_GENERATED_FILES.
v5: Use more pythonish style for iterating the list.
v6: Infer the size of the dest from the size of the srcs, and auto-swizzle
a single small src out to the appropriate size.
v7: Add little helpers for initializing the struct, add a typedef for the
struct like other nir types have.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org (v6)
---
src/glsl/Makefile.am | 5 ++
src/glsl/Makefile.sources | 1 +
src/glsl/nir/.gitignore | 1 +
src/glsl/nir/nir_builder.h| 130
++
src/glsl/nir/nir_builder_opcodes_h.py | 38 ++
5 files changed, 175 insertions(+)
create mode 100644 src/glsl/nir/nir_builder.h
create mode 100644 src/glsl/nir/nir_builder_opcodes_h.py
diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
index 1e4d98f..5d5cacc 100644
--- a/src/glsl/Makefile.am
+++ b/src/glsl/Makefile.am
@@ -216,6 +216,7 @@ BUILT_SOURCES =
\
glsl_lexer.cpp \
glcpp/glcpp-parse.c \
glcpp/glcpp-lex.c \
+ nir/nir_builder_opcodes.h \
nir/nir_constant_expressions.c \
nir/nir_opcodes.c \
nir/nir_opcodes.h \
@@ -232,6 +233,10 @@ dist-hook:
$(RM) glcpp/tests/*.out
$(RM) glcpp/tests/subtest*/*.out
+nir/nir_builder_opcodes.h: nir/nir_opcodes.py nir/nir_builder_opcodes_h.py
+ $(MKDIR_P) nir; \
+ $(PYTHON2) $(PYTHON_FLAGS) $(srcdir)/nir/nir_builder_opcodes_h.py $@
+
nir/nir_constant_expressions.c: nir/nir_opcodes.py
nir/nir_constant_expressions.py nir/nir_constant_expressions.h
$(MKDIR_P) nir; \
$(PYTHON2) $(PYTHON_FLAGS) $(srcdir)/nir/nir_constant_expressions.py
$@
diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
index 7e66e91..3157d9a 100644
--- a/src/glsl/Makefile.sources
+++ b/src/glsl/Makefile.sources
@@ -11,6 +11,7 @@ LIBGLCPP_GENERATED_FILES = \
glcpp/glcpp-parse.c
NIR_GENERATED_FILES = \
+ nir/nir_builder_opcodes.h \
nir/nir_constant_expressions.c \
nir/nir_opcodes.c \
nir/nir_opcodes.h \
diff --git a/src/glsl/nir/.gitignore b/src/glsl/nir/.gitignore
index 261f64f..64828eb 100644
--- a/src/glsl/nir/.gitignore
+++ b/src/glsl/nir/.gitignore
@@ -1,3 +1,4 @@
+nir_builder_opcodes.h
nir_opt_algebraic.c
nir_opcodes.c
nir_opcodes.h
diff --git a/src/glsl/nir/nir_builder.h b/src/glsl/nir/nir_builder.h
new file mode 100644
index 000..7c4f7fd
--- /dev/null
+++ b/src/glsl/nir/nir_builder.h
@@ -0,0 +1,130 @@
+/*
+ * Copyright © 2014-2015 Broadcom
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef NIR_BUILDER_H
+#define NIR_BUILDER_H
+
+struct exec_list;
+
+typedef struct nir_builder {
This doesn't really matter, but you can just do typedef struct { ...
here since nothing is using nir_builder ahead of its definition.
+ struct exec_list *cf_node_list;
+ nir_shader *shader;
+ nir_function_impl *impl;
+} nir_builder;
+
+static inline void
+nir_builder_init(nir_builder *build, nir_function_impl
[Mesa-dev] [PATCH v4] Fixing an x86 FPU bug.
From: Marius Predut marius.pre...@intel.com
On 32-bit, for floating point operations is used x86 FPU registers
instead SSE, reason for when reinterprets an integer as a float
result is unexpected (modify floats when they are written to memory).
The patch was checked with and without -O3 compiler flag.
Also, it add performace improvement because treat GLfloats as GLint.
On x86 systems, moving a float as a int (thereby using integer registers
instead of FP registers) is a performance win.
Neil Roberts review:
-include changes on all places that are storing attribute values.
Brian Paul review:
- use fi_type type instead gl_constant_value
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82668
Signed-off-by: Marius Predut marius.pre...@intel.com
---
src/mesa/main/context.c |3 ++-
src/mesa/main/macros.h| 32
src/mesa/vbo/vbo_attrib_tmp.h | 20
src/mesa/vbo/vbo_context.h| 14 +++---
src/mesa/vbo/vbo_exec.h | 11 ++-
src/mesa/vbo/vbo_exec_api.c | 35 +--
src/mesa/vbo/vbo_exec_draw.c |6 +++---
src/mesa/vbo/vbo_exec_eval.c | 22 +++---
src/mesa/vbo/vbo_save.h | 16
src/mesa/vbo/vbo_save_api.c | 34 +-
src/mesa/vbo/vbo_save_draw.c |4 ++--
11 files changed, 105 insertions(+), 92 deletions(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 63d30a2..f0597e2 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -134,6 +134,7 @@
#include math/m_matrix.h
#include main/dispatch.h /* for _gloffset_COUNT */
#include uniforms.h
+#include macros.h
#ifdef USE_SPARC_ASM
#include sparc/sparc.h
@@ -656,7 +657,7 @@ _mesa_init_constants(struct gl_constants *consts, gl_api
api)
consts-MaxSamples = 0;
/* GLSL default if NativeIntegers == FALSE */
- consts-UniformBooleanTrue = FLT_AS_UINT(1.0f);
+ consts-UniformBooleanTrue = FLOAT_AS_UNION(1.0f).u;
/* GL_ARB_sync */
consts-MaxServerWaitTimeout = 0x1fff7fffULL;
diff --git a/src/mesa/main/macros.h b/src/mesa/main/macros.h
index 2d59c6f..9ca3460 100644
--- a/src/mesa/main/macros.h
+++ b/src/mesa/main/macros.h
@@ -170,25 +170,25 @@ extern GLfloat _mesa_ubyte_to_float_color_tab[256];
ub = ((GLubyte) F_TO_I((f) * 255.0F))
#endif
-static inline GLfloat INT_AS_FLT(GLint i)
+static fi_type UINT_AS_UNION(GLuint u)
{
fi_type tmp;
- tmp.i = i;
- return tmp.f;
+ tmp.u = u;
+ return tmp;
}
-static inline GLfloat UINT_AS_FLT(GLuint u)
+static inline fi_type INT_AS_UNION(GLint i)
{
fi_type tmp;
- tmp.u = u;
- return tmp.f;
+ tmp.i = i;
+ return tmp;
}
-static inline unsigned FLT_AS_UINT(float f)
+static inline fi_type FLOAT_AS_UNION(GLfloat f)
{
fi_type tmp;
tmp.f = f;
- return tmp.u;
+ return tmp;
}
/**
@@ -620,24 +620,24 @@ do { \
* The default values are chosen based on \p type.
*/
static inline void
-COPY_CLEAN_4V_TYPE_AS_FLOAT(GLfloat dst[4], int sz, const GLfloat src[4],
+COPY_CLEAN_4V_TYPE_AS_UNION(fi_type dst[4], int sz, const fi_type src[4],
GLenum type)
{
switch (type) {
case GL_FLOAT:
- ASSIGN_4V(dst, 0, 0, 0, 1);
+ ASSIGN_4V(dst, FLOAT_AS_UNION(0), FLOAT_AS_UNION(0), FLOAT_AS_UNION(0),
FLOAT_AS_UNION(1));
break;
case GL_INT:
- ASSIGN_4V(dst, INT_AS_FLT(0), INT_AS_FLT(0),
- INT_AS_FLT(0), INT_AS_FLT(1));
+ ASSIGN_4V(dst, INT_AS_UNION(0), INT_AS_UNION(0),
+INT_AS_UNION(0), INT_AS_UNION(1));
break;
case GL_UNSIGNED_INT:
- ASSIGN_4V(dst, UINT_AS_FLT(0), UINT_AS_FLT(0),
- UINT_AS_FLT(0), UINT_AS_FLT(1));
+ ASSIGN_4V(dst, UINT_AS_UNION(0), UINT_AS_UNION(0),
+UINT_AS_UNION(0), UINT_AS_UNION(1));
break;
default:
- ASSIGN_4V(dst, 0.0f, 0.0f, 0.0f, 1.0f); /* silence warnings */
- ASSERT(!Unexpected type in COPY_CLEAN_4V_TYPE_AS_FLOAT macro);
+ ASSIGN_4V(dst, FLOAT_AS_UNION(0), FLOAT_AS_UNION(0), FLOAT_AS_UNION(0),
FLOAT_AS_UNION(1)); /* silence warnings */
+ ASSERT(!Unexpected type in COPY_CLEAN_4V_TYPE_AS_UNION macro);
}
COPY_SZ_4V(dst, sz, src);
}
diff --git a/src/mesa/vbo/vbo_attrib_tmp.h b/src/mesa/vbo/vbo_attrib_tmp.h
index ec66934..17a0a10 100644
--- a/src/mesa/vbo/vbo_attrib_tmp.h
+++ b/src/mesa/vbo/vbo_attrib_tmp.h
@@ -28,6 +28,18 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
#include util/u_format_r11g11b10f.h
#include main/varray.h
+
+/* ATTR */
+#define ATTR( A, N, T, V0, V1, V2, V3 ) ATTR_##T((A), (N), (T), (V0),
(V1), (V2), (V3))
+
+#define ATTR_GL_UNSIGNED_INT( A, N, T, V0, V1, V2, V3 ) \
+ATTR_UNION(A, N, T, UINT_AS_UNION(V0), UINT_AS_UNION(V1),
UINT_AS_UNION(V2), UINT_AS_UNION(V3))
+#define ATTR_GL_INT( A, N, T, V0, V1, V2, V3 ) \
+ATTR_UNION(A, N, T,
Re: [Mesa-dev] [PATCH 1/2 v3] configure: add visibility macro detection to configure
On Wed, Feb 18, 2015 at 6:03 AM, Sedat Dilek sedat.di...@gmail.com wrote:
On Tue, Feb 17, 2015 at 11:00 AM, Sedat Dilek sedat.di...@gmail.com wrote:
On Tue, Feb 17, 2015 at 10:40 AM, Marc Dietrich marvi...@gmx.de wrote:
This adds clang/gcc visibility macro detection to configure and
util/macros.h.
This is can be used to conveniently add e.g. a HIDDEN attribute to a
function.
Signed-off-by: Marc Dietrich marvi...@gmx.de
---
v2: use VISIBILITY_*FLAGS instead of *FLAGS directly
v3: no change
configure.ac | 28 ++--
src/util/macros.h | 6 ++
2 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/configure.ac b/configure.ac
index 351027b..266764a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -189,6 +189,7 @@ AX_GCC_FUNC_ATTRIBUTE([flatten])
AX_GCC_FUNC_ATTRIBUTE([format])
AX_GCC_FUNC_ATTRIBUTE([malloc])
AX_GCC_FUNC_ATTRIBUTE([packed])
+AX_GCC_FUNC_ATTRIBUTE([visibility])
AM_CONDITIONAL([GEN_ASM_OFFSETS], test x$GEN_ASM_OFFSETS = xyes)
@@ -245,17 +246,13 @@ if test x$GCC = xyes; then
AC_MSG_RESULT([yes]),
[CFLAGS=$save_CFLAGS -Wmissing-prototypes;
AC_MSG_RESULT([no])]);
+CFLAGS=$save_CFLAGS
# Enable -fvisibility=hidden if using a gcc that supports it
Can you restore this comment with a general pointer to ...compiler
that support it.
BTW, what is the compiler option called for clang to suppress
visibility(-hiden) feature - ... -fvisibility=no ?
I would like to test w/o your patches.
- Sedat -
-save_CFLAGS=$CFLAGS
-AC_MSG_CHECKING([whether $CC supports -fvisibility=hidden])
-VISIBILITY_CFLAGS=-fvisibility=hidden
-CFLAGS=$CFLAGS $VISIBILITY_CFLAGS
-AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
- [VISIBILITY_CFLAGS=; AC_MSG_RESULT([no])]);
-
-# Restore CFLAGS; VISIBILITY_CFLAGS are added to it where needed.
-CFLAGS=$save_CFLAGS
+if test x${ax_cv_have_func_attribute_visibility} = xyes; then
+ VISIBILITY_CFLAGS=-fvisibility=hidden
+ VISIBILITY_CXXFLAGS=-fvisibility=hidden
+fi
# Work around aliasing bugs - developers should comment this out
CFLAGS=$CFLAGS -fno-strict-aliasing
@@ -267,19 +264,6 @@ fi
if test x$GXX = xyes; then
CXXFLAGS=$CXXFLAGS -Wall
-# Enable -fvisibility=hidden if using a gcc that supports it
-save_CXXFLAGS=$CXXFLAGS
-AC_MSG_CHECKING([whether $CXX supports -fvisibility=hidden])
-VISIBILITY_CXXFLAGS=-fvisibility=hidden
-CXXFLAGS=$CXXFLAGS $VISIBILITY_CXXFLAGS
-AC_LANG_PUSH([C++])
-AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
- [VISIBILITY_CXXFLAGS= ; AC_MSG_RESULT([no])]);
-AC_LANG_POP([C++])
-
-# Restore CXXFLAGS; VISIBILITY_CXXFLAGS are added to it where needed.
-CXXFLAGS=$save_CXXFLAGS
-
# Work around aliasing bugs - developers should comment this out
CXXFLAGS=$CXXFLAGS -fno-strict-aliasing
diff --git a/src/util/macros.h b/src/util/macros.h
index eec8b93..7682511 100644
--- a/src/util/macros.h
+++ b/src/util/macros.h
@@ -117,6 +117,12 @@ do { \
#define PRINTFLIKE(f, a)
#endif
+#ifdef HAVE_FUNC_ATTRIBUTE_VISIBILITY
+#define HIDDEN __attribute__((visibility(hidden)))
+#else
+#define HIDDEN
+#endif
+
#ifdef HAVE_FUNC_ATTRIBUTE_MALLOC
#define MALLOCLIKE __attribute__((__malloc__))
#else
--
2.2.2
Here the fix for the comment in visibility macro detection.
- Sedat -
BTW, I would change the subject to something like...
configure: add visibility macro detection (or s/add/introduce)
Can you send a v4 of your patchset, please?
With appropriate credits (Reported-by/Tested-by of mine)?
Thanks!
- Sedat -
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2 v3] configure: add visibility macro detection to configure
On Tue, Feb 17, 2015 at 11:00 AM, Sedat Dilek sedat.di...@gmail.com wrote:
On Tue, Feb 17, 2015 at 10:40 AM, Marc Dietrich marvi...@gmx.de wrote:
This adds clang/gcc visibility macro detection to configure and
util/macros.h.
This is can be used to conveniently add e.g. a HIDDEN attribute to a
function.
Signed-off-by: Marc Dietrich marvi...@gmx.de
---
v2: use VISIBILITY_*FLAGS instead of *FLAGS directly
v3: no change
configure.ac | 28 ++--
src/util/macros.h | 6 ++
2 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/configure.ac b/configure.ac
index 351027b..266764a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -189,6 +189,7 @@ AX_GCC_FUNC_ATTRIBUTE([flatten])
AX_GCC_FUNC_ATTRIBUTE([format])
AX_GCC_FUNC_ATTRIBUTE([malloc])
AX_GCC_FUNC_ATTRIBUTE([packed])
+AX_GCC_FUNC_ATTRIBUTE([visibility])
AM_CONDITIONAL([GEN_ASM_OFFSETS], test x$GEN_ASM_OFFSETS = xyes)
@@ -245,17 +246,13 @@ if test x$GCC = xyes; then
AC_MSG_RESULT([yes]),
[CFLAGS=$save_CFLAGS -Wmissing-prototypes;
AC_MSG_RESULT([no])]);
+CFLAGS=$save_CFLAGS
# Enable -fvisibility=hidden if using a gcc that supports it
Can you restore this comment with a general pointer to ...compiler
that support it.
BTW, what is the compiler option called for clang to suppress
visibility(-hiden) feature - ... -fvisibility=no ?
I would like to test w/o your patches.
- Sedat -
-save_CFLAGS=$CFLAGS
-AC_MSG_CHECKING([whether $CC supports -fvisibility=hidden])
-VISIBILITY_CFLAGS=-fvisibility=hidden
-CFLAGS=$CFLAGS $VISIBILITY_CFLAGS
-AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
- [VISIBILITY_CFLAGS=; AC_MSG_RESULT([no])]);
-
-# Restore CFLAGS; VISIBILITY_CFLAGS are added to it where needed.
-CFLAGS=$save_CFLAGS
+if test x${ax_cv_have_func_attribute_visibility} = xyes; then
+ VISIBILITY_CFLAGS=-fvisibility=hidden
+ VISIBILITY_CXXFLAGS=-fvisibility=hidden
+fi
# Work around aliasing bugs - developers should comment this out
CFLAGS=$CFLAGS -fno-strict-aliasing
@@ -267,19 +264,6 @@ fi
if test x$GXX = xyes; then
CXXFLAGS=$CXXFLAGS -Wall
-# Enable -fvisibility=hidden if using a gcc that supports it
-save_CXXFLAGS=$CXXFLAGS
-AC_MSG_CHECKING([whether $CXX supports -fvisibility=hidden])
-VISIBILITY_CXXFLAGS=-fvisibility=hidden
-CXXFLAGS=$CXXFLAGS $VISIBILITY_CXXFLAGS
-AC_LANG_PUSH([C++])
-AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
- [VISIBILITY_CXXFLAGS= ; AC_MSG_RESULT([no])]);
-AC_LANG_POP([C++])
-
-# Restore CXXFLAGS; VISIBILITY_CXXFLAGS are added to it where needed.
-CXXFLAGS=$save_CXXFLAGS
-
# Work around aliasing bugs - developers should comment this out
CXXFLAGS=$CXXFLAGS -fno-strict-aliasing
diff --git a/src/util/macros.h b/src/util/macros.h
index eec8b93..7682511 100644
--- a/src/util/macros.h
+++ b/src/util/macros.h
@@ -117,6 +117,12 @@ do { \
#define PRINTFLIKE(f, a)
#endif
+#ifdef HAVE_FUNC_ATTRIBUTE_VISIBILITY
+#define HIDDEN __attribute__((visibility(hidden)))
+#else
+#define HIDDEN
+#endif
+
#ifdef HAVE_FUNC_ATTRIBUTE_MALLOC
#define MALLOCLIKE __attribute__((__malloc__))
#else
--
2.2.2
Here the fix for the comment in visibility macro detection.
- Sedat -
From 25ae86da648c611c466a2167d1fbb3c85c0c1def Mon Sep 17 00:00:00 2001
From: Sedat Dilek sedat.di...@gmail.com
Date: Wed, 18 Feb 2015 05:59:26 +0100
Subject: [PATCH] configure: Fix comment in visibility macro detection
Fixes: configure: add visibility macro detection to configure (v3)
Signed-off-by: Sedat Dilek sedat.di...@gmail.com
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 612473b8f77f..77e17d121e59 100644
--- a/configure.ac
+++ b/configure.ac
@@ -197,7 +197,7 @@ if test x$GCC = xyes; then
AC_MSG_RESULT([no])]);
CFLAGS=$save_CFLAGS
-# Enable -fvisibility=hidden if using a gcc that supports it
+# Enable -fvisibility=hidden if using a compiler that supports it
if test x${ax_cv_have_func_attribute_visibility} = xyes; then
VISIBILITY_CFLAGS=-fvisibility=hidden
VISIBILITY_CXXFLAGS=-fvisibility=hidden
--
2.3.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965/skl: Layout a 1D miptree horizontally
On Thu, Feb 19, 2015 at 1:12 AM, Matt Turner matts...@gmail.com wrote:
On Wed, Feb 18, 2015 at 3:34 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Wed, Feb 18, 2015 at 6:02 PM, Ian Romanick i...@freedesktop.org wrote:
On 02/17/2015 06:03 AM, Neil Roberts wrote:
+ /* When this layout is used the horizontal alignment is fixed at 64
and the
+* hardware ignores the value given in the surface state
+*/
+ const unsigned int align_w = 64;
+
+ mt-total_height = mt-physical_height0;
+
+ if (mt-compressed) {
+ mt-total_height = ALIGN(mt-physical_height0, mt-align_h);
+ }
There aren't any compressed formats that support 1D textures, so I don't
think this can occur. Does the bspec say anything about compressed 1D
textures?
This might not be valid for this hardware generation, but ASTC
supports compressed 1D textures...
I don't see that. It [0] mentions TexImage1D in an area that explains
what regular GL 4.2 allows but the next paragraph explains that it
doesn't apply to ASTC. I don't see text anywhere else that indicates
that 1D is supported. Am I looking at the wrong extension or missing
something?
[0] https://www.opengl.org/registry/specs/KHR/texture_compression_astc_hdr.txt
No, you're right, I wasn't being careful enough when checking. My bad,
sorry for the noise.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] DSA for core profile only? (was Re: [Piglit] [PATCH 2/2] arb_direct_state_access: New test for GetCompressedTextureImage.)
On Tuesday, February 17, 2015 02:25:05 PM Ian Romanick wrote: (Cross posting to mesa-dev.) On 02/17/2015 01:54 PM, Ilia Mirkin wrote: On Tue, Feb 17, 2015 at 4:45 PM, Ilia Mirkin imir...@alum.mit.edu wrote: On Tue, Feb 17, 2015 at 4:34 PM, Ian Romanick i...@freedesktop.org wrote: Dependencies OpenGL 2.0 is required. This means Mesa will need a flag for the extension because there are pre-2.0 drivers. Every DSA function will need to check the flag and possibly generate GL_INVALID_OPERATION. If we only support core profile (and always enable it in core profile), the functions won't even be put in the dispatch table for non-core. No flag, and no checks in the functions. So, the $64,000.00 question is: Do we care to support DSA on the few cards that can do 2.0 but not 3.1? Here's a view of some of the hardware that's stuck in GL2-land... not exhaustive: http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html#p=compat So that's basically pre-gen6 intel, NV4x (GeForce 6000 / 7000 series), AMD/ATI r300-r500, and the Adreno gpu's. (And presumably VC4.) Click around the diff mesa versions, I don't have every hw for every mesa version. What's the downside of enabling this in GL1.x drivers BTW? e.g. nv3x won't report GL2 (in Mesa) due to NPOT, and all the GeForce = 4 series due to lack of... features. Not that I really care either way, but just want to make sure there's a reason for it. There are a large number of functions added for features that only exist in 2.0 and later (all the shader related functions, all the occlusion query related functions, etc.). In addition, a bunch of the functions have slightly different behavior between core and compatibility profile. For example: void VertexArrayElementBuffer(uint vaobj, uint buffer); vaobj is [compatibility profile: zero, indicating the default vertex array object, or] the name of the vertex array object, and buffer is zero or the name of the buffer object. If buffer is zero, any existing element array buffer binding to vaobj is removed. Errors An INVALID_OPERATION error is generated by VertexArrayElementBuffer if vaobj is not [compatibility profile: zero or] the name of an existing vertex array object. Not only would we have to implement the different compatibility behavior, but we'd also have to implement tests for it. Oh, and an additional thought, if we make it core profile-only, then it will not be available in compat profile on any hardware, even the latest. I think people are far from done using compat contexts, and this would unnecessarily restrict the software that can make use of this extension. Generally newer applications already require some 3.1+ feature, so they're either running on core profile or not running on Mesa already. The last time I surveyed applications on Steam, which I realize is very specific subset of applications, there were basically two kinds of applications. 1. Games that were basically OpenGL 1.x or 2.x with a tiny set of extra features that were absolutely necessary for some effect. These games use no convenience features... even ones that would improve performance. 2. Games by vendors that are really mad that we don't already support 4.5. They use everything modern, and they never look back. The folks in group 1 aren't going to use DSA, and the folks in group 2 mourned the loss of compatibility profile ages ago. So... is there are 3rd group, and do we care enough to do the work necessary to support them? I'm inclined to simply support it for core profile, at least until an application developer requests compatibility support. It's part of OpenGL 4.5 - I suspect people using legacy GL aren't going to want to use features that are so new they've barely even shipped on the major proprietary drivers. --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
