Re: [Mesa-dev] [PATCH 1/2] util: try to fix the Android build

[Tapani Pälli]

On 09/10/2018 08:02 AM, Tapani Pälli wrote:

Thanks Marek, this fixes the build.


(and reason for breakage was that bionic does not have 
pthread_setaffinity_np)



Reviewed-by: Tapani Pälli 

On 09/09/2018 04:02 AM, Marek Olšák wrote:

From: Marek Olšák 

---
  src/util/u_thread.h | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/util/u_thread.h b/src/util/u_thread.h
index ec0d9a7..0c20ebb 100644
--- a/src/util/u_thread.h
+++ b/src/util/u_thread.h
@@ -29,20 +29,23 @@
  #include 
  #include 
  #include "c11/threads.h"
  #ifdef HAVE_PTHREAD
  #include 
  #endif
+#if defined(HAVE_PTHREAD) && !defined(ANDROID)
+#define HAVE_PTHREAD_SETAFFINITY
+#endif
  static inline thrd_t u_thread_create(int (*routine)(void *), void 
*param)

  {
 thrd_t thread;
  #ifdef HAVE_PTHREAD
 sigset_t saved_set, new_set;
 int ret;
 sigfillset(_set);
 pthread_sigmask(SIG_SETMASK, _set, _set);
@@ -76,41 +79,41 @@ static inline void u_thread_setname( const char 
*name )
   * is very expensive. It's desirable to pin a group of closely 
cooperating

   * threads to one group of cores sharing L3.
   *
   * \param thread    thread
   * \param L3_index  index of the L3 cache
   * \param cores_per_L3  number of CPU cores shared by one L3
   */
  static inline void
  util_pin_thread_to_L3(thrd_t thread, unsigned L3_index, unsigned 
cores_per_L3)

  {
-#if defined(HAVE_PTHREAD)
+#if defined(HAVE_PTHREAD_SETAFFINITY)
 cpu_set_t cpuset;
 CPU_ZERO();
 for (unsigned i = 0; i < cores_per_L3; i++)
    CPU_SET(L3_index * cores_per_L3 + i, );
 pthread_setaffinity_np(thread, sizeof(cpuset), );
  #endif
  }
  /**
   * Return the index of L3 that the thread is pinned to. If the 
thread is

   * pinned to multiple L3 caches, return -1.
   *
   * \param thread    thread
   * \param cores_per_L3  number of CPU cores shared by one L3
   */
  static inline int
  util_get_L3_for_pinned_thread(thrd_t thread, unsigned cores_per_L3)
  {
-#if defined(HAVE_PTHREAD)
+#if defined(HAVE_PTHREAD_SETAFFINITY)
 cpu_set_t cpuset;
 if (pthread_getaffinity_np(thread, sizeof(cpuset), ) == 0) {
    int L3_index = -1;
    for (unsigned i = 0; i < CPU_SETSIZE; i++) {
   if (CPU_ISSET(i, )) {
  int x = i / cores_per_L3;
  if (L3_index != x) {


___
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 1/2] util: try to fix the Android build

[Tapani Pälli]

Thanks Marek, this fixes the build.

Reviewed-by: Tapani Pälli 

On 09/09/2018 04:02 AM, Marek Olšák wrote:

From: Marek Olšák 

---
  src/util/u_thread.h | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/util/u_thread.h b/src/util/u_thread.h
index ec0d9a7..0c20ebb 100644
--- a/src/util/u_thread.h
+++ b/src/util/u_thread.h
@@ -29,20 +29,23 @@
  
  #include 

  #include 
  
  #include "c11/threads.h"
  
  #ifdef HAVE_PTHREAD

  #include 
  #endif
  
+#if defined(HAVE_PTHREAD) && !defined(ANDROID)

+#define HAVE_PTHREAD_SETAFFINITY
+#endif
  
  static inline thrd_t u_thread_create(int (*routine)(void *), void *param)

  {
 thrd_t thread;
  #ifdef HAVE_PTHREAD
 sigset_t saved_set, new_set;
 int ret;
  
 sigfillset(_set);

 pthread_sigmask(SIG_SETMASK, _set, _set);
@@ -76,41 +79,41 @@ static inline void u_thread_setname( const char *name )
   * is very expensive. It's desirable to pin a group of closely cooperating
   * threads to one group of cores sharing L3.
   *
   * \param threadthread
   * \param L3_index  index of the L3 cache
   * \param cores_per_L3  number of CPU cores shared by one L3
   */
  static inline void
  util_pin_thread_to_L3(thrd_t thread, unsigned L3_index, unsigned cores_per_L3)
  {
-#if defined(HAVE_PTHREAD)
+#if defined(HAVE_PTHREAD_SETAFFINITY)
 cpu_set_t cpuset;
  
 CPU_ZERO();

 for (unsigned i = 0; i < cores_per_L3; i++)
CPU_SET(L3_index * cores_per_L3 + i, );
 pthread_setaffinity_np(thread, sizeof(cpuset), );
  #endif
  }
  
  /**

   * Return the index of L3 that the thread is pinned to. If the thread is
   * pinned to multiple L3 caches, return -1.
   *
   * \param threadthread
   * \param cores_per_L3  number of CPU cores shared by one L3
   */
  static inline int
  util_get_L3_for_pinned_thread(thrd_t thread, unsigned cores_per_L3)
  {
-#if defined(HAVE_PTHREAD)
+#if defined(HAVE_PTHREAD_SETAFFINITY)
 cpu_set_t cpuset;
  
 if (pthread_getaffinity_np(thread, sizeof(cpuset), ) == 0) {

int L3_index = -1;
  
for (unsigned i = 0; i < CPU_SETSIZE; i++) {

   if (CPU_ISSET(i, )) {
  int x = i / cores_per_L3;
  
  if (L3_index != x) {



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

[Mesa-dev] [AppVeyor] mesa master #8841 failed

[AppVeyor]

Build mesa 8841 failed


Commit 240af61494 by Dave Airlie on 8/28/2018 10:32 PM:

virgl: don't send a shader create with no data. (v2)\n\nThis fixes the situation where we'd send a shader with just the\nheader and no data.\n\npiglit/glsl-max-varyings test was causing this to happen, and\nthe renderer fix was breaking it.\n\nv2: drop fprintf\n\nFixes: a8987b88ff1d "virgl: add driver for virtio-gpu 3D (v2)"\nReviewed-by: Erik Faye-Lund 


Configure your notification preferences

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

[Mesa-dev] [Bug 107878] Artifacting Hair on Overwatch vega56

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107878

Bug ID: 107878
   Summary: Artifacting Hair on Overwatch vega56
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: coolo...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Hair of most characters in overwatch has blocky artefacts on latest mesa-git
(18.3) and llvm-svn (8)

This is using dxvk and wine-staging with sync and gallium nine patches.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Validate the result of pipe_transfer_map in make_texture

[Josh Pieper]

And apparently I am incapable of operating git send-email, so it
failed to include my context:

When using Freecad, I was getting intermittent segfaults inside of
mesa.  I traced it down to this path in st_cb_drawpixels.c where the
result of pipe_transfer_map wasn't being checked.  In my case, it was
returning NULL because nouveau_bo_new returned ENOENT.  I'm by no
means a mesa developer, but this patch solves the problem for me and
seems reasonable enough.

Thanks!
-Josh

Josh Pieper wrote:
> ---
>  src/mesa/state_tracker/st_cb_drawpixels.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c 
> b/src/mesa/state_tracker/st_cb_drawpixels.c
> index cb50b7104a..8d39b8a01b 100644
> --- a/src/mesa/state_tracker/st_cb_drawpixels.c
> +++ b/src/mesa/state_tracker/st_cb_drawpixels.c
> @@ -566,6 +566,9 @@ make_texture(struct st_context *st,
>dest = pipe_transfer_map(pipe, pt, 0, 0,
> PIPE_TRANSFER_WRITE, 0, 0,
> width, height, );
> +  if (!dest) {
> + return NULL;
> +  }
>
>
>/* Put image into texture transfer.
> --
> 2.17.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: Validate the result of pipe_transfer_map in make_texture

[Josh Pieper]

---
 src/mesa/state_tracker/st_cb_drawpixels.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c 
b/src/mesa/state_tracker/st_cb_drawpixels.c
index cb50b7104a..8d39b8a01b 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -566,6 +566,9 @@ make_texture(struct st_context *st,
   dest = pipe_transfer_map(pipe, pt, 0, 0,
PIPE_TRANSFER_WRITE, 0, 0,
width, height, );
+  if (!dest) {
+ return NULL;
+  }
 
 
   /* Put image into texture transfer.
-- 
2.17.1

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

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

[Timothy Arceri]

On 10/09/18 11:01, Matt Turner wrote:

On Sun, Sep 9, 2018 at 5:00 PM Timothy Arceri  wrote:

On 10/09/18 09:52, Matt Turner wrote:

On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri  wrote:


On 10/09/18 09:22, Ian Romanick wrote:

On 09/08/2018 06:37 AM, Jason Ekstrand wrote:

Is there going to be an accompanying series on the piglit list?  I don't
see anything there immediately.


Which is one of the major reasons we decided we'd never implement this
extension in Mesa.  To test it to the quality levels that we expect, it
would literally take 1,000+ test cases.


As I said in the other thread refusing to implement this extension is
only going to hurt Mesa users and continue the "just use Nvidia if you
want things to work narrative". AMD have also indicated they would be
adding support for this extension in radeonsi. I'm willing to write
tests if they are not up to your quality levels the feel free not to
enable the extension in your driver.


There are so many things wrong with the last statement.



Can you be more specific?


The suggestion that if *common* *core* code isn't good enough we can
just not turn on the extension in our driver is offensively
shortsighted.


This is not at all what I was implying please see my other replies.



We're all working on a hugely important and successful free software
project. One area where it gets its strength is from people from
different companies, countries, interests, backgrounds, etc working
together. That common code saves huge amounts of work for others who
turn the feature on later. I benefit if you add a feature that I
wanted to enable, and vice versa.

But if a feature is implemented in a not so great way or without
sufficient tests, then it might not actually save future developers
time because they'll trip over the sharp edges left behind. Maybe
we'll decide it was actually a bad idea to implement it in the first
place. My point is that there's a (potentially great) cost involved
with supporting new functionality.

Intel really drove GL3+ feature development, and we were pretty
meticulous about getting the details right. Paul and Ken diff'd GL
specs to avoid another catastrophe like missing a one-character change
causing months of unplanned work (0 -> 4 samples required in GL 3.0).
We filed and got spec bugs fixed. People contributed GL CTS tests and
worked with others in Khronos. We probably could have cut some corners
and saved some time if our objective was simply to bump the GL version
number as fast as possible. But it wasn't -- it was to build the best
GL driver stack for i965 hardware and to do it in a way that would
enable others an easier bring up path. Again, because it's really
important to us that the work we do benefits the greater community.

I won't go into detail, but we would not still be working on Mesa
today if Mesa and the i965 driver was not very high quality.

My initial reaction to reading "feel free not to enable the extension
in your driver" is that that's not playing well with others.


Again see my last reply to Ian. This was meant in the same way as you 
don't have to enable compat profile in your driver. Ian was quite 
aggressive in his disapproval in his very first reply. As I said below 
after reading this my initial reaction was that no testing was going to 
be good enough for him to want to enable the extension for i965 to which 
he has pretty much agreed. I was never implying that I wouldn't write 
quality tests or code, I would have thought my actions over the past 6 
years would have spoken to this and to all the points you raised above.




I think it's evident that we can find a way forward based on past
experiences (compatibility profile is supported in Mesa!).



I don't really know what you are trying to say here. I continued what 
Marek's started while implemented a bunch of compat tests, just like 
every other feature we add. You guys just decided not to follow I'm I 
missing something?



There's a legitimate debate to have here, but not like this.


Ian made it pretty clear he didn't want a debate and had already made up
his mind.

"We decided years ago that we were not going to support this horrible,
underspecified steaming pile of an extension in Mesa.  I am not
interested in going back on that decision now or, frankly, ever."

All I'm saying is I'm willing to write tests but I get the feeling
nothing will be good enough when I'm greeted with statements like the
one above.


I agree, but at the same time I'm not sure that you're accurately
estimating the amount of work an appropriate test suite is.

I mean, it's a really bad extension. I have a feeling that you might
start agreeing with Ian when you take a closer look :)


Yes its a very big extension and I'm not intending to implement the 
entire extension at this point. The pieces I've implemented (besides the 
matrix stuff which I would also write tests for since its their) pretty 
much replicate the ARB extension except for if no object exists create 

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

[Timothy Arceri]

On 10/09/18 10:21, Timothy Arceri wrote:

On 10/09/18 10:00, Ian Romanick wrote:

On 09/09/2018 04:57 PM, Ian Romanick wrote:

On 09/09/2018 04:52 PM, Matt Turner wrote:
On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri 
 wrote:


On 10/09/18 09:22, Ian Romanick wrote:

On 09/08/2018 06:37 AM, Jason Ekstrand wrote:
Is there going to be an accompanying series on the piglit list?  
I don't

see anything there immediately.


Which is one of the major reasons we decided we'd never implement 
this
extension in Mesa.  To test it to the quality levels that we 
expect, it

would literally take 1,000+ test cases.


As I said in the other thread refusing to implement this extension is
only going to hurt Mesa users and continue the "just use Nvidia if you
want things to work narrative". AMD have also indicated they would be
adding support for this extension in radeonsi. I'm willing to write
tests if they are not up to your quality levels the feel free not to
enable the extension in your driver.


There are so many things wrong with the last statement.

There's a legitimate debate to have here, but not like this.


I'll ask the question I always ask in these situations: Has anyone
bothered talking to the developer?


The game is years old they are not going to rewrite it now just 
because

it doesn't run on Mesa drivers. The game doesn't even support Linux in
the first place.


Is it actually the game that EXT_dsa or WINE?


Further testing seems to show that Proton (which uses a slightly older 
versions of wine) doesn't seem to use the EXT_dsa functions where as 
wine staging does.


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

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

[Matt Turner]

On Sun, Sep 9, 2018 at 5:00 PM Timothy Arceri  wrote:
> On 10/09/18 09:52, Matt Turner wrote:
> > On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri  wrote:
> >>
> >> On 10/09/18 09:22, Ian Romanick wrote:
> >>> On 09/08/2018 06:37 AM, Jason Ekstrand wrote:
>  Is there going to be an accompanying series on the piglit list?  I don't
>  see anything there immediately.
> >>>
> >>> Which is one of the major reasons we decided we'd never implement this
> >>> extension in Mesa.  To test it to the quality levels that we expect, it
> >>> would literally take 1,000+ test cases.
> >>
> >> As I said in the other thread refusing to implement this extension is
> >> only going to hurt Mesa users and continue the "just use Nvidia if you
> >> want things to work narrative". AMD have also indicated they would be
> >> adding support for this extension in radeonsi. I'm willing to write
> >> tests if they are not up to your quality levels the feel free not to
> >> enable the extension in your driver.
> >
> > There are so many things wrong with the last statement.
> >
>
> Can you be more specific?

The suggestion that if *common* *core* code isn't good enough we can
just not turn on the extension in our driver is offensively
shortsighted.

We're all working on a hugely important and successful free software
project. One area where it gets its strength is from people from
different companies, countries, interests, backgrounds, etc working
together. That common code saves huge amounts of work for others who
turn the feature on later. I benefit if you add a feature that I
wanted to enable, and vice versa.

But if a feature is implemented in a not so great way or without
sufficient tests, then it might not actually save future developers
time because they'll trip over the sharp edges left behind. Maybe
we'll decide it was actually a bad idea to implement it in the first
place. My point is that there's a (potentially great) cost involved
with supporting new functionality.

Intel really drove GL3+ feature development, and we were pretty
meticulous about getting the details right. Paul and Ken diff'd GL
specs to avoid another catastrophe like missing a one-character change
causing months of unplanned work (0 -> 4 samples required in GL 3.0).
We filed and got spec bugs fixed. People contributed GL CTS tests and
worked with others in Khronos. We probably could have cut some corners
and saved some time if our objective was simply to bump the GL version
number as fast as possible. But it wasn't -- it was to build the best
GL driver stack for i965 hardware and to do it in a way that would
enable others an easier bring up path. Again, because it's really
important to us that the work we do benefits the greater community.

I won't go into detail, but we would not still be working on Mesa
today if Mesa and the i965 driver was not very high quality.

My initial reaction to reading "feel free not to enable the extension
in your driver" is that that's not playing well with others.

I think it's evident that we can find a way forward based on past
experiences (compatibility profile is supported in Mesa!).

> > There's a legitimate debate to have here, but not like this.
>
> Ian made it pretty clear he didn't want a debate and had already made up
> his mind.
>
> "We decided years ago that we were not going to support this horrible,
> underspecified steaming pile of an extension in Mesa.  I am not
> interested in going back on that decision now or, frankly, ever."
>
> All I'm saying is I'm willing to write tests but I get the feeling
> nothing will be good enough when I'm greeted with statements like the
> one above.

I agree, but at the same time I'm not sure that you're accurately
estimating the amount of work an appropriate test suite is.

I mean, it's a really bad extension. I have a feeling that you might
start agreeing with Ian when you take a closer look :)

And here's the thing, you sent patches to add this extension without
piglit tests. Were you hoping to commit this series without tests?
Without comments from Ian and Jason I fear that you would have gladly
pushed this.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

[Timothy Arceri]

On 10/09/18 10:40, Ian Romanick wrote:

On 09/09/2018 05:00 PM, Timothy Arceri wrote:

Ian made it pretty clear he didn't want a debate and had already made up
his mind.

"We decided years ago that we were not going to support this horrible,
underspecified steaming pile of an extension in Mesa.  I am not
interested in going back on that decision now or, frankly, ever."

All I'm saying is I'm willing to write tests but I get the feeling
nothing will be good enough when I'm greeted with statements like the
one above.


That's fair.  I have pretty well made up my mind about EXT_dsa.  I also
had my mind pretty well made up about compatibility profile and
EXT_gpu_shader4.  While I may have my own entrenched opinion, I'm not
the only decision maker.

That said, quality of implementation and quality of testing cannot be
debatable points.

When we started seriously working on getting modern OpenGL support for
Mesa back in 2009-2010, we made a key decision really early on.  When I
say "we" here, I mean the team of open-source junkies who happened to
work at Intel.  The only way we were going to be better than certain
closed-source drivers was to be slow and methodical.  In the intervening
8 years, we implemented dozens of extensions that eventually helped get
Mesa to OpenGL 4.5.  We also helped make Mesa one of the first
implementations of OpenGL ES 3.0.  I think we even beat Qualcomm.  All
the while we wrote literally tens of thousands of piglit tests and
submitted dozens of spec bugs.

It's tempting to say, "You have such a big team, you can afford that
luxury."  We made the decision to take this path when the OpenGL team at
Intel was 3 people: Eric, Ken, and myself.  I don't think I need to
quote any software engineering books about the cost of finding defects
early, but it's all true.  The only way we could keep from drowning in
bug reports was to get things right the first time.

It wasn't just the team at Intel who went this way.  We "compelled"
various contractors that we worked with to do the same, and I thought
the drive for quality rubbed off on other people in the community.  I
think the commit statistics in piglit and Mesa support that, too.
Although, part of me does miss the days when a full piglit run took less
than 10 minutes on a slow machine.

Along the way, we caught a lot of flak inside the company for things
taking so long and for being so far behind the rest of the industry.
The payoff came when I would go to GDC or SIGGRAPH, and game developers
would thank me because things just worked, the first time, on Mesa.  We
caught up with the rest of the industry as quickly as we did because we
went as slowly as we did.

It's also tempting to say, "If a feature isn't implemented with high
enough quality, you don't have to enable it."  That is technically true,
but it's also disingenuous.  The only reason these particular features
are being implemented at all is market forces.  If any driver in the
code base supports a particular feature, the ability for other drivers
to resist market forces diminishes to near zero.  Allowing an
inadequately tested feature into core Mesa just pushes the
responsibility for writing tests on to the next person that wants to (or
is compelled to) support the feature.  I hope we can agree that's not okay.


I agree testing is key to Mesa's success. I've even taken that to the 
point where I once went over the entire patchworks outstanding piglit 
tests. Fixing and committing dozens of forgotten about tests, including 
a number from yourself where the extension had been pushed to Mesa and 
the tests had never been pushed to piglit. To be fair you were not the 
only one to do this but it was quite alarming to discover this had been 
happening at the time.


The term quality is somewhat arbitrary. My comment that you could 
disable the extension if the testing was not up to your standards wasn't 
meant to imply I intended to write poor quality test more that I 
believed you were using quality as an easy out given you had already 
made up your mind on the extension in you previous reply.


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

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

[Ian Romanick]

On 09/09/2018 05:00 PM, Timothy Arceri wrote:
> Ian made it pretty clear he didn't want a debate and had already made up
> his mind.
> 
> "We decided years ago that we were not going to support this horrible,
> underspecified steaming pile of an extension in Mesa.  I am not
> interested in going back on that decision now or, frankly, ever."
> 
> All I'm saying is I'm willing to write tests but I get the feeling
> nothing will be good enough when I'm greeted with statements like the
> one above.

That's fair.  I have pretty well made up my mind about EXT_dsa.  I also
had my mind pretty well made up about compatibility profile and
EXT_gpu_shader4.  While I may have my own entrenched opinion, I'm not
the only decision maker.

That said, quality of implementation and quality of testing cannot be
debatable points.

When we started seriously working on getting modern OpenGL support for
Mesa back in 2009-2010, we made a key decision really early on.  When I
say "we" here, I mean the team of open-source junkies who happened to
work at Intel.  The only way we were going to be better than certain
closed-source drivers was to be slow and methodical.  In the intervening
8 years, we implemented dozens of extensions that eventually helped get
Mesa to OpenGL 4.5.  We also helped make Mesa one of the first
implementations of OpenGL ES 3.0.  I think we even beat Qualcomm.  All
the while we wrote literally tens of thousands of piglit tests and
submitted dozens of spec bugs.

It's tempting to say, "You have such a big team, you can afford that
luxury."  We made the decision to take this path when the OpenGL team at
Intel was 3 people: Eric, Ken, and myself.  I don't think I need to
quote any software engineering books about the cost of finding defects
early, but it's all true.  The only way we could keep from drowning in
bug reports was to get things right the first time.

It wasn't just the team at Intel who went this way.  We "compelled"
various contractors that we worked with to do the same, and I thought
the drive for quality rubbed off on other people in the community.  I
think the commit statistics in piglit and Mesa support that, too.
Although, part of me does miss the days when a full piglit run took less
than 10 minutes on a slow machine.

Along the way, we caught a lot of flak inside the company for things
taking so long and for being so far behind the rest of the industry.
The payoff came when I would go to GDC or SIGGRAPH, and game developers
would thank me because things just worked, the first time, on Mesa.  We
caught up with the rest of the industry as quickly as we did because we
went as slowly as we did.

It's also tempting to say, "If a feature isn't implemented with high
enough quality, you don't have to enable it."  That is technically true,
but it's also disingenuous.  The only reason these particular features
are being implemented at all is market forces.  If any driver in the
code base supports a particular feature, the ability for other drivers
to resist market forces diminishes to near zero.  Allowing an
inadequately tested feature into core Mesa just pushes the
responsibility for writing tests on to the next person that wants to (or
is compelled to) support the feature.  I hope we can agree that's not okay.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

[Timothy Arceri]

On 10/09/18 10:00, Ian Romanick wrote:

On 09/09/2018 04:57 PM, Ian Romanick wrote:

On 09/09/2018 04:52 PM, Matt Turner wrote:

On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri  wrote:


On 10/09/18 09:22, Ian Romanick wrote:

On 09/08/2018 06:37 AM, Jason Ekstrand wrote:

Is there going to be an accompanying series on the piglit list?  I don't
see anything there immediately.


Which is one of the major reasons we decided we'd never implement this
extension in Mesa.  To test it to the quality levels that we expect, it
would literally take 1,000+ test cases.


As I said in the other thread refusing to implement this extension is
only going to hurt Mesa users and continue the "just use Nvidia if you
want things to work narrative". AMD have also indicated they would be
adding support for this extension in radeonsi. I'm willing to write
tests if they are not up to your quality levels the feel free not to
enable the extension in your driver.


There are so many things wrong with the last statement.

There's a legitimate debate to have here, but not like this.


I'll ask the question I always ask in these situations: Has anyone
bothered talking to the developer?


The game is years old they are not going to rewrite it now just because
it doesn't run on Mesa drivers. The game doesn't even support Linux in
the first place.


Is it actually the game that EXT_dsa or WINE?


Given the vintage of idTech that the game is based on, there's a good
probability that the game at least tries to use EXT_dsa.  It's based on
id Tech 5 which originally shipped in Rage in 2011.  I'm almost 100%
sure that's before ARB_dsa existed.


Correct. Doom also uses EXT_dsa rather than ARB_dsa but has fallbacks to 
non dsa unlike this game.




So the good follow-up question is: What are the requirements of the
other 3 id Tech 5 games (Rage, Wolfenstein: The New Order, and The Evil
Within)?


Rage is working with some unrelated driconfig hacks although it's pretty 
much unplayable on anything other than Nvidia as they use CUDA for some 
trans-coding apparently which made it pretty much always unusable on 
AMD/ATI but they never bothered fixing it as far as I can tell.


Wolfenstein: The New Order is working great no problems.

The Evil Within runs but eventually hangs my machine, haven't looked 
into why yet.





___
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] Get Wolfenstein: The Old Blood running (Part 2)

[Timothy Arceri]

On 10/09/18 09:52, Ian Romanick wrote:

On 09/09/2018 04:41 PM, Timothy Arceri wrote:

On 10/09/18 09:22, Ian Romanick wrote:

On 09/08/2018 06:37 AM, Jason Ekstrand wrote:

Is there going to be an accompanying series on the piglit list?  I don't
see anything there immediately.


Which is one of the major reasons we decided we'd never implement this
extension in Mesa.  To test it to the quality levels that we expect, it
would literally take 1,000+ test cases.


As I said in the other thread refusing to implement this extension is
only going to hurt Mesa users and continue the "just use Nvidia if you
want things to work narrative". AMD have also indicated they would be
adding support for this extension in radeonsi. I'm willing to write
tests if they are not up to your quality levels the feel free not to
enable the extension in your driver.


That is not and never has been the metric for landing code in core Mesa.


Which part?

I'm willing to write quality tests. You seem to have made up your mind 
that you don't want to enable the extension in your driver. Are you 
saying you want to veto other drivers from supporting something?





I'll ask the question I always ask in these situations: Has anyone
bothered talking to the developer?


The game is years old they are not going to rewrite it now just because
it doesn't run on Mesa drivers. The game doesn't even support Linux in
the first place.


The amount of changes required to the game are a pretty far cry from
"rewrite it."  Delete checks for silly extensions and replace some
instances of EXT with ARB is rewrite?  Give me a break.  They may not be
will to do it, but nobody will ever know if nobody asks.


I've contacted every developer I've added dri config work arounds for so 
far (or found bugs for). The only company that has actuality fixed 
anything is Feral, the No Mans Sky devs said thanks but we wont be 
fixing it for Mesa linux drivers, a few indie devs have thanked me and 
promised fixes but nothing came of it, everyone else either said there 
will be no more game updates or never replied.

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

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

[Ian Romanick]

On 09/09/2018 04:57 PM, Ian Romanick wrote:
> On 09/09/2018 04:52 PM, Matt Turner wrote:
>> On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri  wrote:
>>>
>>> On 10/09/18 09:22, Ian Romanick wrote:
 On 09/08/2018 06:37 AM, Jason Ekstrand wrote:
> Is there going to be an accompanying series on the piglit list?  I don't
> see anything there immediately.

 Which is one of the major reasons we decided we'd never implement this
 extension in Mesa.  To test it to the quality levels that we expect, it
 would literally take 1,000+ test cases.
>>>
>>> As I said in the other thread refusing to implement this extension is
>>> only going to hurt Mesa users and continue the "just use Nvidia if you
>>> want things to work narrative". AMD have also indicated they would be
>>> adding support for this extension in radeonsi. I'm willing to write
>>> tests if they are not up to your quality levels the feel free not to
>>> enable the extension in your driver.
>>
>> There are so many things wrong with the last statement.
>>
>> There's a legitimate debate to have here, but not like this.
>>
 I'll ask the question I always ask in these situations: Has anyone
 bothered talking to the developer?
>>>
>>> The game is years old they are not going to rewrite it now just because
>>> it doesn't run on Mesa drivers. The game doesn't even support Linux in
>>> the first place.
>>
>> Is it actually the game that EXT_dsa or WINE?
> 
> Given the vintage of idTech that the game is based on, there's a good
> probability that the game at least tries to use EXT_dsa.  It's based on
> id Tech 5 which originally shipped in Rage in 2011.  I'm almost 100%
> sure that's before ARB_dsa existed.

So the good follow-up question is: What are the requirements of the
other 3 id Tech 5 games (Rage, Wolfenstein: The New Order, and The Evil
Within)?

> ___
> 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] Get Wolfenstein: The Old Blood running (Part 2)

[Timothy Arceri]

On 10/09/18 09:52, Matt Turner wrote:

On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri  wrote:


On 10/09/18 09:22, Ian Romanick wrote:

On 09/08/2018 06:37 AM, Jason Ekstrand wrote:

Is there going to be an accompanying series on the piglit list?  I don't
see anything there immediately.


Which is one of the major reasons we decided we'd never implement this
extension in Mesa.  To test it to the quality levels that we expect, it
would literally take 1,000+ test cases.


As I said in the other thread refusing to implement this extension is
only going to hurt Mesa users and continue the "just use Nvidia if you
want things to work narrative". AMD have also indicated they would be
adding support for this extension in radeonsi. I'm willing to write
tests if they are not up to your quality levels the feel free not to
enable the extension in your driver.


There are so many things wrong with the last statement.



Can you be more specific?


There's a legitimate debate to have here, but not like this.


Ian made it pretty clear he didn't want a debate and had already made up 
his mind.


"We decided years ago that we were not going to support this horrible,
underspecified steaming pile of an extension in Mesa.  I am not
interested in going back on that decision now or, frankly, ever."

All I'm saying is I'm willing to write tests but I get the feeling 
nothing will be good enough when I'm greeted with statements like the 
one above.





I'll ask the question I always ask in these situations: Has anyone
bothered talking to the developer?


The game is years old they are not going to rewrite it now just because
it doesn't run on Mesa drivers. The game doesn't even support Linux in
the first place.


Is it actually the game that EXT_dsa or WINE?



The game all the id tech engines use OpenGL.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

[Ian Romanick]

On 09/09/2018 04:52 PM, Matt Turner wrote:
> On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri  wrote:
>>
>> On 10/09/18 09:22, Ian Romanick wrote:
>>> On 09/08/2018 06:37 AM, Jason Ekstrand wrote:
 Is there going to be an accompanying series on the piglit list?  I don't
 see anything there immediately.
>>>
>>> Which is one of the major reasons we decided we'd never implement this
>>> extension in Mesa.  To test it to the quality levels that we expect, it
>>> would literally take 1,000+ test cases.
>>
>> As I said in the other thread refusing to implement this extension is
>> only going to hurt Mesa users and continue the "just use Nvidia if you
>> want things to work narrative". AMD have also indicated they would be
>> adding support for this extension in radeonsi. I'm willing to write
>> tests if they are not up to your quality levels the feel free not to
>> enable the extension in your driver.
> 
> There are so many things wrong with the last statement.
> 
> There's a legitimate debate to have here, but not like this.
> 
>>> I'll ask the question I always ask in these situations: Has anyone
>>> bothered talking to the developer?
>>
>> The game is years old they are not going to rewrite it now just because
>> it doesn't run on Mesa drivers. The game doesn't even support Linux in
>> the first place.
> 
> Is it actually the game that EXT_dsa or WINE?

Given the vintage of idTech that the game is based on, there's a good
probability that the game at least tries to use EXT_dsa.  It's based on
id Tech 5 which originally shipped in Rage in 2011.  I'm almost 100%
sure that's before ARB_dsa existed.

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

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

[Matt Turner]

On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri  wrote:
>
> On 10/09/18 09:22, Ian Romanick wrote:
> > On 09/08/2018 06:37 AM, Jason Ekstrand wrote:
> >> Is there going to be an accompanying series on the piglit list?  I don't
> >> see anything there immediately.
> >
> > Which is one of the major reasons we decided we'd never implement this
> > extension in Mesa.  To test it to the quality levels that we expect, it
> > would literally take 1,000+ test cases.
>
> As I said in the other thread refusing to implement this extension is
> only going to hurt Mesa users and continue the "just use Nvidia if you
> want things to work narrative". AMD have also indicated they would be
> adding support for this extension in radeonsi. I'm willing to write
> tests if they are not up to your quality levels the feel free not to
> enable the extension in your driver.

There are so many things wrong with the last statement.

There's a legitimate debate to have here, but not like this.

> > I'll ask the question I always ask in these situations: Has anyone
> > bothered talking to the developer?
>
> The game is years old they are not going to rewrite it now just because
> it doesn't run on Mesa drivers. The game doesn't even support Linux in
> the first place.

Is it actually the game that EXT_dsa or WINE?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

[Ian Romanick]

On 09/09/2018 04:41 PM, Timothy Arceri wrote:
> On 10/09/18 09:22, Ian Romanick wrote:
>> On 09/08/2018 06:37 AM, Jason Ekstrand wrote:
>>> Is there going to be an accompanying series on the piglit list?  I don't
>>> see anything there immediately.
>>
>> Which is one of the major reasons we decided we'd never implement this
>> extension in Mesa.  To test it to the quality levels that we expect, it
>> would literally take 1,000+ test cases.
> 
> As I said in the other thread refusing to implement this extension is
> only going to hurt Mesa users and continue the "just use Nvidia if you
> want things to work narrative". AMD have also indicated they would be
> adding support for this extension in radeonsi. I'm willing to write
> tests if they are not up to your quality levels the feel free not to
> enable the extension in your driver.

That is not and never has been the metric for landing code in core Mesa.

>> I'll ask the question I always ask in these situations: Has anyone
>> bothered talking to the developer?
> 
> The game is years old they are not going to rewrite it now just because
> it doesn't run on Mesa drivers. The game doesn't even support Linux in
> the first place.

The amount of changes required to the game are a pretty far cry from
"rewrite it."  Delete checks for silly extensions and replace some
instances of EXT with ARB is rewrite?  Give me a break.  They may not be
will to do it, but nobody will ever know if nobody asks.

>>> On September 7, 2018 23:32:16 Timothy Arceri 
>>> wrote:
>>>
 EXT_direct_state_access is a huge extension so patch 1 adds a list of
 the functions to displatch sanity that can be used as a TODO list.

 Wolfenstein doesn't use the matrix stuff but since Chris implemented
 it and we are eventually going to add this extension it seemed worth
 sending out with this series.

 This series also provides enough of EXT_direct_state_access for Doom
 to run with the extension enabled. However since this is a partial
 implementation it is not yet enabled, it just happens that Wolfenstein
 forgets to check for the extension so its able to run without us
 having to enable it yet.
>>>
>>> ___
>>> 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] Get Wolfenstein: The Old Blood running (Part 2)

[Timothy Arceri]

On 10/09/18 09:22, Ian Romanick wrote:

On 09/08/2018 06:37 AM, Jason Ekstrand wrote:

Is there going to be an accompanying series on the piglit list?  I don't
see anything there immediately.


Which is one of the major reasons we decided we'd never implement this
extension in Mesa.  To test it to the quality levels that we expect, it
would literally take 1,000+ test cases.


As I said in the other thread refusing to implement this extension is 
only going to hurt Mesa users and continue the "just use Nvidia if you 
want things to work narrative". AMD have also indicated they would be 
adding support for this extension in radeonsi. I'm willing to write 
tests if they are not up to your quality levels the feel free not to 
enable the extension in your driver.




I'll ask the question I always ask in these situations: Has anyone
bothered talking to the developer?


The game is years old they are not going to rewrite it now just because 
it doesn't run on Mesa drivers. The game doesn't even support Linux in 
the first place.





On September 7, 2018 23:32:16 Timothy Arceri  wrote:


EXT_direct_state_access is a huge extension so patch 1 adds a list of
the functions to displatch sanity that can be used as a TODO list.

Wolfenstein doesn't use the matrix stuff but since Chris implemented
it and we are eventually going to add this extension it seemed worth
sending out with this series.

This series also provides enough of EXT_direct_state_access for Doom
to run with the extension enabled. However since this is a partial
implementation it is not yet enabled, it just happens that Wolfenstein
forgets to check for the extension so its able to run without us
having to enable it yet.


___
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 01/13] mesa: add a list of EXT_direct_state_access to dispatch sanity

[Timothy Arceri]

On 10/09/18 08:54, Ian Romanick wrote:

We decided years ago that we were not going to support this horrible,
underspecified steaming pile of an extension in Mesa.  I am not
interested in going back on that decision now or, frankly, ever.


This will only hurt users of Mesa and continue the "just use Nvidia if 
you want things to work narrative".


The games and apps that use this have been around for years. Nobody is 
going back to rewrite their apps and refusing to implements it just 
causes pain for Mesa users.


Obviously having games actually work is important for Valve, but AMD 
have also indicated they want to add support for this extension as they 
continue to add feature parity to radeonsi (vs their pro stack).




On 09/07/2018 09:31 PM, Timothy Arceri wrote:

This extension is huge and this gives us a TODO list of functions
to implement.
---
  src/mesa/main/tests/dispatch_sanity.cpp | 219 
  1 file changed, 219 insertions(+)

diff --git a/src/mesa/main/tests/dispatch_sanity.cpp 
b/src/mesa/main/tests/dispatch_sanity.cpp
index fb2acfbdeea..8b03f5377b3 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -1015,6 +1015,225 @@ const struct function 
common_desktop_functions_possible[] = {
 { "glGetQueryBufferObjecti64v", 45, -1 },
 { "glGetQueryBufferObjectui64v", 45, -1 },
  
+   /* GL_EXT_direct_state_access - GL 1.0 */

+   //{ "glMatrixLoadfEXT", 10, -1 },
+   //{ "glMatrixLoaddEXT", 10, -1 },
+   //{ "glMatrixMultfEXT", 10, -1 },
+   //{ "glMatrixMultdEXT", 10, -1 },
+   //{ "glMatrixLoadIdentityEXT", 10, -1 },
+   //{ "glMatrixRotatefEXT", 10, -1 },
+   //{ "glMatrixRotatedEXT", 10, -1 },
+   //{ "glMatrixScalefEXT", 10, -1 },
+   //{ "glMatrixScaledEXT", 10, -1 },
+   //{ "glMatrixTranslatefEXT", 10, -1 },
+   //{ "glMatrixTranslatedEXT", 10, -1 },
+   //{ "glMatrixOrthoEXT", 10, -1 },
+   //{ "glMatrixFrustumEXT", 10, -1 },
+   //{ "glMatrixPushEXT", 10, -1 },
+   //{ "glMatrixPopEXT", 10, -1 },
+   /* GL_EXT_direct_state_access - GL 1.1 */
+   //{ "glClientAttribDefaultEXT", 10, -1 },
+   //{ "glPushClientAttribDefaultEXT", 10, -1 },
+   //{ "glTextureParameteriEXT", 10, -1 },
+   //{ "glTextureParameterivEXT", 10, -1 },
+   //{ "glTextureParameterfEXT", 10, -1 },
+   //{ "glTextureParameterfvEXT", 10, -1 },
+   //{ "glTextureImage1DEXT", 10, -1 },
+   //{ "glTextureImage2DEXT", 10, -1 },
+   //{ "glTextureSubImage1DEXT", 10, -1 },
+   //{ "glTextureSubImage2DEXT", 10, -1 },
+   //{ "glCopyTextureImage1DEXT", 10, -1 },
+   //{ "glCopyTextureImage2DEXT", 10, -1 },
+   //{ "glCopyTextureSubImage1DEXT", 10, -1 },
+   //{ "glCopyTextureSubImage2DEXT", 10, -1 },
+   //{ "glGetTextureImageEXT", 10, -1 },
+   //{ "glGetTextureParameterfvEXT", 10, -1 },
+   //{ "glGetTextureParameterivEXT", 10, -1 },
+   //{ "glGetTextureLevelParameterfvEXT", 10, -1 },
+   //{ "glGetTextureLevelParameterivEXT", 10, -1 },
+   /* GL_EXT_direct_state_access - GL 1.2 */
+   //{ "glTextureImage3DEXT", 10, -1 },
+   //{ "glTextureSubImage3DEXT", 10, -1 },
+   //{ "glCopyTextureSubImage3DEXT", 10, -1 },
+   /* GL_EXT_direct_state_access - GL 1.2.1 */
+   //{ "glBindMultiTextureEXT", 10, -1 },
+   //{ "glMultiTexCoordPointerEXT", 10, -1 },
+   //{ "glMultiTexEnvfEXT", 10, -1 },
+   //{ "glMultiTexEnvfvEXT", 10, -1 },
+   //{ "glMultiTexEnviEXT", 10, -1 },
+   //{ "glMultiTexEnvivEXT", 10, -1 },
+   //{ "glMultiTexGenEXT", 10, -1 },
+   //{ "glMultiTexGenvEXT", 10, -1 },
+   //{ "glMultiTexGenfEXT", 10, -1 },
+   //{ "glMultiTexGenfvEXT", 10, -1 },
+   //{ "glMultiTexGeniEXT", 10, -1 },
+   //{ "glMultiTexGenivEXT", 10, -1 },
+   //{ "glGenMultiTexEnvfvEXT", 10, -1 },
+   //{ "glGenMultiTexEnvivEXT", 10, -1 },
+   //{ "glGenMultiTexGenvEXT", 10, -1 },
+   //{ "glGenMultiTexGenfvEXT", 10, -1 },
+   //{ "glGenMultiTexGenivEXT", 10, -1 },
+   //{ "glMultiTexParameterfEXT", 10, -1 },
+   //{ "glMultiTexParameterfvEXT", 10, -1 },
+   //{ "glMultiTexParameteriEXT", 10, -1 },
+   //{ "glMultiTexParameterivEXT", 10, -1 },
+   //{ "glMultiTexImage1DEXT", 10, -1 },
+   //{ "glMultiTexImage2DEXT", 10, -1 },
+   //{ "glMultiTexSubImage1DEXT", 10, -1 },
+   //{ "glMultiTexSubImage2DEXT", 10, -1 },
+   //{ "glCopyMultiTexImage1DEXT", 10, -1 },
+   //{ "glCopyMultiTexImage2DEXT", 10, -1 },
+   //{ "glCopyMultiTexSubImage1DEXT", 10, -1 },
+   //{ "glCopyMultiTexSubImage2DEXT", 10, -1 },
+   //{ "glGetMultiTexImageEXT", 10, -1 },
+   //{ "glGetMultiTexParameterfvEXT", 10, -1 },
+   //{ "glGetMultiTexParameterivEXT", 10, -1 },
+   //{ "glGetMultiTexLevelParameterfvEXT", 10, -1 },
+   //{ "glGetMultiTexLevelParameterivEXT", 10, -1 },
+   //{ "glMultiTexImage3DEXT", 10, -1 },
+   //{ "glMultiTexSubImage3DEXT", 10, -1 },
+   //{ "glCopyMultiTexSubImage3DEXT", 10, -1 },
+   //{ "glEnableClientStateIndexedEXT", 10, -1 },
+   //{ "glDisableClientStateIndexedEXT", 10, -1 },
+   //{ "glGetFloatIndexedvEXT", 10, -1 },
+   //{ "glGetDoubleIndexedvEXT", 10, -1 },
+   //{ 

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

[Ian Romanick]

On 09/08/2018 06:37 AM, Jason Ekstrand wrote:
> Is there going to be an accompanying series on the piglit list?  I don't
> see anything there immediately.

Which is one of the major reasons we decided we'd never implement this
extension in Mesa.  To test it to the quality levels that we expect, it
would literally take 1,000+ test cases.

I'll ask the question I always ask in these situations: Has anyone
bothered talking to the developer?

> On September 7, 2018 23:32:16 Timothy Arceri  wrote:
> 
>> EXT_direct_state_access is a huge extension so patch 1 adds a list of
>> the functions to displatch sanity that can be used as a TODO list.
>>
>> Wolfenstein doesn't use the matrix stuff but since Chris implemented
>> it and we are eventually going to add this extension it seemed worth
>> sending out with this series.
>>
>> This series also provides enough of EXT_direct_state_access for Doom
>> to run with the extension enabled. However since this is a partial
>> implementation it is not yet enabled, it just happens that Wolfenstein
>> forgets to check for the extension so its able to run without us
>> having to enable it yet.
> 
> ___
> 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 01/13] mesa: add a list of EXT_direct_state_access to dispatch sanity

[Ian Romanick]

We decided years ago that we were not going to support this horrible,
underspecified steaming pile of an extension in Mesa.  I am not
interested in going back on that decision now or, frankly, ever.

On 09/07/2018 09:31 PM, Timothy Arceri wrote:
> This extension is huge and this gives us a TODO list of functions
> to implement.
> ---
>  src/mesa/main/tests/dispatch_sanity.cpp | 219 
>  1 file changed, 219 insertions(+)
> 
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp 
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index fb2acfbdeea..8b03f5377b3 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -1015,6 +1015,225 @@ const struct function 
> common_desktop_functions_possible[] = {
> { "glGetQueryBufferObjecti64v", 45, -1 },
> { "glGetQueryBufferObjectui64v", 45, -1 },
>  
> +   /* GL_EXT_direct_state_access - GL 1.0 */
> +   //{ "glMatrixLoadfEXT", 10, -1 },
> +   //{ "glMatrixLoaddEXT", 10, -1 },
> +   //{ "glMatrixMultfEXT", 10, -1 },
> +   //{ "glMatrixMultdEXT", 10, -1 },
> +   //{ "glMatrixLoadIdentityEXT", 10, -1 },
> +   //{ "glMatrixRotatefEXT", 10, -1 },
> +   //{ "glMatrixRotatedEXT", 10, -1 },
> +   //{ "glMatrixScalefEXT", 10, -1 },
> +   //{ "glMatrixScaledEXT", 10, -1 },
> +   //{ "glMatrixTranslatefEXT", 10, -1 },
> +   //{ "glMatrixTranslatedEXT", 10, -1 },
> +   //{ "glMatrixOrthoEXT", 10, -1 },
> +   //{ "glMatrixFrustumEXT", 10, -1 },
> +   //{ "glMatrixPushEXT", 10, -1 },
> +   //{ "glMatrixPopEXT", 10, -1 },
> +   /* GL_EXT_direct_state_access - GL 1.1 */
> +   //{ "glClientAttribDefaultEXT", 10, -1 },
> +   //{ "glPushClientAttribDefaultEXT", 10, -1 },
> +   //{ "glTextureParameteriEXT", 10, -1 },
> +   //{ "glTextureParameterivEXT", 10, -1 },
> +   //{ "glTextureParameterfEXT", 10, -1 },
> +   //{ "glTextureParameterfvEXT", 10, -1 },
> +   //{ "glTextureImage1DEXT", 10, -1 },
> +   //{ "glTextureImage2DEXT", 10, -1 },
> +   //{ "glTextureSubImage1DEXT", 10, -1 },
> +   //{ "glTextureSubImage2DEXT", 10, -1 },
> +   //{ "glCopyTextureImage1DEXT", 10, -1 },
> +   //{ "glCopyTextureImage2DEXT", 10, -1 },
> +   //{ "glCopyTextureSubImage1DEXT", 10, -1 },
> +   //{ "glCopyTextureSubImage2DEXT", 10, -1 },
> +   //{ "glGetTextureImageEXT", 10, -1 },
> +   //{ "glGetTextureParameterfvEXT", 10, -1 },
> +   //{ "glGetTextureParameterivEXT", 10, -1 },
> +   //{ "glGetTextureLevelParameterfvEXT", 10, -1 },
> +   //{ "glGetTextureLevelParameterivEXT", 10, -1 },
> +   /* GL_EXT_direct_state_access - GL 1.2 */
> +   //{ "glTextureImage3DEXT", 10, -1 },
> +   //{ "glTextureSubImage3DEXT", 10, -1 },
> +   //{ "glCopyTextureSubImage3DEXT", 10, -1 },
> +   /* GL_EXT_direct_state_access - GL 1.2.1 */
> +   //{ "glBindMultiTextureEXT", 10, -1 },
> +   //{ "glMultiTexCoordPointerEXT", 10, -1 },
> +   //{ "glMultiTexEnvfEXT", 10, -1 },
> +   //{ "glMultiTexEnvfvEXT", 10, -1 },
> +   //{ "glMultiTexEnviEXT", 10, -1 },
> +   //{ "glMultiTexEnvivEXT", 10, -1 },
> +   //{ "glMultiTexGenEXT", 10, -1 },
> +   //{ "glMultiTexGenvEXT", 10, -1 },
> +   //{ "glMultiTexGenfEXT", 10, -1 },
> +   //{ "glMultiTexGenfvEXT", 10, -1 },
> +   //{ "glMultiTexGeniEXT", 10, -1 },
> +   //{ "glMultiTexGenivEXT", 10, -1 },
> +   //{ "glGenMultiTexEnvfvEXT", 10, -1 },
> +   //{ "glGenMultiTexEnvivEXT", 10, -1 },
> +   //{ "glGenMultiTexGenvEXT", 10, -1 },
> +   //{ "glGenMultiTexGenfvEXT", 10, -1 },
> +   //{ "glGenMultiTexGenivEXT", 10, -1 },
> +   //{ "glMultiTexParameterfEXT", 10, -1 },
> +   //{ "glMultiTexParameterfvEXT", 10, -1 },
> +   //{ "glMultiTexParameteriEXT", 10, -1 },
> +   //{ "glMultiTexParameterivEXT", 10, -1 },
> +   //{ "glMultiTexImage1DEXT", 10, -1 },
> +   //{ "glMultiTexImage2DEXT", 10, -1 },
> +   //{ "glMultiTexSubImage1DEXT", 10, -1 },
> +   //{ "glMultiTexSubImage2DEXT", 10, -1 },
> +   //{ "glCopyMultiTexImage1DEXT", 10, -1 },
> +   //{ "glCopyMultiTexImage2DEXT", 10, -1 },
> +   //{ "glCopyMultiTexSubImage1DEXT", 10, -1 },
> +   //{ "glCopyMultiTexSubImage2DEXT", 10, -1 },
> +   //{ "glGetMultiTexImageEXT", 10, -1 },
> +   //{ "glGetMultiTexParameterfvEXT", 10, -1 },
> +   //{ "glGetMultiTexParameterivEXT", 10, -1 },
> +   //{ "glGetMultiTexLevelParameterfvEXT", 10, -1 },
> +   //{ "glGetMultiTexLevelParameterivEXT", 10, -1 },
> +   //{ "glMultiTexImage3DEXT", 10, -1 },
> +   //{ "glMultiTexSubImage3DEXT", 10, -1 },
> +   //{ "glCopyMultiTexSubImage3DEXT", 10, -1 },
> +   //{ "glEnableClientStateIndexedEXT", 10, -1 },
> +   //{ "glDisableClientStateIndexedEXT", 10, -1 },
> +   //{ "glGetFloatIndexedvEXT", 10, -1 },
> +   //{ "glGetDoubleIndexedvEXT", 10, -1 },
> +   //{ "glGetPointerIndexedvEXT", 10, -1 },
> +   //{ "glEnableIndexedEXT", 10, -1 },
> +   //{ "glDisableIndexedEXT", 10, -1 },
> +   //{ "glIsEnabledIndexedEXT", 10, -1 },
> +   //{ "glGetIntegerIndexedvEXT", 10, -1 },
> +   //{ "glGetBooleanIndexedvEXT", 10, -1 },
> +   /* GL_EXT_direct_state_access - ARB_vertex_program */
> +   //{ 

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_vertex_program in core profile

[Ian Romanick]

No.  This is one is definitely out.  ARB_vertex_program *require* all of
the legacy stuff that core profile removes.  There is no way this one is
valid.

On 09/07/2018 09:20 PM, Timothy Arceri wrote:
> This extension is required by "Wolfenstein: The Old Blood". Without
> it the app causes wine to crash on startup.
> ---
>  src/mesa/main/extensions_table.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/main/extensions_table.h 
> b/src/mesa/main/extensions_table.h
> index 09bf923bd0e..7144ce75bbc 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -183,7 +183,7 @@ EXT(ARB_vertex_array_object , dummy_true
>  EXT(ARB_vertex_attrib_64bit , ARB_vertex_attrib_64bit
> ,  32, GLC,  x ,  x , 2010)
>  EXT(ARB_vertex_attrib_binding   , dummy_true 
> , GLL, GLC,  x ,  x , 2012)
>  EXT(ARB_vertex_buffer_object, dummy_true 
> , GLL, GLC,  x ,  x , 2003)
> -EXT(ARB_vertex_program  , ARB_vertex_program 
> , GLL,  x ,  x ,  x , 2002)
> +EXT(ARB_vertex_program  , ARB_vertex_program 
> , GLL, GLC,  x ,  x , 2002)
>  EXT(ARB_vertex_shader   , ARB_vertex_shader  
> , GLL, GLC,  x ,  x , 2002)
>  EXT(ARB_vertex_type_10f_11f_11f_rev , 
> ARB_vertex_type_10f_11f_11f_rev, GLL, GLC,  x ,  x , 2013)
>  EXT(ARB_vertex_type_2_10_10_10_rev  , ARB_vertex_type_2_10_10_10_rev 
> , GLL, GLC,  x ,  x , 2009)
> 

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

[Mesa-dev] [Bug 99765] Make Octopus OpenCL support work on Clover and RadeonSI

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99765

Timothy Arceri  changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover
 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 94273] Clover on RadeonSI OpenCL segfault during testing of clBLAS

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=94273

Timothy Arceri  changed:

   What|Removed |Added

 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 91305] [clover/kaveri] When running JohnTheRipper OpenCL tests: radeon 0000:01:00.0: ring 0 stalled for more than ...msec

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91305

Timothy Arceri  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 100105] Make Theano OpenCL support work on Clover and RadeonSI

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100105

Timothy Arceri  changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 102009] [clover, amdgcn] Blender crashes when compiling OpenCL kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102009

Timothy Arceri  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 82717] OpenCL support for mandelbulber-opencl

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=82717

Timothy Arceri  changed:

   What|Removed |Added

 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 107115] Make darktable OpenCL support work on Clover and RadeonSI

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107115

Timothy Arceri  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 87738] [OpenCL] Please add Image support

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=87738

Timothy Arceri  changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 99553] Tracker bug for runnning OpenCL applications on Clover

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99553

Timothy Arceri  changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover
 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 107873] Doom 2016 - Rendering issues

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107873

--- Comment #3 from Ahmed Elsayed  ---
I tried both OpenGL and Vulkan and same gave me the same behavior. I am trying
to compile Mesa 18.3 for the third time because it failed in the last 2 times.
I hope it will be built without errors this time.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/5] st/nine: Clamp RCP when 0*inf!=0

[Axel Davy]

On 9/9/18 9:40 PM, Ilia Mirkin wrote:

On Sun, Sep 9, 2018 at 3:19 PM, Axel Davy  wrote:

Tests showed Intel on windows does always clamp
RCP, RSQ and LOG (thus preventing inf/nan generation),
for all shader versions (some vendor behaviours vary
with shader versions).

By the way, this happens because on Intel, the ALU is put into a
special mode where it just doesn't generate NaN's at all under any
conditions. I don't think that other vendors operate this way.


Yes exactly, though the documentation, if I remember correctly,

says the flag is for shaders version <= 2.0, but tests showed the clamping

was also used for version 3.0.


The point is that games work properly on all vendors. Thus picking intel 
behaviour is safe,


even if we use a card from another vendor.


I think the inf/nan behaviour on AMD and NVidia was with compute 
applications in mind (there was no


other way to do compute back then), but games weren't interested in Infs 
and NaN.



Also our tests showed that all vendors have 0*inf = 0 and 0*NaN = 0, 
even if rcp, log and rsq are clamped.


(inf and NaN can be passed via constants or inputs for such tests).


Axel

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

Re: [Mesa-dev] [PATCH 1/5] st/nine: Clamp RCP when 0*inf!=0

[Axel Davy]

On 9/9/18 9:35 PM, Ilia Mirkin wrote:

On Sun, Sep 9, 2018 at 3:19 PM, Axel Davy  wrote:

For now clamp for all drivers. An ulterior optimization
would be to avoid clamping for drivers with MUL_ZERO_WINS
for the specific shader versions where NV or AMD don't
clamp.

Too bad. The whole point of this feature was for nine to use it.
Should we just drop that logic?

   -ilia



I have lost my notes on the detailed results of my tests on the 3 
vendors (and the test itself).

But I plan on finding them back and complete them.
Then I want to send a patch to remove any clamping when possible.

I remember there was some weird behaviours depending of whether it is vs 
or ps and shader version,

but that mostly we should be able to get rid of the clamping in most cases.

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

Re: [Mesa-dev] [PATCH 1/5] st/nine: Clamp RCP when 0*inf!=0

[Ilia Mirkin]

On Sun, Sep 9, 2018 at 3:19 PM, Axel Davy  wrote:
> Tests showed Intel on windows does always clamp
> RCP, RSQ and LOG (thus preventing inf/nan generation),
> for all shader versions (some vendor behaviours vary
> with shader versions).

By the way, this happens because on Intel, the ALU is put into a
special mode where it just doesn't generate NaN's at all under any
conditions. I don't think that other vendors operate this way.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/5] st/nine: Clamp RCP when 0*inf!=0

[Ilia Mirkin]

On Sun, Sep 9, 2018 at 3:19 PM, Axel Davy  wrote:
> For now clamp for all drivers. An ulterior optimization
> would be to avoid clamping for drivers with MUL_ZERO_WINS
> for the specific shader versions where NV or AMD don't
> clamp.

Too bad. The whole point of this feature was for nine to use it.
Should we just drop that logic?

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

[Mesa-dev] [PATCH 4/5] st/nine: Add new helper for object creation with bind

[Axel Davy]

Add a new helper to create objects starting with a bind
count instead of a ref count.

Signed-off-by: Axel Davy 
---
 .../state_trackers/nine/nine_helpers.h| 26 +++
 1 file changed, 26 insertions(+)

diff --git a/src/gallium/state_trackers/nine/nine_helpers.h 
b/src/gallium/state_trackers/nine/nine_helpers.h
index a0c55bd9ee..c14dd1c04f 100644
--- a/src/gallium/state_trackers/nine/nine_helpers.h
+++ b/src/gallium/state_trackers/nine/nine_helpers.h
@@ -99,6 +99,32 @@ static inline void _nine_bind(void **dst, void *obj)
 } \
 return D3D_OK
 
+#define NINE_DEVICE_CHILD_BIND_NEW(nine, out, dev, ...) \
+{ \
+struct NineUnknownParams __params; \
+struct Nine##nine *__data; \
+ \
+__data = CALLOC_STRUCT(Nine##nine); \
+if (!__data) { return E_OUTOFMEMORY; } \
+ \
+__params.vtable = ((dev)->params.BehaviorFlags & 
D3DCREATE_MULTITHREADED) ? ##nine##_vtable : ##nine##_vtable; \
+__params.guids = Nine##nine##_IIDs; \
+__params.dtor = (void *)Nine##nine##_dtor; \
+__params.container = NULL; \
+__params.device = dev; \
+__params.start_with_bind_not_ref = true; \
+{ \
+HRESULT __hr = Nine##nine##_ctor(__data, &__params, ## 
__VA_ARGS__); \
+if (FAILED(__hr)) { \
+Nine##nine##_dtor(__data); \
+return __hr; \
+} \
+} \
+ \
+*(out) = __data; \
+} \
+return D3D_OK
+
 #define NINE_NEW(nine, out, lock, ...) \
 { \
 struct NineUnknownParams __params; \
-- 
2.18.0

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

[Mesa-dev] [PATCH 5/5] st/nine: Avoid RefToBind calls in ff

[Axel Davy]

When using csmt, ff shader creation happens on the csmt
thread. Creating the shaders, then calling RefToBind causes
the device ref to be increased then decreased.

However the device dtor assumes than no work pending on the
csmt thread could increase the device ref, leading to hang.

The issue is avoided by creating the shaders with a bind
count directly.

Fixes: https://github.com/iXit/Mesa-3D/issues/295

Signed-off-by: Axel Davy 
---
 src/gallium/state_trackers/nine/nine_ff.c   | 2 --
 src/gallium/state_trackers/nine/pixelshader9.c  | 6 +-
 src/gallium/state_trackers/nine/vertexshader9.c | 6 +-
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/src/gallium/state_trackers/nine/nine_ff.c 
b/src/gallium/state_trackers/nine/nine_ff.c
index fabc1d3b88..58cc29b5e3 100644
--- a/src/gallium/state_trackers/nine/nine_ff.c
+++ b/src/gallium/state_trackers/nine/nine_ff.c
@@ -1698,7 +1698,6 @@ nine_ff_get_vs(struct NineDevice9 *device)
 (void)err;
 assert(err == PIPE_OK);
 device->ff.num_vs++;
-NineUnknown_ConvertRefToBind(NineUnknown(vs));
 
 vs->num_inputs = bld.num_inputs;
 for (n = 0; n < bld.num_inputs; ++n)
@@ -1850,7 +1849,6 @@ nine_ff_get_ps(struct NineDevice9 *device)
 (void)err;
 assert(err == PIPE_OK);
 device->ff.num_ps++;
-NineUnknown_ConvertRefToBind(NineUnknown(ps));
 
 ps->rt_mask = 0x1;
 ps->sampler_mask = sampler_mask;
diff --git a/src/gallium/state_trackers/nine/pixelshader9.c 
b/src/gallium/state_trackers/nine/pixelshader9.c
index bfc395cdf5..6f053f709b 100644
--- a/src/gallium/state_trackers/nine/pixelshader9.c
+++ b/src/gallium/state_trackers/nine/pixelshader9.c
@@ -203,5 +203,9 @@ NinePixelShader9_new( struct NineDevice9 *pDevice,
   struct NinePixelShader9 **ppOut,
   const DWORD *pFunction, void *cso )
 {
-NINE_DEVICE_CHILD_NEW(PixelShader9, ppOut, pDevice, pFunction, cso);
+if (cso) { /* ff shader. Needs to start with bind count */
+NINE_DEVICE_CHILD_BIND_NEW(PixelShader9, ppOut, pDevice, pFunction, 
cso);
+} else {
+NINE_DEVICE_CHILD_NEW(PixelShader9, ppOut, pDevice, pFunction, cso);
+}
 }
diff --git a/src/gallium/state_trackers/nine/vertexshader9.c 
b/src/gallium/state_trackers/nine/vertexshader9.c
index a4228af157..f104a9ad13 100644
--- a/src/gallium/state_trackers/nine/vertexshader9.c
+++ b/src/gallium/state_trackers/nine/vertexshader9.c
@@ -262,5 +262,9 @@ NineVertexShader9_new( struct NineDevice9 *pDevice,
struct NineVertexShader9 **ppOut,
const DWORD *pFunction, void *cso )
 {
-NINE_DEVICE_CHILD_NEW(VertexShader9, ppOut, pDevice, pFunction, cso);
+if (cso) {
+NINE_DEVICE_CHILD_BIND_NEW(VertexShader9, ppOut, pDevice, pFunction, 
cso);
+} else {
+NINE_DEVICE_CHILD_NEW(VertexShader9, ppOut, pDevice, pFunction, cso);
+}
 }
-- 
2.18.0

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

[Mesa-dev] [PATCH 1/5] st/nine: Clamp RCP when 0*inf!=0

[Axel Davy]

Tests done on several devices of all 3 vendors and
of different generations showed that there are several
ways of handling infs and NaN for d3d9.

Tests showed Intel on windows does always clamp
RCP, RSQ and LOG (thus preventing inf/nan generation),
for all shader versions (some vendor behaviours vary
with shader versions).
Doing this in nine avoids 0*inf issues for drivers
that can't generate 0*inf=0 (which is controled by
TGSI's MUL_ZERO_WINS).

For now clamp for all drivers. An ulterior optimization
would be to avoid clamping for drivers with MUL_ZERO_WINS
for the specific shader versions where NV or AMD don't
clamp.

LOG and RSQ being already clamped, this patch only
clamps RCP.

Fixes: https://github.com/iXit/Mesa-3D/issues/316

Signed-off-by: Axel Davy 
CC: 
---
 src/gallium/state_trackers/nine/nine_shader.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/nine/nine_shader.c 
b/src/gallium/state_trackers/nine/nine_shader.c
index 7db07d8f69..5b8ad3f161 100644
--- a/src/gallium/state_trackers/nine/nine_shader.c
+++ b/src/gallium/state_trackers/nine/nine_shader.c
@@ -2273,6 +2273,18 @@ DECL_SPECIAL(POW)
 return D3D_OK;
 }
 
+DECL_SPECIAL(RCP)
+{
+struct ureg_program *ureg = tx->ureg;
+struct ureg_dst dst = tx_dst_param(tx, >insn.dst[0]);
+struct ureg_src src = tx_src_param(tx, >insn.src[0]);
+struct ureg_dst tmp = tx_scratch(tx);
+ureg_RCP(ureg, tmp, src);
+ureg_MIN(ureg, tmp, ureg_imm1f(ureg, FLT_MAX), ureg_src(tmp));
+ureg_MAX(ureg, dst, ureg_imm1f(ureg, -FLT_MAX), ureg_src(tmp));
+return D3D_OK;
+}
+
 DECL_SPECIAL(RSQ)
 {
 struct ureg_program *ureg = tx->ureg;
@@ -2909,7 +2921,7 @@ static const struct sm1_op_info inst_table[] =
 _OPI(SUB, NOP, V(0,0), V(3,0), V(0,0), V(3,0), 1, 2, SPECIAL(SUB)), /* 3 */
 _OPI(MAD, MAD, V(0,0), V(3,0), V(0,0), V(3,0), 1, 3, NULL), /* 4 */
 _OPI(MUL, MUL, V(0,0), V(3,0), V(0,0), V(3,0), 1, 2, NULL), /* 5 */
-_OPI(RCP, RCP, V(0,0), V(3,0), V(0,0), V(3,0), 1, 1, NULL), /* 6 */
+_OPI(RCP, RCP, V(0,0), V(3,0), V(0,0), V(3,0), 1, 1, SPECIAL(RCP)), /* 6 */
 _OPI(RSQ, RSQ, V(0,0), V(3,0), V(0,0), V(3,0), 1, 1, SPECIAL(RSQ)), /* 7 */
 _OPI(DP3, DP3, V(0,0), V(3,0), V(0,0), V(3,0), 1, 2, NULL), /* 8 */
 _OPI(DP4, DP4, V(0,0), V(3,0), V(0,0), V(3,0), 1, 2, NULL), /* 9 */
-- 
2.18.0

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

[Mesa-dev] [PATCH 3/5] st/nine: Add parameter to start with bind

[Axel Davy]

Add a parameter to start new object with a bind
instead of a refcount.

Signed-off-by: Axel Davy 
---
 src/gallium/state_trackers/nine/iunknown.c | 18 +++---
 src/gallium/state_trackers/nine/iunknown.h |  1 +
 src/gallium/state_trackers/nine/nine_helpers.h |  2 ++
 3 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/nine/iunknown.c 
b/src/gallium/state_trackers/nine/iunknown.c
index d76d644789..3835651f53 100644
--- a/src/gallium/state_trackers/nine/iunknown.c
+++ b/src/gallium/state_trackers/nine/iunknown.c
@@ -34,9 +34,21 @@ HRESULT
 NineUnknown_ctor( struct NineUnknown *This,
   struct NineUnknownParams *pParams )
 {
-This->refs = pParams->container ? 0 : 1;
-This->bind = 0;
-This->forward = !This->refs;
+if (pParams->container) {
+This->refs = 0;
+This->forward = true;
+This->bind = 0;
+assert(!pParams->start_with_bind_not_ref);
+} else if (pParams->start_with_bind_not_ref) {
+This->refs = 0;
+This->forward = false;
+This->bind = 1;
+} else {
+This->refs = 1;
+This->forward = false;
+This->bind = 0;
+}
+
 This->container = pParams->container;
 This->device = pParams->device;
 if (This->refs && This->device)
diff --git a/src/gallium/state_trackers/nine/iunknown.h 
b/src/gallium/state_trackers/nine/iunknown.h
index f9ce7b50c9..2f7582ae47 100644
--- a/src/gallium/state_trackers/nine/iunknown.h
+++ b/src/gallium/state_trackers/nine/iunknown.h
@@ -78,6 +78,7 @@ struct NineUnknownParams
 void (*dtor)(void *data);
 struct NineUnknown *container;
 struct NineDevice9 *device;
+bool start_with_bind_not_ref;
 };
 
 HRESULT
diff --git a/src/gallium/state_trackers/nine/nine_helpers.h 
b/src/gallium/state_trackers/nine/nine_helpers.h
index b382c5b72b..a0c55bd9ee 100644
--- a/src/gallium/state_trackers/nine/nine_helpers.h
+++ b/src/gallium/state_trackers/nine/nine_helpers.h
@@ -86,6 +86,7 @@ static inline void _nine_bind(void **dst, void *obj)
 __params.dtor = (void *)Nine##nine##_dtor; \
 __params.container = NULL; \
 __params.device = dev; \
+__params.start_with_bind_not_ref = false; \
 { \
 HRESULT __hr = Nine##nine##_ctor(__data, &__params, ## 
__VA_ARGS__); \
 if (FAILED(__hr)) { \
@@ -111,6 +112,7 @@ static inline void _nine_bind(void **dst, void *obj)
 __params.dtor = (void *)Nine##nine##_dtor; \
 __params.container = NULL; \
 __params.device = NULL; \
+__params.start_with_bind_not_ref = false; \
 { \
 HRESULT __hr = Nine##nine##_ctor(__data, &__params, ## 
__VA_ARGS__); \
 if (FAILED(__hr)) { \
-- 
2.18.0

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

[Mesa-dev] [PATCH 2/5] st/nine: Use perspective correction for ps depth fog

[Axel Davy]

Emulate perspective interpolation of depth for programmable ps fog

ff ps fog uses position z, or 1/w depending on the ff
projection matrix set. This is according to public documents
found describing the algorithm and tests we made.

In the case of programmable ps, we used position's z,
which was sufficient to pass wine tests (which test shaders
don't set w).

Issue https://github.com/iXit/Mesa-3D/issues/315 showed
that this calculation was wrong.
Using perspective interpolation on z, that is using z * 1/w
seems to satisfy both this application and wine tests.

Fixes: https://github.com/iXit/Mesa-3D/issues/315

Signed-off-by: Axel Davy 
---
 src/gallium/state_trackers/nine/nine_shader.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/src/gallium/state_trackers/nine/nine_shader.c 
b/src/gallium/state_trackers/nine/nine_shader.c
index 5b8ad3f161..913508fb88 100644
--- a/src/gallium/state_trackers/nine/nine_shader.c
+++ b/src/gallium/state_trackers/nine/nine_shader.c
@@ -3458,8 +3458,8 @@ shader_add_ps_fog_stage(struct shader_translator *tx, 
struct ureg_src src_col)
 struct ureg_program *ureg = tx->ureg;
 struct ureg_dst oCol0 = ureg_DECL_output(ureg, TGSI_SEMANTIC_COLOR, 0);
 struct ureg_src fog_end, fog_coeff, fog_density;
-struct ureg_src fog_vs, depth, fog_color;
-struct ureg_dst fog_factor;
+struct ureg_src fog_vs, fog_color;
+struct ureg_dst fog_factor, depth;
 
 if (!tx->info->fog_enable) {
 ureg_MOV(ureg, oCol0, src_col);
@@ -3467,8 +3467,10 @@ shader_add_ps_fog_stage(struct shader_translator *tx, 
struct ureg_src src_col)
 }
 
 if (tx->info->fog_mode != D3DFOG_NONE) {
-depth = nine_get_position_input(tx);
-depth = ureg_scalar(depth, TGSI_SWIZZLE_Z);
+depth = tx_scratch_scalar(tx);
+/* Depth used for fog is perspective interpolated */
+ureg_RCP(ureg, depth, ureg_scalar(nine_get_position_input(tx), 
TGSI_SWIZZLE_W));
+ureg_MUL(ureg, depth, ureg_src(depth), 
ureg_scalar(nine_get_position_input(tx), TGSI_SWIZZLE_Z));
 }
 
 nine_info_mark_const_f_used(tx->info, 33);
@@ -3478,16 +3480,16 @@ shader_add_ps_fog_stage(struct shader_translator *tx, 
struct ureg_src src_col)
 if (tx->info->fog_mode == D3DFOG_LINEAR) {
 fog_end = NINE_CONSTANT_SRC_SWIZZLE(33, X);
 fog_coeff = NINE_CONSTANT_SRC_SWIZZLE(33, Y);
-ureg_ADD(ureg, fog_factor, fog_end, ureg_negate(depth));
+ureg_ADD(ureg, fog_factor, fog_end, ureg_negate(ureg_src(depth)));
 ureg_MUL(ureg, ureg_saturate(fog_factor), tx_src_scalar(fog_factor), 
fog_coeff);
 } else if (tx->info->fog_mode == D3DFOG_EXP) {
 fog_density = NINE_CONSTANT_SRC_SWIZZLE(33, X);
-ureg_MUL(ureg, fog_factor, depth, fog_density);
+ureg_MUL(ureg, fog_factor, ureg_src(depth), fog_density);
 ureg_MUL(ureg, fog_factor, tx_src_scalar(fog_factor), ureg_imm1f(ureg, 
-1.442695f));
 ureg_EX2(ureg, fog_factor, tx_src_scalar(fog_factor));
 } else if (tx->info->fog_mode == D3DFOG_EXP2) {
 fog_density = NINE_CONSTANT_SRC_SWIZZLE(33, X);
-ureg_MUL(ureg, fog_factor, depth, fog_density);
+ureg_MUL(ureg, fog_factor, ureg_src(depth), fog_density);
 ureg_MUL(ureg, fog_factor, tx_src_scalar(fog_factor), 
tx_src_scalar(fog_factor));
 ureg_MUL(ureg, fog_factor, tx_src_scalar(fog_factor), ureg_imm1f(ureg, 
-1.442695f));
 ureg_EX2(ureg, fog_factor, tx_src_scalar(fog_factor));
-- 
2.18.0

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

[Mesa-dev] [Bug 107873] Doom 2016 - Rendering issues

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107873

--- Comment #2 from Bas Nieuwenhuizen  ---
So just to check, you enabled Vulkan instead of GL rendering? Doom is using GL
by default.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Request for Mentor - XorgEvoc - Piglit for VA-API

[Christian König]

Am 09.09.2018 um 12:49 schrieb Naveen Naidu:
On Sun 9 Sep, 2018, 4:06 PM Christian König, 
> wrote:


Am 09.09.2018 um 09:55 schrieb Naveen Naidu:


Thank you for the information. Yes I have a AMD GPU, It is a
Radeon r5 m430. But unfortunately it does not have a video
decoder. But I also have an integrated Intel HD 620 GPU, it's a
kabylake and It had a video encoder and video decoder. I have
already discussed about this with Alex Deuscher and he said that
I will be fine with Intel HD 620 and I can carry on with the project.

If you don't mind can you please let me know if i am on the right
track?


Yeah, that should indeed work from the hardware side.

But it could be a problem for mentoring you since we are obviously
interested in improving the VA-API state tracker for AMD hardware.


Does this mean I cannot work on this project?


Well it depends. It means that you won't test with AMD hardware. So if 
you mentor works for AMD and doesn't has the Intel stack available it 
could get really tricky to reproduce and test things.


On the other hand you could ask if one of the Intel guys wants to mentor 
you.


Will it be okay, If I write a proposal using the current hardware and 
once the proposal get selected, I could buy the required hardware.


That could work, but I'm not sure if that fits the requirements for a 
proposal from Google.



Is it possible to write a proposal without the hardware?

It would be really kind of you, if you could let me know any other 
project that is compatible with my hardware.


 I was also looking into the project "Unit Performance tests for VA-API".

Will this be a suitable fit with my hardware.


Same problem with that one.

Regards,
Christian.






Thank you very much for your time

P.S:- Sorry for the starting a new thread with the last mail. I
am new to mailing list. I will see to that I do not repeat the
same mistake.


Well starting a new thread is not much of an issue, but you could
at least remove the digest mail body :)

Regards,
Christian.



P . Naveen Naidu





___
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] [Bug 107873] Doom 2016 - Rendering issues

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107873

Jason Ekstrand  changed:

   What|Removed |Added

 QA Contact||mesa-dev@lists.freedesktop.
   ||org
  Component|Drivers/Vulkan/Common   |Drivers/Vulkan/radeon

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 107873] Doom 2016 - Rendering issues

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107873

--- Comment #1 from Ahmed Elsayed  ---
System information:

Operating system: Manjaro KDE (the latest version).

GPU: AMD HD 8750M

Driver: 18.2.0-1

Wine version: 3.15 staging

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 107873] Doom 2016 - Rendering issues

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107873

Bug ID: 107873
   Summary: Doom 2016 - Rendering issues
   Product: Mesa
   Version: 18.2
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/Common
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: ahmed@aol.com
CC: airl...@freedesktop.org, chadvers...@chromium.org,
dan...@fooishbar.org, ja...@jlekstrand.net

I can't run Doom 2016 with Mesa 18.1.7 or Mesa 18.1.8, so I tried Mesa 18.2.0-1
and the game started but it will start with the intro that looks like a green
artifacts, then it loads and the loading screen in green instead of red, then I
can hear the menu sounds but I can't see the menu because of the red fog that
covers all the screen, and I have to press alt+f4 to end it.

I tried 3 times to record .apitrace file but it doesn't produce any file that I
can upload.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 105333] [gallium-nine] missing geometry after commit ac: replace ac_build_kill with ac_build_kill_if_false

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105333

--- Comment #6 from Axel Davy  ---
Given the regression bisect found the issue came with a radeonsi patch, I
reassign to radeonsi. Maybe the patch introduces a small difference in the
driver behaviour that regresses nine ?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 105333] [gallium-nine] missing geometry after commit ac: replace ac_build_kill with ac_build_kill_if_false

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105333

Axel Davy  changed:

   What|Removed |Added

  Component|Gallium/StateTracker/galliu |Drivers/Gallium/radeonsi
   |mnine   |
   Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org
 CC||mar...@gmail.com
 QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 107777] No 3D in "Vampire: The Masquerade - Bloodlines" when d3d-nine enabled

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=10

