Re: [Mesa-dev] [PATCH v5 00/29] add fp64 support to mesa and glsl compiler
On 02/11/2015 09:13 AM, Tapani Pälli wrote: On 02/10/2015 01:58 PM, Ilia Mirkin wrote: Tapani's "glsl: validate output types for shader stages" patch is necessary for the piglit that its description references to pass. If you have a better suggestion of where to put that code, let me know. I've taken more look in to this. If the output does not have a interpolation qualifier then we incorrectly allow wrong types. My patch validates the output type independent of the interpolation qualifier so that's why it works. I can add more tests if wanted. Sorry, this was not correct conclusion, the involved tests made me think so. The actual reason why patch works is that we validate the output variable types only if they are "valid varying variables" (see is_varying_var function), and output from fragment shader is not "valid varying". So we allow any type of output from fragment shader declared with 'out', this patch fixes that. It has some extra checks as it validates also outputs from other stages but to me it seems legit to do in that place. // Tapani ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 10.5.0 release candidate 1
Hey, Op 12-02-15 om 15:24 schreef Emil Velikov: > Mesa 10.5.0 release candidate 1 is now available for testing. The > current plan is to have an additional release candidate every Friday > until the eventual 10.5.0 release on Mar 6th. > > The tag in the git repository for Mesa 10.5.0-rc1 is 'mesa-10.5.0-rc1'. > > As a reminder, with the 10.5 branch now created, patches nominated with: > > CC: > > will now be candidates only for the new 10.5 branch. To nominate patches > for the older 10.4 branch as well, please use: > > CC: "10.4 10.5" > > The expectation is that the 10.4 branch will remain alive with bi-weekly > releases until after 10.5.1 release. > > Mesa 10.5.0 release candidate 1 is available for download from > ftp://freedesktop.org/pub/mesa/10.5.0/ > > sha256sums: > > 6522ff062e8e6a85390bb175e4088e5afa871a90d8aad1ac558ca00ea7a0a0e3 > mesa-10.5.0-rc1.tar.gz > 4047cdc87488e7a94ab97a507baa4b91f8f84418445aab47e5b29fe3cc49c4bd > mesa-10.5.0-rc1.tar.xz > All other releases used to be called MesaLib, and had a .zip version available. Is this an oversight or are the packaging changes permanent? ~Maarten ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/23] ARB_direct_state_access buffer objects (v2)
On 12/02/15 22:12, Ilia Mirkin wrote: On Thu, Feb 12, 2015 at 3:09 PM, Martin Peres wrote: On 12/02/15 04:05, Laura Ekstrand wrote: This includes a v2 of all of the buffer object code plus a v2 of the related TextureBufferRange entry point. Note that some implementations have been merged together (MapBuffer and MapBufferRange, for instance) because it didn't seem to make sense to keep two separate and nearly identical versions of the same code. As a reminder: Most of the implementation work involved abstracting the internals of the traditional GL functions and writing the DSA functions on top of these abstractions. For instance, to implement GenerateTextureMipmap, most of the functionality of GenerateMipmap was moved to a function: void _mesa_generate_texture_mipmap(struct gl_context *ctx, struct gl_texture_object *texObj, GLenum target, bool dsa). GenerateMipmap and GenerateTextureMipmap were then implemented on top of this function as thin layers that get the context and the relevant texture object. Someone commented on my code, stating that internal functions should not have _mesa_ in their name and I think it makes sense. Do you have an argument against that? I believe that someone was me, and that's not what I said. I said that *static* functions (i.e. functions internal to a .c file) shouldn't have a _mesa prefix. Ones that are exposed in .h files *should* have a _mesa prefix. Fair-enough, I misinterpreted the message. Sorry for the noise. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89107] [Radeonsi/Hawaii] Rendering errors when running basic opengl 3 demo
https://bugs.freedesktop.org/show_bug.cgi?id=89107 --- Comment #12 from Grigori Goronzy --- This seems to be related to the context creation by the included "MicroGlut". The code of this is quite messy. My guess is that something is wrong with context creation, not Mesa. If I replace "MicroGlut" with freeglut, it works as expected. -- 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] i965/simd8vs: Fix SIMD8 atomics
Ben Widawsky writes:
> The short version: we need to set bits in R0.7 which provide a mask to be used
> for PS kill samples/pixels. Since the VS has no such concept, we just need to
> set all 1.
>
> The longer version...
> Execution for SIMD8 atomics is defined as follows:
> SIMD8: The low 8 bits of the execution mask are ANDed with 8 bits of the
> Pixel/Sample Mask from the message header. For the typed messages, the Slot
> Group in the message descriptor selects either the low or high 8 bits. For the
> untyped messages, the low 8 bits are always selected. The resulting mask is
> used
> to determine which slots are read into the destination GRF register (for
> read),
> or which slots are written to the surface (for write). If the header is not
> present, only the low 8 bits of the execution mask are used.
>
> The message header for untyped messages is defined in R0.7 "This field
> contains
> the 16-bit pixel/sample mask to be used for SIMD16 and SIMD8 messages. All 16
> bits are used for SIMD16 messages. For typed SIMD8 messages, Slot Group
> selects
> which 8 bits of this field are used. For untyped SIMD8 messages, the low 8
> bits
> of this field are used." Furthermore, "The message header for the untyped
> messages only needs to be delivered for pixel shader threads, where the
> execution mask may indicate pixels/samples that are enabled only due to
> derivative (LOD) calculations, but the corresponding slot on the surface must
> not be accessed." We're not using a pixel shader here, but AFAICT, this mask
> is
> used for all stages.
>
> This leaves two options, Remove the header, or make the VS code emit the
> correct
> thing for the header. I believe one of the goals of using SIMD8 VS was to get
> as
> much code reuse as possible, and so I chose the latter. Since the VS has no
> such
> thing as kill instructions, the mask is derived simple as all 1's.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87258
> Cc: Kristian Høgsberg
> Signed-off-by: Ben Widawsky
> ---
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> index 2a36d94..c20289f 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> @@ -2994,6 +2994,9 @@ fs_visitor::emit_untyped_atomic(unsigned atomic_op,
> unsigned surf_index,
> if (uses_kill) {
>emit(MOV(component(sources[0], 7), brw_flag_reg(0, 1)))
> ->force_writemask_all = true;
> + } else if (stage == MESA_SHADER_VERTEX) {
> + emit(MOV(component(sources[0], 7),
> + brw_imm_ud(0xff)))->force_writemask_all = true;
> } else {
>emit(MOV(component(sources[0], 7),
> retype(brw_vec1_grf(1, 7), BRW_REGISTER_TYPE_UD)))
Looks good to me,
Reviewed-by: Francisco Jerez
> --
> 2.3.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
pgpSe85tMlCGx.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89107] [Radeonsi/Hawaii] Rendering errors when running basic opengl 3 demo
https://bugs.freedesktop.org/show_bug.cgi?id=89107 --- Comment #13 from Grigori Goronzy --- Created attachment 113522 --> https://bugs.freedesktop.org/attachment.cgi?id=113522&action=edit s/MicroGlut/freeglut/ -- 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 89107] [Radeonsi/Hawaii] Rendering errors when running basic opengl 3 demo
https://bugs.freedesktop.org/show_bug.cgi?id=89107 Grigori Goronzy changed: What|Removed |Added Attachment #113522|text/plain |application/octet-stream mime type|| -- 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] [PATCH 2/4] add visibility hidden to tls entry points
Avoid redefined symbol errors in clang. Based on a suggestion from
Rafael Ãvila de EspÃndola in
http://llvm.org/bugs/show_bug.cgi?id=19778.
Signed-off-by: Marc Dietrich
---
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"
__asm__(".text\n"
".balign 32\n"
@@ -62,7 +63,7 @@ entry_patch_public(void)
{
}
-static char
+extern char HIDDEN
x86_64_entry_start[];
mapi_func
diff --git a/src/mapi/entry_x86_tls.h b/src/mapi/entry_x86_tls.h
index fa7bc15..1926638 100644
--- a/src/mapi/entry_x86_tls.h
+++ b/src/mapi/entry_x86_tls.h
@@ -27,6 +27,7 @@
#include
#include "u_macros.h"
+#include "../util/macros.h"
__asm__(".text");
@@ -72,8 +73,8 @@ __asm__(".text");
extern unsigned long
x86_current_tls();
-static char x86_entry_start[];
-static char x86_entry_end[];
+extern char HIDDEN x86_entry_start[];
+extern char HIDDEN x86_entry_end[];
void
entry_patch_public(void)
diff --git a/src/mapi/entry_x86_tsd.h b/src/mapi/entry_x86_tsd.h
index ece00fa..d1256d9 100644
--- a/src/mapi/entry_x86_tsd.h
+++ b/src/mapi/entry_x86_tsd.h
@@ -26,6 +26,7 @@
*/
#include "u_macros.h"
+#include "../util/macros.h"
#define X86_ENTRY_SIZE 32
@@ -59,8 +60,8 @@ __asm__(".balign 32\n"
#include
#include "u_execmem.h"
-static const char x86_entry_start[];
-static const char x86_entry_end[];
+extern const char HIDDEN x86_entry_start[];
+extern const char HIDDEN x86_entry_end[];
void
entry_patch_public(void)
--
2.2.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] configure: add visibility macro detection to configure
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
---
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..6b1592f 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
-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
+ CFLAGS="$CFLAGS -fvisibility=hidden"
+ CXXFLAGS="$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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [LLVMdev] mesa-10.4.4: BROKEN TLS support in GLXwith llvm-toolchain v3.6.0rc2
Am Samstag, 14. Februar 2015, 18:20:12 schrieb Dimitry Andric: > On 11 Feb 2015, at 11:16, Sedat Dilek wrote: > > On Wed, Feb 11, 2015 at 12:09 AM, Emil Velikov wrote: > >> On 10/02/15 13:17, Dimitry Andric wrote: > >>> On 09 Feb 2015, at 18:52, Sedat Dilek wrote: > On Mon, Feb 9, 2015 at 6:44 PM, Emil Velikov wrote: > > On 07/02/15 22:42, Sedat Dilek wrote: > >>> ... > >>> > >> In file included from ../../src/mapi/entry.c:49: > >> ./entry_x86-64_tls.h:66:1: warning: tentative array definition > >> assumed > >> to have one element > >> x86_64_entry_start[]; > >> ^ > >> fatal error: error in backend: symbol 'x86_64_entry_start' is already > >> defined>>> > >>> ... > >>> > > It may be that it's a bug on our end, but it's a bit painful going > > through all the auto generated sources, the 10+ define guards and > > other > > magic that's inside src/mapi. Getting some idea on llvm/clang > > behaviour > > change should help out :-) > > > > Please open a bug-report with llvm and/or mesa, so that we have all > > the > > info in one place and things don't get lost. > > I am unsure if it is a bug in llvm/clang or in mesa. > Shall I open 2 bug-reports - in mesa and llvm BTS? > >>> > >>> Please have a look at this PR, which I opened in May 2014, and which is about the same issue: > >>> http://llvm.org/PR19778 > >> > >> Hi Dimitry, > >> > >> From a quick look at the bug, the llvm/clang devs are quoting the C11 > >> spec, yet we're not building with -std=c11 so I'm not sure that applies. > >> Feel free to forward that if interested - I'm a bit short on account on > >> their bugzilla :-) > >> > >>> The assertion seems to have been transformed now into a backend error, > >>> but this may also be because you built clang without assertions. (Did > >>> you?)>>> > >>> In any case, the workaround is to change the static symbols into extern symbols, together with a hidden visibility attribute (as suggested by Rafael Espíndola), similar to the fix I posted in this FreeBSD port bug: > >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192286 > >>> > >>> E.g., you can use these patches: > >>> > >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src__ma > >>> pi__entry_x86-64_tls.h?view=markup > >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src__m > >>> api__entry_x86_tls.h?view=markup > >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src__m > >>> api__entry_x86_tsd.h?view=markup>> > >> These patches don't look at all bad. Can you give them a bit of TLS and > >> send them to the list, please ? This also stands for the other patches > >> in FreeBSD's repo :-) > > > > On the one hand I am glad to see that there are patches available. > > I will give them a try when I am at home. > > On the other hand - knowing FreeBSD switched to llvm/clang as > > default-compiler - it's abit pity to see that stuff like this is not > > shared with upstream (did not look at the date of submission). > > If you have more patches in this area, please share them with upstream. > > The complete collection is here: > > https://svnweb.freebsd.org/ports/head/graphics/libGL/files/ > > I didn't create most of these patches, so I can't really say what the > reason for them was, or whether they still apply to Mesa master. > > In any case, for this specific issue with Mesa's TLS related definitions > breaking clang, please consider the attached patch. I think there is no need to restrict this to clang only as it also works with gcc. I submitted a slightly different version to the mesa list which uses a macro instead and also adds some credits. 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
[Mesa-dev] [Bug 89107] [Radeonsi/Hawaii] Rendering errors when running basic opengl 3 demo
https://bugs.freedesktop.org/show_bug.cgi?id=89107 --- Comment #14 from Sebastian Parborg --- (In reply to Grigori Goronzy from comment #12) > This seems to be related to the context creation by the included > "MicroGlut". The code of this is quite messy. My guess is that something is > wrong with context creation, not Mesa. > > If I replace "MicroGlut" with freeglut, it works as expected. Thanks for posting a workaround/fix! I'll try it out soon. ( Now i don't have to reboot to fglrx to work on the labs, thanks to you :) ) My professors "MicroGlut" might be the cause of this problem, I agree. The question is what it's doing wrong though. I mean, it seems to work fine on OSX and with the proprietary drivers from nvidia and amd on Linux. So if it renders correctly with all of those then what is it doing wrong? Do all those drivers interpret faulty code the "right" way? To me it seems quite unlikely that all those drivers would interpret the faulty code the exact same way so it doesn't break on any of them. -- 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] radeonsi: fix a crash if a stencil ref state is set before a DSA state
On Sun, Feb 15, 2015 at 9:43 PM, Axel Davy wrote: > It works fine. > > Since no state tracker need it currently, > why do you want to backport it to older mesa versions ? I nominate all fixes for backporting to stable branches. Some future fix which will also be backported might expose this bug. > > In all cases, > Reviewed-by: Axel Davy > > (btw: missing signoff) I only add signoffs to kernel patches, where it's required. Most people don't use signoffs in Mesa. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] st/mesa: pass etc2 textures to driver if supported
For patches 2 & 3:
Reviewed-by: Marek Olšák
Marek
On Mon, Feb 16, 2015 at 8:36 AM, Ilia Mirkin wrote:
> If the driver actually supports ETC2, don't decode it in software.
>
> Signed-off-by: Ilia Mirkin
> ---
> src/mesa/state_tracker/st_cb_texture.c | 4 ++--
> src/mesa/state_tracker/st_context.c| 3 +++
> src/mesa/state_tracker/st_context.h| 1 +
> src/mesa/state_tracker/st_format.c | 43
> +++---
> 4 files changed, 40 insertions(+), 11 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_texture.c
> b/src/mesa/state_tracker/st_cb_texture.c
> index abc68c0..0525e87 100644
> --- a/src/mesa/state_tracker/st_cb_texture.c
> +++ b/src/mesa/state_tracker/st_cb_texture.c
> @@ -211,7 +211,7 @@ st_MapTextureImage(struct gl_context *ctx,
> map = st_texture_image_map(st, stImage, pipeMode, x, y, slice, w, h, 1,
>&transfer);
> if (map) {
> - if (_mesa_is_format_etc2(texImage->TexFormat) ||
> + if ((_mesa_is_format_etc2(texImage->TexFormat) && !st->has_etc2) ||
>(texImage->TexFormat == MESA_FORMAT_ETC1_RGB8 && !st->has_etc1)) {
> /* ETC isn't supported by gallium and it's represented
>* by uncompressed formats. Only write transfers with precompressed
> @@ -254,7 +254,7 @@ st_UnmapTextureImage(struct gl_context *ctx,
> struct st_context *st = st_context(ctx);
> struct st_texture_image *stImage = st_texture_image(texImage);
>
> - if (_mesa_is_format_etc2(texImage->TexFormat) ||
> + if ((_mesa_is_format_etc2(texImage->TexFormat) && !st->has_etc2) ||
> (texImage->TexFormat == MESA_FORMAT_ETC1_RGB8 && !st->has_etc1)) {
>/* Decompress the ETC texture to the mapped one. */
>unsigned z = slice + stImage->base.Face;
> diff --git a/src/mesa/state_tracker/st_context.c
> b/src/mesa/state_tracker/st_context.c
> index 9fd6cae..5834eba 100644
> --- a/src/mesa/state_tracker/st_context.c
> +++ b/src/mesa/state_tracker/st_context.c
> @@ -230,6 +230,9 @@ st_create_context_priv( struct gl_context *ctx, struct
> pipe_context *pipe,
> st->has_etc1 = screen->is_format_supported(screen, PIPE_FORMAT_ETC1_RGB8,
>PIPE_TEXTURE_2D, 0,
>PIPE_BIND_SAMPLER_VIEW);
> + st->has_etc2 = screen->is_format_supported(screen, PIPE_FORMAT_ETC2_RGB8,
> + PIPE_TEXTURE_2D, 0,
> + PIPE_BIND_SAMPLER_VIEW);
> st->prefer_blit_based_texture_transfer = screen->get_param(screen,
>PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER);
>
> diff --git a/src/mesa/state_tracker/st_context.h
> b/src/mesa/state_tracker/st_context.h
> index 20d5678..b091a88 100644
> --- a/src/mesa/state_tracker/st_context.h
> +++ b/src/mesa/state_tracker/st_context.h
> @@ -93,6 +93,7 @@ struct st_context
> boolean has_time_elapsed;
> boolean has_shader_model3;
> boolean has_etc1;
> + boolean has_etc2;
> boolean prefer_blit_based_texture_transfer;
>
> boolean needs_texcoord_semantic;
> diff --git a/src/mesa/state_tracker/st_format.c
> b/src/mesa/state_tracker/st_format.c
> index 66cace1..a68101e 100644
> --- a/src/mesa/state_tracker/st_format.c
> +++ b/src/mesa/state_tracker/st_format.c
> @@ -443,21 +443,25 @@ st_mesa_format_to_pipe_format(struct st_context *st,
> mesa_format mesaFormat)
> * The destination formats mustn't be changed, because they are also
> * destination formats of the unpack/decompression function. */
> case MESA_FORMAT_ETC2_RGB8:
> - case MESA_FORMAT_ETC2_RGBA8_EAC:
> - case MESA_FORMAT_ETC2_RGB8_PUNCHTHROUGH_ALPHA1:
> - return PIPE_FORMAT_R8G8B8A8_UNORM;
> + return st->has_etc2 ? PIPE_FORMAT_ETC2_RGB8 :
> PIPE_FORMAT_R8G8B8A8_UNORM;
> case MESA_FORMAT_ETC2_SRGB8:
> + return st->has_etc2 ? PIPE_FORMAT_ETC2_SRGB8 :
> PIPE_FORMAT_R8G8B8A8_SRGB;
> + case MESA_FORMAT_ETC2_RGBA8_EAC:
> + return st->has_etc2 ? PIPE_FORMAT_ETC2_RGBA8 :
> PIPE_FORMAT_R8G8B8A8_UNORM;
> case MESA_FORMAT_ETC2_SRGB8_ALPHA8_EAC:
> - case MESA_FORMAT_ETC2_SRGB8_PUNCHTHROUGH_ALPHA1:
> - return PIPE_FORMAT_B8G8R8A8_SRGB;
> + return st->has_etc2 ? PIPE_FORMAT_ETC2_SRGBA8 :
> PIPE_FORMAT_R8G8B8A8_SRGB;
> case MESA_FORMAT_ETC2_R11_EAC:
> - return PIPE_FORMAT_R16_UNORM;
> + return st->has_etc2 ? PIPE_FORMAT_ETC2_R11_UNORM :
> PIPE_FORMAT_R16_UNORM;
> case MESA_FORMAT_ETC2_RG11_EAC:
> - return PIPE_FORMAT_R16G16_UNORM;
> + return st->has_etc2 ? PIPE_FORMAT_ETC2_RG11_UNORM :
> PIPE_FORMAT_R16G16_UNORM;
> case MESA_FORMAT_ETC2_SIGNED_R11_EAC:
> - return PIPE_FORMAT_R16_SNORM;
> + return st->has_etc2 ? PIPE_FORMAT_ETC2_R11_SNORM :
> PIPE_FORMAT_R16_SNORM;
> case MESA_FORMAT_ETC2_SIGNED_RG11_EAC:
> - return PIPE_FORMAT_R16G16_SNORM;
> + return st->has_etc2 ? PIPE_FORMAT_ETC2_RG11
Re: [Mesa-dev] [LLVMdev] mesa-10.4.4: BROKEN TLS support in GLXwithllvm-toolchain v3.6.0rc2
Am Montag, 16. Februar 2015, 12:42:19 schrieb Sedat Dilek: > On Mon, Feb 16, 2015 at 10:39 AM, Marc Dietrich wrote: > > Am Samstag, 14. Februar 2015, 18:20:12 schrieb Dimitry Andric: > >> On 11 Feb 2015, at 11:16, Sedat Dilek wrote: > >> > On Wed, Feb 11, 2015 at 12:09 AM, Emil Velikov > >> > > > > > wrote: > >> >> On 10/02/15 13:17, Dimitry Andric wrote: > >> >>> On 09 Feb 2015, at 18:52, Sedat Dilek wrote: > >> On Mon, Feb 9, 2015 at 6:44 PM, Emil Velikov > >> > > > > wrote: > >> > On 07/02/15 22:42, Sedat Dilek wrote: > >> >>> ... > >> >>> > >> >> In file included from ../../src/mapi/entry.c:49: > >> >> ./entry_x86-64_tls.h:66:1: warning: tentative array definition > >> >> assumed > >> >> to have one element > >> >> x86_64_entry_start[]; > >> >> ^ > >> >> fatal error: error in backend: symbol 'x86_64_entry_start' is > >> >> already > >> >> defined>>> > >> >>> > >> >>> ... > >> >>> > >> > It may be that it's a bug on our end, but it's a bit painful going > >> > through all the auto generated sources, the 10+ define guards and > >> > other > >> > magic that's inside src/mapi. Getting some idea on llvm/clang > >> > behaviour > >> > change should help out :-) > >> > > >> > Please open a bug-report with llvm and/or mesa, so that we have all > >> > the > >> > info in one place and things don't get lost. > >> > >> I am unsure if it is a bug in llvm/clang or in mesa. > >> Shall I open 2 bug-reports - in mesa and llvm BTS? > >> >>> > >> >>> Please have a look at this PR, which I opened in May 2014, and which > >> >>> is > > > > about the same issue: > >> >>> http://llvm.org/PR19778 > >> >> > >> >> Hi Dimitry, > >> >> > >> >> From a quick look at the bug, the llvm/clang devs are quoting the C11 > >> >> spec, yet we're not building with -std=c11 so I'm not sure that > >> >> applies. > >> >> Feel free to forward that if interested - I'm a bit short on account > >> >> on > >> >> their bugzilla :-) > >> >> > >> >>> The assertion seems to have been transformed now into a backend > >> >>> error, > >> >>> but this may also be because you built clang without assertions. (Did > >> >>> you?)>>> > >> >>> In any case, the workaround is to change the static symbols into > >> >>> extern > > > > symbols, together with a hidden visibility attribute (as suggested by > > Rafael> > > Espíndola), similar to the fix I posted in this FreeBSD port bug: > >> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192286 > >> >>> > >> >>> E.g., you can use these patches: > >> >>> > >> >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src_ > >> >>> _ma > >> >>> pi__entry_x86-64_tls.h?view=markup > >> >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src_ > >> >>> _m > >> >>> api__entry_x86_tls.h?view=markup > >> >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src_ > >> >>> _m > >> >>> api__entry_x86_tsd.h?view=markup>> > >> >> > >> >> These patches don't look at all bad. Can you give them a bit of TLS > >> >> and > >> >> send them to the list, please ? This also stands for the other patches > >> >> in FreeBSD's repo :-) > >> > > >> > On the one hand I am glad to see that there are patches available. > >> > I will give them a try when I am at home. > >> > On the other hand - knowing FreeBSD switched to llvm/clang as > >> > default-compiler - it's abit pity to see that stuff like this is not > >> > shared with upstream (did not look at the date of submission). > >> > If you have more patches in this area, please share them with upstream. > >> > >> The complete collection is here: > >> > >> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/ > >> > >> I didn't create most of these patches, so I can't really say what the > >> reason for them was, or whether they still apply to Mesa master. > >> > >> In any case, for this specific issue with Mesa's TLS related definitions > >> breaking clang, please consider the attached patch. > > > > I think there is no need to restrict this to clang only as it also works > > with gcc. I submitted a slightly different version to the mesa list which > > uses a macro instead and also adds some credits. > > Sorry for the late response... troubles with my Internet connection. > > Those two patches or do I need more? > > [PATCH 1/4] configure: add visibility macro detection to configure > [PATCH 2/4] add visibility hidden to tls entry points no that's all, sorry I still have two unrelated patches in my HEAD. So this should actually have been /2. 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 1/4] configure: add visibility macro detection to configure
Am Montag, 16. Februar 2015, 10:36:32 schrieb Marc Dietrich: > 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 for anyone who may wonder, these are actually only two patches (1/2 and 2/2). No more patches to follow. 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] i965/vec4: Override destination register writemask in sampler message send.
Hi Ian, Ian Romanick writes: > Please tag the commit with > > Cc: "10.5" > I don't think that's necessary, the commit that caused this regression isn't part of 10.5. > On 02/13/2015 05:03 AM, Francisco Jerez wrote: >> This line was removed by accident in commit >> 16b911257440afbd77a6eb762e28df62e3c19bc7 causing a regression in the >> ES3-CTS.gtf.GL3Tests.shadow.shadow_execution_vert Khronos conformance >> test. It's necessary because the swizzle_result() code below expects >> all four components of the vector to be valid. >> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89094 >> Tested-by: Lu Hua >> Cc: Matt Turner >> --- >> src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp >> b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp >> index 9421786..eb69ebb 100644 >> --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp >> +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp >> @@ -2613,6 +2613,7 @@ vec4_visitor::visit(ir_texture *ir) >>is_high_sampler(brw, sampler_reg); >> inst->base_mrf = 2; >> inst->mlen = inst->header_present + 1; /* always at least one */ >> + inst->dst.writemask = WRITEMASK_XYZW; >> inst->shadow_compare = ir->shadow_comparitor != NULL; >> >> inst->src[1] = sampler_reg; >> pgp3kwDxYbTY9.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89107] [Radeonsi/Hawaii] Rendering errors when running basic opengl 3 demo
https://bugs.freedesktop.org/show_bug.cgi?id=89107 --- Comment #15 from Grigori Goronzy --- The call to glXChooseFBConfig in MicroGlut doesn't specify any attribute list, so a list of all configs is returned by it. Later on, the GLX context i just uses the first returned config, which can be pretty much anything. When I specify a attribute list to get a suitable FB config, it works fine. Other drivers might get away with it because they return the FB configs in a different order, but obviously you can't count on this. -- 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] [PATCH] mesa: do not adjust float format if extension is not enabled
Patch wraps float internal format adjustment inside extension check.
v2: explicitly check for OpenGL ES 2.0 (Ian Romanick)
Signed-off-by: Tapani Pälli
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88907
---
src/mesa/main/teximage.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 29c325b..b8efaef 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -3246,14 +3246,17 @@ teximage(struct gl_context *ctx, GLboolean compressed,
GLuint dims,
/* In case of HALF_FLOAT_OES or FLOAT_OES, find corresponding sized
* internal floating point format for the given base format.
*/
- if (_mesa_is_gles(ctx) && format == internalFormat) {
- if (type == GL_FLOAT) {
-texObj->_IsFloat = GL_TRUE;
- } else if (type == GL_HALF_FLOAT_OES || type == GL_HALF_FLOAT) {
-texObj->_IsHalfFloat = GL_TRUE;
- }
+ if (ctx->Extensions.OES_texture_float ||
+ ctx->Extensions.OES_texture_half_float) {
+ if (ctx->API == API_OPENGLES2 && format == internalFormat) {
+if (type == GL_FLOAT) {
+ texObj->_IsFloat = GL_TRUE;
+} else if (type == GL_HALF_FLOAT_OES || type == GL_HALF_FLOAT) {
+ texObj->_IsHalfFloat = GL_TRUE;
+}
- internalFormat = adjust_for_oes_float_texture(format, type);
+internalFormat = adjust_for_oes_float_texture(format, type);
+ }
}
texFormat = _mesa_choose_texture_format(ctx, texObj, target, level,
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 88907] [PNV Bisected]Ogles2conform ES2-CTS.gtf.GL2ExtensionTests.texture_float.texture_float segfault
https://bugs.freedesktop.org/show_bug.cgi?id=88907 --- Comment #6 from Tapani Pälli --- I've sent updated patch to the list for review. -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 67676] Transparent windows no longer work
https://bugs.freedesktop.org/show_bug.cgi?id=67676 Jonny Lamb changed: What|Removed |Added Attachment #111864|0 |1 is obsolete|| --- Comment #11 from Jonny Lamb --- Created attachment 113529 --> https://bugs.freedesktop.org/attachment.cgi?id=113529&action=edit EGL_MESA_transparent_alpha draft 2 (In reply to Chad Versace from comment #10) > The proposed extension looks like the right approach to me. > > Regarding issue #1, I weakly prefer that it be illegal to specify > EGL_TRANSPARENT_ALPHA for non-window surfaces. I like to emit errors when > the user asks for the impossible. > > Errors I found in the draft: > - It should be a EGL display extension, not an EGL client extension. > - The new symbols must be suffixed with MESA. Thanks for your comments, I've updated the draft and attached it here. What do you think? -- 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] [PATCH 00/16] Direct State Access: TFO, RBO, SO, PPO and QO
This patchset contains the code to implement the following parts of the Direct State Access extension: - Transform Feedback object - Renderbuffer object - Sampler object - Program Pipeline object - Query object This patchset has been tested on the Intel Haswell GPU and tested for non-regression with the current piglit tests on Broadwell, Haswell, Ivy Bridge and Sandy Bridge. To work properly on Haswell+, the transform feedback part requires full ppgtt. The corresponding piglit tests have been posted to the piglit ML. Please test and comment. Martin Peres (16): main: replace tabs by 8 spaces in bufferobj.c main: replace tabs by 8 spaces in fbobject.c main: fix the validation of the number of samples main: Added entry point for glCreateTransformFeedbacks main: Added entry point for glTransformFeedbackBufferBase main: Added entry point for glTransformFeedbackBufferRange main: Added entry point for glGetTransformFeedbackiv main: Added entry point for glGetTransformFeedbacki_v main: Added entry point for glGetTransformFeedbacki64_v main: Added entry point for glCreateQueries main: Added entry points for glGetQueryBufferObject* main: Added entry point for glCreateProgramPipelines main: Added entry point for glCreateSamplers main: Added entry point for glCreateRenderbuffers main: Added entry point for glGetNamedRenderbufferParameteriv main: Added entry points for NamedRenderbufferStorage/Multisample src/mapi/glapi/gen/ARB_direct_state_access.xml | 118 src/mesa/main/bufferobj.c | 10 +- src/mesa/main/fbobject.c | 395 - src/mesa/main/fbobject.h | 16 + src/mesa/main/multisample.c| 9 + src/mesa/main/objectlabel.c| 2 +- src/mesa/main/pipelineobj.c| 35 ++- src/mesa/main/pipelineobj.h| 3 + src/mesa/main/queryobj.c | 131 +++- src/mesa/main/queryobj.h | 14 + src/mesa/main/samplerobj.c | 26 +- src/mesa/main/samplerobj.h | 2 + src/mesa/main/tests/dispatch_sanity.cpp| 17 ++ src/mesa/main/transformfeedback.c | 375 +++ src/mesa/main/transformfeedback.h | 33 ++- src/mesa/vbo/vbo_exec_array.c | 8 +- 16 files changed, 961 insertions(+), 233 deletions(-) -- 2.3.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/16] main: fix the validation of the number of samples
Maybe this should be the job of the dispatch layer.
Signed-off-by: Martin Peres
---
src/mesa/main/multisample.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/main/multisample.c b/src/mesa/main/multisample.c
index 1f3fa0c..a0a659b 100644
--- a/src/mesa/main/multisample.c
+++ b/src/mesa/main/multisample.c
@@ -150,6 +150,15 @@ GLenum
_mesa_check_sample_count(struct gl_context *ctx, GLenum target,
GLenum internalFormat, GLsizei samples)
{
+ /* From the OpenGL core 3.0 spec, section 2.5:
+*
+* "If a negative number is provided where an argument of type sizei or
+* sizeiptr is specified, the error INVALID VALUE is generated."
+*/
+ if (samples < 0) {
+ return GL_INVALID_VALUE;
+ }
+
/* If ARB_internalformat_query is supported, then treat its highest
* returned sample count as the absolute maximum for this format; it is
* allowed to exceed MAX_SAMPLES.
--
2.3.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/16] main: Added entry point for glGetTransformFeedbacki64_v
v2: Review from Laura Ekstrand
- use the transform feedback object lookup wrapper
v3:
- use the new name of _mesa_lookup_transform_feedback_object_err
Signed-off-by: Martin Peres
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 7 ++
src/mesa/main/tests/dispatch_sanity.cpp| 1 +
src/mesa/main/transformfeedback.c | 32 ++
src/mesa/main/transformfeedback.h | 4
4 files changed, 44 insertions(+)
diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index 935e088..340dbba 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -41,6 +41,13 @@
+
+
+
+
+
+
+
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index d5535e9..ad5da83 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -960,6 +960,7 @@ const struct function gl_core_functions_possible[] = {
{ "glTransformFeedbackBufferRange", 45, -1 },
{ "glGetTransformFeedbackiv", 45, -1 },
{ "glGetTransformFeedbacki_v", 45, -1 },
+ { "glGetTransformFeedbacki64_v", 45, -1 },
{ "glCreateTextures", 45, -1 },
{ "glTextureStorage1D", 45, -1 },
{ "glTextureStorage2D", 45, -1 },
diff --git a/src/mesa/main/transformfeedback.c
b/src/mesa/main/transformfeedback.c
index ce9a6d4..0b6d04b 100644
--- a/src/mesa/main/transformfeedback.c
+++ b/src/mesa/main/transformfeedback.c
@@ -1257,3 +1257,35 @@ _mesa_GetTransformFeedbacki_v(GLuint xfb, GLenum pname,
GLuint index,
"glGetTransformFeedbacki_v(pname=%i)", pname);
}
}
+
+extern void GLAPIENTRY
+_mesa_GetTransformFeedbacki64_v(GLuint xfb, GLenum pname, GLuint index,
+ GLint64 *param)
+{
+ struct gl_transform_feedback_object *obj;
+ GET_CURRENT_CONTEXT(ctx);
+
+ obj = lookup_transform_feedback_object_err(ctx, xfb,
+ "glGetTransformFeedbacki64_v");
+ if(!obj) {
+ return;
+ }
+
+ if (index >= ctx->Const.MaxTransformFeedbackBuffers) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "glGetTransformFeedbacki64_v(index=%i)", index);
+ return;
+ }
+
+ switch(pname) {
+ case GL_TRANSFORM_FEEDBACK_BUFFER_START:
+ *param = obj->Offset[index];
+ break;
+ case GL_TRANSFORM_FEEDBACK_BUFFER_SIZE:
+ *param = obj->RequestedSize[index];
+ break;
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ "glGetTransformFeedbacki64_v(pname=%i)", pname);
+ }
+}
diff --git a/src/mesa/main/transformfeedback.h
b/src/mesa/main/transformfeedback.h
index 9936c68..3d21779 100644
--- a/src/mesa/main/transformfeedback.h
+++ b/src/mesa/main/transformfeedback.h
@@ -162,4 +162,8 @@ extern void GLAPIENTRY
_mesa_GetTransformFeedbacki_v(GLuint xfb, GLenum pname, GLuint index,
GLint *param);
+extern void GLAPIENTRY
+_mesa_GetTransformFeedbacki64_v(GLuint xfb, GLenum pname, GLuint index,
+ GLint64 *param);
+
#endif /* TRANSFORM_FEEDBACK_H */
--
2.3.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/16] main: Added entry points for glGetQueryBufferObject*
These entry points will be fleshed out when the GL_ARB_query_buffer_object
extension gets implemented. In the meantime, return GL_INVALID_OPERATION as
suggested by Ian.
Signed-off-by: Martin Peres
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 27 ++
src/mesa/main/queryobj.c | 39 ++
src/mesa/main/queryobj.h | 12
src/mesa/main/tests/dispatch_sanity.cpp| 4 +++
4 files changed, 82 insertions(+)
diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index 652e8bc..99d2422 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -316,5 +316,32 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c
index 1bb74c9..19bc682 100644
--- a/src/mesa/main/queryobj.c
+++ b/src/mesa/main/queryobj.c
@@ -820,6 +820,45 @@ _mesa_GetQueryObjectui64v(GLuint id, GLenum pname,
GLuint64EXT *params)
}
/**
+ * New with GL_ARB_query_buffer_object
+ */
+void GLAPIENTRY
+_mesa_GetQueryBufferObjectiv(GLuint id, GLuint buffer, GLenum pname,
+ GLintptr offset)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ _mesa_error(ctx, GL_INVALID_OPERATION, "glGetQueryBufferObjectiv");
+}
+
+
+void GLAPIENTRY
+_mesa_GetQueryBufferObjectuiv(GLuint id, GLuint buffer, GLenum pname,
+ GLintptr offset)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ _mesa_error(ctx, GL_INVALID_OPERATION, "glGetQueryBufferObjectuiv");
+}
+
+
+void GLAPIENTRY
+_mesa_GetQueryBufferObjecti64v(GLuint id, GLuint buffer, GLenum pname,
+ GLintptr offset)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ _mesa_error(ctx, GL_INVALID_OPERATION, "glGetQueryBufferObjecti64v");
+}
+
+
+void GLAPIENTRY
+_mesa_GetQueryBufferObjectui64v(GLuint id, GLuint buffer, GLenum pname,
+GLintptr offset)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ _mesa_error(ctx, GL_INVALID_OPERATION, "glGetQueryBufferObjectui64v");
+}
+
+
+/**
* Allocate/init the context state related to query objects.
*/
void
diff --git a/src/mesa/main/queryobj.h b/src/mesa/main/queryobj.h
index 431d420..d1036fc 100644
--- a/src/mesa/main/queryobj.h
+++ b/src/mesa/main/queryobj.h
@@ -79,5 +79,17 @@ void GLAPIENTRY
_mesa_GetQueryObjecti64v(GLuint id, GLenum pname, GLint64EXT *params);
void GLAPIENTRY
_mesa_GetQueryObjectui64v(GLuint id, GLenum pname, GLuint64EXT *params);
+void GLAPIENTRY
+_mesa_GetQueryBufferObjectiv(GLuint id, GLuint buffer, GLenum pname,
+ GLintptr offset);
+void GLAPIENTRY
+_mesa_GetQueryBufferObjectuiv(GLuint id, GLuint buffer, GLenum pname,
+ GLintptr offset);
+void GLAPIENTRY
+_mesa_GetQueryBufferObjecti64v(GLuint id, GLuint buffer, GLenum pname,
+ GLintptr offset);
+void GLAPIENTRY
+_mesa_GetQueryBufferObjectui64v(GLuint id, GLuint buffer, GLenum pname,
+GLintptr offset);
#endif /* QUERYOBJ_H */
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index ee448f1..b65080e 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -994,6 +994,10 @@ const struct function gl_core_functions_possible[] = {
{ "glTextureStorage3DMultisample", 45, -1 },
{ "glTextureBuffer", 45, -1 },
{ "glCreateQueries", 45, -1 },
+ { "glGetQueryBufferObjectiv", 45, -1 },
+ { "glGetQueryBufferObjectuiv", 45, -1 },
+ { "glGetQueryBufferObjecti64v", 45, -1 },
+ { "glGetQueryBufferObjectui64v", 45, -1 },
/* GL_EXT_polygon_offset_clamp */
{ "glPolygonOffsetClampEXT", 11, -1 },
--
2.3.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/16] main: replace tabs by 8 spaces in bufferobj.c
Signed-off-by: Martin Peres --- src/mesa/main/queryobj.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c index 932359c..17eaaac 100644 --- a/src/mesa/main/queryobj.c +++ b/src/mesa/main/queryobj.c @@ -616,8 +616,8 @@ _mesa_GetQueryObjectiv(GLuint id, GLenum pname, GLint *params) } break; case GL_QUERY_RESULT_AVAILABLE_ARB: -if (!q->Ready) - ctx->Driver.CheckQuery( ctx, q ); + if (!q->Ready) +ctx->Driver.CheckQuery( ctx, q ); *params = q->Ready; break; default: @@ -667,8 +667,8 @@ _mesa_GetQueryObjectuiv(GLuint id, GLenum pname, GLuint *params) } break; case GL_QUERY_RESULT_AVAILABLE_ARB: -if (!q->Ready) - ctx->Driver.CheckQuery( ctx, q ); + if (!q->Ready) +ctx->Driver.CheckQuery( ctx, q ); *params = q->Ready; break; default: @@ -707,8 +707,8 @@ _mesa_GetQueryObjecti64v(GLuint id, GLenum pname, GLint64EXT *params) *params = q->Result; break; case GL_QUERY_RESULT_AVAILABLE_ARB: -if (!q->Ready) - ctx->Driver.CheckQuery( ctx, q ); + if (!q->Ready) +ctx->Driver.CheckQuery( ctx, q ); *params = q->Ready; break; default: @@ -747,8 +747,8 @@ _mesa_GetQueryObjectui64v(GLuint id, GLenum pname, GLuint64EXT *params) *params = q->Result; break; case GL_QUERY_RESULT_AVAILABLE_ARB: -if (!q->Ready) - ctx->Driver.CheckQuery( ctx, q ); + if (!q->Ready) +ctx->Driver.CheckQuery( ctx, q ); *params = q->Ready; break; default: -- 2.3.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/16] main: Added entry point for glTransformFeedbackBufferRange
v2: review from Laura Ekstrand
- use the refactored code to lookup the objects
- improve some error messages
- factor out the gl method name computation
- better handle the spec differences between the DSA and non-DSA cases
- quote the spec a little more
v3: review from Laura Ekstrand
- use the new name of _mesa_lookup_bufferobj_err
- swap the comments around the offset and size checks
v4: review from Laura Ekstrand
- add more spec quotes
- properly fix the comments around the offset and size checks
Signed-off-by: Martin Peres
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 8 +++
src/mesa/main/bufferobj.c | 3 +-
src/mesa/main/tests/dispatch_sanity.cpp| 1 +
src/mesa/main/transformfeedback.c | 98 +-
src/mesa/main/transformfeedback.h | 6 +-
5 files changed, 97 insertions(+), 19 deletions(-)
diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index 35d6906..b3c090f 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -20,6 +20,14 @@
+
+
+
+
+
+
+
+
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 86532ea..7558e17 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -3548,7 +3548,8 @@ _mesa_BindBufferRange(GLenum target, GLuint index,
case GL_TRANSFORM_FEEDBACK_BUFFER:
_mesa_bind_buffer_range_transform_feedback(ctx,
ctx->TransformFeedback.CurrentObject,
- index, bufObj, offset, size);
+ index, bufObj, offset, size,
+ false);
return;
case GL_UNIFORM_BUFFER:
bind_buffer_range_uniform_buffer(ctx, index, bufObj, offset, size);
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index 183755f..87f7d6f 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -957,6 +957,7 @@ const struct function gl_core_functions_possible[] = {
/* GL_ARB_direct_state_access */
{ "glCreateTransformFeedbacks", 45, -1 },
{ "glTransformFeedbackBufferBase", 45, -1 },
+ { "glTransformFeedbackBufferRange", 45, -1 },
{ "glCreateTextures", 45, -1 },
{ "glTextureStorage1D", 45, -1 },
{ "glTextureStorage2D", 45, -1 },
diff --git a/src/mesa/main/transformfeedback.c
b/src/mesa/main/transformfeedback.c
index d932943..2dded21 100644
--- a/src/mesa/main/transformfeedback.c
+++ b/src/mesa/main/transformfeedback.c
@@ -541,7 +541,8 @@ bind_buffer_range(struct gl_context *ctx,
/**
* Specify a buffer object to receive transform feedback results. Plus,
* specify the starting offset to place the results, and max size.
- * Called from the glBindBufferRange() function.
+ * Called from the glBindBufferRange() and glTransformFeedbackBufferRange
+ * functions.
*/
void
_mesa_bind_buffer_range_transform_feedback(struct gl_context *ctx,
@@ -549,35 +550,74 @@ _mesa_bind_buffer_range_transform_feedback(struct
gl_context *ctx,
GLuint index,
struct gl_buffer_object *bufObj,
GLintptr offset,
- GLsizeiptr size)
+ GLsizeiptr size,
+ bool dsa)
{
+ const char *gl_methd_name;
+ if (dsa)
+ gl_methd_name = "glTransformFeedbackBufferRange";
+ else
+ gl_methd_name = "glBindBufferRange";
+
+
if (obj->Active) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
- "glBindBufferRange(transform feedback active)");
+ _mesa_error(ctx, GL_INVALID_OPERATION, "%s(transform feedback active)",
+ gl_methd_name);
return;
}
if (index >= ctx->Const.MaxTransformFeedbackBuffers) {
- _mesa_error(ctx, GL_INVALID_VALUE, "glBindBufferRange(index=%d "
- "out of bounds)", index);
+ /* OpenGL 4.5 core profile, 6.1, pdf page 82: An INVALID_VALUE error is
+ * generated if index is greater than or equal to the number of binding
+ * points for transform feedback, as described in section 6.7.1.
+ */
+ _mesa_error(ctx, GL_INVALID_VALUE, "%s(index=%d out of bounds)",
+ gl_methd_name, index);
return;
}
if (size & 0x3) {
- /* must a multiple of four */
- _mesa_error(ctx, GL_INVALID_VALUE, "glBindBufferRange(size=%d)",
- (int) size);
+ /* OpenGL 4.5 core profile, 6.7, pdf page 103: multiple of 4 */
+ _mesa_error(ctx, GL_INVALID_VALUE, "%s(size=%d must be a multiple of "
+ "four)", gl_me
[Mesa-dev] [PATCH 05/16] main: Added entry point for glTransformFeedbackBufferBase
v2: Review from Laura Ekstrand
- give more helpful error messages
- factor the lookup code for the xfb and objBuf
- replace some already-existing tabs with spaces
- add comments to explain the cases where xfb == 0 or buffer == 0
- fix the condition for binding the transform buffer or not
v3: Review from Laura Ekstrand
- rename _mesa_lookup_bufferobj_err to
_mesa_lookup_transform_feedback_bufferobj_err and make it static to avoid a
future conflict
- make _mesa_lookup_transform_feedback_object_err static
v4: Review from Laura Ekstrand
- add the pdf page number when quoting the spec
- rename some of the symbols to follow the public/private conventions
Signed-off-by: Martin Peres
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 6 +
src/mesa/main/bufferobj.c | 9 +-
src/mesa/main/objectlabel.c| 2 +-
src/mesa/main/tests/dispatch_sanity.cpp| 1 +
src/mesa/main/transformfeedback.c | 146 +++--
src/mesa/main/transformfeedback.h | 13 ++-
src/mesa/vbo/vbo_exec_array.c | 8 +-
7 files changed, 139 insertions(+), 46 deletions(-)
diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index 15b00c2..35d6906 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -14,6 +14,12 @@
+
+
+
+
+
+
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 0c1ce98..86532ea 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -3546,8 +3546,9 @@ _mesa_BindBufferRange(GLenum target, GLuint index,
switch (target) {
case GL_TRANSFORM_FEEDBACK_BUFFER:
- _mesa_bind_buffer_range_transform_feedback(ctx, index, bufObj,
-offset, size);
+ _mesa_bind_buffer_range_transform_feedback(ctx,
+
ctx->TransformFeedback.CurrentObject,
+ index, bufObj, offset, size);
return;
case GL_UNIFORM_BUFFER:
bind_buffer_range_uniform_buffer(ctx, index, bufObj, offset, size);
@@ -3611,7 +3612,9 @@ _mesa_BindBufferBase(GLenum target, GLuint index, GLuint
buffer)
switch (target) {
case GL_TRANSFORM_FEEDBACK_BUFFER:
- _mesa_bind_buffer_base_transform_feedback(ctx, index, bufObj);
+ _mesa_bind_buffer_base_transform_feedback(ctx,
+
ctx->TransformFeedback.CurrentObject,
+index, bufObj, false);
return;
case GL_UNIFORM_BUFFER:
bind_buffer_base_uniform_buffer(ctx, index, bufObj);
diff --git a/src/mesa/main/objectlabel.c b/src/mesa/main/objectlabel.c
index 78df96b..19a7e59 100644
--- a/src/mesa/main/objectlabel.c
+++ b/src/mesa/main/objectlabel.c
@@ -170,7 +170,7 @@ get_label_pointer(struct gl_context *ctx, GLenum
identifier, GLuint name,
case GL_TRANSFORM_FEEDBACK:
{
struct gl_transform_feedback_object *tfo =
-_mesa_lookup_transform_feedback_object(ctx, name);
+lookup_transform_feedback_object(ctx, name);
if (tfo)
labelPtr = &tfo->Label;
}
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index bf320bf..183755f 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -956,6 +956,7 @@ const struct function gl_core_functions_possible[] = {
/* GL_ARB_direct_state_access */
{ "glCreateTransformFeedbacks", 45, -1 },
+ { "glTransformFeedbackBufferBase", 45, -1 },
{ "glCreateTextures", 45, -1 },
{ "glTextureStorage1D", 45, -1 },
{ "glTextureStorage2D", 45, -1 },
diff --git a/src/mesa/main/transformfeedback.c
b/src/mesa/main/transformfeedback.c
index 10bb6a1..d932943 100644
--- a/src/mesa/main/transformfeedback.c
+++ b/src/mesa/main/transformfeedback.c
@@ -514,22 +514,24 @@ _mesa_EndTransformFeedback(void)
* Helper used by BindBufferRange() and BindBufferBase().
*/
static void
-bind_buffer_range(struct gl_context *ctx, GLuint index,
+bind_buffer_range(struct gl_context *ctx,
+ struct gl_transform_feedback_object *obj,
+ GLuint index,
struct gl_buffer_object *bufObj,
- GLintptr offset, GLsizeiptr size)
+ GLintptr offset, GLsizeiptr size,
+ bool dsa)
{
- struct gl_transform_feedback_object *obj =
- ctx->TransformFeedback.CurrentObject;
-
/* Note: no need to FLUSH_VERTICES or flag NewTransformFeedback, because
* transform feedback buffers can't be changed while transform feedback is
* active.
*/
- /* The general binding point */
- _mesa_reference_buffer_object(ctx,
- &ctx->Tran
[Mesa-dev] [PATCH 16/16] main: Added entry points for NamedRenderbufferStorage/Multisample
Signed-off-by: Martin Peres
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 15 +++
src/mesa/main/fbobject.c | 147 ++---
src/mesa/main/fbobject.h | 9 ++
src/mesa/main/tests/dispatch_sanity.cpp| 2 +
4 files changed, 135 insertions(+), 38 deletions(-)
diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index 144c891..a5fb84b 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -55,6 +55,21 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index c2ea59c..3f079df 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1407,7 +1407,7 @@ create_render_buffers(struct gl_context *ctx, GLsizei n,
GLuint *renderbuffers,
renderbuffers[i] = name;
if (dsa) {
- obj = _mesa_new_renderbuffer(ctx, name);
+ obj = ctx->Driver.NewRenderbuffer(ctx, name);
} else {
obj = &DummyRenderbuffer;
}
@@ -1772,40 +1772,17 @@ invalidate_rb(GLuint key, void *data, void *userData)
/**
- * Helper function used by _mesa_RenderbufferStorage() and
- * _mesa_RenderbufferStorageMultisample().
- * samples will be NO_SAMPLES if called by _mesa_RenderbufferStorage().
+ * Helper function used by renderbuffer_storage_direct() and
+ * renderbuffer_storage_target().
+ * samples will be NO_SAMPLES if called by a non-multisample function.
*/
static void
-renderbuffer_storage(GLenum target, GLenum internalFormat,
- GLsizei width, GLsizei height, GLsizei samples)
+renderbuffer_storage(struct gl_context *ctx, struct gl_renderbuffer *rb,
+ GLenum internalFormat, GLsizei width,
+ GLsizei height, GLsizei samples, const char *func)
{
- const char *func = samples == NO_SAMPLES ?
- "glRenderbufferStorage" : "glRenderbufferStorageMultisample";
- struct gl_renderbuffer *rb;
GLenum baseFormat;
GLenum sample_count_error;
- GET_CURRENT_CONTEXT(ctx);
-
- if (MESA_VERBOSE & VERBOSE_API) {
- if (samples == NO_SAMPLES)
- _mesa_debug(ctx, "%s(%s, %s, %d, %d)\n",
- func,
- _mesa_lookup_enum_by_nr(target),
- _mesa_lookup_enum_by_nr(internalFormat),
- width, height);
- else
- _mesa_debug(ctx, "%s(%s, %s, %d, %d, %d)\n",
- func,
- _mesa_lookup_enum_by_nr(target),
- _mesa_lookup_enum_by_nr(internalFormat),
- width, height, samples);
- }
-
- if (target != GL_RENDERBUFFER_EXT) {
- _mesa_error(ctx, GL_INVALID_ENUM, "%s(target)", func);
- return;
- }
baseFormat = _mesa_base_fbo_format(ctx, internalFormat);
if (baseFormat == 0) {
@@ -1815,12 +1792,14 @@ renderbuffer_storage(GLenum target, GLenum
internalFormat,
}
if (width < 0 || width > (GLsizei) ctx->Const.MaxRenderbufferSize) {
- _mesa_error(ctx, GL_INVALID_VALUE, "%s(width)", func);
+ _mesa_error(ctx, GL_INVALID_VALUE, "%s(invalid width %d)", func,
+ width);
return;
}
if (height < 0 || height > (GLsizei) ctx->Const.MaxRenderbufferSize) {
- _mesa_error(ctx, GL_INVALID_VALUE, "%s(height)", func);
+ _mesa_error(ctx, GL_INVALID_VALUE, "%s(invalid height %d)", func,
+ height);
return;
}
@@ -1832,7 +1811,7 @@ renderbuffer_storage(GLenum target, GLenum internalFormat,
/* check the sample count;
* note: driver may choose to use more samples than what's requested
*/
- sample_count_error = _mesa_check_sample_count(ctx, target,
+ sample_count_error = _mesa_check_sample_count(ctx, GL_RENDERBUFFER,
internalFormat, samples);
if (sample_count_error != GL_NO_ERROR) {
_mesa_error(ctx, sample_count_error, "%s(samples)", func);
@@ -1840,7 +1819,6 @@ renderbuffer_storage(GLenum target, GLenum internalFormat,
}
}
- rb = ctx->CurrentRenderbuffer;
if (!rb) {
_mesa_error(ctx, GL_INVALID_OPERATION, "%s", func);
return;
@@ -1887,6 +1865,75 @@ renderbuffer_storage(GLenum target, GLenum
internalFormat,
}
}
+/**
+ * Helper function used by _mesa_namedRenderbufferStorage*().
+ * samples will be NO_SAMPLES if called by a non-multisample function.
+ */
+static void
+renderbuffer_storage_named(GLuint renderbuffer, GLenum internalFormat,
+ GLsizei width, GLsizei height, GLsizei samples,
+ const char *func)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ if (MESA_VERBOSE & VERBOSE_API) {
+ if (samples == NO_SAMPLES)
+ _mesa_debug(ctx, "%s(%u, %s, %d, %d)\n",
+ func, render
[Mesa-dev] [PATCH 13/16] main: Added entry point for glCreateSamplers
Signed-off-by: Martin Peres
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 7 +++
src/mesa/main/samplerobj.c | 26 --
src/mesa/main/samplerobj.h | 2 ++
src/mesa/main/tests/dispatch_sanity.cpp| 1 +
4 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index 2102e82..db85ea3 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -308,6 +308,13 @@
+
+
+
+
+
+
+
diff --git a/src/mesa/main/samplerobj.c b/src/mesa/main/samplerobj.c
index cadc9cc..5e44ece 100644
--- a/src/mesa/main/samplerobj.c
+++ b/src/mesa/main/samplerobj.c
@@ -181,19 +181,19 @@ _mesa_delete_sampler_object(struct gl_context *ctx,
free(sampObj);
}
-
-void GLAPIENTRY
-_mesa_GenSamplers(GLsizei count, GLuint *samplers)
+static void
+create_samplers(struct gl_context *ctx, GLsizei count, GLuint *samplers,
+bool dsa)
{
- GET_CURRENT_CONTEXT(ctx);
+ const char *func = dsa ? "glCreateSamplers" : "glGenSamplers";
GLuint first;
GLint i;
if (MESA_VERBOSE & VERBOSE_API)
- _mesa_debug(ctx, "glGenSamplers(%d)\n", count);
+ _mesa_debug(ctx, "%s(%d)\n", func, count);
if (count < 0) {
- _mesa_error(ctx, GL_INVALID_VALUE, "glGenSamplers");
+ _mesa_error(ctx, GL_INVALID_VALUE, "%s(n<0)", func);
return;
}
@@ -211,6 +211,20 @@ _mesa_GenSamplers(GLsizei count, GLuint *samplers)
}
}
+void GLAPIENTRY
+_mesa_GenSamplers(GLsizei count, GLuint *samplers)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ create_samplers(ctx, count, samplers, false);
+}
+
+void GLAPIENTRY
+_mesa_CreateSamplers(GLsizei count, GLuint *samplers)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ create_samplers(ctx, count, samplers, true);
+}
+
void GLAPIENTRY
_mesa_DeleteSamplers(GLsizei count, const GLuint *samplers)
diff --git a/src/mesa/main/samplerobj.h b/src/mesa/main/samplerobj.h
index 1bb3193..988b874 100644
--- a/src/mesa/main/samplerobj.h
+++ b/src/mesa/main/samplerobj.h
@@ -80,6 +80,8 @@ _mesa_init_sampler_object_functions(struct dd_function_table
*driver);
void GLAPIENTRY
_mesa_GenSamplers(GLsizei count, GLuint *samplers);
void GLAPIENTRY
+_mesa_CreateSamplers(GLsizei count, GLuint *samplers);
+void GLAPIENTRY
_mesa_DeleteSamplers(GLsizei count, const GLuint *samplers);
GLboolean GLAPIENTRY
_mesa_IsSampler(GLuint sampler);
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index cc2b267..cfbd1a2 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -993,6 +993,7 @@ const struct function gl_core_functions_possible[] = {
{ "glTextureStorage2DMultisample", 45, -1 },
{ "glTextureStorage3DMultisample", 45, -1 },
{ "glTextureBuffer", 45, -1 },
+ { "glCreateSamplers", 45, -1 },
{ "glCreateProgramPipelines", 45, -1 },
{ "glCreateQueries", 45, -1 },
{ "glGetQueryBufferObjectiv", 45, -1 },
--
2.3.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/16] main: Added entry point for glCreateProgramPipelines
Signed-off-by: Martin Peres
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 7 ++
src/mesa/main/pipelineobj.c| 35 +-
src/mesa/main/pipelineobj.h| 3 +++
src/mesa/main/tests/dispatch_sanity.cpp| 1 +
4 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index 99d2422..2102e82 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -308,6 +308,13 @@
+
+
+
+
+
+
+
diff --git a/src/mesa/main/pipelineobj.c b/src/mesa/main/pipelineobj.c
index b713d95..96bf086 100644
--- a/src/mesa/main/pipelineobj.c
+++ b/src/mesa/main/pipelineobj.c
@@ -498,16 +498,18 @@ _mesa_DeleteProgramPipelines(GLsizei n, const GLuint
*pipelines)
* \param n Number of IDs to generate.
* \param pipelines pipeline of \c n locations to store the IDs.
*/
-void GLAPIENTRY
-_mesa_GenProgramPipelines(GLsizei n, GLuint *pipelines)
+static void
+create_program_pipelines(struct gl_context *ctx, GLsizei n, GLuint *pipelines,
+ bool dsa)
{
- GET_CURRENT_CONTEXT(ctx);
-
+ const char *func;
GLuint first;
GLint i;
+ func = dsa ? "glCreateProgramPipelines" : "glGenProgramPipelines";
+
if (n < 0) {
- _mesa_error(ctx, GL_INVALID_VALUE, "glGenProgramPipelines(n<0)");
+ _mesa_error(ctx, GL_INVALID_VALUE, "%s (n<0)", func);
return;
}
@@ -523,16 +525,37 @@ _mesa_GenProgramPipelines(GLsizei n, GLuint *pipelines)
obj = _mesa_new_pipeline_object(ctx, name);
if (!obj) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, "glGenProgramPipelines");
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "%s", func);
return;
}
+ if (dsa) {
+ /* make dsa-allocated objects behave like program objects */
+ obj->EverBound = GL_TRUE;
+ }
+
save_pipeline_object(ctx, obj);
pipelines[i] = first + i;
}
}
+void GLAPIENTRY
+_mesa_GenProgramPipelines(GLsizei n, GLuint *pipelines)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ create_program_pipelines(ctx, n, pipelines, false);
+}
+
+void GLAPIENTRY
+_mesa_CreateProgramPipelines(GLsizei n, GLuint *pipelines)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ create_program_pipelines(ctx, n, pipelines, true);
+}
+
/**
* Determine if ID is the name of an pipeline object.
*
diff --git a/src/mesa/main/pipelineobj.h b/src/mesa/main/pipelineobj.h
index 7285a78..b57bcb9 100644
--- a/src/mesa/main/pipelineobj.h
+++ b/src/mesa/main/pipelineobj.h
@@ -82,6 +82,9 @@ _mesa_DeleteProgramPipelines(GLsizei n, const GLuint
*pipelines);
extern void GLAPIENTRY
_mesa_GenProgramPipelines(GLsizei n, GLuint *pipelines);
+void GLAPIENTRY
+_mesa_CreateProgramPipelines(GLsizei n, GLuint *pipelines);
+
extern GLboolean GLAPIENTRY
_mesa_IsProgramPipeline(GLuint pipeline);
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index b65080e..cc2b267 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -993,6 +993,7 @@ const struct function gl_core_functions_possible[] = {
{ "glTextureStorage2DMultisample", 45, -1 },
{ "glTextureStorage3DMultisample", 45, -1 },
{ "glTextureBuffer", 45, -1 },
+ { "glCreateProgramPipelines", 45, -1 },
{ "glCreateQueries", 45, -1 },
{ "glGetQueryBufferObjectiv", 45, -1 },
{ "glGetQueryBufferObjectuiv", 45, -1 },
--
2.3.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/16] main: Added entry point for glGetTransformFeedbackiv
v2: Review from Laura Ekstrand
- use the transform feedback object lookup wrapper
Signed-off-by: Martin Peres
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 6 ++
src/mesa/main/tests/dispatch_sanity.cpp| 1 +
src/mesa/main/transformfeedback.c | 25 +
src/mesa/main/transformfeedback.h | 3 +++
4 files changed, 35 insertions(+)
diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index b3c090f..1ac4386 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -28,6 +28,12 @@
+
+
+
+
+
+
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index 87f7d6f..ba36d28 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -958,6 +958,7 @@ const struct function gl_core_functions_possible[] = {
{ "glCreateTransformFeedbacks", 45, -1 },
{ "glTransformFeedbackBufferBase", 45, -1 },
{ "glTransformFeedbackBufferRange", 45, -1 },
+ { "glGetTransformFeedbackiv", 45, -1 },
{ "glCreateTextures", 45, -1 },
{ "glTextureStorage1D", 45, -1 },
{ "glTextureStorage2D", 45, -1 },
diff --git a/src/mesa/main/transformfeedback.c
b/src/mesa/main/transformfeedback.c
index 2dded21..9c9cba2 100644
--- a/src/mesa/main/transformfeedback.c
+++ b/src/mesa/main/transformfeedback.c
@@ -1203,3 +1203,28 @@ _mesa_ResumeTransformFeedback(void)
assert(ctx->Driver.ResumeTransformFeedback);
ctx->Driver.ResumeTransformFeedback(ctx, obj);
}
+
+extern void GLAPIENTRY
+_mesa_GetTransformFeedbackiv(GLuint xfb, GLenum pname, GLint *param)
+{
+struct gl_transform_feedback_object *obj;
+GET_CURRENT_CONTEXT(ctx);
+
+obj = lookup_transform_feedback_object_err(ctx, xfb,
+ "glGetTransformFeedbackiv");
+if(!obj) {
+ return;
+}
+
+switch(pname) {
+case GL_TRANSFORM_FEEDBACK_PAUSED:
+ *param = obj->Paused;
+ break;
+case GL_TRANSFORM_FEEDBACK_ACTIVE:
+ *param = obj->Active;
+ break;
+default:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ "glGetTransformFeedbackiv(pname=%i)", pname);
+}
+}
diff --git a/src/mesa/main/transformfeedback.h
b/src/mesa/main/transformfeedback.h
index 6cad766..ba00636 100644
--- a/src/mesa/main/transformfeedback.h
+++ b/src/mesa/main/transformfeedback.h
@@ -155,4 +155,7 @@ extern void GLAPIENTRY
_mesa_TransformFeedbackBufferRange(GLuint xfb, GLuint index, GLuint buffer,
GLintptr offset, GLsizeiptr size);
+extern void GLAPIENTRY
+_mesa_GetTransformFeedbackiv(GLuint xfb, GLenum pname, GLint *param);
+
#endif /* TRANSFORM_FEEDBACK_H */
--
2.3.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 15/16] main: Added entry point for glGetNamedRenderbufferParameteriv
Signed-off-by: Martin Peres
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 6 +++
src/mesa/main/fbobject.c | 53 +++---
src/mesa/main/fbobject.h | 4 ++
src/mesa/main/tests/dispatch_sanity.cpp| 1 +
4 files changed, 50 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 8c9ddbb..144c891 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -55,6 +55,12 @@
+
+
+
+
+
+
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index c93e188..c2ea59c 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1980,22 +1980,15 @@ _es_RenderbufferStorageEXT(GLenum target, GLenum
internalFormat,
}
-void GLAPIENTRY
-_mesa_GetRenderbufferParameteriv(GLenum target, GLenum pname, GLint *params)
+static void
+get_render_buffer_parameteriv(struct gl_context *ctx,
+ struct gl_renderbuffer *rb, GLenum pname,
+ GLint *params, bool dsa)
{
- struct gl_renderbuffer *rb;
- GET_CURRENT_CONTEXT(ctx);
-
- if (target != GL_RENDERBUFFER_EXT) {
- _mesa_error(ctx, GL_INVALID_ENUM,
- "glGetRenderbufferParameterivEXT(target)");
- return;
- }
-
- rb = ctx->CurrentRenderbuffer;
+ const char *func = dsa ? "glGetNamedRenderbufferParameteriv" :
+"glGetRenderbufferParameteriv";
if (!rb) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
- "glGetRenderbufferParameterivEXT");
+ _mesa_error(ctx, GL_INVALID_OPERATION, "%s", func);
return;
}
@@ -2030,9 +2023,41 @@ _mesa_GetRenderbufferParameteriv(GLenum target, GLenum
pname, GLint *params)
/* fallthrough */
default:
_mesa_error(ctx, GL_INVALID_ENUM,
+ "%s(target)", func);
+ return;
+ }
+}
+
+
+void GLAPIENTRY
+_mesa_GetRenderbufferParameteriv(GLenum target, GLenum pname, GLint *params)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ if (target != GL_RENDERBUFFER_EXT) {
+ _mesa_error(ctx, GL_INVALID_ENUM,
"glGetRenderbufferParameterivEXT(target)");
return;
}
+
+ get_render_buffer_parameteriv(ctx, ctx->CurrentRenderbuffer, pname,
+ params, false);
+}
+
+
+void GLAPIENTRY
+_mesa_GetNamedRenderbufferParameteriv(GLuint renderbuffer, GLenum pname,
+ GLint *params)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ struct gl_renderbuffer *rb = _mesa_lookup_renderbuffer(ctx, renderbuffer);
+ if (rb == &DummyRenderbuffer) {
+ /* ID was reserved, but no real renderbuffer object made yet */
+ rb = NULL;
+ }
+
+ get_render_buffer_parameteriv(ctx, rb, pname, params, true);
}
diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h
index 9ab6b0b..b92149b 100644
--- a/src/mesa/main/fbobject.h
+++ b/src/mesa/main/fbobject.h
@@ -137,6 +137,10 @@ extern void GLAPIENTRY
_mesa_GetRenderbufferParameteriv(GLenum target, GLenum pname,
GLint *params);
+void GLAPIENTRY
+_mesa_GetNamedRenderbufferParameteriv(GLuint renderbuffer, GLenum pname,
+ GLint *params);
+
extern GLboolean GLAPIENTRY
_mesa_IsFramebuffer(GLuint framebuffer);
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index 34e52d2..1d7a57e 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -962,6 +962,7 @@ const struct function gl_core_functions_possible[] = {
{ "glGetTransformFeedbacki_v", 45, -1 },
{ "glGetTransformFeedbacki64_v", 45, -1 },
{ "glCreateRenderbuffers", 45, -1 },
+ { "glGetNamedRenderbufferParameteriv", 45, -1 },
{ "glCreateTextures", 45, -1 },
{ "glTextureStorage1D", 45, -1 },
{ "glTextureStorage2D", 45, -1 },
--
2.3.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/16] main: replace tabs by 8 spaces in fbobject.c
Signed-off-by: Martin Peres
---
src/mesa/main/fbobject.c | 166 +++
1 file changed, 83 insertions(+), 83 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 3053622..09c931d 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -212,13 +212,13 @@ get_attachment(struct gl_context *ctx, struct
gl_framebuffer *fb,
*/
i = attachment - GL_COLOR_ATTACHMENT0_EXT;
if (i >= ctx->Const.MaxColorAttachments
- || (i > 0 && ctx->API == API_OPENGLES)) {
-return NULL;
+ || (i > 0 && ctx->API == API_OPENGLES)) {
+ return NULL;
}
return &fb->Attachment[BUFFER_COLOR0 + i];
case GL_DEPTH_STENCIL_ATTACHMENT:
if (!_mesa_is_desktop_gl(ctx) && !_mesa_is_gles3(ctx))
-return NULL;
+ return NULL;
/* fall-through */
case GL_DEPTH_ATTACHMENT_EXT:
return &fb->Attachment[BUFFER_DEPTH];
@@ -1122,28 +1122,28 @@ _mesa_test_framebuffer_completeness(struct gl_context
*ctx,
if (_mesa_is_desktop_gl(ctx) && !ctx->Extensions.ARB_ES2_compatibility) {
/* Check that all DrawBuffers are present */
for (j = 0; j < ctx->Const.MaxDrawBuffers; j++) {
-if (fb->ColorDrawBuffer[j] != GL_NONE) {
- const struct gl_renderbuffer_attachment *att
- = get_attachment(ctx, fb, fb->ColorDrawBuffer[j]);
- assert(att);
- if (att->Type == GL_NONE) {
- fb->_Status = GL_FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER_EXT;
- fbo_incomplete(ctx, "missing drawbuffer", j);
- return;
- }
-}
+ if (fb->ColorDrawBuffer[j] != GL_NONE) {
+const struct gl_renderbuffer_attachment *att
+ = get_attachment(ctx, fb, fb->ColorDrawBuffer[j]);
+assert(att);
+if (att->Type == GL_NONE) {
+ fb->_Status = GL_FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER_EXT;
+ fbo_incomplete(ctx, "missing drawbuffer", j);
+ return;
+}
+ }
}
/* Check that the ReadBuffer is present */
if (fb->ColorReadBuffer != GL_NONE) {
-const struct gl_renderbuffer_attachment *att
- = get_attachment(ctx, fb, fb->ColorReadBuffer);
-assert(att);
-if (att->Type == GL_NONE) {
- fb->_Status = GL_FRAMEBUFFER_INCOMPLETE_READ_BUFFER_EXT;
+ const struct gl_renderbuffer_attachment *att
+= get_attachment(ctx, fb, fb->ColorReadBuffer);
+ assert(att);
+ if (att->Type == GL_NONE) {
+fb->_Status = GL_FRAMEBUFFER_INCOMPLETE_READ_BUFFER_EXT;
fbo_incomplete(ctx, "missing readbuffer", -1);
- return;
-}
+return;
+ }
}
}
@@ -1233,12 +1233,12 @@ bind_renderbuffer(GLenum target, GLuint renderbuffer,
bool allow_user_names)
}
if (!newRb) {
-/* create new renderbuffer object */
-newRb = ctx->Driver.NewRenderbuffer(ctx, renderbuffer);
-if (!newRb) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, "glBindRenderbufferEXT");
- return;
-}
+ /* create new renderbuffer object */
+ newRb = ctx->Driver.NewRenderbuffer(ctx, renderbuffer);
+ if (!newRb) {
+_mesa_error(ctx, GL_OUT_OF_MEMORY, "glBindRenderbufferEXT");
+return;
+ }
ASSERT(newRb->AllocStorage);
_mesa_HashInsert(ctx->Shared->RenderBuffers, renderbuffer, newRb);
newRb->RefCount = 1; /* referenced by hash table */
@@ -1333,9 +1333,9 @@ _mesa_DeleteRenderbuffers(GLsizei n, const GLuint
*renderbuffers)
for (i = 0; i < n; i++) {
if (renderbuffers[i] > 0) {
-struct gl_renderbuffer *rb;
-rb = _mesa_lookup_renderbuffer(ctx, renderbuffers[i]);
-if (rb) {
+ struct gl_renderbuffer *rb;
+ rb = _mesa_lookup_renderbuffer(ctx, renderbuffers[i]);
+ if (rb) {
/* check if deleting currently bound renderbuffer object */
if (rb == ctx->CurrentRenderbuffer) {
/* bind default */
@@ -1368,17 +1368,17 @@ _mesa_DeleteRenderbuffers(GLsizei n, const GLuint
*renderbuffers)
_mesa_detach_renderbuffer(ctx, ctx->ReadBuffer, rb);
}
- /* Remove from hash table immediately, to free the ID.
+/* Remove from hash table immediately, to free the ID.
* But the object will not be freed until it's no longer
* referenced anywhere else.
*/
- _mesa_HashRemove(ctx->Shared->RenderBuffers, renderbuffers[i]);
+_mesa_HashRemove(ctx->Shared->RenderBuffers, renderbuffers[i]);
if (rb != &DummyRenderbuffer) {
/* no longer referenced by hash table */
_mesa_reference_renderbuffer(&rb, NULL);
- }
-}
+}
+ }
[Mesa-dev] [PATCH 14/16] main: Added entry point for glCreateRenderbuffers
Signed-off-by: Martin Peres
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 7 +
src/mesa/main/fbobject.c | 37 +-
src/mesa/main/fbobject.h | 3 +++
src/mesa/main/tests/dispatch_sanity.cpp| 1 +
4 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index db85ea3..8c9ddbb 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -48,6 +48,13 @@
+
+
+
+
+
+
+
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 09c931d..c93e188 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1383,16 +1383,17 @@ _mesa_DeleteRenderbuffers(GLsizei n, const GLuint
*renderbuffers)
}
}
-
-void GLAPIENTRY
-_mesa_GenRenderbuffers(GLsizei n, GLuint *renderbuffers)
+static void
+create_render_buffers(struct gl_context *ctx, GLsizei n, GLuint *renderbuffers,
+ bool dsa)
{
- GET_CURRENT_CONTEXT(ctx);
+ struct gl_renderbuffer *obj;
GLuint first;
GLint i;
if (n < 0) {
- _mesa_error(ctx, GL_INVALID_VALUE, "glGenRenderbuffersEXT(n)");
+ _mesa_error(ctx, GL_INVALID_VALUE, "%s(n<0)",
+ dsa ? "glCreateRenderbuffers" : "glGenRenderbuffers");
return;
}
@@ -1404,14 +1405,36 @@ _mesa_GenRenderbuffers(GLsizei n, GLuint *renderbuffers)
for (i = 0; i < n; i++) {
GLuint name = first + i;
renderbuffers[i] = name;
- /* insert dummy placeholder into hash table */
+
+ if (dsa) {
+ obj = _mesa_new_renderbuffer(ctx, name);
+ } else {
+ obj = &DummyRenderbuffer;
+ }
+ /* insert the object into the hash table */
mtx_lock(&ctx->Shared->Mutex);
- _mesa_HashInsert(ctx->Shared->RenderBuffers, name, &DummyRenderbuffer);
+ _mesa_HashInsert(ctx->Shared->RenderBuffers, name, obj);
mtx_unlock(&ctx->Shared->Mutex);
}
}
+void GLAPIENTRY
+_mesa_GenRenderbuffers(GLsizei n, GLuint *renderbuffers)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ create_render_buffers(ctx, n, renderbuffers, false);
+}
+
+
+void GLAPIENTRY
+_mesa_CreateRenderbuffers(GLsizei n, GLuint *renderbuffers)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ create_render_buffers(ctx, n, renderbuffers, true);
+}
+
+
/**
* Given an internal format token for a render buffer, return the
* corresponding base format (one of GL_RGB, GL_RGBA, GL_STENCIL_INDEX,
diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h
index 77fdef4..9ab6b0b 100644
--- a/src/mesa/main/fbobject.h
+++ b/src/mesa/main/fbobject.h
@@ -115,6 +115,9 @@ extern void GLAPIENTRY
_mesa_GenRenderbuffers(GLsizei n, GLuint *renderbuffers);
extern void GLAPIENTRY
+_mesa_CreateRenderbuffers(GLsizei n, GLuint *renderbuffers);
+
+extern void GLAPIENTRY
_mesa_RenderbufferStorage(GLenum target, GLenum internalformat,
GLsizei width, GLsizei height);
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index cfbd1a2..34e52d2 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -961,6 +961,7 @@ const struct function gl_core_functions_possible[] = {
{ "glGetTransformFeedbackiv", 45, -1 },
{ "glGetTransformFeedbacki_v", 45, -1 },
{ "glGetTransformFeedbacki64_v", 45, -1 },
+ { "glCreateRenderbuffers", 45, -1 },
{ "glCreateTextures", 45, -1 },
{ "glTextureStorage1D", 45, -1 },
{ "glTextureStorage2D", 45, -1 },
--
2.3.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/16] main: Added entry point for glGetTransformFeedbacki_v
v2: Review from Laura Ekstrand
- use the transform feedback object lookup wrapper
v3:
- use the new name of _mesa_lookup_transform_feedback_object_err
Signed-off-by: Martin Peres
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 7 +++
src/mesa/main/tests/dispatch_sanity.cpp| 1 +
src/mesa/main/transformfeedback.c | 29 ++
src/mesa/main/transformfeedback.h | 4
4 files changed, 41 insertions(+)
diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index 1ac4386..935e088 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -34,6 +34,13 @@
+
+
+
+
+
+
+
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index ba36d28..d5535e9 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -959,6 +959,7 @@ const struct function gl_core_functions_possible[] = {
{ "glTransformFeedbackBufferBase", 45, -1 },
{ "glTransformFeedbackBufferRange", 45, -1 },
{ "glGetTransformFeedbackiv", 45, -1 },
+ { "glGetTransformFeedbacki_v", 45, -1 },
{ "glCreateTextures", 45, -1 },
{ "glTextureStorage1D", 45, -1 },
{ "glTextureStorage2D", 45, -1 },
diff --git a/src/mesa/main/transformfeedback.c
b/src/mesa/main/transformfeedback.c
index 9c9cba2..ce9a6d4 100644
--- a/src/mesa/main/transformfeedback.c
+++ b/src/mesa/main/transformfeedback.c
@@ -1228,3 +1228,32 @@ _mesa_GetTransformFeedbackiv(GLuint xfb, GLenum pname,
GLint *param)
"glGetTransformFeedbackiv(pname=%i)", pname);
}
}
+
+extern void GLAPIENTRY
+_mesa_GetTransformFeedbacki_v(GLuint xfb, GLenum pname, GLuint index,
+ GLint *param)
+{
+ struct gl_transform_feedback_object *obj;
+ GET_CURRENT_CONTEXT(ctx);
+
+ obj = lookup_transform_feedback_object_err(ctx, xfb,
+ "glGetTransformFeedbacki_v");
+ if(!obj) {
+ return;
+ }
+
+ if (index >= ctx->Const.MaxTransformFeedbackBuffers) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "glGetTransformFeedbacki_v(index=%i)", index);
+ return;
+ }
+
+ switch(pname) {
+ case GL_TRANSFORM_FEEDBACK_BUFFER_BINDING:
+ *param = obj->BufferNames[index];
+ break;
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ "glGetTransformFeedbacki_v(pname=%i)", pname);
+ }
+}
diff --git a/src/mesa/main/transformfeedback.h
b/src/mesa/main/transformfeedback.h
index ba00636..9936c68 100644
--- a/src/mesa/main/transformfeedback.h
+++ b/src/mesa/main/transformfeedback.h
@@ -158,4 +158,8 @@ _mesa_TransformFeedbackBufferRange(GLuint xfb, GLuint
index, GLuint buffer,
extern void GLAPIENTRY
_mesa_GetTransformFeedbackiv(GLuint xfb, GLenum pname, GLint *param);
+extern void GLAPIENTRY
+_mesa_GetTransformFeedbacki_v(GLuint xfb, GLenum pname, GLuint index,
+ GLint *param);
+
#endif /* TRANSFORM_FEEDBACK_H */
--
2.3.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/16] main: Added entry point for glCreateTransformFeedbacks
v2: Review from Laura Ekstrand
- generate the name of the gl method once
- shorten some lines to stay in the 78 chars limit
v3: Review from Fredrik Höglund
- rename gl_mthd_name to func
- set EverBound in _mesa_create_transform_feedbacks in the dsa case
v4:
- rename _mesa_create_transform_feedbacks to create_transform_feedbacks and
make it static
Signed-off-by: Martin Peres
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 7 +++
src/mesa/main/tests/dispatch_sanity.cpp| 1 +
src/mesa/main/transformfeedback.c | 67 --
src/mesa/main/transformfeedback.h | 3 ++
4 files changed, 63 insertions(+), 15 deletions(-)
diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index 2fe1638..15b00c2 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 @@
+
+
+
+
+
+
+
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index 1f1a3a8..bf320bf 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 */
+ { "glCreateTransformFeedbacks", 45, -1 },
{ "glCreateTextures", 45, -1 },
{ "glTextureStorage1D", 45, -1 },
{ "glTextureStorage2D", 45, -1 },
diff --git a/src/mesa/main/transformfeedback.c
b/src/mesa/main/transformfeedback.c
index a737463..10bb6a1 100644
--- a/src/mesa/main/transformfeedback.c
+++ b/src/mesa/main/transformfeedback.c
@@ -825,25 +825,24 @@ _mesa_lookup_transform_feedback_object(struct gl_context
*ctx, GLuint name)
_mesa_HashLookup(ctx->TransformFeedback.Objects, name);
}
-
-/**
- * Create new transform feedback objects. Transform feedback objects
- * encapsulate the state related to transform feedback to allow quickly
- * switching state (and drawing the results, below).
- * Part of GL_ARB_transform_feedback2.
- */
-void GLAPIENTRY
-_mesa_GenTransformFeedbacks(GLsizei n, GLuint *names)
+static void
+create_transform_feedbacks(struct gl_context *ctx, GLsizei n, GLuint *ids,
+ bool dsa)
{
GLuint first;
- GET_CURRENT_CONTEXT(ctx);
+ const char* func;
+
+ if (dsa)
+ func = "glCreateTransformFeedbacks";
+ else
+ func = "glGenTransformFeedbacks";
if (n < 0) {
- _mesa_error(ctx, GL_INVALID_VALUE, "glGenTransformFeedbacks(n < 0)");
+ _mesa_error(ctx, GL_INVALID_VALUE, "%s(n < 0)", func);
return;
}
- if (!names)
+ if (!ids)
return;
/* we don't need contiguous IDs, but this might be faster */
@@ -854,18 +853,56 @@ _mesa_GenTransformFeedbacks(GLsizei n, GLuint *names)
struct gl_transform_feedback_object *obj
= ctx->Driver.NewTransformFeedback(ctx, first + i);
if (!obj) {
-_mesa_error(ctx, GL_OUT_OF_MEMORY, "glGenTransformFeedbacks");
+_mesa_error(ctx, GL_OUT_OF_MEMORY, "%s", func);
return;
}
- names[i] = first + i;
+ ids[i] = first + i;
_mesa_HashInsert(ctx->TransformFeedback.Objects, first + i, obj);
+ if (dsa) {
+/* this is normally done at bind time in the non-dsa case */
+obj->EverBound = GL_TRUE;
+ }
}
}
else {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, "glGenTransformFeedbacks");
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "%s", func);
}
}
+/**
+ * Create new transform feedback objects. Transform feedback objects
+ * encapsulate the state related to transform feedback to allow quickly
+ * switching state (and drawing the results, below).
+ * Part of GL_ARB_transform_feedback2.
+ */
+void GLAPIENTRY
+_mesa_GenTransformFeedbacks(GLsizei n, GLuint *names)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ /* GenTransformFeedbacks should just reserve the object names that a
+* subsequent call to BindTransformFeedback should actively create. For
+* the sake of simplicity, we reserve the names and create the objects
+* straight away.
+*/
+
+ create_transform_feedbacks(ctx, n, names, false);
+}
+
+/**
+ * Create new transform feedback objects. Transform feedback objects
+ * encapsulate the state related to transform feedback to allow quickly
+ * switching state (and drawing the results, below).
+ * Part of GL_ARB_direct_state_access.
+ */
+void GLAPIENTRY
+_mesa_CreateTransformFeedbacks(GLsizei n, GLuint *names)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ create_transform_feedbacks(ctx, n, names, true);
+}
+
/**
* Is the given ID a transform feedback object?
diff --git a/src/mesa/main/transformfeedback.h
b/src/mesa/main/transformfeedback.h
index 87f4080..9de1fef 100644
--- a/src/mesa/main/transformfeedback.h
+++ b/src/mesa/main/transformfeedback.h
@@ -102,6
[Mesa-dev] [PATCH 10/16] main: Added entry point for glCreateQueries
Signed-off-by: Martin Peres
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 8 +++
src/mesa/main/queryobj.c | 76 +++---
src/mesa/main/queryobj.h | 2 +
src/mesa/main/tests/dispatch_sanity.cpp| 1 +
4 files changed, 80 insertions(+), 7 deletions(-)
diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index 340dbba..652e8bc 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -308,5 +308,13 @@
+
+
+
+
+
+
+
+
diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c
index 17eaaac..1bb74c9 100644
--- a/src/mesa/main/queryobj.c
+++ b/src/mesa/main/queryobj.c
@@ -188,18 +188,22 @@ get_query_binding_point(struct gl_context *ctx, GLenum
target, GLuint index)
}
}
-
-void GLAPIENTRY
-_mesa_GenQueries(GLsizei n, GLuint *ids)
+/**
+ * Create $n query objects and store them in *ids. Make them of type $target
+ * if dsa is set. Called from _mesa_GenQueries() and _mesa_CreateQueries().
+ */
+static void
+create_queries(struct gl_context *ctx, GLenum target, GLsizei n, GLuint *ids,
+ bool dsa)
{
+ const char *func = dsa ? "glGenQueries" : "glCreateQueries";
GLuint first;
- GET_CURRENT_CONTEXT(ctx);
if (MESA_VERBOSE & VERBOSE_API)
- _mesa_debug(ctx, "glGenQueries(%d)\n", n);
+ _mesa_debug(ctx, "%s(%d)\n", func, n);
if (n < 0) {
- _mesa_error(ctx, GL_INVALID_VALUE, "glGenQueriesARB(n < 0)");
+ _mesa_error(ctx, GL_INVALID_VALUE, "%s(n < 0)", func);
return;
}
@@ -210,8 +214,12 @@ _mesa_GenQueries(GLsizei n, GLuint *ids)
struct gl_query_object *q
= ctx->Driver.NewQueryObject(ctx, first + i);
if (!q) {
-_mesa_error(ctx, GL_OUT_OF_MEMORY, "glGenQueriesARB");
+_mesa_error(ctx, GL_OUT_OF_MEMORY, "%s", func);
return;
+ } else if (dsa) {
+/* Do the equivalent of binding the buffer with a target */
+q->Target = target;
+q->EverBound = GL_TRUE;
}
ids[i] = first + i;
_mesa_HashInsert(ctx->Query.QueryObjects, first + i, q);
@@ -219,6 +227,36 @@ _mesa_GenQueries(GLsizei n, GLuint *ids)
}
}
+void GLAPIENTRY
+_mesa_GenQueries(GLsizei n, GLuint *ids)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ create_queries(ctx, 0, n, ids, false);
+}
+
+void GLAPIENTRY
+_mesa_CreateQueries(GLenum target, GLsizei n, GLuint *ids)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ switch (target) {
+ case GL_SAMPLES_PASSED:
+ case GL_ANY_SAMPLES_PASSED:
+ case GL_ANY_SAMPLES_PASSED_CONSERVATIVE:
+ case GL_TIME_ELAPSED:
+ case GL_TIMESTAMP:
+ case GL_PRIMITIVES_GENERATED:
+ case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN:
+ break;
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM, "glCreateQueries(invalid target = %i)",
+ target);
+ return;
+ }
+
+ create_queries(ctx, target, n, ids, true);
+}
+
void GLAPIENTRY
_mesa_DeleteQueries(GLsizei n, const GLuint *ids)
@@ -363,6 +401,18 @@ _mesa_BeginQueryIndexed(GLenum target, GLuint index,
GLuint id)
}
}
+ /* This possibly changes the target of a buffer allocated by
+* CreateQueries. Issue 39) in the ARB_direct_state_access extension states
+* the following:
+*
+* "CreateQueries adds a , so strictly speaking the
+* command isn't needed for BeginQuery/EndQuery, but in the end, this also
+* isn't a selector, so we decided not to change it."
+*
+* Updating the target of the query object should be acceptable, so let's
+* do that.
+*/
+
q->Target = target;
q->Active = GL_TRUE;
q->Result = 0;
@@ -480,6 +530,18 @@ _mesa_QueryCounter(GLuint id, GLenum target)
return;
}
+ /* This possibly changes the target of a buffer allocated by
+* CreateQueries. Issue 39) in the ARB_direct_state_access extension states
+* the following:
+*
+* "CreateQueries adds a , so strictly speaking the
+* command isn't needed for BeginQuery/EndQuery, but in the end, this also
+* isn't a selector, so we decided not to change it."
+*
+* Updating the target of the query object should be acceptable, so let's
+* do that.
+*/
+
q->Target = target;
q->Result = 0;
q->Ready = GL_FALSE;
diff --git a/src/mesa/main/queryobj.h b/src/mesa/main/queryobj.h
index 6cbcabd..431d420 100644
--- a/src/mesa/main/queryobj.h
+++ b/src/mesa/main/queryobj.h
@@ -51,6 +51,8 @@ _mesa_free_queryobj_data(struct gl_context *ctx);
void GLAPIENTRY
_mesa_GenQueries(GLsizei n, GLuint *ids);
void GLAPIENTRY
+_mesa_CreateQueries(GLenum target, GLsizei n, GLuint *ids);
+void GLAPIENTRY
_mesa_DeleteQueries(GLsizei n, const GLuint *ids);
GLboolean GLAPIENTRY
_mesa_IsQuery(GLuint id);
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/me
[Mesa-dev] [Bug 89107] [Radeonsi/Hawaii] Rendering errors when running basic opengl 3 demo
https://bugs.freedesktop.org/show_bug.cgi?id=89107 --- Comment #16 from Sebastian Parborg --- (In reply to Grigori Goronzy from comment #15) > The call to glXChooseFBConfig in MicroGlut doesn't specify any attribute > list, so a list of all configs is returned by it. Later on, the GLX context > i just uses the first returned config, which can be pretty much anything. > When I specify a attribute list to get a suitable FB config, it works fine. > > Other drivers might get away with it because they return the FB configs in a > different order, but obviously you can't count on this. Ah, that makes sense. It works for me now too :) Thank you (and everyone else) for your help! I will inform my professor and hope that he includes the changes so other students doesn't have to run into the same problems as I did. I guess this bug can be closed then? As you said, the order of the returned configs doesn't have to be in any specific order. So I guess the other drivers just got lucky. -- 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] mesa: don't enable NV_fragment_program_option with swrast
Am 16.02.2015 um 00:36 schrieb Matt Turner: > On Sat, Feb 14, 2015 at 2:33 PM, Roland Scheidegger > wrote: >> Am 14.02.2015 um 21:12 schrieb Kenneth Graunke: >>> On Saturday, February 14, 2015 04:37:25 PM srol...@vmware.com wrote: From: Roland Scheidegger Since dropping some NV_fragment_program opcodes (commits 868f95f1da74cf6dd7468cba1b56664aad585ccb, a3688d686f147f4252d19b298ae26d4ac72c2e08) we can no longer parse all opcodes necessary for this extension, leading to bugs (https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D86980&d=AwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=WR7M0CMoTs3KQMrLGbBd33mSg7pYv21Om0yOzq27Swg&s=VVYgQUmxDRQ8b-H-36lfDVGUw4SFuqAVM1qfxbB71pc&e= ). Hence don't announce support for it in swrast. (The rest of the infrastructure ranging from dead opcodes (TXP_NV) to parsing condition codes along with the NV_fragment_program_option variable in the context could probably nuked too this is just a minimal fix appropriate for stable too.) --- src/mesa/main/extensions.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c index 220b220..c94009f 100644 --- a/src/mesa/main/extensions.c +++ b/src/mesa/main/extensions.c @@ -511,7 +511,6 @@ _mesa_enable_sw_extensions(struct gl_context *ctx) ctx->Extensions.NV_point_sprite = GL_TRUE; ctx->Extensions.NV_texture_env_combine4 = GL_TRUE; ctx->Extensions.NV_texture_rectangle = GL_TRUE; - ctx->Extensions.NV_fragment_program_option = GL_TRUE; ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE; ctx->Extensions.OES_standard_derivatives = GL_TRUE; ctx->Extensions.TDFX_texture_compression_FXT1 = GL_TRUE; >>> >>> Nuking this extension would make some compiler work I'm planning to do >>> easier, so I'd definitely be interested to hear whether you still need >>> it. >>> >> >> Well, according to the git log specviewperf11 catia test won't run >> correctly without supporting some bits from NV_program_option and >> NV_fragment_program2 - obviously the benchmark doesn't care one bit if >> the extension is actually officially supported by a driver or not. >> I suspect this is something which we still need to be able to run, >> though Brian would probably know the definitive answer. > > If we knew specifically what it uses, maybe we can just support that > instead of the whole extension? Not having to handle the condition > code bits of the extension would be nice, for instance. > There's definitely some bits around condition codes with IF/ELSE/ENDIF needed (with NV_fp2/NV_vp3 even), though it seems there's some differences to our private code there to make it work. Apart from that I'm not entirely sure. Maybe we could expose it as an ordinary quirk to make things more obvious but I've never dealt with that viewperf issue. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/simd8vs: Fix SIMD8 atomics
On Feb 15, 2015 11:55 PM, "Ben Widawsky"
wrote:
>
> The short version: we need to set bits in R0.7 which provide a mask to be
used
> for PS kill samples/pixels. Since the VS has no such concept, we just
need to
> set all 1.
>
> The longer version...
> Execution for SIMD8 atomics is defined as follows:
> SIMD8: The low 8 bits of the execution mask are ANDed with 8 bits of the
> Pixel/Sample Mask from the message header. For the typed messages, the
Slot
> Group in the message descriptor selects either the low or high 8 bits.
For the
> untyped messages, the low 8 bits are always selected. The resulting mask
is used
> to determine which slots are read into the destination GRF register (for
read),
> or which slots are written to the surface (for write). If the header is
not
> present, only the low 8 bits of the execution mask are used.
>
> The message header for untyped messages is defined in R0.7 "This field
contains
> the 16-bit pixel/sample mask to be used for SIMD16 and SIMD8 messages.
All 16
> bits are used for SIMD16 messages. For typed SIMD8 messages, Slot Group
selects
> which 8 bits of this field are used. For untyped SIMD8 messages, the low
8 bits
> of this field are used." Furthermore, "The message header for the untyped
> messages only needs to be delivered for pixel shader threads, where the
> execution mask may indicate pixels/samples that are enabled only due to
> derivative (LOD) calculations, but the corresponding slot on the surface
must
> not be accessed." We're not using a pixel shader here, but AFAICT, this
mask is
> used for all stages.
>
> This leaves two options, Remove the header, or make the VS code emit the
correct
> thing for the header. I believe one of the goals of using SIMD8 VS was to
get as
> much code reuse as possible, and so I chose the latter. Since the VS has
no such
> thing as kill instructions, the mask is derived simple as all 1's.
Hm. This seems a little fishy. Don't we still have an execution mask for
vertex shaders? The second half of the if copies that into the bit field.
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87258
> Cc: Kristian Høgsberg
> Signed-off-by: Ben Widawsky
> ---
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> index 2a36d94..c20289f 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> @@ -2994,6 +2994,9 @@ fs_visitor::emit_untyped_atomic(unsigned atomic_op,
unsigned surf_index,
> if (uses_kill) {
>emit(MOV(component(sources[0], 7), brw_flag_reg(0, 1)))
> ->force_writemask_all = true;
> + } else if (stage == MESA_SHADER_VERTEX) {
> + emit(MOV(component(sources[0], 7),
> + brw_imm_ud(0xff)))->force_writemask_all = true;
> } else {
>emit(MOV(component(sources[0], 7),
> retype(brw_vec1_grf(1, 7), BRW_REGISTER_TYPE_UD));
Also would you mind rearranging the logic a bit here. Something like this
would make it more clear that the header stuff is only for vertex shaders:
If (fragment) {
If (uses_kill) {
} else {
}
} else {
// vertex stuff
}
> --
> 2.3.0
>
> ___
> 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] i965/simd8vs: Fix SIMD8 atomics
Jason Ekstrand writes:
> On Feb 15, 2015 11:55 PM, "Ben Widawsky"
> wrote:
>>
>> The short version: we need to set bits in R0.7 which provide a mask to be
> used
>> for PS kill samples/pixels. Since the VS has no such concept, we just
> need to
>> set all 1.
>>
>> The longer version...
>> Execution for SIMD8 atomics is defined as follows:
>> SIMD8: The low 8 bits of the execution mask are ANDed with 8 bits of the
>> Pixel/Sample Mask from the message header. For the typed messages, the
> Slot
>> Group in the message descriptor selects either the low or high 8 bits.
> For the
>> untyped messages, the low 8 bits are always selected. The resulting mask
> is used
>> to determine which slots are read into the destination GRF register (for
> read),
>> or which slots are written to the surface (for write). If the header is
> not
>> present, only the low 8 bits of the execution mask are used.
>>
>> The message header for untyped messages is defined in R0.7 "This field
> contains
>> the 16-bit pixel/sample mask to be used for SIMD16 and SIMD8 messages.
> All 16
>> bits are used for SIMD16 messages. For typed SIMD8 messages, Slot Group
> selects
>> which 8 bits of this field are used. For untyped SIMD8 messages, the low
> 8 bits
>> of this field are used." Furthermore, "The message header for the untyped
>> messages only needs to be delivered for pixel shader threads, where the
>> execution mask may indicate pixels/samples that are enabled only due to
>> derivative (LOD) calculations, but the corresponding slot on the surface
> must
>> not be accessed." We're not using a pixel shader here, but AFAICT, this
> mask is
>> used for all stages.
>>
>> This leaves two options, Remove the header, or make the VS code emit the
> correct
>> thing for the header. I believe one of the goals of using SIMD8 VS was to
> get as
>> much code reuse as possible, and so I chose the latter. Since the VS has
> no such
>> thing as kill instructions, the mask is derived simple as all 1's.
>
> Hm. This seems a little fishy. Don't we still have an execution mask for
> vertex shaders? The second half of the if copies that into the bit field.
>
That's fine. 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. What the "second half of
the if" copies is not the execution mask but the sample mask used to
identify helper invocations of the fragment shader executed to
approximate derivatives which are required not to have side effects.
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87258
>> Cc: Kristian Høgsberg
>> Signed-off-by: Ben Widawsky
>> ---
>> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
>> index 2a36d94..c20289f 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
>> @@ -2994,6 +2994,9 @@ fs_visitor::emit_untyped_atomic(unsigned atomic_op,
> unsigned surf_index,
>> if (uses_kill) {
>>emit(MOV(component(sources[0], 7), brw_flag_reg(0, 1)))
>> ->force_writemask_all = true;
>> + } else if (stage == MESA_SHADER_VERTEX) {
>> + emit(MOV(component(sources[0], 7),
>> + brw_imm_ud(0xff)))->force_writemask_all = true;
>> } else {
>>emit(MOV(component(sources[0], 7),
>> retype(brw_vec1_grf(1, 7), BRW_REGISTER_TYPE_UD));
>
> Also would you mind rearranging the logic a bit here. Something like this
> would make it more clear that the header stuff is only for vertex shaders:
>
> If (fragment) {
>If (uses_kill) {
>} else {
>}
> } else {
>// vertex stuff
> }
>
Agreed, I had the same thought when I reviewed this but didn't care
enough to complain. :)
>> --
>> 2.3.0
>>
>> ___
>> 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
pgp7nQpdl7fwu.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 10.5.0 release candidate 1
On 16/02/15 08:43, Maarten Lankhorst wrote: > Hey, > > Op 12-02-15 om 15:24 schreef Emil Velikov: >> Mesa 10.5.0 release candidate 1 is now available for testing. The >> current plan is to have an additional release candidate every Friday >> until the eventual 10.5.0 release on Mar 6th. >> >> The tag in the git repository for Mesa 10.5.0-rc1 is 'mesa-10.5.0-rc1'. >> >> As a reminder, with the 10.5 branch now created, patches nominated with: >> >> CC: >> >> will now be candidates only for the new 10.5 branch. To nominate patches >> for the older 10.4 branch as well, please use: >> >> CC: "10.4 10.5" >> >> The expectation is that the 10.4 branch will remain alive with bi-weekly >> releases until after 10.5.1 release. >> >> Mesa 10.5.0 release candidate 1 is available for download from >> ftp://freedesktop.org/pub/mesa/10.5.0/ >> >> sha256sums: >> >> 6522ff062e8e6a85390bb175e4088e5afa871a90d8aad1ac558ca00ea7a0a0e3 >> mesa-10.5.0-rc1.tar.gz >> 4047cdc87488e7a94ab97a507baa4b91f8f84418445aab47e5b29fe3cc49c4bd >> mesa-10.5.0-rc1.tar.xz >> > All other releases used to be called MesaLib, and had a .zip version > available. Is this an oversight or are the packaging changes permanent? > Hi Maarten, Both of these (plus more as per original message) are deliberate changes. And yes they are permanent. Guess I forgot to mention the latter :-) If people really need the zip archive we can bring it back, but I like to avoid bringing that dinosaur back. Cheers, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] ra: Disable round-robin strategy for optimistically colorable nodes.
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;
int i;
while (progress) {
@@ -483,12 +490,16 @@ ra_simplify(struct ra_graph *g)
if (!progress && best_optimistic_node != ~0U) {
decrement_q(g, best_optimistic_node);
+ stack_optimistic_start =
+MIN2(stack_optimistic_start, g->stack_count);
g->stack[g->stack_count] = best_optimistic_node;
g->stack_count++;
g->nodes[best_optimistic_node].in_stack = true;
progress = true;
}
}
+
+ g->stack_optimistic_start = stack_optimistic_start;
}
/**
@@ -542,7 +553,16 @@ ra_select(struct ra_graph *g)
g->nodes[n].reg = r;
g->stack_count--;
- if (g->regs->round_robin)
+ /* Rotate the starting point except for optimistically colorable nodes.
+ * The likelihood that we will succeed at allocating optimistically
+ * colorable nodes is highly dependent on the way that the previous
+ * nodes popped off the stack are laid out. The round-robin strategy
+ * increases the fragmentation of the register file and decreases the
+ * number of nearby nodes assigned to the same color, what increases the
+ * likelihood of spilling with respect to the dense packing strategy.
+ */
+ if (g->regs->round_robin &&
+ g->stack_count <= g->stack_optimistic_start)
start_search_reg = r + 1;
}
--
2.1.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: don't enable NV_fragment_program_option with swrast
On 02/16/2015 08:11 AM, Roland Scheidegger wrote: Am 16.02.2015 um 00:36 schrieb Matt Turner: On Sat, Feb 14, 2015 at 2:33 PM, Roland Scheidegger wrote: Am 14.02.2015 um 21:12 schrieb Kenneth Graunke: On Saturday, February 14, 2015 04:37:25 PM srol...@vmware.com wrote: From: Roland Scheidegger Since dropping some NV_fragment_program opcodes (commits 868f95f1da74cf6dd7468cba1b56664aad585ccb, a3688d686f147f4252d19b298ae26d4ac72c2e08) we can no longer parse all opcodes necessary for this extension, leading to bugs (https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D86980&d=AwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=WR7M0CMoTs3KQMrLGbBd33mSg7pYv21Om0yOzq27Swg&s=VVYgQUmxDRQ8b-H-36lfDVGUw4SFuqAVM1qfxbB71pc&e= ). Hence don't announce support for it in swrast. (The rest of the infrastructure ranging from dead opcodes (TXP_NV) to parsing condition codes along with the NV_fragment_program_option variable in the context could probably nuked too this is just a minimal fix appropriate for stable too.) --- src/mesa/main/extensions.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c index 220b220..c94009f 100644 --- a/src/mesa/main/extensions.c +++ b/src/mesa/main/extensions.c @@ -511,7 +511,6 @@ _mesa_enable_sw_extensions(struct gl_context *ctx) ctx->Extensions.NV_point_sprite = GL_TRUE; ctx->Extensions.NV_texture_env_combine4 = GL_TRUE; ctx->Extensions.NV_texture_rectangle = GL_TRUE; - ctx->Extensions.NV_fragment_program_option = GL_TRUE; ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE; ctx->Extensions.OES_standard_derivatives = GL_TRUE; ctx->Extensions.TDFX_texture_compression_FXT1 = GL_TRUE; Nuking this extension would make some compiler work I'm planning to do easier, so I'd definitely be interested to hear whether you still need it. Well, according to the git log specviewperf11 catia test won't run correctly without supporting some bits from NV_program_option and NV_fragment_program2 - obviously the benchmark doesn't care one bit if the extension is actually officially supported by a driver or not. Just to clarify, this is because the viewperf tests are basically application traces which get replayed, and unfortunately, viewperf doesn't even bother to check if the OpenGL driver supports the extensions which are used by the trace. The traces were created with nvidia drivers. I suspect this is something which we still need to be able to run, though Brian would probably know the definitive answer. If we knew specifically what it uses, maybe we can just support that instead of the whole extension? Not having to handle the condition code bits of the extension would be nice, for instance. There's definitely some bits around condition codes with IF/ELSE/ENDIF needed (with NV_fp2/NV_vp3 even), though it seems there's some differences to our private code there to make it work. Apart from that I'm not entirely sure. Maybe we could expose it as an ordinary quirk to make things more obvious but I've never dealt with that viewperf issue. Here's an example of a fragment program from the catia-03 #3 test: !!ARBfp1.0 OPTION NV_fragment_program2; # cgc version 1.5.0023, build date Sep 26 2007 08:51:03 # command line args: #vendor NVIDIA Corporation #version 1.5.0.23 #profile fp40 #program AdvancedHighlightPS #semantic AdvancedHighlightPS.iOutlineColor #semantic AdvancedHighlightPS.iHaloSize #semantic AdvancedHighlightPS.iHaloIntensity #semantic AdvancedHighlightPS.iHaloColor #semantic AdvancedHighlightPS.iScanEffectIntensity #semantic AdvancedHighlightPS.iScanEffectColor #semantic AdvancedHighlightPS.iInputTexture #semantic outlineColor #semantic haloColor #semantic haloIntensity #semantic haloSize #semantic scanEffectColor #semantic scanEffectIntensity #semantic inputTexture #semantic filterBlurData #semantic filterBlurDataLow #var float4 IN.ScreenPosition : $vin.TEXCOORD0 : TEX0 : 0 : 1 #var float4 iOutlineColor : : c[0] : 1 : 1 #var float iHaloSize : : c[1] : 2 : 1 #var float iHaloIntensity : : c[2] : 3 : 1 #var float4 iHaloColor : : c[3] : 4 : 1 #var float iScanEffectIntensity : : : 5 : 0 #var float4 iScanEffectColor : : c[4] : 6 : 1 #var samplerRECT iInputTexture : : texunit 0 : 7 : 1 #var float4 outlineColor : : : -1 : 0 #var float4 haloColor : : : -1 : 0 #var float haloIntensity : : : -1 : 0 #var float haloSize : : : -1 : 0 #var float4 scanEffectColor : : : -1 : 0 #var float scanEffectIntensity : : : -1 : 0 #var samplerRECT inputTexture : : : -1 : 0 #var float2 filterBlurData[0] : : c[5] : -1 : 1 #var float2 filterBlurData[1] : : c[6] : -1 : 1 #var float2 filterBlurData[2] : : c[7] : -1 : 1 #var float2 filterBlurData[3] : : c[8] : -1 : 1 #var float2 filterBlurData[4] : : c[9] : -1 : 1 #var float2 filterBlurData[5] : : c[10] : -1 : 1 #var float2 filterBlurData[6] :
Re: [Mesa-dev] [PATCH] ra: Disable round-robin strategy for optimistically colorable nodes.
On Feb 16, 2015 8:35 AM, "Francisco Jerez" 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.
Actually, that's not true. Matt was doing some experiments recently with a
noise shader from synmark and the difference between our 2nd and 3rd choice
schedulers is huge. In that test he disabled the third choice scheduler
and the result was a shader that spilled 6 or 8 times but ran something
like 30% faster. We really need to do some more experimentation with
scheduling and figure out better heuristics than "SIMD16 is always faster"
and "spilling is bad".
> 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;
> int i;
>
> while (progress) {
> @@ -483,12 +490,16 @@ ra_simplify(struct ra_graph *g)
>
>if (!progress && best_optimistic_node != ~0U) {
> decrement_q(g, best_optimistic_node);
> + stack_optimistic_start =
> +MIN2(stack_optimistic_start, g->stack_count);
> g->stack[g->stack_count] = best_optimistic_node;
> g->stack_count++;
> g->nodes[best_optimistic_node].in_stack = true;
> progress = true;
>}
> }
> +
> + g->stack_optimistic_start = stack_optimistic_start;
> }
>
> /**
> @@ -542,7 +553,16 @@ ra_select(struct ra_graph *g)
>g->nodes[n].reg = r;
>g->stack_count--;
>
> - if (g->regs->round_robin)
> + /* Rotate the starting point except for optimistically colorable
nodes.
> + * The likelihood that we will succeed at allocating optimistically
> + * colorable nodes is highly dependent on the way that the previous
> + * nodes popped off the stack are laid out. The round-robin
strategy
> + * increases the fragmentation of the register file and decreases
the
> + * number of nearby nodes assigned to the same color, what
increases the
> + * likelihood of spilling with respect to the dense packing
strategy.
> + */
> + if (g->regs->round_robin &&
> + g->stack_count <= g->stack_optimistic_start)
> start_search_reg = r + 1;
> }
>
> --
> 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] [PATCH] i965/simd8vs: Fix SIMD8 atomics
On Feb 16, 2015 7:46 AM, "Francisco Jerez" wrote:
>
> Jason Ekstrand writes:
>
> > On Feb 15, 2015 11:55 PM, "Ben Widawsky"
> > wrote:
> >>
> >> The short version: we need to set bits in R0.7 which provide a mask to
be
> > used
> >> for PS kill samples/pixels. Since the VS has no such concept, we just
> > need to
> >> set all 1.
> >>
> >> The longer version...
> >> Execution for SIMD8 atomics is defined as follows:
> >> SIMD8: The low 8 bits of the execution mask are ANDed with 8 bits of
the
> >> Pixel/Sample Mask from the message header. For the typed messages, the
> > Slot
> >> Group in the message descriptor selects either the low or high 8 bits.
> > For the
> >> untyped messages, the low 8 bits are always selected. The resulting
mask
> > is used
> >> to determine which slots are read into the destination GRF register
(for
> > read),
> >> or which slots are written to the surface (for write). If the header is
> > not
> >> present, only the low 8 bits of the execution mask are used.
> >>
> >> The message header for untyped messages is defined in R0.7 "This field
> > contains
> >> the 16-bit pixel/sample mask to be used for SIMD16 and SIMD8 messages.
> > All 16
> >> bits are used for SIMD16 messages. For typed SIMD8 messages, Slot
Group
> > selects
> >> which 8 bits of this field are used. For untyped SIMD8 messages, the
low
> > 8 bits
> >> of this field are used." Furthermore, "The message header for the
untyped
> >> messages only needs to be delivered for pixel shader threads, where the
> >> execution mask may indicate pixels/samples that are enabled only due to
> >> derivative (LOD) calculations, but the corresponding slot on the
surface
> > must
> >> not be accessed." We're not using a pixel shader here, but AFAICT, this
> > mask is
> >> used for all stages.
> >>
> >> This leaves two options, Remove the header, or make the VS code emit
the
> > correct
> >> thing for the header. I believe one of the goals of using SIMD8 VS was
to
> > get as
> >> much code reuse as possible, and so I chose the latter. Since the VS
has
> > no such
> >> thing as kill instructions, the mask is derived simple as all 1's.
> >
> > Hm. This seems a little fishy. Don't we still have an execution mask for
> > vertex shaders? The second half of the if copies that into the bit
field.
> >
>
> That's fine. 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. What the "second half of
> the if" copies is not the execution mask but the sample mask used to
> identify helper invocations of the fragment shader executed to
> approximate derivatives which are required not to have side effects.
Good enough for me. With the control flow change below,
Reviewed-by: Jason Ekstrand
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87258
> >> Cc: Kristian Høgsberg
> >> Signed-off-by: Ben Widawsky
> >> ---
> >> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> > b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> >> index 2a36d94..c20289f 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> >> +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> >> @@ -2994,6 +2994,9 @@ fs_visitor::emit_untyped_atomic(unsigned
atomic_op,
> > unsigned surf_index,
> >> if (uses_kill) {
> >>emit(MOV(component(sources[0], 7), brw_flag_reg(0, 1)))
> >> ->force_writemask_all = true;
> >> + } else if (stage == MESA_SHADER_VERTEX) {
> >> + emit(MOV(component(sources[0], 7),
> >> + brw_imm_ud(0xff)))->force_writemask_all = true;
> >> } else {
> >>emit(MOV(component(sources[0], 7),
> >> retype(brw_vec1_grf(1, 7), BRW_REGISTER_TYPE_UD));
> >
> > Also would you mind rearranging the logic a bit here. Something like
this
> > would make it more clear that the header stuff is only for vertex
shaders:
> >
> > If (fragment) {
> >If (uses_kill) {
> >} else {
> >}
> > } else {
> >// vertex stuff
> > }
> >
>
> Agreed, I had the same thought when I reviewed this but didn't care
> enough to complain. :)
>
> >> --
> >> 2.3.0
> >>
> >> ___
> >> 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 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.
Jason Ekstrand writes:
> On Feb 16, 2015 8:35 AM, "Francisco Jerez" 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.
>
> Actually, that's not true. Matt was doing some experiments recently with a
> noise shader from synmark and the difference between our 2nd and 3rd choice
> schedulers is huge. In that test he disabled the third choice scheduler
> and the result was a shader that spilled 6 or 8 times but ran something
> like 30% faster. We really need to do some more experimentation with
> scheduling and figure out better heuristics than "SIMD16 is always faster"
> and "spilling is bad".
>
Yes, I'm aware of rare corner cases like that where e.g. SIMD16 leads to
higher cache thrashing than SIMD8 leading to decreased overall
performance, and a case where a shader SIMD16 *with* spills has better
performance than the SIMD8 version of the same shader without spills.
In any case it's not the register allocator's business to implement such
heuristics, and that's not an argument against the register allocator
trying to make a more efficient use of the register file.
>> 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;
>> int i;
>>
>> while (progress) {
>> @@ -483,12 +490,16 @@ ra_simplify(struct ra_graph *g)
>>
>>if (!progress && best_optimistic_node != ~0U) {
>> decrement_q(g, best_optimistic_node);
>> + stack_optimistic_start =
>> +MIN2(stack_optimistic_start, g->stack_count);
>> g->stack[g->stack_count] = best_optimistic_node;
>> g->stack_count++;
>> g->nodes[best_optimistic_node].in_stack = true;
>> progress = true;
>>}
>> }
>> +
>> + g->stack_optimistic_start = stack_optimistic_start;
>> }
>>
>> /**
>> @@ -542,7 +553,16 @@ ra_select(struct ra_graph *g)
>>g->nodes[n].reg = r;
>>g->stack_count--;
>>
>> - if (g->regs->round_robin)
>> + /* Rotate the starting point except for optimistically colorable
> nodes.
>> + * The likelihood that we will succeed at allocating optimistically
>> + * colorable nodes is highly dependent on the way that the previous
>> + * nodes popped off the stack are laid out. The round-robin
> strategy
>> + * increases the fragmentation of the register file and decreases
> the
>> + * number of nearby nodes assigned to the same color, what
> increases the
>> + * likelihood of spilling with respect to the dense packing
> strategy.
>> + */
>> + if (g->regs->round_robin &&
>> + g->stack_count <= g->stack_optimistic_start)
>> start_search_reg = r + 1;
>> }
>>
>> --
>> 2.1.3
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
pgpRJS927TVjv.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:mesa 1/4] Remove extraneous ; after DECL_TYPE usage
Series looks good to me. Reviewed-by: Brian Paul On 02/15/2015 07:41 PM, Alan Coopersmith wrote: The macro is defined to provide a trailing ; so this caused the expansion to end in ";;" which made the Solaris Studio compilers issue warnings for every line of: "builtin_type_macros.h", line 113: Warning: extra ";" ignored. for every file that included the header, filling build logs with thousands of useless warnings. Signed-off-by: Alan Coopersmith --- src/glsl/builtin_type_macros.h | 66 1 file changed, 33 insertions(+), 33 deletions(-) diff --git a/src/glsl/builtin_type_macros.h b/src/glsl/builtin_type_macros.h index 236e1ce..7a21801 100644 --- a/src/glsl/builtin_type_macros.h +++ b/src/glsl/builtin_type_macros.h @@ -110,39 +110,39 @@ DECL_TYPE(sampler2DRectShadow, GL_SAMPLER_2D_RECT_SHADOW,GLSL_TYPE_SA DECL_TYPE(samplerExternalOES, GL_SAMPLER_EXTERNAL_OES, GLSL_TYPE_SAMPLER, GLSL_SAMPLER_DIM_EXTERNAL, 0, 0, GLSL_TYPE_FLOAT) -DECL_TYPE(image1D, GL_IMAGE_1D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_1D, 0, 0, GLSL_TYPE_FLOAT); -DECL_TYPE(image2D, GL_IMAGE_2D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_2D, 0, 0, GLSL_TYPE_FLOAT); -DECL_TYPE(image3D, GL_IMAGE_3D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_3D, 0, 0, GLSL_TYPE_FLOAT); -DECL_TYPE(image2DRect, GL_IMAGE_2D_RECT, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_RECT, 0, 0, GLSL_TYPE_FLOAT); -DECL_TYPE(imageCube, GL_IMAGE_CUBE, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_CUBE, 0, 0, GLSL_TYPE_FLOAT); -DECL_TYPE(imageBuffer, GL_IMAGE_BUFFER, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_BUF,0, 0, GLSL_TYPE_FLOAT); -DECL_TYPE(image1DArray,GL_IMAGE_1D_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_1D, 0, 1, GLSL_TYPE_FLOAT); -DECL_TYPE(image2DArray,GL_IMAGE_2D_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_2D, 0, 1, GLSL_TYPE_FLOAT); -DECL_TYPE(imageCubeArray, GL_IMAGE_CUBE_MAP_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_CUBE, 0, 1, GLSL_TYPE_FLOAT); -DECL_TYPE(image2DMS, GL_IMAGE_2D_MULTISAMPLE, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_MS, 0, 0, GLSL_TYPE_FLOAT); -DECL_TYPE(image2DMSArray, GL_IMAGE_2D_MULTISAMPLE_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_MS, 0, 1, GLSL_TYPE_FLOAT); -DECL_TYPE(iimage1D,GL_INT_IMAGE_1D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_1D, 0, 0, GLSL_TYPE_INT); -DECL_TYPE(iimage2D,GL_INT_IMAGE_2D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_2D, 0, 0, GLSL_TYPE_INT); -DECL_TYPE(iimage3D,GL_INT_IMAGE_3D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_3D, 0, 0, GLSL_TYPE_INT); -DECL_TYPE(iimage2DRect,GL_INT_IMAGE_2D_RECT, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_RECT, 0, 0, GLSL_TYPE_INT); -DECL_TYPE(iimageCube, GL_INT_IMAGE_CUBE, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_CUBE, 0, 0, GLSL_TYPE_INT); -DECL_TYPE(iimageBuffer,GL_INT_IMAGE_BUFFER, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_BUF,0, 0, GLSL_TYPE_INT); -DECL_TYPE(iimage1DArray, GL_INT_IMAGE_1D_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_1D, 0, 1, GLSL_TYPE_INT); -DECL_TYPE(iimage2DArray, GL_INT_IMAGE_2D_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_2D, 0, 1, GLSL_TYPE_INT); -DECL_TYPE(iimageCubeArray, GL_INT_IMAGE_CUBE_MAP_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_CUBE, 0, 1, GLSL_TYPE_INT); -DECL_TYPE(iimage2DMS, GL_INT_IMAGE_2D_MULTISAMPLE, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_MS, 0, 0, GLSL_TYPE_INT); -DECL_TYPE(iimage2DMSArray, GL_INT_IMAGE_2D_MULTISAMPLE_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_MS, 0, 1, GLSL_TYPE_INT); -DECL_TYPE(uimage1D,GL_UNSIGNED_INT_IMAGE_1D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_1D, 0, 0, GLSL_TYPE_UINT); -DECL_TYPE(uimage2D,GL_UNSIGNED_INT_IMAGE_2D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_2D, 0, 0, GLSL_TYPE_UINT); -DECL_TYPE(uimage3D,GL_UNSIGNED_INT_IMAGE_3D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_3D, 0, 0, GLSL_TYPE_UINT); -DECL_TYPE(uimage2DRect,GL_UNSIGNED_INT_IMAGE_2D_RECT, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_RECT, 0, 0, GLSL_TYPE_UINT); -DECL_TYPE(uimageCube, GL_UNSIGNED_INT_IMAGE_CUBE, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_CUBE, 0, 0, GLSL_TYPE_UINT); -DECL_TYPE(uimageBuffer,GL_UNSIGNED_INT_IMAGE_BUFFER, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_BUF,0, 0, GLSL_TYPE_UINT); -DECL_TYPE(uimage1DArray, GL_UNSIGNED_INT_IMAGE_1D_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_1D
Re: [Mesa-dev] [PATCH] ra: Disable round-robin strategy for optimistically colorable nodes.
On Feb 16, 2015 9:34 AM, "Francisco Jerez" wrote:
>
> Jason Ekstrand writes:
>
> > On Feb 16, 2015 8:35 AM, "Francisco Jerez"
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.
> >
> > Actually, that's not true. Matt was doing some experiments recently
with a
> > noise shader from synmark and the difference between our 2nd and 3rd
choice
> > schedulers is huge. In that test he disabled the third choice scheduler
> > and the result was a shader that spilled 6 or 8 times but ran something
> > like 30% faster. We really need to do some more experimentation with
> > scheduling and figure out better heuristics than "SIMD16 is always
faster"
> > and "spilling is bad".
> >
>
> Yes, I'm aware of rare corner cases like that where e.g. SIMD16 leads to
> higher cache thrashing than SIMD8 leading to decreased overall
> performance, and a case where a shader SIMD16 *with* spills has better
> performance than the SIMD8 version of the same shader without spills.
>
> In any case it's not the register allocator's business to implement such
> heuristics, and that's not an argument against the register allocator
> trying to make a more efficient use of the register file.
The primary point I was trying to make is that scheduling *does* matter.
It matters a lot. In fact, Matt and i have talked about throwing away the
SIMD16 program if it ends up using the pessimal schedulong algorithm.
Throwing scheduling to the wind just to gain a few SIMD16 programs is
probably not a good trade-off.
It could be that this is an good idea, but it's going to take more than
hand-waved theories about register allocation one shader not spilling to
convince me. Do you actually know what it did to scheduling? It wouldn't
be hard to hack up the driver and shader-db to collect that information.
--Jason
> >> 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;
> >> int i;
> >>
> >> while (progress) {
> >> @@ -483,12 +490,16 @@ ra_simplify(struct ra_graph *g)
> >>
> >>if (!progress && best_optimistic_node != ~0U) {
> >> decrement_q(g, best_optimistic_node);
> >> + stack_optimistic_start =
> >> +MIN2(stack_optimistic_start, g->stack_count);
> >> g->stack[g->stack_count] = best_optimistic_node;
> >> g->stack_count++;
> >> g->nodes[best_optimistic_node].in_stack = true;
> >> progress = true;
> >>}
> >> }
> >> +
> >> + g->stack_optimistic_start = stack_optimistic_start;
> >> }
> >>
> >> /**
> >> @@ -542,7 +553,16 @@ ra_select(struct ra_graph *g)
> >>g->nodes[n].reg = r;
> >>g->stack_count--;
> >>
> >> - if (g->regs->round_robin)
> >> + /* Rotate the starting point except for optimistically colorable
> > nodes.
> >> + * The likelihood that we will succeed at allocating
optimistically
> >> + * colorable nodes is highly dependent on the way that the
previous
> >> + * nodes popped off the stack are laid out. The round-robin
> >
Re: [Mesa-dev] [PATCH] mesa: don't enable NV_fragment_program_option with swrast
Am 16.02.2015 18:13, schrieb Brian Paul: On 02/16/2015 08:11 AM, Roland Scheidegger wrote: Am 16.02.2015 um 00:36 schrieb Matt Turner: On Sat, Feb 14, 2015 at 2:33 PM, Roland Scheidegger wrote: Am 14.02.2015 um 21:12 schrieb Kenneth Graunke: On Saturday, February 14, 2015 04:37:25 PM srol...@vmware.com wrote: From: Roland Scheidegger Since dropping some NV_fragment_program opcodes (commits 868f95f1da74cf6dd7468cba1b56664aad585ccb, a3688d686f147f4252d19b298ae26d4ac72c2e08) we can no longer parse all opcodes necessary for this extension, leading to bugs (https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D86980&d=AwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=WR7M0CMoTs3KQMrLGbBd33mSg7pYv21Om0yOzq27Swg&s=VVYgQUmxDRQ8b-H-36lfDVGUw4SFuqAVM1qfxbB71pc&e= ). Hence don't announce support for it in swrast. (The rest of the infrastructure ranging from dead opcodes (TXP_NV) to parsing condition codes along with the NV_fragment_program_option variable in the context could probably nuked too this is just a minimal fix appropriate for stable too.) --- src/mesa/main/extensions.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c index 220b220..c94009f 100644 --- a/src/mesa/main/extensions.c +++ b/src/mesa/main/extensions.c @@ -511,7 +511,6 @@ _mesa_enable_sw_extensions(struct gl_context *ctx) ctx->Extensions.NV_point_sprite = GL_TRUE; ctx->Extensions.NV_texture_env_combine4 = GL_TRUE; ctx->Extensions.NV_texture_rectangle = GL_TRUE; - ctx->Extensions.NV_fragment_program_option = GL_TRUE; ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE; ctx->Extensions.OES_standard_derivatives = GL_TRUE; ctx->Extensions.TDFX_texture_compression_FXT1 = GL_TRUE; Nuking this extension would make some compiler work I'm planning to do easier, so I'd definitely be interested to hear whether you still need it. Well, according to the git log specviewperf11 catia test won't run correctly without supporting some bits from NV_program_option and NV_fragment_program2 - obviously the benchmark doesn't care one bit if the extension is actually officially supported by a driver or not. Just to clarify, this is because the viewperf tests are basically application traces which get replayed, and unfortunately, viewperf doesn't even bother to check if the OpenGL driver supports the extensions which are used by the trace. The traces were created with nvidia drivers. I suspect this is something which we still need to be able to run, though Brian would probably know the definitive answer. If we knew specifically what it uses, maybe we can just support that instead of the whole extension? Not having to handle the condition code bits of the extension would be nice, for instance. There's definitely some bits around condition codes with IF/ELSE/ENDIF needed (with NV_fp2/NV_vp3 even), though it seems there's some differences to our private code there to make it work. Apart from that I'm not entirely sure. Maybe we could expose it as an ordinary quirk to make things more obvious but I've never dealt with that viewperf issue. Here's an example of a fragment program from the catia-03 #3 test: !!ARBfp1.0 OPTION NV_fragment_program2; # cgc version 1.5.0023, build date Sep 26 2007 08:51:03 # command line args: #vendor NVIDIA Corporation #version 1.5.0.23 #profile fp40 #program AdvancedHighlightPS #semantic AdvancedHighlightPS.iOutlineColor #semantic AdvancedHighlightPS.iHaloSize #semantic AdvancedHighlightPS.iHaloIntensity #semantic AdvancedHighlightPS.iHaloColor #semantic AdvancedHighlightPS.iScanEffectIntensity #semantic AdvancedHighlightPS.iScanEffectColor #semantic AdvancedHighlightPS.iInputTexture #semantic outlineColor #semantic haloColor #semantic haloIntensity #semantic haloSize #semantic scanEffectColor #semantic scanEffectIntensity #semantic inputTexture #semantic filterBlurData #semantic filterBlurDataLow #var float4 IN.ScreenPosition : $vin.TEXCOORD0 : TEX0 : 0 : 1 #var float4 iOutlineColor : : c[0] : 1 : 1 #var float iHaloSize : : c[1] : 2 : 1 #var float iHaloIntensity : : c[2] : 3 : 1 #var float4 iHaloColor : : c[3] : 4 : 1 #var float iScanEffectIntensity : : : 5 : 0 #var float4 iScanEffectColor : : c[4] : 6 : 1 #var samplerRECT iInputTexture : : texunit 0 : 7 : 1 #var float4 outlineColor : : : -1 : 0 #var float4 haloColor : : : -1 : 0 #var float haloIntensity : : : -1 : 0 #var float haloSize : : : -1 : 0 #var float4 scanEffectColor : : : -1 : 0 #var float scanEffectIntensity : : : -1 : 0 #var samplerRECT inputTexture : : : -1 : 0 #var float2 filterBlurData[0] : : c[5] : -1 : 1 #var float2 filterBlurData[1] : : c[6] : -1 : 1 #var float2 filterBlurData[2] : : c[7] : -1 : 1 #var float2 filterBlurData[3] : : c[8] : -1 : 1 #var float2 filterBlurData[4] : : c[9] : -1 : 1 #var float2 filterBlurData[5
Re: [Mesa-dev] [PATCH] mesa: don't enable NV_fragment_program_option with swrast
On Mon, Feb 16, 2015 at 9:59 AM, Dieter Nützel wrote: > Sorry that I step in but what about GL_NV_vertex_program* in general? > There are several Mesa-demos (e.g. in tests) which do not work any longer. > > mesa-demos/tests> ./vptest1 > Sorry, this program requires GL_NV_vertex_program That sounds like the tail wagging the dog. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] configure: add visibility macro detection to configure
On Mon, Feb 16, 2015 at 1:36 AM, Marc Dietrich 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
> ---
> 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..6b1592f 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])
This hunk looks fine.
>
> 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
> -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
> + CFLAGS="$CFLAGS -fvisibility=hidden"
> + CXXFLAGS="$CXXFLAGS -fvisibility=hidden"
> +fi
I was going to suggest not making this change when I thought this was
a nop, but this is just wrong. :)
You shouldn't modify CFLAGS/CXXFLAGS in configure, and even if we were
(and removing VISIBILITY_CFLAGS) we should have removed
VISIBILITY_CFLAGS from all of the places its used in Makefiles.
>
> # 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
> +
This hunk looks fine.
> #ifdef HAVE_FUNC_ATTRIBUTE_MALLOC
> #define MALLOCLIKE __attribute__((__malloc__))
> #else
> --
> 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
Re: [Mesa-dev] [PATCH] ra: Disable round-robin strategy for optimistically colorable nodes.
Hi Francisco,
A few comments:
1) This is just a difference in definitions, but to me an
optimistically-colored node is a node that we pushed onto the stack
without knowing whether we could color it or not. There may be (and
most certainly are) nodes above the optimistically-colored node on the
stack that we know we can color, so I wouldn't call those
optimistically colored even though they probably have the
characteristics you mentioned. The distinction is useful since the
optimistically colored nodes are those which we may have to spill.
2) Given the above, what you're doing here is disabling the
round-robin strategy for the nodes above the lowest
optimistically-colored node as well as the lowest
optimistically-colored node itself. But you don't need to disable
round-robin for the lowest optimistically-colored node itself, since
once we're able to find a register (any register!) for that one, we
know we'll be able to find a register for everything else that's left,
so it doesn't really matter which register we start searching at.
3) Usually, there are a series of registers that are pushed onto the
stack optimistically until we can go back to the normal strategy, and
it's one of the registers in the middle of the stack we fail to place,
so we don't need to disable round-robin for *all* the optimistically
colored nodes, only everything above the node that would've failed to
allocate. Another way to think of it is that when I changed the
handling of optimistic coloring a while ago, we gained ~150 SIMD16
shaders. So of the >200 SIMD16 shaders that we optimistically color
but still successfully allocate after your patch, only 50 -- less than
a quarter -- actually need to have round-robin disabled. This is just
an idea, but maybe we could handle this similarly to how we handle
spilling: first, try ra_select() using round-robin all the way, and
only when it fails do we disable round-robin for everything above the
thing that we failed to allocate and try ra_select() again. We would
keep doing this until disabling round-robin wouldn't make a
difference.
On Mon, Feb 16, 2015 at 11:39 AM, Francisco Jerez 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;
> int i;
>
> while (progress) {
> @@ -483,12 +490,16 @@ ra_simplify(struct ra_graph *g)
>
>if (!progress && best_optimistic_node != ~0U) {
> decrement_q(g, best_optimistic_node);
> + stack_optimistic_start =
> +MIN2(stack_optimistic_start, g->stack_count);
> g->stack[g->stack_count] = best_optimistic_node;
> g->stack_count++;
> g->nodes[best_optimistic_node].in_stack = true;
> progress = true;
>}
> }
> +
> + g->stack_optimistic_start = stack_optimistic_start;
> }
>
> /**
> @@ -542,7 +553,16 @@ ra_select(struct ra_graph *g)
>g->nodes[n].reg = r;
>g->stack_count--;
>
> - if (g->regs->round_robin)
> + /* Rotate the starting point except for optimistically colorable nodes.
> + * The likelihood that we will succeed at allocating optimistically
> +
[Mesa-dev] [PATCH] auxiliary/vl: Build vl_winsys_dri.c only when needed.
With commit c39dbfdd0f7(auxiliary/vl: bring back the VL code for the dri targets) we did not fully consider users of dri-swrast alone. Thus we ended up trying to compile the dri2 specific code on platform which lack it - Cygwin for example. Cc: "10.5" Cc: Jon TURNEY Reported-by: Jon TURNEY Signed-off-by: Emil Velikov --- Hi Jon, Can you give this patch a try. I realise it's longer solution than the one you sent, but imho this makes sense (in a way) considering all the craziness that we have around. -Emil configure.ac | 10 +- src/gallium/auxiliary/Makefile.am | 4 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 351027b..65425cb 100644 --- a/configure.ac +++ b/configure.ac @@ -1577,11 +1577,19 @@ if test "x$enable_dri" = xyes -o \ "x$enable_vdpau" = xyes -o \ "x$enable_omx" = xyes -o \ "x$enable_va" = xyes; then -PKG_CHECK_MODULES([VL], [x11-xcb xcb xcb-dri2 >= $XCBDRI2_REQUIRED]) need_gallium_vl=yes fi AM_CONDITIONAL(NEED_GALLIUM_VL, test "x$need_gallium_vl" = xyes) +if test "x$enable_xvmc" = xyes -o \ +"x$enable_vdpau" = xyes -o \ +"x$enable_omx" = xyes -o \ +"x$enable_va" = xyes; then +PKG_CHECK_MODULES([VL], [x11-xcb xcb xcb-dri2 >= $XCBDRI2_REQUIRED]) +need_gallium_vl_winsys=yes +fi +AM_CONDITIONAL(NEED_GALLIUM_VL_WINSYS, test "x$need_gallium_vl_winsys" = xyes) + if test "x$enable_xvmc" = xyes; then PKG_CHECK_MODULES([XVMC], [xvmc >= $XVMC_REQUIRED]) enable_gallium_loader=$enable_shared_pipe_drivers diff --git a/src/gallium/auxiliary/Makefile.am b/src/gallium/auxiliary/Makefile.am index 453282a..6a628e9 100644 --- a/src/gallium/auxiliary/Makefile.am +++ b/src/gallium/auxiliary/Makefile.am @@ -74,6 +74,8 @@ libgalliumvl_la_CFLAGS = \ libgalliumvl_la_SOURCES = \ $(VL_SOURCES) +if NEED_GALLIUM_VL_WINSYS + noinst_LTLIBRARIES += libgalliumvlwinsys.la libgalliumvlwinsys_la_CFLAGS = \ @@ -84,6 +86,8 @@ libgalliumvlwinsys_la_SOURCES = \ endif +endif + EXTRA_DIST = \ SConscript \ indices/u_indices.c \ -- 2.1.3 ___ 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
On Mon, Feb 16, 2015 at 1:36 AM, Marc Dietrich wrote:
> Avoid redefined symbol errors in clang. Based on a suggestion from
> Rafael à vila de EspÃndola in
> http://llvm.org/bugs/show_bug.cgi?id=19778.
>
> Signed-off-by: Marc Dietrich
> ---
> 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?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] swrast: fix multiple color buffer writing
If a fragment program wrote to more than one color buffer, the
first fragment color got replicated to all dest buffers. This
fixes 5 piglit FBO tests, including fbo-drawbuffers-arbfp.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45348
Cc: "10.4, 10.5"
---
src/mesa/swrast/s_span.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/src/mesa/swrast/s_span.c b/src/mesa/swrast/s_span.c
index caea673..321959d 100644
--- a/src/mesa/swrast/s_span.c
+++ b/src/mesa/swrast/s_span.c
@@ -933,19 +933,19 @@ clamp_colors(SWspan *span)
* \param output which fragment program color output is being processed
*/
static inline void
-convert_color_type(SWspan *span, GLenum newType, GLuint output)
+convert_color_type(SWspan *span, GLenum srcType, GLenum newType, GLuint output)
{
GLvoid *src, *dst;
- if (output > 0 || span->array->ChanType == GL_FLOAT) {
+ if (output > 0 || srcType == GL_FLOAT) {
src = span->array->attribs[VARYING_SLOT_COL0 + output];
span->array->ChanType = GL_FLOAT;
}
- else if (span->array->ChanType == GL_UNSIGNED_BYTE) {
+ else if (srcType == GL_UNSIGNED_BYTE) {
src = span->array->rgba8;
}
else {
- ASSERT(span->array->ChanType == GL_UNSIGNED_SHORT);
+ ASSERT(srcType == GL_UNSIGNED_SHORT);
src = span->array->rgba16;
}
@@ -979,7 +979,7 @@ shade_texture_span(struct gl_context *ctx, SWspan *span)
ctx->ATIFragmentShader._Enabled) {
/* programmable shading */
if (span->primitive == GL_BITMAP && span->array->ChanType != GL_FLOAT) {
- convert_color_type(span, GL_FLOAT, 0);
+ convert_color_type(span, span->array->ChanType, GL_FLOAT, 0);
}
else {
span->array->rgba = (void *) span->array->attribs[VARYING_SLOT_COL0];
@@ -1314,6 +1314,8 @@ _swrast_write_rgba_span( struct gl_context *ctx, SWspan
*span)
const GLboolean multiFragOutputs =
_swrast_use_fragment_program(ctx)
&& fp->Base.OutputsWritten >= (1 << FRAG_RESULT_DATA0);
+ /* Save srcColorType because convert_color_type() can change it */
+ const GLenum srcColorType = span->array->ChanType;
GLuint buf;
for (buf = 0; buf < numBuffers; buf++) {
@@ -1325,17 +1327,18 @@ _swrast_write_rgba_span( struct gl_context *ctx, SWspan
*span)
/* re-use one of the attribute array buffers for rgbaSave */
GLchan (*rgbaSave)[4] = (GLchan (*)[4]) span->array->attribs[0];
struct swrast_renderbuffer *srb = swrast_renderbuffer(rb);
-GLenum colorType = srb->ColorType;
+const GLenum dstColorType = srb->ColorType;
-assert(colorType == GL_UNSIGNED_BYTE ||
- colorType == GL_FLOAT);
+assert(dstColorType == GL_UNSIGNED_BYTE ||
+ dstColorType == GL_FLOAT);
/* set span->array->rgba to colors for renderbuffer's datatype */
-if (span->array->ChanType != colorType) {
- convert_color_type(span, colorType, 0);
+if (srcColorType != dstColorType) {
+ convert_color_type(span, srcColorType, dstColorType,
+ multiFragOutputs ? buf : 0);
}
else {
- if (span->array->ChanType == GL_UNSIGNED_BYTE) {
+ if (srcColorType == GL_UNSIGNED_BYTE) {
span->array->rgba = span->array->rgba8;
}
else {
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] mesa: remove unused _math_trans_4chan()
---
src/mesa/math/m_translate.c | 21 -
src/mesa/math/m_translate.h | 10 --
2 files changed, 31 deletions(-)
diff --git a/src/mesa/math/m_translate.c b/src/mesa/math/m_translate.c
index 0b8c858..3a8ca74 100644
--- a/src/mesa/math/m_translate.c
+++ b/src/mesa/math/m_translate.c
@@ -30,7 +30,6 @@
#include "main/glheader.h"
#include "main/macros.h"
-#include "main/mtypes.h" /* GLchan hack */
#include "m_translate.h"
@@ -676,26 +675,6 @@ void _math_trans_4ub(GLubyte (*to)[4],
}
/**
- * Translate vector of values to GLchan [4].
- */
-void _math_trans_4chan( GLchan (*to)[4],
- const void *ptr,
- GLuint stride,
- GLenum type,
- GLuint size,
- GLuint start,
- GLuint n )
-{
-#if CHAN_TYPE == GL_UNSIGNED_BYTE
- _math_trans_4ub( to, ptr, stride, type, size, start, n );
-#elif CHAN_TYPE == GL_UNSIGNED_SHORT
- _math_trans_4us( to, ptr, stride, type, size, start, n );
-#elif CHAN_TYPE == GL_FLOAT
- _math_trans_4fn( to, ptr, stride, type, size, start, n );
-#endif
-}
-
-/**
* Translate vector of values to GLushort [4].
*/
void _math_trans_4us(GLushort (*to)[4],
diff --git a/src/mesa/math/m_translate.h b/src/mesa/math/m_translate.h
index 250921a..bdfa4c7 100644
--- a/src/mesa/math/m_translate.h
+++ b/src/mesa/math/m_translate.h
@@ -28,8 +28,6 @@
#include "main/compiler.h"
#include "main/glheader.h"
-#include "main/mtypes.h" /* hack for GLchan */
-#include "swrast/s_chan.h"
/**
* Array translation.
@@ -76,14 +74,6 @@ extern void _math_trans_4ub(GLubyte (*to)[4],
GLuint start,
GLuint n );
-extern void _math_trans_4chan( GLchan (*to)[4],
- const void *ptr,
- GLuint stride,
- GLenum type,
- GLuint size,
- GLuint start,
- GLuint n );
-
extern void _math_trans_4us(GLushort (*to)[4],
const void *ptr,
GLuint stride,
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/simd8vs: Fix SIMD8 atomics
On Mon, Feb 16, 2015 at 09:24:34AM -0800, Jason Ekstrand wrote:
> On Feb 16, 2015 7:46 AM, "Francisco Jerez" wrote:
> >
> > Jason Ekstrand writes:
> >
> > > On Feb 15, 2015 11:55 PM, "Ben Widawsky"
> > > wrote:
> > >>
> > >> The short version: we need to set bits in R0.7 which provide a mask to
> be
> > > used
> > >> for PS kill samples/pixels. Since the VS has no such concept, we just
> > > need to
> > >> set all 1.
> > >>
> > >> The longer version...
> > >> Execution for SIMD8 atomics is defined as follows:
> > >> SIMD8: The low 8 bits of the execution mask are ANDed with 8 bits of
> the
> > >> Pixel/Sample Mask from the message header. For the typed messages, the
> > > Slot
> > >> Group in the message descriptor selects either the low or high 8 bits.
> > > For the
> > >> untyped messages, the low 8 bits are always selected. The resulting
> mask
> > > is used
> > >> to determine which slots are read into the destination GRF register
> (for
> > > read),
> > >> or which slots are written to the surface (for write). If the header is
> > > not
> > >> present, only the low 8 bits of the execution mask are used.
> > >>
> > >> The message header for untyped messages is defined in R0.7 "This field
> > > contains
> > >> the 16-bit pixel/sample mask to be used for SIMD16 and SIMD8 messages.
> > > All 16
> > >> bits are used for SIMD16 messages. For typed SIMD8 messages, Slot
> Group
> > > selects
> > >> which 8 bits of this field are used. For untyped SIMD8 messages, the
> low
> > > 8 bits
> > >> of this field are used." Furthermore, "The message header for the
> untyped
> > >> messages only needs to be delivered for pixel shader threads, where the
> > >> execution mask may indicate pixels/samples that are enabled only due to
> > >> derivative (LOD) calculations, but the corresponding slot on the
> surface
> > > must
> > >> not be accessed." We're not using a pixel shader here, but AFAICT, this
> > > mask is
> > >> used for all stages.
> > >>
> > >> This leaves two options, Remove the header, or make the VS code emit
> the
> > > correct
> > >> thing for the header. I believe one of the goals of using SIMD8 VS was
> to
> > > get as
> > >> much code reuse as possible, and so I chose the latter. Since the VS
> has
> > > no such
> > >> thing as kill instructions, the mask is derived simple as all 1's.
> > >
> > > Hm. This seems a little fishy. Don't we still have an execution mask for
> > > vertex shaders? The second half of the if copies that into the bit
> field.
> > >
> >
> > That's fine. 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. What the "second half of
> > the if" copies is not the execution mask but the sample mask used to
> > identify helper invocations of the fragment shader executed to
> > approximate derivatives which are required not to have side effects.
>
> Good enough for me. With the control flow change below,
>
> Reviewed-by: Jason Ekstrand
>
Hi. Thanks for asking this, it reminded me that I should throw a comment in the
code as well - it took me a few hours to track down all the relevant parts of
the docs, and this commit message is a bit dense (and that was after several
hours to roughly figure out what was going on).
Thanks to the both of you. I will make the requested change.
> > >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87258
> > >> Cc: Kristian Høgsberg
> > >> Signed-off-by: Ben Widawsky
> > >> ---
> > >> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 3 +++
> > >> 1 file changed, 3 insertions(+)
> > >>
> > >> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> > > b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> > >> index 2a36d94..c20289f 100644
> > >> --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> > >> +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> > >> @@ -2994,6 +2994,9 @@ fs_visitor::emit_untyped_atomic(unsigned
> atomic_op,
> > > unsigned surf_index,
> > >> if (uses_kill) {
> > >>emit(MOV(component(sources[0], 7), brw_flag_reg(0, 1)))
> > >> ->force_writemask_all = true;
> > >> + } else if (stage == MESA_SHADER_VERTEX) {
> > >> + emit(MOV(component(sources[0], 7),
> > >> + brw_imm_ud(0xff)))->force_writemask_all = true;
> > >> } else {
> > >>emit(MOV(component(sources[0], 7),
> > >> retype(brw_vec1_grf(1, 7), BRW_REGISTER_TYPE_UD));
> > >
> > > Also would you mind rearranging the logic a bit here. Something like
> this
> > > would make it more clear that the header stuff is only for vertex
> shaders:
> > >
> > > If (fragment) {
> > >If (uses_kill) {
> > >} else {
> > >}
> > > } else {
> > >// vertex stuff
> > > }
> > >
> >
> > Agreed, I had the same thought when I reviewed this but didn't care
> > enough to complain. :)
> >
> > >> --
>
Re: [Mesa-dev] [PATCH 1/2] mesa: remove unused _math_trans_4chan()
Looks to be dead since: commit 588225770c60834dfd2a95850435cc549167dc05 Author: Keith Whitwell Date: Mon Jan 5 15:24:53 2004 + Beef up t_vertex.c: - cope with input vectors with size less than that of the emitted attribute. - cope with vertices with 'holes' inside and between vertices. Fix calculation of tnl->render_inputs to work with fp programs. Mirror VB->PointSizePtr in VB->AttribPtr so that it can work with t_vertex.c. Transition swrast_setup/ to use t_vertex.c to build swrast vertices. Wow. Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/simd8vs: Fix SIMD8 atomics
On Mon, Feb 16, 2015 at 10:28 AM, Ben Widawsky wrote:
> On Mon, Feb 16, 2015 at 09:24:34AM -0800, Jason Ekstrand wrote:
> > On Feb 16, 2015 7:46 AM, "Francisco Jerez"
> wrote:
> > >
> > > Jason Ekstrand writes:
> > >
> > > > On Feb 15, 2015 11:55 PM, "Ben Widawsky" <
> benjamin.widaw...@intel.com>
> > > > wrote:
> > > >>
> > > >> The short version: we need to set bits in R0.7 which provide a mask
> to
> > be
> > > > used
> > > >> for PS kill samples/pixels. Since the VS has no such concept, we
> just
> > > > need to
> > > >> set all 1.
> > > >>
> > > >> The longer version...
> > > >> Execution for SIMD8 atomics is defined as follows:
> > > >> SIMD8: The low 8 bits of the execution mask are ANDed with 8 bits of
> > the
> > > >> Pixel/Sample Mask from the message header. For the typed messages,
> the
> > > > Slot
> > > >> Group in the message descriptor selects either the low or high 8
> bits.
> > > > For the
> > > >> untyped messages, the low 8 bits are always selected. The resulting
> > mask
> > > > is used
> > > >> to determine which slots are read into the destination GRF register
> > (for
> > > > read),
> > > >> or which slots are written to the surface (for write). If the
> header is
> > > > not
> > > >> present, only the low 8 bits of the execution mask are used.
> > > >>
> > > >> The message header for untyped messages is defined in R0.7 "This
> field
> > > > contains
> > > >> the 16-bit pixel/sample mask to be used for SIMD16 and SIMD8
> messages.
> > > > All 16
> > > >> bits are used for SIMD16 messages. For typed SIMD8 messages, Slot
> > Group
> > > > selects
> > > >> which 8 bits of this field are used. For untyped SIMD8 messages, the
> > low
> > > > 8 bits
> > > >> of this field are used." Furthermore, "The message header for the
> > untyped
> > > >> messages only needs to be delivered for pixel shader threads, where
> the
> > > >> execution mask may indicate pixels/samples that are enabled only
> due to
> > > >> derivative (LOD) calculations, but the corresponding slot on the
> > surface
> > > > must
> > > >> not be accessed." We're not using a pixel shader here, but AFAICT,
> this
> > > > mask is
> > > >> used for all stages.
> > > >>
> > > >> This leaves two options, Remove the header, or make the VS code emit
> > the
> > > > correct
> > > >> thing for the header. I believe one of the goals of using SIMD8 VS
> was
> > to
> > > > get as
> > > >> much code reuse as possible, and so I chose the latter. Since the VS
> > has
> > > > no such
> > > >> thing as kill instructions, the mask is derived simple as all 1's.
> > > >
> > > > Hm. This seems a little fishy. Don't we still have an execution mask
> for
> > > > vertex shaders? The second half of the if copies that into the bit
> > field.
> > > >
> > >
> > > That's fine. 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. What the "second half
> of
> > > the if" copies is not the execution mask but the sample mask used to
> > > identify helper invocations of the fragment shader executed to
> > > approximate derivatives which are required not to have side effects.
> >
> > Good enough for me. With the control flow change below,
> >
> > Reviewed-by: Jason Ekstrand
> >
>
> Hi. Thanks for asking this, it reminded me that I should throw a comment
> in the
> code as well - it took me a few hours to track down all the relevant parts
> of
> the docs, and this commit message is a bit dense (and that was after
> several
> hours to roughly figure out what was going on).
>
Yeah, I like comments in code better than in commit messages. That way you
see it when you read it rather than having to do git archeology.
> Thanks to the both of you. I will make the requested change.
>
> > > >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87258
> > > >> Cc: Kristian Høgsberg
> > > >> Signed-off-by: Ben Widawsky
> > > >> ---
> > > >> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 3 +++
> > > >> 1 file changed, 3 insertions(+)
> > > >>
> > > >> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> > > > b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> > > >> index 2a36d94..c20289f 100644
> > > >> --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> > > >> +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> > > >> @@ -2994,6 +2994,9 @@ fs_visitor::emit_untyped_atomic(unsigned
> > atomic_op,
> > > > unsigned surf_index,
> > > >> if (uses_kill) {
> > > >>emit(MOV(component(sources[0], 7), brw_flag_reg(0, 1)))
> > > >> ->force_writemask_all = true;
> > > >> + } else if (stage == MESA_SHADER_VERTEX) {
> > > >> + emit(MOV(component(sources[0], 7),
> > > >> + brw_imm_ud(0xff)))->force_writemask_all = true;
> > > >> } else {
> > > >>emit(MOV(component(sources[0], 7),
> > > >>
Re: [Mesa-dev] [PATCH] ra: Disable round-robin strategy for optimistically colorable nodes.
Jason Ekstrand writes:
> On Feb 16, 2015 9:34 AM, "Francisco Jerez" wrote:
>>
>> Jason Ekstrand writes:
>>
>> > On Feb 16, 2015 8:35 AM, "Francisco Jerez"
> 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.
>> >
>> > Actually, that's not true. Matt was doing some experiments recently
> with a
>> > noise shader from synmark and the difference between our 2nd and 3rd
> choice
>> > schedulers is huge. In that test he disabled the third choice scheduler
>> > and the result was a shader that spilled 6 or 8 times but ran something
>> > like 30% faster. We really need to do some more experimentation with
>> > scheduling and figure out better heuristics than "SIMD16 is always
> faster"
>> > and "spilling is bad".
>> >
>>
>> Yes, I'm aware of rare corner cases like that where e.g. SIMD16 leads to
>> higher cache thrashing than SIMD8 leading to decreased overall
>> performance, and a case where a shader SIMD16 *with* spills has better
>> performance than the SIMD8 version of the same shader without spills.
>>
>> In any case it's not the register allocator's business to implement such
>> heuristics, and that's not an argument against the register allocator
>> trying to make a more efficient use of the register file.
>
> The primary point I was trying to make is that scheduling *does* matter.
> It matters a lot. In fact, Matt and i have talked about throwing away the
> SIMD16 program if it ends up using the pessimal schedulong algorithm.
> Throwing scheduling to the wind just to gain a few SIMD16 programs is
> probably not a good trade-off.
>
In my experience the exact opposite observation has been far more
common. Running SIMD16 vs SIMD8 has a larger impact on performance than
the way you end up scheduling things post-regalloc. Actually even if
you end up causing some unmet instruction dependencies by the way
instructions are scheduled post-regalloc, the EU can context-switch to
service the next available thread almost for free when a thread stalls
on some dependency. Also the fact that you're doing SIMD16 itself makes
post-regalloc scheduling less important because it naturally has an
effect in hiding latency.
My intuition is that the huge performance improvement Matt observed by
disabling the third scheduling heuristic is more likely to have been
caused by a decrease in the amount of cache thrashing caused by the fact
that he was running less channels concurrently rather than by the
scheduling heuristic itself. Matt, did you rule out that possibility?
The other thing is this patch has an effect on the allocation strategy
for optimistically colorable nodes *only*. We're already heavily
constrained by register pressure when we get to that point, and assuming
allocation succeeds the post-regalloc scheduler is going to have little
room for maneuvering anyway.
> It could be that this is an good idea, but it's going to take more than
> hand-waved theories about register allocation one shader not spilling to
> convince me. Do you actually know what it did to scheduling? It wouldn't
> be hard to hack up the driver and shader-db to collect that information.
>
44 shaders going SIMD16 seems like a strong enough argument to me.
Could you be more precise about what additional information you want me
to collect?
> --Jason
>
>> >> 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;
>> >>
Re: [Mesa-dev] [PATCH] ra: Disable round-robin strategy for optimistically colorable nodes.
On Mon, Feb 16, 2015 at 10:40 AM, Francisco Jerez wrote: > My intuition is that the huge performance improvement Matt observed by > disabling the third scheduling heuristic is more likely to have been > caused by a decrease in the amount of cache thrashing caused by the fact > that he was running less channels concurrently rather than by the > scheduling heuristic itself. Matt, did you rule out that possibility? Actually, the fragment shader used in the demo [1] doesn't can't register allocate in SIMD16 at all. From my Dec/Jan status report: > As an aside, I did an experiment to see what would happen if we used > SCHEDULE_PRE and spilled anyway (I added a couple of extra instructions > to increase register pressure over the threshold). I changed the window > size to 2048x2048 and rendered 1000 frames. > > SCHEDULE_PRE with no spills: 17.5 seconds to render 1000 fames > SCHEDULE_PRE with 4 spills (8 sends): 17.5 seconds > SCHEDULE_PRE_NON_LIFO with no spills: 28 seconds The demo does no texturing (no send instructions at all if no spilling), so it's not affected by caching as far as I understand. [1] https://github.com/ashima/webgl-noise ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: don't enable NV_fragment_program_option with swrast
Am 16.02.2015 um 18:59 schrieb Dieter Nützel: > Am 16.02.2015 18:13, schrieb Brian Paul: >> On 02/16/2015 08:11 AM, Roland Scheidegger wrote: >>> Am 16.02.2015 um 00:36 schrieb Matt Turner: On Sat, Feb 14, 2015 at 2:33 PM, Roland Scheidegger wrote: > Am 14.02.2015 um 21:12 schrieb Kenneth Graunke: >> On Saturday, February 14, 2015 04:37:25 PM srol...@vmware.com wrote: >>> From: Roland Scheidegger >>> >>> Since dropping some NV_fragment_program opcodes (commits >>> 868f95f1da74cf6dd7468cba1b56664aad585ccb, >>> a3688d686f147f4252d19b298ae26d4ac72c2e08) >>> we can no longer parse all opcodes necessary for this extension, >>> leading >>> to bugs >>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D86980&d=AwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=WR7M0CMoTs3KQMrLGbBd33mSg7pYv21Om0yOzq27Swg&s=VVYgQUmxDRQ8b-H-36lfDVGUw4SFuqAVM1qfxbB71pc&e= >>> ). >>> Hence don't announce support for it in swrast. >>> (The rest of the infrastructure ranging from dead opcodes >>> (TXP_NV) to >>> parsing condition codes along with the NV_fragment_program_option >>> variable >>> in the context could probably nuked too this is just a minimal >>> fix appropriate >>> for stable too.) >>> --- >>> src/mesa/main/extensions.c | 1 - >>> 1 file changed, 1 deletion(-) >>> >>> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c >>> index 220b220..c94009f 100644 >>> --- a/src/mesa/main/extensions.c >>> +++ b/src/mesa/main/extensions.c >>> @@ -511,7 +511,6 @@ _mesa_enable_sw_extensions(struct gl_context >>> *ctx) >>> ctx->Extensions.NV_point_sprite = GL_TRUE; >>> ctx->Extensions.NV_texture_env_combine4 = GL_TRUE; >>> ctx->Extensions.NV_texture_rectangle = GL_TRUE; >>> - ctx->Extensions.NV_fragment_program_option = GL_TRUE; >>> ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE; >>> ctx->Extensions.OES_standard_derivatives = GL_TRUE; >>> ctx->Extensions.TDFX_texture_compression_FXT1 = GL_TRUE; >>> >> >> Nuking this extension would make some compiler work I'm planning >> to do >> easier, so I'd definitely be interested to hear whether you still >> need >> it. >> > > Well, according to the git log specviewperf11 catia test won't run > correctly without supporting some bits from NV_program_option and > NV_fragment_program2 - obviously the benchmark doesn't care one bit if > the extension is actually officially supported by a driver or not. >> >> Just to clarify, this is because the viewperf tests are basically >> application traces which get replayed, and unfortunately, viewperf >> doesn't even bother to check if the OpenGL driver supports the >> extensions which are used by the trace. The traces were created with >> nvidia drivers. >> >> > I suspect this is something which we still need to be able to run, > though Brian would probably know the definitive answer. If we knew specifically what it uses, maybe we can just support that instead of the whole extension? Not having to handle the condition code bits of the extension would be nice, for instance. >>> >>> There's definitely some bits around condition codes with IF/ELSE/ENDIF >>> needed (with NV_fp2/NV_vp3 even), though it seems there's some >>> differences to our private code there to make it work. Apart from that >>> I'm not entirely sure. Maybe we could expose it as an ordinary quirk to >>> make things more obvious but I've never dealt with that viewperf issue. >> >> Here's an example of a fragment program from the catia-03 #3 test: >> >> !!ARBfp1.0 >> OPTION NV_fragment_program2; >> # cgc version 1.5.0023, build date Sep 26 2007 08:51:03 >> # command line args: >> #vendor NVIDIA Corporation >> #version 1.5.0.23 >> #profile fp40 >> #program AdvancedHighlightPS >> #semantic AdvancedHighlightPS.iOutlineColor >> #semantic AdvancedHighlightPS.iHaloSize >> #semantic AdvancedHighlightPS.iHaloIntensity >> #semantic AdvancedHighlightPS.iHaloColor >> #semantic AdvancedHighlightPS.iScanEffectIntensity >> #semantic AdvancedHighlightPS.iScanEffectColor >> #semantic AdvancedHighlightPS.iInputTexture >> #semantic outlineColor >> #semantic haloColor >> #semantic haloIntensity >> #semantic haloSize >> #semantic scanEffectColor >> #semantic scanEffectIntensity >> #semantic inputTexture >> #semantic filterBlurData >> #semantic filterBlurDataLow >> #var float4 IN.ScreenPosition : $vin.TEXCOORD0 : TEX0 : 0 : 1 >> #var float4 iOutlineColor : : c[0] : 1 : 1 >> #var float iHaloSize : : c[1] : 2 : 1 >> #var float iHaloIntensity : : c[2] : 3 : 1 >> #var float4 iHaloColor : : c[3] : 4 : 1 >> #var float iScanEffectIntensity : : : 5 : 0 >> #var float4 iScanEffectColor : : c[4] : 6 : 1 >> #var samplerRECT iInputTex
Re: [Mesa-dev] [PATCH] ra: Disable round-robin strategy for optimistically colorable nodes.
On Mon, Feb 16, 2015 at 10:40 AM, Francisco Jerez wrote: > Jason Ekstrand writes: > > > On Feb 16, 2015 9:34 AM, "Francisco Jerez" > wrote: > >> > >> Jason Ekstrand writes: > >> > >> > On Feb 16, 2015 8:35 AM, "Francisco Jerez" > > 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. > >> > > >> > Actually, that's not true. Matt was doing some experiments recently > > with a > >> > noise shader from synmark and the difference between our 2nd and 3rd > > choice > >> > schedulers is huge. In that test he disabled the third choice > scheduler > >> > and the result was a shader that spilled 6 or 8 times but ran > something > >> > like 30% faster. We really need to do some more experimentation with > >> > scheduling and figure out better heuristics than "SIMD16 is always > > faster" > >> > and "spilling is bad". > >> > > >> > >> Yes, I'm aware of rare corner cases like that where e.g. SIMD16 leads to > >> higher cache thrashing than SIMD8 leading to decreased overall > >> performance, and a case where a shader SIMD16 *with* spills has better > >> performance than the SIMD8 version of the same shader without spills. > >> > >> In any case it's not the register allocator's business to implement such > >> heuristics, and that's not an argument against the register allocator > >> trying to make a more efficient use of the register file. > > > > The primary point I was trying to make is that scheduling *does* matter. > > It matters a lot. In fact, Matt and i have talked about throwing away > the > > SIMD16 program if it ends up using the pessimal schedulong algorithm. > > Throwing scheduling to the wind just to gain a few SIMD16 programs is > > probably not a good trade-off. > > > In my experience the exact opposite observation has been far more > common. Running SIMD16 vs SIMD8 has a larger impact on performance than > the way you end up scheduling things post-regalloc. Actually even if > you end up causing some unmet instruction dependencies by the way > instructions are scheduled post-regalloc, the EU can context-switch to > service the next available thread almost for free when a thread stalls > on some dependency. Also the fact that you're doing SIMD16 itself makes > post-regalloc scheduling less important because it naturally has an > effect in hiding latency. > > My intuition is that the huge performance improvement Matt observed by > disabling the third scheduling heuristic is more likely to have been > caused by a decrease in the amount of cache thrashing caused by the fact > that he was running less channels concurrently rather than by the > scheduling heuristic itself. Matt, did you rule out that possibility? > > The other thing is this patch has an effect on the allocation strategy > for optimistically colorable nodes *only*. We're already heavily > constrained by register pressure when we get to that point, and assuming > allocation succeeds the post-regalloc scheduler is going to have little > room for maneuvering anyway. > > > It could be that this is an good idea, but it's going to take more than > > hand-waved theories about register allocation one shader not spilling to > > convince me. Do you actually know what it did to scheduling? It > wouldn't > > be hard to hack up the driver and shader-db to collect that information. > > > 44 shaders going SIMD16 seems like a strong enough argument to me. > Could you be more precise about what additional information you want me > to collect? > How many shaders go from the first scheduling method to the second or to the third. In other words some sort of metric on which shaders are "helped" or "hurt" in their scheduling. > > --Jason > > > >> >> 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:
Re: [Mesa-dev] [PATCH] ra: Disable round-robin strategy for optimistically colorable nodes.
Matt Turner writes: > On Mon, Feb 16, 2015 at 10:40 AM, Francisco Jerez > wrote: >> My intuition is that the huge performance improvement Matt observed by >> disabling the third scheduling heuristic is more likely to have been >> caused by a decrease in the amount of cache thrashing caused by the fact >> that he was running less channels concurrently rather than by the >> scheduling heuristic itself. Matt, did you rule out that possibility? > > Actually, the fragment shader used in the demo [1] doesn't can't > register allocate in SIMD16 at all. > > From my Dec/Jan status report: > >> As an aside, I did an experiment to see what would happen if we used >> SCHEDULE_PRE and spilled anyway (I added a couple of extra instructions >> to increase register pressure over the threshold). I changed the window >> size to 2048x2048 and rendered 1000 frames. >> >> SCHEDULE_PRE with no spills: 17.5 seconds to render 1000 fames >> SCHEDULE_PRE with 4 spills (8 sends): 17.5 seconds >> SCHEDULE_PRE_NON_LIFO with no spills: 28 seconds > > The demo does no texturing (no send instructions at all if no > spilling), so it's not affected by caching as far as I understand. > > [1] https://github.com/ashima/webgl-noise Ahh, yes, that makes sense to me too. pgp9eZ26w8x4f.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] ra: Disable round-robin strategy for optimistically colorable nodes.
On Mon, Feb 16, 2015 at 10:57 AM, Jason Ekstrand wrote: > > > On Mon, Feb 16, 2015 at 10:40 AM, Francisco Jerez > wrote: > >> Jason Ekstrand writes: >> >> > On Feb 16, 2015 9:34 AM, "Francisco Jerez" >> wrote: >> >> >> >> Jason Ekstrand writes: >> >> >> >> > On Feb 16, 2015 8:35 AM, "Francisco Jerez" >> > 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. >> >> > >> >> > Actually, that's not true. Matt was doing some experiments recently >> > with a >> >> > noise shader from synmark and the difference between our 2nd and 3rd >> > choice >> >> > schedulers is huge. In that test he disabled the third choice >> scheduler >> >> > and the result was a shader that spilled 6 or 8 times but ran >> something >> >> > like 30% faster. We really need to do some more experimentation with >> >> > scheduling and figure out better heuristics than "SIMD16 is always >> > faster" >> >> > and "spilling is bad". >> >> > >> >> >> >> Yes, I'm aware of rare corner cases like that where e.g. SIMD16 leads >> to >> >> higher cache thrashing than SIMD8 leading to decreased overall >> >> performance, and a case where a shader SIMD16 *with* spills has better >> >> performance than the SIMD8 version of the same shader without spills. >> >> >> >> In any case it's not the register allocator's business to implement >> such >> >> heuristics, and that's not an argument against the register allocator >> >> trying to make a more efficient use of the register file. >> > >> > The primary point I was trying to make is that scheduling *does* matter. >> > It matters a lot. In fact, Matt and i have talked about throwing away >> the >> > SIMD16 program if it ends up using the pessimal schedulong algorithm. >> > Throwing scheduling to the wind just to gain a few SIMD16 programs is >> > probably not a good trade-off. >> > >> In my experience the exact opposite observation has been far more >> common. Running SIMD16 vs SIMD8 has a larger impact on performance than >> the way you end up scheduling things post-regalloc. Actually even if >> you end up causing some unmet instruction dependencies by the way >> instructions are scheduled post-regalloc, the EU can context-switch to >> service the next available thread almost for free when a thread stalls >> on some dependency. Also the fact that you're doing SIMD16 itself makes >> post-regalloc scheduling less important because it naturally has an >> effect in hiding latency. >> >> My intuition is that the huge performance improvement Matt observed by >> disabling the third scheduling heuristic is more likely to have been >> caused by a decrease in the amount of cache thrashing caused by the fact >> that he was running less channels concurrently rather than by the >> scheduling heuristic itself. Matt, did you rule out that possibility? >> >> The other thing is this patch has an effect on the allocation strategy >> for optimistically colorable nodes *only*. We're already heavily >> constrained by register pressure when we get to that point, and assuming >> allocation succeeds the post-regalloc scheduler is going to have little >> room for maneuvering anyway. >> >> > It could be that this is an good idea, but it's going to take more than >> > hand-waved theories about register allocation one shader not spilling to >> > convince me. Do you actually know what it did to scheduling? It >> wouldn't >> > be hard to hack up the driver and shader-db to collect that information. >> > >> 44 shaders going SIMD16 seems like a strong enough argument to me. >> Could you be more precise about what additional information you want me >> to collect? >> > > How many shaders go from the first scheduling method to the second or to > the third. In other words some sort of metric on which shaders are > "helped" or "hurt" in their scheduling. > Also, if you have an example of where this helps/hurts a real benchmark/game, that would be nice to know too. --Jason > > --Jason >> > >> >> >> Shader-db results on the i965 driver: >> >> >> >> >> >> total ins
[Mesa-dev] [PATCH] auxiliary/vl: honour the DRI2PROTO_CFLAGS
Otherwise for non-default installations the build will fail to find the headers and error out. Cc: "10.5" Signed-off-by: Emil Velikov --- src/gallium/auxiliary/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/auxiliary/Makefile.am b/src/gallium/auxiliary/Makefile.am index 6a628e9..4b62057 100644 --- a/src/gallium/auxiliary/Makefile.am +++ b/src/gallium/auxiliary/Makefile.am @@ -56,6 +56,7 @@ if NEED_GALLIUM_VL COMMON_VL_CFLAGS = \ $(AM_CFLAGS) \ $(VL_CFLAGS) \ + $(DRI2PROTO_CFLAGS) \ $(LIBDRM_CFLAGS) \ $(GALLIUM_PIPE_LOADER_DEFINES) \ -DPIPE_SEARCH_DIR=\"$(libdir)/gallium-pipe\" -- 2.1.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v5 08/29] glsl: fix uniform linking logic in the presence of structs
On Tue, Feb 10, 2015 at 6:58 AM, Ilia Mirkin wrote:
> Add a enter/leave record callback so that the offset may be aligned to
> the proper value. Otherwise only leaf fields are called, and the first
> field needs to be aligned to the outer struct's base alignment while the
> last field needs to be aligned to the inner struct's base alignment.
>
> This removes most usage of the last field/record type values passed into
> visit_field.
>
> Signed-off-by: Ilia Mirkin
> ---
> I kept this separate from the other changes since it seemed self-contained.
> I can fold somewhere else if desired.
>
> src/glsl/link_uniform_blocks.cpp | 45
> ++--
> src/glsl/link_uniforms.cpp | 37 +++--
> src/glsl/linker.h| 6 ++
> 3 files changed, 57 insertions(+), 31 deletions(-)
>
> diff --git a/src/glsl/link_uniform_blocks.cpp
> b/src/glsl/link_uniform_blocks.cpp
> index f5fc502..1c175ec 100644
> --- a/src/glsl/link_uniform_blocks.cpp
> +++ b/src/glsl/link_uniform_blocks.cpp
> @@ -67,6 +67,25 @@ private:
>assert(!"Should not get here.");
> }
>
> + virtual void enter_record(const glsl_type *type, const char *name,
> + bool row_major) {
> + this->offset = glsl_align(
> +this->offset, type->std140_base_alignment(row_major));
> + }
> +
> + virtual void leave_record(const glsl_type *type, const char *name,
> + bool row_major) {
> + /* If this is the last field of a structure, apply rule #9. The
> + * GL_ARB_uniform_buffer_object spec says:
> + *
> + * "The structure may have padding at the end; the base offset of
> + * the member following the sub-structure is rounded up to the next
> + * multiple of the base alignment of the structure."
> + */
> + this->offset = glsl_align(
> +this->offset, type->std140_base_alignment(row_major));
> + }
> +
> virtual void visit_field(const glsl_type *type, const char *name,
> bool row_major, const glsl_type *record_type,
> bool last_field)
> @@ -97,27 +116,13 @@ private:
> v->IndexName = v->Name;
>}
>
> - const unsigned alignment = record_type
> - ? record_type->std140_base_alignment(v->RowMajor)
> - : type->std140_base_alignment(v->RowMajor);
> + const unsigned alignment = type->std140_base_alignment(v->RowMajor);
>unsigned size = type->std140_size(v->RowMajor);
>
>this->offset = glsl_align(this->offset, alignment);
>v->Offset = this->offset;
>
> - /* If this is the last field of a structure, apply rule #9. The
> - * GL_ARB_uniform_buffer_object spec says:
> - *
> - * "The structure may have padding at the end; the base offset of
> - * the member following the sub-structure is rounded up to the next
> - * multiple of the base alignment of the structure."
> - *
> - * last_field won't be set if this is the last field of a UBO that is
> - * not a named instance.
> - */
>this->offset += size;
> - if (last_field)
> - this->offset = glsl_align(this->offset, 16);
>
>/* From the GL_ARB_uniform_buffer_object spec:
> *
> @@ -131,16 +136,6 @@ private:
> */
>this->buffer_size = glsl_align(this->offset, 16);
> }
> -
> - virtual void visit_field(const glsl_struct_field *field)
> - {
> - /* FINISHME: When support for doubles (dvec4, etc.) is added to the
> - * FINISHME: compiler, this may be incorrect for a structure in a UBO
> - * FINISHME: like struct s { struct { float f } s1; dvec4 v; };.
> - */
> - this->offset = glsl_align(this->offset,
> -field->type->std140_base_alignment(false));
> - }
> };
>
> class count_block_size : public program_resource_visitor {
> diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
> index 3aa6e0a..347f079 100644
> --- a/src/glsl/link_uniforms.cpp
> +++ b/src/glsl/link_uniforms.cpp
> @@ -169,6 +169,9 @@ program_resource_visitor::recursion(const glsl_type *t,
> char **name,
>if (record_type == NULL && t->is_record())
> record_type = t;
>
> + if (t->is_record())
> + this->enter_record(t, *name, row_major);
> +
>for (unsigned i = 0; i < t->length; i++) {
> const char *field = t->fields.structure[i].name;
> size_t new_length = name_length;
> @@ -208,6 +211,11 @@ program_resource_visitor::recursion(const glsl_type *t,
> char **name,
>*/
> record_type = NULL;
>}
> +
> + if (t->is_record()) {
> + (*name)[name_length] = '\0';
> + this->leave_record(t, *name, row_major);
> + }
> } else if (t->is_array() && (t->fields.array->is_record()
> || t->fields.a
Re: [Mesa-dev] [PATCH] ra: Disable round-robin strategy for optimistically colorable nodes.
Jason Ekstrand writes: > On Mon, Feb 16, 2015 at 10:40 AM, Francisco Jerez > wrote: > >> Jason Ekstrand writes: >> >> > On Feb 16, 2015 9:34 AM, "Francisco Jerez" >> wrote: >> >> >> >> Jason Ekstrand writes: >> >> >> >> > On Feb 16, 2015 8:35 AM, "Francisco Jerez" >> > 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. >> >> > >> >> > Actually, that's not true. Matt was doing some experiments recently >> > with a >> >> > noise shader from synmark and the difference between our 2nd and 3rd >> > choice >> >> > schedulers is huge. In that test he disabled the third choice >> scheduler >> >> > and the result was a shader that spilled 6 or 8 times but ran >> something >> >> > like 30% faster. We really need to do some more experimentation with >> >> > scheduling and figure out better heuristics than "SIMD16 is always >> > faster" >> >> > and "spilling is bad". >> >> > >> >> >> >> Yes, I'm aware of rare corner cases like that where e.g. SIMD16 leads to >> >> higher cache thrashing than SIMD8 leading to decreased overall >> >> performance, and a case where a shader SIMD16 *with* spills has better >> >> performance than the SIMD8 version of the same shader without spills. >> >> >> >> In any case it's not the register allocator's business to implement such >> >> heuristics, and that's not an argument against the register allocator >> >> trying to make a more efficient use of the register file. >> > >> > The primary point I was trying to make is that scheduling *does* matter. >> > It matters a lot. In fact, Matt and i have talked about throwing away >> the >> > SIMD16 program if it ends up using the pessimal schedulong algorithm. >> > Throwing scheduling to the wind just to gain a few SIMD16 programs is >> > probably not a good trade-off. >> > >> In my experience the exact opposite observation has been far more >> common. Running SIMD16 vs SIMD8 has a larger impact on performance than >> the way you end up scheduling things post-regalloc. Actually even if >> you end up causing some unmet instruction dependencies by the way >> instructions are scheduled post-regalloc, the EU can context-switch to >> service the next available thread almost for free when a thread stalls >> on some dependency. Also the fact that you're doing SIMD16 itself makes >> post-regalloc scheduling less important because it naturally has an >> effect in hiding latency. >> >> My intuition is that the huge performance improvement Matt observed by >> disabling the third scheduling heuristic is more likely to have been >> caused by a decrease in the amount of cache thrashing caused by the fact >> that he was running less channels concurrently rather than by the >> scheduling heuristic itself. Matt, did you rule out that possibility? >> >> The other thing is this patch has an effect on the allocation strategy >> for optimistically colorable nodes *only*. We're already heavily >> constrained by register pressure when we get to that point, and assuming >> allocation succeeds the post-regalloc scheduler is going to have little >> room for maneuvering anyway. >> >> > It could be that this is an good idea, but it's going to take more than >> > hand-waved theories about register allocation one shader not spilling to >> > convince me. Do you actually know what it did to scheduling? It >> wouldn't >> > be hard to hack up the driver and shader-db to collect that information. >> > >> 44 shaders going SIMD16 seems like a strong enough argument to me. >> Could you be more precise about what additional information you want me >> to collect? >> > > How many shaders go from the first scheduling method to the second or to > the third. In other words some sort of metric on which shaders are > "helped" or "hurt" in their scheduling. OK, I hacked the driver to output the scheduling heuristic that had been used when we allocated registers successfully for the program via KHR_debug and then ran shader-db before and after applying this patch. Before this patch: Heuristic SIMD8 SIMD16
Re: [Mesa-dev] [PATCH 02/16] main: replace tabs by 8 spaces in fbobject.c
LGTM.
Reviewed-by: Laura Ekstrand
On Mon, Feb 16, 2015 at 6:13 AM, Martin Peres
wrote:
> Signed-off-by: Martin Peres
> ---
> src/mesa/main/fbobject.c | 166
> +++
> 1 file changed, 83 insertions(+), 83 deletions(-)
>
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 3053622..09c931d 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -212,13 +212,13 @@ get_attachment(struct gl_context *ctx, struct
> gl_framebuffer *fb,
> */
>i = attachment - GL_COLOR_ATTACHMENT0_EXT;
>if (i >= ctx->Const.MaxColorAttachments
> - || (i > 0 && ctx->API == API_OPENGLES)) {
> -return NULL;
> + || (i > 0 && ctx->API == API_OPENGLES)) {
> + return NULL;
>}
>return &fb->Attachment[BUFFER_COLOR0 + i];
> case GL_DEPTH_STENCIL_ATTACHMENT:
>if (!_mesa_is_desktop_gl(ctx) && !_mesa_is_gles3(ctx))
> -return NULL;
> + return NULL;
>/* fall-through */
> case GL_DEPTH_ATTACHMENT_EXT:
>return &fb->Attachment[BUFFER_DEPTH];
> @@ -1122,28 +1122,28 @@ _mesa_test_framebuffer_completeness(struct
> gl_context *ctx,
> if (_mesa_is_desktop_gl(ctx) &&
> !ctx->Extensions.ARB_ES2_compatibility) {
>/* Check that all DrawBuffers are present */
>for (j = 0; j < ctx->Const.MaxDrawBuffers; j++) {
> -if (fb->ColorDrawBuffer[j] != GL_NONE) {
> - const struct gl_renderbuffer_attachment *att
> - = get_attachment(ctx, fb, fb->ColorDrawBuffer[j]);
> - assert(att);
> - if (att->Type == GL_NONE) {
> - fb->_Status = GL_FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER_EXT;
> - fbo_incomplete(ctx, "missing drawbuffer", j);
> - return;
> - }
> -}
> + if (fb->ColorDrawBuffer[j] != GL_NONE) {
> +const struct gl_renderbuffer_attachment *att
> + = get_attachment(ctx, fb, fb->ColorDrawBuffer[j]);
> +assert(att);
> +if (att->Type == GL_NONE) {
> + fb->_Status = GL_FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER_EXT;
> + fbo_incomplete(ctx, "missing drawbuffer", j);
> + return;
> +}
> + }
>}
>
>/* Check that the ReadBuffer is present */
>if (fb->ColorReadBuffer != GL_NONE) {
> -const struct gl_renderbuffer_attachment *att
> - = get_attachment(ctx, fb, fb->ColorReadBuffer);
> -assert(att);
> -if (att->Type == GL_NONE) {
> - fb->_Status = GL_FRAMEBUFFER_INCOMPLETE_READ_BUFFER_EXT;
> + const struct gl_renderbuffer_attachment *att
> += get_attachment(ctx, fb, fb->ColorReadBuffer);
> + assert(att);
> + if (att->Type == GL_NONE) {
> +fb->_Status = GL_FRAMEBUFFER_INCOMPLETE_READ_BUFFER_EXT;
> fbo_incomplete(ctx, "missing readbuffer", -1);
> - return;
> -}
> +return;
> + }
>}
> }
>
> @@ -1233,12 +1233,12 @@ bind_renderbuffer(GLenum target, GLuint
> renderbuffer, bool allow_user_names)
>}
>
>if (!newRb) {
> -/* create new renderbuffer object */
> -newRb = ctx->Driver.NewRenderbuffer(ctx, renderbuffer);
> -if (!newRb) {
> - _mesa_error(ctx, GL_OUT_OF_MEMORY, "glBindRenderbufferEXT");
> - return;
> -}
> + /* create new renderbuffer object */
> + newRb = ctx->Driver.NewRenderbuffer(ctx, renderbuffer);
> + if (!newRb) {
> +_mesa_error(ctx, GL_OUT_OF_MEMORY, "glBindRenderbufferEXT");
> +return;
> + }
> ASSERT(newRb->AllocStorage);
> _mesa_HashInsert(ctx->Shared->RenderBuffers, renderbuffer,
> newRb);
> newRb->RefCount = 1; /* referenced by hash table */
> @@ -1333,9 +1333,9 @@ _mesa_DeleteRenderbuffers(GLsizei n, const GLuint
> *renderbuffers)
>
> for (i = 0; i < n; i++) {
>if (renderbuffers[i] > 0) {
> -struct gl_renderbuffer *rb;
> -rb = _mesa_lookup_renderbuffer(ctx, renderbuffers[i]);
> -if (rb) {
> + struct gl_renderbuffer *rb;
> + rb = _mesa_lookup_renderbuffer(ctx, renderbuffers[i]);
> + if (rb) {
> /* check if deleting currently bound renderbuffer object */
> if (rb == ctx->CurrentRenderbuffer) {
> /* bind default */
> @@ -1368,17 +1368,17 @@ _mesa_DeleteRenderbuffers(GLsizei n, const GLuint
> *renderbuffers)
> _mesa_detach_renderbuffer(ctx, ctx->ReadBuffer, rb);
> }
>
> - /* Remove from hash table immediately, to free the ID.
> +/* Remove from hash table immediately, to free the ID.
> * But the object will not be freed until it's no longer
> * referenced anywhere else.
> */
> - _mesa_HashRemove(ctx->Shared->RenderBuff
Re: [Mesa-dev] [PATCH 01/16] main: replace tabs by 8 spaces in bufferobj.c
LGTM. Reviewed-by: Laura Ekstrand On Mon, Feb 16, 2015 at 6:13 AM, Martin Peres wrote: > Signed-off-by: Martin Peres > --- > src/mesa/main/queryobj.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c > index 932359c..17eaaac 100644 > --- a/src/mesa/main/queryobj.c > +++ b/src/mesa/main/queryobj.c > @@ -616,8 +616,8 @@ _mesa_GetQueryObjectiv(GLuint id, GLenum pname, GLint > *params) > } > break; >case GL_QUERY_RESULT_AVAILABLE_ARB: > -if (!q->Ready) > - ctx->Driver.CheckQuery( ctx, q ); > + if (!q->Ready) > +ctx->Driver.CheckQuery( ctx, q ); > *params = q->Ready; > break; >default: > @@ -667,8 +667,8 @@ _mesa_GetQueryObjectuiv(GLuint id, GLenum pname, > GLuint *params) > } > break; >case GL_QUERY_RESULT_AVAILABLE_ARB: > -if (!q->Ready) > - ctx->Driver.CheckQuery( ctx, q ); > + if (!q->Ready) > +ctx->Driver.CheckQuery( ctx, q ); > *params = q->Ready; > break; >default: > @@ -707,8 +707,8 @@ _mesa_GetQueryObjecti64v(GLuint id, GLenum pname, > GLint64EXT *params) > *params = q->Result; > break; >case GL_QUERY_RESULT_AVAILABLE_ARB: > -if (!q->Ready) > - ctx->Driver.CheckQuery( ctx, q ); > + if (!q->Ready) > +ctx->Driver.CheckQuery( ctx, q ); > *params = q->Ready; > break; >default: > @@ -747,8 +747,8 @@ _mesa_GetQueryObjectui64v(GLuint id, GLenum pname, > GLuint64EXT *params) > *params = q->Result; > break; >case GL_QUERY_RESULT_AVAILABLE_ARB: > -if (!q->Ready) > - ctx->Driver.CheckQuery( ctx, q ); > + if (!q->Ready) > +ctx->Driver.CheckQuery( ctx, q ); > *params = q->Ready; > break; >default: > -- > 2.3.0 > > ___ > 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] ra: Disable round-robin strategy for optimistically colorable nodes.
On Mon, Feb 16, 2015 at 12:02 PM, Francisco Jerez wrote: > Jason Ekstrand writes: > > > On Mon, Feb 16, 2015 at 10:40 AM, Francisco Jerez > > > wrote: > > > >> Jason Ekstrand writes: > >> > >> > On Feb 16, 2015 9:34 AM, "Francisco Jerez" > >> wrote: > >> >> > >> >> Jason Ekstrand writes: > >> >> > >> >> > On Feb 16, 2015 8:35 AM, "Francisco Jerez" > >> > 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. > >> >> > > >> >> > Actually, that's not true. Matt was doing some experiments > recently > >> > with a > >> >> > noise shader from synmark and the difference between our 2nd and > 3rd > >> > choice > >> >> > schedulers is huge. In that test he disabled the third choice > >> scheduler > >> >> > and the result was a shader that spilled 6 or 8 times but ran > >> something > >> >> > like 30% faster. We really need to do some more experimentation > with > >> >> > scheduling and figure out better heuristics than "SIMD16 is always > >> > faster" > >> >> > and "spilling is bad". > >> >> > > >> >> > >> >> Yes, I'm aware of rare corner cases like that where e.g. SIMD16 > leads to > >> >> higher cache thrashing than SIMD8 leading to decreased overall > >> >> performance, and a case where a shader SIMD16 *with* spills has > better > >> >> performance than the SIMD8 version of the same shader without spills. > >> >> > >> >> In any case it's not the register allocator's business to implement > such > >> >> heuristics, and that's not an argument against the register allocator > >> >> trying to make a more efficient use of the register file. > >> > > >> > The primary point I was trying to make is that scheduling *does* > matter. > >> > It matters a lot. In fact, Matt and i have talked about throwing away > >> the > >> > SIMD16 program if it ends up using the pessimal schedulong algorithm. > >> > Throwing scheduling to the wind just to gain a few SIMD16 programs is > >> > probably not a good trade-off. > >> > > >> In my experience the exact opposite observation has been far more > >> common. Running SIMD16 vs SIMD8 has a larger impact on performance than > >> the way you end up scheduling things post-regalloc. Actually even if > >> you end up causing some unmet instruction dependencies by the way > >> instructions are scheduled post-regalloc, the EU can context-switch to > >> service the next available thread almost for free when a thread stalls > >> on some dependency. Also the fact that you're doing SIMD16 itself makes > >> post-regalloc scheduling less important because it naturally has an > >> effect in hiding latency. > >> > >> My intuition is that the huge performance improvement Matt observed by > >> disabling the third scheduling heuristic is more likely to have been > >> caused by a decrease in the amount of cache thrashing caused by the fact > >> that he was running less channels concurrently rather than by the > >> scheduling heuristic itself. Matt, did you rule out that possibility? > >> > >> The other thing is this patch has an effect on the allocation strategy > >> for optimistically colorable nodes *only*. We're already heavily > >> constrained by register pressure when we get to that point, and assuming > >> allocation succeeds the post-regalloc scheduler is going to have little > >> room for maneuvering anyway. > >> > >> > It could be that this is an good idea, but it's going to take more > than > >> > hand-waved theories about register allocation one shader not spilling > to > >> > convince me. Do you actually know what it did to scheduling? It > >> wouldn't > >> > be hard to hack up the driver and shader-db to collect that > information. > >> > > >> 44 shaders going SIMD16 seems like a strong enough argument to me. > >> Could you be more precise about what additional information you want me > >> to collect? > >> > > > > How many shaders go from the first scheduling method to the second or to > > the third. In other words some sort of metric on which shaders are > > "helped"
Re: [Mesa-dev] [PATCH v3 05/12] nir: Properly clean up CF nodes when we remove them
I gave my r-b on v1 since I couldn't find the v2 and you hadn't sent
the v3 yet. We'll figure out the rest of it later.
On Mon, Feb 9, 2015 at 11:24 PM, Jason Ekstrand wrote:
> Previously, if you remved a CF node that still had instructions in it, none
> of the use/def information from those instructions would get cleaned up.
> Also, we weren't removing if statements from the if_uses of the
> corresponding register or SSA def. This commit fixes both of these
> problems
> ---
> src/glsl/nir/nir.c | 54
> ++
> 1 file changed, 54 insertions(+)
>
> diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
> index 9a88bd3..8ea7bb5 100644
> --- a/src/glsl/nir/nir.c
> +++ b/src/glsl/nir/nir.c
> @@ -1148,6 +1148,58 @@ stitch_blocks(nir_block *before, nir_block *after)
> exec_node_remove(&after->cf_node.node);
> }
>
> +static void
> +remove_defs_uses(nir_instr *instr);
> +
> +static void
> +cleanup_cf_node(nir_cf_node *node)
> +{
> + switch (node->type) {
> + case nir_cf_node_block: {
> + nir_block *block = nir_cf_node_as_block(node);
> + /* We need to walk the instructions and clean up defs/uses */
> + nir_foreach_instr(block, instr)
> + remove_defs_uses(instr);
> + break;
> + }
> +
> + case nir_cf_node_if: {
> + nir_if *if_stmt = nir_cf_node_as_if(node);
> + foreach_list_typed(nir_cf_node, child, node, &if_stmt->then_list)
> + cleanup_cf_node(child);
> + foreach_list_typed(nir_cf_node, child, node, &if_stmt->else_list)
> + cleanup_cf_node(child);
> +
> + struct set *if_uses;
> + if (if_stmt->condition.is_ssa) {
> + if_uses = if_stmt->condition.ssa->if_uses;
> + } else {
> + if_uses = if_stmt->condition.reg.reg->if_uses;
> + }
> +
> + struct set_entry *entry = _mesa_set_search(if_uses, if_stmt);
> + assert(entry);
> + _mesa_set_remove(if_uses, entry);
> + break;
> + }
> +
> + case nir_cf_node_loop: {
> + nir_loop *loop = nir_cf_node_as_loop(node);
> + foreach_list_typed(nir_cf_node, child, node, &loop->body)
> + cleanup_cf_node(child);
> + break;
> + }
> + case nir_cf_node_function: {
> + nir_function_impl *impl = nir_cf_node_as_function(node);
> + foreach_list_typed(nir_cf_node, child, node, &impl->body)
> + cleanup_cf_node(child);
> + break;
> + }
> + default:
> + unreachable("Invalid CF node type");
> + }
> +}
> +
> void
> nir_cf_node_remove(nir_cf_node *node)
> {
> @@ -1175,6 +1227,8 @@ nir_cf_node_remove(nir_cf_node *node)
>exec_node_remove(&node->node);
>stitch_blocks(before_block, after_block);
> }
> +
> + cleanup_cf_node(node);
> }
>
> static bool
> --
> 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
Re: [Mesa-dev] [PATCH v3 05/12] nir: Properly clean up CF nodes when we remove them
On Mon, Feb 16, 2015 at 12:46 PM, Connor Abbott wrote:
> I gave my r-b on v1 since I couldn't find the v2 and you hadn't sent
> the v3 yet. We'll figure out the rest of it later.
>
Noted. I'll get that added.
> On Mon, Feb 9, 2015 at 11:24 PM, Jason Ekstrand
> wrote:
> > Previously, if you remved a CF node that still had instructions in it,
> none
> > of the use/def information from those instructions would get cleaned up.
> > Also, we weren't removing if statements from the if_uses of the
> > corresponding register or SSA def. This commit fixes both of these
> > problems
> > ---
> > src/glsl/nir/nir.c | 54
> ++
> > 1 file changed, 54 insertions(+)
> >
> > diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
> > index 9a88bd3..8ea7bb5 100644
> > --- a/src/glsl/nir/nir.c
> > +++ b/src/glsl/nir/nir.c
> > @@ -1148,6 +1148,58 @@ stitch_blocks(nir_block *before, nir_block *after)
> > exec_node_remove(&after->cf_node.node);
> > }
> >
> > +static void
> > +remove_defs_uses(nir_instr *instr);
> > +
> > +static void
> > +cleanup_cf_node(nir_cf_node *node)
> > +{
> > + switch (node->type) {
> > + case nir_cf_node_block: {
> > + nir_block *block = nir_cf_node_as_block(node);
> > + /* We need to walk the instructions and clean up defs/uses */
> > + nir_foreach_instr(block, instr)
> > + remove_defs_uses(instr);
> > + break;
> > + }
> > +
> > + case nir_cf_node_if: {
> > + nir_if *if_stmt = nir_cf_node_as_if(node);
> > + foreach_list_typed(nir_cf_node, child, node, &if_stmt->then_list)
> > + cleanup_cf_node(child);
> > + foreach_list_typed(nir_cf_node, child, node, &if_stmt->else_list)
> > + cleanup_cf_node(child);
> > +
> > + struct set *if_uses;
> > + if (if_stmt->condition.is_ssa) {
> > + if_uses = if_stmt->condition.ssa->if_uses;
> > + } else {
> > + if_uses = if_stmt->condition.reg.reg->if_uses;
> > + }
> > +
> > + struct set_entry *entry = _mesa_set_search(if_uses, if_stmt);
> > + assert(entry);
> > + _mesa_set_remove(if_uses, entry);
> > + break;
> > + }
> > +
> > + case nir_cf_node_loop: {
> > + nir_loop *loop = nir_cf_node_as_loop(node);
> > + foreach_list_typed(nir_cf_node, child, node, &loop->body)
> > + cleanup_cf_node(child);
> > + break;
> > + }
> > + case nir_cf_node_function: {
> > + nir_function_impl *impl = nir_cf_node_as_function(node);
> > + foreach_list_typed(nir_cf_node, child, node, &impl->body)
> > + cleanup_cf_node(child);
> > + break;
> > + }
> > + default:
> > + unreachable("Invalid CF node type");
> > + }
> > +}
> > +
> > void
> > nir_cf_node_remove(nir_cf_node *node)
> > {
> > @@ -1175,6 +1227,8 @@ nir_cf_node_remove(nir_cf_node *node)
> >exec_node_remove(&node->node);
> >stitch_blocks(before_block, after_block);
> > }
> > +
> > + cleanup_cf_node(node);
> > }
> >
> > static bool
> > --
> > 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
Re: [Mesa-dev] [PATCH v3 08/12] nir/from_ssa: Don't try to read an invalid instruction
Now that we talked about this on the last version of this patch, this makes more sense. But I'd like to see something in the commit message explaining what the issue was (going too far and casting the exec_node embedded in the block to a nir_instr) and how you put the patch that changes the behavior of nir_instr_prev() to actually fix this next in order to avoid segfaults in the middle of the series. On Mon, Feb 9, 2015 at 11:24 PM, Jason Ekstrand wrote: > --- > src/glsl/nir/nir_from_ssa.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/glsl/nir/nir_from_ssa.c b/src/glsl/nir/nir_from_ssa.c > index 3625237..7c50095 100644 > --- a/src/glsl/nir/nir_from_ssa.c > +++ b/src/glsl/nir/nir_from_ssa.c > @@ -272,7 +272,7 @@ get_parallel_copy_at_end_of_block(nir_block *block) > if (last_instr->type == nir_instr_type_jump) >last_instr = nir_instr_prev(last_instr); > > - if (last_instr->type == nir_instr_type_parallel_copy) > + if (last_instr && last_instr->type == nir_instr_type_parallel_copy) >return nir_instr_as_parallel_copy(last_instr); > else >return NULL; > -- > 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
Re: [Mesa-dev] [PATCH v3 08/12] nir/from_ssa: Don't try to read an invalid instruction
On Mon, Feb 16, 2015 at 3:57 PM, Connor Abbott wrote: > Now that we talked about this on the last version of this patch, this > makes more sense. But I'd like to see something in the commit message > explaining what the issue was (going too far and casting the exec_node > embedded in the block to a nir_instr) and how you put the patch that > changes the behavior of nir_instr_prev() to actually fix this next in > order to avoid segfaults in the middle of the series. Whoops, I forgot... once you do that, you get my r-b for this and the next patch. > > On Mon, Feb 9, 2015 at 11:24 PM, Jason Ekstrand wrote: >> --- >> src/glsl/nir/nir_from_ssa.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/src/glsl/nir/nir_from_ssa.c b/src/glsl/nir/nir_from_ssa.c >> index 3625237..7c50095 100644 >> --- a/src/glsl/nir/nir_from_ssa.c >> +++ b/src/glsl/nir/nir_from_ssa.c >> @@ -272,7 +272,7 @@ get_parallel_copy_at_end_of_block(nir_block *block) >> if (last_instr->type == nir_instr_type_jump) >>last_instr = nir_instr_prev(last_instr); >> >> - if (last_instr->type == nir_instr_type_parallel_copy) >> + if (last_instr && last_instr->type == nir_instr_type_parallel_copy) >>return nir_instr_as_parallel_copy(last_instr); >> else >>return NULL; >> -- >> 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
Re: [Mesa-dev] [PATCH v3 10/12] nir/instr: Change "live" to a more generic "pass_flags" field
Reviewed-by: Connor Abbott
On Mon, Feb 9, 2015 at 11:24 PM, Jason Ekstrand wrote:
> ---
> This replaces the original patch 10 even though they are very different.
>
> src/glsl/nir/nir.h | 6 --
> src/glsl/nir/nir_opt_dce.c | 14 +-
> 2 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
> index f4056f4..6ac1bfd 100644
> --- a/src/glsl/nir/nir.h
> +++ b/src/glsl/nir/nir.h
> @@ -411,8 +411,10 @@ typedef struct {
> nir_instr_type type;
> struct nir_block *block;
>
> - /* flag for dead code elimination (see nir_opt_dce.c) */
> - bool live;
> + /* A temporary for optimization and analysis passes to use for storing
> +* flags. For instance, DCE uses this to store the "dead/live" info.
> +*/
> + uint8_t pass_flags;
> } nir_instr;
>
> static inline nir_instr *
> diff --git a/src/glsl/nir/nir_opt_dce.c b/src/glsl/nir/nir_opt_dce.c
> index 3f7d94d..e0ebdc6 100644
> --- a/src/glsl/nir/nir_opt_dce.c
> +++ b/src/glsl/nir/nir_opt_dce.c
> @@ -39,7 +39,7 @@ worklist_push(struct exec_list *worklist, nir_instr *instr)
> {
> worklist_elem *elem = ralloc(worklist, worklist_elem);
> elem->instr = instr;
> - instr->live = true;
> + instr->pass_flags = 1;
> exec_list_push_tail(worklist, &elem->node);
> }
>
> @@ -56,7 +56,7 @@ mark_live_cb(nir_src *src, void *_state)
> {
> struct exec_list *worklist = (struct exec_list *) _state;
>
> - if (src->is_ssa && !src->ssa->parent_instr->live) {
> + if (src->is_ssa && !src->ssa->parent_instr->pass_flags) {
>worklist_push(worklist, src->ssa->parent_instr);
> }
>
> @@ -70,7 +70,11 @@ init_instr(nir_instr *instr, struct exec_list *worklist)
> nir_intrinsic_instr *intrin_instr;
> nir_tex_instr *tex_instr;
>
> - instr->live = false;
> + /* We use the pass_flags to store the live/dead information. In DCE, we
> +* just treat it as a zero/non-zerl boolean for whether or not the
> +* instruction is live.
> +*/
> + instr->pass_flags = 0;
>
> switch (instr->type) {
> case nir_instr_type_call:
> @@ -119,7 +123,7 @@ init_block_cb(nir_block *block, void *_state)
> nir_if *following_if = nir_block_get_following_if(block);
> if (following_if) {
>if (following_if->condition.is_ssa &&
> - !following_if->condition.ssa->parent_instr->live)
> + !following_if->condition.ssa->parent_instr->pass_flags)
> worklist_push(worklist, following_if->condition.ssa->parent_instr);
> }
>
> @@ -132,7 +136,7 @@ delete_block_cb(nir_block *block, void *_state)
> bool *progress = (bool *) _state;
>
> nir_foreach_instr_safe(block, instr) {
> - if (!instr->live) {
> + if (!instr->pass_flags) {
> nir_instr_remove(instr);
> *progress = true;
>}
> --
> 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
Re: [Mesa-dev] [PATCH v3 08/12] nir/from_ssa: Don't try to read an invalid instruction
On Mon, Feb 16, 2015 at 1:03 PM, Connor Abbott wrote: > On Mon, Feb 16, 2015 at 3:57 PM, Connor Abbott > wrote: > > Now that we talked about this on the last version of this patch, this > > makes more sense. But I'd like to see something in the commit message > > explaining what the issue was (going too far and casting the exec_node > > embedded in the block to a nir_instr) and how you put the patch that > > changes the behavior of nir_instr_prev() to actually fix this next in > > order to avoid segfaults in the middle of the series. > > Whoops, I forgot... once you do that, you get my r-b for this and the > next patch. > How about: Right now, the nir_instr_prev function function blindly looks up the previous element in the exec list and casts it to an instruction even if it's the tail sentinel. The next commit will change this to return null if it's the first instruction. Making this change first avoids getting a segfault between commits. The only reason we never noticed is that, thanks to the way things are laid out in nir_block, the casted instruction's type was never parallal_copy. > > > > On Mon, Feb 9, 2015 at 11:24 PM, Jason Ekstrand > wrote: > >> --- > >> src/glsl/nir/nir_from_ssa.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/src/glsl/nir/nir_from_ssa.c b/src/glsl/nir/nir_from_ssa.c > >> index 3625237..7c50095 100644 > >> --- a/src/glsl/nir/nir_from_ssa.c > >> +++ b/src/glsl/nir/nir_from_ssa.c > >> @@ -272,7 +272,7 @@ get_parallel_copy_at_end_of_block(nir_block *block) > >> if (last_instr->type == nir_instr_type_jump) > >>last_instr = nir_instr_prev(last_instr); > >> > >> - if (last_instr->type == nir_instr_type_parallel_copy) > >> + if (last_instr && last_instr->type == nir_instr_type_parallel_copy) > >>return nir_instr_as_parallel_copy(last_instr); > >> else > >>return NULL; > >> -- > >> 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
Re: [Mesa-dev] [PATCH 2/6] gallium: add interface and state tracker support for GL_AMD_pinned_memory
On Thu, Feb 12, 2015 at 3:11 PM, Roland Scheidegger wrote: > Am 11.02.2015 um 21:18 schrieb Marek Olšák: >> From: Marek Olšák >> >> --- >> src/gallium/docs/source/screen.rst | 5 + >> src/gallium/drivers/i915/i915_screen.c | 1 + >> src/gallium/drivers/ilo/ilo_screen.c | 1 + >> src/gallium/drivers/llvmpipe/lp_screen.c | 1 + >> src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + >> src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + >> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + >> src/gallium/drivers/r300/r300_screen.c | 1 + >> src/gallium/drivers/softpipe/sp_screen.c | 1 + >> src/gallium/drivers/svga/svga_screen.c | 1 + >> src/gallium/drivers/vc4/vc4_screen.c | 1 + >> src/gallium/include/pipe/p_defines.h | 1 + >> src/gallium/include/pipe/p_screen.h| 8 >> src/mesa/state_tracker/st_cb_bufferobjects.c | 18 +- >> src/mesa/state_tracker/st_extensions.c | 1 + >> 15 files changed, 38 insertions(+), 5 deletions(-) >> >> diff --git a/src/gallium/docs/source/screen.rst >> b/src/gallium/docs/source/screen.rst >> index aa519d2..313980a 100644 >> --- a/src/gallium/docs/source/screen.rst >> +++ b/src/gallium/docs/source/screen.rst >> @@ -246,6 +246,11 @@ The integer capabilities: >> * ``PIPE_CAP_MULTISAMPLE_Z_RESOLVE``: Whether the driver supports blitting >>a multisampled depth buffer into a single-sampled texture (or depth >> buffer). >>Only the first sampled should be copied. >> +* ``PIPE_CAP_RESOURCE_FROM_USER_MEMORY``: Whether the driver can create >> + a pipe_resource where an already-existing piece of (malloc'd) user memory >> + is used as its backing storage. In other words, whether the driver can map >> + existing user memory into the device address space for direct device >> access. >> + The create function is pipe_screen::resource_from_user_memory. > I think this is only really guaranteed to work if addresses and sizes > are page-aligned. If so could that be mentioned here? Yes, I'll add that. > > > >> >> >> .. _pipe_capf: >> diff --git a/src/gallium/drivers/i915/i915_screen.c >> b/src/gallium/drivers/i915/i915_screen.c >> index d2199a2..6c35fc8 100644 >> --- a/src/gallium/drivers/i915/i915_screen.c >> +++ b/src/gallium/drivers/i915/i915_screen.c >> @@ -231,6 +231,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap >> cap) >> case PIPE_CAP_VERTEXID_NOBASE: >> case PIPE_CAP_POLYGON_OFFSET_CLAMP: >> case PIPE_CAP_MULTISAMPLE_Z_RESOLVE: >> + case PIPE_CAP_RESOURCE_FROM_USER_MEMORY: >>return 0; >> >> case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS: >> diff --git a/src/gallium/drivers/ilo/ilo_screen.c >> b/src/gallium/drivers/ilo/ilo_screen.c >> index 6e9e723..0182b7f 100644 >> --- a/src/gallium/drivers/ilo/ilo_screen.c >> +++ b/src/gallium/drivers/ilo/ilo_screen.c >> @@ -473,6 +473,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap >> param) >> case PIPE_CAP_CONDITIONAL_RENDER_INVERTED: >> case PIPE_CAP_SAMPLER_VIEW_TARGET: >> case PIPE_CAP_MULTISAMPLE_Z_RESOLVE: >> + case PIPE_CAP_RESOURCE_FROM_USER_MEMORY: >>return 0; >> >> case PIPE_CAP_VENDOR_ID: >> diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c >> b/src/gallium/drivers/llvmpipe/lp_screen.c >> index 31c65df..8b6e66e 100644 >> --- a/src/gallium/drivers/llvmpipe/lp_screen.c >> +++ b/src/gallium/drivers/llvmpipe/lp_screen.c >> @@ -288,6 +288,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum >> pipe_cap param) >> case PIPE_CAP_POLYGON_OFFSET_CLAMP: >>return 1; >> case PIPE_CAP_MULTISAMPLE_Z_RESOLVE: >> + case PIPE_CAP_RESOURCE_FROM_USER_MEMORY: >>return 0; >> } >> /* should only get here on unhandled cases */ >> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c >> b/src/gallium/drivers/nouveau/nv30/nv30_screen.c >> index 9c183f2..247ecbb 100644 >> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c >> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c >> @@ -160,6 +160,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum >> pipe_cap param) >> case PIPE_CAP_VERTEXID_NOBASE: >> case PIPE_CAP_POLYGON_OFFSET_CLAMP: >> case PIPE_CAP_MULTISAMPLE_Z_RESOLVE: >> + case PIPE_CAP_RESOURCE_FROM_USER_MEMORY: >>return 0; >> >> case PIPE_CAP_VENDOR_ID: >> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c >> b/src/gallium/drivers/nouveau/nv50/nv50_screen.c >> index b79c237..729fc04 100644 >> --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c >> +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c >> @@ -208,6 +208,7 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum >> pipe_cap param) >> case PIPE_CAP_DRAW_INDIRECT: >> case PIPE_CAP_VERTEXID_NOBASE: >> case PIPE_CAP_MULTISAMPLE_Z_RESOLVE: /* potentially supported on some hw >> */ >> + case PIPE_CAP_RESOURCE_FROM_USER_MEMORY: >>re
Re: [Mesa-dev] [PATCH v3 08/12] nir/from_ssa: Don't try to read an invalid instruction
That seems fine to me. On Mon, Feb 16, 2015 at 4:23 PM, Jason Ekstrand wrote: > > > On Mon, Feb 16, 2015 at 1:03 PM, Connor Abbott wrote: >> >> On Mon, Feb 16, 2015 at 3:57 PM, Connor Abbott >> wrote: >> > Now that we talked about this on the last version of this patch, this >> > makes more sense. But I'd like to see something in the commit message >> > explaining what the issue was (going too far and casting the exec_node >> > embedded in the block to a nir_instr) and how you put the patch that >> > changes the behavior of nir_instr_prev() to actually fix this next in >> > order to avoid segfaults in the middle of the series. >> >> Whoops, I forgot... once you do that, you get my r-b for this and the >> next patch. > > > How about: > > Right now, the nir_instr_prev function function blindly looks up the > previous element in the exec list and casts it to an instruction even if > it's the tail sentinel. The next commit will change this to return null if > it's the first instruction. Making this change first avoids getting a > segfault between commits. The only reason we never noticed is that, thanks > to the way things are laid out in nir_block, the casted instruction's type > was never parallal_copy. > >> >> > >> > On Mon, Feb 9, 2015 at 11:24 PM, Jason Ekstrand >> > wrote: >> >> --- >> >> src/glsl/nir/nir_from_ssa.c | 2 +- >> >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> >> >> diff --git a/src/glsl/nir/nir_from_ssa.c b/src/glsl/nir/nir_from_ssa.c >> >> index 3625237..7c50095 100644 >> >> --- a/src/glsl/nir/nir_from_ssa.c >> >> +++ b/src/glsl/nir/nir_from_ssa.c >> >> @@ -272,7 +272,7 @@ get_parallel_copy_at_end_of_block(nir_block *block) >> >> if (last_instr->type == nir_instr_type_jump) >> >>last_instr = nir_instr_prev(last_instr); >> >> >> >> - if (last_instr->type == nir_instr_type_parallel_copy) >> >> + if (last_instr && last_instr->type == nir_instr_type_parallel_copy) >> >>return nir_instr_as_parallel_copy(last_instr); >> >> else >> >>return NULL; >> >> -- >> >> 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] [PATCH v2 2/2] driconf: Update Catalan translation
Signed-off-by: Alex Henrie --- Changes from version 1: Minor correction to the translation of t_options.h:240 src/mesa/drivers/dri/common/xmlpool/ca.po | 52 --- 1 file changed, 34 insertions(+), 18 deletions(-) diff --git a/src/mesa/drivers/dri/common/xmlpool/ca.po b/src/mesa/drivers/dri/common/xmlpool/ca.po index 23e9f42..f335b69 100644 --- a/src/mesa/drivers/dri/common/xmlpool/ca.po +++ b/src/mesa/drivers/dri/common/xmlpool/ca.po @@ -25,15 +25,15 @@ msgid "" msgstr "" "Project-Id-Version: Mesa 10.1.0-devel\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2014-09-25 22:29-0600\n" -"PO-Revision-Date: 2014-09-26 14:43-0700\n" +"POT-Creation-Date: 2015-02-07 02:08-0700\n" +"PO-Revision-Date: 2015-02-16 16:31-0700\n" "Last-Translator: Alex Henrie \n" "Language-Team: Catalan \n" "Language: ca\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" -"X-Generator: Poedit 1.6.9\n" +"X-Generator: Poedit 1.7.4\n" #: t_options.h:56 msgid "Debugging" @@ -83,8 +83,8 @@ msgstr "Deshabilita el GL_ARB_shader_bit_encoding" msgid "" "Force a default GLSL version for shaders that lack an explicit #version line" msgstr "" -"Força una versió GLSL per defecte en els shaders als quals falta una línia " -"#version explícita" +"Força una versió GLSL per defecte en els shaders als quals lis manca una " +"línia #version explícita" #: t_options.h:110 msgid "Allow GLSL #extension directives in the middle of shaders" @@ -92,7 +92,7 @@ msgstr "Permet les directives #extension GLSL en el mitjà dels shaders" #: t_options.h:120 msgid "Image Quality" -msgstr "Qualitat d'Imatge" +msgstr "Qualitat d'imatge" #: t_options.h:133 msgid "Texture color depth" @@ -149,11 +149,11 @@ msgstr "Mètode d'arrodoniment de color" #: t_options.h:171 msgid "Round color components downward" -msgstr "Arrondeix els components de color a baix" +msgstr "Arrodoneix els components de color a baix" #: t_options.h:172 msgid "Round to nearest color" -msgstr "Arrondeix al color més proper" +msgstr "Arrodoneix al color més proper" #: t_options.h:181 msgid "Color dithering method" @@ -181,15 +181,15 @@ msgstr "Un filtre de postprocessament per a aplicar cel shading a la sortida" #: t_options.h:200 msgid "A post-processing filter to remove the red channel" -msgstr "Un filtre de postprocessament per a treure el canal vermell" +msgstr "Un filtre de postprocessament per a eliminar el canal vermell" #: t_options.h:205 msgid "A post-processing filter to remove the green channel" -msgstr "Un filtre de postprocessament per a treure el canal verd" +msgstr "Un filtre de postprocessament per a eliminar el canal verd" #: t_options.h:210 msgid "A post-processing filter to remove the blue channel" -msgstr "Un filtre de postprocessament per a treure el canal blau" +msgstr "Un filtre de postprocessament per a eliminar el canal blau" #: t_options.h:215 msgid "" @@ -222,17 +222,17 @@ msgstr "Utilitza la canonada TCL de programari" #: t_options.h:240 msgid "Use hardware TCL as first TCL pipeline stage" -msgstr "Utilitza el TCL maquinàri com la primera fase de la canonada TCL" +msgstr "Utilitza el TCL de maquinari com a la primera fase de la canonada TCL" #: t_options.h:241 msgid "Bypass the TCL pipeline" -msgstr "Passar per alt la canonada TCL" +msgstr "Passa per alt la canonada TCL" #: t_options.h:242 msgid "" "Bypass the TCL pipeline with state-based machine code generated on-the-fly" msgstr "" -"Passar per alt la canonada TCL amb codi màquina basat en estats, generat " +"Passa per alt la canonada TCL amb codi de màquina basat en estats, generat " "sobre la marxa" #: t_options.h:251 @@ -245,7 +245,7 @@ msgstr "Espera activa pel maquinari de gràfics" #: t_options.h:253 msgid "Sleep for brief intervals while waiting for the graphics hardware" -msgstr "Dormi per intervals breus mentre s'espera al maquinari de gràfics" +msgstr "Dorm per intervals breus mentre s'espera al maquinari de gràfics" #: t_options.h:254 msgid "Let the graphics hardware emit a software interrupt and sleep" @@ -259,7 +259,7 @@ msgstr "Sincronització amb refresc vertical (intervals d'intercanvi)" #: t_options.h:265 msgid "Never synchronize with vertical refresh, ignore application's choice" msgstr "" -"Mai sincronitzis amb el refresc vertial, ignora l'elecció de l'aplicació" +"Mai sincronitzis amb el refresc vertical, ignora l'elecció de l'aplicació" #: t_options.h:266 msgid "Initial swap interval 0, obey application's choice" @@ -301,7 +301,7 @@ msgstr "Tota la memòria disponible" #: t_options.h:296 msgid "Only card memory (if available)" -msgstr "Només memòria de tarjeta (si està disponible)" +msgstr "Només memòria de targeta (si està disponible)" #: t_options.h:297 msgid "Only GART (AGP/PCIE) memory (if available)" @@ -329,4 +329,20 @@ msgstr "Inicialització" #: t_options.h:341 msgid "Define the graphic device to use if possible" -m
[Mesa-dev] [PATCH v2 1/2] driconf: Update Spanish translation
Signed-off-by: Alex Henrie --- Changes from version 1: None src/mesa/drivers/dri/common/xmlpool/es.po | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/src/mesa/drivers/dri/common/xmlpool/es.po b/src/mesa/drivers/dri/common/xmlpool/es.po index a68c329..23aa37c 100644 --- a/src/mesa/drivers/dri/common/xmlpool/es.po +++ b/src/mesa/drivers/dri/common/xmlpool/es.po @@ -9,8 +9,8 @@ msgid "" msgstr "" "Project-Id-Version: es\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2014-09-25 22:29-0600\n" -"PO-Revision-Date: 2014-09-26 14:22-0700\n" +"POT-Creation-Date: 2015-02-07 02:08-0700\n" +"PO-Revision-Date: 2015-02-08 23:44-0700\n" "Last-Translator: Alex Henrie \n" "Language-Team: Spanish \n" "Language: es\n" @@ -18,7 +18,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" -"X-Generator: Poedit 1.6.9\n" +"X-Generator: Poedit 1.7.3\n" #: t_options.h:56 msgid "Debugging" @@ -301,11 +301,11 @@ msgstr "Habilitar la extensión GL_ARB_vertex_program" #: t_options.h:323 msgid "Miscellaneous" -msgstr "Misceláneo" +msgstr "Misceláneos" #: t_options.h:327 msgid "Create all visuals with a depth buffer" -msgstr "Crear todos los visuales con buffer de profundidad" +msgstr "Crear todos los visuales con búfer de profundidad" #: t_options.h:337 msgid "Initialization" @@ -314,3 +314,19 @@ msgstr "Inicialización" #: t_options.h:341 msgid "Define the graphic device to use if possible" msgstr "Define el dispositivo de gráficos que usar si es posible" + +#: t_options.h:350 +msgid "Gallium Nine" +msgstr "Gallium Nueve" + +#: t_options.h:354 +msgid "" +"Define the throttling value. -1 for no throttling, -2 for default (usually " +"2), 0 for glfinish behaviour" +msgstr "" +"Define el valor de regulación. -1 para no regular, -2 para el por defecto " +"(generalmente 2), 0 para el comportamiento de glfinish" + +#: t_options.h:359 +msgid "Use an additional thread to submit buffers." +msgstr "Usa un hilo adicional para entregar los búfer." -- 2.3.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st:glsl_to_tgsi: fix whitespace
From: Dave Airlie
everytime I open this file in emacs with show trailing whitespace
or git add from it my screen flares with red.
Just do a general cleanup, makes working on fp64 support not as
jarring.
I'm not saying this is perfect, its just better than before.
Signed-off-by: Dave Airlie
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 380 ++---
1 file changed, 178 insertions(+), 202 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index a9ea8c8..3dac004 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -268,7 +268,7 @@ public:
this->size = size;
this->type = type;
}
-
+
gl_constant_value values[4];
int size; /**< Number of components (1-4) */
int type; /**< GL_FLOAT, GL_INT, GL_BOOL, or GL_UNSIGNED_INT */
@@ -327,7 +327,7 @@ public:
int num_address_regs;
int samplers_used;
bool indirect_addr_consts;
-
+
int glsl_version;
bool native_integers;
bool have_sqrt;
@@ -394,14 +394,14 @@ public:
glsl_to_tgsi_instruction *emit(ir_instruction *ir, unsigned op);
glsl_to_tgsi_instruction *emit(ir_instruction *ir, unsigned op,
- st_dst_reg dst, st_src_reg src0);
+ st_dst_reg dst, st_src_reg src0);
glsl_to_tgsi_instruction *emit(ir_instruction *ir, unsigned op,
- st_dst_reg dst, st_src_reg src0, st_src_reg
src1);
+ st_dst_reg dst, st_src_reg src0, st_src_reg
src1);
glsl_to_tgsi_instruction *emit(ir_instruction *ir, unsigned op,
- st_dst_reg dst,
- st_src_reg src0, st_src_reg src1, st_src_reg
src2);
+ st_dst_reg dst,
+ st_src_reg src0, st_src_reg src1, st_src_reg
src2);
glsl_to_tgsi_instruction *emit(ir_instruction *ir, unsigned op,
st_dst_reg dst,
@@ -422,15 +422,15 @@ public:
unsigned elements);
void emit_scalar(ir_instruction *ir, unsigned op,
- st_dst_reg dst, st_src_reg src0);
+st_dst_reg dst, st_src_reg src0);
void emit_scalar(ir_instruction *ir, unsigned op,
- st_dst_reg dst, st_src_reg src0, st_src_reg src1);
+st_dst_reg dst, st_src_reg src0, st_src_reg src1);
void emit_arl(ir_instruction *ir, st_dst_reg dst, st_src_reg src0);
void emit_scs(ir_instruction *ir, unsigned op,
-st_dst_reg dst, const st_src_reg &src);
+ st_dst_reg dst, const st_src_reg &src);
bool try_emit_mad(ir_expression *ir,
int mul_operand);
@@ -526,7 +526,7 @@ glsl_to_tgsi_visitor::emit(ir_instruction *ir, unsigned op,
{
glsl_to_tgsi_instruction *inst = new(mem_ctx) glsl_to_tgsi_instruction();
int num_reladdr = 0, i;
-
+
op = get_opcode(ir, op, dst, src0, src1);
/* If we have to do relative addressing, we want to load the ARL
@@ -560,7 +560,7 @@ glsl_to_tgsi_visitor::emit(ir_instruction *ir, unsigned op,
inst->dead_mask = 0;
inst->function = NULL;
-
+
/* Update indirect addressing status used by TGSI */
if (dst.reladdr) {
switch(dst.file) {
@@ -577,7 +577,7 @@ glsl_to_tgsi_visitor::emit(ir_instruction *ir, unsigned op,
}
}
else {
- for (i=0; i<4; i++) {
+ for (i = 0; i < 4; i++) {
if(inst->src[i].reladdr) {
switch(inst->src[i].file) {
case PROGRAM_STATE_VAR:
@@ -610,14 +610,14 @@ glsl_to_tgsi_visitor::emit(ir_instruction *ir, unsigned
op,
glsl_to_tgsi_instruction *
glsl_to_tgsi_visitor::emit(ir_instruction *ir, unsigned op,
-st_dst_reg dst, st_src_reg src0, st_src_reg src1)
+ st_dst_reg dst, st_src_reg src0, st_src_reg src1)
{
return emit(ir, op, dst, src0, src1, undef_src, undef_src);
}
glsl_to_tgsi_instruction *
glsl_to_tgsi_visitor::emit(ir_instruction *ir, unsigned op,
-st_dst_reg dst, st_src_reg src0)
+ st_dst_reg dst, st_src_reg src0)
{
assert(dst.writemask != 0);
return emit(ir, op, dst, src0, undef_src, undef_src, undef_src);
@@ -630,13 +630,13 @@ glsl_to_tgsi_visitor::emit(ir_instruction *ir, unsigned
op)
}
/**
- * Determines whether to use an integer, unsigned integer, or float opcode
+ * Determines whether to use an integer, unsigned integer, or float opcode
* based on the operands and input opcode, then emits the result.
*/
unsigned
glsl_to_tgsi_visitor::get_opcode(ir_instruction *ir, unsigned op,
-st_dst_reg dst,
-st_src_reg src0, st_src_reg src1)
+ st_dst_reg dst,
+
Re: [Mesa-dev] [LLVMdev] mesa-10.4.4: BROKEN TLS support in GLXwith llvm-toolchain v3.6.0rc2
On Mon, Feb 16, 2015 at 10:39 AM, Marc Dietrich wrote: > Am Samstag, 14. Februar 2015, 18:20:12 schrieb Dimitry Andric: >> On 11 Feb 2015, at 11:16, Sedat Dilek wrote: >> > On Wed, Feb 11, 2015 at 12:09 AM, Emil Velikov > wrote: >> >> On 10/02/15 13:17, Dimitry Andric wrote: >> >>> On 09 Feb 2015, at 18:52, Sedat Dilek wrote: >> On Mon, Feb 9, 2015 at 6:44 PM, Emil Velikov > wrote: >> > On 07/02/15 22:42, Sedat Dilek wrote: >> >>> ... >> >>> >> >> In file included from ../../src/mapi/entry.c:49: >> >> ./entry_x86-64_tls.h:66:1: warning: tentative array definition >> >> assumed >> >> to have one element >> >> x86_64_entry_start[]; >> >> ^ >> >> fatal error: error in backend: symbol 'x86_64_entry_start' is already >> >> defined>>> >> >>> ... >> >>> >> > It may be that it's a bug on our end, but it's a bit painful going >> > through all the auto generated sources, the 10+ define guards and >> > other >> > magic that's inside src/mapi. Getting some idea on llvm/clang >> > behaviour >> > change should help out :-) >> > >> > Please open a bug-report with llvm and/or mesa, so that we have all >> > the >> > info in one place and things don't get lost. >> >> I am unsure if it is a bug in llvm/clang or in mesa. >> Shall I open 2 bug-reports - in mesa and llvm BTS? >> >>> >> >>> Please have a look at this PR, which I opened in May 2014, and which is > about the same issue: >> >>> http://llvm.org/PR19778 >> >> >> >> Hi Dimitry, >> >> >> >> From a quick look at the bug, the llvm/clang devs are quoting the C11 >> >> spec, yet we're not building with -std=c11 so I'm not sure that applies. >> >> Feel free to forward that if interested - I'm a bit short on account on >> >> their bugzilla :-) >> >> >> >>> The assertion seems to have been transformed now into a backend error, >> >>> but this may also be because you built clang without assertions. (Did >> >>> you?)>>> >> >>> In any case, the workaround is to change the static symbols into extern > symbols, together with a hidden visibility attribute (as suggested by Rafael > Espíndola), similar to the fix I posted in this FreeBSD port bug: >> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192286 >> >>> >> >>> E.g., you can use these patches: >> >>> >> >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src__ma >> >>> pi__entry_x86-64_tls.h?view=markup >> >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src__m >> >>> api__entry_x86_tls.h?view=markup >> >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src__m >> >>> api__entry_x86_tsd.h?view=markup>> >> >> These patches don't look at all bad. Can you give them a bit of TLS and >> >> send them to the list, please ? This also stands for the other patches >> >> in FreeBSD's repo :-) >> > >> > On the one hand I am glad to see that there are patches available. >> > I will give them a try when I am at home. >> > On the other hand - knowing FreeBSD switched to llvm/clang as >> > default-compiler - it's abit pity to see that stuff like this is not >> > shared with upstream (did not look at the date of submission). >> > If you have more patches in this area, please share them with upstream. >> >> The complete collection is here: >> >> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/ >> >> I didn't create most of these patches, so I can't really say what the >> reason for them was, or whether they still apply to Mesa master. >> >> In any case, for this specific issue with Mesa's TLS related definitions >> breaking clang, please consider the attached patch. > > I think there is no need to restrict this to clang only as it also works with > gcc. I submitted a slightly different version to the mesa list which uses a > macro instead and also adds some credits. > Sorry for the late response... troubles with my Internet connection. Those two patches or do I need more? [PATCH 1/4] configure: add visibility macro detection to configure [PATCH 2/4] add visibility hidden to tls entry points Regards, - Sedat - [1] http://lists.freedesktop.org/archives/mesa-dev/2015-February/076980.html [2] http://lists.freedesktop.org/archives/mesa-dev/2015-February/076979.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v5 29/29] glsl/tests: add DOUBLE/IMAGE types
On 10 February 2015 at 21:59, Ilia Mirkin wrote: > Signed-off-by: Ilia Mirkin This makes sense but the warning is there now, so I tore out the IMAGE bits and pushed them. The double bits are, Reviewed-by: Dave Airlie Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v5 28/29] glsl: add a lowering pass for frexp/ldexp with double arguments
On 10 February 2015 at 21:59, Ilia Mirkin wrote: > Signed-off-by: Ilia Mirkin Looks good to me, Reviewed-by: Dave Airlie ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v5 08/29] glsl: fix uniform linking logic in the presence of structs
On 17 February 2015 at 06:01, Ilia Mirkin wrote: > On Tue, Feb 10, 2015 at 6:58 AM, Ilia Mirkin wrote: >> Add a enter/leave record callback so that the offset may be aligned to >> the proper value. Otherwise only leaf fields are called, and the first >> field needs to be aligned to the outer struct's base alignment while the >> last field needs to be aligned to the inner struct's base alignment. >> >> This removes most usage of the last field/record type values passed into >> visit_field. >> >> Signed-off-by: Ilia Mirkin This seems like the correct solution, hopefully Ian can further examine this, but it seems to fix the problems seen. Reviewed-by: Dave Airlie ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89107] [Radeonsi/Hawaii] Rendering errors when running basic opengl 3 demo
https://bugs.freedesktop.org/show_bug.cgi?id=89107 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG -- 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 89152] glBlitFramebuffer always "bad src/dst multisample pixel formats", when src fbo is multisample
https://bugs.freedesktop.org/show_bug.cgi?id=89152 Michel Dänzer changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|Mesa core Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org --- Comment #1 from Michel Dänzer --- I'm hitting several other GL error conditions first: Mesa: User error: GL_INVALID_VALUE in glSampleMaski(index) Mesa: User error: GL_INVALID_ENUM in glFramebufferTextureLayer(target=0x1) Mesa: User error: GL_INVALID_ENUM in glDrawElementsInstanced(mode=8ca8) Mesa: User error: GL_INVALID_OPERATION in glFramebufferTexture Mesa: User error: GL_INVALID_ENUM in glBindRenderbufferEXT(target) glGetError = GL_INVALID_VALUE Try running the app with a debugging build of Mesa in gdb and setting a breakpoint on _mesa_error. -- 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 89131] [Bisected] Graphical corruption in Weston, shows old framebuffer pieces
https://bugs.freedesktop.org/show_bug.cgi?id=89131 Michel Dänzer changed: What|Removed |Added CC||pjm0...@gmail.com Component|EGL/Wayland |Mesa core Assignee|wayland-bugs@lists.freedesk |mesa-dev@lists.freedesktop. |top.org |org --- Comment #4 from Michel Dänzer --- Sounds like maybe pp_jimenezmlaa gets enabled even when there's no depth buffer. Do you really want to use those post-processing effects with weston, though? :) -- 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] st:glsl_to_tgsi: fix whitespace
[re-adding mesa-dev, dropped by accident] On Mon, Feb 16, 2015 at 11:48 PM, Ilia Mirkin wrote: > On Mon, Feb 16, 2015 at 7:06 PM, Dave Airlie wrote: >> From: Dave Airlie >> >> everytime I open this file in emacs with show trailing whitespace >> or git add from it my screen flares with red. >> >> Just do a general cleanup, makes working on fp64 support not as >> jarring. >> >> I'm not saying this is perfect, its just better than before. >> >> Signed-off-by: Dave Airlie > > Fix the subject (st/, not st:), and this is > > Reviewed-by: Ilia Mirkin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89131] [Bisected] Graphical corruption in Weston, shows old framebuffer pieces
https://bugs.freedesktop.org/show_bug.cgi?id=89131 --- Comment #5 from Park, Jeongmin --- I moved depth buffer checks from dri*.c to pp_jimenezmlaa() per Brian's comment here: https://bugs.freedesktop.org/show_bug.cgi?id=88962 depth buffer check was added to pp_mlaa.c in 2e6ba6afdb62e80689b844c7267272d261db172c and removed from dri*.c in 0467a52dc3f7d51eeb51179ce2f9871758ecacb1 This bug seems to be caused by my patch didn't check if pp_jimenezmlaa() was failed. In pp_run.c, if there are multiple postprocess stages(ppq->n_filters > 1) so that it requires a temp buffer(ppq->tmp[]), and pp_jimenzmlaa return immediately without writing to 'out', then the temp buffer would have old data. -- 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 89152] glBlitFramebuffer always "bad src/dst multisample pixel formats", when src fbo is multisample
https://bugs.freedesktop.org/show_bug.cgi?id=89152 --- Comment #2 from Tapani Pälli --- program prints no errors when run on i965 (tested on haswell) -- 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
