Re: [Mesa-dev] [PATCH 1/5] swr/rast: Remove unneeded virtual from methods

[Kyriazis, George]

Whole series

Reviewed-By: George Kyriazis 
>

Thanks!


On May 16, 2018, at 11:14 AM, Alok Hota 
> wrote:

---
src/gallium/drivers/swr/rasterizer/jitter/JitManager.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.h 
b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.h
index 54a25d8..152776a 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.h
+++ b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.h
@@ -108,12 +108,12 @@ public:
}

/// notifyObjectCompiled - Provides a pointer to compiled code for Module M.
-virtual void notifyObjectCompiled(const llvm::Module *M, 
llvm::MemoryBufferRef Obj);
+void notifyObjectCompiled(const llvm::Module *M, llvm::MemoryBufferRef 
Obj) override;

/// Returns a pointer to a newly allocated MemoryBuffer that contains the
/// object which corresponds with Module M, or 0 if an object is not
/// available.
-virtual std::unique_ptr getObject(const llvm::Module* 
M);
+std::unique_ptr getObject(const llvm::Module* M) 
override;

private:
std::string mCpu;
--
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr: Fix include for createInstructionCombiningPass with llvm-7.0.

[Kyriazis, George]

It would be nice to avoid the extra #if LLVM_VERSION_MAJOR and include 
InstCombine.h into the same #if below, as follows:

--- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
@@ -69,6 +69,7 @@ using PassManager = llvm::legacy::PassManager;
#include "llvm/Transforms/Scalar.h"
#if LLVM_VERSION_MAJOR >= 7
#include "llvm/Transforms/Utils.h"
+#include "llvm/Transforms/InstCombine/InstCombine.h"
#endif
#include "llvm/Support/Host.h"
#include "llvm/Support/DynamicLibrary.h”

With the above change

Reviewed-By: George Kyriazis 
>

Thanks

George

On Apr 29, 2018, at 1:40 AM, Vinson Lee 
> wrote:

Fix build error after llvm-7.0.0svn r330669 ("InstCombine: Fix layering
by not including Scalar.h in InstCombine").

 CXX  rasterizer/jitter/libmesaswr_la-blend_jit.lo
rasterizer/jitter/blend_jit.cpp:816:20: error: use of undeclared identifier 
'createInstructionCombiningPass'; did you mean 
'createInstructionSimplifierPass'?
   passes.add(createInstructionCombiningPass());
  ^~
  createInstructionSimplifierPass

Signed-off-by: Vinson Lee >
---
src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp | 3 +++
1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp 
b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
index 216938fa7b07..6e4d24dde8fa 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
@@ -66,6 +66,9 @@ using PassManager = llvm::legacy::PassManager;
#include "llvm/Support/TargetSelect.h"
#include "llvm/Support/DynamicLibrary.h"
#include "llvm/Transforms/IPO.h"
+#if LLVM_VERSION_MAJOR >= 7
+#include "llvm/Transforms/InstCombine/InstCombine.h"
+#endif
#include "llvm/Transforms/Scalar.h"
#if LLVM_VERSION_MAJOR >= 7
#include "llvm/Transforms/Utils.h"
--
2.17.0


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr/rast: Fix WriteBitcodeToFile usage with llvm-7.0.

[Kyriazis, George]

Reviewed-By: George Kyriazis 
>


On May 1, 2018, at 2:05 AM, Vinson Lee 
> wrote:

Fix build error after llvm-7.0svn r325155 ("Pass a reference to a module
to the bitcode writer.").

 CXX  rasterizer/jitter/libmesaswr_la-JitManager.lo
rasterizer/jitter/JitManager.cpp:548:30: error: reference to type 'const 
llvm::Module' could not bind to an lvalue of type 'const llvm::Module *'
   llvm::WriteBitcodeToFile(M, bitcodeStream);
^

Suggested-by: George Kyriazis 
>
Signed-off-by: Vinson Lee >
---
src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp | 4 
1 file changed, 4 insertions(+)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp 
b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
index aadcca25550f..efb747abdee8 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
@@ -545,7 +545,11 @@ static inline uint32_t ComputeModuleCRC(const 
llvm::Module* M)
std::string bitcodeBuffer;
raw_string_ostream bitcodeStream(bitcodeBuffer);

+#if LLVM_VERSION_MAJOR >= 7
+llvm::WriteBitcodeToFile(*M, bitcodeStream);
+#else
llvm::WriteBitcodeToFile(M, bitcodeStream);
+#endif
//M->print(bitcodeStream, nullptr, false);

bitcodeStream.flush();
--
2.17.0


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr: Fix include for createInstructionCombiningPass with llvm-7.0.

[Kyriazis, George]

This patch does not address all the compile issues with llvm trunk (at least 
the ones that I see in my build).

The following patch, however, works:

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp 
b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
index aadcca2..efb747a 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
@@ -545,7 +545,11 @@ static inline uint32_t ComputeModuleCRC(const 
llvm::Module* M)
 std::string bitcodeBuffer;
 raw_string_ostream bitcodeStream(bitcodeBuffer);
 
+#if LLVM_VERSION_MAJOR >= 7
+llvm::WriteBitcodeToFile(*M, bitcodeStream);
+#else
 llvm::WriteBitcodeToFile(M, bitcodeStream);
+#endif
 //M->print(bitcodeStream, nullptr, false);
 
 bitcodeStream.flush();
diff --git a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp 
b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
index 216938f..001a1ab 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
@@ -69,6 +69,7 @@ using PassManager = llvm::legacy::PassManager;
 #include "llvm/Transforms/Scalar.h"
 #if LLVM_VERSION_MAJOR >= 7
 #include "llvm/Transforms/Utils.h"
+#include "llvm/Transforms/InstCombine/InstCombine.h"
 #endif
 #include "llvm/Support/Host.h"
 #include "llvm/Support/DynamicLibrary.h"

Please feel free to use that as a v2 (since you are already started the patch 
thread), and I will review.

Thanks,

George
 

> On Apr 29, 2018, at 1:40 AM, Vinson Lee  wrote:
> 
> Fix build error after llvm-7.0.0svn r330669 ("InstCombine: Fix layering
> by not including Scalar.h in InstCombine").
> 
>  CXX  rasterizer/jitter/libmesaswr_la-blend_jit.lo
> rasterizer/jitter/blend_jit.cpp:816:20: error: use of undeclared identifier 
> 'createInstructionCombiningPass'; did you mean 
> 'createInstructionSimplifierPass'?
>passes.add(createInstructionCombiningPass());
>   ^~
>   createInstructionSimplifierPass
> 
> Signed-off-by: Vinson Lee 
> ---
> src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp | 3 +++
> 1 file changed, 3 insertions(+)
> 
> diff --git a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp 
> b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> index 216938fa7b07..6e4d24dde8fa 100644
> --- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> +++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> @@ -66,6 +66,9 @@ using PassManager = llvm::legacy::PassManager;
> #include "llvm/Support/TargetSelect.h"
> #include "llvm/Support/DynamicLibrary.h"
> #include "llvm/Transforms/IPO.h"
> +#if LLVM_VERSION_MAJOR >= 7
> +#include "llvm/Transforms/InstCombine/InstCombine.h"
> +#endif
> #include "llvm/Transforms/Scalar.h"
> #if LLVM_VERSION_MAJOR >= 7
> #include "llvm/Transforms/Utils.h"
> -- 
> 2.17.0
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] Autotools: Add passes.h to sources so it will be included in the tarball

[Kyriazis, George]

I agree on the commit message wording.

Sorry about missing passes.h in the original check-in.

Reviewed-by: George Kyriazis 
>

On Apr 20, 2018, at 10:00 PM, Kenneth Graunke 
> wrote:

On Friday, April 20, 2018 7:19:50 PM PDT Dylan Baker wrote:
Signed-off-by: Dylan Baker 
>
---
src/gallium/drivers/swr/Makefile.sources | 1 +
1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/swr/Makefile.sources 
b/src/gallium/drivers/swr/Makefile.sources
index dd815dcb581..a06d1d7b929 100644
--- a/src/gallium/drivers/swr/Makefile.sources
+++ b/src/gallium/drivers/swr/Makefile.sources
@@ -155,6 +155,7 @@ JITTER_CXX_SOURCES := \
rasterizer/jitter/streamout_jit.cpp \
rasterizer/jitter/streamout_jit.h \
rasterizer/jitter/shader_lib/DebugOutput.cpp \
+ rasterizer/jitter/functionpasses/passes.h \
rasterizer/jitter/functionpasses/lower_x86.cpp

MEMORY_CXX_SOURCES := \


I would add the following to the commit message:

This was introduced in commit 8f848ada8a42d9aaa8136afa1bafe32281a0fb48
but not added to the sources list, which is necessary for it to be
included in release tarballs.

Fixes: 8f848ada8a42d9aaa8136afa1bafe32281a0fb48 (swr/rast: Start refactoring of 
builder/packetizer.)
Reviewed-by: Kenneth Graunke 
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr: Remove unnecessary memset call

[Kyriazis, George]

Reviewed-By: George Kyriazis 
>


On Apr 12, 2018, at 8:49 PM, Vlad Golovkin 
> wrote:

Zeroing memory after calloc is not necessary. This also allows to avoid
possible crash when allocation fails, because memset is called before
checking screen for NULL.
---
src/gallium/drivers/swr/swr_screen.cpp | 1 -
1 file changed, 1 deletion(-)

diff --git a/src/gallium/drivers/swr/swr_screen.cpp 
b/src/gallium/drivers/swr/swr_screen.cpp
index 880a177c39..4e43ac55fb 100644
--- a/src/gallium/drivers/swr/swr_screen.cpp
+++ b/src/gallium/drivers/swr/swr_screen.cpp
@@ -1130,7 +1130,6 @@ struct pipe_screen *
swr_create_screen_internal(struct sw_winsys *winsys)
{
   struct swr_screen *screen = CALLOC_STRUCT(swr_screen);
-   memset(screen, 0, sizeof(struct swr_screen));

   if (!screen)
  return NULL;
--
2.14.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 4/4] swr: Fix include for createPromoteMemoryToRegisterPass

[Kyriazis, George]

Thank you!

Reviewed-By: George Kyriazis 
>

On Apr 4, 2018, at 3:22 AM, Mike Lothian 
> wrote:

Include llvm/Transforms/Utils.h with the newest LLVM 7

v2: Include with " " rather than < > (Vinson Lee)

v3: Use LLVM_VERSION_MAJOR rather than HAVE_LLVM (George Kyriazis)

Signed-of-by: Mike Lothian >
Tested-by: Vinson Lee >
---
src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp | 3 +++
1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp 
b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
index 031bced8a0..19f68c2bb6 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
@@ -67,6 +67,9 @@ using PassManager = llvm::legacy::PassManager;
#include "llvm/Support/DynamicLibrary.h"
#include "llvm/Transforms/IPO.h"
#include "llvm/Transforms/Scalar.h"
+#if LLVM_VERSION_MAJOR >= 7
+#include "llvm/Transforms/Utils.h"
+#endif
#include "llvm/Support/Host.h"
#include "llvm/Support/DynamicLibrary.h"

--
2.17.0


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] swr: Fix include for createPromoteMemoryToRegisterPass

[Kyriazis, George]

Please use LLVM defines consistent with the surrounding code.  Surrounding code 
uses LLVM_VERSION_MAJOR / LLVM_VERSION_MINOR.

This code should then be:

#if LLVM_VERSION_MAJOR >= 7
…
#endif

Thank you!

George

> On Apr 1, 2018, at 3:05 PM, Vinson Lee  wrote:
> 
> On Sun, Apr 1, 2018 at 1:10 AM, Mike Lothian  wrote:
>> Include llvm/Transforms/Utils.h with the newest LLVM 7
>> 
>> Signed-of-by: Mike Lothian 
>> ---
>> src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp | 3 +++
>> 1 file changed, 3 insertions(+)
>> 
>> diff --git a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp 
>> b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
>> index 031bced8a0..d726d4844e 100644
>> --- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
>> +++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
>> @@ -67,6 +67,9 @@ using PassManager = llvm::legacy::PassManager;
>> #include "llvm/Support/DynamicLibrary.h"
>> #include "llvm/Transforms/IPO.h"
>> #include "llvm/Transforms/Scalar.h"
>> +#if HAVE_LLVM >= 0x0700
>> +#include 
>> +#endif
>> #include "llvm/Support/Host.h"
>> #include "llvm/Support/DynamicLibrary.h"
>> 
>> --
>> 2.16.3
>> 
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> 
> The added include uses <> delimiters whereas the other includes use ""
> delimiters.
> 
> Tested-by: Vinson Lee 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] autotools: include all meson.build files

[Kyriazis, George]

Reviewed-By: George Kyriazis 
>

On Mar 2, 2018, at 12:00 PM, Dylan Baker 
> wrote:

Otherwise SWR cannot be built with meson from an autotools generated
tarball, such as the 18.0.0-rc4 tarball.

CC: George Kyriazis 
>
CC: Emil Velikov >
Fixes: 16bf81383080 ("meson/swr: re-shuffle generated files")
Signed-off-by: Dylan Baker 
>
---
src/gallium/drivers/swr/Makefile.am | 2 ++
1 file changed, 2 insertions(+)

diff --git a/src/gallium/drivers/swr/Makefile.am 
b/src/gallium/drivers/swr/Makefile.am
index 2edaf666f11..13c7f8b7345 100644
--- a/src/gallium/drivers/swr/Makefile.am
+++ b/src/gallium/drivers/swr/Makefile.am
@@ -364,7 +364,9 @@ endif
EXTRA_DIST = \
SConscript \
meson.build \
+ rasterizer/jitter/meson.build \
rasterizer/codegen/meson.build \
+ rasterizer/core/backends/meson.build \
rasterizer/archrast/events.proto \
rasterizer/codegen/gen_llvm_ir_macros.py \
rasterizer/codegen/gen_llvm_types.py \
--
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr/rast: Fix macOS macro.

[Kyriazis, George]

Yes, a typo on our end.

Thank you!

Reviewed-By: George Kyriazis 
>

On Feb 24, 2018, at 5:55 PM, Vinson Lee 
> wrote:

Fixes: a25093de7188 ("swr/rast: Implement JIT shader caching to disk")
Signed-off-by: Vinson Lee >
---
src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp 
b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
index ab7c6eb15b09..0cefa43529fc 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
@@ -47,7 +47,7 @@
#define JITTER_OUTPUT_DIR SWR_OUTPUT_DIR "\\Jitter"
#endif // _WIN32

-#if defined(__APPLE) || defined(FORCE_LINUX) || defined(__linux__) || 
defined(__gnu_linux__)
+#if defined(__APPLE__) || defined(FORCE_LINUX) || defined(__linux__) || 
defined(__gnu_linux__)
#include 
#include 
#endif
@@ -532,7 +532,7 @@ static inline uint32_t ComputeModuleCRC(const llvm::Module* 
M)
/// constructor
JitCache::JitCache()
{
-#if defined(__APPLE) || defined(FORCE_LINUX) || defined(__linux__) || 
defined(__gnu_linux__)
+#if defined(__APPLE__) || defined(FORCE_LINUX) || defined(__linux__) || 
defined(__gnu_linux__)
if (strncmp(KNOB_JIT_CACHE_DIR.c_str(), "~/", 2) == 0) {
char *homedir;
if (!(homedir = getenv("HOME"))) {
--
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Patch submit question

[Kyriazis, George]

It’s a commit that needs to be slightly different in master and 18.0, hence 2x 
the # of commits.

Thanks for the 662cff8f pointer.  Perfect example!


George

> On Feb 26, 2018, at 4:14 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> 
> On 26 February 2018 at 20:18, Kyriazis, George
> <george.kyria...@intel.com> wrote:
>> Thanks Jordan,
>> 
>> Since I won’t be checking this in to mesa master, what do I need to do to 
>> actually push it to the stable branch, after I get a review on mesa-dev?
>> 
> When possible, please refrain from pushing to the stable branch.
> 
> If there's no equivalent in master - following Jordan's example is
> amazing - explicit prefix + clear note it's does not exist in master.
> Alternatively please keep track to the original patch - see
> 662cff8fe4c5cd06b7cb44edefdc2d182b8328d8 for reference.
> 
> Thanks
> Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Patch submit question

[Kyriazis, George]

Thanks Jordan,

Since I won’t be checking this in to mesa master, what do I need to do to 
actually push it to the stable branch, after I get a review on mesa-dev?

George

> On Feb 23, 2018, at 5:43 PM, Justen, Jordan L <jordan.l.jus...@intel.com> 
> wrote:
> 
> On 2018-02-23 13:20:21, Kyriazis, George wrote:
>> Hello mesa-dev,
>> 
>> I have a quick patch submission question:
>> 
>> I have a patch that I’d like to also nominate to mesa-stable
>> (specifically 18.0.1 or 18.0.2), however the same patch is different
>> between master and stable branches, due to neighboring code having
>> changed in the meantime.
>> 
>> What’s the best process of submitting / pushing this sort of change?
> 
> 719f2c934030f74ce0a4892233f494f168852698 was an 18.0 specific patch. I
> Cc'd 18.0 in the commit message:
> 
> Cc: "18.0" <mesa-sta...@lists.freedesktop.org>
> 
> And, I used:
> 
> git format-patch --subject-prefix=PATCH\ 18.0
> 
> You might also add "Fixes" to the commit message if applicable, even
> though in this case it wouldn't be used to trigger cherry-picking to
> the stable branch.
> 
> -Jordan

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/15] glsl: Switch ast_type_qualifier to a 128-bit bitset.

[Kyriazis, George]

It also fixes the errors that I was getting with gcc 5.4.0 with configure build 
on ubuntu 16.04.

Tested-By: George Kyriazis 
>

On Feb 25, 2018, at 6:52 PM, Roland Scheidegger 
> wrote:

Am 25.02.2018 um 21:12 schrieb Francisco Jerez:
Roland Scheidegger > writes:

Am 25.02.2018 um 03:35 schrieb Francisco Jerez:
Roland Scheidegger > writes:

This seems to have broken compilation with some gcc versions (with scons
build):

In file included from src/compiler/glsl/ast_array_index.cpp:24:0:
src/compiler/glsl/ast.h:648:16: error: member
‘ast_type_qualifier::bitset_t ast_type_qualifier::flags::i’ with
constructor not allowed in union
  bitset_t i;
   ^

Oops...  And the only reason bitset_t has a default constructor was...
to avoid using another C++11 feature (defaulted member functions).
Does the attached patch fix the build failure for you?  The cleaner
alternative would be to define the default constructor of the bitset
object like 'T() = default', but that would imply dropping support for
GCC 4.2-4.3 which don't implement the feature...

FWIW the compile error was happening with gcc 4.8 - I didn't see it with
gcc 5.4.
(I don't think at vmware we'd care about anything older than gcc 4.4 at
least but last time someone wanted to bump gcc requirements there were
still people requiring gcc 4.2.)

The patch compiles albeit there's about two dozen warnings like the
following:
glsl/ast_type.cpp: In member function 'bool
ast_fully_specified_type::has_qualifiers(_mesa_glsl_parse_state*) const':
glsl/ast_type.cpp:50:67: warning: ISO C++ says that these are ambiguous,
even though the worst conversion for the first is better than the worst
conversion for the second: [enabled by default]
   return (this->qualifier.flags.i & ~subroutine_only.flags.i) != 0;
  ^
In file included from glsl/ast.h:31:0,
from glsl/ast_type.cpp:24:
../../src/util/bitset.h:181:7: note: candidate 1: bool operator!=(const
ast_type_qualifier::bitset_t&, unsigned int)
  operator!=(const T , BITSET_WORD x) \
  ^
glsl/ast.h:477:4: note: in expansion of macro 'DECLARE_BITSET_T'
   DECLARE_BITSET_T(bitset_t, 128);
   ^
glsl/ast_type.cpp:50:67: note: candidate 2: operator!=(int, int) 
   return (this->qualifier.flags.i & ~subroutine_only.flags.i) != 0;
  ^
Roland


Ah, yeah, that's because I didn't provide overloads for signed integer
types, but it should be harmless since the two candidates have the same
semantics, and should go away with a C++11-capable compiler.  I think
the attached patch should shut the warnings on older compilers.

Yes, that compiles without warnings (with gcc 4.8)
Tested-by: Roland Scheidegger >






src/compiler/glsl/ast.h:648:16: note: unrestricted unions only available
with -std=c++11 or -std=gnu++11
scons: *** [build/linux-x86_64-checked/compiler/glsl/ast_array_index.os]
Error 1
src/gallium/tests/unit/u_format_test.c: In function ‘main’:
src/gallium/tests/unit/u_format_test.c:649:44: warning: array subscript
is above array bounds [-Warray-bounds]
 unpacked[i][j] = test->unpacked[i][j][1];
   ^
In file included from src/compiler/glsl/ast_expr.cpp:24:0:
src/compiler/glsl/ast.h:648:16: error: member
‘ast_type_qualifier::bitset_t ast_type_qualifier::flags::i’ with
constructor not allowed in union
  bitset_t i;
   ^
src/compiler/glsl/ast.h:648:16: note: unrestricted unions only available
with -std=c++11 or -std=gnu++11

Roland

[...]



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): glsl: Switch ast_type_qualifier to a 128-bit bitset.

[Kyriazis, George]

Hello Francisco,

This change breaks my ubuntu 16.04 build with gcc 5.4.0.  Here’t where it 
breaks:

  CXX  glsl/glsl_lexer.lo
In file included from ../../../src/compiler/glsl/glsl_lexer.ll:27:0:
../../../src/compiler/glsl/ast.h:643:16: error: member 
‘ast_type_qualifier::bitset_t ast_type_qualifier::flags::i’ with constructor 
not allowed in union
   bitset_t i;
^
../../../src/compiler/glsl/ast.h:643:16: note: unrestricted unions only 
available with -std=c++11 or -std=gnu++11
In file included from ../../../src/compiler/glsl/glsl_lexer.ll:29:0:
../../../src/compiler/glsl/glsl_parser.yy:106:30: error: member 
‘ast_type_qualifier YYSTYPE::type_qualifier’ with constructor not allowed in 
union
struct ast_type_qualifier type_qualifier;
  ^
glsl/glsl_lexer.cpp: In function ‘int yy_get_next_buffer(yyscan_t)’:
glsl/glsl_lexer.cpp:3490:47: warning: comparison between signed and unsigned 
integer expressions [-Wsign-compare]
  if ((int) (yyg->yy_n_chars + number_to_move) > 
YY_CURRENT_BUFFER_LVALUE->yy_buf_
   ^
Makefile:2489: recipe for target 'glsl/glsl_lexer.lo’ failed

The following fixes it:

diff --git a/src/compiler/Makefile.am b/src/compiler/Makefile.am
index fd6811f..76a9a7f 100644
--- a/src/compiler/Makefile.am
+++ b/src/compiler/Makefile.am
@@ -47,6 +47,7 @@ AM_CFLAGS = \
 
 AM_CXXFLAGS = \
$(VISIBILITY_CXXFLAGS) \
+   $(CXX11_CXXFLAGS) \
$(MSVC2013_COMPAT_CXXFLAGS)
 
 noinst_LTLIBRARIES = libcompiler.la
diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am
index 195e440..fb4abc1 100644
--- a/src/mesa/Makefile.am
+++ b/src/mesa/Makefile.am
@@ -118,6 +118,7 @@ AM_CFLAGS = \
 AM_CXXFLAGS = \
$(LLVM_CFLAGS) \
$(VISIBILITY_CXXFLAGS) \
+   $(CXX11_CXXFLAGS) \
$(MSVC2013_COMPAT_CXXFLAGS)
 
 ARCH_LIBS =


I am not sure if it is the best place to put this flag, but the basic idea is 
that -std=c++11 needs to be added to compile those files.

Thanks,

George


> On Feb 24, 2018, at 6:34 PM, Francisco Jerez 
>  wrote:
> 
> Module: Mesa
> Branch: master
> Commit: ba79a90fb52e1e81fbfb38113e85a56b13497c50
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=ba79a90fb52e1e81fbfb38113e85a56b13497c50
> 
> Author: Francisco Jerez 
> Date:   Mon Feb 12 14:18:15 2018 -0800
> 
> glsl: Switch ast_type_qualifier to a 128-bit bitset.
> 
> This should end the drought of bits in the ast_type_qualifier object.
> The bitset_t type works pretty much as a drop-in replacement for the
> current uint64_t bitset.
> 
> The only catch is that the bitset_t type as defined in the previous
> commit doesn't have a trivial constructor (because it has a
> user-defined constructor), so it cannot be used as union member
> without providing a user-defined constructor for the union (which
> causes it in turn to be non-trivially constructible).  This annoyance
> could be easily addressed in C++11 by declaring the default
> constructor of bitset_t to be the implicitly defined one -- IMO one
> more reason to drop support for GCC 4.2-4.3.
> 
> The other minor change was required because glsl_parser_extras.cpp was
> hard-coding the type of bitset temporaries as uint64_t, which (unlike
> would have been the case if the uint64_t had been replaced with
> e.g. an __int128) would otherwise have caused a build failure, because
> the boolean conversion operator of bitset_t is marked explicit (if
> C++11 is available), so the bitset won't be silently truncated down to
> 1 bit in order to use it to initialize the uint64_t temporaries
> (yikes).
> 
> Reviewed-by: Plamena Manolova 
> 
> ---
> 
> src/compiler/glsl/ast.h  | 8 ++--
> src/compiler/glsl/glsl_parser.yy | 1 +
> src/compiler/glsl/glsl_parser_extras.cpp | 4 ++--
> 3 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/src/compiler/glsl/ast.h b/src/compiler/glsl/ast.h
> index eee2248281..2a38a4b1f7 100644
> --- a/src/compiler/glsl/ast.h
> +++ b/src/compiler/glsl/ast.h
> @@ -28,6 +28,7 @@
> #include "list.h"
> #include "glsl_parser_extras.h"
> #include "compiler/glsl_types.h"
> +#include "util/bitset.h"
> 
> struct _mesa_glsl_parse_state;
> 
> @@ -473,8 +474,11 @@ enum {
> 
> struct ast_type_qualifier {
>DECLARE_RALLOC_CXX_OPERATORS(ast_type_qualifier);
> +   DECLARE_BITSET_T(bitset_t, 128);
> +
> +   union flags {
> +  flags() : i(0) {}
> 
> -   union {
>   struct {
>unsigned invariant:1;
>  unsigned precise:1;
> @@ -636,7 +640,7 @@ struct ast_type_qualifier {
>   q;
> 
>   /** \brief Set of flags, accessed as a bitmask. */
> -  uint64_t i;
> +  bitset_t i;
>} flags;
> 
>/** Precision of the type (highp/medium/lowp). */
> diff --git a/src/compiler/glsl/glsl_parser.yy 
> b/src/compiler/glsl/glsl_parser.yy
> index 19147c7a3e..4faf9602a0 100644
> --- 

[Mesa-dev] Patch submit question

[Kyriazis, George]

Hello mesa-dev,

I have a quick patch submission question:

I have a patch that I’d like to also nominate to mesa-stable (specifically 
18.0.1 or 18.0.2), however the same patch is different between master and 
stable branches, due to neighboring code having changed in the meantime.

What’s the best process of submitting / pushing this sort of change?

Thank you!

George

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx: Properly handle cases where screen creation fails

[Kyriazis, George]

I believed I created the same failure by deleting libswr*.so, however in my 
case (running glxgears) I hit a SEGV in XMesaCreateVisual (calling 
xmdpy->screen->is_format_supported()), because xmesa_init_display() created an 
xmdpy with a NULL screen.  I never get to the xmesa_close_display().

Were you just testing with vtk, and maybe hitting a localized issue?  Looks 
like the failure needs to be taken care of when the screen is initialized the 
first time.

George

On Feb 21, 2018, at 12:13 PM, Chuck Atkins 
<chuck.atk...@kitware.com<mailto:chuck.atk...@kitware.com>> wrote:

Hi George,

This first showed up on one of our older dashboard machines without AVX 
(Nehalem processor).   You can easily reproduce it by building with 
--with-swr-archs=knl,skx when the machine you're trying to use it on is 
neither.  Note that dri-glx seems to handle this case just fine but xlib-glx 
segfaults.

- Chuck


On Wed, Feb 21, 2018 at 12:36 PM, Kyriazis, George 
<george.kyria...@intel.com<mailto:george.kyria...@intel.com>> wrote:
Chuck,

In which cases do you hit this?  When an architecture is not supported, then 
swr_create_screen() falls back to a different (older) architecture.

Thanks,

George

> On Feb 21, 2018, at 8:26 AM, Chuck Atkins 
> <chuck.atk...@kitware.com<mailto:chuck.atk...@kitware.com>> wrote:
>
> This fixes a segfault exposed by a29d63ecf7 which occurs when swr is
> used on an unsupported architecture.
>
> Signed-off-by: Chuck Atkins 
> <chuck.atk...@kitware.com<mailto:chuck.atk...@kitware.com>>
> Cc: 
> mesa-sta...@lists.freedesktop.org<mailto:mesa-sta...@lists.freedesktop.org>
> Cc: George Kyriazis 
> <george.kyria...@intel.com<mailto:george.kyria...@intel.com>>
> Cc: Bruce Cherniak <bruce.chern...@intel.com<mailto:bruce.chern...@intel.com>>
> ---
> src/gallium/state_trackers/glx/xlib/xm_api.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.c 
> b/src/gallium/state_trackers/glx/xlib/xm_api.c
> index 934c0aba11..3aec57e85d 100644
> --- a/src/gallium/state_trackers/glx/xlib/xm_api.c
> +++ b/src/gallium/state_trackers/glx/xlib/xm_api.c
> @@ -182,9 +182,12 @@ xmesa_close_display(Display *display)
> * }
> */
>
> -   if (xmdpy->smapi->destroy)
> -  xmdpy->smapi->destroy(xmdpy->smapi);
> -   free(xmdpy->smapi);
> +   if (xmdpy->smapi)
> +   {
> +  if (xmdpy->smapi->destroy)
> + xmdpy->smapi->destroy(xmdpy->smapi);
> +  free(xmdpy->smapi);
> +   }
>
>XFree((char *) info);
> }
> @@ -767,7 +770,7 @@ XMesaVisual XMesaCreateVisual( Display *display,
>XMesaVisual v;
>GLint red_bits, green_bits, blue_bits, alpha_bits;
>
> -   if (!xmdpy)
> +   if (!xmdpy || !xmdpy->screen)
>   return NULL;
>
>/* For debugging only */
> --
> 2.14.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org<mailto:mesa-dev@lists.freedesktop.org>
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org<mailto:mesa-dev@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx: Properly handle cases where screen creation fails

[Kyriazis, George]

Chuck,

In which cases do you hit this?  When an architecture is not supported, then 
swr_create_screen() falls back to a different (older) architecture.

Thanks,

George

> On Feb 21, 2018, at 8:26 AM, Chuck Atkins  wrote:
> 
> This fixes a segfault exposed by a29d63ecf7 which occurs when swr is
> used on an unsupported architecture.
> 
> Signed-off-by: Chuck Atkins 
> Cc: mesa-sta...@lists.freedesktop.org
> Cc: George Kyriazis 
> Cc: Bruce Cherniak 
> ---
> src/gallium/state_trackers/glx/xlib/xm_api.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.c 
> b/src/gallium/state_trackers/glx/xlib/xm_api.c
> index 934c0aba11..3aec57e85d 100644
> --- a/src/gallium/state_trackers/glx/xlib/xm_api.c
> +++ b/src/gallium/state_trackers/glx/xlib/xm_api.c
> @@ -182,9 +182,12 @@ xmesa_close_display(Display *display)
> * }
> */
> 
> -   if (xmdpy->smapi->destroy)
> -  xmdpy->smapi->destroy(xmdpy->smapi);
> -   free(xmdpy->smapi);
> +   if (xmdpy->smapi)
> +   {
> +  if (xmdpy->smapi->destroy)
> + xmdpy->smapi->destroy(xmdpy->smapi);
> +  free(xmdpy->smapi);
> +   }
> 
>XFree((char *) info);
> }
> @@ -767,7 +770,7 @@ XMesaVisual XMesaCreateVisual( Display *display,
>XMesaVisual v;
>GLint red_bits, green_bits, blue_bits, alpha_bits;
> 
> -   if (!xmdpy)
> +   if (!xmdpy || !xmdpy->screen)
>   return NULL;
> 
>/* For debugging only */
> -- 
> 2.14.3
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr: remove dead LLVM code paths

[Kyriazis, George]

Thank you, Emil, for the cleanup!

Reviewed-By: George Kyriazis 
>

On Feb 20, 2018, at 12:03 PM, Emil Velikov 
> wrote:

From: Emil Velikov 
>

LLVM requirement was bumped to 4.0.0 with earlier commit.
Hence any code tailored for older versions is now unreachable.

Cc: George Kyriazis 
>
Cc: Andres Gomez >
Signed-off-by: Emil Velikov 
>
---
.../drivers/swr/rasterizer/jitter/JitManager.cpp  | 19 ---
.../drivers/swr/rasterizer/jitter/builder_mem.cpp |  5 -
src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp |  4 
3 files changed, 28 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp 
b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
index 8092c144025..ab7c6eb15b0 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
@@ -71,11 +71,6 @@ JitManager::JitManager(uint32_t simdWidth, const char *arch, 
const char* core)
tOpts.NoInfsFPMath = false;
tOpts.NoNaNsFPMath = false;
tOpts.UnsafeFPMath = false;
-#if defined(_DEBUG)
-#if LLVM_VERSION_MAJOR == 3 && LLVM_VERSION_MINOR < 7
-tOpts.NoFramePointerElim = true;
-#endif
-#endif

//tOpts.PrintMachineCode= true;

@@ -249,15 +244,9 @@ DIType* JitManager::GetDebugType(Type* pTy)
switch (id)
{
case Type::VoidTyID: return builder.createUnspecifiedType("void"); break;
-#if LLVM_VERSION_MAJOR >= 4
case Type::HalfTyID: return builder.createBasicType("float16", 16, 
dwarf::DW_ATE_float); break;
case Type::FloatTyID: return builder.createBasicType("float", 32, 
dwarf::DW_ATE_float); break;
case Type::DoubleTyID: return builder.createBasicType("double", 64, 
dwarf::DW_ATE_float); break;
-#else
-case Type::HalfTyID: return builder.createBasicType("float16", 16, 0, 
dwarf::DW_ATE_float); break;
-case Type::FloatTyID: return builder.createBasicType("float", 32, 0, 
dwarf::DW_ATE_float); break;
-case Type::DoubleTyID: return builder.createBasicType("double", 64, 0, 
dwarf::DW_ATE_float); break;
-#endif
case Type::IntegerTyID: return GetDebugIntegerType(pTy); break;
case Type::StructTyID: return GetDebugStructType(pTy); break;
case Type::ArrayTyID: return GetDebugArrayType(pTy); break;
@@ -294,19 +283,11 @@ DIType* JitManager::GetDebugIntegerType(Type* pTy)
IntegerType* pIntTy = cast(pTy);
switch (pIntTy->getBitWidth())
{
-#if LLVM_VERSION_MAJOR >= 4
case 1: return builder.createBasicType("int1", 1, dwarf::DW_ATE_unsigned); 
break;
case 8: return builder.createBasicType("int8", 8, dwarf::DW_ATE_signed); 
break;
case 16: return builder.createBasicType("int16", 16, dwarf::DW_ATE_signed); 
break;
case 32: return builder.createBasicType("int", 32, dwarf::DW_ATE_signed); 
break;
case 64: return builder.createBasicType("int64", 64, dwarf::DW_ATE_signed); 
break;
-#else
-case 1: return builder.createBasicType("int1", 1, 0, 
dwarf::DW_ATE_unsigned); break;
-case 8: return builder.createBasicType("int8", 8, 0, 
dwarf::DW_ATE_signed); break;
-case 16: return builder.createBasicType("int16", 16, 0, 
dwarf::DW_ATE_signed); break;
-case 32: return builder.createBasicType("int", 32, 0, 
dwarf::DW_ATE_signed); break;
-case 64: return builder.createBasicType("int64", 64, 0, 
dwarf::DW_ATE_signed); break;
-#endif
default: SWR_ASSERT(false, "Unimplemented integer bit width");
}
return nullptr;
diff --git a/src/gallium/drivers/swr/rasterizer/jitter/builder_mem.cpp 
b/src/gallium/drivers/swr/rasterizer/jitter/builder_mem.cpp
index f7d0402a3d4..3bba6ff04f3 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/builder_mem.cpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/builder_mem.cpp
@@ -117,12 +117,7 @@ namespace SwrJit
}
else
{
-// maskload intrinsic expects integer mask operand in llvm >= 3.8
-#if (LLVM_VERSION_MAJOR > 3) || (LLVM_VERSION_MAJOR == 3 && LLVM_VERSION_MINOR 
>= 8)
mask = BITCAST(mask, VectorType::get(mInt32Ty, mVWidth));
-#else
-mask = BITCAST(mask, VectorType::get(mFP32Ty, mVWidth));
-#endif
Function *func = Intrinsic::getDeclaration(JM()->mpCurrentModule, 
Intrinsic::x86_avx_maskload_ps_256);
vResult = BITCAST(CALL(func, { src,mask }), 
VectorType::get(mInt32Ty, mVWidth));
}
diff --git a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp 
b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
index 53c03214aad..031bced8a0a 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
@@ -105,12 

Re: [Mesa-dev] [PATCH] swr: bump minimum supported LLVM version to 4.0

[Kyriazis, George]

> On Feb 13, 2018, at 4:54 PM, Dylan Baker  wrote:
> 
> Quoting Andres Gomez (2018-02-13 14:42:57)
> [snip]
>> 
>> -if with_amd_vk or with_gallium_radeonsi
>> +if with_amd_vk or with_gallium_radeonsi or with_gallium_swr
>>   _llvm_version = '>= 4.0.0'
>> -elif with_gallium_opencl or with_gallium_swr or with_gallium_r600
>> +elif with_gallium_opencl or with_gallium_r600
> 
> It's really up to the SWR team what they want to do here, but Meson doesn't
> generate the headers as part of building a dist tarball, it generates them at
> build time whether in git or in a tarball. And doesn't use the ones generated 
> by
> autotools, so it *should* be possible to leave this as 3.9.0 if they like.
> 
It makes sense to be consistent across the board.  Once we switch to 4.0.0, it 
could be confusing to have some aspects of the build still be doable with 
pre-4.0.0 llvm.

> As long as either Tim or George gives an ack or review,
> Reviewed-by: Dylan Baker 



signature.asc
Description: Message signed with OpenPGP
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr: bump minimum supported LLVM version to 4.0

[Kyriazis, George]

I am not an expert on all the changes needed for travis and packaging, but the 
swr changes look good.

Reviewed-by: George Kyriazis 
>

On Feb 13, 2018, at 4:42 PM, Andres Gomez 
> wrote:

Since radv and radeonsi removed support for LLVM 3.9 the distcheck
target got broken because SWR distribution needed 3.9.x.

After checking with George Kyriazis, SWR is OK with moving to LLVM 4.0
and above, which will solve this problem.

Fixes: 3bf1e036e8a ("amd: remove support for LLVM 3.9")
Cc: George Kyriazis 
>
Cc: Tim Rowley >
Cc: Emil Velikov >
Cc: Dylan Baker >
Cc: Eric Engestrom >
Signed-off-by: Andres Gomez >
---
.travis.yml | 15 ++-
configure.ac|  6 +++---
meson.build |  4 ++--
src/gallium/drivers/swr/Makefile.am |  2 +-
src/gallium/drivers/swr/SConscript  |  4 ++--
5 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 3651d00169f..0ec08e5bff7 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -90,12 +90,10 @@ matrix:
- BUILD=make
- MAKEFLAGS="-j4"
- MAKE_CHECK_COMMAND="true"
-- LLVM_VERSION=3.9
+- LLVM_VERSION=4.0
- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
- OVERRIDE_CC="gcc-4.8"
- OVERRIDE_CXX="g++-4.8"
-# New binutils linker is required for llvm-3.9
-- OVERRIDE_PATH=/usr/lib/binutils-2.26/bin
- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
- DRI_DRIVERS=""
- GALLIUM_ST="--enable-dri --disable-opencl --disable-xa --disable-nine 
--disable-xvmc --disable-vdpau --disable-va --disable-omx-bellagio 
--disable-gallium-osmesa"
@@ -105,13 +103,12 @@ matrix:
  addons:
apt:
  sources:
-- llvm-toolchain-trusty-3.9
+- llvm-toolchain-trusty-4.0
  packages:
-- binutils-2.26
# LLVM packaging is broken and misses these dependencies
- libedit-dev
# From sources above
-- llvm-3.9-dev
+- llvm-4.0-dev
# Common
- xz-utils
- x11proto-xf86vidmode-dev
@@ -400,7 +397,7 @@ matrix:
- BUILD=scons
- SCONSFLAGS="-j4"
- SCONS_TARGET="swr=1"
-- LLVM_VERSION=3.9
+- LLVM_VERSION=4.0
- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
# Keep it symmetrical to the make build. There's no actual SWR, yet.
- SCONS_CHECK_COMMAND="true"
@@ -409,13 +406,13 @@ matrix:
  addons:
apt:
  sources:
-- llvm-toolchain-trusty-3.9
+- llvm-toolchain-trusty-4.0
  packages:
- scons
# LLVM packaging is broken and misses these dependencies
- libedit-dev
# From sources above
-- llvm-3.9-dev
+- llvm-4.0-dev
# Common
- xz-utils
- x11proto-xf86vidmode-dev
diff --git a/configure.ac b/configure.ac
index 8ed606c7694..7fff725954d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -105,7 +105,7 @@ LLVM_REQUIRED_OPENCL=3.9.0
LLVM_REQUIRED_R600=3.9.0
LLVM_REQUIRED_RADEONSI=4.0.0
LLVM_REQUIRED_RADV=4.0.0
-LLVM_REQUIRED_SWR=3.9.0
+LLVM_REQUIRED_SWR=4.0.0

dnl Check for progs
AC_PROG_CPP
@@ -2695,8 +2695,8 @@ if test -n "$with_gallium_drivers"; then
fi

# XXX: Keep in sync with LLVM_REQUIRED_SWR
-AM_CONDITIONAL(SWR_INVALID_LLVM_VERSION, test "x$LLVM_VERSION" != x3.9.0 -a \
-  "x$LLVM_VERSION" != x3.9.1)
+AM_CONDITIONAL(SWR_INVALID_LLVM_VERSION, test "x$LLVM_VERSION" != x4.0.0 -a \
+  "x$LLVM_VERSION" != x4.0.1)

if test "x$enable_llvm" = "xyes" -a "$with_gallium_drivers"; then
llvm_require_version $LLVM_REQUIRED_GALLIUM "gallium"
diff --git a/meson.build b/meson.build
index b39e2f8ab96..96e44459465 100644
--- a/meson.build
+++ b/meson.build
@@ -1011,9 +1011,9 @@ if with_gallium_opencl
  # TODO: optional modules
endif

-if with_amd_vk or with_gallium_radeonsi
+if with_amd_vk or with_gallium_radeonsi or with_gallium_swr
  _llvm_version = '>= 4.0.0'
-elif with_gallium_opencl or with_gallium_swr or with_gallium_r600
+elif with_gallium_opencl or with_gallium_r600
  _llvm_version = '>= 3.9.0'
else
  _llvm_version = '>= 3.3.0'
diff --git a/src/gallium/drivers/swr/Makefile.am 
b/src/gallium/drivers/swr/Makefile.am
index 2bc129429c6..3ee79f7be25 100644
--- a/src/gallium/drivers/swr/Makefile.am
+++ b/src/gallium/drivers/swr/Makefile.am
@@ -352,7 +352,7 @@ include 

Re: [Mesa-dev] [PATCH] travis: radeonsi and radv need LLVM 4.0

[Kyriazis, George]

SWR is OK with moving to LLVM 4.0 and above.

Just to clarify: This goes to master, which means mesa 18.0 is not affected, 
just 18.1 and later.  Correct?

Thanks,

George

> On Feb 6, 2018, at 11:07 AM, Kyriazis, George <george.kyria...@intel.com> 
> wrote:
> 
> As far as SWR is concerned, we’ll have to ask our customers.  Will respond 
> shortly.
> 
> Thanks,
> 
> George
> 
>> On Feb 6, 2018, at 9:42 AM, Andres Gomez <ago...@igalia.com> wrote:
>> 
>> Fixes: 3bf1e036e8a ("amd: remove support for LLVM 3.9")
>> Cc: Marek Olšák <marek.ol...@amd.com>
>> Cc: Emil Velikov <emil.veli...@collabora.com>
>> Cc: Jan Vesely <jan.ves...@rutgers.edu>
>> Signed-off-by: Andres Gomez <ago...@igalia.com>
>> ---
>> 
>> Additionally, AMD's support removal for LLVM 3.9 has also affected the
>> distcheck target.
>> 
>> Unfortunately, SWR distribution needs 3.9.x, therefore, we cannot
>> simply use LLVM 4.0 to generate the distribution tarball.
>> 
>> Either SWR upgrades its minimal dependency to LLVM 4.0 or we find a
>> way of instructing distcheck so it would use LLVM 3.9 for the tarball
>> generation and LLVM 4.0 for the check stage of the distcheck ...
>> 
>> .travis.yml | 46 --
>> 1 file changed, 36 insertions(+), 10 deletions(-)
>> 
>> diff --git a/.travis.yml b/.travis.yml
>> index 0156eefb7ad..3651d00169f 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -37,12 +37,12 @@ matrix:
>>  addons:
>>apt:
>>  sources:
>> -- llvm-toolchain-trusty-3.9
>> +- llvm-toolchain-trusty-4.0
>>  packages:
>># LLVM packaging is broken and misses these dependencies
>>- libedit-dev
>># From sources above
>> -- llvm-3.9-dev
>> +- llvm-4.0-dev
>># Common
>>- xz-utils
>>- libexpat1-dev
>> @@ -119,6 +119,35 @@ matrix:
>>- libx11-xcb-dev
>>- libelf-dev
>>- libunwind8-dev
>> +- env:
>> +- LABEL="make Gallium Drivers RadeonSI"
>> +- BUILD=make
>> +- MAKEFLAGS="-j4"
>> +- MAKE_CHECK_COMMAND="true"
>> +- LLVM_VERSION=4.0
>> +- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
>> +- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
>> +- DRI_DRIVERS=""
>> +- GALLIUM_ST="--enable-dri --disable-opencl --disable-xa 
>> --disable-nine --disable-xvmc --disable-vdpau --disable-va 
>> --disable-omx-bellagio --disable-gallium-osmesa"
>> +- GALLIUM_DRIVERS="radeonsi"
>> +- VULKAN_DRIVERS=""
>> +- LIBUNWIND_FLAGS="--enable-libunwind"
>> +  addons:
>> +apt:
>> +  sources:
>> +- llvm-toolchain-trusty-4.0
>> +  packages:
>> +# LLVM packaging is broken and misses these dependencies
>> +- libedit-dev
>> +# From sources above
>> +- llvm-4.0-dev
>> +# Common
>> +- xz-utils
>> +- x11proto-xf86vidmode-dev
>> +- libexpat1-dev
>> +- libx11-xcb-dev
>> +- libelf-dev
>> +- libunwind8-dev
>>- env:
>>- LABEL="make Gallium Drivers Other"
>>- BUILD=make
>> @@ -131,7 +160,7 @@ matrix:
>>- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
>>- DRI_DRIVERS=""
>>- GALLIUM_ST="--enable-dri --disable-opencl --disable-xa 
>> --disable-nine --disable-xvmc --disable-vdpau --disable-va 
>> --disable-omx-bellagio --disable-gallium-osmesa"
>> -- 
>> GALLIUM_DRIVERS="i915,nouveau,pl111,r300,r600,radeonsi,freedreno,svga,swrast,vc4,virgl,etnaviv,imx"
>> +- 
>> GALLIUM_DRIVERS="i915,nouveau,pl111,r300,r600,freedreno,svga,swrast,vc4,virgl,etnaviv,imx"
>>- VULKAN_DRIVERS=""
>>- LIBUNWIND_FLAGS="--enable-libunwind"
>>  addons:
>> @@ -166,7 +195,7 @@ matrix:
>>- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
>>- DRI_DRIVERS=""
>>- GALLIUM_ST="--disable-dri --enable-opencl --enable-opencl-icd 
>> --enable-llvm --disable-xa --disable-nine -

Re: [Mesa-dev] [PATCH] travis: radeonsi and radv need LLVM 4.0

[Kyriazis, George]

As far as SWR is concerned, we’ll have to ask our customers.  Will respond 
shortly.

Thanks,

George

> On Feb 6, 2018, at 9:42 AM, Andres Gomez  wrote:
> 
> Fixes: 3bf1e036e8a ("amd: remove support for LLVM 3.9")
> Cc: Marek Olšák 
> Cc: Emil Velikov 
> Cc: Jan Vesely 
> Signed-off-by: Andres Gomez 
> ---
> 
> Additionally, AMD's support removal for LLVM 3.9 has also affected the
> distcheck target.
> 
> Unfortunately, SWR distribution needs 3.9.x, therefore, we cannot
> simply use LLVM 4.0 to generate the distribution tarball.
> 
> Either SWR upgrades its minimal dependency to LLVM 4.0 or we find a
> way of instructing distcheck so it would use LLVM 3.9 for the tarball
> generation and LLVM 4.0 for the check stage of the distcheck ...
> 
> .travis.yml | 46 --
> 1 file changed, 36 insertions(+), 10 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 0156eefb7ad..3651d00169f 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -37,12 +37,12 @@ matrix:
>   addons:
> apt:
>   sources:
> -- llvm-toolchain-trusty-3.9
> +- llvm-toolchain-trusty-4.0
>   packages:
> # LLVM packaging is broken and misses these dependencies
> - libedit-dev
> # From sources above
> -- llvm-3.9-dev
> +- llvm-4.0-dev
> # Common
> - xz-utils
> - libexpat1-dev
> @@ -119,6 +119,35 @@ matrix:
> - libx11-xcb-dev
> - libelf-dev
> - libunwind8-dev
> +- env:
> +- LABEL="make Gallium Drivers RadeonSI"
> +- BUILD=make
> +- MAKEFLAGS="-j4"
> +- MAKE_CHECK_COMMAND="true"
> +- LLVM_VERSION=4.0
> +- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> +- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
> +- DRI_DRIVERS=""
> +- GALLIUM_ST="--enable-dri --disable-opencl --disable-xa 
> --disable-nine --disable-xvmc --disable-vdpau --disable-va 
> --disable-omx-bellagio --disable-gallium-osmesa"
> +- GALLIUM_DRIVERS="radeonsi"
> +- VULKAN_DRIVERS=""
> +- LIBUNWIND_FLAGS="--enable-libunwind"
> +  addons:
> +apt:
> +  sources:
> +- llvm-toolchain-trusty-4.0
> +  packages:
> +# LLVM packaging is broken and misses these dependencies
> +- libedit-dev
> +# From sources above
> +- llvm-4.0-dev
> +# Common
> +- xz-utils
> +- x11proto-xf86vidmode-dev
> +- libexpat1-dev
> +- libx11-xcb-dev
> +- libelf-dev
> +- libunwind8-dev
> - env:
> - LABEL="make Gallium Drivers Other"
> - BUILD=make
> @@ -131,7 +160,7 @@ matrix:
> - DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
> - DRI_DRIVERS=""
> - GALLIUM_ST="--enable-dri --disable-opencl --disable-xa 
> --disable-nine --disable-xvmc --disable-vdpau --disable-va 
> --disable-omx-bellagio --disable-gallium-osmesa"
> -- 
> GALLIUM_DRIVERS="i915,nouveau,pl111,r300,r600,radeonsi,freedreno,svga,swrast,vc4,virgl,etnaviv,imx"
> +- 
> GALLIUM_DRIVERS="i915,nouveau,pl111,r300,r600,freedreno,svga,swrast,vc4,virgl,etnaviv,imx"
> - VULKAN_DRIVERS=""
> - LIBUNWIND_FLAGS="--enable-libunwind"
>   addons:
> @@ -166,7 +195,7 @@ matrix:
> - DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
> - DRI_DRIVERS=""
> - GALLIUM_ST="--disable-dri --enable-opencl --enable-opencl-icd 
> --enable-llvm --disable-xa --disable-nine --disable-xvmc --disable-vdpau 
> --disable-va --disable-omx-bellagio --disable-gallium-osmesa"
> -- GALLIUM_DRIVERS="r600,radeonsi"
> +- GALLIUM_DRIVERS="r600"
> - VULKAN_DRIVERS=""
> - LIBUNWIND_FLAGS="--enable-libunwind"
>   addons:
> @@ -303,10 +332,8 @@ matrix:
> - BUILD=make
> - MAKEFLAGS="-j4"
> - MAKE_CHECK_COMMAND="make -C src/gtest check && make -C src/intel 
> check"
> -- LLVM_VERSION=3.9
> +- LLVM_VERSION=4.0
> - LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> -# New binutils linker is required for llvm-3.9
> -- OVERRIDE_PATH=/usr/lib/binutils-2.26/bin
> - DRI_LOADERS="--disable-glx --disable-gbm --disable-egl 
> --with-platforms=x11,wayland"
> - DRI_DRIVERS=""
> - GALLIUM_ST="--enable-dri --enable-dri3 --disable-opencl 
> --disable-xa --disable-nine --disable-xvmc --disable-vdpau --disable-va 
> --disable-omx-bellagio --disable-gallium-osmesa"
> @@ -316,13 +343,12 @@ matrix:
>   addons:
> apt:
>   sources:
> -- llvm-toolchain-trusty-3.9
> +- llvm-toolchain-trusty-4.0
>   packages:
> -- binutils-2.26
>

Re: [Mesa-dev] [PATCH] swr: don't export swr_create_screen_internal

[Kyriazis, George]

Yep, tested on our side, and looks good.

Reviewed-By: George Kyriazis 
>


On Jan 29, 2018, at 9:42 AM, Chuck Atkins 
> wrote:

Lgtm, should probably get a rb from Intel though to make sure it doesn't break 
anything they're trying to do.

Tested-by: Chuck Atkins 
>

On Jan 29, 2018 07:09, "Emil Velikov" 
> wrote:
On 22 January 2018 at 17:52, Emil Velikov 
> wrote:
> From: Emil Velikov 
> >
>
> With earlier rework the user and provider of the symbol are within the
> same binary. Thus there's no point in exporting the function.
>
> Spotted while reviewing patch from Chuck, that nearly added another
> unneeded PUBLIC function.
>
> Cc: Chuck Atkins >
> Cc: Tim Rowley >
> Fixes: f50aa21456d "(swr: build driver proper separate from rasterizer")
> Signed-off-by: Emil Velikov 
> >
> ---
> The comment might need updating as well, although I'm short on
> suggestions.
> ---
>  src/gallium/drivers/swr/swr_public.h   | 2 +-
>  src/gallium/drivers/swr/swr_screen.cpp | 1 -
>  2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/swr/swr_public.h 
> b/src/gallium/drivers/swr/swr_public.h
> index 4b150705cd7..cb205479a91 100644
> --- a/src/gallium/drivers/swr/swr_public.h
> +++ b/src/gallium/drivers/swr/swr_public.h
> @@ -36,7 +36,7 @@ extern "C" {
>  struct pipe_screen *swr_create_screen(struct sw_winsys *winsys);
>
>  // arch-specific dll entry point
> -PUBLIC struct pipe_screen *swr_create_screen_internal(struct sw_winsys 
> *winsys);
> +struct pipe_screen *swr_create_screen_internal(struct sw_winsys *winsys);
>
>  #ifdef _WIN32
>  void swr_gdi_swap(struct pipe_screen *screen,
> diff --git a/src/gallium/drivers/swr/swr_screen.cpp 
> b/src/gallium/drivers/swr/swr_screen.cpp
> index b67ac25ac89..10b7e891aca 100644
> --- a/src/gallium/drivers/swr/swr_screen.cpp
> +++ b/src/gallium/drivers/swr/swr_screen.cpp
> @@ -1114,7 +1114,6 @@ swr_validate_env_options(struct swr_screen *screen)
>  }
>
>
> -PUBLIC
>  struct pipe_screen *
>  swr_create_screen_internal(struct sw_winsys *winsys)
>  {
> --
Humble ping?

-Eiml


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] swr/rast: support llvm 3.9 type declarations

[Kyriazis, George]

On Jan 24, 2018, at 11:43 AM, Emil Velikov 
> wrote:

On 24 January 2018 at 15:30, George Kyriazis 
> wrote:
LLVM 3.9 was not taken into in initial check-in.

Fixes: 01ab218bbc ("swr/rast: Initial work for debugging support.")
cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp | 14 ++
1 file changed, 14 insertions(+)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp 
b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
index 93e3240..1e954f6 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
@@ -249,9 +249,15 @@ DIType* JitManager::GetDebugType(Type* pTy)
switch (id)
{
case Type::VoidTyID: return builder.createUnspecifiedType("void"); break;
+#if LLVM_VERSION_MAJOR >= 4
case Type::HalfTyID: return builder.createBasicType("float16", 16, 
dwarf::DW_ATE_float); break;
case Type::FloatTyID: return builder.createBasicType("float", 32, 
dwarf::DW_ATE_float); break;
case Type::DoubleTyID: return builder.createBasicType("double", 64, 
dwarf::DW_ATE_float); break;
+#else
+case Type::HalfTyID: return builder.createBasicType("float16", 16, 16, 
dwarf::DW_ATE_float); break;
+case Type::FloatTyID: return builder.createBasicType("float", 32, 32, 
dwarf::DW_ATE_float); break;
+case Type::DoubleTyID: return builder.createBasicType("double", 64, 64, 
dwarf::DW_ATE_float); break;
+#endif
case Type::IntegerTyID: return GetDebugIntegerType(pTy); break;
case Type::StructTyID: return GetDebugStructType(pTy); break;
case Type::ArrayTyID: return GetDebugArrayType(pTy); break;
@@ -288,11 +294,19 @@ DIType* JitManager::GetDebugIntegerType(Type* pTy)
IntegerType* pIntTy = cast(pTy);
switch (pIntTy->getBitWidth())
{
+#if LLVM_VERSION_MAJOR >= 4
case 1: return builder.createBasicType("int1", 1, dwarf::DW_ATE_unsigned); 
break;
case 8: return builder.createBasicType("int8", 8, dwarf::DW_ATE_signed); 
break;
case 16: return builder.createBasicType("int16", 16, dwarf::DW_ATE_signed); 
break;
case 32: return builder.createBasicType("int", 32, dwarf::DW_ATE_signed); 
break;
case 64: return builder.createBasicType("int64", 64, dwarf::DW_ATE_signed); 
break;
+#else
+case 1: return builder.createBasicType("int1", 1, 8, 
dwarf::DW_ATE_unsigned); break;
+case 8: return builder.createBasicType("int8", 8, 8, 
dwarf::DW_ATE_signed); break;
+case 16: return builder.createBasicType("int16", 16, 16, 
dwarf::DW_ATE_signed); break;
+case 32: return builder.createBasicType("int", 32, 32, 
dwarf::DW_ATE_signed); break;
+case 64: return builder.createBasicType("int64", 64, 64, 
dwarf::DW_ATE_signed); break;
+#endif

Please mention in the commit message why we're not using zero for
AlignInBits as in the LLVM patch [1]. With that:

You are right, alignment could be 0.  I can do a v2 with alignment set to 0.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104749
Acked-by: Emil Velikov 
>

Thanks
Emil

[1] 
https://github.com/llvm-mirror/llvm/commit/e69c459a6e9756ca1ff3acb1dcfc434843aee80f#diff-71a247a97ac2b40bf8d9d8d64460f6f9

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 04/20] swr/rast: Initial work for debugging support.

[Kyriazis, George]

Emil,

I’m already working on it.

Thanks!

George

> On Jan 23, 2018, at 10:04 AM, Emil Velikov  wrote:
> 
> Hi George,
> 
> On 19 January 2018 at 21:46, George Kyriazis  
> wrote:
>> Adds ability to step into jitted llvm IR in Visual Studio.
>> - Updated llvm type generation script to also generate corresponding debug 
>> types.
>> - New module pass inserts debug metadata into the IR for each function
>> 
>> Disabled by default.
>> ---
> 
> This commit introduces createBasicType() which has varying signature
> across LLVM versions.
> Leading to build failure with LLVM 3.9 - LLVM 5.0.0 seems to be fine.
> Skim through the LLVM repo highlights [1].
> 
> NOTE: that this was the first build error that I've spotted and there
> could be others.
> 
> Can you please fix-up so that things build across all supported LLVM
> versions, or simply adjust the versions supported for the builds [2]?
> Adding a fixes tag in the fix-up, will make it easier to correlate two 
> commits.
> 
> Fixes: 01ab218bbc5 ("swr/rast: Initial work for debugging support.")
> 
> As dealing multiple LLVM versions is a pain, we have a few build
> combinations for Travis-CI.
> There is no automated testing yet, so you can use your github account
> to test before submitting/merging patches.
> Do tweak the matrix to better fit SWR needs.
> 
> You don't have to use Travis, if you have something else at hand.
> 
> For now, I'll do 18.0.0-rc1 with a big disclaimer that SWR+LLVM 3.9
> builds are broken.
> 
> Thanks
> Emil
> 
> [1] 
> https://github.com/llvm-mirror/llvm/commit/e69c459a6e9756ca1ff3acb1dcfc434843aee80f
> 
> [2] The following files will need to be tweaked
> configure.ac, LLVM_REQUIRED_SWR
> src/gallium/drivers/swr/SConscript
> meson.build
> 
> [3] https://travis-ci.org/evelikov/Mesa/builds/322358291

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr: refactor swr_create_screen to allow for proper cleanup on error

[Kyriazis, George]

Chuck,

Change verified on my end; check-in coming coming up soon.

George

On Jan 22, 2018, at 2:11 PM, Kyriazis, George 
<george.kyria...@intel.com<mailto:george.kyria...@intel.com>> wrote:


On Jan 22, 2018, at 12:02 PM, Chuck Atkins 
<chuck.atk...@kitware.com<mailto:chuck.atk...@kitware.com>> wrote:

Hi Emil,

Fixes: a4be2bcee2f ("swr: allow a single swr architecture to be builtin")

It doesn't fix anything that was broken from that commit.  The issues with 
error handling were already present before then, it's just that the changes in 
a4be2bcee2f were substantial so this commit works off the result of the 
previous.  So really it would be "Depends on: " rather than "Fixes: ".


Right this cleans up after the following commit - please include the tag.
Don't bother re-sending.

Not sure how I would go about that since I don't have push access.  The ML is 
really the only mechanism I have to send commits to the git repo.  Given that 
I've been submitting patches from time to time for the past two years or so 
(not often, but every few months I have a handful), should I go ahead and apply 
for an account now?

Chuck,

Don’t worry about it, I will check in this change, and include the tag while 
checking in.  I’ll do that after I finish my testing.  You can, of course, 
apply for an account; that’s completely orthogonal.

Which bring up the question, Emil, when does the branch happen?  I haven’t seen 
any new branches/tags in mesa/master.

Thanks,

George

- Chuck
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org<mailto:mesa-dev@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org<mailto:mesa-dev@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr: refactor swr_create_screen to allow for proper cleanup on error

[Kyriazis, George]

On Jan 22, 2018, at 12:02 PM, Chuck Atkins 
> wrote:

Hi Emil,

Fixes: a4be2bcee2f ("swr: allow a single swr architecture to be builtin")

It doesn't fix anything that was broken from that commit.  The issues with 
error handling were already present before then, it's just that the changes in 
a4be2bcee2f were substantial so this commit works off the result of the 
previous.  So really it would be "Depends on: " rather than "Fixes: ".


Right this cleans up after the following commit - please include the tag.
Don't bother re-sending.

Not sure how I would go about that since I don't have push access.  The ML is 
really the only mechanism I have to send commits to the git repo.  Given that 
I've been submitting patches from time to time for the past two years or so 
(not often, but every few months I have a handful), should I go ahead and apply 
for an account now?

Chuck,

Don’t worry about it, I will check in this change, and include the tag while 
checking in.  I’ll do that after I finish my testing.  You can, of course, 
apply for an account; that’s completely orthogonal.

Which bring up the question, Emil, when does the branch happen?  I haven’t seen 
any new branches/tags in mesa/master.

Thanks,

George

- Chuck
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallivm: avx-512 changes for texel fetcher

[Kyriazis, George]

On Jan 18, 2018, at 1:10 PM, Roland Scheidegger 
> wrote:

Am 17.01.2018 um 23:33 schrieb George Kyriazis:
The texture swizzle was not doing the right thing for avx512-style
16-wide loads.

Special-case the post-load swizzle operations for avx512 so that we move
the xyzw components correctly to the outputs.

cc: Jose Fonseca >
---
src/gallium/auxiliary/gallivm/lp_bld_pack.c | 40 +++--
1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_pack.c 
b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
index e8d4fcd..7879826 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_pack.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
@@ -129,6 +129,31 @@ lp_build_const_unpack_shuffle_half(struct gallivm_state 
*gallivm,
}

/**
+ * Similar to lp_build_const_unpack_shuffle_half, but for AVX512
+ * See comment above lp_build_interleave2_half for more details.
+ */
+static LLVMValueRef
+lp_build_const_unpack_shuffle_16wide(struct gallivm_state *gallivm,
+ unsigned lo_hi)
+{
+   LLVMValueRef elems[LP_MAX_VECTOR_LENGTH];
+   unsigned i, j;
+
+   assert(lo_hi < 2);
+
+   // for the following lo_hi setting, convert 0 -> f to:
+   // 0: 0 16 4 20  8 24 12 28 1 17 5 21  9 25 13 29
+   // 1: 2 18 6 22 10 26 14 30 3 19 7 23 11 27 15 31
+   for (i = 0; i < 16; i++) {
+  j = ((i&0x06)<<1) + ((i&1)<<4) + (i>>3) + (lo_hi<<1);
+
+  elems[i] = lp_build_const_int32(gallivm, j);
+   }
+
+   return LLVMConstVector(elems, 16);
+}
+
+/**
 * Build shuffle vectors that match PACKxx (SSE) instructions or
 * VPERM (Altivec).
 */
@@ -325,8 +350,8 @@ lp_build_interleave2(struct gallivm_state *gallivm,
}

/**
- * Interleave vector elements but with 256 bit,
- * treats it as interleave with 2 concatenated 128 bit vectors.
+ * Interleave vector elements but with 256 (or 512) bit,
+ * treats it as interleave with 2 concatenated 128 (or 256) bit vectors.
 *
 * This differs to lp_build_interleave2 as that function would do the following 
(for lo):
 * a0 b0 a1 b1 a2 b2 a3 b3, and this does not compile into an AVX unpack 
instruction.
@@ -343,6 +368,14 @@ lp_build_interleave2(struct gallivm_state *gallivm,
 *
 * And interleave-hi would result in:
 *   a2 b2 a3 b3 a6 b6 a7 b7
+ *
+ * For 512 bits, the following are true:
+ *
+ * Interleave-lo would result in (capital letters denote hex indices):
+ *   a0 b0 a1 b1 a4 b4 a5 b5 a8 b8 a9 b9 aC bC aD bD
+ *
+ * Interleave-hi would result in:
+ *   a2 b2 a3 b3 a6 b6 a7 b7 aA bA aB bB aE bE aF bF
 */
LLVMValueRef
lp_build_interleave2_half(struct gallivm_state *gallivm,
@@ -354,6 +387,9 @@ lp_build_interleave2_half(struct gallivm_state *gallivm,
   if (type.length * type.width == 256) {
  LLVMValueRef shuffle = lp_build_const_unpack_shuffle_half(gallivm, 
type.length, lo_hi);
  return LLVMBuildShuffleVector(gallivm->builder, a, b, shuffle, "");
+   } else if ((type.length == 16) && (type.width == 32)) {
+  LLVMValueRef shuffle = lp_build_const_unpack_shuffle_16wide(gallivm, 
lo_hi);
+  return LLVMBuildShuffleVector(gallivm->builder, a, b, shuffle, "");
This is not really "interleave_half", more like "interleave_quarter"...
That said, avx512 certainly follows the same rules as avx256, so 128bit
pieces are treated independently. So maybe this should be renamed like
"interleave_native" or something like that.
Also, I believe it is definitely a mistake to restrict this to dword
interleaves here. You should handle all type widths, just like the
256bit case can handle all widths.
And I'm not sure through which paths you reach this, but I'm not sure
why you don't need the corresponding unpack2_native and pack2_native
adjustments - it should not really be a special case, avx512 should
generally handle things like this (if you'd want to extend the gallivm
code to use avx512...). For that matter, the commit log and shortlog is
confusing, because this isn't directly related to texture fetching.

Roland

Roland,

The stack trace that I am seeing is the following:

(gdb) bt
#0  lp_build_const_unpack_shuffle_16wide (gallivm=0x168b690, lo_hi=0)
at ../../../../src/gallium/auxiliary/gallivm/lp_bld_pack.c:138
#1  0x762786de in lp_build_interleave2_half (gallivm=0x168b690,
type=..., a=0x16a7378, b=0x16a7d38, lo_hi=0)
at ../../../../src/gallium/auxiliary/gallivm/lp_bld_pack.c:391
#2  0x7629585f in lp_build_transpose_aos (gallivm=0x168b690,
single_type_lp=..., src=0x7fff32e0, dst=0x7fff3300)
at ../../../../src/gallium/auxiliary/gallivm/lp_bld_swizzle.c:664
#3  0x7626a887 in lp_build_fetch_rgba_soa (gallivm=0x168b690,
format_desc=0x767fe9a0 ,
type=..., aligned=1 '\001', base_ptr=0x16a3218, offset=0x16a6890,
i=0xf87a90, j=0xf87a90, cache=0x0, rgba_out=0x7fff4280)
at ../../../../src/gallium/auxiliary/gallivm/lp_bld_format_soa.c:635
#4  

Re: [Mesa-dev] [PATCH] gallivm: avx-512 changes for texel fetcher

[Kyriazis, George]

On Jan 18, 2018, at 1:10 PM, Roland Scheidegger 
> wrote:

Am 17.01.2018 um 23:33 schrieb George Kyriazis:
The texture swizzle was not doing the right thing for avx512-style
16-wide loads.

Special-case the post-load swizzle operations for avx512 so that we move
the xyzw components correctly to the outputs.

cc: Jose Fonseca >
---
src/gallium/auxiliary/gallivm/lp_bld_pack.c | 40 +++--
1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_pack.c 
b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
index e8d4fcd..7879826 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_pack.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
@@ -129,6 +129,31 @@ lp_build_const_unpack_shuffle_half(struct gallivm_state 
*gallivm,
}

/**
+ * Similar to lp_build_const_unpack_shuffle_half, but for AVX512
+ * See comment above lp_build_interleave2_half for more details.
+ */
+static LLVMValueRef
+lp_build_const_unpack_shuffle_16wide(struct gallivm_state *gallivm,
+ unsigned lo_hi)
+{
+   LLVMValueRef elems[LP_MAX_VECTOR_LENGTH];
+   unsigned i, j;
+
+   assert(lo_hi < 2);
+
+   // for the following lo_hi setting, convert 0 -> f to:
+   // 0: 0 16 4 20  8 24 12 28 1 17 5 21  9 25 13 29
+   // 1: 2 18 6 22 10 26 14 30 3 19 7 23 11 27 15 31
+   for (i = 0; i < 16; i++) {
+  j = ((i&0x06)<<1) + ((i&1)<<4) + (i>>3) + (lo_hi<<1);
+
+  elems[i] = lp_build_const_int32(gallivm, j);
+   }
+
+   return LLVMConstVector(elems, 16);
+}
+
+/**
 * Build shuffle vectors that match PACKxx (SSE) instructions or
 * VPERM (Altivec).
 */
@@ -325,8 +350,8 @@ lp_build_interleave2(struct gallivm_state *gallivm,
}

/**
- * Interleave vector elements but with 256 bit,
- * treats it as interleave with 2 concatenated 128 bit vectors.
+ * Interleave vector elements but with 256 (or 512) bit,
+ * treats it as interleave with 2 concatenated 128 (or 256) bit vectors.
 *
 * This differs to lp_build_interleave2 as that function would do the following 
(for lo):
 * a0 b0 a1 b1 a2 b2 a3 b3, and this does not compile into an AVX unpack 
instruction.
@@ -343,6 +368,14 @@ lp_build_interleave2(struct gallivm_state *gallivm,
 *
 * And interleave-hi would result in:
 *   a2 b2 a3 b3 a6 b6 a7 b7
+ *
+ * For 512 bits, the following are true:
+ *
+ * Interleave-lo would result in (capital letters denote hex indices):
+ *   a0 b0 a1 b1 a4 b4 a5 b5 a8 b8 a9 b9 aC bC aD bD
+ *
+ * Interleave-hi would result in:
+ *   a2 b2 a3 b3 a6 b6 a7 b7 aA bA aB bB aE bE aF bF
 */
LLVMValueRef
lp_build_interleave2_half(struct gallivm_state *gallivm,
@@ -354,6 +387,9 @@ lp_build_interleave2_half(struct gallivm_state *gallivm,
   if (type.length * type.width == 256) {
  LLVMValueRef shuffle = lp_build_const_unpack_shuffle_half(gallivm, 
type.length, lo_hi);
  return LLVMBuildShuffleVector(gallivm->builder, a, b, shuffle, "");
+   } else if ((type.length == 16) && (type.width == 32)) {
+  LLVMValueRef shuffle = lp_build_const_unpack_shuffle_16wide(gallivm, 
lo_hi);
+  return LLVMBuildShuffleVector(gallivm->builder, a, b, shuffle, "");
This is not really "interleave_half", more like "interleave_quarter"...
That said, avx512 certainly follows the same rules as avx256, so 128bit
pieces are treated independently. So maybe this should be renamed like
"interleave_native" or something like that.
Also, I believe it is definitely a mistake to restrict this to dword
interleaves here. You should handle all type widths, just like the
256bit case can handle all widths.
And I'm not sure through which paths you reach this, but I'm not sure
why you don't need the corresponding unpack2_native and pack2_native
adjustments - it should not really be a special case, avx512 should
generally handle things like this (if you'd want to extend the gallivm
code to use avx512...). For that matter, the commit log and shortlog is
confusing, because this isn't directly related to texture fetching.


Thanks Roland,

This check-in is a prerequisite for some avx-512 changes I am about to check in 
to the swr driver.  I’ve hit this for piglit test vs-texelfetch-isampler1d and 
similar ones that try to fetch from a texture from a VS.  You are right, there 
are probably other cases where this gets hit, but that was the place where I’ve 
hit it first.  If you could recommend some tests that hit the other width 
cases, it would be great to fix them too; since didn’t know where those cases 
would be hit, I decided to make this “surgical” change.

My follow-on changes depend on this change for correctness, and I’d like to get 
the the other changes in before the mesa 18.0 date (tomorrow).  AVX512 support 
is an ongoing effort on our side, so they will definitely be additional 
check-ins along the same lines.

Thoughts on checking in as-is for 18.0, with upcoming changes slowly creeping 
in to fix additional issues, and 

Re: [Mesa-dev] Mesa 18.0.0 release plan

[Kyriazis, George]

Hello Emil,

For the swr driver we are planning on getting some features in in the last 
couple of days, but one extra week will help us out.

Specifically, we are thinking of checking in:

- FE 16-wide shader support. This will entail calling lp_build_tgsi_soa() with 
width 16.  Having some problems with that; still trying to characterize. (I can 
elaborate in a separate thread, if you’d like).  There is some additional fixes 
that we need to check-in to support VertexID correctly.

- Early rasterization.  This allows is to early reject triangles that are too 
small to rasterize to any pixels, which is quite common to our workloads.  This 
will require some additional testing on our end to increase confidence.

Thank you!

George


> On Jan 16, 2018, at 1:18 PM, Emil Velikov  wrote:
> 
> Hi all,
> 
> As you've know the Mesa 18.0.0 release plan has been available for a while
> on the mesa3d.org website [1].
> 
> In case you've missed it here it is:
> 
> Jan 19 2018 - Feature freeze/Release candidate 1
> Jan 26 2018 - Release candidate 2
> Feb 02 2018 - Release candidate 3
> Feb 09 2018 - Release candidate 4/final release
> 
> This gives us half a week until the branch point.
> 
> As this is shorter notice than usual, I'm open to adjusting the schedule by a
> week. Do let me know ASAP, if we should go that route.
> 
> As always - do list features/sets that you'd like to see merged. Thus we can
> all have a clear idea and prioritise accordingly.
> 
> Thanks
> Emil
> 
> [1] https://www.mesa3d.org/release-calendar.html
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] swr: Correct texture allocation and limit max size to 2GB

[Kyriazis, George]

Looks good.

Reviewed-By: George Kyriazis 
>

On Nov 30, 2017, at 11:51 AM, Bruce Cherniak 
> wrote:

This patch fixes piglit tex3d-maxsize by correcting 4 things:

The total_size calculation was using 32-bit math, therefore a >4GB
allocation request overflowed and was not returning false (unsupported).

Changed AlignedMalloc arguments from "unsigned int" to size_t, to handle
4GB allocations.

Added error checking on texture allocations to fail gracefully.

Finally, temporarily decreased supported max texture size from 4GB to 2GB.
The gallivm texture-sampler needs some additional work to correctly handle
larger than 2GB textures (offsets to LLVMBuildGEP are signed).

I'm working on a follow-on patch to allow up to 4GB textures, as this is
useful in HPC visualization applications.

Fixes piglit tex3d-maxsize.

v2: Updated patch description to clarify ">4GB".
---
src/gallium/drivers/swr/rasterizer/common/os.h |  2 +-
src/gallium/drivers/swr/swr_screen.cpp | 12 +---
2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/common/os.h 
b/src/gallium/drivers/swr/rasterizer/common/os.h
index 4ed6b88e45..358cb33b6e 100644
--- a/src/gallium/drivers/swr/rasterizer/common/os.h
+++ b/src/gallium/drivers/swr/rasterizer/common/os.h
@@ -210,7 +210,7 @@ unsigned char _BitScanReverse(unsigned int *Index, unsigned 
int Mask)
}

inline
-void *AlignedMalloc(unsigned int size, unsigned int alignment)
+void *AlignedMalloc(size_t size, size_t alignment)
{
void *ret;
if (posix_memalign(, alignment, size))
diff --git a/src/gallium/drivers/swr/swr_screen.cpp 
b/src/gallium/drivers/swr/swr_screen.cpp
index 3f2433e65a..71a07ebe8d 100644
--- a/src/gallium/drivers/swr/swr_screen.cpp
+++ b/src/gallium/drivers/swr/swr_screen.cpp
@@ -50,7 +50,7 @@
 * Max texture sizes
 * XXX Check max texture size values against core and sampler.
 */
-#define SWR_MAX_TEXTURE_SIZE (4 * 1024 * 1024 * 1024ULL) /* 4GB */
+#define SWR_MAX_TEXTURE_SIZE (2 * 1024 * 1024 * 1024ULL) /* 2GB */
#define SWR_MAX_TEXTURE_2D_LEVELS 14  /* 8K x 8K for now */
#define SWR_MAX_TEXTURE_3D_LEVELS 12  /* 2K x 2K x 2K for now */
#define SWR_MAX_TEXTURE_CUBE_LEVELS 14  /* 8K x 8K for now */
@@ -821,13 +821,15 @@ swr_texture_layout(struct swr_screen *screen,
 ComputeSurfaceOffset(0, 0, 0, 0, 0, level, >swr);
   }

-   size_t total_size = res->swr.depth * res->swr.qpitch * res->swr.pitch *
-   res->swr.numSamples;
+   size_t total_size = (uint64_t)res->swr.depth * res->swr.qpitch *
+ res->swr.pitch * res->swr.numSamples;
   if (total_size > SWR_MAX_TEXTURE_SIZE)
  return false;

   if (allocate) {
  res->swr.xpBaseAddress = (gfxptr_t)AlignedMalloc(total_size, 64);
+  if (!res->swr.xpBaseAddress)
+ return false;

  if (res->has_depth && res->has_stencil) {
 res->secondary = res->swr;
@@ -843,6 +845,10 @@ swr_texture_layout(struct swr_screen *screen,
  res->secondary.pitch * res->secondary.numSamples;

 res->secondary.xpBaseAddress = (gfxptr_t) AlignedMalloc(total_size, 
64);
+ if (!res->secondary.xpBaseAddress) {
+AlignedFree((void *)res->swr.xpBaseAddress);
+return false;
+ }
  }
   }

--
2.11.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3] threads, configure.ac, meson.build: define and use HAVE_TIMESPEC_GET

[Kyriazis, George]

The problem that I’m seeing with timespec_get is that centos6 does not have it.

I’ve put some changes out for review that actually remove timespec_get() in 
favor of using a variation of os_time_get_nano().  It’s good to always use the 
same time functions, and not have multiple ways of doing similar things.

Thoughts?

George


> On Nov 16, 2017, at 8:57 AM, Emil Velikov  wrote:
> 
> On 15 November 2017 at 20:58, Nicolai Hähnle  wrote:
>> From: Nicolai Hähnle 
>> 
>> Tested with Travis and Appveyor.
>> 
>> v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
>> v3: use check_functions in Scons (Eric)
>> 
>> Cc: Rob Herring 
>> Cc: Alexander von Gluck IV 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
>> Fixes: f1a364878431 ("threads: update for late C11 changes")
>> Reviewed-by: Eric Engestrom  (v2)
>> Reviewed-by: Dylan Baker  (v2)
>> Reviewed-by: Jon Turney  (v2)
> 
> Thank you Nicolai, you're a star.
> 
> Reviewed-by: Emil Velikov 
> 
> -Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] add util_queue_fence_wait_timeout checkin breaks centos6 build

[Kyriazis, George]

Hmm..

Looking at /usr/include/time.h on ubuntu, I see the following:

#if (!defined __timespec_defined\
 && ((defined _TIME_H   \
  && (defined __USE_POSIX199309 \
  || defined __USE_ISOC11)) \
 || defined __need_timespec))
# define __timespec_defined 1

…

# ifdef __USE_ISOC11
/* Set TS to calendar time based in time base BASE.  */
extern int timespec_get (struct timespec *__ts, int __base)
 __THROW __nonnull ((1));
# endif


However, on centos6, I see:

#if !defined __timespec_defined &&  \
((defined _TIME_H &&\
  (defined __USE_POSIX199309 || defined __USE_MISC)) || \
  defined __need_timespec)
# define __timespec_defined 1

No definition for timespec_get().

So, the difference between the two looks like it’s the dependence of 
__USE_ISOC11.

The quick fix would be to depend on __USE_ISOC11 (or even better 
__timespec_defined && __USE_ISOC11), but I’m not sure how portable it is.

Of course, the most fool-proof solution would be a configure script check, but 
it could be redundant.

George

> On Nov 10, 2017, at 2:41 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
> 
> On 10.11.2017 19:20, Kyriazis, George wrote:
>> Hello Nicolai,
>> Your commit e3a8013 (util/u_queue: add util_queue_fence_wait_timeout), 
>> breaks the centos6 build.
>> Specifically, I am getting:
>>   CC libmesautil_la-u_queue.lo
>> ../../../src/util/u_queue.c: In function '_util_queue_fence_wait_timeout':
>> ../../../src/util/u_queue.c:173:7: error: implicit declaration of function 
>> 'timespec_get' [-Werror=implicit-function-declaration]
>>timespec_get(, TIME_UTC);
>>^
>> cc1: some warnings being treated as errors
> 
> Thanks for the heads up. That's annoying. Any good ideas for how to test for 
> timespec_get availability? Some configure script check, I guess?
> 
> Cheers,
> Nicolai
> 
> 
>> Thanks!
>> George
> 
> 
> -- 
> Lerne, wie die Welt wirklich ist,
> Aber vergiss niemals, wie sie sein sollte.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] add util_queue_fence_wait_timeout checkin breaks centos6 build

[Kyriazis, George]

Hello Nicolai,

Your commit e3a8013 (util/u_queue: add util_queue_fence_wait_timeout), breaks 
the centos6 build.

Specifically, I am getting:

  CC libmesautil_la-u_queue.lo
../../../src/util/u_queue.c: In function '_util_queue_fence_wait_timeout':
../../../src/util/u_queue.c:173:7: error: implicit declaration of function 
'timespec_get' [-Werror=implicit-function-declaration]
   timespec_get(, TIME_UTC);
   ^
cc1: some warnings being treated as errors


Thanks!

George

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr: Fixed an uncommon freed-memory access during state validation

[Kyriazis, George]

Looks good..

Reviewed-By: George Kyriazis 
>

On Nov 8, 2017, at 6:39 PM, Bruce Cherniak 
> wrote:

State validation is performed during clear and draw calls.  Validation
during clear was still accessing vertex buffer state.  When the currently
set vertex buffers are client arrays, this could lead to accessing freed
memory.  Such is the case with the VMD application.

Previously, vertex buffer validation depended on a dirty bit or the
draw info indicating an indexed draw.  This required special handling for
clears.  But, vertex buffer validation still occurred which was unnecessary
and wrong.

Now, only minimal validation is performed during clear, deferring the
remainder to the next draw.  And, by setting the dirty bit in swr_draw_vbo
for indexed draws, vertex buffer validation is only dependent upon a
single dirty bit.

This fixes a bug exposed by the VMD application when changing models.
---
src/gallium/drivers/swr/swr_draw.cpp  |  7 ++-
src/gallium/drivers/swr/swr_state.cpp | 35 +++
2 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_draw.cpp 
b/src/gallium/drivers/swr/swr_draw.cpp
index 57660c7464..a94cdd6da0 100644
--- a/src/gallium/drivers/swr/swr_draw.cpp
+++ b/src/gallium/drivers/swr/swr_draw.cpp
@@ -52,7 +52,12 @@ swr_draw_vbo(struct pipe_context *pipe, const struct 
pipe_draw_info *info)
  return;
   }

-   /* Update derived state, pass draw info to update function */
+   /* If indexed draw, force vertex validation since index buffer comes
+* from draw info. */
+   if (info->index_size)
+  ctx->dirty |= SWR_NEW_VERTEX;
+
+   /* Update derived state, pass draw info to update function. */
   swr_update_derived(pipe, info);

   swr_update_draw_context(ctx);
diff --git a/src/gallium/drivers/swr/swr_state.cpp 
b/src/gallium/drivers/swr/swr_state.cpp
index c6da4fcb8e..4530d377ee 100644
--- a/src/gallium/drivers/swr/swr_state.cpp
+++ b/src/gallium/drivers/swr/swr_state.cpp
@@ -1204,11 +1204,6 @@ swr_update_derived(struct pipe_context *pipe,
  ctx->api.pfnSwrSetRastState(ctx->swrContext, rastState);
   }

-   /* Scissor */
-   if (ctx->dirty & SWR_NEW_SCISSOR) {
-  ctx->api.pfnSwrSetScissorRects(ctx->swrContext, 1, >swr_scissor);
-   }
-
   /* Viewport */
   if (ctx->dirty & (SWR_NEW_VIEWPORT | SWR_NEW_FRAMEBUFFER
 | SWR_NEW_RASTERIZER)) {
@@ -1249,18 +1244,26 @@ swr_update_derived(struct pipe_context *pipe,
  ctx->api.pfnSwrSetViewports(ctx->swrContext, 1, vp, vpm);
   }

-   /* Set vertex & index buffers
-* (using draw info if called by swr_draw_vbo)
-* If indexed draw, revalidate since index buffer comes from
-* pipe_draw_info.
-*/
-   if (ctx->dirty & SWR_NEW_VERTEX ||
-  (p_draw_info && p_draw_info->index_size)) {
+   /* When called from swr_clear (p_draw_info = null), render targets,
+* rasterState and viewports (dependent on render targets) are the only
+* necessary validation.  Defer remaining validation by setting
+* post_update_dirty_flags and clear all dirty flags.  BackendState is
+* still unconditionally validated below */
+   if (!p_draw_info) {
+  post_update_dirty_flags = ctx->dirty & ~(SWR_NEW_FRAMEBUFFER |
+   SWR_NEW_RASTERIZER |
+   SWR_NEW_VIEWPORT);
+  ctx->dirty = 0;
+   }
+
+   /* Scissor */
+   if (ctx->dirty & SWR_NEW_SCISSOR) {
+  ctx->api.pfnSwrSetScissorRects(ctx->swrContext, 1, >swr_scissor);
+   }

-  /* If being called by swr_draw_vbo, copy draw details */
-  struct pipe_draw_info info = {0};
-  if (p_draw_info)
- info = *p_draw_info;
+   /* Set vertex & index buffers */
+   if (ctx->dirty & SWR_NEW_VERTEX) {
+  const struct pipe_draw_info  = *p_draw_info;

  /* vertex buffers */
  SWR_VERTEX_BUFFER_STATE swrVertexBuffers[PIPE_MAX_ATTRIBS];
--
2.11.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Piglit on windows

[Kyriazis, George]

> On Oct 10, 2017, at 1:23 PM, Dylan Baker <dy...@pnwbakers.com> wrote:
> 
> Quoting Kyriazis, George (2017-10-10 11:02:26)
>> 
>>> On Oct 10, 2017, at 12:46 PM, Dylan Baker <dy...@pnwbakers.com> wrote:
>>> 
>>> Quoting Jose Fonseca (2017-10-10 08:41:49)
>>>> On 10/10/17 16:31, Kyriazis, George wrote:
>>>>> Hello…
>>>>> 
>>>>> Piglit on windows prints out a message saying “Timeout are not 
>>>>> implemented on Windows.”.  These timeouts are the test timeouts in case a 
>>>>> test hangs.
>>>>> 
>>>>> What do people do when running piglit on windows and they hit a timeout?  
>>>>> I would imagine there would be a non-zero number of people running piglit 
>>>>> on windows on a regular basis, as a regression tool...
>>>>> 
>>>>> Thank you!
>>>>> 
>>>>> George
>>>> 
>>>> I haven't been involved into piglit Windows testing lately, so my
>>>> understanding might be dated.
>>>> 
>>>> I believe that we have timeouts when we test piglit on Windows. It's not
>>>> implemented on piglit python framework itself, but rather on VMware
>>>> testing framework (that driver piglit, and a bunch of other tests.)
>>>> 
>>>> That said, I believe it would be better long term if piglit framework
>>>> had timeouts on Windows, as it can probably track that with finer
>>>> granularity than we do now by putting a timeout on whole piglit or
>>>> subsets of piglit tests.
>>>> 
>>>> python3's subprocess module has timeout options, so it should be
>>>> relatively easy to implement on top of it, in a cross-platform manner.
>>>> 
>>>> Jose
>>>> ___
>>>> mesa-dev mailing list
>>>> mesa-dev@lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>> 
>>> Since I added that warning message...
>>> 
>>> There are no timeouts in python 2 on windows, even with 3rd party packages.
>>> 
>>> For python 3 to properly handle timeouts you need to kill the process that
>>> exceeds the expected timeout. Basically when timeout expires the sub-process
>>> communicate call stops blocking, but doesn't actually kill the process. On 
>>> Linux
>>> we ask the process to terminate, wait 3 seconds and then SIGKILL it.
>>> 
>>> I don't know how to do that on windows, so I didn't implement it and instead
>>> windows users get a warning. If someone with a basic grasp of how to kill a
>>> process on windows wanted that functionality it probably wouldn't be too 
>>> hard to
>>> implement.
>>> 
>>> Alternatively there are constructs that are only in python 3 that do the 
>>> killing
>>> for you, on both Windows and Linux, but they don't have a python 2 
>>> equivalent.
>>> 
>> Hmm..  Since the current code has special cases between python 2/3 and 
>> windows/linux, finding a cross-platform method for both OSes seems like a 
>> “nice to have” at this point, although desirable.
>> 
>> I’ll see if I can find a quick fix for this.
>> 
>> Thank you!
>> 
>> George
>> 
>>> Dylan
>> 
> 
> You could have a look at framework/test/base.py, the logic is in there. I 
> don't
> think it would really be that much code to add to that mess, and we could 
> always
> delete it whenever we finally decide that we don't care about python 2 
> anymore.
> 
> Dylan

The interest is for python3, I don’t think windows piglit works with python2 
anyway.  The README file lists python3 as a requirement for windows.

So, I did some simple tests with Popen() on windows, and it looks like 
commnicate() understands the timeout argument, and proc.kill() seems to work 
(at least for simple things, like “sleep”).

Maybe python3 support changed between the time you wrote the code and now?  I’m 
using Python 3.6.3.

Thanks,

george

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Piglit on windows

[Kyriazis, George]

> On Oct 10, 2017, at 12:46 PM, Dylan Baker <dy...@pnwbakers.com> wrote:
> 
> Quoting Jose Fonseca (2017-10-10 08:41:49)
>> On 10/10/17 16:31, Kyriazis, George wrote:
>>> Hello…
>>> 
>>> Piglit on windows prints out a message saying “Timeout are not implemented 
>>> on Windows.”.  These timeouts are the test timeouts in case a test hangs.
>>> 
>>> What do people do when running piglit on windows and they hit a timeout?  I 
>>> would imagine there would be a non-zero number of people running piglit on 
>>> windows on a regular basis, as a regression tool...
>>> 
>>> Thank you!
>>> 
>>> George
>> 
>> I haven't been involved into piglit Windows testing lately, so my
>> understanding might be dated.
>> 
>> I believe that we have timeouts when we test piglit on Windows. It's not
>> implemented on piglit python framework itself, but rather on VMware
>> testing framework (that driver piglit, and a bunch of other tests.)
>> 
>> That said, I believe it would be better long term if piglit framework
>> had timeouts on Windows, as it can probably track that with finer
>> granularity than we do now by putting a timeout on whole piglit or
>> subsets of piglit tests.
>> 
>> python3's subprocess module has timeout options, so it should be
>> relatively easy to implement on top of it, in a cross-platform manner.
>> 
>> Jose
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> Since I added that warning message...
> 
> There are no timeouts in python 2 on windows, even with 3rd party packages.
> 
> For python 3 to properly handle timeouts you need to kill the process that
> exceeds the expected timeout. Basically when timeout expires the sub-process
> communicate call stops blocking, but doesn't actually kill the process. On 
> Linux
> we ask the process to terminate, wait 3 seconds and then SIGKILL it.
> 
> I don't know how to do that on windows, so I didn't implement it and instead
> windows users get a warning. If someone with a basic grasp of how to kill a
> process on windows wanted that functionality it probably wouldn't be too hard 
> to
> implement.
> 
> Alternatively there are constructs that are only in python 3 that do the 
> killing
> for you, on both Windows and Linux, but they don't have a python 2 equivalent.
> 
Hmm..  Since the current code has special cases between python 2/3 and 
windows/linux, finding a cross-platform method for both OSes seems like a “nice 
to have” at this point, although desirable.

I’ll see if I can find a quick fix for this.

Thank you!

George

> Dylan



signature.asc
Description: Message signed with OpenPGP
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Piglit on windows

[Kyriazis, George]

On Oct 10, 2017, at 10:41 AM, Jose Fonseca 
<jfons...@vmware.com<mailto:jfons...@vmware.com>> wrote:

On 10/10/17 16:31, Kyriazis, George wrote:
Hello…
Piglit on windows prints out a message saying “Timeout are not implemented on 
Windows.”.  These timeouts are the test timeouts in case a test hangs.
What do people do when running piglit on windows and they hit a timeout?  I 
would imagine there would be a non-zero number of people running piglit on 
windows on a regular basis, as a regression tool...
Thank you!
George

I haven't been involved into piglit Windows testing lately, so my understanding 
might be dated.

I believe that we have timeouts when we test piglit on Windows. It's not 
implemented on piglit python framework itself, but rather on VMware testing 
framework (that driver piglit, and a bunch of other tests.)

That said, I believe it would be better long term if piglit framework had 
timeouts on Windows, as it can probably track that with finer granularity than 
we do now by putting a timeout on whole piglit or subsets of piglit tests.

Yes, definitely, that’s the way to go.

The code that I see in framework/test/base.py says:

if sys.platform == 'win32':
# There is no implementation in piglit to make timeouts work in
# windows, this uses the same Popen snippet as python 2 without
# subprocess32 to mask it. Patches are welcome.
# XXX: Should this also include cygwin?
warnings.warn('Timeouts are not implemented on Windows.')



python3's subprocess module has timeout options, so it should be relatively 
easy to implement on top of it, in a cross-platform manner.

Not being a python expert it looks like subprocess does not work on windows.

George


Jose

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Piglit on windows

[Kyriazis, George]

Hello…

Piglit on windows prints out a message saying “Timeout are not implemented on 
Windows.”.  These timeouts are the test timeouts in case a test hangs.

What do people do when running piglit on windows and they hit a timeout?  I 
would imagine there would be a non-zero number of people running piglit on 
windows on a regular basis, as a regression tool...

Thank you!

George

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [OS]Mesa MinGW AppVeyor Repository

[Kyriazis, George]

Emil,

I’m working with Trevor to upstream the correct versions of the swr patches.

Thanks,

George

> On Oct 2, 2017, at 9:04 AM, Emil Velikov  wrote:
> 
> Hi Trevor,
> 
> On 2 October 2017 at 13:48, Trevor Sandy  wrote:
>> Hi George,
>> 
>> You might be interested to know I have set up a CI env on AppVeyor for MinGW
>> builds.
>> 
>> Here is the GitHub repo: https://github.com/trevorsandy/osmesa_mingw_av.
>> Follow the badge in the README to the AppVeyor instance.
>> 
>> You can demo your patches quite easily - see the README.md on how to extract
>> source that can be used by my build script. Or change set the version to
>> download and build its source bundle. Perhaps later on I'll add the ability
>> to get build content (tag, branch, commit etc...) directly from Mesa's git
>> repo.
>> 
> The upstream Mesa repository has AppVeyor integration, admittedly it
> builds only with MSVC.
> 
> If you want for things to work, I strongly recommend upstreaming your patches.
> Otherwise it will be in a perpetual state of brokenness and you'll
> have to dedicate even more resources as time goes by.
> 
> Thanks
> Emil

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] swr: Report format max_samples=1 to maintain support for "fake" msaa.

[Kyriazis, George]

Discussed with Bruce.

Reviewed-By: George Kyriazis 
>

On Aug 31, 2017, at 11:09 PM, Brian Paul 
> wrote:

I'm not familiar with this driver so I'll give this an

Acked-by: Brian Paul >

Roland gave me his R-b for the state tracker patch off-list.

I'll commit that and you can take care of this one.  Feel free to close the bug 
then.

-Brian


On 08/25/2017 01:59 PM, Bruce Cherniak wrote:
Accompanying patch "st/mesa: only try to create 1x msaa surfaces for
'fake' msaa" requires driver to report max_samples=1 to enable "fake"
msaa. Previously, 0 and 1 were treated equivalently in st_init_extensions()
and either could enable "fake" msaa.

This patch raises the swr default msaa_max_count from 0 to 1, so that
swr_is_format_supported will report max_samples=1.

Real msaa can still be enabled by exporting SWR_MSAA_MAX_COUNT with a
pow2 value between 2 and 16.

This patch is necessary to prevent an OpenSWR regression resulting from
the st/mesa patch.

Bugzilla: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D102038=DwIBAg=uilaK90D4TOVoH58JNXRgQ=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA=qdD02tm0IRZ3cDM-14sDyg5PjXgN7HpvqxwdIKPKG_0=Lfh53G7s15bwea6KD_n-r5t38aWcMLmz8Dp-k0TfKbA=
---
 src/gallium/drivers/swr/swr_screen.cpp | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_screen.cpp 
b/src/gallium/drivers/swr/swr_screen.cpp
index 3287bc6fee..cc8d9955b8 100644
--- a/src/gallium/drivers/swr/swr_screen.cpp
+++ b/src/gallium/drivers/swr/swr_screen.cpp
@@ -255,13 +255,13 @@ swr_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
   return 1;

/* MSAA support
-* If user has explicitly set max_sample_count = 0 (via SWR_MSAA_MAX_COUNT)
-* then disable all MSAA support and go back to old caps. */
+* If user has explicitly set max_sample_count = 1 (via SWR_MSAA_MAX_COUNT)
+* then disable all MSAA support and go back to old (FAKE_SW_MSAA) caps. */
case PIPE_CAP_TEXTURE_MULTISAMPLE:
case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
-  return swr_screen(screen)->msaa_max_count ? 1 : 0;
+  return (swr_screen(screen)->msaa_max_count > 1) ? 1 : 0;
case PIPE_CAP_FAKE_SW_MSAA:
-  return swr_screen(screen)->msaa_max_count ? 0 : 1;
+  return (swr_screen(screen)->msaa_max_count > 1) ? 0 : 1;

   /* unsupported features */
case PIPE_CAP_ANISOTROPIC_FILTER:
@@ -1079,22 +1079,22 @@ swr_validate_env_options(struct swr_screen *screen)
   screen->client_copy_limit = client_copy_limit;

/* XXX msaa under development, disable by default for now */
-   screen->msaa_max_count = 0; /* was SWR_MAX_NUM_MULTISAMPLES; */
+   screen->msaa_max_count = 1; /* was SWR_MAX_NUM_MULTISAMPLES; */

/* validate env override values, within range and power of 2 */
-   int msaa_max_count = debug_get_num_option("SWR_MSAA_MAX_COUNT", 0);
-   if (msaa_max_count) {
-  if ((msaa_max_count < 0) || (msaa_max_count > SWR_MAX_NUM_MULTISAMPLES)
+   int msaa_max_count = debug_get_num_option("SWR_MSAA_MAX_COUNT", 1);
+   if (msaa_max_count != 1) {
+  if ((msaa_max_count < 1) || (msaa_max_count > SWR_MAX_NUM_MULTISAMPLES)
 || !util_is_power_of_two(msaa_max_count)) {
  fprintf(stderr, "SWR_MSAA_MAX_COUNT invalid: %d\n", msaa_max_count);
  fprintf(stderr, "must be power of 2 between 1 and %d" \
- " (or 0 to disable msaa)\n",
+ " (or 1 to disable msaa)\n",
SWR_MAX_NUM_MULTISAMPLES);
- msaa_max_count = 0;
+ msaa_max_count = 1;
   }

   fprintf(stderr, "SWR_MSAA_MAX_COUNT: %d\n", msaa_max_count);
-  if (!msaa_max_count)
+  if (msaa_max_count == 1)
  fprintf(stderr, "(msaa disabled)\n");

   screen->msaa_max_count = msaa_max_count;


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] swr: fix transform feedback logic

[Kyriazis, George]

> On Jul 27, 2017, at 1:49 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> 
> On Thu, Jul 27, 2017 at 2:45 PM, Kyriazis, George
> <george.kyria...@intel.com> wrote:
>> 
>> On Jul 27, 2017, at 1:25 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>> 
>> On Wed, Jul 26, 2017 at 6:27 PM, George Kyriazis
>> <george.kyria...@intel.com> wrote:
>> 
>> The shader that is used to copy vertex data out of the vs/gs shaders to
>> the user-specified buffer (streamout or SO shader) was not using the
>> correct offsets.
>> 
>> Adjust the offsets that are used just for the SO shader:
>> - Make sure that position is handled in the same special way
>> as in the vs/gs shaders
>> - Use the correct offset to be passed in the core
>> - consolidate register slot mapping logic into one function, since it's
>> been calculated in 2 different places (one for calcuating the slot mask,
>> and one for the register offsets themselves
>> 
>> Also make room for all attibutes in the backend vertex area.
>> 
>> Fixes:
>> - all vtk GL2PS tests
>> - 18 piglit tests (16 ext_transform_feedback tests,
>> arb-quads-follow-provoking-vertex and primitive-type gl_points
>> 
>> v2:
>> 
>> - take care of more SGV slots in slot mapping logic
>> - trim feState.vsVertexSize
>> - fix GS interface and incorporate GS while calculating vsVertexSize
>> 
>> Note that vsVertexSize is used in the core as the one parameter that
>> controls vertex size between all stages, so it has to be adjusted
>> appropriately
>> for the whole vs/gs/fs pipeline.
>> 
>> fixes:
>> - fixes total of 20 piglit tests
>> 
>> CC: 17.2 <mesa-sta...@lists.freedesktop.org>
>> ---
>> src/gallium/drivers/swr/swr_draw.cpp   | 38
>> +-
>> src/gallium/drivers/swr/swr_shader.cpp | 32 +++-
>> src/gallium/drivers/swr/swr_shader.h   |  3 +++
>> src/gallium/drivers/swr/swr_state.cpp  |  5 +++--
>> 4 files changed, 70 insertions(+), 8 deletions(-)
>> 
>> diff --git a/src/gallium/drivers/swr/swr_draw.cpp
>> b/src/gallium/drivers/swr/swr_draw.cpp
>> index 62ad3f7..38a711e 100644
>> --- a/src/gallium/drivers/swr/swr_draw.cpp
>> +++ b/src/gallium/drivers/swr/swr_draw.cpp
>> @@ -81,8 +81,11 @@ swr_draw_vbo(struct pipe_context *pipe, const struct
>> pipe_draw_info *info)
>>   offsets[output_buffer] = so->output[i].dst_offset;
>>}
>> 
>> +unsigned attrib_slot = so->output[i].register_index;
>> +attrib_slot = swr_so_adjust_attrib(attrib_slot, ctx->vs);
>> +
>>state.stream.decl[num].bufferIndex = output_buffer;
>> -state.stream.decl[num].attribSlot =
>> so->output[i].register_index - 1;
>> +state.stream.decl[num].attribSlot = attrib_slot;
>> 
>> 
>> 
>> I'm confused... this still doesn't take GS into account. There does
>> not need to be any relation between VS outputs and GS outputs, and the
>> SO is all in reference to GS outputs (if a GS is there).
>> 
>> Yes, it doesn’t take GS into account in swr_draw_vbo() at this point.  There
>> are some other issues with GS that will prevent it from working.  Of course
>> we want to fix it, just not in this patch.  This patch fixes the majority of
>> the issues that we are concerned with relating to SO, which is what is
>> important for 17.2.
> 
> Ah OK - I just thought based on the change description that this was
> meant to work for GS. If it's a "todo" for later, that's fine too,
> although it might be nice to indicate that in a comment.

I’ll add a comment in the change description before checking in, to explain it 
a bit more.

Thanks!

George

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] swr: fix transform feedback logic

[Kyriazis, George]

On Jul 27, 2017, at 1:25 PM, Ilia Mirkin 
> wrote:

On Wed, Jul 26, 2017 at 6:27 PM, George Kyriazis
> wrote:
The shader that is used to copy vertex data out of the vs/gs shaders to
the user-specified buffer (streamout or SO shader) was not using the
correct offsets.

Adjust the offsets that are used just for the SO shader:
- Make sure that position is handled in the same special way
 as in the vs/gs shaders
- Use the correct offset to be passed in the core
- consolidate register slot mapping logic into one function, since it's
 been calculated in 2 different places (one for calcuating the slot mask,
 and one for the register offsets themselves

Also make room for all attibutes in the backend vertex area.

Fixes:
- all vtk GL2PS tests
- 18 piglit tests (16 ext_transform_feedback tests,
 arb-quads-follow-provoking-vertex and primitive-type gl_points

v2:

- take care of more SGV slots in slot mapping logic
- trim feState.vsVertexSize
- fix GS interface and incorporate GS while calculating vsVertexSize

Note that vsVertexSize is used in the core as the one parameter that
controls vertex size between all stages, so it has to be adjusted appropriately
for the whole vs/gs/fs pipeline.

fixes:
- fixes total of 20 piglit tests

CC: 17.2 
>
---
src/gallium/drivers/swr/swr_draw.cpp   | 38 +-
src/gallium/drivers/swr/swr_shader.cpp | 32 +++-
src/gallium/drivers/swr/swr_shader.h   |  3 +++
src/gallium/drivers/swr/swr_state.cpp  |  5 +++--
4 files changed, 70 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_draw.cpp 
b/src/gallium/drivers/swr/swr_draw.cpp
index 62ad3f7..38a711e 100644
--- a/src/gallium/drivers/swr/swr_draw.cpp
+++ b/src/gallium/drivers/swr/swr_draw.cpp
@@ -81,8 +81,11 @@ swr_draw_vbo(struct pipe_context *pipe, const struct 
pipe_draw_info *info)
   offsets[output_buffer] = so->output[i].dst_offset;
}

+unsigned attrib_slot = so->output[i].register_index;
+attrib_slot = swr_so_adjust_attrib(attrib_slot, ctx->vs);
+
state.stream.decl[num].bufferIndex = output_buffer;
-state.stream.decl[num].attribSlot = so->output[i].register_index - 
1;
+state.stream.decl[num].attribSlot = attrib_slot;


I'm confused... this still doesn't take GS into account. There does
not need to be any relation between VS outputs and GS outputs, and the
SO is all in reference to GS outputs (if a GS is there).

Yes, it doesn’t take GS into account in swr_draw_vbo() at this point.  There 
are some other issues with GS that will prevent it from working.  Of course we 
want to fix it, just not in this patch.  This patch fixes the majority of the 
issues that we are concerned with relating to SO, which is what is important 
for 17.2.

state.stream.decl[num].componentMask =
   ((1 << so->output[i].num_components) - 1)
   << so->output[i].start_component;
@@ -129,10 +132,35 @@ swr_draw_vbo(struct pipe_context *pipe, const struct 
pipe_draw_info *info)
* XXX setup provokingVertex & topologyProvokingVertex */
   SWR_FRONTEND_STATE feState = {0};

-   feState.vsVertexSize =
-  VERTEX_ATTRIB_START_SLOT +
-  + ctx->vs->info.base.num_outputs
-  - (ctx->vs->info.base.writes_position ? 1 : 0);
+   // feState.vsVertexSize seeds the PA size that is used as an interface
+   // between all the shader stages, so it has to be large enough to
+   // incorporate all interfaces between stages
+
+   // max of gs and vs num_outputs
+   feState.vsVertexSize = ctx->vs->info.base.num_outputs;
+   if (ctx->gs &&
+   ctx->gs->info.base.num_outputs > feState.vsVertexSize) {
+  feState.vsVertexSize = ctx->gs->info.base.num_outputs;
+   }
+
+   if (ctx->vs->info.base.num_outputs)
+  // gs does not adjust for position in SGV slot at input from vs
+  if (!ctx->gs)
+ feState.vsVertexSize--;
+
+   // other (non-SGV) slots start at VERTEX_ATTRIB_START_SLOT
+   feState.vsVertexSize += VERTEX_ATTRIB_START_SLOT;
+
+   // The PA in the clipper does not handle BE vertex sizes
+   // different from FE. Increase vertexsize only for the cases that needed it
+
+   // primid needs a slot
+   if (ctx->fs->info.base.uses_primid)
+  feState.vsVertexSize++;
+   // sprite coord enable
+   if (ctx->rasterizer->sprite_coord_enable)
+  feState.vsVertexSize++;
+

   if (ctx->rasterizer->flatshade_first) {
  feState.provokingVertex = {1, 0, 0};
diff --git a/src/gallium/drivers/swr/swr_shader.cpp 
b/src/gallium/drivers/swr/swr_shader.cpp
index 83b49c4..0a81eaa 100644
--- a/src/gallium/drivers/swr/swr_shader.cpp
+++ b/src/gallium/drivers/swr/swr_shader.cpp
@@ -414,7 +414,10 @@ BuilderSWR::swr_gs_llvm_emit_vertex(const struct 
lp_build_tgsi_gs_iface *gs_base
 

Re: [Mesa-dev] [PATCH] swr: fix transform feedback logic

[Kyriazis, George]

On Jul 23, 2017, at 1:51 PM, Ilia Mirkin 
<imir...@alum.mit.edu<mailto:imir...@alum.mit.edu>> wrote:

On Sun, Jul 23, 2017 at 12:27 PM, Kyriazis, George
<george.kyria...@intel.com<mailto:george.kyria...@intel.com>> wrote:

On Jul 23, 2017, at 11:21 AM, Ilia Mirkin 
<imir...@alum.mit.edu<mailto:imir...@alum.mit.edu>> wrote:

On Sun, Jul 23, 2017 at 12:08 PM, George Kyriazis
<george.kyria...@intel.com<mailto:george.kyria...@intel.com>> wrote:

The shader that is used to copy vertex data out of the vs/gs shaders to
the user-specified buffer (streamout os SO shader) was not using the
correct offsets.

Adjust the offsets that are used just for the SO shader:
- Make sure that position is handled in the same special way
as in the vs/gs shaders
- Use the correct offset to be passed in the core
- consolidate register slot mapping logic into one function, since it's
been calculated in 2 different places (one for calcuating the slot mask,
and one for the register offsets themselves

Also make room for all attibutes in the backend vertex area.

Fixes:
- all vtk GL2PS tests
- 18 piglit tests (16 ext_transform_feedback tests,
arb-quads-follow-provoking-vertex and primitive-type gl_points
---
src/gallium/drivers/swr/swr_draw.cpp  | 11 ---
src/gallium/drivers/swr/swr_state.cpp | 31 +--
src/gallium/drivers/swr/swr_state.h   |  3 +++
3 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_draw.cpp
b/src/gallium/drivers/swr/swr_draw.cpp
index 62ad3f7..218de0f 100644
--- a/src/gallium/drivers/swr/swr_draw.cpp
+++ b/src/gallium/drivers/swr/swr_draw.cpp
@@ -26,6 +26,7 @@
#include "swr_resource.h"
#include "swr_fence.h"
#include "swr_query.h"
+#include "swr_state.h"
#include "jit_api.h"

#include "util/u_draw.h"
@@ -81,8 +82,11 @@ swr_draw_vbo(struct pipe_context *pipe, const struct
pipe_draw_info *info)
  offsets[output_buffer] = so->output[i].dst_offset;
   }

+unsigned attrib_slot = so->output[i].register_index;
+attrib_slot = swr_so_adjust_attrib(attrib_slot, ctx->vs);
+
   state.stream.decl[num].bufferIndex = output_buffer;
-state.stream.decl[num].attribSlot =
so->output[i].register_index - 1;
+state.stream.decl[num].attribSlot = attrib_slot;
   state.stream.decl[num].componentMask =
  ((1 << so->output[i].num_components) - 1)
  << so->output[i].start_component;
@@ -130,9 +134,10 @@ swr_draw_vbo(struct pipe_context *pipe, const struct
pipe_draw_info *info)
  SWR_FRONTEND_STATE feState = {0};

  feState.vsVertexSize =
-  VERTEX_ATTRIB_START_SLOT +
+  VERTEX_ATTRIB_START_SLOT
 + ctx->vs->info.base.num_outputs
-  - (ctx->vs->info.base.writes_position ? 1 : 0);
+  - (ctx->vs->info.base.writes_position ? 1 : 0)
+  + ctx->fs->info.base.num_outputs;

Why do you care about the number of fs outputs in the vertex size?

In theory, there shouldn’t be, but, as I said in my previous email, the clipper 
and dinner have some dependency that forces them to use the same vertex size.  
It could be changed, but it’s a much more intrusive change.


  if (ctx->rasterizer->flatshade_first) {
 feState.provokingVertex = {1, 0, 0};
diff --git a/src/gallium/drivers/swr/swr_state.cpp
b/src/gallium/drivers/swr/swr_state.cpp
index 501fdea..3e07929 100644
--- a/src/gallium/drivers/swr/swr_state.cpp
+++ b/src/gallium/drivers/swr/swr_state.cpp
@@ -345,13 +345,15 @@ swr_create_vs_state(struct pipe_context *pipe,
 // soState.streamToRasterizer not used

 for (uint32_t i = 0; i < stream_output->num_outputs; i++) {
+ unsigned attrib_slot = stream_output->output[i].register_index;
+ attrib_slot = swr_so_adjust_attrib(attrib_slot, swr_vs);
swr_vs->soState.streamMasks[stream_output->output[i].stream] |=
-1 << (stream_output->output[i].register_index - 1);
+(1 << attrib_slot);
 }
 for (uint32_t i = 0; i < MAX_SO_STREAMS; i++) {
   swr_vs->soState.streamNumEntries[i] =
_mm_popcnt_u32(swr_vs->soState.streamMasks[i]);
-swr_vs->soState.vertexAttribOffset[i] = VERTEX_ATTRIB_START_SLOT;
// TODO: optimize
+swr_vs->soState.vertexAttribOffset[i] = 0;
  }
  }

@@ -1777,6 +1779,31 @@ swr_update_derived(struct pipe_context *pipe,
  ctx->dirty = post_update_dirty_flags;
}

+unsigned
+swr_so_adjust_attrib(unsigned in_attrib,
+ swr_vertex_shader *swr_vs)
+{
+   ubyte semantic_name;
+   unsigned attrib;
+
+   attrib = in_attrib + VERTEX_ATTRIB_START_SLOT;
+
+   if (swr_vs) {
+  semantic_name = swr_vs->info.base.output_semantic_name[in_attrib];
+  if (semantic_name == TGSI_SEMANTIC_POSITION) {


But it's not just the position... 

Re: [Mesa-dev] [PATCH] swr: fix transform feedback logic

[Kyriazis, George]

On Jul 23, 2017, at 1:42 PM, Rowley, Timothy O 
> wrote:


On Jul 23, 2017, at 11:08 AM, George Kyriazis 
> wrote:

The shader that is used to copy vertex data out of the vs/gs shaders to
the user-specified buffer (streamout os SO shader) was not using the
correct offsets.

Adjust the offsets that are used just for the SO shader:
- Make sure that position is handled in the same special way
as in the vs/gs shaders
- Use the correct offset to be passed in the core
- consolidate register slot mapping logic into one function, since it's
been calculated in 2 different places (one for calcuating the slot mask,
and one for the register offsets themselves

Also make room for all attibutes in the backend vertex area.

Add a comment to the commit indicating that as Ilia states, this is not a 
complete solution.

Ok


Fixes:
- all vtk GL2PS tests
- 18 piglit tests (16 ext_transform_feedback tests,
arb-quads-follow-provoking-vertex and primitive-type gl_points
---
src/gallium/drivers/swr/swr_draw.cpp  | 11 ---
src/gallium/drivers/swr/swr_state.cpp | 31 +--
src/gallium/drivers/swr/swr_state.h   |  3 +++
3 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_draw.cpp 
b/src/gallium/drivers/swr/swr_draw.cpp
index 62ad3f7..218de0f 100644
--- a/src/gallium/drivers/swr/swr_draw.cpp
+++ b/src/gallium/drivers/swr/swr_draw.cpp
@@ -26,6 +26,7 @@
#include "swr_resource.h"
#include "swr_fence.h"
#include "swr_query.h"
+#include "swr_state.h"
#include "jit_api.h"

#include "util/u_draw.h"
@@ -81,8 +82,11 @@ swr_draw_vbo(struct pipe_context *pipe, const struct 
pipe_draw_info *info)
  offsets[output_buffer] = so->output[i].dst_offset;
   }

+unsigned attrib_slot = so->output[i].register_index;
+attrib_slot = swr_so_adjust_attrib(attrib_slot, ctx->vs);
+
   state.stream.decl[num].bufferIndex = output_buffer;
-state.stream.decl[num].attribSlot = so->output[i].register_index - 
1;
+state.stream.decl[num].attribSlot = attrib_slot;
   state.stream.decl[num].componentMask =
  ((1 << so->output[i].num_components) - 1)
  << so->output[i].start_component;
@@ -130,9 +134,10 @@ swr_draw_vbo(struct pipe_context *pipe, const struct 
pipe_draw_info *info)
  SWR_FRONTEND_STATE feState = {0};

  feState.vsVertexSize =
-  VERTEX_ATTRIB_START_SLOT +
+  VERTEX_ATTRIB_START_SLOT
 + ctx->vs->info.base.num_outputs
-  - (ctx->vs->info.base.writes_position ? 1 : 0);
+  - (ctx->vs->info.base.writes_position ? 1 : 0)
+  + ctx->fs->info.base.num_outputs;

Sizing vsVertexSize to essentially vs->num_outputs + fs->num_outputs seems odd, 
as the fe shouldn’t care about the number of outputs of the fs (inputs, maybe).

The clipper/binner code uses the stride (which originates from vsVertexSize) to 
create the intermediate vertices for the backend.  The sizes for the FE and BE 
are bound by the same size because of that.  In order to size the vertices to 
the absolute minimum size, you’ll have to do more intrusive changes in the core 
to decouple the two.

  if (ctx->rasterizer->flatshade_first) {
 feState.provokingVertex = {1, 0, 0};
diff --git a/src/gallium/drivers/swr/swr_state.cpp 
b/src/gallium/drivers/swr/swr_state.cpp
index 501fdea..3e07929 100644
--- a/src/gallium/drivers/swr/swr_state.cpp
+++ b/src/gallium/drivers/swr/swr_state.cpp
@@ -345,13 +345,15 @@ swr_create_vs_state(struct pipe_context *pipe,
 // soState.streamToRasterizer not used

 for (uint32_t i = 0; i < stream_output->num_outputs; i++) {
+ unsigned attrib_slot = stream_output->output[i].register_index;
+ attrib_slot = swr_so_adjust_attrib(attrib_slot, swr_vs);
swr_vs->soState.streamMasks[stream_output->output[i].stream] |=
-1 << (stream_output->output[i].register_index - 1);
+(1 << attrib_slot);
 }
 for (uint32_t i = 0; i < MAX_SO_STREAMS; i++) {
   swr_vs->soState.streamNumEntries[i] =
_mm_popcnt_u32(swr_vs->soState.streamMasks[i]);
-swr_vs->soState.vertexAttribOffset[i] = VERTEX_ATTRIB_START_SLOT; // 
TODO: optimize
+swr_vs->soState.vertexAttribOffset[i] = 0;
  }
  }

@@ -1777,6 +1779,31 @@ swr_update_derived(struct pipe_context *pipe,
  ctx->dirty = post_update_dirty_flags;
}

+unsigned
+swr_so_adjust_attrib(unsigned in_attrib,
+ swr_vertex_shader *swr_vs)
+{
+   ubyte semantic_name;
+   unsigned attrib;
+
+   attrib = in_attrib + VERTEX_ATTRIB_START_SLOT;
+
+   if (swr_vs) {
+  semantic_name = swr_vs->info.base.output_semantic_name[in_attrib];
+  if (semantic_name == TGSI_SEMANTIC_POSITION) {
+ attrib = VERTEX_POSITION_SLOT;
+  } else {
+ for (int i = 0; i < PIPE_MAX_SHADER_OUTPUTS; i++) {
+if 

Re: [Mesa-dev] [PATCH] swr: fix transform feedback logic

[Kyriazis, George]

On Jul 23, 2017, at 11:21 AM, Ilia Mirkin 
> wrote:

On Sun, Jul 23, 2017 at 12:08 PM, George Kyriazis
> wrote:
The shader that is used to copy vertex data out of the vs/gs shaders to
the user-specified buffer (streamout os SO shader) was not using the
correct offsets.

Adjust the offsets that are used just for the SO shader:
- Make sure that position is handled in the same special way
 as in the vs/gs shaders
- Use the correct offset to be passed in the core
- consolidate register slot mapping logic into one function, since it's
 been calculated in 2 different places (one for calcuating the slot mask,
 and one for the register offsets themselves

Also make room for all attibutes in the backend vertex area.

Fixes:
- all vtk GL2PS tests
- 18 piglit tests (16 ext_transform_feedback tests,
 arb-quads-follow-provoking-vertex and primitive-type gl_points
---
src/gallium/drivers/swr/swr_draw.cpp  | 11 ---
src/gallium/drivers/swr/swr_state.cpp | 31 +--
src/gallium/drivers/swr/swr_state.h   |  3 +++
3 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_draw.cpp 
b/src/gallium/drivers/swr/swr_draw.cpp
index 62ad3f7..218de0f 100644
--- a/src/gallium/drivers/swr/swr_draw.cpp
+++ b/src/gallium/drivers/swr/swr_draw.cpp
@@ -26,6 +26,7 @@
#include "swr_resource.h"
#include "swr_fence.h"
#include "swr_query.h"
+#include "swr_state.h"
#include "jit_api.h"

#include "util/u_draw.h"
@@ -81,8 +82,11 @@ swr_draw_vbo(struct pipe_context *pipe, const struct 
pipe_draw_info *info)
   offsets[output_buffer] = so->output[i].dst_offset;
}

+unsigned attrib_slot = so->output[i].register_index;
+attrib_slot = swr_so_adjust_attrib(attrib_slot, ctx->vs);
+
state.stream.decl[num].bufferIndex = output_buffer;
-state.stream.decl[num].attribSlot = so->output[i].register_index - 
1;
+state.stream.decl[num].attribSlot = attrib_slot;
state.stream.decl[num].componentMask =
   ((1 << so->output[i].num_components) - 1)
   << so->output[i].start_component;
@@ -130,9 +134,10 @@ swr_draw_vbo(struct pipe_context *pipe, const struct 
pipe_draw_info *info)
   SWR_FRONTEND_STATE feState = {0};

   feState.vsVertexSize =
-  VERTEX_ATTRIB_START_SLOT +
+  VERTEX_ATTRIB_START_SLOT
  + ctx->vs->info.base.num_outputs
-  - (ctx->vs->info.base.writes_position ? 1 : 0);
+  - (ctx->vs->info.base.writes_position ? 1 : 0)
+  + ctx->fs->info.base.num_outputs;

   if (ctx->rasterizer->flatshade_first) {
  feState.provokingVertex = {1, 0, 0};
diff --git a/src/gallium/drivers/swr/swr_state.cpp 
b/src/gallium/drivers/swr/swr_state.cpp
index 501fdea..3e07929 100644
--- a/src/gallium/drivers/swr/swr_state.cpp
+++ b/src/gallium/drivers/swr/swr_state.cpp
@@ -345,13 +345,15 @@ swr_create_vs_state(struct pipe_context *pipe,
  // soState.streamToRasterizer not used

  for (uint32_t i = 0; i < stream_output->num_outputs; i++) {
+ unsigned attrib_slot = stream_output->output[i].register_index;
+ attrib_slot = swr_so_adjust_attrib(attrib_slot, swr_vs);
 swr_vs->soState.streamMasks[stream_output->output[i].stream] |=
-1 << (stream_output->output[i].register_index - 1);
+(1 << attrib_slot);
  }
  for (uint32_t i = 0; i < MAX_SO_STREAMS; i++) {
swr_vs->soState.streamNumEntries[i] =
 _mm_popcnt_u32(swr_vs->soState.streamMasks[i]);
-swr_vs->soState.vertexAttribOffset[i] = VERTEX_ATTRIB_START_SLOT; // 
TODO: optimize
+swr_vs->soState.vertexAttribOffset[i] = 0;
   }
   }

@@ -1777,6 +1779,31 @@ swr_update_derived(struct pipe_context *pipe,
   ctx->dirty = post_update_dirty_flags;
}

+unsigned
+swr_so_adjust_attrib(unsigned in_attrib,
+ swr_vertex_shader *swr_vs)
+{
+   ubyte semantic_name;
+   unsigned attrib;
+
+   attrib = in_attrib + VERTEX_ATTRIB_START_SLOT;
+
+   if (swr_vs) {
+  semantic_name = swr_vs->info.base.output_semantic_name[in_attrib];
+  if (semantic_name == TGSI_SEMANTIC_POSITION) {

But it's not just the position... there are plenty of other attributes
that need similar treatment. e.g. pointsize, layer, viewport index.

Yes, we want to deal with the other attributes, too, but lack the testing time, 
due to the 17.2 schedule.  Since position fixes the vtk tests (that we are 
mostly concerned about), that is what this patch covers.  It’s in our plan to 
deal with the rest of the attributes in the near future (before we get 
distracted).

I tried to fix this a while back but IIRC my solution was left wanting:

https://github.com/imirkin/mesa/commits/swr

(see the WIP commits at the top).

I ended up getting distracted and never completed the work. Feel free
to copy/ignore/whatever the above commits. I also tried 

Re: [Mesa-dev] [PATCH] swr: invalidate attachment on transition change

[Kyriazis, George]

+Bruce

Andres,

VTK/Kitware has already modified their code to enable dual depth peeling for 
Mesa version >= 17.2.  From that perspective, it doesn’t matter if the change 
goes into the 17.1.x releases or 17.2.

Having said that, we haven’t seen any issues with that check-in, so if it makes 
it to a release branch earlier than 17.2, it’s still a good thing for us.

Thanks!

George

> On Jul 7, 2017, at 4:11 PM, Andres Gomez  wrote:
> 
> George, would we want this patch in -stable or we shouldn't bother ?
> 
> On Tue, 2017-06-20 at 11:42 -0500, George Kyriazis wrote:
>> Consider the following RT attachment order:
>> 1. Attach surfaces attachments 0 & 1, and render with them
>> 2. Detach 0 & 1
>> 3. Re-attach 0 & 1 to different surfaces
>> 4. Render with the new attachment
>> 
>> The definition of a tile being resolved is that local changes have been
>> flushed out to the surface, hence there is no need to reload the tile before
>> it's written to.  For an invalid tile, the tile has to be reloaded from
>> the surface before rendering.
>> 
>> Stage (2) was marking hot tiles for attachements 0 & 1 as RESOLVED,
>> which means that the hot tiles can be written out to memory with no
>> need to read them back in (they are "clean").  They need to be marked as
>> resolved here, because a surface may be destroyed after a detach, and we
>> don't want to have un-resolved tiles that may force a readback from a
>> NULL (destroyed) surface.  (Part of a destroy is detach all attachments 
>> first)
>> 
>> Stage (3), during the no att -> att transition, we  need to realize that the
>> "new" surface tiles need to be fetched fresh from the new surface, instead
>> of using the resolved tiles, that belong to a stale attachment.
>> 
>> This is done by marking the hot tiles as invalid in stage (3), when we 
>> realize
>> that a new attachment is being made, so that they are re-fetched during
>> rendering in stage (4).
>> 
>> Also note that hot tiles are indexed by attachment.
>> 
>> - Fixes VTK dual depth-peeling tests.
>> - No piglit changes
>> ---
>> src/gallium/drivers/swr/swr_draw.cpp   | 19 +++
>> src/gallium/drivers/swr/swr_resource.h |  4 
>> src/gallium/drivers/swr/swr_state.cpp  |  5 +
>> 3 files changed, 28 insertions(+)
>> 
>> diff --git a/src/gallium/drivers/swr/swr_draw.cpp 
>> b/src/gallium/drivers/swr/swr_draw.cpp
>> index 03c82a7..ac300e2 100644
>> --- a/src/gallium/drivers/swr/swr_draw.cpp
>> +++ b/src/gallium/drivers/swr/swr_draw.cpp
>> @@ -215,6 +215,25 @@ swr_finish(struct pipe_context *pipe)
>>swr_fence_reference(pipe->screen, , NULL);
>> }
>> 
>> +/*
>> + * Invalidate tiles so they can be reloaded back when needed
>> + */
>> +void
>> +swr_invalidate_render_target(struct pipe_context *pipe,
>> + uint32_t attachment,
>> + uint16_t width, uint16_t height)
>> +{
>> +   struct swr_context *ctx = swr_context(pipe);
>> +
>> +   /* grab the rect from the passed in arguments */
>> +   swr_update_draw_context(ctx);
>> +   SWR_RECT full_rect =
>> +  {0, 0, (int32_t)width, (int32_t)height};
>> +   SwrInvalidateTiles(ctx->swrContext,
>> +  1 << attachment,
>> +  full_rect);
>> +}
>> +
>> 
>> /*
>>  * Store SWR HotTiles back to renderTarget surface.
>> diff --git a/src/gallium/drivers/swr/swr_resource.h 
>> b/src/gallium/drivers/swr/swr_resource.h
>> index ae9954c..4effd46 100644
>> --- a/src/gallium/drivers/swr/swr_resource.h
>> +++ b/src/gallium/drivers/swr/swr_resource.h
>> @@ -96,6 +96,10 @@ swr_resource_data(struct pipe_resource *resource)
>> }
>> 
>> 
>> +void swr_invalidate_render_target(struct pipe_context *pipe,
>> +  uint32_t attachment,
>> +  uint16_t width, uint16_t height);
>> +
>> void swr_store_render_target(struct pipe_context *pipe,
>>  uint32_t attachment,
>>  enum SWR_TILE_STATE post_tile_state);
>> diff --git a/src/gallium/drivers/swr/swr_state.cpp 
>> b/src/gallium/drivers/swr/swr_state.cpp
>> index 08549e5..deae4e6 100644
>> --- a/src/gallium/drivers/swr/swr_state.cpp
>> +++ b/src/gallium/drivers/swr/swr_state.cpp
>> @@ -933,6 +933,11 @@ swr_change_rt(struct swr_context *ctx,
>>* INVALID so they are reloaded from surface. */
>>   swr_store_render_target(>pipe, attachment, SWR_TILE_INVALID);
>>   need_fence = true;
>> +   } else {
>> +  /* if no previous attachment, invalidate tiles that may be marked
>> +   * RESOLVED because of an old attachment */
>> +  swr_invalidate_render_target(>pipe, attachment, sf->width, 
>> sf->height);
>> +  /* no need to set fence here */
>>}
>> 
>>/* Make new attachment */
> -- 
> Br,
> 
> Andres

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/11] mesa/glthread: remove HAVE_PTHREAD guards

[Kyriazis, George]

I can verify that the fix works.

Thank you!

George

> On Jun 26, 2017, at 3:24 PM, Marek Olšák <mar...@gmail.com> wrote:
> 
> I just pushed the fix.
> 
> Marek
> 
> On Mon, Jun 26, 2017 at 10:01 PM, Kyriazis, George
> <george.kyria...@intel.com> wrote:
>> Marek
>> 
>> Our windows mesa build broke with your checkin: "mesa/glthread: remove 
>> HAVE_PTHREAD guards”.
>> 
>> Namely:
>> 
>>  Compiling src\mesa\main\context.c ...
>> context.c
>> c:\users\gkyriazi\src\mesa\src\mesa\main\glthread.h(34): fatal error C1083: 
>> Cannot open include file: 'pthread.h': No such file or directory
>> scons: *** [build\windows-x86_64-debug\mesa\main\context.obj] Error 2
>> scons: building terminated because of errors.
>> 
>> Ideas?
>> 
>> George
>> 
>>> On Jun 21, 2017, at 8:02 PM, Marek Olšák <mar...@gmail.com> wrote:
>>> 
>>> From: Marek Olšák <marek.ol...@amd.com>
>>> 
>>> we are switching to util_queue.
>>> ---
>>> src/mapi/glapi/gen/gl_marshal.py |  5 +
>>> src/mesa/main/glthread.c |  4 
>>> src/mesa/main/glthread.h | 30 --
>>> src/mesa/main/marshal.c  |  4 
>>> src/mesa/main/marshal.h  | 27 ---
>>> 5 files changed, 1 insertion(+), 69 deletions(-)
>>> 
>>> diff --git a/src/mapi/glapi/gen/gl_marshal.py 
>>> b/src/mapi/glapi/gen/gl_marshal.py
>>> index f52b9b7..062afe5 100644
>>> --- a/src/mapi/glapi/gen/gl_marshal.py
>>> +++ b/src/mapi/glapi/gen/gl_marshal.py
>>> @@ -59,34 +59,31 @@ def indent(delta = 3):
>>> class PrintCode(gl_XML.gl_print_base):
>>>def __init__(self):
>>>super(PrintCode, self).__init__()
>>> 
>>>self.name = 'gl_marshal.py'
>>>self.license = license.bsd_license_template % (
>>>'Copyright (C) 2012 Intel Corporation', 'INTEL CORPORATION')
>>> 
>>>def printRealHeader(self):
>>>print header
>>> -print '#ifdef HAVE_PTHREAD'
>>> -print
>>>print 'static inline int safe_mul(int a, int b)'
>>>print '{'
>>>print 'if (a < 0 || b < 0) return -1;'
>>>print 'if (a == 0 || b == 0) return 0;'
>>>print 'if (a > INT_MAX / b) return -1;'
>>>print 'return a * b;'
>>>print '}'
>>>print
>>> 
>>>def printRealFooter(self):
>>> -print
>>> -print '#endif'
>>> +pass
>>> 
>>>def print_sync_call(self, func):
>>>call = 'CALL_{0}(ctx->CurrentServerDispatch, ({1}))'.format(
>>>func.name, func.get_called_parameter_string())
>>>if func.return_type == 'void':
>>>out('{0};'.format(call))
>>>else:
>>>out('return {0};'.format(call))
>>> 
>>>def print_sync_dispatch(self, func):
>>> diff --git a/src/mesa/main/glthread.c b/src/mesa/main/glthread.c
>>> index 455b829..e90709c 100644
>>> --- a/src/mesa/main/glthread.c
>>> +++ b/src/mesa/main/glthread.c
>>> @@ -31,22 +31,20 @@
>>> * quickly logs the GL commands to a buffer to be processed by a worker
>>> * thread.
>>> */
>>> 
>>> #include "main/mtypes.h"
>>> #include "main/glthread.h"
>>> #include "main/marshal.h"
>>> #include "main/marshal_generated.h"
>>> #include "util/u_thread.h"
>>> 
>>> -#ifdef HAVE_PTHREAD
>>> -
>>> static void
>>> glthread_allocate_batch(struct gl_context *ctx)
>>> {
>>>   struct glthread_state *glthread = ctx->GLThread;
>>> 
>>>   /* TODO: handle memory allocation failure. */
>>>   glthread->batch = malloc(sizeof(*glthread->batch));
>>>   if (!glthread->batch)
>>>  return;
>>>   memset(glthread->batch, 0, offsetof(struct glthread_batch, buffer));
>>> @@ -277,12 +275,10 @@ _mesa_glthread_finish(struct gl_context *ctx)
>>> _glapi_set_dispatch(dispatch);
>>>  }
>>>   } else {
>>>  _mesa_glthread_flush_batch_locked(ctx);
>>>  while (glthread->batch_queue || glthread->busy)
>>> pthread_cond_wait(>work_done, >mutex);
>>>   }
>>> 
>>>   pthread_mutex_unlock(&g

Re: [Mesa-dev] [PATCH 02/11] mesa/glthread: remove HAVE_PTHREAD guards

[Kyriazis, George]

Marek

Our windows mesa build broke with your checkin: "mesa/glthread: remove 
HAVE_PTHREAD guards”.

Namely:

  Compiling src\mesa\main\context.c ...
context.c
c:\users\gkyriazi\src\mesa\src\mesa\main\glthread.h(34): fatal error C1083: 
Cannot open include file: 'pthread.h': No such file or directory
scons: *** [build\windows-x86_64-debug\mesa\main\context.obj] Error 2
scons: building terminated because of errors.

Ideas?

George

> On Jun 21, 2017, at 8:02 PM, Marek Olšák  wrote:
> 
> From: Marek Olšák 
> 
> we are switching to util_queue.
> ---
> src/mapi/glapi/gen/gl_marshal.py |  5 +
> src/mesa/main/glthread.c |  4 
> src/mesa/main/glthread.h | 30 --
> src/mesa/main/marshal.c  |  4 
> src/mesa/main/marshal.h  | 27 ---
> 5 files changed, 1 insertion(+), 69 deletions(-)
> 
> diff --git a/src/mapi/glapi/gen/gl_marshal.py 
> b/src/mapi/glapi/gen/gl_marshal.py
> index f52b9b7..062afe5 100644
> --- a/src/mapi/glapi/gen/gl_marshal.py
> +++ b/src/mapi/glapi/gen/gl_marshal.py
> @@ -59,34 +59,31 @@ def indent(delta = 3):
> class PrintCode(gl_XML.gl_print_base):
> def __init__(self):
> super(PrintCode, self).__init__()
> 
> self.name = 'gl_marshal.py'
> self.license = license.bsd_license_template % (
> 'Copyright (C) 2012 Intel Corporation', 'INTEL CORPORATION')
> 
> def printRealHeader(self):
> print header
> -print '#ifdef HAVE_PTHREAD'
> -print
> print 'static inline int safe_mul(int a, int b)'
> print '{'
> print 'if (a < 0 || b < 0) return -1;'
> print 'if (a == 0 || b == 0) return 0;'
> print 'if (a > INT_MAX / b) return -1;'
> print 'return a * b;'
> print '}'
> print
> 
> def printRealFooter(self):
> -print
> -print '#endif'
> +pass
> 
> def print_sync_call(self, func):
> call = 'CALL_{0}(ctx->CurrentServerDispatch, ({1}))'.format(
> func.name, func.get_called_parameter_string())
> if func.return_type == 'void':
> out('{0};'.format(call))
> else:
> out('return {0};'.format(call))
> 
> def print_sync_dispatch(self, func):
> diff --git a/src/mesa/main/glthread.c b/src/mesa/main/glthread.c
> index 455b829..e90709c 100644
> --- a/src/mesa/main/glthread.c
> +++ b/src/mesa/main/glthread.c
> @@ -31,22 +31,20 @@
>  * quickly logs the GL commands to a buffer to be processed by a worker
>  * thread.
>  */
> 
> #include "main/mtypes.h"
> #include "main/glthread.h"
> #include "main/marshal.h"
> #include "main/marshal_generated.h"
> #include "util/u_thread.h"
> 
> -#ifdef HAVE_PTHREAD
> -
> static void
> glthread_allocate_batch(struct gl_context *ctx)
> {
>struct glthread_state *glthread = ctx->GLThread;
> 
>/* TODO: handle memory allocation failure. */
>glthread->batch = malloc(sizeof(*glthread->batch));
>if (!glthread->batch)
>   return;
>memset(glthread->batch, 0, offsetof(struct glthread_batch, buffer));
> @@ -277,12 +275,10 @@ _mesa_glthread_finish(struct gl_context *ctx)
>  _glapi_set_dispatch(dispatch);
>   }
>} else {
>   _mesa_glthread_flush_batch_locked(ctx);
>   while (glthread->batch_queue || glthread->busy)
>  pthread_cond_wait(>work_done, >mutex);
>}
> 
>pthread_mutex_unlock(>mutex);
> }
> -
> -#endif
> diff --git a/src/mesa/main/glthread.h b/src/mesa/main/glthread.h
> index 50c1db2..07bed38 100644
> --- a/src/mesa/main/glthread.h
> +++ b/src/mesa/main/glthread.h
> @@ -22,22 +22,20 @@
>  */
> 
> #ifndef _GLTHREAD_H
> #define _GLTHREAD_H
> 
> #include "main/mtypes.h"
> 
> /* Command size is a number of bytes stored in a short. */
> #define MARSHAL_MAX_CMD_SIZE 65535
> 
> -#ifdef HAVE_PTHREAD
> -
> #include 
> #include 
> #include 
> 
> enum marshal_dispatch_cmd_id;
> 
> struct glthread_state
> {
>/** The worker thread that asynchronously processes our GL commands. */
>pthread_t thread;
> @@ -117,39 +115,11 @@ struct glthread_batch
>uint8_t buffer[MARSHAL_MAX_CMD_SIZE];
> };
> 
> void _mesa_glthread_init(struct gl_context *ctx);
> void _mesa_glthread_destroy(struct gl_context *ctx);
> 
> void _mesa_glthread_restore_dispatch(struct gl_context *ctx);
> void _mesa_glthread_flush_batch(struct gl_context *ctx);
> void _mesa_glthread_finish(struct gl_context *ctx);
> 
> -#else /* HAVE_PTHREAD */
> -
> -static inline void
> -_mesa_glthread_init(struct gl_context *ctx)
> -{
> -}
> -
> -static inline void
> -_mesa_glthread_destroy(struct gl_context *ctx)
> -{
> -}
> -
> -static inline void
> -_mesa_glthread_finish(struct gl_context *ctx)
> -{
> -}
> -
> -static inline void
> -_mesa_glthread_restore_dispatch(struct gl_context *ctx)
> -{
> -}
> -
> -static inline void
> -_mesa_glthread_flush_batch(struct gl_context *ctx)
> -{
> -}
> -
> -#endif /* !HAVE_PTHREAD */
> 

Re: [Mesa-dev] [PATCH 2/2] swr: Fix polygonmode for front==back

[Kyriazis, George]

I am perfectly fine not submitting into stable.  And can remove the assert, 
since it’s causing trouble.

FWIW, piglit llvmpipe.py fixes 3 tests with no regressions.

George

On Apr 25, 2017, at 9:23 PM, Rowley, Timothy O 
> wrote:

Additionally I don’t think this should go into stable - without the 
corresponding rasterizer commit (which feels like a risky change post -rc1) it 
is of limited use.

On Apr 25, 2017, at 6:58 PM, Ilia Mirkin 
> wrote:

This will cause asserts on piglit and dEQP runs instead of failures. This is 
incredibly inconvenient, as e.g. dEQP runs everything in a single process.

On Apr 25, 2017 7:29 PM, "George Kyriazis" 
> wrote:
Add logic for converting enums and also making sure stipple works.

CC: 
>

---
 src/gallium/drivers/swr/swr_state.cpp | 14 +-
 src/gallium/drivers/swr/swr_state.h   | 20 
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/swr/swr_state.cpp 
b/src/gallium/drivers/swr/swr_state.cpp
index 56b1374..24a6759 100644
--- a/src/gallium/drivers/swr/swr_state.cpp
+++ b/src/gallium/drivers/swr/swr_state.cpp
@@ -201,6 +201,12 @@ swr_create_rasterizer_state(struct pipe_context *pipe,
struct pipe_rasterizer_state *state;
state = (pipe_rasterizer_state *)mem_dup(rast, sizeof *rast);

+   if (state) {
+  if (state->fill_front != state->fill_back) {
+ assert(0 && "front != back polygon mode not supported");
+  }
+   }
+
return state;
 }

@@ -1153,6 +1159,10 @@ swr_update_derived(struct pipe_context *pipe,
  rastState->slopeScaledDepthBias = 0;
  rastState->depthBiasClamp = 0;
   }
+
+  /* translate polygon mode, at least for the front==back case */
+  rastState->fillMode = swr_convert_fill_mode(rasterizer->fill_front);
+
   struct pipe_surface *zb = fb->zsbuf;
   if (zb && swr_resource(zb->texture)->has_depth)
  rastState->depthFormat = swr_resource(zb->texture)->swr.format;
@@ -1423,7 +1433,9 @@ swr_update_derived(struct pipe_context *pipe,
/* and points, since we rasterize them as triangles, too */
/* Has to be before fragment shader, since it sets SWR_NEW_FS */
if (p_draw_info) {
-  bool new_prim_is_poly = (u_reduced_prim(p_draw_info->mode) == 
PIPE_PRIM_TRIANGLES);
+  bool new_prim_is_poly =
+ (u_reduced_prim(p_draw_info->mode) == PIPE_PRIM_TRIANGLES) &&
+ (ctx->derived.rastState.fillMode == SWR_FILLMODE_SOLID);
   if (new_prim_is_poly != ctx->poly_stipple.prim_is_poly) {
  ctx->dirty |= SWR_NEW_FS;
  ctx->poly_stipple.prim_is_poly = new_prim_is_poly;
diff --git a/src/gallium/drivers/swr/swr_state.h 
b/src/gallium/drivers/swr/swr_state.h
index 9a8c4e1..7940a96 100644
--- a/src/gallium/drivers/swr/swr_state.h
+++ b/src/gallium/drivers/swr/swr_state.h
@@ -376,4 +376,24 @@ swr_convert_prim_topology(const unsigned mode)
   return TOP_UNKNOWN;
}
 };
+
+/*
+ * convert mesa PIPE_POLYGON_MODE_X to SWR enum SWR_FILLMODE
+ */
+static INLINE enum SWR_FILLMODE
+swr_convert_fill_mode(const unsigned mode)
+{
+   switch(mode) {
+   case PIPE_POLYGON_MODE_FILL:
+  return SWR_FILLMODE_SOLID;
+   case PIPE_POLYGON_MODE_LINE:
+  return SWR_FILLMODE_WIREFRAME;
+   case PIPE_POLYGON_MODE_POINT:
+  return SWR_FILLMODE_POINT;
+   default:
+  assert(0 && "Unknown fillmode");
+  return SWR_FILLMODE_SOLID; // at least do something sensible
+   }
+}
+
 #endif
--
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 10/14] travis: add "scons swr" to the build matrix

[Kyriazis, George]

As discussed,

If you run scons with a small -j number, it would work (verified by Emil).

With that change

Reviewed-by: George Kyriazis 
>

For the rest of the series, I don’t have enough experience with travis to 
review..

George

On Apr 21, 2017, at 7:08 AM, Emil Velikov 
> wrote:

From: Emil Velikov 
>

Requires GCC 5.0 (due to the C++14 requirement) and LLVM 3.9.

v2: Enable the target, add libedit-dev, rework check target.

Cc: Tim Rowley >
Cc: George Kyriazis 
>
Signed-off-by: Emil Velikov 
>
---
Note!
With this the Travis instance seems to be having Internal Compiler Error
at various stages of the build. Both GCC5 and GCC6 are affected, yet the
Autotools build (coming later) seems unaffected.

Tim, George do you guys have some time to investigate the problem?
Alternatively we'll have to drop the patch for now :-(
---
.travis.yml | 28 
1 file changed, 28 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index 6eb208ace24..aa2a55d7bb4 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -82,6 +82,32 @@ matrix:
- libexpat1-dev
- libx11-xcb-dev
- libelf-dev
+- env:
+- LABEL="scons SWR"
+- BUILD=scons
+- SCONS_TARGET="swr=1"
+- SCONS_CHECK_COMMAND="true"
+- LLVM_VERSION=3.9
+- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
+- OVERRIDE_CC=gcc-5
+- OVERRIDE_CXX=g++-5
+  addons:
+apt:
+  sources:
+- ubuntu-toolchain-r-test
+- llvm-toolchain-trusty-3.9
+  packages:
+- scons
+# LLVM packaging is broken and misses these dependencies
+- libedit-dev
+# From sources above
+- g++-5
+- llvm-3.9-dev
+# Common
+- x11proto-xf86vidmode-dev
+- libexpat1-dev
+- libx11-xcb-dev
+- libelf-dev

install:
  - pip install --user mako
@@ -157,5 +183,7 @@ script:
fi

  - if test "x$BUILD" = xscons; then
+  test $OVERRIDE_CC && export CC=$OVERRIDE_CC;
+  test $OVERRIDE_CXX && export CXX=$OVERRIDE_CXX;
  scons $SCONS_TARGET && eval $SCONS_CHECK_COMMAND;
fi
--
2.12.2


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 10/14] travis: add "scons swr" to the build matrix

[Kyriazis, George]

rasterizer.cpp takes a lot of resources to compile.  Looks like the autotools 
build runs -j2, which limits the exposure, because of fewer parallel jobs, 
while scons, by default is more aggressive.

Suggest running scons -j 1 or scons -j 2 for swr.

Thanks,

George

> On Apr 21, 2017, at 7:08 AM, Emil Velikov  wrote:
> 
> From: Emil Velikov 
> 
> Requires GCC 5.0 (due to the C++14 requirement) and LLVM 3.9.
> 
> v2: Enable the target, add libedit-dev, rework check target.
> 
> Cc: Tim Rowley 
> Cc: George Kyriazis 
> Signed-off-by: Emil Velikov 
> ---
> Note!
> With this the Travis instance seems to be having Internal Compiler Error
> at various stages of the build. Both GCC5 and GCC6 are affected, yet the
> Autotools build (coming later) seems unaffected.
> 
> Tim, George do you guys have some time to investigate the problem?
> Alternatively we'll have to drop the patch for now :-(
> ---
> .travis.yml | 28 
> 1 file changed, 28 insertions(+)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 6eb208ace24..aa2a55d7bb4 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -82,6 +82,32 @@ matrix:
> - libexpat1-dev
> - libx11-xcb-dev
> - libelf-dev
> +- env:
> +- LABEL="scons SWR"
> +- BUILD=scons
> +- SCONS_TARGET="swr=1"
> +- SCONS_CHECK_COMMAND="true"
> +- LLVM_VERSION=3.9
> +- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> +- OVERRIDE_CC=gcc-5
> +- OVERRIDE_CXX=g++-5
> +  addons:
> +apt:
> +  sources:
> +- ubuntu-toolchain-r-test
> +- llvm-toolchain-trusty-3.9
> +  packages:
> +- scons
> +# LLVM packaging is broken and misses these dependencies
> +- libedit-dev
> +# From sources above
> +- g++-5
> +- llvm-3.9-dev
> +# Common
> +- x11proto-xf86vidmode-dev
> +- libexpat1-dev
> +- libx11-xcb-dev
> +- libelf-dev
> 
> install:
>   - pip install --user mako
> @@ -157,5 +183,7 @@ script:
> fi
> 
>   - if test "x$BUILD" = xscons; then
> +  test $OVERRIDE_CC && export CC=$OVERRIDE_CC;
> +  test $OVERRIDE_CXX && export CXX=$OVERRIDE_CXX;
>   scons $SCONS_TARGET && eval $SCONS_CHECK_COMMAND;
> fi
> -- 
> 2.12.2
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr: Fix swr osmesa build

[Kyriazis, George]

Thanks Emil,

I will attempt to un-meh a bit at checkin.

George

> On Apr 14, 2017, at 5:52 PM, Emil Velikov  wrote:
> 
> Commit summary is a bit meh, but regardless.
> 
> Reviewed-by: Emil Velikov 
> 
> -Emil

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr: Enable MSAA in OpenSWR software renderer

[Kyriazis, George]

Reviewed-by: George Kyriazis 
>

With the assumption that there are additional changes forthcoming.

On Apr 13, 2017, at 5:40 PM, Bruce Cherniak 
> wrote:

This patch enables multisample antialiasing in the OpenSWR software renderer.

MSAA is a proof-of-concept/work-in-progress with bug fixes and performance
on the way.  We wanted to get the changes out now to allow several customers
to begin experimenting with MSAA in a software renderer.  So as not to
impact current customers, MSAA is turned off by default - previous
functionality and performance remain intact.  It is easily enabled via
environment variables, as described below.

It has only been tested with the glx-lib winsys.  The intention is to
enable other state-trackers, both Windows and Linux and more fully support
FBOs.

There are 2 environment variables that affect behavior:

* SWR_MSAA_FORCE_ENABLE - force MSAA on, for apps that are not designed
 for MSAA... Beware, results will vary.  This is mainly for testing.

* SWR_MSAA_MAX_SAMPLE_COUNT - sets maximum supported number of
 samples (1,2,4,8,16), or 0 to disable MSAA altogether.
 (The default is currently 0.)


---
src/gallium/drivers/swr/swr_context.cpp |  90 +-
src/gallium/drivers/swr/swr_context.h   |   3 +
src/gallium/drivers/swr/swr_resource.h  |   4 +
src/gallium/drivers/swr/swr_screen.cpp  | 159 +---
src/gallium/drivers/swr/swr_screen.h|   8 ++
src/gallium/drivers/swr/swr_state.cpp   |  74 +--
6 files changed, 313 insertions(+), 25 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_context.cpp 
b/src/gallium/drivers/swr/swr_context.cpp
index 6f46d66..aa5cca8 100644
--- a/src/gallium/drivers/swr/swr_context.cpp
+++ b/src/gallium/drivers/swr/swr_context.cpp
@@ -267,20 +267,104 @@ swr_resource_copy(struct pipe_context *pipe,
}


+/* XXX: This resolve is incomplete and suboptimal. It will be removed once the
+ * pipelined resolve blit works. */
+void
+swr_do_msaa_resolve(struct pipe_resource *src_resource,
+struct pipe_resource *dst_resource)
+{
+   /* This is a pretty dumb inline resolve.  It only supports 8-bit formats
+* (ex RGBA8/BGRA8) - which are most common display formats anyway.
+*/
+
+   /* quick check for 8-bit and number of components */
+   uint8_t bits_per_component =
+  util_format_get_component_bits(src_resource->format,
+UTIL_FORMAT_COLORSPACE_RGB, 0);
+
+   /* Unsupported resolve format */
+   assert(src_resource->format == dst_resource->format);
+   assert(bits_per_component == 8);
+   if ((src_resource->format != dst_resource->format) ||
+   (bits_per_component != 8)) {
+  return;
+   }
+
+   uint8_t src_num_comps = util_format_get_nr_components(src_resource->format);
+
+   SWR_SURFACE_STATE *src_surface = _resource(src_resource)->swr;
+   SWR_SURFACE_STATE *dst_surface = _resource(dst_resource)->swr;
+
+   uint32_t *src, *dst, offset;
+   uint32_t num_samples = src_surface->numSamples;
+   float recip_num_samples = 1.0f / num_samples;
+   for (uint32_t y = 0; y < src_surface->height; y++) {
+  for (uint32_t x = 0; x < src_surface->width; x++) {
+ float r = 0.0f;
+ float g = 0.0f;
+ float b = 0.0f;
+ float a = 0.0f;
+ for (uint32_t sampleNum = 0;  sampleNum < num_samples; sampleNum++) {
+offset = ComputeSurfaceOffset(x, y, 0, 0, sampleNum, 0, 
src_surface);
+src = (uint32_t *) src_surface->pBaseAddress + 
offset/src_num_comps;
+const uint32_t sample = *src;
+r += (float)((sample >> 24) & 0xff) / 255.0f * recip_num_samples;
+g += (float)((sample >> 16) & 0xff) / 255.0f * recip_num_samples;
+b += (float)((sample >>  8) & 0xff) / 255.0f * recip_num_samples;
+a += (float)((sample  ) & 0xff) / 255.0f * recip_num_samples;
+ }
+ uint32_t result = 0;
+ result  = ((uint8_t)(r * 255.0f) & 0xff) << 24;
+ result |= ((uint8_t)(g * 255.0f) & 0xff) << 16;
+ result |= ((uint8_t)(b * 255.0f) & 0xff) <<  8;
+ result |= ((uint8_t)(a * 255.0f) & 0xff);
+ offset = ComputeSurfaceOffset(x, y, 0, 0, 0, 0, src_surface);
+ dst = (uint32_t *) dst_surface->pBaseAddress + offset/src_num_comps;
+ *dst = result;
+  }
+   }
+}
+
+
static void
swr_blit(struct pipe_context *pipe, const struct pipe_blit_info *blit_info)
{
   struct swr_context *ctx = swr_context(pipe);
+   /* Make a copy of the const blit_info, so we can modify it */
   struct pipe_blit_info info = *blit_info;

-   if (blit_info->render_condition_enable && !swr_check_render_cond(pipe))
+   if (info.render_condition_enable && !swr_check_render_cond(pipe))
  return;

   if (info.src.resource->nr_samples > 1 && info.dst.resource->nr_samples <= 1
   && 

Re: [Mesa-dev] [PATCH] swr: Add polygon stipple support

[Kyriazis, George]

On Apr 14, 2017, at 11:35 AM, Ilia Mirkin 
> wrote:

On Fri, Apr 14, 2017 at 11:18 AM, Ilia Mirkin 
> wrote:
On Thu, Apr 13, 2017 at 4:30 PM, George Kyriazis
> wrote:
Add polygon stipple functionality to the fragment shader.

Explicitly turn off polygon stipple for lines and points, since we
do them using tris.
---
src/gallium/drivers/swr/swr_context.h  |  4 ++-
src/gallium/drivers/swr/swr_shader.cpp | 56 ++
src/gallium/drivers/swr/swr_shader.h   |  1 +
src/gallium/drivers/swr/swr_state.cpp  | 27 ++--
src/gallium/drivers/swr/swr_state.h|  5 +++
5 files changed, 84 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_context.h 
b/src/gallium/drivers/swr/swr_context.h
index be65a20..9d80c70 100644
--- a/src/gallium/drivers/swr/swr_context.h
+++ b/src/gallium/drivers/swr/swr_context.h
@@ -98,6 +98,8 @@ struct swr_draw_context {

   float userClipPlanes[PIPE_MAX_CLIP_PLANES][4];

+   uint32_t polyStipple[32];
+
   SWR_SURFACE_STATE renderTargets[SWR_NUM_ATTACHMENTS];
   void *pStats;
};
@@ -127,7 +129,7 @@ struct swr_context {
   struct pipe_constant_buffer
  constants[PIPE_SHADER_TYPES][PIPE_MAX_CONSTANT_BUFFERS];
   struct pipe_framebuffer_state framebuffer;
-   struct pipe_poly_stipple poly_stipple;
+   struct swr_poly_stipple poly_stipple;
   struct pipe_scissor_state scissor;
   SWR_RECT swr_scissor;
   struct pipe_sampler_view *
diff --git a/src/gallium/drivers/swr/swr_shader.cpp 
b/src/gallium/drivers/swr/swr_shader.cpp
index 6fc0596..d8f5512 100644
--- a/src/gallium/drivers/swr/swr_shader.cpp
+++ b/src/gallium/drivers/swr/swr_shader.cpp
@@ -165,6 +165,9 @@ swr_generate_fs_key(struct swr_jit_fs_key ,
  sizeof(key.vs_output_semantic_idx));

   swr_generate_sampler_key(swr_fs->info, ctx, PIPE_SHADER_FRAGMENT, key);
+
+   key.poly_stipple_enable = ctx->rasterizer->poly_stipple_enable &&
+  ctx->poly_stipple.prim_is_poly;
}

void
@@ -1099,17 +1102,58 @@ BuilderSWR::CompileFS(struct swr_context *ctx, 
swr_jit_fs_key )
   memset(_values, 0, sizeof(system_values));

   struct lp_build_mask_context mask;
+   bool uses_mask = false;

-   if (swr_fs->info.base.uses_kill) {
-  Value *mask_val = LOAD(pPS, {0, SWR_PS_CONTEXT_activeMask}, 
"activeMask");
+   if (swr_fs->info.base.uses_kill ||
+   key.poly_stipple_enable) {
+  Value *vActiveMask = NULL;
+  if (swr_fs->info.base.uses_kill) {
+ vActiveMask = LOAD(pPS, {0, SWR_PS_CONTEXT_activeMask}, "activeMask");
+  }
+  if (key.poly_stipple_enable) {
+ // first get fragment xy coords and clip to stipple bounds
+ Value *vXf = LOAD(pPS, {0, SWR_PS_CONTEXT_vX, PixelPositions_UL});
+ Value *vYf = LOAD(pPS, {0, SWR_PS_CONTEXT_vY, PixelPositions_UL});
+ Value *vXu = FP_TO_UI(vXf, mSimdInt32Ty);
+ Value *vYu = FP_TO_UI(vYf, mSimdInt32Ty);
+
+ // stipple pattern is 32x32, which means that one line of stipple
+ // is stored in one word:
+ // vXstipple is bit offset inside 32-bit stipple word
+ // vYstipple is word index is stipple array
+ Value *vXstipple = AND(vXu, VIMMED1(0x1f)); // & (32-1)
+ Value *vYstipple = AND(vYu, VIMMED1(0x1f)); // & (32-1)
+
+ // grab stipple pattern base address
+ Value *stipplePtr = GEP(hPrivateData, {0, 
swr_draw_context_polyStipple, 0});
+ stipplePtr = BITCAST(stipplePtr, mInt8PtrTy);
+
+ // peform a gather to grab stipple words for each lane
+ Value *vStipple = GATHERDD(VUNDEF_I(), stipplePtr, vYstipple,
+VIMMED1(0x), C((char)4));
+
+ // create a mask with one bit corresponding to the x stipple
+ // and AND it with the pattern, to see if we have a bit
+ Value *vBitMask = LSHR(VIMMED1(0x8000), vXstipple);
+ Value *vStippleMask = AND(vStipple, vBitMask);
+ vStippleMask = ICMP_NE(vStippleMask, VIMMED1(0));
+ vStippleMask = VMASK(vStippleMask);
+
+ if (swr_fs->info.base.uses_kill) {
+vActiveMask = AND(vActiveMask, vStippleMask);
+ } else {
+vActiveMask = vStippleMask;
+ }
+  }
  lp_build_mask_begin(
- , gallivm, lp_type_float_vec(32, 32 * 8), wrap(mask_val));
+ , gallivm, lp_type_float_vec(32, 32 * 8), wrap(vActiveMask));
+  uses_mask = true;
   }

   lp_build_tgsi_soa(gallivm,
 swr_fs->pipe.tokens,
 lp_type_float_vec(32, 32 * 8),
- swr_fs->info.base.uses_kill ?  : NULL, // mask
+ uses_mask ?  : NULL, // mask
 wrap(consts_ptr),
 wrap(const_sizes_ptr),
 _values,
@@ -1172,13 +1216,13 @@ BuilderSWR::CompileFS(struct swr_context *ctx, 

Re: [Mesa-dev] [PATCH] swr: add linux to scons build

[Kyriazis, George]

On Apr 14, 2017, at 12:44 PM, Emil Velikov 
> wrote:

On 13 April 2017 at 20:17, George Kyriazis 
> wrote:
Make swr compile for both linux and windows.
---
src/gallium/drivers/swr/SConscript| 7 +--
src/gallium/targets/libgl-xlib/SConscript | 2 +-
2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/swr/SConscript 
b/src/gallium/drivers/swr/SConscript
index eca5dba..5e3784b 100644
--- a/src/gallium/drivers/swr/SConscript
+++ b/src/gallium/drivers/swr/SConscript
@@ -17,11 +17,6 @@ if env['LLVM_VERSION'] < 
distutils.version.LooseVersion('3.9'):
env['swr'] = False
Return()

-if env['platform'] != 'windows':
-print "warning: swr scons build only supports windows: not building swr"
-env['swr'] = False
-Return()
-
env.MSVC2013Compat()

env = env.Clone()
@@ -205,7 +200,7 @@ envavx2.Append(CPPDEFINES = ['KNOB_ARCH=KNOB_ARCH_AVX2'])
if env['platform'] == 'windows':
envavx2.Append(CCFLAGS = ['/arch:AVX2'])
else:
-envavx2.Append(CCFLAGS = ['-mavx2'])
+envavx2.Append(CCFLAGS = ['-mavx2', '-mfma', '-mbmi2', '-mf16c'])

swrAVX2 = envavx2.SharedLibrary(
target = 'swrAVX2',
diff --git a/src/gallium/targets/libgl-xlib/SConscript 
b/src/gallium/targets/libgl-xlib/SConscript
index d01bb3c..a81ac79 100644
--- a/src/gallium/targets/libgl-xlib/SConscript
+++ b/src/gallium/targets/libgl-xlib/SConscript
@@ -49,7 +49,7 @@ if env['llvm']:
env.Prepend(LIBS = [llvmpipe])

if env['swr']:
-env.Append(CPPDEFINES = 'HAVE_SWR')
+env.Append(CPPDEFINES = 'GALLIUM_SWR')
Seems like we want the same fix in src/gallium/targets/osmesa/SConscript.
Please squash that alongside a small note in docs/relnotes/17.1.0.html

Checkin is already submitted, so I’ll make a foliow-up commit with those 
changes.

With the above
Reviewed-by: Emil Velikov 
>

As a follow-up commit can we have $sed -i s/HAVE_/GALLIUM_
src/gallium/targets/libgl-xlib/* && git commit -asm “…”

Yes, I want to fix this, too, and I was planning on doing it on a later commit.

Thanks,

George


Thanks
Emil

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] docs: document the C++14 SWR requirement

[Kyriazis, George]

On Apr 12, 2017, at 10:03 AM, Rowley, Timothy O 
> wrote:


On Apr 12, 2017, at 9:11 AM, Emil Velikov 
> wrote:

From: Emil Velikov 
>

Earlier commit bumped the requirement for the SWR driver.

Cc: Tim Rowley >
Fixes: 3c52a7316a1 ("swr: [configure.ac/scons] require c++14")
Signed-off-by: Emil Velikov 
>
---
Tim, couple of unrelated questions:
- Did you get to nuke the in-tree mako copy?

Yes, this is now gone.

- Any plans on adding !Windows support in the scons build?

George is the one working with scons.  George, your thoughts?

Yes, I can add a check for !windows.

George


docs/relnotes/17.1.0.html | 1 +
1 file changed, 1 insertion(+)

diff --git a/docs/relnotes/17.1.0.html b/docs/relnotes/17.1.0.html
index 0a5cabe4f1b..eb324e25a44 100644
--- a/docs/relnotes/17.1.0.html
+++ b/docs/relnotes/17.1.0.html
@@ -68,6 +68,7 @@ Note: some of the new features are only available with 
certain drivers.
The swr driver now requires LLVM = 3.9.0.
The radeonsi driver now requires LLVM 3.8.0.
The MESA_GLSL=opt and MESA_GLSL=no_opt environment vars have been 
removed.
+The SWR gallium driver now requires C++14 capable compiler

Wording should be adjusted to “The SWR gallium driver now requires a C++14 
capable compiler.”

Or possibly the two swr items could be combined: “The swr driver now requires 
LLVM >= 3.9.0 and a C++14 capable compiler."

Pick your poison, Reviewed-by: Tim Rowley 
>


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 10/10] swr: [rasterizer codegen] Fix windows build

[Kyriazis, George]

Tried Depends(), but it doesn’t work all the time.  There are some cases where 
it works, and some others where it doesn’t.

I’ll need to investigate more.  Fix in a separate checkin later?

George

On Mar 27, 2017, at 8:38 PM, Rowley, Timothy O 
> wrote:

On closer review of 10/10, I don’t like the approach taken here.

You’ve added a —template argument to gen_backends.py, making it different from 
the rest of the scripts and actually running it with different parameters on 
automake and scons.  Can’t you get scons to have the necessary dependency using 
its Depends() call?

http://scons.org/doc/production/HTML/scons-user/ch06s05.html

On Mar 27, 2017, at 7:39 PM, George Kyriazis 
> wrote:

Fix codegen build break that was introduced earlier

v2: update rules for gen_knobs.cpp and gen_knobs.h

---
src/gallium/drivers/swr/Makefile.am|  4 +--
src/gallium/drivers/swr/SConscript | 15 ++-
.../drivers/swr/rasterizer/codegen/gen_backends.py | 30 ++
.../swr/rasterizer/codegen/gen_llvm_ir_macros.py   | 20 +++
4 files changed, 39 insertions(+), 30 deletions(-)

diff --git a/src/gallium/drivers/swr/Makefile.am 
b/src/gallium/drivers/swr/Makefile.am
index 515a9089cc..cc37abf3e8 100644
--- a/src/gallium/drivers/swr/Makefile.am
+++ b/src/gallium/drivers/swr/Makefile.am
@@ -97,14 +97,14 @@ rasterizer/jitter/gen_builder.hpp: 
rasterizer/codegen/gen_llvm_ir_macros.py rast
$(PYTHON_GEN) \
$(srcdir)/rasterizer/codegen/gen_llvm_ir_macros.py \
--input $(LLVM_INCLUDEDIR)/llvm/IR/IRBuilder.h \
- --output rasterizer/jitter \
+ --output $@ \
--gen_h

rasterizer/jitter/gen_builder_x86.hpp: rasterizer/codegen/gen_llvm_ir_macros.py 
rasterizer/codegen/templates/gen_builder.hpp rasterizer/codegen/gen_common.py
$(MKDIR_GEN)
$(PYTHON_GEN) \
$(srcdir)/rasterizer/codegen/gen_llvm_ir_macros.py \
- --output rasterizer/jitter \
+ --output $@ \
--gen_x86_h

rasterizer/archrast/gen_ar_event.hpp: rasterizer/codegen/gen_archrast.py 
rasterizer/codegen/templates/gen_ar_event.hpp rasterizer/archrast/events.proto 
rasterizer/codegen/gen_common.py
diff --git a/src/gallium/drivers/swr/SConscript 
b/src/gallium/drivers/swr/SConscript
index ad16162c29..aa4a8e6d55 100644
--- a/src/gallium/drivers/swr/SConscript
+++ b/src/gallium/drivers/swr/SConscript
@@ -51,15 +51,15 @@ swrroot = '#src/gallium/drivers/swr/'
env.CodeGenerate(
target = 'rasterizer/codegen/gen_knobs.cpp',
script = swrroot + 'rasterizer/codegen/gen_knobs.py',
-source = 'rasterizer/codegen/templates/gen_knobs.cpp',
-command = python_cmd + ' $SCRIPT --input $SOURCE --output $TARGET 
--gen_cpp'
+source = '',
+command = python_cmd + ' $SCRIPT --output $TARGET --gen_cpp'
)

env.CodeGenerate(
target = 'rasterizer/codegen/gen_knobs.h',
script = swrroot + 'rasterizer/codegen/gen_knobs.py',
-source = 'rasterizer/codegen/templates/gen_knobs.cpp',
-command = python_cmd + ' $SCRIPT --input $SOURCE --output $TARGET --gen_h'
+source = '',
+command = python_cmd + ' $SCRIPT --output $TARGET --gen_h'
)

env.CodeGenerate(
@@ -73,14 +73,14 @@ env.CodeGenerate(
target = 'rasterizer/jitter/gen_builder.hpp',
script = swrroot + 'rasterizer/codegen/gen_llvm_ir_macros.py',
source = os.path.join(llvm_includedir, 'llvm/IR/IRBuilder.h'),
-command = python_cmd + ' $SCRIPT --input $SOURCE --output 
rasterizer/jitter --gen_h'
+command = python_cmd + ' $SCRIPT --input $SOURCE --output $TARGET --gen_h'
)

env.CodeGenerate(
target = 'rasterizer/jitter/gen_builder_x86.hpp',
script = swrroot + 'rasterizer/codegen/gen_llvm_ir_macros.py',
source = '',
-command = python_cmd + ' $SCRIPT --output rasterizer/jitter --gen_x86_h'
+command = python_cmd + ' $SCRIPT --output $TARGET --gen_x86_h'
)

env.CodeGenerate(
@@ -127,7 +127,8 @@ env.CodeGenerate(
env.CodeGenerate(
target = 'rasterizer/core/gen_BackendPixelRate0.cpp',
script = swrroot + 'rasterizer/codegen/gen_backends.py',
-command = python_cmd + ' $SCRIPT --output rasterizer/core --dim 5 2 3 2 2 
2 --split 0 --cpp'
+source = swrroot + 'rasterizer/codegen/templates/gen_backend.cpp',
+command = python_cmd + ' $SCRIPT --output $TARGET --template $SOURCE --dim 
5 2 3 2 2 2 --split 0 --cpp'
)

# Auto-generated .cpp files (that need to generate object files)
diff --git a/src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py 
b/src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py
index 242ab7a73e..8f7ba94ba1 100644
--- a/src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py
+++ b/src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py
@@ -34,7 +34,10 @@ def main(args=sys.argv[1:]):
parser = ArgumentParser("Generate files and initialization functions for 
all permutuations of BackendPixelRate.")
parser.add_argument('--dim', help="gBackendPixelRateTable array 

Re: [Mesa-dev] [PATCH 01/10] swr: [rasterizer codegen] Refactor codegen

[Kyriazis, George]

Apart from 01/10 and 10/10 (that have been discussed in other emails), patches 
02/10 to 09/10

Reviewed-By: George Kyriazis 
>


On Mar 25, 2017, at 7:00 AM, Tim Rowley 
> wrote:

Move common codegen functions into gen_common.py.
---
src/gallium/drivers/swr/Makefile.am|  22 +--
.../drivers/swr/rasterizer/codegen/gen_archrast.py |  30 +---
.../drivers/swr/rasterizer/codegen/gen_backends.py |  30 +---
.../drivers/swr/rasterizer/codegen/gen_common.py   | 162 +
.../drivers/swr/rasterizer/codegen/gen_knobs.py|  55 +++
.../swr/rasterizer/codegen/gen_llvm_ir_macros.py   |  35 +
.../swr/rasterizer/codegen/gen_llvm_types.py   |  32 +---
7 files changed, 212 insertions(+), 154 deletions(-)
create mode 100644 src/gallium/drivers/swr/rasterizer/codegen/gen_common.py

diff --git a/src/gallium/drivers/swr/Makefile.am 
b/src/gallium/drivers/swr/Makefile.am
index 8ba9ac9..3a0d8da 100644
--- a/src/gallium/drivers/swr/Makefile.am
+++ b/src/gallium/drivers/swr/Makefile.am
@@ -71,30 +71,30 @@ gen_swr_context_llvm.h: 
rasterizer/codegen/gen_llvm_types.py rasterizer/codegen/
--input $(srcdir)/swr_context.h \
--output ./gen_swr_context_llvm.h

-rasterizer/codegen/gen_knobs.cpp: rasterizer/codegen/gen_knobs.py 
rasterizer/codegen/knob_defs.py rasterizer/codegen/templates/gen_knobs.cpp
+rasterizer/codegen/gen_knobs.cpp: rasterizer/codegen/gen_knobs.py 
rasterizer/codegen/knob_defs.py rasterizer/codegen/templates/gen_knobs.cpp 
rasterizer/codegen/gen_common.py
$(MKDIR_GEN)
$(PYTHON_GEN) \
$(srcdir)/rasterizer/codegen/gen_knobs.py \
- --input $(srcdir)/rasterizer/codegen/templates/gen_knobs.cpp \
+ --input $(realpath $(srcdir)/rasterizer/codegen/templates/gen_knobs.cpp) \
--output rasterizer/codegen/gen_knobs.cpp \
--gen_cpp

-rasterizer/codegen/gen_knobs.h: rasterizer/codegen/gen_knobs.py 
rasterizer/codegen/knob_defs.py rasterizer/codegen/templates/gen_knobs.cpp
+rasterizer/codegen/gen_knobs.h: rasterizer/codegen/gen_knobs.py 
rasterizer/codegen/knob_defs.py rasterizer/codegen/templates/gen_knobs.cpp 
rasterizer/codegen/gen_common.py
$(MKDIR_GEN)
$(PYTHON_GEN) \
$(srcdir)/rasterizer/codegen/gen_knobs.py \
- --input $(srcdir)/rasterizer/codegen/templates/gen_knobs.cpp \
+ --input $(realpath $(srcdir)/rasterizer/codegen/templates/gen_knobs.cpp) \
--output rasterizer/codegen/gen_knobs.h \
--gen_h

-rasterizer/jitter/gen_state_llvm.h: rasterizer/codegen/gen_llvm_types.py 
rasterizer/codegen/templates/gen_llvm.hpp rasterizer/core/state.h
+rasterizer/jitter/gen_state_llvm.h: rasterizer/codegen/gen_llvm_types.py 
rasterizer/codegen/templates/gen_llvm.hpp rasterizer/core/state.h 
rasterizer/codegen/gen_common.py
$(MKDIR_GEN)
$(PYTHON_GEN) \
$(srcdir)/rasterizer/codegen/gen_llvm_types.py \
--input $(srcdir)/rasterizer/core/state.h \
--output rasterizer/jitter/gen_state_llvm.h

-rasterizer/jitter/gen_builder.hpp: rasterizer/codegen/gen_llvm_ir_macros.py 
rasterizer/codegen/templates/gen_builder.hpp
+rasterizer/jitter/gen_builder.hpp: rasterizer/codegen/gen_llvm_ir_macros.py 
rasterizer/codegen/templates/gen_builder.hpp rasterizer/codegen/gen_common.py
$(MKDIR_GEN)
$(PYTHON_GEN) \
$(srcdir)/rasterizer/codegen/gen_llvm_ir_macros.py \
@@ -102,14 +102,14 @@ rasterizer/jitter/gen_builder.hpp: 
rasterizer/codegen/gen_llvm_ir_macros.py rast
--output rasterizer/jitter \
--gen_h

-rasterizer/jitter/gen_builder_x86.hpp: 
rasterizer/codegen/gen_llvm_ir_macros.py 
rasterizer/codegen/templates/gen_builder.hpp
+rasterizer/jitter/gen_builder_x86.hpp: 
rasterizer/codegen/gen_llvm_ir_macros.py 
rasterizer/codegen/templates/gen_builder.hpp rasterizer/codegen/gen_common.py
$(MKDIR_GEN)
$(PYTHON_GEN) \
$(srcdir)/rasterizer/codegen/gen_llvm_ir_macros.py \
--output rasterizer/jitter \
--gen_x86_h

-rasterizer/archrast/gen_ar_event.hpp: rasterizer/codegen/gen_archrast.py 
rasterizer/codegen/templates/gen_ar_event.hpp rasterizer/archrast/events.proto
+rasterizer/archrast/gen_ar_event.hpp: rasterizer/codegen/gen_archrast.py 
rasterizer/codegen/templates/gen_ar_event.hpp rasterizer/archrast/events.proto 
rasterizer/codegen/gen_common.py
$(MKDIR_GEN)
$(PYTHON_GEN) \
$(srcdir)/rasterizer/codegen/gen_archrast.py \
@@ -117,7 +117,7 @@ rasterizer/archrast/gen_ar_event.hpp: 
rasterizer/codegen/gen_archrast.py rasteri
--output rasterizer/archrast/gen_ar_event.hpp \
--gen_event_h

-rasterizer/archrast/gen_ar_event.cpp: rasterizer/codegen/gen_archrast.py 
rasterizer/codegen/templates/gen_ar_event.cpp rasterizer/archrast/events.proto
+rasterizer/archrast/gen_ar_event.cpp: rasterizer/codegen/gen_archrast.py 
rasterizer/codegen/templates/gen_ar_event.cpp rasterizer/archrast/events.proto 
rasterizer/codegen/gen_common.py
$(MKDIR_GEN)
$(PYTHON_GEN) \
$(srcdir)/rasterizer/codegen/gen_archrast.py \
@@ -125,7 +125,7 @@ rasterizer/archrast/gen_ar_event.cpp: 
rasterizer/codegen/gen_archrast.py rasteri
--output 

Re: [Mesa-dev] [PATCH v2 01/10] swr: [rasterizer codegen] Refactor codegen

[Kyriazis, George]

With this v2 change PATCH 10/10 has to be updated.  V2 of 10/10 coming in a 
separate envelope.

With the 10/10 update, this patch:

Reviewed-By: George Kyriazis 
>

George

On Mar 27, 2017, at 11:17 AM, Tim Rowley 
> wrote:

Move common codegen functions into gen_common.py.

v2: change gen_knobs.py to find the template file internally, like
the rest of the gen scripts.
---
src/gallium/drivers/swr/Makefile.am|  20 ++-
.../drivers/swr/rasterizer/codegen/gen_archrast.py |  30 +---
.../drivers/swr/rasterizer/codegen/gen_backends.py |  30 +---
.../drivers/swr/rasterizer/codegen/gen_common.py   | 162 +
.../drivers/swr/rasterizer/codegen/gen_knobs.py|  64 +++-
.../swr/rasterizer/codegen/gen_llvm_ir_macros.py   |  35 +
.../swr/rasterizer/codegen/gen_llvm_types.py   |  32 +---
7 files changed, 215 insertions(+), 158 deletions(-)
create mode 100644 src/gallium/drivers/swr/rasterizer/codegen/gen_common.py

diff --git a/src/gallium/drivers/swr/Makefile.am 
b/src/gallium/drivers/swr/Makefile.am
index 8ba9ac9..515a908 100644
--- a/src/gallium/drivers/swr/Makefile.am
+++ b/src/gallium/drivers/swr/Makefile.am
@@ -71,30 +71,28 @@ gen_swr_context_llvm.h: 
rasterizer/codegen/gen_llvm_types.py rasterizer/codegen/
--input $(srcdir)/swr_context.h \
--output ./gen_swr_context_llvm.h

-rasterizer/codegen/gen_knobs.cpp: rasterizer/codegen/gen_knobs.py 
rasterizer/codegen/knob_defs.py rasterizer/codegen/templates/gen_knobs.cpp
+rasterizer/codegen/gen_knobs.cpp: rasterizer/codegen/gen_knobs.py 
rasterizer/codegen/knob_defs.py rasterizer/codegen/templates/gen_knobs.cpp 
rasterizer/codegen/gen_common.py
$(MKDIR_GEN)
$(PYTHON_GEN) \
$(srcdir)/rasterizer/codegen/gen_knobs.py \
- --input $(srcdir)/rasterizer/codegen/templates/gen_knobs.cpp \
--output rasterizer/codegen/gen_knobs.cpp \
--gen_cpp

-rasterizer/codegen/gen_knobs.h: rasterizer/codegen/gen_knobs.py 
rasterizer/codegen/knob_defs.py rasterizer/codegen/templates/gen_knobs.cpp
+rasterizer/codegen/gen_knobs.h: rasterizer/codegen/gen_knobs.py 
rasterizer/codegen/knob_defs.py rasterizer/codegen/templates/gen_knobs.cpp 
rasterizer/codegen/gen_common.py
$(MKDIR_GEN)
$(PYTHON_GEN) \
$(srcdir)/rasterizer/codegen/gen_knobs.py \
- --input $(srcdir)/rasterizer/codegen/templates/gen_knobs.cpp \
--output rasterizer/codegen/gen_knobs.h \
--gen_h

-rasterizer/jitter/gen_state_llvm.h: rasterizer/codegen/gen_llvm_types.py 
rasterizer/codegen/templates/gen_llvm.hpp rasterizer/core/state.h
+rasterizer/jitter/gen_state_llvm.h: rasterizer/codegen/gen_llvm_types.py 
rasterizer/codegen/templates/gen_llvm.hpp rasterizer/core/state.h 
rasterizer/codegen/gen_common.py
$(MKDIR_GEN)
$(PYTHON_GEN) \
$(srcdir)/rasterizer/codegen/gen_llvm_types.py \
--input $(srcdir)/rasterizer/core/state.h \
--output rasterizer/jitter/gen_state_llvm.h

-rasterizer/jitter/gen_builder.hpp: rasterizer/codegen/gen_llvm_ir_macros.py 
rasterizer/codegen/templates/gen_builder.hpp
+rasterizer/jitter/gen_builder.hpp: rasterizer/codegen/gen_llvm_ir_macros.py 
rasterizer/codegen/templates/gen_builder.hpp rasterizer/codegen/gen_common.py
$(MKDIR_GEN)
$(PYTHON_GEN) \
$(srcdir)/rasterizer/codegen/gen_llvm_ir_macros.py \
@@ -102,14 +100,14 @@ rasterizer/jitter/gen_builder.hpp: 
rasterizer/codegen/gen_llvm_ir_macros.py rast
--output rasterizer/jitter \
--gen_h

-rasterizer/jitter/gen_builder_x86.hpp: 
rasterizer/codegen/gen_llvm_ir_macros.py 
rasterizer/codegen/templates/gen_builder.hpp
+rasterizer/jitter/gen_builder_x86.hpp: 
rasterizer/codegen/gen_llvm_ir_macros.py 
rasterizer/codegen/templates/gen_builder.hpp rasterizer/codegen/gen_common.py
$(MKDIR_GEN)
$(PYTHON_GEN) \
$(srcdir)/rasterizer/codegen/gen_llvm_ir_macros.py \
--output rasterizer/jitter \
--gen_x86_h

-rasterizer/archrast/gen_ar_event.hpp: rasterizer/codegen/gen_archrast.py 
rasterizer/codegen/templates/gen_ar_event.hpp rasterizer/archrast/events.proto
+rasterizer/archrast/gen_ar_event.hpp: rasterizer/codegen/gen_archrast.py 
rasterizer/codegen/templates/gen_ar_event.hpp rasterizer/archrast/events.proto 
rasterizer/codegen/gen_common.py
$(MKDIR_GEN)
$(PYTHON_GEN) \
$(srcdir)/rasterizer/codegen/gen_archrast.py \
@@ -117,7 +115,7 @@ rasterizer/archrast/gen_ar_event.hpp: 
rasterizer/codegen/gen_archrast.py rasteri
--output rasterizer/archrast/gen_ar_event.hpp \
--gen_event_h

-rasterizer/archrast/gen_ar_event.cpp: rasterizer/codegen/gen_archrast.py 
rasterizer/codegen/templates/gen_ar_event.cpp rasterizer/archrast/events.proto
+rasterizer/archrast/gen_ar_event.cpp: rasterizer/codegen/gen_archrast.py 
rasterizer/codegen/templates/gen_ar_event.cpp rasterizer/archrast/events.proto 
rasterizer/codegen/gen_common.py
$(MKDIR_GEN)
$(PYTHON_GEN) \
$(srcdir)/rasterizer/codegen/gen_archrast.py \
@@ -125,7 +123,7 @@ rasterizer/archrast/gen_ar_event.cpp: 
rasterizer/codegen/gen_archrast.py rasteri
--output 

Re: [Mesa-dev] [PATCH v2 1/2] [util] add extern "C" guards

[Kyriazis, George]

> -Original Message-
> From: ibmir...@gmail.com [mailto:ibmir...@gmail.com] On Behalf Of Ilia
> Mirkin
> Sent: Wednesday, February 15, 2017 10:04 PM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH v2 1/2] [util] add extern "C" guards
> 
> On Wed, Feb 15, 2017 at 10:53 PM, George Kyriazis
> <george.kyria...@intel.com> wrote:
> > Added extern "C" __cplusplus guards on headers that did not have them.
> > ---
> >  src/gallium/auxiliary/util/u_transfer.h   | 8 
> >  src/gallium/auxiliary/util/u_upload_mgr.h | 7 +++
> >  2 files changed, 15 insertions(+)
> >
> > diff --git a/src/gallium/auxiliary/util/u_transfer.h
> > b/src/gallium/auxiliary/util/u_transfer.h
> > index ab787ab..1408498 100644
> > --- a/src/gallium/auxiliary/util/u_transfer.h
> > +++ b/src/gallium/auxiliary/util/u_transfer.h
> > @@ -10,6 +10,10 @@
> >  struct pipe_context;
> >  struct winsys_handle;
> >
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> 
> I'm a little weak on the details, but I wonder if this has to encompass the 
> type
> forward decls above. I know that the C extern convention affects function
> name mangling, but it would stand to reason that it could also affect types.
> Not sure. e.g. u_blit.h and u_blitter.h include the forward decls inside the
> extern section.
> 


Yes,

I was wondering about that, too, but I followed what was happening in other 
header files, for example util/u_format.h.

I've seen name mangling affect global vars on MS devenv, but not on gcc, but 
types seem to work OK on both.


> With that figured out one way or the other, this is
> 
> Reviewed-by: Ilia Mirkin <imir...@alum.mit.edu>
> 
> > +
> >  boolean u_default_resource_get_handle(struct pipe_screen *screen,
> >struct pipe_resource *resource,
> >struct winsys_handle *handle);
> > @@ -95,4 +99,8 @@ void u_transfer_flush_region_vtbl( struct
> > pipe_context *pipe,  void u_transfer_unmap_vtbl( struct pipe_context
> *rm_ctx,
> >  struct pipe_transfer *transfer );
> >
> > +#ifdef __cplusplus
> > +} // extern "C" {
> > +#endif
> > +
> >  #endif
> > diff --git a/src/gallium/auxiliary/util/u_upload_mgr.h
> > b/src/gallium/auxiliary/util/u_upload_mgr.h
> > index 633291e..4538291 100644
> > --- a/src/gallium/auxiliary/util/u_upload_mgr.h
> > +++ b/src/gallium/auxiliary/util/u_upload_mgr.h
> > @@ -38,6 +38,9 @@
> >  struct pipe_context;
> >  struct pipe_resource;
> >
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> >
> >  /**
> >   * Create the upload manager.
> > @@ -109,4 +112,8 @@ void u_upload_data(struct u_upload_mgr *upload,
> > unsigned *out_offset,
> > struct pipe_resource **outbuf);
> >
> > +#ifdef __cplusplus
> > +} // extern "C" {
> > +#endif
> > +
> >  #endif
> > --
> > 2.7.4
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] [swr] fix windows build

[Kyriazis, George]

You mean use extern "C" (inside a c++ guard) on u_upload_mgr.h and friends?

Thanks,

George

> -Original Message-
> From: ibmir...@gmail.com [mailto:ibmir...@gmail.com] On Behalf Of Ilia
> Mirkin
> Sent: Wednesday, February 15, 2017 4:25 PM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH] [swr] fix windows build
> 
> I'd rather see the remainder of the headers fixed to be includable from C++
> contexts. extern "C" { #include } is an anti-pattern...
> 
>   -ilia
> 
> On Wed, Feb 15, 2017 at 5:23 PM, George Kyriazis
> <george.kyria...@intel.com> wrote:
> > move util/u_upload_mgr.h inside extern "C"
> > ---
> >  src/gallium/drivers/swr/swr_context.cpp | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/drivers/swr/swr_context.cpp
> > b/src/gallium/drivers/swr/swr_context.cpp
> > index 2e37bac..04ff146 100644
> > --- a/src/gallium/drivers/swr/swr_context.cpp
> > +++ b/src/gallium/drivers/swr/swr_context.cpp
> > @@ -33,9 +33,9 @@
> >  #include "util/u_inlines.h"
> >  #include "util/u_format.h"
> >  #include "util/u_atomic.h"
> > -#include "util/u_upload_mgr.h"
> >
> >  extern "C" {
> > +#include "util/u_upload_mgr.h"
> >  #include "util/u_transfer.h"
> >  #include "util/u_surface.h"
> >  }
> > --
> > 2.7.4
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] [swr] fix index buffers with non-zero indices

[Kyriazis, George]

Thanks,

Good point.  I'll send a new version our for review.

George

> -Original Message-
> From: ibmir...@gmail.com [mailto:ibmir...@gmail.com] On Behalf Of Ilia
> Mirkin
> Sent: Tuesday, January 31, 2017 11:50 AM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH] [swr] fix index buffers with non-zero
> indices
> 
> Here's the current code:
> 
>   for (UINT i = 0; i < ctx->num_vertex_buffers; i++) {
>  uint32_t size, pitch, elems, partial_inbounds;
>  const uint8_t *p_data;
>  struct pipe_vertex_buffer *vb = >vertex_buffer[i];
> 
>  pitch = vb->stride;
>  if (!vb->user_buffer) {
> /* VBO
>  * size is based on buffer->width0 rather than info.max_index
>  * to prevent having to validate VBO on each draw */
> size = vb->buffer->width0;
> elems = size / pitch;
> partial_inbounds = size % pitch;
> 
> p_data = swr_resource_data(vb->buffer) + vb->buffer_offset;
>  } else {
> /* Client buffer
>  * client memory is one-time use, re-trigger SWR_NEW_VERTEX to
>  * revalidate on each draw */
> post_update_dirty_flags |= SWR_NEW_VERTEX;
> 
> uint32_t base;
> swr_user_vbuf_range(, ctx->velems, vb, i, , ,
> );
> partial_inbounds = 0;
> 
> /* Copy only needed vertices to scratch space */
> size = AlignUp(size, 4);
> const void *ptr = (const uint8_t *) vb->user_buffer + base;
> memcpy(scratch, ptr, size);
> ptr = scratch;
> scratch += size;
> p_data = (const uint8_t *)ptr - base;
>  }
> 
>  swrVertexBuffers[i] = {0};
>  swrVertexBuffers[i].index = i;
>  swrVertexBuffers[i].pitch = pitch;
>  swrVertexBuffers[i].pData = p_data;
>  swrVertexBuffers[i].size = size;
>  swrVertexBuffers[i].maxVertex = elems;
>  swrVertexBuffers[i].partialInboundsSize = partial_inbounds;
>   }
> 
> You're modifying only the client buffer case. The VBO case
> (!vb->user_buffer) is not adjusted in any way. Your patch changes the base
> vertex passed in no matter what (and remember - I'm 99% sure it's possible
> to mix VBO and non-VBO in the same draw). So it stands to reason that now
> VBO-based draws with base vertex set will now be done so incorrectly when
> min_index != 0.
> 
> I think the solution to your problem is to include a minVertex in the vertex
> buffer definition, and clamp the range on that in the vertex jit.
> 
> Cheers,
> 
>   -ilia
> 
> On Tue, Jan 31, 2017 at 12:32 PM, Kyriazis, George
> <george.kyria...@intel.com> wrote:
> > Ilia,
> >
> > The problem is the following: This occurs only with index buffers that do
> not contain vertex index 0.  The vertex fetcher operates in blocks of 8
> vertices.  Consequently, the last batch of 8 could access elements outside the
> range of the index buffer.  There is a chance that those elements will be
> outside range / non valid.  The 1st phase of the vertex fetcher replaces
> invalid indices with 0 (in later phases, the actual vertex fetch operation is
> masked).  Vertex index 0 is outside the range of the copied index buffer, and
> we SEGV accessing indices with 0 index.  The BaseVertex offset gets added
> to every index in the index buffer, so the 0 index will now point to the real
> beginning of the (copied) index buffer, instead of unallocated memory.
> >
> > VBOs should be similar to DrawElement calls where we don't access client
> memory directly (ie. we copy the appropriate vertex and index buffers,
> which is the case that this fixes).  What do you think?
> >
> > Thanks,
> >
> > George
> >
> >> -Original Message-
> >> From: ibmir...@gmail.com [mailto:ibmir...@gmail.com] On Behalf Of
> >> Ilia Mirkin
> >> Sent: Tuesday, January 31, 2017 11:17 AM
> >> To: Kyriazis, George <george.kyria...@intel.com>
> >> Cc: mesa-dev@lists.freedesktop.org
> >> Subject: Re: [Mesa-dev] [PATCH] [swr] fix index buffers with non-zero
> >> indices
> >>
> >> What's the problem being fixed exactly? We're passing what is
> >> effectively the zero index to the core, and the core shouldn't ever
> >> access data outside of [min, max] + bias.
> >>
> >> That said, what you have is probably a cleaner implementation.
> >> However I'm a bit concerned about how it will functio

Re: [Mesa-dev] [PATCH] [swr] fix index buffers with non-zero indices

[Kyriazis, George]

Ilia,

The problem is the following: This occurs only with index buffers that do not 
contain vertex index 0.  The vertex fetcher operates in blocks of 8 vertices.  
Consequently, the last batch of 8 could access elements outside the range of 
the index buffer.  There is a chance that those elements will be outside range 
/ non valid.  The 1st phase of the vertex fetcher replaces invalid indices with 
0 (in later phases, the actual vertex fetch operation is masked).  Vertex index 
0 is outside the range of the copied index buffer, and we SEGV accessing 
indices with 0 index.  The BaseVertex offset gets added to every index in the 
index buffer, so the 0 index will now point to the real beginning of the 
(copied) index buffer, instead of unallocated memory.

VBOs should be similar to DrawElement calls where we don't access client memory 
directly (ie. we copy the appropriate vertex and index buffers, which is the 
case that this fixes).  What do you think?

Thanks,

George

> -Original Message-
> From: ibmir...@gmail.com [mailto:ibmir...@gmail.com] On Behalf Of Ilia
> Mirkin
> Sent: Tuesday, January 31, 2017 11:17 AM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH] [swr] fix index buffers with non-zero
> indices
> 
> What's the problem being fixed exactly? We're passing what is effectively
> the zero index to the core, and the core shouldn't ever access data outside of
> [min, max] + bias.
> 
> That said, what you have is probably a cleaner implementation. However I'm
> a bit concerned about how it will function with VBO's rather than client-side
> arrays. I don't think min_index is guaranteed to be zero in that case, e.g. it
> could be set via glDrawRangeElements[BaseVertex].
> 
> So you're effectively mixing a zero-based pointer for VBO and a min-based
> pointer for client-side arrays. I don't think this can work... perhaps you 
> need
> to add a minVertex in addition to the maxVertex?
> 
> Cheers,
> 
>   -ilia
> 
> On Tue, Jan 31, 2017 at 11:38 AM, George Kyriazis
> <george.kyria...@intel.com> wrote:
> > Fix issue with index buffers that do not contain 0 index.  Use core
> > BaseVertex functionality to offset index buffer indices, instead of
> > offsetting vertex buffer to point before the buffer origin.
> > ---
> >  src/gallium/drivers/swr/swr_draw.cpp  | 2 +-
> > src/gallium/drivers/swr/swr_state.cpp | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/gallium/drivers/swr/swr_draw.cpp
> > b/src/gallium/drivers/swr/swr_draw.cpp
> > index c4d5e5c..88000e5 100644
> > --- a/src/gallium/drivers/swr/swr_draw.cpp
> > +++ b/src/gallium/drivers/swr/swr_draw.cpp
> > @@ -200,7 +200,7 @@ swr_draw_vbo(struct pipe_context *pipe, const
> struct pipe_draw_info *info)
> >info->count,
> >info->instance_count,
> >info->start,
> > -  info->index_bias,
> > +  info->index_bias - info->min_index,
> >info->start_instance);
> > else
> >SwrDrawInstanced(ctx->swrContext, diff --git
> > a/src/gallium/drivers/swr/swr_state.cpp
> > b/src/gallium/drivers/swr/swr_state.cpp
> > index f1f4963..f03f814 100644
> > --- a/src/gallium/drivers/swr/swr_state.cpp
> > +++ b/src/gallium/drivers/swr/swr_state.cpp
> > @@ -1133,7 +1133,7 @@ swr_update_derived(struct pipe_context *pipe,
> >  memcpy(scratch, ptr, size);
> >  ptr = scratch;
> >  scratch += size;
> > -p_data = (const uint8_t *)ptr - base;
> > +p_data = (const uint8_t *)ptr;
> >   }
> >
> >   swrVertexBuffers[i] = {0};
> > --
> > 2.7.4
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/9] scons: swr: remove explicit __STDC_.*_MACROS defines

[Kyriazis, George]

Signed-off: George Kyriazis <george.kyria...@intel.com>

> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Thursday, January 26, 2017 7:24 AM
> To: mesa-dev@lists.freedesktop.org
> Cc: emil.l.veli...@gmail.com; Kyriazis, George <george.kyria...@intel.com>
> Subject: [PATCH 7/9] scons: swr: remove explicit __STDC_.*_MACROS
> defines
> 
> From: Emil Velikov <emil.veli...@collabora.com>
> 
> Analogous to previous commits.
> 
> Cc: George Kyriazis <george.kyria...@intel.com>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
> ---
>  src/gallium/drivers/swr/SConscript | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/src/gallium/drivers/swr/SConscript
> b/src/gallium/drivers/swr/SConscript
> index 3f0517b36c..c0677afc97 100644
> --- a/src/gallium/drivers/swr/SConscript
> +++ b/src/gallium/drivers/swr/SConscript
> @@ -41,11 +41,6 @@ loadersource =
> env.ParseSourceList('Makefile.sources', [
>  'LOADER_SOURCES'
>  ])
> 
> -env.Append(CPPDEFINES = [
> -'__STDC_CONSTANT_MACROS',
> -'__STDC_LIMIT_MACROS'
> -])
> -
>  if not env['msvc'] :
>  env.Append(CCFLAGS = [
>  '-std=c++11',
> --
> 2.11.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr: Prune empty nodes in CalculateProcessorTopology.

[Kyriazis, George]

Bruce,

I think you have to add the cc: line in the message body, and not cc 
mesa-stable explicitly, as described in http://www.mesa3d.org/devinfo.html.  I 
could be wrong, though.

Otherwise,

Reviewed-By: George Kyriazis 

Thanks,

George

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Bruce Cherniak
> Sent: Thursday, January 19, 2017 3:45 PM
> To: mesa-dev@lists.freedesktop.org; mesa-sta...@lists.freedesktop.org
> Subject: [Mesa-dev] [PATCH] swr: Prune empty nodes in
> CalculateProcessorTopology.
> 
> CalculateProcessorTopology tries to figure out system topology by parsing
> /proc/cpuinfo to determine the number of threads, cores, and NUMA
> nodes.  There are some architectures where the "physical id" begins with 1
> rather than 0, which was creating and empty "0" node and causing a crash in
> CreateThreadPool.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97102
> ---
>  src/gallium/drivers/swr/rasterizer/core/threads.cpp | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/src/gallium/drivers/swr/rasterizer/core/threads.cpp
> b/src/gallium/drivers/swr/rasterizer/core/threads.cpp
> index ee12612..f1c3030 100644
> --- a/src/gallium/drivers/swr/rasterizer/core/threads.cpp
> +++ b/src/gallium/drivers/swr/rasterizer/core/threads.cpp
> @@ -217,6 +217,15 @@ void CalculateProcessorTopology(CPUNumaNodes&
> out_nodes, uint32_t& out_numThread
>  out_numThreadsPerProcGroup++;
>  }
> 
> +/* Prune empty numa nodes */
> +for (auto it = out_nodes.begin(); it != out_nodes.end(); ) {
> +   if ((*it).cores.size() == 0)
> +  it = out_nodes.erase(it);
> +   else
> +  ++it;
> +}
> +
> +/* Prune empty core nodes */
>  for (uint32_t node = 0; node < out_nodes.size(); node++) {
>  auto& numaNode = out_nodes[node];
>  auto it = numaNode.cores.begin();
> --
> 2.7.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3] swr: fix windows build break

[Kyriazis, George]

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Ilia Mirkin
> Sent: Wednesday, January 4, 2017 2:30 PM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH v3] swr: fix windows build break
> 
> On Wed, Jan 4, 2017 at 3:24 PM, Kyriazis, George
> <george.kyria...@intel.com> wrote:
> >
> >
> >> -Original Message-
> >> From: ibmir...@gmail.com [mailto:ibmir...@gmail.com] On Behalf Of
> >> Ilia Mirkin
> >> Sent: Wednesday, January 4, 2017 2:22 PM
> >> To: Kyriazis, George <george.kyria...@intel.com>
> >> Cc: mesa-dev@lists.freedesktop.org
> >> Subject: Re: [Mesa-dev] [PATCH v3] swr: fix windows build break
> >>
> >> On Wed, Jan 4, 2017 at 3:20 PM, George Kyriazis
> >> <george.kyria...@intel.com>
> >> wrote:
> >> > wrap lp_bld_type.h around extern "C".
> >> > Windows decorates global variables, so when used from .cpp files,
> >> > need to use an undecorated version.
> >> > ---
> >> >  src/gallium/auxiliary/gallivm/lp_bld_type.h | 7 +++
> >> >  src/gallium/drivers/swr/swr_screen.cpp  | 4 
> >> >  2 files changed, 7 insertions(+), 4 deletions(-)
> >> >
> >> > diff --git a/src/gallium/auxiliary/gallivm/lp_bld_type.h
> >> > b/src/gallium/auxiliary/gallivm/lp_bld_type.h
> >> > index 7fb449f..afe8722 100644
> >> > --- a/src/gallium/auxiliary/gallivm/lp_bld_type.h
> >> > +++ b/src/gallium/auxiliary/gallivm/lp_bld_type.h
> >> > @@ -41,6 +41,10 @@
> >> >  #include "pipe/p_compiler.h"
> >> >  #include "gallivm/lp_bld.h"
> >> >
> >> > +#ifdef __cplusplus
> >> > +extern "C" {
> >> > +#endif
> >> > +
> >> >  /**
> >> >   * Native SIMD architecture width available at runtime.
> >> >   *
> >> > @@ -449,5 +453,8 @@ lp_build_context_init(struct lp_build_context
> >> > *bld,  unsigned  lp_build_count_ir_module(LLVMModuleRef module);
> >> >
> >> > +#ifdef __cplusplus
> >> > +}
> >> > +#endif
> >> >
> >> >  #endif /* !LP_BLD_TYPE_H */
> >>
> >> Changes to this file are
> >>
> >> Reviewed-by: Ilia Mirkin <imir...@alum.mit.edu>
> >>
> >> > diff --git a/src/gallium/drivers/swr/swr_screen.cpp
> >> > b/src/gallium/drivers/swr/swr_screen.cpp
> >> > index a9905d7..3b010fe 100644
> >> > --- a/src/gallium/drivers/swr/swr_screen.cpp
> >> > +++ b/src/gallium/drivers/swr/swr_screen.cpp
> >> > @@ -39,10 +39,6 @@
> >> >
> >> >  #include "state_tracker/sw_winsys.h"
> >> >
> >> > -extern "C" {
> >> > -#include "gallivm/lp_bld_limits.h"
> >> > -}
> >> > -
> >>
> >> I'm still confused by this hunk. It doesn't seem to be related to the
> >> change description. It also doesn't define any function prototypes,
> >> so it doesn't really need the extern "C" thing either.
> >>
> > This was part of the old code, hence the removal.  Yes, it doesn't quite fit
> with the rest; I can split to a different check-in.
> 
> Fine to keep it together (as far as I'm concerned). It just didn't mesh with 
> the
> change description. If you update the change description to make a mention
> of this unnecessary include being removed, the whole change gets my
> 
> Reviewed-by: Ilia Mirkin <imir...@alum.mit.edu>
> 
Thanks!

Changed change description.  Tim Rowley will check in the code.

George

> Cheers,
> 
>   -ilia
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3] swr: fix windows build break

[Kyriazis, George]

> -Original Message-
> From: ibmir...@gmail.com [mailto:ibmir...@gmail.com] On Behalf Of Ilia
> Mirkin
> Sent: Wednesday, January 4, 2017 2:22 PM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH v3] swr: fix windows build break
> 
> On Wed, Jan 4, 2017 at 3:20 PM, George Kyriazis <george.kyria...@intel.com>
> wrote:
> > wrap lp_bld_type.h around extern "C".
> > Windows decorates global variables, so when used from .cpp files, need
> > to use an undecorated version.
> > ---
> >  src/gallium/auxiliary/gallivm/lp_bld_type.h | 7 +++
> >  src/gallium/drivers/swr/swr_screen.cpp  | 4 
> >  2 files changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/gallium/auxiliary/gallivm/lp_bld_type.h
> > b/src/gallium/auxiliary/gallivm/lp_bld_type.h
> > index 7fb449f..afe8722 100644
> > --- a/src/gallium/auxiliary/gallivm/lp_bld_type.h
> > +++ b/src/gallium/auxiliary/gallivm/lp_bld_type.h
> > @@ -41,6 +41,10 @@
> >  #include "pipe/p_compiler.h"
> >  #include "gallivm/lp_bld.h"
> >
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> >  /**
> >   * Native SIMD architecture width available at runtime.
> >   *
> > @@ -449,5 +453,8 @@ lp_build_context_init(struct lp_build_context
> > *bld,  unsigned  lp_build_count_ir_module(LLVMModuleRef module);
> >
> > +#ifdef __cplusplus
> > +}
> > +#endif
> >
> >  #endif /* !LP_BLD_TYPE_H */
> 
> Changes to this file are
> 
> Reviewed-by: Ilia Mirkin <imir...@alum.mit.edu>
> 
> > diff --git a/src/gallium/drivers/swr/swr_screen.cpp
> > b/src/gallium/drivers/swr/swr_screen.cpp
> > index a9905d7..3b010fe 100644
> > --- a/src/gallium/drivers/swr/swr_screen.cpp
> > +++ b/src/gallium/drivers/swr/swr_screen.cpp
> > @@ -39,10 +39,6 @@
> >
> >  #include "state_tracker/sw_winsys.h"
> >
> > -extern "C" {
> > -#include "gallivm/lp_bld_limits.h"
> > -}
> > -
> 
> I'm still confused by this hunk. It doesn't seem to be related to the change
> description. It also doesn't define any function prototypes, so it doesn't 
> really
> need the extern "C" thing either.
> 
This was part of the old code, hence the removal.  Yes, it doesn't quite fit 
with the rest; I can split to a different check-in.

> >  #include "jit_api.h"
> >
> >  #include "memory/TilingFunctions.h"
> > --
> > 2.10.0.windows.1
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr: remove unneeded llvm version check

[Kyriazis, George]

Reviewed-by: George Kyriazis 

George

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Tim Rowley
> Sent: Tuesday, January 3, 2017 10:25 AM
> To: Cherniak, Bruce ; mesa-
> d...@lists.freedesktop.org
> Subject: [Mesa-dev] [PATCH] swr: remove unneeded llvm version check
> 
> Old test caused breakage with llvm-svn (4.0.0svn), and not needed as the
> minimum required llvm version for swr is 3.6.
> ---
>  src/gallium/drivers/swr/swr_shader.cpp | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/src/gallium/drivers/swr/swr_shader.cpp
> b/src/gallium/drivers/swr/swr_shader.cpp
> index 294a568..979a28b 100644
> --- a/src/gallium/drivers/swr/swr_shader.cpp
> +++ b/src/gallium/drivers/swr/swr_shader.cpp
> @@ -344,9 +344,7 @@ BuilderSWR::CompileVS(struct swr_context *ctx,
> swr_jit_vs_key )
> debug_printf("vert shader  %p\n", pFunc);
> assert(pFunc && "Error: VertShader = NULL");
> 
> -#if (LLVM_VERSION_MAJOR == 3) && (LLVM_VERSION_MINOR >= 5)
> JM()->mIsModuleFinalized = true;
> -#endif
> 
> return pFunc;
>  }
> @@ -706,9 +704,7 @@ BuilderSWR::CompileFS(struct swr_context *ctx,
> swr_jit_fs_key )
> debug_printf("frag shader  %p\n", kernel);
> assert(kernel && "Error: FragShader = NULL");
> 
> -#if (LLVM_VERSION_MAJOR == 3) && (LLVM_VERSION_MINOR >= 5)
> JM()->mIsModuleFinalized = true;
> -#endif
> 
> return kernel;
>  }
> --
> 2.9.3
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr: Implement fence attached work queues for deferred deletion.

[Kyriazis, George]

Reviewed-by: George Kyriazis 

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Bruce Cherniak
> Sent: Monday, December 12, 2016 7:25 PM
> To: mesa-dev@lists.freedesktop.org
> Subject: [Mesa-dev] [PATCH] swr: Implement fence attached work queues
> for deferred deletion.
> 
> Work can now be added to fences and triggered by fence completion. This
> allows for deferred resource deletion, and other asynchronous tasks.
> ---
>  src/gallium/drivers/swr/Makefile.sources   |   2 +
>  src/gallium/drivers/swr/swr_context.cpp|   7 +-
>  src/gallium/drivers/swr/swr_fence.cpp  |  14 ++-
>  src/gallium/drivers/swr/swr_fence.h|   8 ++
>  src/gallium/drivers/swr/swr_fence_work.cpp | 148
> +
>  src/gallium/drivers/swr/swr_fence_work.h   |  47 +
>  src/gallium/drivers/swr/swr_scratch.cpp|  32 +++
>  src/gallium/drivers/swr/swr_screen.cpp |  35 ---
>  src/gallium/drivers/swr/swr_state.cpp  |  16 ++--
>  9 files changed, 255 insertions(+), 54 deletions(-)
>  create mode 100644 src/gallium/drivers/swr/swr_fence_work.cpp
>  create mode 100644 src/gallium/drivers/swr/swr_fence_work.h
> 
> diff --git a/src/gallium/drivers/swr/Makefile.sources
> b/src/gallium/drivers/swr/Makefile.sources
> index d81d458..1afb532 100644
> --- a/src/gallium/drivers/swr/Makefile.sources
> +++ b/src/gallium/drivers/swr/Makefile.sources
> @@ -42,6 +42,8 @@ CXX_SOURCES := \
>   swr_memory.h \
>   swr_fence.h \
>   swr_fence.cpp \
> + swr_fence_work.h \
> + swr_fence_work.cpp \
>   swr_query.h \
>   swr_query.cpp
> 
> diff --git a/src/gallium/drivers/swr/swr_context.cpp
> b/src/gallium/drivers/swr/swr_context.cpp
> index b8c87fa..8933085 100644
> --- a/src/gallium/drivers/swr/swr_context.cpp
> +++ b/src/gallium/drivers/swr/swr_context.cpp
> @@ -355,9 +355,6 @@ swr_destroy(struct pipe_context *pipe)
> if (ctx->blitter)
>util_blitter_destroy(ctx->blitter);
> 
> -   /* Idle core before deleting context */
> -   SwrWaitForIdle(ctx->swrContext);
> -
> for (unsigned i = 0; i < PIPE_MAX_COLOR_BUFS; i++) {
>pipe_surface_reference(>framebuffer.cbufs[i], NULL);
> }
> @@ -372,6 +369,10 @@ swr_destroy(struct pipe_context *pipe)
>pipe_sampler_view_reference(
> >sampler_views[PIPE_SHADER_VERTEX][i], NULL);
> }
> 
> +   /* Idle core after destroying buffer resources, but before deleting
> +* context.  Destroying resources has potentially called StoreTiles.*/
> +   SwrWaitForIdle(ctx->swrContext);
> +
> if (ctx->swrContext)
>SwrDestroyContext(ctx->swrContext);
> 
> diff --git a/src/gallium/drivers/swr/swr_fence.cpp
> b/src/gallium/drivers/swr/swr_fence.cpp
> index 7fe2470..c73bbbf 100644
> --- a/src/gallium/drivers/swr/swr_fence.cpp
> +++ b/src/gallium/drivers/swr/swr_fence.cpp
> @@ -38,10 +38,13 @@
>   * to SwrSync call.
>   */
>  static void
> -swr_sync_cb(uint64_t userData, uint64_t userData2, uint64_t userData3)
> +swr_fence_cb(uint64_t userData, uint64_t userData2, uint64_t userData3)
>  {
> struct swr_fence *fence = (struct swr_fence *)userData;
> 
> +   /* Complete all work attached to the fence */
> +   swr_fence_do_work(fence);
> +
> /* Correct value is in SwrSync data, and not the fence write field. */
> fence->read = userData2;
>  }
> @@ -56,7 +59,7 @@ swr_fence_submit(struct swr_context *ctx, struct
> pipe_fence_handle *fh)
> 
> fence->write++;
> fence->pending = TRUE;
> -   SwrSync(ctx->swrContext, swr_sync_cb, (uint64_t)fence, fence->write,
> 0);
> +   SwrSync(ctx->swrContext, swr_fence_cb, (uint64_t)fence, fence->write,
> 0);
>  }
> 
>  /*
> @@ -72,6 +75,7 @@ swr_fence_create()
> 
> pipe_reference_init(>reference, 1);
> fence->id = fence_id++;
> +   fence->work.tail = >work.head;
> 
> return (struct pipe_fence_handle *)fence;
>  }
> @@ -80,6 +84,8 @@ swr_fence_create()
>  static void
>  swr_fence_destroy(struct swr_fence *fence)
>  {
> +   /* Complete any work left if fence was not submitted */
> +   swr_fence_do_work(fence);
> FREE(fence);
>  }
> 
> @@ -101,8 +107,10 @@ swr_fence_reference(struct pipe_screen *screen,
>old = NULL;
> }
> 
> -   if (pipe_reference(>reference, >reference))
> +   if (pipe_reference(>reference, >reference)) {
> +  swr_fence_finish(screen, NULL, (struct pipe_fence_handle *) old, 0);
>swr_fence_destroy(old);
> +   }
>  }
> 
> 
> diff --git a/src/gallium/drivers/swr/swr_fence.h
> b/src/gallium/drivers/swr/swr_fence.h
> index 80a4345..4766b5b 100644
> --- a/src/gallium/drivers/swr/swr_fence.h
> +++ b/src/gallium/drivers/swr/swr_fence.h
> @@ -25,6 +25,8 @@
>  #include "pipe/p_state.h"
>  #include "util/u_inlines.h"
> 
> +#include "swr_fence_work.h"
> +
>  struct pipe_screen;
> 
>  struct swr_fence {
> @@ -36,6 +38,12 @@ struct swr_fence {
> unsigned pending;
> 
> unsigned id; /* Just for reference */
> +
> +   struct {
> +  

Re: [Mesa-dev] [PATCH] swr: Templetize std::max to work on windows

[Kyriazis, George]

> -Original Message-
> From: ibmir...@gmail.com [mailto:ibmir...@gmail.com] On Behalf Of Ilia
> Mirkin
> Sent: Tuesday, November 29, 2016 1:54 PM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH] swr: Templetize std::max to work on
> windows
> 
> How about just making 'layers' unsigned? (Hm, I wonder why this didn't
> trigger issues with gcc... maybe it should be +1u instead of +1?)
> 
Could do that, too, but there are other places in our code that use templetized 
versions of std::max.

I guess gcc prioritizes implicit casts...  +1u does not help, since the 
last_layer/first_layer fields are already unsigned.  It's the int vs unsigned 
type mismatch that caused the issue.

George


> On Tue, Nov 29, 2016 at 2:46 PM, George Kyriazis
> <george.kyria...@intel.com> wrote:
> > ---
> >  src/gallium/drivers/swr/swr_clear.cpp | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/gallium/drivers/swr/swr_clear.cpp
> > b/src/gallium/drivers/swr/swr_clear.cpp
> > index f59179f..e752ee0 100644
> > --- a/src/gallium/drivers/swr/swr_clear.cpp
> > +++ b/src/gallium/drivers/swr/swr_clear.cpp
> > @@ -46,20 +46,20 @@ swr_clear(struct pipe_context *pipe,
> >for (unsigned i = 0; i < fb->nr_cbufs; ++i)
> >   if (fb->cbufs[i] && (buffers & (PIPE_CLEAR_COLOR0 << i))) {
> >  clearMask |= (SWR_ATTACHMENT_COLOR0_BIT << i);
> > -layers = std::max(layers, fb->cbufs[i]->u.tex.last_layer -
> > +layers = std::max(layers,
> > + fb->cbufs[i]->u.tex.last_layer -
> >fb->cbufs[i]->u.tex.first_layer + 1);
> >   }
> > }
> >
> > if (buffers & PIPE_CLEAR_DEPTH && fb->zsbuf) {
> >clearMask |= SWR_ATTACHMENT_DEPTH_BIT;
> > -  layers = std::max(layers, fb->zsbuf->u.tex.last_layer -
> > +  layers = std::max(layers, fb->zsbuf->u.tex.last_layer -
> >  fb->zsbuf->u.tex.first_layer + 1);
> > }
> >
> > if (buffers & PIPE_CLEAR_STENCIL && fb->zsbuf) {
> >clearMask |= SWR_ATTACHMENT_STENCIL_BIT;
> > -  layers = std::max(layers, fb->zsbuf->u.tex.last_layer -
> > +  layers = std::max(layers, fb->zsbuf->u.tex.last_layer -
> >  fb->zsbuf->u.tex.first_layer + 1);
> > }
> >
> > --
> > 2.7.4
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gdi: Add GALLIUM_TRACE and GALLIUM_RBUG to gdi

[Kyriazis, George]

I'll retract this diff for now, then.

George

> -Original Message-
> From: Jose Fonseca [mailto:jfons...@vmware.com]
> Sent: Thursday, November 24, 2016 1:42 PM
> To: Emil Velikov <emil.l.veli...@gmail.com>; Kyriazis, George
> <george.kyria...@intel.com>
> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH] gdi: Add GALLIUM_TRACE and
> GALLIUM_RBUG to gdi
> 
> On 23/11/16 17:37, Emil Velikov wrote:
> > On 23 November 2016 at 16:14, George Kyriazis
> <george.kyria...@intel.com> wrote:
> >> ---
> >>  src/gallium/targets/libgl-gdi/SConscript  | 1 +
> >> src/gallium/targets/libgl-gdi/libgl_gdi.c | 4 
> >>  2 files changed, 5 insertions(+)
> >>
> >> diff --git a/src/gallium/targets/libgl-gdi/SConscript
> >> b/src/gallium/targets/libgl-gdi/SConscript
> >> index d3251ca..adb3581 100644
> >> --- a/src/gallium/targets/libgl-gdi/SConscript
> >> +++ b/src/gallium/targets/libgl-gdi/SConscript
> >> @@ -41,6 +41,7 @@ if env['gcc'] and env['machine'] != 'x86_64':
> >>  else:
> >>  sources += ['#src/gallium/state_trackers/wgl/opengl32.def']
> >>
> >> +env.Append(CPPDEFINES = ['GALLIUM_TRACE', 'GALLIUM_RBUG'])
> >>  drivers += [trace, rbug]
> >>
> >>  env['no_import_lib'] = 1
> >> diff --git a/src/gallium/targets/libgl-gdi/libgl_gdi.c
> >> b/src/gallium/targets/libgl-gdi/libgl_gdi.c
> >> index 12576db..4b0819f 100644
> >> --- a/src/gallium/targets/libgl-gdi/libgl_gdi.c
> >> +++ b/src/gallium/targets/libgl-gdi/libgl_gdi.c
> >> @@ -55,6 +55,8 @@
> >>  #include "swr/swr_public.h"
> >>  #endif
> >>
> >> +#include "target-helpers/inline_debug_helper.h"
> >> +
> >>  static boolean use_llvmpipe = FALSE;  static boolean use_swr =
> >> FALSE;
> >>
> >> @@ -100,6 +102,8 @@ gdi_screen_create(void)
> >>screen = softpipe_create_screen( winsys );
> >> }
> >>
> >> +   screen = debug_screen_wrap(screen);
> >> +
> > Heh, nice one. Considering the nice comment in gdi_sw_display() did
> > you test this on llvmpipe/softpipe ?
> >
> > At the same time, we can simplify a lot of stuff here:
> >  - replace the explicit driver specific winsys retrieval +
> > gdi_sw_display() calls with pipe_screen::flush_frontbuffer() as
> > mentioned in the gdi_sw_display() comment.
> > The pipe_screen callback does effectively the same thing for
> softpipe/llvmpipe.
> >  - drop the use_* variables and use inline_sw_helper.h
> > sw_screen_create() instead of open-coding it.
> >
> > Jose, does this sounds about right ? Did you guys intentionally
> > (considering the comment?) _not_ use the trace/rbug drivers, despite
> > that one links against them ?
> 
> Right.  We'd need some way to traverse the layers (doable but brittle).
> Or move all needed functionality to gallium interfaces, and kill the off-the-
> side communication channel (doable and realible, but complex.)
> 
> Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gdi: Add GALLIUM_TRACE and GALLIUM_RBUG to gdi

[Kyriazis, George]

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Emil Velikov
> Sent: Wednesday, November 23, 2016 11:37 AM
> To: Kyriazis, George <george.kyria...@intel.com>; Jose Fonseca
> <jfons...@vmware.com>
> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH] gdi: Add GALLIUM_TRACE and
> GALLIUM_RBUG to gdi
> 
> On 23 November 2016 at 16:14, George Kyriazis <george.kyria...@intel.com>
> wrote:
> > ---
> >  src/gallium/targets/libgl-gdi/SConscript  | 1 +
> > src/gallium/targets/libgl-gdi/libgl_gdi.c | 4 
> >  2 files changed, 5 insertions(+)
> >
> > diff --git a/src/gallium/targets/libgl-gdi/SConscript
> > b/src/gallium/targets/libgl-gdi/SConscript
> > index d3251ca..adb3581 100644
> > --- a/src/gallium/targets/libgl-gdi/SConscript
> > +++ b/src/gallium/targets/libgl-gdi/SConscript
> > @@ -41,6 +41,7 @@ if env['gcc'] and env['machine'] != 'x86_64':
> >  else:
> >  sources += ['#src/gallium/state_trackers/wgl/opengl32.def']
> >
> > +env.Append(CPPDEFINES = ['GALLIUM_TRACE', 'GALLIUM_RBUG'])
> >  drivers += [trace, rbug]
> >
> >  env['no_import_lib'] = 1
> > diff --git a/src/gallium/targets/libgl-gdi/libgl_gdi.c
> > b/src/gallium/targets/libgl-gdi/libgl_gdi.c
> > index 12576db..4b0819f 100644
> > --- a/src/gallium/targets/libgl-gdi/libgl_gdi.c
> > +++ b/src/gallium/targets/libgl-gdi/libgl_gdi.c
> > @@ -55,6 +55,8 @@
> >  #include "swr/swr_public.h"
> >  #endif
> >
> > +#include "target-helpers/inline_debug_helper.h"
> > +
> >  static boolean use_llvmpipe = FALSE;
> >  static boolean use_swr = FALSE;
> >
> > @@ -100,6 +102,8 @@ gdi_screen_create(void)
> >screen = softpipe_create_screen( winsys );
> > }
> >
> > +   screen = debug_screen_wrap(screen);
> > +
> Heh, nice one. Considering the nice comment in gdi_sw_display() did you
> test this on llvmpipe/softpipe ?
> 
> At the same time, we can simplify a lot of stuff here:
>  - replace the explicit driver specific winsys retrieval +
> gdi_sw_display() calls with pipe_screen::flush_frontbuffer() as mentioned in
> the gdi_sw_display() comment.

Yes, this needs to be done, otherwise it won't work with llvmpipe.  For swr, we 
ended up calling flush_frontbuffer(), but for a different reason.  I'll need to 
modify this for llvmpipe, too.

> The pipe_screen callback does effectively the same thing for
> softpipe/llvmpipe.
>  - drop the use_* variables and use inline_sw_helper.h
> sw_screen_create() instead of open-coding it.
> 
> Jose, does this sounds about right ? Did you guys intentionally (considering
> the comment?) _not_ use the trace/rbug drivers, despite that one links
> against them ?
> 
> -Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 09/10] gallium: swr: Added swr build for windows

[Kyriazis, George]

Thanks,

I'll update the docs explaining the *-By: a bit better and send it out for 
review.

George

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Ilia Mirkin
> Sent: Wednesday, November 23, 2016 10:59 AM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>; Emil Velikov
> <emil.l.veli...@gmail.com>
> Subject: Re: [Mesa-dev] [PATCH v4 09/10] gallium: swr: Added swr build for
> windows
> 
> On Wed, Nov 23, 2016 at 11:10 AM, Kyriazis, George
> <george.kyria...@intel.com> wrote:
> >
> >> -Original Message-
> >> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> >> Behalf Of Emil Velikov
> >> Sent: Wednesday, November 23, 2016 10:02 AM
> >> To: Ilia Mirkin <imir...@alum.mit.edu>
> >> Cc: Kyriazis, George <george.kyria...@intel.com>; ML mesa-dev  >> d...@lists.freedesktop.org>
> >> Subject: Re: [Mesa-dev] [PATCH v4 09/10] gallium: swr: Added swr
> >> build for windows
> >>
> >> On 23 November 2016 at 15:39, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> >> > On Wed, Nov 23, 2016 at 10:20 AM, Kyriazis, George
> >> > <george.kyria...@intel.com> wrote:
> >> >> Thanks Emil,
> >> >>
> >> >> One thing that I am clear about is: what is the difference between
> >> Reviewed-by:, Acked-by:, etc.  It sounds like they do the same thing,
> >> however in the documentation they are worded as if they mean
> >> different things.
> >> >
> >> > Reviewed-by = I am familiar with this code, and I have carefully
> >> > looked over your change and am fairly sure that it will work
> >> > properly Acked-by = I glanced at the change and it seems reasonable
> >> > OR I looked carefully at the change, but am not overly familiar
> >> > with the surrounding code
> >> >
> >> Exactly this. Thanks Ilia!
> >>
> > Thanks!  In the docs there is also a reference to "Signed-off-by".  Thoughts
> on that one?
> 
> That one's a little trickier - in the Linux Kernel, it has real significance -
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Document
> ation/SubmittingPatches#n420
> 
> However as we have no comparable document in the mesa tree, it loses
> some of its luster. I think a lot of mesa hackers are also kernel hackers, and
> the practice has sort of flowed over. There's no hard rule about it though.
> 
> Cheers,
> 
>   -ilia
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 09/10] gallium: swr: Added swr build for windows

[Kyriazis, George]

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Emil Velikov
> Sent: Wednesday, November 23, 2016 10:02 AM
> To: Ilia Mirkin <imir...@alum.mit.edu>
> Cc: Kyriazis, George <george.kyria...@intel.com>; ML mesa-dev  d...@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH v4 09/10] gallium: swr: Added swr build for
> windows
> 
> On 23 November 2016 at 15:39, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> > On Wed, Nov 23, 2016 at 10:20 AM, Kyriazis, George
> > <george.kyria...@intel.com> wrote:
> >> Thanks Emil,
> >>
> >> One thing that I am clear about is: what is the difference between
> Reviewed-by:, Acked-by:, etc.  It sounds like they do the same thing,
> however in the documentation they are worded as if they mean different
> things.
> >
> > Reviewed-by = I am familiar with this code, and I have carefully
> > looked over your change and am fairly sure that it will work properly
> > Acked-by = I glanced at the change and it seems reasonable OR I looked
> > carefully at the change, but am not overly familiar with the
> > surrounding code
> >
> Exactly this. Thanks Ilia!
> 
Thanks!  In the docs there is also a reference to "Signed-off-by".  Thoughts on 
that one?

George

> -Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 09/10] gallium: swr: Added swr build for windows

[Kyriazis, George]

Thanks Emil,

One thing that I am clear about is: what is the difference between 
Reviewed-by:, Acked-by:, etc.  It sounds like they do the same thing, however 
in the documentation they are worded as if they mean different things.

I will also suggest some edits and send out a diff for review.

George


> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Monday, November 21, 2016 10:27 AM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH v4 09/10] gallium: swr: Added swr build for
> windows
> 
> On 18 November 2016 at 19:49, Kyriazis, George <george.kyria...@intel.com>
> wrote:
> >
> >
> >> -Original Message-
> >> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> >> Behalf Of Emil Velikov
> >> Sent: Friday, November 18, 2016 5:24 AM
> >> To: Kyriazis, George <george.kyria...@intel.com>
> >> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> >> Subject: Re: [Mesa-dev] [PATCH v4 09/10] gallium: swr: Added swr
> >> build for windows
> >>
> >> On 18 November 2016 at 04:27, George Kyriazis
> >> <george.kyria...@intel.com>
> >> wrote:
> >> > Also, modify gen_knobs.py so that each invocation creates a single
> >> > generated file.  This is more similar to how the other generators behave.
> >> > ---
> >> >  src/gallium/SConscript |   1 +
> >> >  src/gallium/drivers/swr/Makefile.am|  15 +-
> >> >  src/gallium/drivers/swr/SConscript | 216
> >> +
> >> >  .../drivers/swr/rasterizer/scripts/gen_knobs.py|  51 ++---
> >> >  4 files changed, 257 insertions(+), 26 deletions(-)  create mode
> >> > 100644 src/gallium/drivers/swr/SConscript
> >> >
> >> This is getting tiresome :'-(
> >>
> >> I've mentioned on multiple occasions to keep separate logical changes
> >> into individual patches.
> >> In my previous sounds I've _explicitly_ left only the ones
> >> (SConscript
> >> fixes) that should be squashed here.
> >> Please read review comments more carefully ?
> >>
> > I hope we can go past the confusion.  Hopefully last set of patches will be
> posted in a bit.
> >
> >> When sending version X of patch series, adding r-b/ack-b/t-b/other
> >> tags (where applicable) and brief version history is highly recommended.
> >> If in doubt on the latter - skim through git log + grep v2.
> >>
> > Appreciate the pointer; I am new to mesa check-in practices, and I didn't
> know.  I think it's a good idea to add this info in the Mesa Development notes
> webpage, to make it more obvious (http://www.mesa3d.org/devinfo.html).
> >
> Having a look and most/all the things mentioned seems to be already there.
> From splitting, breakage, to the r-b,t-b, ack-b tags.
> 
> I've just split devinfo.html in a goal to make things clearer/stand out.
> Information about patch submission is in docs/submittingpatches.html.
> If there's anything unclear (or a hyperlink should be nice) do send a patch.
> Pretty please ?
> 
> Thanks
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v5 09/11] swr: Modify gen_knobs.{cpp|h} creation script

[Kyriazis, George]

Thank you for the reviews, Emil.

Tim will check-in the series, since he has check-in privileges.

George

> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Saturday, November 19, 2016 4:23 PM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH v5 09/11] swr: Modify gen_knobs.{cpp|h}
> creation script
> 
> Hi George,
> 
> Thanks for sorting things.. There's a pretty trivial nitpick below, but please
> don't bother addressing it.
> Things are pretty good as-is - check with Tim/others and land the series.
> 
> On 18 November 2016 at 20:38, George Kyriazis <george.kyria...@intel.com>
> wrote:
> > Modify gen_knobs.py so that each invocation creates a single generated
> > file.  This is more similar to how the other generators behave.
> >
> > v5: remove Scoscript edits from this commit; moved to commit that
> > first adds SConscript
> >
> > Acked-by: Emil Velikov <emil.veli...@collabora.com>
> > ---
> >  src/gallium/drivers/swr/Makefile.am| 15 ++-
> >  .../drivers/swr/rasterizer/scripts/gen_knobs.py| 51 --
> 
> 
> > @@ -235,6 +245,7 @@ libswrAVX2_la_LDFLAGS = \  include
> > $(top_srcdir)/install-gallium-links.mk
> >
> >  EXTRA_DIST = \
> > +   SConscript \
> 
> IIRC I've mentioned it a couple of times - this should be part of the commit
> that introduces the file.
> 
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 09/10] gallium: swr: Added swr build for windows

[Kyriazis, George]

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Emil Velikov
> Sent: Friday, November 18, 2016 5:24 AM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH v4 09/10] gallium: swr: Added swr build for
> windows
> 
> On 18 November 2016 at 04:27, George Kyriazis <george.kyria...@intel.com>
> wrote:
> > Also, modify gen_knobs.py so that each invocation creates a single
> > generated file.  This is more similar to how the other generators behave.
> > ---
> >  src/gallium/SConscript |   1 +
> >  src/gallium/drivers/swr/Makefile.am|  15 +-
> >  src/gallium/drivers/swr/SConscript | 216
> +
> >  .../drivers/swr/rasterizer/scripts/gen_knobs.py|  51 ++---
> >  4 files changed, 257 insertions(+), 26 deletions(-)  create mode
> > 100644 src/gallium/drivers/swr/SConscript
> >
> This is getting tiresome :'-(
> 
> I've mentioned on multiple occasions to keep separate logical changes into
> individual patches.
> In my previous sounds I've _explicitly_ left only the ones (SConscript
> fixes) that should be squashed here.
> Please read review comments more carefully ?
> 
I hope we can go past the confusion.  Hopefully last set of patches will be 
posted in a bit.

> When sending version X of patch series, adding r-b/ack-b/t-b/other tags
> (where applicable) and brief version history is highly recommended.
> If in doubt on the latter - skim through git log + grep v2.
> 
Appreciate the pointer; I am new to mesa check-in practices, and I didn't know. 
 I think it's a good idea to add this info in the Mesa Development notes 
webpage, to make it more obvious (http://www.mesa3d.org/devinfo.html).

Thanks,

George

> Thanks
> Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 06/10] swr: Windows-related changes

[Kyriazis, George]

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Emil Velikov
> Sent: Thursday, November 17, 2016 11:12 AM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH v3 06/10] swr: Windows-related changes
> 
> Hi George,
> 
> Seems I was unclear as a few suggestions got missed.
> 
> On 16 November 2016 at 02:26, George Kyriazis <george.kyria...@intel.com>
> wrote:
> > - Handle dynamic library loading for windows
> > - Implement swap for gdi
> > - fix prototypes
> > - update include paths on configure-based build for swr_loader.cpp
> > ---
> >  src/gallium/drivers/swr/Makefile.am|  7 +++
> >  src/gallium/drivers/swr/swr_loader.cpp | 28
> +---
> >  src/gallium/drivers/swr/swr_public.h   | 11 +++
> >  3 files changed, 39 insertions(+), 7 deletions(-)
> >
> > diff --git a/src/gallium/drivers/swr/Makefile.am
> > b/src/gallium/drivers/swr/Makefile.am
> > index dd1c2e6..305154f 100644
> > --- a/src/gallium/drivers/swr/Makefile.am
> > +++ b/src/gallium/drivers/swr/Makefile.am
> > @@ -217,6 +217,12 @@ libswrAVX2_la_CXXFLAGS = \
> libswrAVX2_la_SOURCES
> > = \
> > $(COMMON_SOURCES)
> >
> > +# XXX: $(SWR_AVX_CXXFLAGS) should not be included, but we end up
> > +including # simdintrin.h, which throws a warning if AVX is not
> > +enabled libmesaswr_la_CXXFLAGS = \
> > +   $(COMMON_CXXFLAGS) \
> > +   $(SWR_AVX_CXXFLAGS)
> > +
> Drop this.
> 
This is needed for linux configure-based build.

> >  # XXX: Don't ship these generated sources for now, since they are
> > specific  # to the LLVM version they are generated from. Thus a
> > release tarball  # containing the said files, generated against eg.
> > LLVM 3.8 will fail to build @@ -235,6 +241,7 @@ libswrAVX2_la_LDFLAGS
> > = \  include $(top_srcdir)/install-gallium-links.mk
> >
> >  EXTRA_DIST = \
> > +   SConscript \
> This should be part of the patch which brings the file - namely 08/10.
> 
Ok, will do.

> > rasterizer/archrast/events.proto \
> > rasterizer/jitter/scripts/gen_llvm_ir_macros.py \
> > rasterizer/jitter/scripts/gen_llvm_types.py \ diff --git
> > a/src/gallium/drivers/swr/swr_loader.cpp
> > b/src/gallium/drivers/swr/swr_loader.cpp
> > index 2113c37..4f3329e 100644
> > --- a/src/gallium/drivers/swr/swr_loader.cpp
> > +++ b/src/gallium/drivers/swr/swr_loader.cpp
> 
> > +#include "swr_screen.h"
> > +#include "swr_resource.h"
> > +
> You only need p_screen.h here. Adding the swr ones is wrong (afaict).
> 
Ok, replaced.

> 
> > -struct pipe_screen *swr_create_screen(struct sw_winsys *winsys);
> > +PUBLIC struct pipe_screen *swr_create_screen(struct sw_winsys
> > +*winsys);
> >
> Do you really need this ? As-it this will make the swr loader
> swr_create_screen public which is bad.
> 
> Either way - [re]name the loader and backend entrypoints differently and
> use separate declarations. You can squash it here, but a separate patch
> (5.5/10) would be better.
> 
Ok, renaming backend entry points.

I'll resend another batch of changes for review, since there is order 
dependency and I can't send 6/10 ad 5.5/10 after the later ones.

Thanks,

george

> Thanks
> Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 06/10] swr: Windows-related changes

[Kyriazis, George]

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Emil Velikov
> Sent: Thursday, November 17, 2016 11:12 AM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH v3 06/10] swr: Windows-related changes
> 
> Hi George,
> 
> Seems I was unclear as a few suggestions got missed.
> 
> On 16 November 2016 at 02:26, George Kyriazis <george.kyria...@intel.com>
> wrote:
> > - Handle dynamic library loading for windows
> > - Implement swap for gdi
> > - fix prototypes
> > - update include paths on configure-based build for swr_loader.cpp
> > ---
> >  src/gallium/drivers/swr/Makefile.am|  7 +++
> >  src/gallium/drivers/swr/swr_loader.cpp | 28
> +---
> >  src/gallium/drivers/swr/swr_public.h   | 11 +++
> >  3 files changed, 39 insertions(+), 7 deletions(-)
> >
> > diff --git a/src/gallium/drivers/swr/Makefile.am
> > b/src/gallium/drivers/swr/Makefile.am
> > index dd1c2e6..305154f 100644
> > --- a/src/gallium/drivers/swr/Makefile.am
> > +++ b/src/gallium/drivers/swr/Makefile.am
> > @@ -217,6 +217,12 @@ libswrAVX2_la_CXXFLAGS = \
> libswrAVX2_la_SOURCES
> > = \
> > $(COMMON_SOURCES)
> >
> > +# XXX: $(SWR_AVX_CXXFLAGS) should not be included, but we end up
> > +including # simdintrin.h, which throws a warning if AVX is not
> > +enabled libmesaswr_la_CXXFLAGS = \
> > +   $(COMMON_CXXFLAGS) \
> > +   $(SWR_AVX_CXXFLAGS)
> > +
> Drop this.
> 
These are needed, otherwise the linux configure build breaks.

> >  # XXX: Don't ship these generated sources for now, since they are
> > specific  # to the LLVM version they are generated from. Thus a
> > release tarball  # containing the said files, generated against eg.
> > LLVM 3.8 will fail to build @@ -235,6 +241,7 @@ libswrAVX2_la_LDFLAGS
> > = \  include $(top_srcdir)/install-gallium-links.mk
> >
> >  EXTRA_DIST = \
> > +   SConscript \
> This should be part of the patch which brings the file - namely 08/10.
> 
OK.

> > rasterizer/archrast/events.proto \
> > rasterizer/jitter/scripts/gen_llvm_ir_macros.py \
> > rasterizer/jitter/scripts/gen_llvm_types.py \ diff --git
> > a/src/gallium/drivers/swr/swr_loader.cpp
> > b/src/gallium/drivers/swr/swr_loader.cpp
> > index 2113c37..4f3329e 100644
> > --- a/src/gallium/drivers/swr/swr_loader.cpp
> > +++ b/src/gallium/drivers/swr/swr_loader.cpp
> 
> > +#include "swr_screen.h"
> > +#include "swr_resource.h"
> > +
> You only need p_screen.h here. Adding the swr ones is wrong (afaict).
> 
These are needed for the screen struct definition needed to call 
screen->flush_frontbuffer()

> 
> > -struct pipe_screen *swr_create_screen(struct sw_winsys *winsys);
> > +PUBLIC struct pipe_screen *swr_create_screen(struct sw_winsys
> > +*winsys);
> >
> Do you really need this ? As-it this will make the swr loader
> swr_create_screen public which is bad.
> 
Ok.  I will rename our internal back-end one.  BTW, the same entry points are 
used on linux.

> Either way - [re]name the loader and backend entrypoints differently and
> use separate declarations. You can squash it here, but a separate patch
> (5.5/10) would be better.
> 
> Thanks
> Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 10/10] swr: Modify gen_knobs.{cpp|h} creation script

[Kyriazis, George]

> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Thursday, November 17, 2016 11:22 AM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH v3 10/10] swr: Modify gen_knobs.{cpp|h}
> creation script
> 
> On 16 November 2016 at 02:27, George Kyriazis <george.kyria...@intel.com>
> wrote:
> > Modify gen_knobs.py so that each invocation creates a single generated
> > file.  This is more similar to how the other generators behave.
> Nicely done.
> 
> >  mode change 100644 => 100755 src/gallium/drivers/swr/Makefile.am
> Please don't !
> 
Sorry, don’t know how this got there. :-)

> >
> >  env.CodeGenerate(
> > -target = 'rasterizer/archrast/gen_ar.event.cpp',
> > +target = 'rasterizer/archrast/gen_ar_event.cpp',
> >  script = swrroot + 'rasterizer/scripts/gen_archrast.py',
> >  source = 'rasterizer/archrast/events.proto',
> > -command = python_cmd + ' $SCRIPT --proto $SOURCE --output $TARGET
> --gen-event_cpp'
> > +command = python_cmd + ' $SCRIPT --proto $SOURCE --output
> $TARGET --gen_event_cpp'
> Squash there with 8/10
> 
> 
> >
> > -source = [
> > +# Auto-generated .cpp files (that need to generate object files)
> > +built_sources = [
> >  'rasterizer/scripts/gen_knobs.cpp',
> >  'rasterizer/jitter/builder_gen.cpp',
> >  'rasterizer/jitter/builder_x86.cpp',
> > +'rasterizer/archrast/gen_ar_event.cpp',
> >  ]
> >
> > +source = built_sources
> and these.
> 
> With that
> 1-5 and 7-9 (with the bits squashed appropriately) are
> Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
> 
> 6/10 and the potential 5.5/10 need some work.
> 
Can you please elaborate?  Not sure what needs work.  I've already fixed your 
previous comment to use UTIL_DL_PREFIX and UTIL_DL_EXT.

Thanks!

George

> This one is
> Acked-by: Emil Velikov <emil.veli...@collabora.com>
> 
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver

[Kyriazis, George]

Emil,

I've followed the approach of trying to localize the swr changes to where they 
belong in order to avoid "polluting" upper-level files.  If you're talking 
about modifying some of the files in the scons/ directory, I don't see a place 
where swr fits in, conceptually.

I do agree that using the full SCons.Script.ARGUMENTS is clunky, but I don't 
want to pollute top-level files with driver-specific things (swr in this case).

Thoughts?

George

> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Thursday, November 10, 2016 12:13 PM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver
> 
> On 10 November 2016 at 17:27, Kyriazis, George <george.kyria...@intel.com>
> wrote:
> >> -Original Message-
> >> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> >> Sent: Thursday, November 10, 2016 8:14 AM
> >> To: Kyriazis, George <george.kyria...@intel.com>
> >> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> >> Subject: Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver
> >>
> >> "gallium/targets: scons: wire swr support for libgl-gdi/libgl-xlib/osmesa"
> >>
> >> ... or alike ?
> >>
> >> > +import SCons.Script.SConscript
> >> > +
> >>
> >> > +if 'swr' in SCons.Script.ARGUMENTS and
> >> SCons.Script.ARGUMENTS['swr']:
> >> With the "move this to top level" suggestion this will read roughly
> >> as
> >>
> >> if env['swr']:
> >>
> > The command line variables, however (like swr=1) are not part of the
> environment.  Even then, env['swr'] would fail for non-swr builds, since 'swr'
> is not in the env dictionary.  This works for env['llvm'] sincellvm.py 
> initially
> sets it to False.  So, it will still be a 2-level test:   if 'swr' in env and 
> env['swr']:,
> which is not a simplication really.
> >
> > Is your point to move it to the environment, or to do a one-check test?
> >
> To consolidate the 'clunky' SCons.Script.ARGUMENTS + requirements [only
> llvm?] checking in a single place. Thus the [newly added in the env 
> dictionary]
> swr can be used throughout without even import(ing)
> SCons.Script.SConscript.
> 
> Thanks !
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver

[Kyriazis, George]

> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Thursday, November 10, 2016 8:14 AM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver
> 
> "gallium/targets: scons: wire swr support for libgl-gdi/libgl-xlib/osmesa"
> 
> ... or alike ?
> 
> > +import SCons.Script.SConscript
> > +
> 
> > +if 'swr' in SCons.Script.ARGUMENTS and
> SCons.Script.ARGUMENTS['swr']:
> With the "move this to top level" suggestion this will read roughly as
> 
> if env['swr']:
> 
The command line variables, however (like swr=1) are not part of the 
environment.  Even then, env['swr'] would fail for non-swr builds, since 'swr' 
is not in the env dictionary.  This works for env['llvm'] sincellvm.py 
initially sets it to False.  So, it will still be a 2-level test:   if 'swr' in 
env and env['swr']:, which is not a simplication really.

Is your point to move it to the environment, or to do a one-check test?

Thanks,

George

> -Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] mesa: added msvc HAS_TRIVIAL_DESTRUCTOR implementation

[Kyriazis, George]

Alright,

I won't include that particular change in my v2 of the other changes that I 
have, then.

Thanks!

George

> -Original Message-
> From: Brian Paul [mailto:bri...@vmware.com]
> Sent: Wednesday, November 9, 2016 4:03 PM
> To: Kyriazis, George <george.kyria...@intel.com>; Marek Olšák
> <mar...@gmail.com>
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH 2/3] mesa: added msvc
> HAS_TRIVIAL_DESTRUCTOR implementation
> 
> Sorry, I already pushed the modified patch.
> 
> -Brian
> 
> On 11/09/2016 02:57 PM, Kyriazis, George wrote:
> > I'll be sending about v2 of my patches later today, and (pending review) I
> will check them in (actually, I'll ask Tim Rowley to check them in for me, 
> since
> I don't have write access yet).
> >
> > I'll modify the check against _MSV_VER 1800 (instead of 1900), but it won't
> be tested on my end.
> >
> > Thanks,
> >
> > George
> >
> >> -Original Message-
> >> From: Marek Olšák [mailto:mar...@gmail.com]
> >> Sent: Wednesday, November 9, 2016 3:31 PM
> >> To: Brian Paul <bri...@vmware.com>
> >> Cc: Kyriazis, George <george.kyria...@intel.com>; mesa-
> >> d...@lists.freedesktop.org
> >> Subject: Re: [Mesa-dev] [PATCH 2/3] mesa: added msvc
> >> HAS_TRIVIAL_DESTRUCTOR implementation
> >>
> >> On Wed, Nov 9, 2016 at 9:58 PM, Brian Paul <bri...@vmware.com>
> wrote:
> >>> On 11/07/2016 03:32 PM, George Kyriazis wrote:
> >>>>
> >>>> not having it on windows causes a CANARY assertion in
> >>>> src/util/ralloc.c:get_header()
> >>>>
> >>>> Tested only on MSVC 19.00 (DevStudio 14.0), so #ifdef guards reflect
> that.
> >>>> ---
> >>>>src/util/macros.h | 5 +
> >>>>1 file changed, 5 insertions(+)
> >>>>
> >>>> diff --git a/src/util/macros.h b/src/util/macros.h index
> >>>> 27d1b62..12b26d3 100644
> >>>> --- a/src/util/macros.h
> >>>> +++ b/src/util/macros.h
> >>>> @@ -175,6 +175,11 @@ do {   \
> >>>>#  if __has_feature(has_trivial_destructor)
> >>>># define HAS_TRIVIAL_DESTRUCTOR(T)
> __has_trivial_destructor(T)
> >>>>#  endif
> >>>> +#   elif defined(_MSC_VER) && !defined(__INTEL_COMPILER)
> >>>> +#  if _MSC_VER >= 1900
> >>>> +# define HAS_TRIVIAL_DESTRUCTOR(T)
> __has_trivial_destructor(T)
> >>>> +#  else
> >>>> +#  endif
> >>>>#   endif
> >>>>#   ifndef HAS_TRIVIAL_DESTRUCTOR
> >>>>   /* It's always safe (if inefficient) to assume that a
> >>>>
> >>>
> >>> This seems to fix things for me too.  Though I changed the _MSC_VER
> >>> test to compare against 1800 for VS 2013.
> >>>
> >>> Tested-by: Brian Paul <bri...@vmware.com>
> >>>
> >>> If there's no objections, I'd like to commit this soon.
> >>
> >> Sounds good to me.
> >>
> >> Marek

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] mesa: added msvc HAS_TRIVIAL_DESTRUCTOR implementation

[Kyriazis, George]

I'll be sending about v2 of my patches later today, and (pending review) I will 
check them in (actually, I'll ask Tim Rowley to check them in for me, since I 
don't have write access yet).

I'll modify the check against _MSV_VER 1800 (instead of 1900), but it won't be 
tested on my end.

Thanks,

George

> -Original Message-
> From: Marek Olšák [mailto:mar...@gmail.com]
> Sent: Wednesday, November 9, 2016 3:31 PM
> To: Brian Paul <bri...@vmware.com>
> Cc: Kyriazis, George <george.kyria...@intel.com>; mesa-
> d...@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH 2/3] mesa: added msvc
> HAS_TRIVIAL_DESTRUCTOR implementation
> 
> On Wed, Nov 9, 2016 at 9:58 PM, Brian Paul <bri...@vmware.com> wrote:
> > On 11/07/2016 03:32 PM, George Kyriazis wrote:
> >>
> >> not having it on windows causes a CANARY assertion in
> >> src/util/ralloc.c:get_header()
> >>
> >> Tested only on MSVC 19.00 (DevStudio 14.0), so #ifdef guards reflect that.
> >> ---
> >>   src/util/macros.h | 5 +
> >>   1 file changed, 5 insertions(+)
> >>
> >> diff --git a/src/util/macros.h b/src/util/macros.h index
> >> 27d1b62..12b26d3 100644
> >> --- a/src/util/macros.h
> >> +++ b/src/util/macros.h
> >> @@ -175,6 +175,11 @@ do {   \
> >>   #  if __has_feature(has_trivial_destructor)
> >>   # define HAS_TRIVIAL_DESTRUCTOR(T) __has_trivial_destructor(T)
> >>   #  endif
> >> +#   elif defined(_MSC_VER) && !defined(__INTEL_COMPILER)
> >> +#  if _MSC_VER >= 1900
> >> +# define HAS_TRIVIAL_DESTRUCTOR(T) __has_trivial_destructor(T)
> >> +#  else
> >> +#  endif
> >>   #   endif
> >>   #   ifndef HAS_TRIVIAL_DESTRUCTOR
> >>  /* It's always safe (if inefficient) to assume that a
> >>
> >
> > This seems to fix things for me too.  Though I changed the _MSC_VER
> > test to compare against 1800 for VS 2013.
> >
> > Tested-by: Brian Paul <bri...@vmware.com>
> >
> > If there's no objections, I'd like to commit this soon.
> 
> Sounds good to me.
> 
> Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] gallium/scons: OpenSWR Windows support

[Kyriazis, George]

> -Original Message-
> From: Jose Fonseca [mailto:jfons...@vmware.com]
> Sent: Tuesday, November 8, 2016 4:17 PM
> To: Kyriazis, George <george.kyria...@intel.com>; mesa-
> d...@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH 1/3] gallium/scons: OpenSWR Windows
> support
> 
> On 07/11/16 22:32, George Kyriazis wrote:
> > - Added code to create screen and handle swaps in libgl_gdi.c
> > - Added call to swr SConscript
> > - included llvm 3.9 support for scons (windows swr only support 3.9 and
> >   later)
> > - include -DHAVE_SWR to subdirs that need it
> >
> > To buils SWR on windows, use "scons swr libgl-gdi"
> > ---
> >  scons/llvm.py | 21 +++--
> >  src/gallium/SConscript|  1 +
> >  src/gallium/targets/libgl-gdi/SConscript  |  4 
> > src/gallium/targets/libgl-gdi/libgl_gdi.c | 28
> > +++-  src/gallium/targets/libgl-xlib/SConscript
> |  4 
> >  src/gallium/targets/osmesa/SConscript |  4 
> >  6 files changed, 55 insertions(+), 7 deletions(-)
> >
> > diff --git a/scons/llvm.py b/scons/llvm.py index 1fc8a3f..977e47a
> > 100644
> > --- a/scons/llvm.py
> > +++ b/scons/llvm.py
> > @@ -106,7 +106,24 @@ def generate(env):
> >  ])
> >  env.Prepend(LIBPATH = [os.path.join(llvm_dir, 'lib')])
> >  # LIBS should match the output of `llvm-config --libs engine mcjit
> bitwriter x86asmprinter`
> > -if llvm_version >= distutils.version.LooseVersion('3.7'):
> > +if llvm_version >= distutils.version.LooseVersion('3.9'):
> > +env.Prepend(LIBS = [
> > +'LLVMX86Disassembler', 'LLVMX86AsmParser',
> > +'LLVMX86CodeGen', 'LLVMSelectionDAG', 'LLVMAsmPrinter',
> > +'LLVMDebugInfoCodeView', 'LLVMCodeGen',
> > +'LLVMScalarOpts', 'LLVMInstCombine',
> > +'LLVMInstrumentation', 'LLVMTransformUtils',
> > +'LLVMBitWriter', 'LLVMX86Desc',
> > +'LLVMMCDisassembler', 'LLVMX86Info',
> > +'LLVMX86AsmPrinter', 'LLVMX86Utils',
> > +'LLVMMCJIT', 'LLVMExecutionEngine', 'LLVMTarget',
> > +'LLVMAnalysis', 'LLVMProfileData',
> > +'LLVMRuntimeDyld', 'LLVMObject', 'LLVMMCParser',
> > +'LLVMBitReader', 'LLVMMC', 'LLVMCore',
> > +'LLVMSupport',
> > +'LLVMIRReader', 'LLVMASMParser'
> > +])
> > +elif llvm_version >= distutils.version.LooseVersion('3.7'):
> >  env.Prepend(LIBS = [
> >  'LLVMBitWriter', 'LLVMX86Disassembler', 'LLVMX86AsmParser',
> >  'LLVMX86CodeGen', 'LLVMSelectionDAG',
> > 'LLVMAsmPrinter', @@ -203,7 +220,7 @@ def generate(env):
> >  if '-fno-rtti' in cxxflags:
> >  env.Append(CXXFLAGS = ['-fno-rtti'])
> >
> > -components = ['engine', 'mcjit', 'bitwriter', 'x86asmprinter',
> 'mcdisassembler']
> > +components = ['engine', 'mcjit', 'bitwriter',
> > + 'x86asmprinter', 'mcdisassembler', 'irreader']
> >
> >  env.ParseConfig('llvm-config --libs ' + ' '.join(components))
> >  env.ParseConfig('llvm-config --ldflags') diff --git
> > a/src/gallium/SConscript b/src/gallium/SConscript index
> > f98268f..9273db7 100644
> > --- a/src/gallium/SConscript
> > +++ b/src/gallium/SConscript
> > @@ -18,6 +18,7 @@ SConscript([
> >  'drivers/softpipe/SConscript',
> >  'drivers/svga/SConscript',
> >  'drivers/trace/SConscript',
> > +'drivers/swr/SConscript',
> >  ])
> >
> >  #
> > diff --git a/src/gallium/targets/libgl-gdi/SConscript
> > b/src/gallium/targets/libgl-gdi/SConscript
> > index 2a52363..ef8050b 100644
> > --- a/src/gallium/targets/libgl-gdi/SConscript
> > +++ b/src/gallium/targets/libgl-gdi/SConscript
> > @@ -30,6 +30,10 @@ if env['llvm']:
> >  env.Append(CPPDEFINES = 'HAVE_LLVMPIPE')
> >  drivers += [llvmpipe]
> >
> > +if 'swr' in COMMAND_LINE_TARGETS :
> > +env.Append(CPPDEFINES = 'HAVE_SWR')
> > +drivers += [swr]
> > +
> >  if env['gcc'] and env['machine'] != 'x86_64':
> >  # DEF parser in certain versions of MinGW is busted, as does not behave
> as
> >  # MSVC.  mingw-w64 works fine.
> > diff --git a/src/gallium/targets/libgl-gdi/libgl_gdi.c
> > b/src/gallium/targets/libgl-gdi/libgl_gdi.c
> > 

Re: [Mesa-dev] [PATCH 2/3] mesa: added msvc HAS_TRIVIAL_DESTRUCTOR implementation

[Kyriazis, George]

> -Original Message-
> From: Jose Fonseca [mailto:jfons...@vmware.com]
> Sent: Tuesday, November 8, 2016 4:12 PM
> To: Kyriazis, George <george.kyria...@intel.com>; mesa-
> d...@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH 2/3] mesa: added msvc
> HAS_TRIVIAL_DESTRUCTOR implementation
> 
> On 07/11/16 22:32, George Kyriazis wrote:
> > not having it on windows causes a CANARY assertion in
> > src/util/ralloc.c:get_header()
> >
> > Tested only on MSVC 19.00 (DevStudio 14.0), so #ifdef guards reflect that.
> > ---
> >  src/util/macros.h | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/src/util/macros.h b/src/util/macros.h index
> > 27d1b62..12b26d3 100644
> > --- a/src/util/macros.h
> > +++ b/src/util/macros.h
> > @@ -175,6 +175,11 @@ do {   \
> >  #  if __has_feature(has_trivial_destructor)
> >  # define HAS_TRIVIAL_DESTRUCTOR(T) __has_trivial_destructor(T)
> >  #  endif
> > +#   elif defined(_MSC_VER) && !defined(__INTEL_COMPILER)
> > +#  if _MSC_VER >= 1900
> > +# define HAS_TRIVIAL_DESTRUCTOR(T) __has_trivial_destructor(T)
> > +#  else
> 
> #else is redundant her.  Otherwise looks good.
> 
No problem.  I'll remove.

George

> Reviewed-by: Jose Fonseca <jfons...@vmware.com>
> 
> > +#  endif
> >  #   endif
> >  #   ifndef HAS_TRIVIAL_DESTRUCTOR
> > /* It's always safe (if inefficient) to assume that a
> >

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] swr: Support windows builds

[Kyriazis, George]

> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Tuesday, November 8, 2016 10:54 AM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH 3/3] swr: Support windows builds
> 
> On 8 November 2016 at 15:48, Kyriazis, George <george.kyria...@intel.com>
> wrote:
> > Comments inline..
> >
> >> -Original Message-
> >> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> >> Sent: Tuesday, November 8, 2016 8:25 AM
> >> To: Kyriazis, George <george.kyria...@intel.com>
> >> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> >> Subject: Re: [Mesa-dev] [PATCH 3/3] swr: Support windows builds
> >>
> >> On 7 November 2016 at 22:32, George Kyriazis
> >> <george.kyria...@intel.com>
> >> wrote:
> >> > - Added SConscript files
> >> > - better handling of NOMINMAX for  inclusion
> >> > - Reorder header files in swr_context.cpp to handle NOMINMAX
> >> > better,
> >> since
> >> >   mesa header files include windows.h before we get a chance to
> #define
> >> >   NOMINMAX
> >> > - cleaner support for .dll and .so prefix/suffix across OSes
> >> > - added PUBLIC for some protos
> >> > - added swr_gdi_swap() which is call from libgl_gdi.c
> >> > ---
> >> >  src/gallium/drivers/swr/Makefile.am|   8 ++
> >> >  src/gallium/drivers/swr/SConscript |  46 +++
> >> >  src/gallium/drivers/swr/SConscript-arch| 175
> >> +
> >> >  src/gallium/drivers/swr/rasterizer/common/os.h |   5 +-
> >> >  src/gallium/drivers/swr/swr_context.cpp|  16 +--
> >> >  src/gallium/drivers/swr/swr_context.h  |   2 +
> >> >  src/gallium/drivers/swr/swr_loader.cpp |  37 +-
> >> >  src/gallium/drivers/swr/swr_public.h   |  11 +-
> >> >  src/gallium/drivers/swr/swr_screen.cpp |  25 +---
> >> >  9 files changed, 291 insertions(+), 34 deletions(-)  create mode
> >> > 100644 src/gallium/drivers/swr/SConscript
> >> >  create mode 100644 src/gallium/drivers/swr/SConscript-arch
> >> >
> >> Similar to 1/3 this patch does too many things. Please _don't_  do that.
> >>
> >> Some ideas based on the above:
> >>  - source code fixes - one or multiple patches, depending on details.
> >>  - automake fixes - ^^
> >>  - introduce scons build (+ the EXTRA_DIST hunk)
> >>
> > As stated in review of patch 1/3, I will send v2 of patches with different
> breakdown.
> >
> >
> >> Some misc comments below.
> >>
> >>
> >> > +++ b/src/gallium/drivers/swr/SConscript
> >> > @@ -0,0 +1,46 @@
> >> > +Import('*')
> >> > +
> >> > +from sys import executable as python_cmd import distutils.version
> >> Seems unused. Maybe it was aimed for the llvm 3.9 requirement/check
> >> mentioned in 1/3 ?
> >>
> > Scons build fails without the Import('*'), because env is undefined:
> >
> > NameError: name 'env' is not defined:
> >
> The "unused" comment was meant for the "import distutils.version"
> line. Which seemingly got manged somewhere along the way.
> 

That explains it.  Ok, I'll take care of it.

> >> > +import os.path
> >> > +
> >> > +if not 'swr' in COMMAND_LINE_TARGETS:
> >> > +Return()
> >> > +
> >> > +if not env['llvm']:
> >> > +print 'warning: LLVM disabled: not building swr'
> >> > +Return()
> >> > +
> >> > +env.MSVC2013Compat()
> >> > +
> >>
> >> > +swr_arch = 'avx'
> >> > +VariantDir('avx', '.', duplicate=0)
> >> > +SConscript('avx/SConscript-arch', exports='swr_arch')
> >> > +
> >> > +swr_arch = 'avx2'
> >> > +VariantDir('avx2', '.', duplicate=0)
> >> > +SConscript('avx2/SConscript-arch', exports='swr_arch')
> >> > +
> >> Afaict one can just fold the SConscript-arch here. Thus one won't
> >> need to bother with the above nor the Depends hunk below.
> >> Additionally with current approach one is generating [the] identical
> >> source files twice. Far from ideal...
> >>
> > The AVX and AVX2 builds build differently (with different compiler flags).
> At runtime, w

Re: [Mesa-dev] [PATCH 3/3] swr: Support windows builds

[Kyriazis, George]

Comments inline..

> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Tuesday, November 8, 2016 8:25 AM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH 3/3] swr: Support windows builds
> 
> On 7 November 2016 at 22:32, George Kyriazis <george.kyria...@intel.com>
> wrote:
> > - Added SConscript files
> > - better handling of NOMINMAX for  inclusion
> > - Reorder header files in swr_context.cpp to handle NOMINMAX better,
> since
> >   mesa header files include windows.h before we get a chance to #define
> >   NOMINMAX
> > - cleaner support for .dll and .so prefix/suffix across OSes
> > - added PUBLIC for some protos
> > - added swr_gdi_swap() which is call from libgl_gdi.c
> > ---
> >  src/gallium/drivers/swr/Makefile.am|   8 ++
> >  src/gallium/drivers/swr/SConscript |  46 +++
> >  src/gallium/drivers/swr/SConscript-arch| 175
> +
> >  src/gallium/drivers/swr/rasterizer/common/os.h |   5 +-
> >  src/gallium/drivers/swr/swr_context.cpp|  16 +--
> >  src/gallium/drivers/swr/swr_context.h  |   2 +
> >  src/gallium/drivers/swr/swr_loader.cpp |  37 +-
> >  src/gallium/drivers/swr/swr_public.h   |  11 +-
> >  src/gallium/drivers/swr/swr_screen.cpp |  25 +---
> >  9 files changed, 291 insertions(+), 34 deletions(-)  create mode
> > 100644 src/gallium/drivers/swr/SConscript
> >  create mode 100644 src/gallium/drivers/swr/SConscript-arch
> >
> Similar to 1/3 this patch does too many things. Please _don't_  do that.
> 
> Some ideas based on the above:
>  - source code fixes - one or multiple patches, depending on details.
>  - automake fixes - ^^
>  - introduce scons build (+ the EXTRA_DIST hunk)
> 
As stated in review of patch 1/3, I will send v2 of patches with different 
breakdown.


> Some misc comments below.
> 
> 
> > +++ b/src/gallium/drivers/swr/SConscript
> > @@ -0,0 +1,46 @@
> > +Import('*')
> > +
> > +from sys import executable as python_cmd import distutils.version
> Seems unused. Maybe it was aimed for the llvm 3.9 requirement/check
> mentioned in 1/3 ?
> 
Scons build fails without the Import('*'), because env is undefined:

NameError: name 'env' is not defined:

> > +import os.path
> > +
> > +if not 'swr' in COMMAND_LINE_TARGETS:
> > +Return()
> > +
> > +if not env['llvm']:
> > +print 'warning: LLVM disabled: not building swr'
> > +Return()
> > +
> > +env.MSVC2013Compat()
> > +
> 
> > +swr_arch = 'avx'
> > +VariantDir('avx', '.', duplicate=0)
> > +SConscript('avx/SConscript-arch', exports='swr_arch')
> > +
> > +swr_arch = 'avx2'
> > +VariantDir('avx2', '.', duplicate=0)
> > +SConscript('avx2/SConscript-arch', exports='swr_arch')
> > +
> Afaict one can just fold the SConscript-arch here. Thus one won't need to
> bother with the above nor the Depends hunk below.
> Additionally with current approach one is generating [the] identical source
> files twice. Far from ideal...
> 
The AVX and AVX2 builds build differently (with different compiler flags).  At 
runtime, we load the appropriate dll, based on the underlying architecture.  We 
do the same thing on the linux build.  Also, since duplicate=0, source is not 
duplicated.  Yes, generated files are generated twice, however currently 
SConscript is just a shell around SConscript-arch; all the logic that generates 
the files and source lists is in SConscript-arch.  By moving the auto 
generation to SConscript will generate only one copy of the gen files, however 
it splits the build logic into two files, which is more messy.  I can certainly 
move the generation code in SConscript, however, I think that it's cleaner to 
strive for source code cleanliness, as opposed to generate code cleanliness.

> > +env = env.Clone()
> > +
> > +source = env.ParseSourceList('Makefile.sources', [
> > +'LOADER_SOURCES'
> > +])
> > +
> > +env.Prepend(CPPPATH = [
> > +'rasterizer/scripts'
> > +])
> > +
> > +swr = env.ConvenienceLibrary(
> > +   target = 'swr',
> > +   source = source,
> > +   )
> Keep the indentation to 4 spaces here and throughout the SConscripts.
> That's a python requirement.
Ok, will correct that.

> In general I'd encourage using .editorconfig and updating the section for swr,
> if needed.
> 
> 
> > +# remove headers, as scons thinks they are static objects for the .so
> > +sou

Re: [Mesa-dev] [PATCH 1/3] gallium/scons: OpenSWR Windows support

[Kyriazis, George]

Thank you for the review.  Comments inline.

> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Tuesday, November 8, 2016 7:52 AM
> To: Kyriazis, George <george.kyria...@intel.com>; Jose Fonseca
> <jfons...@vmware.com>
> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH 1/3] gallium/scons: OpenSWR Windows
> support
> 
> Hi George,
> 
> For Scons changes please keep Jose Fonseca in the loop.
> 
> On 7 November 2016 at 22:32, George Kyriazis <george.kyria...@intel.com>
> wrote:
> > - Added code to create screen and handle swaps in libgl_gdi.c
> > - Added call to swr SConscript
> > - included llvm 3.9 support for scons (windows swr only support 3.9 and
> >   later)
> If that's the case building SWR with earlier one should error out ?
> Then again, here you reference gallium/drivers/swr/
> 
Yes, SWR will only work on windows for 3.9 and above.

> > - include -DHAVE_SWR to subdirs that need it
> >
> As the above indicates here you have multiple independent changes.
> Please do _not_ mix those into a single patch.
> 
I'll resend v2 of the patches with a different breakdown.

Additional comments on your review of patch 3/3.

Thanks,

George

> 
> > To buils SWR on windows, use "scons swr libgl-gdi"
> > ---
> >  scons/llvm.py | 21 +++--
> >  src/gallium/SConscript|  1 +
> >  src/gallium/targets/libgl-gdi/SConscript  |  4 
> > src/gallium/targets/libgl-gdi/libgl_gdi.c | 28
> > +++-  src/gallium/targets/libgl-xlib/SConscript
> |  4 
> >  src/gallium/targets/osmesa/SConscript |  4 
> >  6 files changed, 55 insertions(+), 7 deletions(-)
> >
> > diff --git a/scons/llvm.py b/scons/llvm.py index 1fc8a3f..977e47a
> > 100644
> > --- a/scons/llvm.py
> > +++ b/scons/llvm.py
> > @@ -106,7 +106,24 @@ def generate(env):
> >  ])
> >  env.Prepend(LIBPATH = [os.path.join(llvm_dir, 'lib')])
> >  # LIBS should match the output of `llvm-config --libs engine mcjit
> bitwriter x86asmprinter`
> > -if llvm_version >= distutils.version.LooseVersion('3.7'):
> > +if llvm_version >= distutils.version.LooseVersion('3.9'):
> > +env.Prepend(LIBS = [
> > +'LLVMX86Disassembler', 'LLVMX86AsmParser',
> > +'LLVMX86CodeGen', 'LLVMSelectionDAG', 'LLVMAsmPrinter',
> > +'LLVMDebugInfoCodeView', 'LLVMCodeGen',
> > +'LLVMScalarOpts', 'LLVMInstCombine',
> > +'LLVMInstrumentation', 'LLVMTransformUtils',
> > +'LLVMBitWriter', 'LLVMX86Desc',
> > +'LLVMMCDisassembler', 'LLVMX86Info',
> > +'LLVMX86AsmPrinter', 'LLVMX86Utils',
> > +'LLVMMCJIT', 'LLVMExecutionEngine', 'LLVMTarget',
> > +'LLVMAnalysis', 'LLVMProfileData',
> > +'LLVMRuntimeDyld', 'LLVMObject', 'LLVMMCParser',
> > +'LLVMBitReader', 'LLVMMC', 'LLVMCore',
> > +'LLVMSupport',
> > +'LLVMIRReader', 'LLVMASMParser'
> > +])
> LLVM 3.9 support. cc: mesa-stable (if Jose/Brian are up for it).
> 
> > +elif llvm_version >= distutils.version.LooseVersion('3.7'):
> >  env.Prepend(LIBS = [
> >  'LLVMBitWriter', 'LLVMX86Disassembler', 'LLVMX86AsmParser',
> >  'LLVMX86CodeGen', 'LLVMSelectionDAG',
> > 'LLVMAsmPrinter', @@ -203,7 +220,7 @@ def generate(env):
> >  if '-fno-rtti' in cxxflags:
> >  env.Append(CXXFLAGS = ['-fno-rtti'])
> >
> > -components = ['engine', 'mcjit', 'bitwriter', 'x86asmprinter',
> 'mcdisassembler']
> > +components = ['engine', 'mcjit', 'bitwriter',
> > + 'x86asmprinter', 'mcdisassembler', 'irreader']
> Standalone bugfix. Cc: mesa-stable ?
> 
> 
> > +++ b/src/gallium/SConscript
> 
> > +'drivers/swr/SConscript',
> This file is only introduced with 3/3. Which means that you've added scons
> support which is broken - please don't do that.
> 
> 
> > +++ b/src/gallium/targets/libgl-gdi/SConscript
> > +++ b/src/gallium/targets/libgl-gdi/libgl_gdi.c
> > +++ b/src/gallium/targets/libgl-xlib/SConscript
> > +++ b/src/gallium/targets/osmesa/SConscript
> 
> Couple of ideas how to split these. Or anything else that comes to mind on
> your end.
> 
> A)
> Patch 1
> src/gallium/SConscript
> src/gallium/targets/libgl-gdi/SConscr

Re: [Mesa-dev] [PATCH] swr: Removed stalling SwrWaitForIdle from queries.

[Kyriazis, George]

Reviewed-by: George Kyriazis 
>



From: Bruce Cherniak >
Subject: [PATCH] swr: Removed stalling SwrWaitForIdle from queries.
Date: September 27, 2016 at 1:27:08 PM CDT
To: >
Cc: Bruce Cherniak >

Previous fundamental change in stats gathering added a temporary
SwrWaitForIdle to begin_query and end_query.  Code has been reworked to
remove stall.
---
src/gallium/drivers/swr/swr_context.cpp |  33 +++
src/gallium/drivers/swr/swr_context.h   |  11 ++-
src/gallium/drivers/swr/swr_query.cpp   | 152 +---
src/gallium/drivers/swr/swr_query.h |  10 +--
4 files changed, 87 insertions(+), 119 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_context.cpp 
b/src/gallium/drivers/swr/swr_context.cpp
index 15e60cd..cbc60e0 100644
--- a/src/gallium/drivers/swr/swr_context.cpp
+++ b/src/gallium/drivers/swr/swr_context.cpp
@@ -24,6 +24,7 @@
#include "util/u_memory.h"
#include "util/u_inlines.h"
#include "util/u_format.h"
+#include "util/u_atomic.h"

extern "C" {
#include "util/u_transfer.h"
@@ -352,9 +353,9 @@ swr_UpdateStats(HANDLE hPrivateContext, const SWR_STATS 
*pStats)
   if (!pDC)
  return;

-   struct swr_context *ctx = (struct swr_context *)pDC->swr_ctx;
+   struct swr_query_result *pqr = (struct swr_query_result *)pDC->pStats;

-   SWR_STATS *pSwrStats = >stats;
+   SWR_STATS *pSwrStats = >core;

   pSwrStats->DepthPassCount += pStats->DepthPassCount;
   pSwrStats->PsInvocations += pStats->PsInvocations;
@@ -369,22 +370,24 @@ swr_UpdateStatsFE(HANDLE hPrivateContext, const 
SWR_STATS_FE *pStats)
   if (!pDC)
  return;

-   struct swr_context *ctx = (struct swr_context *)pDC->swr_ctx;
+   struct swr_query_result *pqr = (struct swr_query_result *)pDC->pStats;

-   SWR_STATS_FE *pSwrStats = >statsFE;
-   pSwrStats->IaVertices += pStats->IaVertices;
-   pSwrStats->IaPrimitives += pStats->IaPrimitives;
-   pSwrStats->VsInvocations += pStats->VsInvocations;
-   pSwrStats->HsInvocations += pStats->HsInvocations;
-   pSwrStats->DsInvocations += pStats->DsInvocations;
-   pSwrStats->GsInvocations += pStats->GsInvocations;
-   pSwrStats->CInvocations += pStats->CInvocations;
-   pSwrStats->CPrimitives += pStats->CPrimitives;
-   pSwrStats->GsPrimitives += pStats->GsPrimitives;
+   SWR_STATS_FE *pSwrStats = >coreFE;
+   p_atomic_add(>IaVertices, pStats->IaVertices);
+   p_atomic_add(>IaPrimitives, pStats->IaPrimitives);
+   p_atomic_add(>VsInvocations, pStats->VsInvocations);
+   p_atomic_add(>HsInvocations, pStats->HsInvocations);
+   p_atomic_add(>DsInvocations, pStats->DsInvocations);
+   p_atomic_add(>GsInvocations, pStats->GsInvocations);
+   p_atomic_add(>CInvocations, pStats->CInvocations);
+   p_atomic_add(>CPrimitives, pStats->CPrimitives);
+   p_atomic_add(>GsPrimitives, pStats->GsPrimitives);

   for (unsigned i = 0; i < 4; i++) {
-  pSwrStats->SoPrimStorageNeeded[i] += pStats->SoPrimStorageNeeded[i];
-  pSwrStats->SoNumPrimsWritten[i] += pStats->SoNumPrimsWritten[i];
+  p_atomic_add(>SoPrimStorageNeeded[i],
+pStats->SoPrimStorageNeeded[i]);
+  p_atomic_add(>SoNumPrimsWritten[i],
+pStats->SoNumPrimsWritten[i]);
   }
}

diff --git a/src/gallium/drivers/swr/swr_context.h 
b/src/gallium/drivers/swr/swr_context.h
index 6854d69..eecfe0d 100644
--- a/src/gallium/drivers/swr/swr_context.h
+++ b/src/gallium/drivers/swr/swr_context.h
@@ -92,7 +92,7 @@ struct swr_draw_context {
   float userClipPlanes[PIPE_MAX_CLIP_PLANES][4];

   SWR_SURFACE_STATE renderTargets[SWR_NUM_ATTACHMENTS];
-   void *swr_ctx;
+   void *pStats;
};

/* gen_llvm_types FINI */
@@ -159,9 +159,6 @@ struct swr_context {
   /* SWR private state - draw context */
   struct swr_draw_context swrDC;

-   SWR_STATS stats;
-   SWR_STATS_FE statsFE;
-
   unsigned dirty; /**< Mask of SWR_NEW_x flags */
};

@@ -172,11 +169,13 @@ swr_context(struct pipe_context *pipe)
}

static INLINE void
-swr_update_draw_context(struct swr_context *ctx)
+swr_update_draw_context(struct swr_context *ctx,
+  struct swr_query_result *pqr = nullptr)
{
   swr_draw_context *pDC =
  (swr_draw_context *)SwrGetPrivateContextState(ctx->swrContext);
-   ctx->swrDC.swr_ctx = ctx;
+   if (pqr)
+  ctx->swrDC.pStats = pqr;
   memcpy(pDC, >swrDC, sizeof(swr_draw_context));
}

diff --git a/src/gallium/drivers/swr/swr_query.cpp 
b/src/gallium/drivers/swr/swr_query.cpp
index c51c529..8bb0b16 100644
--- a/src/gallium/drivers/swr/swr_query.cpp
+++ b/src/gallium/drivers/swr/swr_query.cpp
@@ -71,48 +71,6 @@ swr_destroy_query(struct pipe_context *pipe, struct 
pipe_query *q)
}


-static void
-swr_gather_stats(struct pipe_context *pipe, struct swr_query *pq)
-{
-   struct swr_context *ctx = swr_context(pipe);
-
-   assert(pq->result);
-   struct swr_query_result 

Re: [Mesa-dev] [PATCH] gallium: detect avx512 cpu features

[Kyriazis, George]

All good, but I would suggest matching the already existing editing style (ie 
correct tabulation, and zero-padding of cpuid() args.

Reviewed-By: George Kyriazis 


> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Tim Rowley
> Sent: Wednesday, May 25, 2016 7:11 PM
> To: mesa-dev@lists.freedesktop.org
> Subject: [Mesa-dev] [PATCH] gallium: detect avx512 cpu features
> 
> ---
>  src/gallium/auxiliary/util/u_cpu_detect.c | 17 +
>  src/gallium/auxiliary/util/u_cpu_detect.h | 10 ++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/src/gallium/auxiliary/util/u_cpu_detect.c
> b/src/gallium/auxiliary/util/u_cpu_detect.c
> index aa3c30a..0d4a7c4 100644
> --- a/src/gallium/auxiliary/util/u_cpu_detect.c
> +++ b/src/gallium/auxiliary/util/u_cpu_detect.c
> @@ -387,6 +387,23 @@ util_cpu_detect(void)
>   util_cpu_caps.has_avx2 = (regs7[1] >> 5) & 1;
>}
> 
> +  // check for avx512
> +  if (((regs2[2] >> 27) & 1) && // OSXSAVE
> +  (xgetbv() & (0x7 << 5)) && // OPMASK: upper-256 enabled by OS
> +  (xgetbv() & (0x3 << 1))) { // XMM/YMM enabled by OS
> + uint32_t regs3[4];
> + cpuid(0x7, regs3);
> + util_cpu_caps.has_avx512f= (regs3[1] >> 16) & 1;
> + util_cpu_caps.has_avx512dq   = (regs3[1] >> 17) & 1;
> + util_cpu_caps.has_avx512ifma = (regs3[1] >> 21) & 1;
> + util_cpu_caps.has_avx512pf   = (regs3[1] >> 26) & 1;
> + util_cpu_caps.has_avx512er   = (regs3[1] >> 27) & 1;
> + util_cpu_caps.has_avx512cd   = (regs3[1] >> 28) & 1;
> + util_cpu_caps.has_avx512bw   = (regs3[1] >> 30) & 1;
> + util_cpu_caps.has_avx512vl   = (regs3[1] >> 31) & 1;
> + util_cpu_caps.has_avx512vbmi = (regs3[2] >>  1) & 1;
> +  }
> +
>if (regs[1] == 0x756e6547 && regs[2] == 0x6c65746e && regs[3] ==
> 0x49656e69) {
>   /* GenuineIntel */
>   util_cpu_caps.has_intel = 1;
> diff --git a/src/gallium/auxiliary/util/u_cpu_detect.h
> b/src/gallium/auxiliary/util/u_cpu_detect.h
> index 5ccfc93..b612a2c 100644
> --- a/src/gallium/auxiliary/util/u_cpu_detect.h
> +++ b/src/gallium/auxiliary/util/u_cpu_detect.h
> @@ -71,6 +71,16 @@ struct util_cpu_caps {
> unsigned has_xop:1;
> unsigned has_altivec:1;
> unsigned has_daz:1;
> +
> +   unsigned has_avx512f:1;
> +   unsigned has_avx512dq:1;
> +   unsigned has_avx512ifma:1;
> +   unsigned has_avx512pf:1;
> +   unsigned has_avx512er:1;
> +   unsigned has_avx512cd:1;
> +   unsigned has_avx512bw:1;
> +   unsigned has_avx512vl:1;
> +   unsigned has_avx512vbmi:1;
>  };
> 
>  extern struct util_cpu_caps
> --
> 1.8.3.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr: Add missing break in query switch statement.

[Kyriazis, George]

Reviewed-by: George Kyriazis 

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of BruceCherniak
> Sent: Monday, May 9, 2016 9:00 AM
> To: mesa-dev@lists.freedesktop.org
> Subject: [Mesa-dev] [PATCH] swr: Add missing break in query switch
> statement.
> 
> Missed a switch break in query stat collection when refactoring queries.
> ---
>  src/gallium/drivers/swr/swr_query.cpp |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/src/gallium/drivers/swr/swr_query.cpp
> b/src/gallium/drivers/swr/swr_query.cpp
> index 5c59965..7867db3 100644
> --- a/src/gallium/drivers/swr/swr_query.cpp
> +++ b/src/gallium/drivers/swr/swr_query.cpp
> @@ -152,6 +152,7 @@ swr_get_query_result(struct pipe_context *pipe,
>break;
> case PIPE_QUERY_PRIMITIVES_GENERATED:
>result->u64 = end->core.IaPrimitives - start->core.IaPrimitives;
> +  break;
> case PIPE_QUERY_PRIMITIVES_EMITTED:
>result->u64 = end->core.SoNumPrimsWritten[index]
>   - start->core.SoNumPrimsWritten[index];
> --
> 1.7.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr: Remove stall waiting for core query counters.

[Kyriazis, George]

Reviewed-By: George Kyriazis 

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of BruceCherniak
> Sent: Thursday, April 28, 2016 12:13 PM
> To: mesa-dev@lists.freedesktop.org
> Subject: [Mesa-dev] [PATCH] swr: Remove stall waiting for core query
> counters.
> 
> When gathering query results, swr_gather_stats was
> unnecessarily stalling the entire pipeline.  Results are now
> collected asynchronously, with a fence marking completion.
> ---
>  src/gallium/drivers/swr/swr_fence.cpp |6 -
>  src/gallium/drivers/swr/swr_fence.h   |8 ++
>  src/gallium/drivers/swr/swr_query.cpp |  180 --
> ---
>  src/gallium/drivers/swr/swr_query.h   |   11 ++-
>  4 files changed, 81 insertions(+), 124 deletions(-)
> 
> diff --git a/src/gallium/drivers/swr/swr_fence.cpp
> b/src/gallium/drivers/swr/swr_fence.cpp
> index 2e95b39..8a8e864 100644
> --- a/src/gallium/drivers/swr/swr_fence.cpp
> +++ b/src/gallium/drivers/swr/swr_fence.cpp
> @@ -105,12 +105,6 @@ swr_fence_reference(struct pipe_screen *screen,
>swr_fence_destroy(old);
>  }
> 
> -static INLINE boolean
> -swr_is_fence_done(struct pipe_fence_handle *fence_handle)
> -{
> -   struct swr_fence *fence = swr_fence(fence_handle);
> -   return (fence->read == fence->write);
> -}
> 
>  /*
>   * Wait for the fence to finish.
> diff --git a/src/gallium/drivers/swr/swr_fence.h
> b/src/gallium/drivers/swr/swr_fence.h
> index df3776e..47f4d2e 100644
> --- a/src/gallium/drivers/swr/swr_fence.h
> +++ b/src/gallium/drivers/swr/swr_fence.h
> @@ -45,6 +45,14 @@ swr_fence(struct pipe_fence_handle *fence)
> return (struct swr_fence *)fence;
>  }
> 
> +
> +static INLINE boolean
> +swr_is_fence_done(struct pipe_fence_handle *fence_handle)
> +{
> +   struct swr_fence *fence = swr_fence(fence_handle);
> +   return (fence->read == fence->write);
> +}
> +
>  static INLINE boolean
>  swr_is_fence_pending(struct pipe_fence_handle *fence_handle)
>  {
> diff --git a/src/gallium/drivers/swr/swr_query.cpp
> b/src/gallium/drivers/swr/swr_query.cpp
> index f038a6e..5c59965 100644
> --- a/src/gallium/drivers/swr/swr_query.cpp
> +++ b/src/gallium/drivers/swr/swr_query.cpp
> @@ -62,10 +62,8 @@ swr_destroy_query(struct pipe_context *pipe, struct
> pipe_query *q)
> struct swr_query *pq = swr_query(q);
> 
> if (pq->fence) {
> -  if (!swr_is_fence_pending(pq->fence)) {
> - swr_fence_submit(swr_context(pipe), pq->fence);
> +  if (swr_is_fence_pending(pq->fence))
>   swr_fence_finish(pipe->screen, pq->fence, 0);
> -  }
>swr_fence_reference(pipe->screen, >fence, NULL);
> }
> 
> @@ -73,100 +71,45 @@ swr_destroy_query(struct pipe_context *pipe,
> struct pipe_query *q)
>  }
> 
> 
> -// XXX Create a fence callback, rather than stalling SwrWaitForIdle
>  static void
>  swr_gather_stats(struct pipe_context *pipe, struct swr_query *pq)
>  {
> struct swr_context *ctx = swr_context(pipe);
> 
> assert(pq->result);
> -   union pipe_query_result *result = pq->result;
> +   struct swr_query_result *result = pq->result;
> boolean enable_stats = pq->enable_stats;
> -   SWR_STATS swr_stats = {0};
> -
> -   if (pq->fence) {
> -  if (!swr_is_fence_pending(pq->fence)) {
> - swr_fence_submit(ctx, pq->fence);
> - swr_fence_finish(pipe->screen, pq->fence, 0);
> -  }
> -  swr_fence_reference(pipe->screen, >fence, NULL);
> -   }
> 
> -   /*
> -* These queries don't need SWR Stats enabled in the core
> -* Set and return.
> -*/
> +   /* A few results don't require the core, so don't involve it */
> switch (pq->type) {
> case PIPE_QUERY_TIMESTAMP:
> case PIPE_QUERY_TIME_ELAPSED:
> -  result->u64 = swr_get_timestamp(pipe->screen);
> -  return;
> +  result->timestamp = swr_get_timestamp(pipe->screen);
>break;
> case PIPE_QUERY_TIMESTAMP_DISJOINT:
> -  /* nothing to do here */
> -  return;
> -  break;
> case PIPE_QUERY_GPU_FINISHED:
> -  result->b = TRUE; /* XXX TODO Add an api func to SWR to compare
> drawId
> -   vs LastRetiredId? */
> -  return;
> +  /* nothing to do here */
>break;
> default:
> -  /* Any query that needs SwrCore stats */
> -  break;
> -   }
> -
> -   /*
> -* All other results are collected from SwrCore counters
> -*/
> +  /*
> +   * All other results are collected from SwrCore counters via
> +   * SwrGetStats. This returns immediately, but results are later filled
> +   * in by the backend.  Fence status is the only indication of
> +   * completion.  */
> +  SwrGetStats(ctx->swrContext, >core);
> +
> +  if (!pq->fence) {
> + struct swr_screen *screen = swr_screen(pipe->screen);
> + swr_fence_reference(pipe->screen, >fence, screen-
> >flush_fence);
> +  }
> +  swr_fence_submit(ctx, pq->fence);
> 
> -   /* XXX, Should turn this into 

Re: [Mesa-dev] [PATCH v2] swr: fix memory leaks from vs/fs compilation

[Kyriazis, George]

Reviewed by: George Kyriazis 

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Tim Rowley
> Sent: Wednesday, April 20, 2016 7:42 PM
> To: mesa-dev@lists.freedesktop.org
> Subject: [Mesa-dev] [PATCH v2] swr: fix memory leaks from vs/fs
> compilation
> 
> v2: varient -> variant
> ---
>  src/gallium/drivers/swr/swr_shader.cpp | 41 --
> 
>  src/gallium/drivers/swr/swr_state.cpp  |  6 ++---
>  src/gallium/drivers/swr/swr_state.h| 17 --
>  3 files changed, 41 insertions(+), 23 deletions(-)
> 
> diff --git a/src/gallium/drivers/swr/swr_shader.cpp
> b/src/gallium/drivers/swr/swr_shader.cpp
> index 83e3216..f693f51 100644
> --- a/src/gallium/drivers/swr/swr_shader.cpp
> +++ b/src/gallium/drivers/swr/swr_shader.cpp
> @@ -124,12 +124,19 @@ swr_generate_vs_key(struct swr_jit_vs_key ,
> }
> 
>  struct BuilderSWR : public Builder {
> -   BuilderSWR(JitManager *pJitMgr)
> +   BuilderSWR(JitManager *pJitMgr, const char *pName)
>: Builder(pJitMgr)
> {
>pJitMgr->SetupNewModule();
> +  gallivm = gallivm_create(pName, wrap(()->mContext));
> +  pJitMgr->mpCurrentModule = unwrap(gallivm->module);
> }
> 
> +   ~BuilderSWR() {
> +  gallivm_free_ir(gallivm);
> +   }
> +
> +   struct gallivm_state *gallivm;
> PFN_VERTEX_FUNC CompileVS(struct swr_context *ctx, swr_jit_vs_key
> );
> PFN_PIXEL_KERNEL CompileFS(struct swr_context *ctx, swr_jit_fs_key
> );  }; @@ -151,12 +158,6 @@ BuilderSWR::CompileVS(struct
> swr_context *ctx, swr_jit_vs_key )
>}
> }
> 
> -   //   tgsi_dump(swr_vs->pipe.tokens, 0);
> -
> -   struct gallivm_state *gallivm =
> -  gallivm_create("VS", wrap(()->mContext));
> -   gallivm->module = wrap(JM()->mpCurrentModule);
> -
> LLVMValueRef
> inputs[PIPE_MAX_SHADER_INPUTS][TGSI_NUM_CHANNELS];
> LLVMValueRef
> outputs[PIPE_MAX_SHADER_OUTPUTS][TGSI_NUM_CHANNELS];
> 
> @@ -231,6 +232,8 @@ BuilderSWR::CompileVS(struct swr_context *ctx,
> swr_jit_vs_key )
>   _vs->info.base,
>   NULL); // geometry shader face
> 
> +   sampler->destroy(sampler);
> +
> IRB()->SetInsertPoint(unwrap(LLVMGetInsertBlock(gallivm->builder)));
> 
> Value *vtxOutput = LOAD(pVsCtx, {0, SWR_VS_CONTEXT_pVout}); @@ -
> 273,8 +276,12 @@ PFN_VERTEX_FUNC  swr_compile_vs(struct swr_context
> *ctx, swr_jit_vs_key )  {
> BuilderSWR builder(
> -  reinterpret_cast(swr_screen(ctx->pipe.screen)-
> >hJitMgr));
> -   return builder.CompileVS(ctx, key);
> +  reinterpret_cast(swr_screen(ctx->pipe.screen)-
> >hJitMgr),
> +  "VS");
> +   PFN_VERTEX_FUNC func = builder.CompileVS(ctx, key);
> +
> +   ctx->vs->map.insert(std::make_pair(key,
> make_unique(builder.gallivm, func)));
> +   return func;
>  }
> 
>  static unsigned
> @@ -304,12 +311,6 @@ BuilderSWR::CompileFS(struct swr_context *ctx,
> swr_jit_fs_key )  {
> struct swr_fragment_shader *swr_fs = ctx->fs;
> 
> -   //   tgsi_dump(swr_fs->pipe.tokens, 0);
> -
> -   struct gallivm_state *gallivm =
> -  gallivm_create("FS", wrap(()->mContext));
> -   gallivm->module = wrap(JM()->mpCurrentModule);
> -
> LLVMValueRef
> inputs[PIPE_MAX_SHADER_INPUTS][TGSI_NUM_CHANNELS];
> LLVMValueRef
> outputs[PIPE_MAX_SHADER_OUTPUTS][TGSI_NUM_CHANNELS];
> 
> @@ -540,6 +541,8 @@ BuilderSWR::CompileFS(struct swr_context *ctx,
> swr_jit_fs_key )
>   _fs->info.base,
>   NULL); // geometry shader face
> 
> +   sampler->destroy(sampler);
> +
> IRB()->SetInsertPoint(unwrap(LLVMGetInsertBlock(gallivm->builder)));
> 
> for (uint32_t attrib = 0; attrib < swr_fs->info.base.num_outputs; @@ -
> 620,6 +623,10 @@ PFN_PIXEL_KERNEL  swr_compile_fs(struct swr_context
> *ctx, swr_jit_fs_key )  {
> BuilderSWR builder(
> -  reinterpret_cast(swr_screen(ctx->pipe.screen)-
> >hJitMgr));
> -   return builder.CompileFS(ctx, key);
> +  reinterpret_cast(swr_screen(ctx->pipe.screen)-
> >hJitMgr),
> +  "FS");
> +   PFN_PIXEL_KERNEL func = builder.CompileFS(ctx, key);
> +
> +   ctx->fs->map.insert(std::make_pair(key,
> make_unique(builder.gallivm, func)));
> +   return func;
>  }
> diff --git a/src/gallium/drivers/swr/swr_state.cpp
> b/src/gallium/drivers/swr/swr_state.cpp
> index 4ce2d12..18c4fb2 100644
> --- a/src/gallium/drivers/swr/swr_state.cpp
> +++ b/src/gallium/drivers/swr/swr_state.cpp
> @@ -1030,10 +1030,9 @@ swr_update_derived(struct pipe_context *pipe,
>auto search = ctx->vs->map.find(key);
>PFN_VERTEX_FUNC func;
>if (search != ctx->vs->map.end()) {
> - func = search->second;
> + func = search->second->shader;
>} else {
>   func = swr_compile_vs(ctx, key);
> - ctx->vs->map.insert(std::make_pair(key, func));
>}
>SwrSetVertexFunc(ctx->swrContext, func);
> 
> @@ -1062,10 +1061,9 @@ swr_update_derived(struct pipe_context *pipe,
>

Re: [Mesa-dev] [PATCH] swr: support samplers in vertex shaders

[Kyriazis, George]

Reviewed-by: George Kyriazis 

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf
> Of Tim Rowley
> Sent: Friday, April 1, 2016 8:03 PM
> To: mesa-dev@lists.freedesktop.org
> Subject: [Mesa-dev] [PATCH] swr: support samplers in vertex shaders
> 
> ---
>  src/gallium/drivers/swr/swr_shader.cpp |  98 +++---
>  src/gallium/drivers/swr/swr_shader.h   |  41 +---
>  src/gallium/drivers/swr/swr_state.cpp  | 153 
> +++--
>  src/gallium/drivers/swr/swr_state.h|   6 +-
>  src/gallium/drivers/swr/swr_tex_sample.cpp |  33 ++-
>  src/gallium/drivers/swr/swr_tex_sample.h   |   2 +-
>  6 files changed, 228 insertions(+), 105 deletions(-)
> 
> diff --git a/src/gallium/drivers/swr/swr_shader.cpp
> b/src/gallium/drivers/swr/swr_shader.cpp
> index ff16d0f..90f0f22 100644
> --- a/src/gallium/drivers/swr/swr_shader.cpp
> +++ b/src/gallium/drivers/swr/swr_shader.cpp
> @@ -40,32 +40,29 @@
>  #include "swr_state.h"
>  #include "swr_screen.h"
> 
> -bool operator==(const swr_jit_key , const swr_jit_key )
> +bool operator==(const swr_jit_fs_key , const swr_jit_fs_key )
>  {
> return !memcmp(, , sizeof(lhs));  }
> 
> -void
> -swr_generate_fs_key(struct swr_jit_key ,
> -struct swr_context *ctx,
> -swr_fragment_shader *swr_fs)
> +bool operator==(const swr_jit_vs_key , const swr_jit_vs_key )
>  {
> -   key.nr_cbufs = ctx->framebuffer.nr_cbufs;
> -   key.light_twoside = ctx->rasterizer->light_twoside;
> -   memcpy(_output_semantic_name,
> -  >vs->info.base.output_semantic_name,
> -  sizeof(key.vs_output_semantic_name));
> -   memcpy(_output_semantic_idx,
> -  >vs->info.base.output_semantic_index,
> -  sizeof(key.vs_output_semantic_idx));
> +   return !memcmp(, , sizeof(lhs)); }
> 
> -   key.nr_samplers = swr_fs->info.base.file_max[TGSI_FILE_SAMPLER] + 1;
> +static void
> +swr_generate_sampler_key(const struct lp_tgsi_info ,
> + struct swr_context *ctx,
> + unsigned shader_type,
> + struct swr_jit_sampler_key ) {
> +   key.nr_samplers = info.base.file_max[TGSI_FILE_SAMPLER] + 1;
> 
> for (unsigned i = 0; i < key.nr_samplers; i++) {
> -  if (swr_fs->info.base.file_mask[TGSI_FILE_SAMPLER] & (1 << i)) {
> +  if (info.base.file_mask[TGSI_FILE_SAMPLER] & (1 << i)) {
>   lp_sampler_static_sampler_state(
>  [i].sampler_state,
> -ctx->samplers[PIPE_SHADER_FRAGMENT][i]);
> +ctx->samplers[shader_type][i]);
>}
> }
> 
> @@ -74,28 +71,57 @@ swr_generate_fs_key(struct swr_jit_key ,
>  * are dx10-style? Can't really have mixed opcodes, at least not
>  * if we want to skip the holes here (without rescanning tgsi).
>  */
> -   if (swr_fs->info.base.file_max[TGSI_FILE_SAMPLER_VIEW] != -1) {
> +   if (info.base.file_max[TGSI_FILE_SAMPLER_VIEW] != -1) {
>key.nr_sampler_views =
> - swr_fs->info.base.file_max[TGSI_FILE_SAMPLER_VIEW] + 1;
> + info.base.file_max[TGSI_FILE_SAMPLER_VIEW] + 1;
>for (unsigned i = 0; i < key.nr_sampler_views; i++) {
> - if (swr_fs->info.base.file_mask[TGSI_FILE_SAMPLER_VIEW] & (1 << i)) 
> {
> + if (info.base.file_mask[TGSI_FILE_SAMPLER_VIEW] & (1 << i)) {
>  lp_sampler_static_texture_state(
> [i].texture_state,
> -   ctx->sampler_views[PIPE_SHADER_FRAGMENT][i]);
> +   ctx->sampler_views[shader_type][i]);
>   }
>}
> } else {
>key.nr_sampler_views = key.nr_samplers;
>for (unsigned i = 0; i < key.nr_sampler_views; i++) {
> - if (swr_fs->info.base.file_mask[TGSI_FILE_SAMPLER] & (1 << i)) {
> + if (info.base.file_mask[TGSI_FILE_SAMPLER] & (1 << i)) {
>  lp_sampler_static_texture_state(
> [i].texture_state,
> -   ctx->sampler_views[PIPE_SHADER_FRAGMENT][i]);
> +   ctx->sampler_views[shader_type][i]);
>   }
>}
> }
>  }
> 
> +void
> +swr_generate_fs_key(struct swr_jit_fs_key ,
> +struct swr_context *ctx,
> +swr_fragment_shader *swr_fs) {
> +   memset(, 0, sizeof(key));
> +
> +   key.nr_cbufs = ctx->framebuffer.nr_cbufs;
> +   key.light_twoside = ctx->rasterizer->light_twoside;
> +   memcpy(_output_semantic_name,
> +  >vs->info.base.output_semantic_name,
> +  sizeof(key.vs_output_semantic_name));
> +   memcpy(_output_semantic_idx,
> +  >vs->info.base.output_semantic_index,
> +  sizeof(key.vs_output_semantic_idx));
> +
> +   swr_generate_sampler_key(swr_fs->info, ctx, PIPE_SHADER_FRAGMENT,
> +key); }
> +
> +void
> +swr_generate_vs_key(struct swr_jit_vs_key ,
> +struct swr_context *ctx,
> +swr_vertex_shader *swr_vs) {
> +   memset(, 0, 

Re: [Mesa-dev] [PATCH] swr: handle pci cap requests

[Kyriazis, George]

Reviewed-by: George Kyriazis 

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf
> Of Tim Rowley
> Sent: Friday, April 1, 2016 8:03 PM
> To: mesa-dev@lists.freedesktop.org
> Subject: [Mesa-dev] [PATCH] swr: handle pci cap requests
> 
> ---
>  src/gallium/drivers/swr/swr_screen.cpp | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/gallium/drivers/swr/swr_screen.cpp
> b/src/gallium/drivers/swr/swr_screen.cpp
> index f9e52be..4a4992f 100644
> --- a/src/gallium/drivers/swr/swr_screen.cpp
> +++ b/src/gallium/drivers/swr/swr_screen.cpp
> @@ -337,6 +337,10 @@ swr_get_param(struct pipe_screen *screen, enum
> pipe_cap param)
> case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
> case PIPE_CAP_QUERY_BUFFER_OBJECT:
> case PIPE_CAP_QUERY_MEMORY_INFO:
> +   case PIPE_CAP_PCI_GROUP:
> +   case PIPE_CAP_PCI_BUS:
> +   case PIPE_CAP_PCI_DEVICE:
> +   case PIPE_CAP_PCI_FUNCTION:
>return 0;
> }
> 
> --
> 1.9.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/swr: Resource management

[Kyriazis, George]

Reviewed-By: George Kyriazis

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of BruceCherniak
> Sent: Wednesday, March 9, 2016 7:30 PM
> To: mesa-dev@lists.freedesktop.org
> Subject: [Mesa-dev] [PATCH] gallium/swr: Resource management
> 
> From: Bruce Cherniak 
> 
> Better tracking of resource state and synchronization.
> A follow on commit will clean up resource functions into a new
> swr_resource.cpp file.
> ---
>  src/gallium/drivers/swr/swr_clear.cpp   |4 +-
>  src/gallium/drivers/swr/swr_context.cpp |  103 --
> -
>  src/gallium/drivers/swr/swr_draw.cpp|   64 +--
>  src/gallium/drivers/swr/swr_fence.cpp   |   29 ++---
>  src/gallium/drivers/swr/swr_fence.h |6 +-
>  src/gallium/drivers/swr/swr_query.cpp   |6 +-
>  src/gallium/drivers/swr/swr_resource.h  |   54 +++-
>  src/gallium/drivers/swr/swr_screen.cpp  |   57 -
>  src/gallium/drivers/swr/swr_state.cpp   |   83 ++---
>  src/gallium/drivers/swr/swr_state.h |2 +-
>  10 files changed, 265 insertions(+), 143 deletions(-)
> 
> diff --git a/src/gallium/drivers/swr/swr_clear.cpp
> b/src/gallium/drivers/swr/swr_clear.cpp
> index 9027f84..103bca9 100644
> --- a/src/gallium/drivers/swr/swr_clear.cpp
> +++ b/src/gallium/drivers/swr/swr_clear.cpp
> @@ -40,7 +40,7 @@ swr_clear(struct pipe_context *pipe,
>return;
> 
> if (ctx->dirty)
> -  swr_update_derived(ctx);
> +  swr_update_derived(pipe);
> 
>  /* Update clearMask/targetMask */
>  #if 0 /* XXX SWR currently only clears SWR_ATTACHMENT_COLOR0, don't
> bother   \
> @@ -76,7 +76,7 @@ swr_clear(struct pipe_context *pipe,
> vp.height = ctx->framebuffer.height;
> SwrSetViewports(ctx->swrContext, 1, , NULL);
> 
> - swr_update_draw_context(ctx);
> +   swr_update_draw_context(ctx);
> SwrClearRenderTarget(ctx->swrContext, clearMask, color->f, depth,
> stencil);  }
> 
> diff --git a/src/gallium/drivers/swr/swr_context.cpp
> b/src/gallium/drivers/swr/swr_context.cpp
> index 0e7ebb7..c8cb145 100644
> --- a/src/gallium/drivers/swr/swr_context.cpp
> +++ b/src/gallium/drivers/swr/swr_context.cpp
> @@ -36,6 +36,7 @@ extern "C" {
>  #include "swr_resource.h"
>  #include "swr_scratch.h"
>  #include "swr_query.h"
> +#include "swr_fence.h"
> 
>  #include "api.h"
>  #include "backend.h"
> @@ -85,36 +86,10 @@ swr_surface_destroy(struct pipe_context *pipe,
> struct pipe_surface *surf)
> assert(surf->texture);
> struct pipe_resource *resource = surf->texture;
> 
> -   /* If the surface being destroyed is a current render target,
> -* call StoreTiles to resolve the hotTile state then set attachment
> -* to NULL.
> -*/
> -   if (resource->bind & (PIPE_BIND_RENDER_TARGET |
> PIPE_BIND_DEPTH_STENCIL
> - | PIPE_BIND_DISPLAY_TARGET)) {
> -  struct swr_context *ctx = swr_context(pipe);
> -  struct swr_resource *spr = swr_resource(resource);
> - swr_draw_context *pDC = >swrDC;
> - SWR_SURFACE_STATE *renderTargets = pDC->renderTargets;
> -  for (uint32_t i = 0; i < SWR_NUM_ATTACHMENTS; i++)
> - if (renderTargets[i].pBaseAddress == spr->swr.pBaseAddress) {
> -swr_store_render_target(ctx, i, SWR_TILE_RESOLVED);
> -
> -/*
> - * Mesa thinks depth/stencil are fused, so we'll never get an
> - * explicit resource for stencil.  So, if checking depth, then
> - * also check for stencil.
> - */
> -if (spr->has_stencil && (i == SWR_ATTACHMENT_DEPTH)) {
> -   swr_store_render_target(
> -  ctx, SWR_ATTACHMENT_STENCIL, SWR_TILE_RESOLVED);
> -}
> -
> -SwrWaitForIdle(ctx->swrContext);
> -break;
> - }
> -   }
> +   /* If the resource has been drawn to, store tiles. */
> +   swr_store_dirty_resource(pipe, resource, SWR_TILE_RESOLVED);
> 
> -   pipe_resource_reference(>texture, NULL);
> +   pipe_resource_reference(, NULL);
> FREE(surf);
>  }
> 
> @@ -127,6 +102,7 @@ swr_transfer_map(struct pipe_context *pipe,
>   const struct pipe_box *box,
>   struct pipe_transfer **transfer)  {
> +   struct swr_screen *screen = swr_screen(pipe->screen);
> struct swr_resource *spr = swr_resource(resource);
> struct pipe_transfer *pt;
> enum pipe_format format = resource->format; @@ -134,30 +110,28 @@
> swr_transfer_map(struct pipe_context *pipe,
> assert(resource);
> assert(level <= resource->last_level);
> 
> -   /*
> -* If mapping any attached rendertarget, store tiles and wait for idle
> -* before giving CPU access to the surface.
> -* (set postStoreTileState to SWR_TILE_INVALID so tiles are reloaded)
> -*/
> -   if (resource->bind & (PIPE_BIND_RENDER_TARGET |
> PIPE_BIND_DEPTH_STENCIL
> - | 

Re: [Mesa-dev] [PATCH v3 2/2] Hang off screen destructor off main XCloseDisplay() callback.

[Kyriazis, George]

Brian,

Thanks!  Based on my last email, the code that destroys the screen I think 
should be removed.  I can either send out an updated patch, or check it in 
through Tim Rowley (since he just got his write privileges).

Thank you!

George

> -Original Message-
> From: Brian Paul [mailto:bri...@vmware.com]
> Sent: Thursday, March 3, 2016 11:32 AM
> To: Kyriazis, George <george.kyria...@intel.com>; mesa-
> d...@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH v3 2/2] Hang off screen destructor off main
> XCloseDisplay() callback.
> 
> On 03/02/2016 06:28 PM, George Kyriazis wrote:
> > This resolves some order dependencies between the already existing
> > callback the newly created one.
> > ---
> >   src/gallium/state_trackers/glx/xlib/glx_api.c |  1 +
> >   src/gallium/state_trackers/glx/xlib/xm_api.c  | 58 
> > +++--
> --
> >   src/gallium/state_trackers/glx/xlib/xm_api.h  |  3 ++
> >   3 files changed, 27 insertions(+), 35 deletions(-)
> >
> > diff --git a/src/gallium/state_trackers/glx/xlib/glx_api.c
> > b/src/gallium/state_trackers/glx/xlib/glx_api.c
> > index 0456d44..1c541b7 100644
> > --- a/src/gallium/state_trackers/glx/xlib/glx_api.c
> > +++ b/src/gallium/state_trackers/glx/xlib/glx_api.c
> > @@ -615,6 +615,7 @@ close_display_callback(Display *dpy, XExtCodes
> *codes)
> >   {
> >  xmesa_destroy_buffers_on_display(dpy);
> >  destroy_visuals_on_display(dpy);
> > +   xmesa_close_display(dpy);
> >  return 0;
> >   }
> >
> > diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.c
> > b/src/gallium/state_trackers/glx/xlib/xm_api.c
> > index 2f1bfae..cee4f18 100644
> > --- a/src/gallium/state_trackers/glx/xlib/xm_api.c
> > +++ b/src/gallium/state_trackers/glx/xlib/xm_api.c
> > @@ -126,7 +126,6 @@ xmesa_get_param(struct st_manager *smapi,
> >   typedef struct _XMesaExtDisplayInfo {
> >  struct _XMesaExtDisplayInfo *next;
> >  Display *display;
> > -   XExtCodes *codes;
> >  struct xmesa_display mesaDisplay;
> >   } XMesaExtDisplayInfo;
> >
> > @@ -138,8 +137,8 @@ typedef struct _XMesaExtInfo {
> >   static XMesaExtInfo MesaExtInfo;
> >
> >   /* hook to delete XMesaDisplay on XDestroyDisplay */ -static int
> > -xmesa_close_display(Display *display, XExtCodes *codes)
> > +extern void
> > +xmesa_close_display(Display *display)
> >   {
> >  XMesaExtDisplayInfo *info, *prev;
> >
> > @@ -159,7 +158,7 @@ xmesa_close_display(Display *display, XExtCodes
> *codes)
> >  if (info == NULL) {
> > /* no display found */
> > _XUnlockMutex(_Xglobal_lock);
> > -  return 0;
> > +  return;
> >  }
> >
> >  /* remove display entry from list */ @@ -181,7 +180,6 @@
> > xmesa_close_display(Display *display, XExtCodes *codes)
> >  free(xmdpy->smapi);
> >
> >  XFree((char *) info);
> > -   return 1;
> >   }
> >
> >   static XMesaDisplay
> > @@ -218,14 +216,6 @@ xmesa_init_display( Display *display )
> > return NULL;
> >  }
> >  info->display = display;
> > -   info->codes = XAddExtension(display);
> > -   if (info->codes == NULL) {
> > -  /* could not allocate extension.  Fail */
> > -  Xfree(info);
> > -  pipe_mutex_unlock(init_mutex);
> > -  return NULL;
> > -   }
> > -   XESetCloseDisplay(display, info->codes->extension,
> xmesa_close_display);
> >  xmdpy = >mesaDisplay; /* to be filled out below */
> >
> >  /* chain to the list of displays */ @@ -236,32 +226,30 @@
> > xmesa_init_display( Display *display )
> >  _XUnlockMutex(_Xglobal_lock);
> >
> >  /* now create the new XMesaDisplay info */
> > -   if (display) {
> > -  xmdpy->display = display;
> > -  xmdpy->screen = driver.create_pipe_screen(display);
> > -  xmdpy->smapi = CALLOC_STRUCT(st_manager);
> > -  xmdpy->pipe = NULL;
> > -  if (xmdpy->smapi) {
> > - xmdpy->smapi->screen = xmdpy->screen;
> > - xmdpy->smapi->get_param = xmesa_get_param;
> > -  }
> > +   assert(display);
> > +
> > +   xmdpy->display = display;
> > +   xmdpy->screen = driver.create_pipe_screen(display);
> > +   xmdpy->smapi = CALLOC_STRUCT(st_manager);
> > +   xmdpy->pipe = NULL;
> > +   if (xmdpy->smapi) {
> > +  xmdpy->smapi->screen = xmdpy->screen;
> > +  xmdpy->smapi-&g

Re: [Mesa-dev] [PATCH v2] Support unlimited number of display connections

[Kyriazis, George]

One way to solve this is to avoid deleting the screen at the end of 
xmesa_close_display().  This ends up being not worse than the original code, 
however we get the benefit of unlimited connections.

Thanks,

George

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Kyriazis, George
> Sent: Wednesday, March 2, 2016 7:03 PM
> To: Brian Paul <bri...@vmware.com>; mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH v2] Support unlimited number of display
> connections
> 
> I am re-sending an updated patch that fixes this stomping, however, there is
> an additional issue that is exposed in programs that use multiple windows
> (for example manywin).  The issue is that resources are shared between
> contexts, so when we destroy context 2, it tries to free resources that 
> already
> freed by destroying screen 1.
> 
> I think what needs to happen is that these resources should have a refcount.
> 
> Thanks,
> 
> George
> 
> 
> > -Original Message-
> > From: Brian Paul [mailto:bri...@vmware.com]
> > Sent: Wednesday, March 2, 2016 11:45 AM
> > To: Kyriazis, George <george.kyria...@intel.com>; mesa-
> > d...@lists.freedesktop.org
> > Subject: Re: [Mesa-dev] [PATCH v2] Support unlimited number of display
> > connections
> >
> > On 03/02/2016 10:33 AM, Kyriazis, George wrote:
> > > Brian,
> > >
> > > I looked for a trivial/tri test in the mesa repo and I only found
> > > the
> > gallium/trivial/tri test.  This one I found is loading the device
> > pipes directly and is not using glx so it's not affected by my change.
> > It shows some valgrind memory leaks upon exit regardless of my change.
> > >
> > > Or maybe are you talking about a different  test?
> >
> > Yeah, check out the mesa demos tree at
> > git.freedesktop.org/git/mesa/demos
> >
> >
> > -Brian
> >
> >
> > > Thank you,
> > >
> > > George
> > >
> > >> -Original Message-
> > >> From: Brian Paul [mailto:bri...@vmware.com]
> > >> Sent: Tuesday, March 1, 2016 8:45 PM
> > >> To: Kyriazis, George <george.kyria...@intel.com>; mesa-
> > >> d...@lists.freedesktop.org
> > >> Subject: Re: [Mesa-dev] [PATCH v2] Support unlimited number of
> > >> display connections
> > >>
> > >> Hmm, I applied your patch locally and ran the trivial/tri demo and
> > >> saw a few valgrind errors upon exit (invalid memory reads).  Can
> > >> you look
> > into that?
> > >>
> > >> -Brian
> > >>
> > >> On 03/01/2016 07:20 PM, Kyriazis, George wrote:
> > >>> Thanks Brian,
> > >>>
> > >>> Since I don't have git write privileges, can somebody check this in for
> me?
> > >>>
> > >>> I am working with Tim Rowley @ Intel for the openswr driver.
> > >>>
> > >>> George
> > >>>
> > >>>> -Original Message-
> > >>>> From: Brian Paul [mailto:bri...@vmware.com]
> > >>>> Sent: Tuesday, March 1, 2016 6:55 PM
> > >>>> To: Kyriazis, George <george.kyria...@intel.com>; mesa-
> > >>>> d...@lists.freedesktop.org
> > >>>> Subject: Re: [Mesa-dev] [PATCH v2] Support unlimited number of
> > >>>> display connections
> > >>>>
> > >>>> On 03/01/2016 05:44 PM, George Kyriazis wrote:
> > >>>>> There is a limit of 10 display connections, which was a problem
> > >>>>> for apps/tests that were continuously opening/closing display
> > >>>>> connections.
> > >>>>>
> > >>>>> This fix uses XAddExtension() and XESetCloseDisplay() to keep
> > >>>>> track of the status of the display connections from the X
> > >>>>> server, freeing mesa-related data as X displays get destroyed by the
> X server.
> > >>>>>
> > >>>>> Poster child is the VTK "TimingTests"
> > >>>>>
> > >>>>> v2: Added missing initializer in struct
> > >>>>>
> > >>>>> ---
> > >>>>> src/gallium/state_trackers/glx/xlib/xm_api.c | 122
> > >>>> ++-
> > >>>>> 1 file changed, 103 insertions(+), 19 deletions(-)
> > >>>>>
> > &g