--- Comment #5 from Axel Davy  ---
Could you try to launch the game in a wine virtual desktop (see winecfg) see if
the issue is unaffected ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Request for Mentor - XorgEvoc - Piglit for VA-API

[Naveen Naidu]

On Sun 9 Sep, 2018, 4:06 PM Christian König, <
ckoenig.leichtzumer...@gmail.com> wrote:

> Am 09.09.2018 um 09:55 schrieb Naveen Naidu:
>
>
> Thank you for the information. Yes I have a AMD GPU, It is a Radeon r5
> m430. But unfortunately it does not have a video decoder. But I also have
> an integrated Intel HD 620 GPU, it's a kabylake and It had a video encoder
> and video decoder. I have already discussed about this with Alex Deuscher
> and he said that I will be fine with Intel HD 620 and I can carry on with
> the project.
>
> If you don't mind can you please let me know if i am on the right track?
>
>
> Yeah, that should indeed work from the hardware side.
>
> But it could be a problem for mentoring you since we are obviously
> interested in improving the VA-API state tracker for AMD hardware.
>

Does this mean I cannot work on this project? Will it be okay, If I write a
proposal using the current hardware and once the proposal get selected, I
could buy the required hardware.

Is it possible to write a proposal without the hardware?

It would be really kind of you, if you could let me know any other project
that is compatible with my hardware.

 I was also looking into the project "Unit Performance tests for VA-API".

Will this be a suitable fit with my hardware.


>
> Thank you very much for your time
>
> P.S:- Sorry for the starting a new thread with the last mail. I am new to
> mailing list. I will see to that I do not repeat the same mistake.
>
>
> Well starting a new thread is not much of an issue, but you could at least
> remove the digest mail body :)
>
> Regards,
> Christian.
>
>
> P . Naveen Naidu
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Request for Mentor - XorgEvoc - Piglit for VA-API

[Christian König]

Am 09.09.2018 um 09:55 schrieb Naveen Naidu:


Thank you for the information. Yes I have a AMD GPU, It is a Radeon r5 
m430. But unfortunately it does not have a video decoder. But I also 
have an integrated Intel HD 620 GPU, it's a kabylake and It had a 
video encoder and video decoder. I have already discussed about this 
with Alex Deuscher and he said that I will be fine with Intel HD 620 
and I can carry on with the project.


If you don't mind can you please let me know if i am on the right track?


Yeah, that should indeed work from the hardware side.

But it could be a problem for mentoring you since we are obviously 
interested in improving the VA-API state tracker for AMD hardware.




Thank you very much for your time

P.S:- Sorry for the starting a new thread with the last mail. I am new 
to mailing list. I will see to that I do not repeat the same mistake.


Well starting a new thread is not much of an issue, but you could at 
least remove the digest mail body :)


Regards,
Christian.



P . Naveen Naidu



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

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/3] android: broadcom/genxml: fix collision with intel/genxml header-gen macro

[Mauro Rossi]

Hi,

Il giorno gio 6 set 2018 alle ore 18:20 Dylan Baker
 ha scritto:
>
> Quoting Rob Herring (2018-09-06 07:16:07)
> > On Mon, Sep 3, 2018 at 4:27 PM Eric Anholt  wrote:
> > >
> > > Mauro Rossi  writes:
> > >
> > > > Fixes the following building error, happening when building both intel 
> > > > and broadcom:
> > >
> > > I wish someone maintaining android Mesa would work on making the meson
> > > build work for them instead of just continuing to maintain the
> > > Android.mk mess.
> >
> > Trust me, no one likes this thankless job.
> >
> > How do you envision that would work without meson support in the
> > Android build system? I went down the path of defining a "prebuilt"
> > Android.mk target which calls meson to do a build. This was a dead end
> > because the Android.mk gets none of the build environment. It's
> > possible to dump all that out and re-construct those settings. That
> > seems horribly fragile, and I'd guess we'd just be switching from mesa
> > to AOSP breaking the build. Of course the latter already happens too.
> > Finally, I'm pretty sure this would not be accepted for the AOSP copy
> > of mesa (which is trying to track mainline).
> >
> > The other route would be some sort automatic meson to Android BP build
> > file translation. Such a thing exists for autotools, but I've never
> > seen it in actual use anywhere.
> >
> > Either way, this seems like a unicorn to me until AOSP provides some
> > support to support meson. If you really want to force the issue, strip
> > all the Android.mk files out of mesa. Though that will mainly put the
> > pain on downstream device trees, not AOSP.
> >
> > Rob
>
> With my meson hat on,
>
> I've been looking at blueprint recently, trying to decide if we could 
> implement
> a meson-for-android on top of blueprint. While I know a lot about meson (I've
> written a bunch of the meson implementation), I don't know a lot about 
> blueprint
> and their documentation is basically aimed at explaining how soong works. I
> certainly can't commit to full time development on a meson-on-blueprint
> implementation, but I certainly could help write one if there was someone
> interested in working on it as well. It would also be helpful if there was
> someone in the blueprint camp who could tell me whether such a thing is even
> feasible or not.
>
> Dylan

I can comment that when talking about the patching process in Mesa,
it is very much clear when Android.mk changes are needed
and there are many people currently supporting Android.mk and in the
last three years
there was much attention to keep Android.mk in good shape.
That's why it is in good shape.

In my understanding kati for building with Android.mk will be dropped
at some point,
Android.bp will be the only building script language supported by AOSP.

Android.bp will be easier to mantain than Android.mk, because Android.bp
is intentionally very similar to Bazel build script language,
which should have corresponding objects and grammar/syntax rules than
can be translated or visually inspected, if people will continue to
care.

IMHO .go language scripts should not be used when unnecessary, for
architecture conditionals and genrules that may be supported in
Android.bp
but environement variables, if I understood correctly, will require
.go script because of how Blueprint is inspired to Bazel but not
identical.
I'm still wondering if a .go-less Android.bp may be feasible

So options are:

1. Use the androidmk parser / blueprint_tools to perform the draft
translation, then huge work to fix the Android.bp build through all
the tree.
2. meson to Android.bp parser/translator - this would be interesting,
if we could find a way to generate the .go which is not tackled with
in 1.,or surrogate rules in bp
3. Go to Google  ninja-build forums if they have plans to perform
feasibility analysis and develop soong to accept meson directly (In
the long term it is a Win for them)
4. Go to Google Build forum and propose a meson-to-bp added to
blueprint_tools (and have part of this task driven by them  - A
clearly mesa is not the only project using meson)
5. Propose Google to setup one/two projects for next GSoC in area 3. and 4.
6. Wait for Google be at the milestone of kati/Android.mk demise and
see how they will build mesa.

I am interested in contributing in part of my spare time.

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

Re: [Mesa-dev] Request for Mentor - XorgEvoc - Piglit for VA-API

[Naveen Naidu]

_api_create_context(struct st_api *stapi, struct
> st_manager *smapi,
> > > struct st_context *shared_ctx = (struct st_context *)
> shared_stctxi;
> > > struct st_context *st;
> > > struct pipe_context *pipe;
> > > +   struct gl_config* mode_ptr;
> > > struct gl_config mode;
> > > gl_api api;
> > > bool no_error = false;
> > > @@ -893,7 +894,13 @@ st_api_create_context(struct st_api *stapi,
> struct st_manager *smapi,
> > > }
> > >
> > > st_visual_to_context_mode(>visual, );
> > > -   st = st_create_context(api, pipe, , shared_ctx,
> > > +
> > > +   if (attribs->visual.no_config)
> > > +  mode_ptr = NULL;
> > > +   else
> > > +  mode_ptr = 
> > > +
> > > +   st = st_create_context(api, pipe, mode_ptr, shared_ctx,
> > >>options, no_error);
> > > if (!st) {
> > >*error = ST_CONTEXT_ERROR_NO_MEMORY;
> > > --
> > > 2.18.0
> > >
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
> --
>
> Message: 2
> Date: Sat, 8 Sep 2018 22:22:27 -0700
> From: Vinson Lee 
> To: Marek Olšák 
> Cc: ML mesa-dev 
> Subject: Re: [Mesa-dev] [PATCH 2/2] gallium: try to fix the Windows
> build
> Message-ID:
>  rcy6uw4pkj9map-nc...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Sat, Sep 8, 2018 at 6:02 PM, Marek Olšák  wrote:
> > From: Marek Olšák 
> >
> > Windows doesn't have thrd_current.
> > ---
> >  src/gallium/auxiliary/util/u_helpers.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/src/gallium/auxiliary/util/u_helpers.c
> b/src/gallium/auxiliary/util/u_helpers.c
> > index f773360..8095242 100644
> > --- a/src/gallium/auxiliary/util/u_helpers.c
> > +++ b/src/gallium/auxiliary/util/u_helpers.c
> > @@ -127,20 +127,21 @@ util_upload_index_buffer(struct pipe_context *pipe,
> >   * The function pins the current thread and driver threads to a group of
> >   * CPU cores that share the same L3 cache. This is needed for good
> multi-
> >   * threading performance on AMD Zen CPUs.
> >   *
> >   * \param upper_thread  thread in the state tracker that also needs to
> be
> >   *  pinned.
> >   */
> >  void
> >  util_context_thread_changed(struct pipe_context *ctx, thrd_t
> *upper_thread)
> >  {
> > +#ifdef HAVE_PTHREAD
> > thrd_t current = thrd_current();
> > int cache = util_get_L3_for_pinned_thread(current,
> >
>  util_cpu_caps.cores_per_L3);
> >
> > /* If the main thread is not pinned, choose the L3 cache. */
> > if (cache == -1) {
> >unsigned num_caches = util_cpu_caps.nr_cpus /
> >  util_cpu_caps.cores_per_L3;
> >static unsigned last_cache;
> >
> > @@ -151,20 +152,21 @@ util_context_thread_changed(struct pipe_context
> *ctx, thrd_t *upper_thread)
> >
> > /* Tell the driver to pin its threads to the same L3 cache. */
> > if (ctx->set_context_param) {
> >ctx->set_context_param(ctx,
> PIPE_CONTEXT_PARAM_PIN_THREADS_TO_L3_CACHE,
> >   cache);
> > }
> >
> > /* Do the same for the upper level thread if there is any (e.g.
> glthread) */
> > if (upper_thread)
> >util_pin_thread_to_L3(*upper_thread, cache,
> util_cpu_caps.cores_per_L3);
> > +#endif
> >  }
> >
> >  /* This is a helper for hardware bring-up. Don't remove. */
> >  struct pipe_query *
> >  util_begin_pipestat_query(struct pipe_context *ctx)
> >  {
> > struct pipe_query *q =
> >ctx->create_query(ctx, PIPE_QUERY_PIPELINE_STATISTICS, 0);
> > if (!q)
> >return NULL;
> > --
> > 2.7.4
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> Tested-by: Vinson Lee 
>
>
> --
>
> Message: 3
> Date: Sun, 09 Sep 2018 05:34:28 +
> From: bugzilla-dae...@freedesktop.org
> To: mesa-dev@lists.freedesktop.org
> Subject: [Mesa-dev] [Bug 107870] Undefined symbols for architecture
> x86_64: "_util_cpu_caps"
> Me

Re: [Mesa-dev] [PATCH] utils/u_math: break dependency on gallium/utils

[Marek Olšák]

I think this will break non-GL gallium state trackers. src/mesa is
only for GL, which is why common gallium code and gallium drivers
can't use code from src/mesa.

Marek

On Sun, Sep 9, 2018 at 2:39 AM, Dylan Baker  wrote:
> Currently u_math needs gallium utils for cpu detection.  Most of what
> u_math uses out of u_cpu_detection is duplicated in src/mesa/x86
> (surprise!), so I've just reworked it as much as possible to use the
> x86/common_x86_features macros instead of the gallium ones. There is
> one small function that was copied over, as promoting u_cpu_detection is
> itself a fairly hefty undertaking, as it depends on u_debug, and this
> fixes the bug for now.
>
> bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107870
> cc: v...@freedesktop.org
> ---
>
> I have no idea if this fixes the build on mac, I had this in a branch where I
> started replacing more of imports.{h,c} with utils stuff, and this fixes some
> build problems on Linux. I don't have a mac to test on and I wont until 
> Monday.
> If this works let me know.
>
>  src/util/u_math.c | 43 ++-
>  1 file changed, 38 insertions(+), 5 deletions(-)
>
> diff --git a/src/util/u_math.c b/src/util/u_math.c
> index c58af911be7..bf0c398eeec 100644
> --- a/src/util/u_math.c
> +++ b/src/util/u_math.c
> @@ -29,7 +29,7 @@
>
>  #include "pipe/p_config.h"
>  #include "util/u_math.h"
> -#include "util/u_cpu_detect.h"
> +#include "x86/common_x86_features.h"
>
>  #if defined(PIPE_ARCH_SSE)
>  #include 
> @@ -90,7 +90,7 @@ util_fpstate_get(void)
> unsigned mxcsr = 0;
>
>  #if defined(PIPE_ARCH_SSE)
> -   if (util_cpu_caps.has_sse) {
> +   if (cpu_has_xmm) {
>mxcsr = _mm_getcsr();
> }
>  #endif
> @@ -98,6 +98,31 @@ util_fpstate_get(void)
> return mxcsr;
>  }
>
> +/* TODO: this was copied from u_cpu_detection. It's another case of 
> duplication
> + * between gallium and core mesa, and it would be nice to get rid of that
> + * duplication as well.
> + */
> +#if defined(PIPE_ARCH_X86)
> +PIPE_ALIGN_STACK static inline bool sse2_has_daz(void)
> +{
> +   struct {
> +  uint32_t pad1[7];
> +  uint32_t mxcsr_mask;
> +  uint32_t pad2[128-8];
> +   } PIPE_ALIGN_VAR(16) fxarea;
> +
> +   fxarea.mxcsr_mask = 0;
> +#if defined(PIPE_CC_GCC)
> +   __asm __volatile ("fxsave %0" : "+m" (fxarea));
> +#elif defined(PIPE_CC_MSVC) || defined(PIPE_CC_ICL)
> +   _fxsave();
> +#else
> +   fxarea.mxcsr_mask = 0;
> +#endif
> +   return !!(fxarea.mxcsr_mask & (1 << 6));
> +}
> +#endif
> +
>  /**
>   * Make sure that the fp treats the denormalized floating
>   * point numbers as zero.
> @@ -108,13 +133,21 @@ unsigned
>  util_fpstate_set_denorms_to_zero(unsigned current_mxcsr)
>  {
>  #if defined(PIPE_ARCH_SSE)
> -   if (util_cpu_caps.has_sse) {
> +   if (cpu_has_xmm) {
>/* Enable flush to zero mode */
>current_mxcsr |= _MM_FLUSH_ZERO_MASK;
> -  if (util_cpu_caps.has_daz) {
> +  /* x86_64 cpus always have daz, as do cpus with sse3 in fact, there's
> +   * basically only a handful of very early pentium 4's that have sse2 
> but
> +   * not daz.
> +   */
> +# if !defined(PIPE_ARCH_x86_64) && !defined(PIPE_ARCH_SSSE3)
> +  if (sse2_has_daz()) {
> +# endif
>   /* Enable denormals are zero mode */
>   current_mxcsr |= _MM_DENORMALS_ZERO_MASK;
> +# if !defined(PIPE_ARCH_x86_64) && !defined(PIPE_ARCH_SSSE3)
>}
> +#endif
>util_fpstate_set(current_mxcsr);
> }
>  #endif
> @@ -130,7 +163,7 @@ void
>  util_fpstate_set(unsigned mxcsr)
>  {
>  #if defined(PIPE_ARCH_SSE)
> -   if (util_cpu_caps.has_sse) {
> +   if (cpu_has_xmm) {
>_mm_setcsr(mxcsr);
> }
>  #endif
> --
> 2.18.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] mesa-dev Digest, Vol 102, Issue 134

[Naveen Naidu]

> -   st = st_create_context(api, pipe, , shared_ctx,
> > > +
> > > +   if (attribs->visual.no_config)
> > > +  mode_ptr = NULL;
> > > +   else
> > > +  mode_ptr = 
> > > +
> > > +   st = st_create_context(api, pipe, mode_ptr, shared_ctx,
> > >>options, no_error);
> > > if (!st) {
> > >*error = ST_CONTEXT_ERROR_NO_MEMORY;
> > > --
> > > 2.18.0
> > >
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
> --
>
> Message: 2
> Date: Sat, 8 Sep 2018 22:22:27 -0700
> From: Vinson Lee 
> To: Marek Olšák 
> Cc: ML mesa-dev 
> Subject: Re: [Mesa-dev] [PATCH 2/2] gallium: try to fix the Windows
> build
> Message-ID:
>  rcy6uw4pkj9map-nc...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Sat, Sep 8, 2018 at 6:02 PM, Marek Olšák  wrote:
> > From: Marek Olšák 
> >
> > Windows doesn't have thrd_current.
> > ---
> >  src/gallium/auxiliary/util/u_helpers.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/src/gallium/auxiliary/util/u_helpers.c
> b/src/gallium/auxiliary/util/u_helpers.c
> > index f773360..8095242 100644
> > --- a/src/gallium/auxiliary/util/u_helpers.c
> > +++ b/src/gallium/auxiliary/util/u_helpers.c
> > @@ -127,20 +127,21 @@ util_upload_index_buffer(struct pipe_context *pipe,
> >   * The function pins the current thread and driver threads to a group of
> >   * CPU cores that share the same L3 cache. This is needed for good
> multi-
> >   * threading performance on AMD Zen CPUs.
> >   *
> >   * \param upper_thread  thread in the state tracker that also needs to
> be
> >   *  pinned.
> >   */
> >  void
> >  util_context_thread_changed(struct pipe_context *ctx, thrd_t
> *upper_thread)
> >  {
> > +#ifdef HAVE_PTHREAD
> > thrd_t current = thrd_current();
> > int cache = util_get_L3_for_pinned_thread(current,
> >
>  util_cpu_caps.cores_per_L3);
> >
> > /* If the main thread is not pinned, choose the L3 cache. */
> > if (cache == -1) {
> >unsigned num_caches = util_cpu_caps.nr_cpus /
> >  util_cpu_caps.cores_per_L3;
> >static unsigned last_cache;
> >
> > @@ -151,20 +152,21 @@ util_context_thread_changed(struct pipe_context
> *ctx, thrd_t *upper_thread)
> >
> > /* Tell the driver to pin its threads to the same L3 cache. */
> > if (ctx->set_context_param) {
> >ctx->set_context_param(ctx,
> PIPE_CONTEXT_PARAM_PIN_THREADS_TO_L3_CACHE,
> >   cache);
> > }
> >
> > /* Do the same for the upper level thread if there is any (e.g.
> glthread) */
> > if (upper_thread)
> >util_pin_thread_to_L3(*upper_thread, cache,
> util_cpu_caps.cores_per_L3);
> > +#endif
> >  }
> >
> >  /* This is a helper for hardware bring-up. Don't remove. */
> >  struct pipe_query *
> >  util_begin_pipestat_query(struct pipe_context *ctx)
> >  {
> > struct pipe_query *q =
> >ctx->create_query(ctx, PIPE_QUERY_PIPELINE_STATISTICS, 0);
> > if (!q)
> >return NULL;
> > --
> > 2.7.4
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> Tested-by: Vinson Lee 
>
>
> --
>
> Message: 3
> Date: Sun, 09 Sep 2018 05:34:28 +
> From: bugzilla-dae...@freedesktop.org
> To: mesa-dev@lists.freedesktop.org
> Subject: [Mesa-dev] [Bug 107870] Undefined symbols for architecture
> x86_64: "_util_cpu_caps"
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
>
> https://bugs.freedesktop.org/show_bug.cgi?id=107870
>
> Bug ID: 107870
>Summary: Undefined symbols for architecture x86_64:
> "_util_cpu_caps"
>Product: Mesa
>Version: git
>   Hardware: x86-64 (AMD64)
> OS: Mac OS X (All)
> Status: NEW
>   Keywords: regression
>   Severity: normal
>   Priority: medium
>  Component: Mesa core
>   Assignee: mesa-dev@lists.freede

[Mesa-dev] [Bug 107870] Undefined symbols for architecture x86_64: "_util_cpu_caps"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107870

--- Comment #1 from Dylan Baker  ---
I've sent a patch to the list that hopefully fixes this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 107870] Undefined symbols for architecture x86_64: "_util_cpu_caps"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107870

Dylan Baker  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |baker.dyla...@gmail.com
   |org |

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Request for Mentor - XorgEvoc - Piglit for VA-API

[Benson Muite]

Welcome! From the page:

https://www.x.org/wiki/SummerOfCodeIdeas/

Might try and ping Christian König. Do you have an AMD GPU?

Benson

On 09/09/2018 09:41 AM, Naveen Naidu wrote:

Hello Everyone,

I am Naveen a Junior year computer science undergrad from India. I 
really apologize for disturbing you all again. But I have been going 
through the available projects for the XorgEVoC program and the 
project *Piglit for VA-API *caught my attention. I have mailed last 
week looking out for mentors for the project, but unfortunately this 
email did not receive attention due to the busy schedule at Xorg I guess.


I have been working on the project since the last time I mailed asking 
for directions. As Alex mentioned in his reply, I have read through 
the piglit documentation and am now sufficiently familiar with piglit.


Things that I have done until now:-

 1. Read through the Piglit documentation (Capable of understanding
and writing small tests using piglit)
 2. Compiled gstreamer, and also set up the gst-uninstalled environment.
 3. Understood about the architecture of gstreamer.
 4. Currently reading about VA-API.
 5. Planning to implement a simple VA-API app to better understand the
type of tests I need to write for VA-API


I am comfortable with both C and Python and given the skill set I am 
confident of accomplishing the project. I would thus like to discuss 
the details and deliverable of the project with my potential mentor 
and would like to know how I can proceed with the project.


Since no potential mentor was mentioned in the Idea's Page, it would 
be really kind of someone if they are willing to be a mentor for the 
project. I can assure you that I will put the best of my efforts and 
dedication into the project and will see that the project is completed.


Thank you for your valuable time.

Regards,
Naveen Naidu
https://github.com/Naveenaidu



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

[Mesa-dev] Request for Mentor - XorgEvoc - Piglit for VA-API

[Naveen Naidu]

Hello Everyone,

I am Naveen a Junior year computer science undergrad from India. I really
apologize for disturbing you all again. But I have been going through the
available projects for the XorgEVoC program and the project *Piglit for
VA-API *caught my attention. I have mailed last week looking out for
mentors for the project, but unfortunately this email did not receive
attention due to the busy schedule at Xorg I guess.

I have been working on the project since the last time I mailed asking for
directions. As Alex mentioned in his reply, I have read through the piglit
documentation and am now sufficiently familiar with piglit.

Things that I have done until now:-

   1. Read through the Piglit documentation (Capable of understanding and
   writing small tests using piglit)
   2. Compiled gstreamer, and also set up the gst-uninstalled environment.
   3. Understood about the architecture of gstreamer.
   4. Currently reading about VA-API.
   5. Planning to implement a simple VA-API app to better understand the
   type of tests I need to write for VA-API


I am comfortable with both C and Python and given the skill set I am
confident of accomplishing the project. I would thus like to discuss the
details and deliverable of the project with my potential mentor and would
like to know how I can proceed with the project.

Since no potential mentor was mentioned in the Idea's Page, it would be
really kind of someone if they are willing to be a mentor for the project.
I can assure you that I will put the best of my efforts and dedication into
the project and will see that the project is completed.

Thank you for your valuable time.

Regards,
Naveen Naidu
https://github.com/Naveenaidu
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] utils/u_math: break dependency on gallium/utils

[Dylan Baker]

Currently u_math needs gallium utils for cpu detection.  Most of what
u_math uses out of u_cpu_detection is duplicated in src/mesa/x86
(surprise!), so I've just reworked it as much as possible to use the
x86/common_x86_features macros instead of the gallium ones. There is
one small function that was copied over, as promoting u_cpu_detection is
itself a fairly hefty undertaking, as it depends on u_debug, and this
fixes the bug for now.

bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107870
cc: v...@freedesktop.org
---

I have no idea if this fixes the build on mac, I had this in a branch where I
started replacing more of imports.{h,c} with utils stuff, and this fixes some
build problems on Linux. I don't have a mac to test on and I wont until Monday.
If this works let me know.

 src/util/u_math.c | 43 ++-
 1 file changed, 38 insertions(+), 5 deletions(-)

diff --git a/src/util/u_math.c b/src/util/u_math.c
index c58af911be7..bf0c398eeec 100644
--- a/src/util/u_math.c
+++ b/src/util/u_math.c
@@ -29,7 +29,7 @@
 
 #include "pipe/p_config.h"
 #include "util/u_math.h"
-#include "util/u_cpu_detect.h"
+#include "x86/common_x86_features.h"
 
 #if defined(PIPE_ARCH_SSE)
 #include 
@@ -90,7 +90,7 @@ util_fpstate_get(void)
unsigned mxcsr = 0;
 
 #if defined(PIPE_ARCH_SSE)
-   if (util_cpu_caps.has_sse) {
+   if (cpu_has_xmm) {
   mxcsr = _mm_getcsr();
}
 #endif
@@ -98,6 +98,31 @@ util_fpstate_get(void)
return mxcsr;
 }
 
+/* TODO: this was copied from u_cpu_detection. It's another case of duplication
+ * between gallium and core mesa, and it would be nice to get rid of that
+ * duplication as well.
+ */
+#if defined(PIPE_ARCH_X86)
+PIPE_ALIGN_STACK static inline bool sse2_has_daz(void)
+{
+   struct {
+  uint32_t pad1[7];
+  uint32_t mxcsr_mask;
+  uint32_t pad2[128-8];
+   } PIPE_ALIGN_VAR(16) fxarea;
+
+   fxarea.mxcsr_mask = 0;
+#if defined(PIPE_CC_GCC)
+   __asm __volatile ("fxsave %0" : "+m" (fxarea));
+#elif defined(PIPE_CC_MSVC) || defined(PIPE_CC_ICL)
+   _fxsave();
+#else
+   fxarea.mxcsr_mask = 0;
+#endif
+   return !!(fxarea.mxcsr_mask & (1 << 6));
+}
+#endif
+
 /**
  * Make sure that the fp treats the denormalized floating
  * point numbers as zero.
@@ -108,13 +133,21 @@ unsigned
 util_fpstate_set_denorms_to_zero(unsigned current_mxcsr)
 {
 #if defined(PIPE_ARCH_SSE)
-   if (util_cpu_caps.has_sse) {
+   if (cpu_has_xmm) {
   /* Enable flush to zero mode */
   current_mxcsr |= _MM_FLUSH_ZERO_MASK;
-  if (util_cpu_caps.has_daz) {
+  /* x86_64 cpus always have daz, as do cpus with sse3 in fact, there's
+   * basically only a handful of very early pentium 4's that have sse2 but
+   * not daz.
+   */
+# if !defined(PIPE_ARCH_x86_64) && !defined(PIPE_ARCH_SSSE3)
+  if (sse2_has_daz()) {
+# endif
  /* Enable denormals are zero mode */
  current_mxcsr |= _MM_DENORMALS_ZERO_MASK;
+# if !defined(PIPE_ARCH_x86_64) && !defined(PIPE_ARCH_SSSE3)
   }
+#endif
   util_fpstate_set(current_mxcsr);
}
 #endif
@@ -130,7 +163,7 @@ void
 util_fpstate_set(unsigned mxcsr)
 {
 #if defined(PIPE_ARCH_SSE)
-   if (util_cpu_caps.has_sse) {
+   if (cpu_has_xmm) {
   _mm_setcsr(mxcsr);
}
 #endif
-- 
2.18.0

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