[Mesa-dev] [PATCH] nouveau: when mapping a persistent buffer, synchronize on former xfers

2017-04-08 Thread Ilia Mirkin
If the buffer is being used, we should wait for those uses to be
complete before returning the map.

Fixes: GL45-CTS.direct_state_access.buffers_functional
Signed-off-by: Ilia Mirkin 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/nouveau/nouveau_buffer.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c 
b/src/gallium/drivers/nouveau/nouveau_buffer.c
index 17052b2..2c60441 100644
--- a/src/gallium/drivers/nouveau/nouveau_buffer.c
+++ b/src/gallium/drivers/nouveau/nouveau_buffer.c
@@ -406,9 +406,6 @@ nouveau_buffer_transfer_map(struct pipe_context *pipe,
!util_ranges_intersect(&buf->valid_buffer_range, box->x, box->x + 
box->width))
   usage |= PIPE_TRANSFER_DISCARD_RANGE | PIPE_TRANSFER_UNSYNCHRONIZED;
 
-   if (usage & PIPE_TRANSFER_PERSISTENT)
-  usage |= PIPE_TRANSFER_UNSYNCHRONIZED;
-
if (buf->domain == NOUVEAU_BO_VRAM) {
   if (usage & NOUVEAU_TRANSFER_DISCARD) {
  /* Set up a staging area for the user to write to. It will be copied
@@ -476,7 +473,8 @@ nouveau_buffer_transfer_map(struct pipe_context *pipe,
 * complete its operation, or set up a staging area to perform our work in.
 */
if (nouveau_buffer_busy(buf, usage & PIPE_TRANSFER_READ_WRITE)) {
-  if (unlikely(usage & PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE)) {
+  if (unlikely(usage & (PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE |
+PIPE_TRANSFER_PERSISTENT))) {
  /* Discarding was not possible, must sync because
   * subsequent transfers might use UNSYNCHRONIZED. */
  nouveau_buffer_sync(nv, buf, usage & PIPE_TRANSFER_READ_WRITE);
-- 
2.10.2

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


Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)

2017-04-08 Thread Jose Fonseca

On 08/04/17 00:24, Dylan Baker wrote:

Quoting Jose Fonseca (2017-03-30 15:19:31)


Cool.  BTW, another alternative (for things like LLVM) would  be to
chain build systems (ie, have a wrap that builds LLVM invoking CMake)

Jose



I have no idea whether chaining would work or not, that would be an interesting
thing to try.

I have force pushed to the meson branch. Things are building on Linux with both
mingw, gcc, and clang. I've wrapped freeglut and glew, and pulled out the epoxy
stuff. The mingw cross build does rely on an unmerged patch (that is approved,
just awaiting merge) for mingw windres support in the cross file. That shouldn't
be a problem for msvc or building natively with mingw.

I have not done any of the msvc work or either mesa-demos or for freeglut or
glew. Hopefully this gets things far enough along that you can get msvc going
when you have some time.

Dylan



Thanks.  I hit an errors early on with MSVC.

I fixed a few, but I didn't spend much time on it.  Instead I added 
AppVeyor integration so anybody can experiment.



https://ci.appveyor.com/project/jrfonseca/mesademos/build/job/qysf73s4975i2w36

  https://cgit.freedesktop.org/~jrfonseca/mesademos/log/?h=meson-appveyor

I had to push to a private git repos since I'd need a FDO admin to 
install Appveyor hook on the official mesa demos repo.  I'll get that 
going but it'll probably take time.


Given you use Github, it should be trivial to hook Appveyor on your 
mesademos repos in github.


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


[Mesa-dev] [PATCH shader-db] Add ".so" shared objects to .gitignore

2017-04-08 Thread Rhys Kidd
For intel_stubs.so

Signed-off-by: Rhys Kidd 
---

I don't have commit access, so I would appreciate a reviewer pushing this to
master.

 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index f69750a..95a04f6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 bin
 run
+*.so
-- 
2.9.3

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


Re: [Mesa-dev] [PATCH 2/2] egl, dri: Propagate context priority hint to driver->CreateContext

2017-04-08 Thread Emil Velikov
On 7 April 2017 at 09:50, Chris Wilson  wrote:
> On Thu, Apr 06, 2017 at 08:29:55PM -0400, Rob Clark wrote:
>> On Thu, Apr 6, 2017 at 3:12 PM, Chris Wilson  
>> wrote:
>> > Jump through the layers of abstraction between egl and dri in order to
>> > feed the context priority attribute through to the backend. This
>> > requires us to read the value from the base _egl_context, convert it to
>> > a DRI attribute, parse it again in the generic context creater before
>> > passing it to the driver as a function parameter.
>> >
>> > Issues:
>> >
>> >  * How to pass back the priority of the create context (as it may be
>> > modified by the driver) back to EGL?
>>
>> Maybe driver provides a bitmask of supportable priority levels, and
>> then EGL clamps?  Or a NumPriorityLevels param?  That avoids needing
>> to get the value back from the driver and at least works for the
>> situations I can think of.  (Ie. either kernel+hw support multiple
>> priority levels or it doesn't.)  Maybe with an additional system level
>> limit, ie. maybe only compositor can be highest priority.. but that
>> seems like a system level thing rather than driver level thing, so
>> should be in EGL?
>
> We mirrored our kernel API around nice(2) in that we allow anybody to
> reduce their priority, but only a privileged process can raise it above
> 0. To be accurate, I was going to use the result of the context priority
> adjustment to see if the requested level was applied.
>
> I think we can at least do something like
>
> dri2_setup_screen:
> dri2_dpy->*->getCapabilities()
>
> and use disp->Extensions.IMG_context_priority = (LO | MED | HI);
> to pass the support up the chain.

This sounds like a plan IMHO.

Humble suggestion though - do split the .CreateContext changes from
the rest of the patch.
Those are no-op, plus as-is the gallium drivers don't even build :-\

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


[Mesa-dev] [PATCH] nvc0: increase texture buffer object alignment to 256 for pre-GM107

2017-04-08 Thread Ilia Mirkin
We currently don't pass the low byte of the address via the surface
info, so in order to work with images, these have to implicitly be
aligned to 256. The proprietary driver also doesn't go out of its way to
provide lower alignment.

Fixes GL45-CTS.texture_buffer.texture_buffer_texture_buffer_range

Signed-off-by: Ilia Mirkin 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 543857a..fc44d32 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -147,7 +147,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT:
   return 256;
case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT:
-  if (class_3d < NVE4_3D_CLASS)
+  if (class_3d < GM107_3D_CLASS)
  return 256; /* IMAGE bindings require alignment to 256 */
   return 16;
case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
-- 
2.10.2

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


Re: [Mesa-dev] [PATCH v2] gbm: add support for loading third-party backend (v2)

2017-04-08 Thread Emil Velikov
On 7 April 2017 at 08:28, Qiang Yu  wrote:
> V2:
>   1. export gbmint.h and test backend/libgbm ABI compatible
>   2. drop GBM_BACKEND_DIR, specify backend path in config file
>   3. add GBM_CONFIG_DIR for config file
>   4. add per backend priority
>   5. take care of thread safe
>
> Third-party can put their backend to a directory and create a
> /etc/gbm.conf.d/*.conf file which contains the backend so file
> path to overwrite the default builtin DRI backend.
>
> The /etc/gbm.conf.d/*.conf will be sorted and the backends added
> will be tried one-by-one until one can successfully create a gbm
> device. The default DRI backend is tried at last.
>
> /etc/gbm.conf.d/*.conf can also contain a "priority" field.
> backend with bigger number will be tried first. Default priority
> is 1000 inlcuding the builtin backend.
>
> GBM config file example:
> lib:/opt/amdgpu-pro/lib/gbm/amdgpu.so
> priority:2000
>
> People can still use GBM_BACKEND to overwrite the backend try
> order.
>
What happened with the idea of reusing your existing amdgpu_dri.so ?
As mentioned before the DRI loader (libgbm) <> DRI driver (foo_dri.so)
interface is stable, so things should just work.

If you are concerned about the loader picking radeonsi_dri.so over
amdgpu_dri.so, simply do "export MESA_LOADER_DRIVER_OVERRIDE=amdgpu"
and enjoy.

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


Re: [Mesa-dev] [PATCH 9/9] mesa/st: take ownership rather than adding reference for new renderbuffers

2017-04-08 Thread Emil Velikov
On 8 April 2017 at 02:04, Timothy Arceri  wrote:
> This avoids locking in the reference calls and fixes a leak after the
> RefCount initialisation was change from 0 to 1.
>
> Fixes: 32141e53d1520 (mesa: tidy up renderbuffer RefCount initialisation)
> ---
>  src/mesa/state_tracker/st_manager.c | 21 -
>  1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_manager.c 
> b/src/mesa/state_tracker/st_manager.c
> index f469ebd..48daab6 100644
> --- a/src/mesa/state_tracker/st_manager.c
> +++ b/src/mesa/state_tracker/st_manager.c
> @@ -305,27 +305,38 @@ st_framebuffer_add_renderbuffer(struct st_framebuffer 
> *stfb,
> }
>
> if (format == PIPE_FORMAT_NONE)
>return FALSE;
>
> rb = st_new_renderbuffer_fb(format, stfb->iface->visual->samples, sw);
> if (!rb)
>return FALSE;
>
> if (idx != BUFFER_DEPTH) {
> -  _mesa_add_renderbuffer(&stfb->Base, idx, rb);
> +  _mesa_add_renderbuffer_without_ref(&stfb->Base, idx, rb);
> }
> else {
> -  if (util_format_get_component_bits(format, UTIL_FORMAT_COLORSPACE_ZS, 
> 0))
> - _mesa_add_renderbuffer(&stfb->Base, BUFFER_DEPTH, rb);
> -  if (util_format_get_component_bits(format, UTIL_FORMAT_COLORSPACE_ZS, 
> 1))
> - _mesa_add_renderbuffer(&stfb->Base, BUFFER_STENCIL, rb);
> +  bool rb_ownership_taken = false;
> +  if (util_format_get_component_bits(format,
> + UTIL_FORMAT_COLORSPACE_ZS, 0)) {
> + _mesa_add_renderbuffer_without_ref(&stfb->Base, BUFFER_DEPTH, rb);
> + rb_ownership_taken = true;
> +  }
> +  if (util_format_get_component_bits(format,
> + UTIL_FORMAT_COLORSPACE_ZS, 1)) {
> + if (rb_ownership_taken)
> +_mesa_add_renderbuffer(&stfb->Base, BUFFER_STENCIL, rb);
> + else {
> +_mesa_add_renderbuffer_without_ref(&stfb->Base, BUFFER_STENCIL,
> +   rb);
> + }
> +  }
> }
>
Nitpick: return early for idx != BUFFER_DEPTH and re-indent the rest
to make it easier on the eyes.

   if (idx != BUFFER_DEPTH) {
  _mesa_add_renderbuffer_without_ref(&stfb->Base, idx, rb);
  return TRUE;
   }

   bool rb_ownership_taken = false;
   if (util_format_get_component_bits(format, UTIL_FORMAT_COLORSPACE_ZS, 0)) {
  _mesa_add_renderbuffer_without_ref(&stfb->Base, BUFFER_DEPTH, rb);
  rb_ownership_taken = true;
   }

   if (util_format_get_component_bits(format, UTIL_FORMAT_COLORSPACE_ZS, 1)) {
  if (rb_ownership_taken)
 _mesa_add_renderbuffer(&stfb->Base, BUFFER_STENCIL, rb);
  else
 _mesa_add_renderbuffer_without_ref(&stfb->Base, BUFFER_STENCIL, rb);
   }

For the series (ideally with the nitpick, but meh)
Reviewed-by; Emil Velikov 

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


Re: [Mesa-dev] [PATCH 10/14] mesa/main: Maintain compressed fog mode.

2017-04-08 Thread Constantine Kharlamov
On 08.04.2017 19:37, Marek Olšák wrote:
> On Sat, Apr 8, 2017 at 12:53 AM, Gustaw Smolarczyk  
> wrote:
>> 2017-04-07 23:56 GMT+02:00 Marek Olšák :
>>> On Fri, Apr 7, 2017 at 6:54 PM, Gustaw Smolarczyk  
>>> wrote:
 2017-04-07 16:31 GMT+02:00 Marek Olšák :
> On Thu, Mar 30, 2017 at 8:09 PM, Gustaw Smolarczyk  
> wrote:
>> Signed-off-by: Gustaw Smolarczyk 
>> ---
>>  src/mesa/main/enable.c |  1 +
>>  src/mesa/main/fog.c|  9 +
>>  src/mesa/main/mtypes.h | 14 ++
>>  3 files changed, 24 insertions(+)
>>
>> diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
>> index d9d63a6b4b..ef278a318a 100644
>> --- a/src/mesa/main/enable.c
>> +++ b/src/mesa/main/enable.c
>> @@ -385,6 +385,7 @@ _mesa_set_enable(struct gl_context *ctx, GLenum cap, 
>> GLboolean state)
>>  return;
>>   FLUSH_VERTICES(ctx, _NEW_FOG);
>>   ctx->Fog.Enabled = state;
>> + ctx->Fog._PackedEnabledMode = state ? ctx->Fog._PackedMode : 
>> FOG_NONE;
>>   break;
>>case GL_LIGHT0:
>>case GL_LIGHT1:
>> diff --git a/src/mesa/main/fog.c b/src/mesa/main/fog.c
>> index 1ad939cfde..76e65080b7 100644
>> --- a/src/mesa/main/fog.c
>> +++ b/src/mesa/main/fog.c
>> @@ -102,8 +102,13 @@ _mesa_Fogfv( GLenum pname, const GLfloat *params )
>>   m = (GLenum) (GLint) *params;
>>  switch (m) {
>>  case GL_LINEAR:
>> +   ctx->Fog._PackedMode = FOG_LINEAR;
>> +   break;
>>  case GL_EXP:
>> +   ctx->Fog._PackedMode = FOG_EXP;
>> +   break;
>>  case GL_EXP2:
>> +   ctx->Fog._PackedMode = FOG_EXP2;
>
> Perhaps these should be set before FLUSH_VERTICES?
>
> Marek

 That would make us need two switch() statements instead of one. Also,
 if ctx->Fog.Mode == m then we are essentially writing the same values
 so nothing changes - doing it after the check shouldn't affect
 correctness in any way. I might be wrong, though. _PackedMode is only
 ever used to manage _PackedEnabledMode (here and in _mesa_set_enable),
 so I think we should be safe.

 Since this simplification is pretty minor, I can change the code if you 
 want.
>>>
>>> It's OK if _PackedMode is only a temporary variable used after
>>> FLUSH_VERTICES. It can't be used directly in places that don't call
>>> FLUSH_VERTICES though (e.g. ff_fragment_program.cpp).
>>
>> Since current _PackedMode usage is restricted to mesa/main just after
>> FLUSH_VERTICES is called (and will probably stay this way), I think
>> the prerequisites are fulfilled.
> 
> The prerequisites are fulfilled only if _PackedMode isn't used by
> FLUSH_VERTICES itself.
> 
> Mesa doesn't send all draw calls to drivers. Some draw calls are
> queued in the vbo module. FLUSH_VERTICES flushes the queue. All state
> changes should happen after FLUSH_VERTICES. If they happen before
> FLUSH_VERTICES, they could affect previous draw calls. It's basically
> the same as changing the order of GL calls in an incorrect way. We
> should make sure that it never happens.
> 
>>
>> If you are ok with the patches, could please push the whole series? I
>> don't have commit access.
> 
> If you send me a git link to the whole series, I'll push it.

You can actually get the series from patchwork, then unwind it to local repo 
with "git am some-series.mbox", then "git push".

E.g. this series is under "download mbox" here 
https://patchwork.freedesktop.org/series/22231/ "mbox" is just all patches 
squashed one after another. Applying it with "git am" preserves commits and 
messages of the series.

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


Re: [Mesa-dev] [PATCH 10/14] mesa/main: Maintain compressed fog mode.

2017-04-08 Thread Gustaw Smolarczyk
2017-04-08 18:37 GMT+02:00 Marek Olšák :
> On Sat, Apr 8, 2017 at 12:53 AM, Gustaw Smolarczyk  
> wrote:
>> 2017-04-07 23:56 GMT+02:00 Marek Olšák :
>>> On Fri, Apr 7, 2017 at 6:54 PM, Gustaw Smolarczyk  
>>> wrote:
 2017-04-07 16:31 GMT+02:00 Marek Olšák :
> On Thu, Mar 30, 2017 at 8:09 PM, Gustaw Smolarczyk  
> wrote:
>> Signed-off-by: Gustaw Smolarczyk 
>> ---
>>  src/mesa/main/enable.c |  1 +
>>  src/mesa/main/fog.c|  9 +
>>  src/mesa/main/mtypes.h | 14 ++
>>  3 files changed, 24 insertions(+)
>>
>> diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
>> index d9d63a6b4b..ef278a318a 100644
>> --- a/src/mesa/main/enable.c
>> +++ b/src/mesa/main/enable.c
>> @@ -385,6 +385,7 @@ _mesa_set_enable(struct gl_context *ctx, GLenum cap, 
>> GLboolean state)
>>  return;
>>   FLUSH_VERTICES(ctx, _NEW_FOG);
>>   ctx->Fog.Enabled = state;
>> + ctx->Fog._PackedEnabledMode = state ? ctx->Fog._PackedMode : 
>> FOG_NONE;
>>   break;
>>case GL_LIGHT0:
>>case GL_LIGHT1:
>> diff --git a/src/mesa/main/fog.c b/src/mesa/main/fog.c
>> index 1ad939cfde..76e65080b7 100644
>> --- a/src/mesa/main/fog.c
>> +++ b/src/mesa/main/fog.c
>> @@ -102,8 +102,13 @@ _mesa_Fogfv( GLenum pname, const GLfloat *params )
>>   m = (GLenum) (GLint) *params;
>>  switch (m) {
>>  case GL_LINEAR:
>> +   ctx->Fog._PackedMode = FOG_LINEAR;
>> +   break;
>>  case GL_EXP:
>> +   ctx->Fog._PackedMode = FOG_EXP;
>> +   break;
>>  case GL_EXP2:
>> +   ctx->Fog._PackedMode = FOG_EXP2;
>
> Perhaps these should be set before FLUSH_VERTICES?
>
> Marek

 That would make us need two switch() statements instead of one. Also,
 if ctx->Fog.Mode == m then we are essentially writing the same values
 so nothing changes - doing it after the check shouldn't affect
 correctness in any way. I might be wrong, though. _PackedMode is only
 ever used to manage _PackedEnabledMode (here and in _mesa_set_enable),
 so I think we should be safe.

 Since this simplification is pretty minor, I can change the code if you 
 want.
>>>
>>> It's OK if _PackedMode is only a temporary variable used after
>>> FLUSH_VERTICES. It can't be used directly in places that don't call
>>> FLUSH_VERTICES though (e.g. ff_fragment_program.cpp).
>>
>> Since current _PackedMode usage is restricted to mesa/main just after
>> FLUSH_VERTICES is called (and will probably stay this way), I think
>> the prerequisites are fulfilled.
>
> The prerequisites are fulfilled only if _PackedMode isn't used by
> FLUSH_VERTICES itself.
>
> Mesa doesn't send all draw calls to drivers. Some draw calls are
> queued in the vbo module. FLUSH_VERTICES flushes the queue. All state
> changes should happen after FLUSH_VERTICES. If they happen before
> FLUSH_VERTICES, they could affect previous draw calls. It's basically
> the same as changing the order of GL calls in an incorrect way. We
> should make sure that it never happens.

Yes, I understand how it's important not to modify some state before
the driver (or vbo module or st/mesa) is done using it for things that
were being buffered (like the vertices). Since currently _PackedMode
is not used there, it shouldn't be a problem. And I think it's always
better to use _PackedEnabledMode instead of _PackedMode since it also
tells you whether the whole fog processing is enabled or not. Maybe I
should put a comment saying that _PackedMode is for internal use and
shouldn't be used in any other way than helping _PackedEnabledMode
initialization?

>
>>
>> If you are ok with the patches, could please push the whole series? I
>> don't have commit access.
>
> If you send me a git link to the whole series, I'll push it.

I am not sure what you mean by "git link". Did I forget about
something while using git-format-patch/git-send-email before sending
the series? Or do you want a git repository you can pull the series
from?

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


Re: [Mesa-dev] [PATCH 10/14] mesa/main: Maintain compressed fog mode.

2017-04-08 Thread Marek Olšák
On Sat, Apr 8, 2017 at 12:53 AM, Gustaw Smolarczyk  wrote:
> 2017-04-07 23:56 GMT+02:00 Marek Olšák :
>> On Fri, Apr 7, 2017 at 6:54 PM, Gustaw Smolarczyk  
>> wrote:
>>> 2017-04-07 16:31 GMT+02:00 Marek Olšák :
 On Thu, Mar 30, 2017 at 8:09 PM, Gustaw Smolarczyk  
 wrote:
> Signed-off-by: Gustaw Smolarczyk 
> ---
>  src/mesa/main/enable.c |  1 +
>  src/mesa/main/fog.c|  9 +
>  src/mesa/main/mtypes.h | 14 ++
>  3 files changed, 24 insertions(+)
>
> diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
> index d9d63a6b4b..ef278a318a 100644
> --- a/src/mesa/main/enable.c
> +++ b/src/mesa/main/enable.c
> @@ -385,6 +385,7 @@ _mesa_set_enable(struct gl_context *ctx, GLenum cap, 
> GLboolean state)
>  return;
>   FLUSH_VERTICES(ctx, _NEW_FOG);
>   ctx->Fog.Enabled = state;
> + ctx->Fog._PackedEnabledMode = state ? ctx->Fog._PackedMode : 
> FOG_NONE;
>   break;
>case GL_LIGHT0:
>case GL_LIGHT1:
> diff --git a/src/mesa/main/fog.c b/src/mesa/main/fog.c
> index 1ad939cfde..76e65080b7 100644
> --- a/src/mesa/main/fog.c
> +++ b/src/mesa/main/fog.c
> @@ -102,8 +102,13 @@ _mesa_Fogfv( GLenum pname, const GLfloat *params )
>   m = (GLenum) (GLint) *params;
>  switch (m) {
>  case GL_LINEAR:
> +   ctx->Fog._PackedMode = FOG_LINEAR;
> +   break;
>  case GL_EXP:
> +   ctx->Fog._PackedMode = FOG_EXP;
> +   break;
>  case GL_EXP2:
> +   ctx->Fog._PackedMode = FOG_EXP2;

 Perhaps these should be set before FLUSH_VERTICES?

 Marek
>>>
>>> That would make us need two switch() statements instead of one. Also,
>>> if ctx->Fog.Mode == m then we are essentially writing the same values
>>> so nothing changes - doing it after the check shouldn't affect
>>> correctness in any way. I might be wrong, though. _PackedMode is only
>>> ever used to manage _PackedEnabledMode (here and in _mesa_set_enable),
>>> so I think we should be safe.
>>>
>>> Since this simplification is pretty minor, I can change the code if you 
>>> want.
>>
>> It's OK if _PackedMode is only a temporary variable used after
>> FLUSH_VERTICES. It can't be used directly in places that don't call
>> FLUSH_VERTICES though (e.g. ff_fragment_program.cpp).
>
> Since current _PackedMode usage is restricted to mesa/main just after
> FLUSH_VERTICES is called (and will probably stay this way), I think
> the prerequisites are fulfilled.

The prerequisites are fulfilled only if _PackedMode isn't used by
FLUSH_VERTICES itself.

Mesa doesn't send all draw calls to drivers. Some draw calls are
queued in the vbo module. FLUSH_VERTICES flushes the queue. All state
changes should happen after FLUSH_VERTICES. If they happen before
FLUSH_VERTICES, they could affect previous draw calls. It's basically
the same as changing the order of GL calls in an incorrect way. We
should make sure that it never happens.

>
> If you are ok with the patches, could please push the whole series? I
> don't have commit access.

If you send me a git link to the whole series, I'll push it.

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


[Mesa-dev] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

2017-04-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98502

Emil Velikov  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #27 from Emil Velikov  ---
(In reply to Eugene Shalygin from comment #26)
> (In reply to Eugene Shalygin from comment #25)
> > Just found that dGPU wakes up when I connect an Android phone via USB.
> 
> No, any USB device makes that. kernel 4.10.8.

While the side effects are similar, the issue seems unrelated. There are some
suggestions in comment 23, that you might want to explode.

In either case, please keep it a separate bug report. Thank you!

-- 
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 00/13] Better Travis-CI integration

2017-04-08 Thread Emil Velikov
On 8 April 2017 at 14:19, Edward O'Callaghan
 wrote:
>
>
> On 04/08/2017 05:05 AM, Emil Velikov wrote:
>> Hi all,
>>
>> Inspired by the work from Andres, I've went ahead and made our
>> integration a bit better. Highlights include:
>>  - run in container - faster startup times, always 2 cores
>>  - removed unneeded packages
>>  - "build everything" - st/vdpau and ANV cannot be build at this
>> stage,
>> with the respective commits containing further information.
>>
>> Needless to say the C++ code-bases of SWR and Clover are _very_
>> slow to
> Hi Emil,
>
> May I suggest using clang over gcc for compiling C++ code as it is
> *much* faster! You also get the benefit of a bit of shadow compiling as
> most folks use gcc.
>
Good point about clang.

I was itching to add the combinations below, but realised that the
series is large enough as-is ;-)
Feel free to lend a hand - I will focus on git hook/notification email first.

 - travis
scons + mingw-w64
osx + make + gcc/clang
 - appveyor
scons llvm=0 mingw-w64/clang/msvc
scons llvm=1 mingw-w64/clang
scons swr=1 mingw-w64/clang/msvc
cygwin + make +  gcc/clang

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


Re: [Mesa-dev] [PATCH 00/13] Better Travis-CI integration

2017-04-08 Thread Edward O'Callaghan


On 04/08/2017 05:05 AM, Emil Velikov wrote:
> Hi all,
> 
> Inspired by the work from Andres, I've went ahead and made our 
> integration a bit better. Highlights include:
>  - run in container - faster startup times, always 2 cores
>  - removed unneeded packages
>  - "build everything" - st/vdpau and ANV cannot be build at this 
> stage, 
> with the respective commits containing further information.
> 
> Needless to say the C++ code-bases of SWR and Clover are _very_ 
> slow to 
Hi Emil,

May I suggest using clang over gcc for compiling C++ code as it is
*much* faster! You also get the benefit of a bit of shadow compiling as
most folks use gcc.

Kind Regards,
Edward.
> build. I've split and reshuffled so that the overall runtime is 
> not too 
> badly affected.
> 
> Plus one can easily drop the build from the matrix if they 
> haven't 
> touched some parts of mesa.
> 
> As step two, is to set a git hook and send reports back to 
> mesa-dev@ 
> analogous to the Appveyor setup. I'm planning to take a look at 
> that 
> next week.
> 
> For those interested, here is a sample run
> https://travis-ci.org/evelikov/Mesa/builds/219744835
> 
> Thanks
> Emil
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 



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


Re: [Mesa-dev] [PATCH 9/9] nvc0: Enable ARB_shader_ballot on Kepler+

2017-04-08 Thread Ilia Mirkin
Meh, caution to the wind. It'll be easy to fix when/if someone complains.

On Sat, Apr 8, 2017 at 8:59 AM, Samuel Pitoiset
 wrote:
> I would just suggest to only enable the feature on GK110 for now. Except if
> someone else can test on GK104 and GM107+.
>
>
> On 04/08/2017 11:51 AM, Boyan Ding wrote:
>>
>> readInvocationARB() and readFirstInvocationARB() need SHFL.IDX
>> instruction which is introduced in Kepler.
>> ---
>>   docs/features.txt  | 2 +-
>>   docs/relnotes/17.1.0.html  | 2 +-
>>   src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 3 ++-
>>   3 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/docs/features.txt b/docs/features.txt
>> index 5cc109036b..505eee4516 100644
>> --- a/docs/features.txt
>> +++ b/docs/features.txt
>> @@ -292,7 +292,7 @@ Khronos, ARB, and OES extensions that are not part of
>> any OpenGL or OpenGL ES ve
>> GL_ARB_sample_locations   not started
>> GL_ARB_seamless_cubemap_per_texture   DONE (i965,
>> nvc0, radeonsi, r600, softpipe, swr)
>> GL_ARB_shader_atomic_counter_ops  DONE
>> (i965/gen7+, nvc0, radeonsi, softpipe)
>> -  GL_ARB_shader_ballot  DONE (radeonsi)
>> +  GL_ARB_shader_ballot  DONE (nvc0,
>> radeonsi)
>> GL_ARB_shader_clock   DONE
>> (i965/gen7+, radeonsi)
>> GL_ARB_shader_draw_parameters DONE (i965,
>> nvc0, radeonsi)
>> GL_ARB_shader_group_vote  DONE (nvc0,
>> radeonsi)
>> diff --git a/docs/relnotes/17.1.0.html b/docs/relnotes/17.1.0.html
>> index 7419970283..10c60a066c 100644
>> --- a/docs/relnotes/17.1.0.html
>> +++ b/docs/relnotes/17.1.0.html
>> @@ -45,7 +45,7 @@ Note: some of the new features are only available with
>> certain drivers.
>> 
>>   GL_ARB_gpu_shader_int64 on i965/gen8+, nvc0, radeonsi, softpipe,
>> llvmpipe
>> -GL_ARB_shader_ballot on radeonsi
>> +GL_ARB_shader_ballot on nvc0, radeonsi
>>   GL_ARB_shader_clock on radeonsi
>>   GL_ARB_shader_group_vote on radeonsi
>>   GL_ARB_sparse_buffer on radeonsi/CIK+
>> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
>> b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
>> index 064848db4a..6a027e9a51 100644
>> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
>> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
>> @@ -258,6 +258,8 @@ nvc0_screen_get_param(struct pipe_screen *pscreen,
>> enum pipe_cap param)
>> return class_3d >= NVE4_3D_CLASS; /* needs testing on fermi */
>>  case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
>> return class_3d >= GM200_3D_CLASS;
>> +   case PIPE_CAP_TGSI_BALLOT:
>> +  return class_3d >= NVE4_3D_CLASS;
>>/* unsupported caps */
>>  case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
>> @@ -289,7 +291,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen,
>> enum pipe_cap param)
>>  case PIPE_CAP_INT64_DIVMOD:
>>  case PIPE_CAP_TGSI_CLOCK:
>>  case PIPE_CAP_SPARSE_BUFFER_PAGE_SIZE:
>> -   case PIPE_CAP_TGSI_BALLOT:
>> return 0;
>>case PIPE_CAP_VENDOR_ID:
>>
> ___
> 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 07/53] i965/drm: Drop libpciaccess dependencies.

2017-04-08 Thread Chris Wilson
On Wed, Apr 05, 2017 at 10:31:48AM +0100, Chris Wilson wrote:
> On Tue, Apr 04, 2017 at 05:09:57PM -0700, Kenneth Graunke wrote:
> > i965 doesn't use drm_intel_get_aperture_sizes(), so we can delete
> > support for it.  This avoids a build dependency on libpciaccess.
> 
> \o/
> 
> There's a really old bug that hopefully has been closed already
> (although as far as I can tell, it has never been fixed) about
> how using libpciaccess from libdrm_intel breaks the world (since
> libpciaccess uses a singleton that is torn down at the first request
> rather than upon the last user).

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

> Reviewed-by: Chris Wilson 
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 9/9] nvc0: Enable ARB_shader_ballot on Kepler+

2017-04-08 Thread Samuel Pitoiset
I would just suggest to only enable the feature on GK110 for now. Except 
if someone else can test on GK104 and GM107+.


On 04/08/2017 11:51 AM, Boyan Ding wrote:

readInvocationARB() and readFirstInvocationARB() need SHFL.IDX
instruction which is introduced in Kepler.
---
  docs/features.txt  | 2 +-
  docs/relnotes/17.1.0.html  | 2 +-
  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 3 ++-
  3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index 5cc109036b..505eee4516 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -292,7 +292,7 @@ Khronos, ARB, and OES extensions that are not part of any 
OpenGL or OpenGL ES ve
GL_ARB_sample_locations   not started
GL_ARB_seamless_cubemap_per_texture   DONE (i965, nvc0, 
radeonsi, r600, softpipe, swr)
GL_ARB_shader_atomic_counter_ops  DONE (i965/gen7+, 
nvc0, radeonsi, softpipe)
-  GL_ARB_shader_ballot  DONE (radeonsi)
+  GL_ARB_shader_ballot  DONE (nvc0, radeonsi)
GL_ARB_shader_clock   DONE (i965/gen7+, 
radeonsi)
GL_ARB_shader_draw_parameters DONE (i965, nvc0, 
radeonsi)
GL_ARB_shader_group_vote  DONE (nvc0, radeonsi)
diff --git a/docs/relnotes/17.1.0.html b/docs/relnotes/17.1.0.html
index 7419970283..10c60a066c 100644
--- a/docs/relnotes/17.1.0.html
+++ b/docs/relnotes/17.1.0.html
@@ -45,7 +45,7 @@ Note: some of the new features are only available with 
certain drivers.
  
  

  GL_ARB_gpu_shader_int64 on i965/gen8+, nvc0, radeonsi, softpipe, 
llvmpipe
-GL_ARB_shader_ballot on radeonsi
+GL_ARB_shader_ballot on nvc0, radeonsi
  GL_ARB_shader_clock on radeonsi
  GL_ARB_shader_group_vote on radeonsi
  GL_ARB_sparse_buffer on radeonsi/CIK+
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 064848db4a..6a027e9a51 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -258,6 +258,8 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
return class_3d >= NVE4_3D_CLASS; /* needs testing on fermi */
 case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
return class_3d >= GM200_3D_CLASS;
+   case PIPE_CAP_TGSI_BALLOT:
+  return class_3d >= NVE4_3D_CLASS;
  
 /* unsupported caps */

 case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
@@ -289,7 +291,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
 case PIPE_CAP_INT64_DIVMOD:
 case PIPE_CAP_TGSI_CLOCK:
 case PIPE_CAP_SPARSE_BUFFER_PAGE_SIZE:
-   case PIPE_CAP_TGSI_BALLOT:
return 0;
  
 case PIPE_CAP_VENDOR_ID:



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


Re: [Mesa-dev] [PATCH 0/9] nvc0: ARB_shader_ballot for Kepler+

2017-04-08 Thread Samuel Pitoiset

Nice series. How about ARB_shader_clock now? :)

On 04/08/2017 11:51 AM, Boyan Ding wrote:

This series implements ARB_shader_ballot for Kepler+. I have tested
it on GK208, 8 of 9 of piglit execution tests passed against current
master. The only failed test is because of the test's wrong assumption
when thread group size is less than 64, which is the case for nvidia
hardware. Other architectures (GK104 and GM107) are not tested because
of my lack of hareware, but I have validated the code generated on both
architectures, and it seems correct.

Patches 1-4 implement OP_SHFL emission, with a fix for nvc0 in patch 2.
Patch 5 extends nv50 ir's OP_VOTE to translate readFirstInvocationARB.
Patches 6-8 hook up the logic with tgsi, and the extension is eventually
flipped on in the last patch.

Boyan Ding (9):
   gm107/ir: Emit third src 'bound' and optional predicate output of SHFL
   nvc0/ir: Properly handle a "split form" of predicate destination
   nvc0/ir: Emit OP_SHFL
   gk110/ir: Emit OP_SHFL
   nvc0/ir: Allow 0/1 immediate value as source of OP_VOTE
   nvc0/ir: Add SV_LANEMASK_* system values.
   nvc0/ir: Implement TGSI_SEMANTIC_SUBGROUP_*
   nvc0/ir: Implement TGSI_OPCODE_BALLOT and TGSI_OPCODE_READ_*
   nvc0: Enable ARB_shader_ballot on Kepler+

  docs/features.txt  |  2 +-
  docs/relnotes/17.1.0.html  |  2 +-
  src/gallium/drivers/nouveau/codegen/nv50_ir.h  |  5 ++
  .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 76 +-
  .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 47 +--
  .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp  | 90 --
  .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp  | 55 +
  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c |  3 +-
  8 files changed, 260 insertions(+), 20 deletions(-)


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


Re: [Mesa-dev] [PATCH 1/9] gm107/ir: Emit third src 'bound' and optional predicate output of SHFL

2017-04-08 Thread Samuel Pitoiset



On 04/08/2017 02:49 PM, Boyan Ding wrote:

2017-04-08 20:42 GMT+08:00 Samuel Pitoiset :



On 04/08/2017 11:51 AM, Boyan Ding wrote:


---
   .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 23
++
   1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index 6903132efa..4a741bf45b 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
@@ -966,11 +966,26 @@ CodeEmitterGM107::emitSHFL()
 break;
  }
   -   /*XXX: what is this arg? hardcode immediate for now */
-   emitField(0x22, 13, 0x1c03);
-   type |= 2;
+   switch (insn->src(2).getFile()) {
+   case FILE_GPR:
+  emitGPR(0x27, insn->src(2));
+  break;
+   case FILE_IMMEDIATE:
+  emitIMMD(0x22, 13, insn->src(2));
+  type |= 2;
+  break;
+   default:
+  assert(!"invalid src2 file");
+  break;
+   }



This looks wrong to me. I think you need to check that src(2) exists because
you might hit the assert for DFDX (and friends) which uses SHFL.


I wasn't aware that this was used in gm107's lowering. That explains
the 0x1c03 magic number here.

Do you think I shall leave 0x1c03 as default value or add the constant
in nv50_ir_lowering_gm107.cpp?


Yeah, you probably need to emit src(2) there and it would be nice to 
figure out the magic number. :)




Thanks for pointing it out.

Cheers,
Boyan Ding





+
+   if (!insn->defExists(1))
+  emitPRED(0x30);
+   else {
+  assert(insn->def(1).getFile() == FILE_PREDICATE);
+  emitPRED(0x30, insn->def(1));
+   }
   -   emitPRED (0x30);
  emitField(0x1e, 2, insn->subOp);
  emitField(0x1c, 2, type);
  emitGPR  (0x08, insn->src(0));




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


Re: [Mesa-dev] [PATCH 1/9] gm107/ir: Emit third src 'bound' and optional predicate output of SHFL

2017-04-08 Thread Boyan Ding
2017-04-08 20:42 GMT+08:00 Samuel Pitoiset :
>
>
> On 04/08/2017 11:51 AM, Boyan Ding wrote:
>>
>> ---
>>   .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 23
>> ++
>>   1 file changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
>> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
>> index 6903132efa..4a741bf45b 100644
>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
>> @@ -966,11 +966,26 @@ CodeEmitterGM107::emitSHFL()
>> break;
>>  }
>>   -   /*XXX: what is this arg? hardcode immediate for now */
>> -   emitField(0x22, 13, 0x1c03);
>> -   type |= 2;
>> +   switch (insn->src(2).getFile()) {
>> +   case FILE_GPR:
>> +  emitGPR(0x27, insn->src(2));
>> +  break;
>> +   case FILE_IMMEDIATE:
>> +  emitIMMD(0x22, 13, insn->src(2));
>> +  type |= 2;
>> +  break;
>> +   default:
>> +  assert(!"invalid src2 file");
>> +  break;
>> +   }
>
>
> This looks wrong to me. I think you need to check that src(2) exists because
> you might hit the assert for DFDX (and friends) which uses SHFL.

I wasn't aware that this was used in gm107's lowering. That explains
the 0x1c03 magic number here.

Do you think I shall leave 0x1c03 as default value or add the constant
in nv50_ir_lowering_gm107.cpp?

Thanks for pointing it out.

Cheers,
Boyan Ding

>
>
>> +
>> +   if (!insn->defExists(1))
>> +  emitPRED(0x30);
>> +   else {
>> +  assert(insn->def(1).getFile() == FILE_PREDICATE);
>> +  emitPRED(0x30, insn->def(1));
>> +   }
>>   -   emitPRED (0x30);
>>  emitField(0x1e, 2, insn->subOp);
>>  emitField(0x1c, 2, type);
>>  emitGPR  (0x08, insn->src(0));
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/9] gm107/ir: Emit third src 'bound' and optional predicate output of SHFL

2017-04-08 Thread Samuel Pitoiset



On 04/08/2017 11:51 AM, Boyan Ding wrote:

---
  .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 23 ++
  1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index 6903132efa..4a741bf45b 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
@@ -966,11 +966,26 @@ CodeEmitterGM107::emitSHFL()
break;
 }
  
-   /*XXX: what is this arg? hardcode immediate for now */

-   emitField(0x22, 13, 0x1c03);
-   type |= 2;
+   switch (insn->src(2).getFile()) {
+   case FILE_GPR:
+  emitGPR(0x27, insn->src(2));
+  break;
+   case FILE_IMMEDIATE:
+  emitIMMD(0x22, 13, insn->src(2));
+  type |= 2;
+  break;
+   default:
+  assert(!"invalid src2 file");
+  break;
+   }


This looks wrong to me. I think you need to check that src(2) exists 
because you might hit the assert for DFDX (and friends) which uses SHFL.



+
+   if (!insn->defExists(1))
+  emitPRED(0x30);
+   else {
+  assert(insn->def(1).getFile() == FILE_PREDICATE);
+  emitPRED(0x30, insn->def(1));
+   }
  
-   emitPRED (0x30);

 emitField(0x1e, 2, insn->subOp);
 emitField(0x1c, 2, type);
 emitGPR  (0x08, insn->src(0));


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


Re: [Mesa-dev] [PATCH 3/9] nvc0/ir: Emit OP_SHFL

2017-04-08 Thread Samuel Pitoiset



On 04/08/2017 11:51 AM, Boyan Ding wrote:

---
  .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp  | 51 ++
  1 file changed, 51 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
index d5a310f88c..8dd73bd77d 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
@@ -150,6 +150,8 @@ private:
  
 void emitPIXLD(const Instruction *);
  
+   void emitSHFL(const Instruction *);

+
 void emitVOTE(const Instruction *);
  
 inline void defId(const ValueDef&, const int pos);

@@ -2529,6 +2531,52 @@ CodeEmitterNVC0::emitPIXLD(const Instruction *i)
  }
  
  void

+CodeEmitterNVC0::emitSHFL(const Instruction *i)
+{


assert(targ->getChipset() >= NVISA_GK104_CHIPSET);


+   code[0] = 0x0005;
+   code[1] = 0x8800 | (i->subOp << 23);
+
+   emitPredicate(i);
+
+   defId(i->def(0), 14);
+   srcId(i->src(0), 20);
+
+   switch (i->src(1).getFile()) {
+   case FILE_GPR:
+  srcId(i->src(1), 26);
+  break;
+   case FILE_IMMEDIATE:
+  code[0] |= (i->src(1).get()->asImm()->reg.data.u32 & 0x1f) << 26;
+  code[0] |= 1 << 5;
+  break;
+   default:
+  assert(!"invalid src1 file");
+  break;
+   }
+
+   switch (i->src(2).getFile()) {
+   case FILE_GPR:
+  srcId(i->src(2), 49);
+  break;
+   case FILE_IMMEDIATE:
+  code[1] |= (i->src(2).get()->asImm()->reg.data.u32 & 0x1fff) << 10;
+  code[0] |= 1 << 6;
+  break;
+   default:
+  assert(!"invalid src2 file");
+  break;
+   }
+
+   if (!i->defExists(1)) {
+  code[0] |= 3 << 8;
+  code[1] |= 1 << 26;
+   } else {
+  assert(i->def(1).getFile() == FILE_PREDICATE);
+  setPDSTL(i->def(1));
+   }
+}
+
+void
  CodeEmitterNVC0::emitVOTE(const Instruction *i)
  {
 assert(i->src(0).getFile() == FILE_PREDICATE);
@@ -2837,6 +2885,9 @@ CodeEmitterNVC0::emitInstruction(Instruction *insn)
 case OP_PIXLD:
emitPIXLD(insn);
break;
+   case OP_SHFL:
+  emitSHFL(insn);
+  break;
 case OP_VOTE:
emitVOTE(insn);
break;


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


Re: [Mesa-dev] [PATCH 5/9] nvc0/ir: Allow 0/1 immediate value as source of OP_VOTE

2017-04-08 Thread Samuel Pitoiset



On 04/08/2017 11:51 AM, Boyan Ding wrote:

Implementation of readFirstInvocationARB() on nvidia hardware needs a
ballotARB(true) used to decide the first active thread. This expressed
in gm107 asm as (supposing output is $r0):
vote any $r0 0x1 0x1

To model the always true input, which corresponds to the second 0x1
above, we make OP_VOTE accept immediate value 0/1 and emit "0x1" and
"not 0x1" in the src field respectively.
---
  .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp  | 21 +
  .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp  | 19 ---
  .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp   | 21 +
  3 files changed, 50 insertions(+), 11 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
index e82e3684b0..31af6dcc17 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
@@ -1615,7 +1615,7 @@ CodeEmitterGK110::emitSHFL(const Instruction *i)
  void
  CodeEmitterGK110::emitVOTE(const Instruction *i)
  {
-   assert(i->src(0).getFile() == FILE_PREDICATE);
+   uint32_t imm;
  
 code[0] = 0x0002;

 code[1] = 0x86c0 | (i->subOp << 19);
@@ -1640,9 +1640,22 @@ CodeEmitterGK110::emitVOTE(const Instruction *i)
code[0] |= 255 << 2;
 if (!(rp & 2))
code[1] |= 7 << 16;
-   if (i->src(0).mod == Modifier(NV50_IR_MOD_NOT))
-  code[1] |= 1 << 13;
-   srcId(i->src(0), 42);
+
+   switch (i->src(0).getFile()) {
+   case FILE_PREDICATE:
+  if (i->src(0).mod == Modifier(NV50_IR_MOD_NOT))
+ code[0] |= 1 << 13;
+  srcId(i->src(0), 42);
+  break;
+   case FILE_IMMEDIATE:
+  imm = i->src(0).get()->asImm()->reg.data.u32;


Usually we check that asImm() is not NULL, like

imm = i->src(0).get->asImm();
assert(imm);

Same in other emitters.


+  assert(imm == 0 || imm == 1);
+  code[1] |= (imm == 1 ? 0x7 : 0xf) << 10;
+  break;
+   default:
+  assert(!"Unhandled src");
+  break;
+   }
  }
  
  void

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index 4a741bf45b..ee1046fea0 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
@@ -2930,7 +2930,7 @@ CodeEmitterGM107::emitMEMBAR()
  void
  CodeEmitterGM107::emitVOTE()
  {
-   assert(insn->src(0).getFile() == FILE_PREDICATE);
+   uint32_t imm;
  
 int r = -1, p = -1;

 for (int i = 0; insn->defExists(i); i++) {
@@ -2950,8 +2950,21 @@ CodeEmitterGM107::emitVOTE()
emitPRED (0x2d, insn->def(p));
 else
emitPRED (0x2d);
-   emitField(0x2a, 1, insn->src(0).mod == Modifier(NV50_IR_MOD_NOT));
-   emitPRED (0x27, insn->src(0));
+
+   switch (insn->src(0).getFile()) {
+   case FILE_PREDICATE:
+  emitField(0x2a, 1, insn->src(0).mod == Modifier(NV50_IR_MOD_NOT));
+  emitPRED (0x27, insn->src(0));
+  break;
+   case FILE_IMMEDIATE:
+  imm = insn->src(0).get()->asImm()->reg.data.u32;
+  assert(imm == 0 || imm == 1);
+  emitField(0x27, 4, imm == 1 ? 0x7 : 0xf);
+  break;
+   default:
+  assert(!"Unhandled src");
+  break;
+   }
  }
  
  void

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
index 8dd73bd77d..fafb65743e 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
@@ -2579,7 +2579,7 @@ CodeEmitterNVC0::emitSHFL(const Instruction *i)
  void
  CodeEmitterNVC0::emitVOTE(const Instruction *i)
  {
-   assert(i->src(0).getFile() == FILE_PREDICATE);
+   uint32_t imm;
  
 code[0] = 0x0004 | (i->subOp << 5);

 code[1] = 0x4800;
@@ -2604,9 +2604,22 @@ CodeEmitterNVC0::emitVOTE(const Instruction *i)
code[0] |= 63 << 14;
 if (!(rp & 2))
code[1] |= 7 << 22;
-   if (i->src(0).mod == Modifier(NV50_IR_MOD_NOT))
-  code[0] |= 1 << 23;
-   srcId(i->src(0), 20);
+
+   switch (i->src(0).getFile()) {
+   case FILE_PREDICATE:
+  if (i->src(0).mod == Modifier(NV50_IR_MOD_NOT))
+ code[0] |= 1 << 23;
+  srcId(i->src(0), 20);
+  break;
+   case FILE_IMMEDIATE:
+  imm = i->src(0).get()->asImm()->reg.data.u32;
+  assert(imm == 0 || imm == 1);
+  code[0] |= (imm == 1 ? 0x7 : 0xf) << 20;
+  break;
+   default:
+  assert(!"Unhandled src");
+  break;
+   }
  }
  
  bool



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


[Mesa-dev] [Bug 98974] Can't see borders/empires in Stellaris

2017-04-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98974

--- Comment #8 from lukas.fuernkranz+bugzil...@gmail.com ---
I still have that problem. with the new Stellaris version (1.5.0) and Mesa
17.1.0-devel.

-- 
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] mesa: fix renderbuffer leak

2017-04-08 Thread Bartosz Tomczyk

I confirm that the series fix all memory leaks I was observing.

Tested-by: Bartosz Tomczyk 


On 08.04.2017 05:23, Timothy Arceri wrote:

On 08/04/17 12:25, Timothy Arceri wrote:

Actually please ignore that series for now. There are some issue with it
I need to fix up.



Sorry for the noise. V3 of the first patch should fix things up.


On 08/04/17 11:13, Timothy Arceri wrote:



On 08/04/17 02:25, Bartosz Tomczyk wrote:

Patch didn't fix all leaks. There's one more still reported by ASAN:

Direct leak of 2112 byte(s) in 12 object(s) allocated from:
   #0 0x7fe18d168800 in calloc
(/usr/lib/clang/3.9.1/lib/linux/libclang_rt.asan-x86_64.so
+0xf6800)
   #1 0x7fe181c141f6 in st_new_renderbuffer_fb
/home/bartek/Devel/mesa/src/mesa/state_tracker/st_cb_fbo.c:277:11


Right, there was some internal renderbuffer creation going on that I
didn't notice. This series should fix it:

https://patchwork.freedesktop.org/series/22708/
___
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


[Mesa-dev] [PATCH 9/9] nvc0: Enable ARB_shader_ballot on Kepler+

2017-04-08 Thread Boyan Ding
readInvocationARB() and readFirstInvocationARB() need SHFL.IDX
instruction which is introduced in Kepler.
---
 docs/features.txt  | 2 +-
 docs/relnotes/17.1.0.html  | 2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 3 ++-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index 5cc109036b..505eee4516 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -292,7 +292,7 @@ Khronos, ARB, and OES extensions that are not part of any 
OpenGL or OpenGL ES ve
   GL_ARB_sample_locations   not started
   GL_ARB_seamless_cubemap_per_texture   DONE (i965, nvc0, 
radeonsi, r600, softpipe, swr)
   GL_ARB_shader_atomic_counter_ops  DONE (i965/gen7+, 
nvc0, radeonsi, softpipe)
-  GL_ARB_shader_ballot  DONE (radeonsi)
+  GL_ARB_shader_ballot  DONE (nvc0, radeonsi)
   GL_ARB_shader_clock   DONE (i965/gen7+, 
radeonsi)
   GL_ARB_shader_draw_parameters DONE (i965, nvc0, 
radeonsi)
   GL_ARB_shader_group_vote  DONE (nvc0, radeonsi)
diff --git a/docs/relnotes/17.1.0.html b/docs/relnotes/17.1.0.html
index 7419970283..10c60a066c 100644
--- a/docs/relnotes/17.1.0.html
+++ b/docs/relnotes/17.1.0.html
@@ -45,7 +45,7 @@ Note: some of the new features are only available with 
certain drivers.
 
 
 GL_ARB_gpu_shader_int64 on i965/gen8+, nvc0, radeonsi, softpipe, 
llvmpipe
-GL_ARB_shader_ballot on radeonsi
+GL_ARB_shader_ballot on nvc0, radeonsi
 GL_ARB_shader_clock on radeonsi
 GL_ARB_shader_group_vote on radeonsi
 GL_ARB_sparse_buffer on radeonsi/CIK+
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 064848db4a..6a027e9a51 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -258,6 +258,8 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
   return class_3d >= NVE4_3D_CLASS; /* needs testing on fermi */
case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
   return class_3d >= GM200_3D_CLASS;
+   case PIPE_CAP_TGSI_BALLOT:
+  return class_3d >= NVE4_3D_CLASS;
 
/* unsupported caps */
case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
@@ -289,7 +291,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_INT64_DIVMOD:
case PIPE_CAP_TGSI_CLOCK:
case PIPE_CAP_SPARSE_BUFFER_PAGE_SIZE:
-   case PIPE_CAP_TGSI_BALLOT:
   return 0;
 
case PIPE_CAP_VENDOR_ID:
-- 
2.12.1

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


[Mesa-dev] [PATCH 7/9] nvc0/ir: Implement TGSI_SEMANTIC_SUBGROUP_*

2017-04-08 Thread Boyan Ding
---
 .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp  | 27 ++
 1 file changed, 27 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
index 13625bf3bd..56e7951e99 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
@@ -450,6 +450,12 @@ static nv50_ir::SVSemantic translateSysVal(uint sysval)
case TGSI_SEMANTIC_BASEINSTANCE: return nv50_ir::SV_BASEINSTANCE;
case TGSI_SEMANTIC_DRAWID: return nv50_ir::SV_DRAWID;
case TGSI_SEMANTIC_WORK_DIM:   return nv50_ir::SV_WORK_DIM;
+   case TGSI_SEMANTIC_SUBGROUP_INVOCATION: return nv50_ir::SV_LANEID;
+   case TGSI_SEMANTIC_SUBGROUP_EQ_MASK: return nv50_ir::SV_LANEMASK_EQ;
+   case TGSI_SEMANTIC_SUBGROUP_LT_MASK: return nv50_ir::SV_LANEMASK_LT;
+   case TGSI_SEMANTIC_SUBGROUP_LE_MASK: return nv50_ir::SV_LANEMASK_LE;
+   case TGSI_SEMANTIC_SUBGROUP_GT_MASK: return nv50_ir::SV_LANEMASK_GT;
+   case TGSI_SEMANTIC_SUBGROUP_GE_MASK: return nv50_ir::SV_LANEMASK_GE;
default:
   assert(0);
   return nv50_ir::SV_CLOCK;
@@ -1667,6 +1673,8 @@ private:
Symbol *srcToSym(tgsi::Instruction::SrcRegister, int c);
Symbol *dstToSym(tgsi::Instruction::DstRegister, int c);
 
+   bool isSubGroupMask(uint8_t semantic);
+
bool handleInstruction(const struct tgsi_full_instruction *);
void exportOutputs();
inline Subroutine *getSubroutine(unsigned ip);
@@ -1996,6 +2004,21 @@ Converter::adjustTempIndex(int arrayId, int &idx, int 
&idx2d) const
idx += it->second;
 }
 
+bool
+Converter::isSubGroupMask(uint8_t semantic)
+{
+   switch (semantic) {
+  case TGSI_SEMANTIC_SUBGROUP_EQ_MASK:
+  case TGSI_SEMANTIC_SUBGROUP_LT_MASK:
+  case TGSI_SEMANTIC_SUBGROUP_LE_MASK:
+  case TGSI_SEMANTIC_SUBGROUP_GT_MASK:
+  case TGSI_SEMANTIC_SUBGROUP_GE_MASK:
+ return true;
+  default:
+ return false;
+   }
+}
+
 Value *
 Converter::fetchSrc(tgsi::Instruction::SrcRegister src, int c, Value *ptr)
 {
@@ -2041,6 +2064,10 @@ Converter::fetchSrc(tgsi::Instruction::SrcRegister src, 
int c, Value *ptr)
   if (info->sv[idx].sn == TGSI_SEMANTIC_THREAD_ID &&
   info->prop.cp.numThreads[swz] == 1)
  return loadImm(NULL, 0u);
+  if (isSubGroupMask(info->sv[idx].sn) && swz > 0)
+ return loadImm(NULL, 0u);
+  if (info->sv[idx].sn == TGSI_SEMANTIC_SUBGROUP_SIZE)
+ return loadImm(NULL, 32u);
   ld = mkOp1(OP_RDSV, TYPE_U32, getSSA(), srcToSym(src, c));
   ld->perPatch = info->sv[idx].patch;
   return ld->getDef(0);
-- 
2.12.1

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


[Mesa-dev] [PATCH 8/9] nvc0/ir: Implement TGSI_OPCODE_BALLOT and TGSI_OPCODE_READ_*

2017-04-08 Thread Boyan Ding
---
 .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp  | 28 ++
 1 file changed, 28 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
index 56e7951e99..10cb2325e9 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
@@ -978,6 +978,10 @@ static nv50_ir::operation translateOpcode(uint opcode)
NV50_IR_OPCODE_CASE(VOTE_ANY, VOTE);
NV50_IR_OPCODE_CASE(VOTE_EQ, VOTE);
 
+   NV50_IR_OPCODE_CASE(BALLOT, VOTE);
+   NV50_IR_OPCODE_CASE(READ_INVOC, SHFL);
+   NV50_IR_OPCODE_CASE(READ_FIRST, SHFL);
+
NV50_IR_OPCODE_CASE(END, EXIT);
 
default:
@@ -3431,6 +3435,30 @@ Converter::handleInstruction(const struct 
tgsi_full_instruction *insn)
  mkCvt(OP_CVT, TYPE_U32, dst0[c], TYPE_U8, val0);
   }
   break;
+   case TGSI_OPCODE_BALLOT:
+  val0 = new_LValue(func, FILE_PREDICATE);
+  mkCmp(OP_SET, CC_NE, TYPE_U32, val0, TYPE_U32, fetchSrc(0, 0), zero);
+  mkOp1(op, TYPE_U32, dst0[0], val0)->subOp = NV50_IR_SUBOP_VOTE_ANY;
+  mkMov(dst0[1], zero, TYPE_U32);
+  break;
+   case TGSI_OPCODE_READ_FIRST:
+  // ReadFirstInvocationARB(src) is implemented as
+  // ReadInvocationARB(src, findLSB(ballot(true)))
+  val0 = getScratch();
+  mkOp1(OP_VOTE, TYPE_U32, val0, mkImm(1))->subOp = NV50_IR_SUBOP_VOTE_ANY;
+  mkOp2(OP_EXTBF, TYPE_U32, val0, val0, mkImm(0x2000))
+ ->subOp = NV50_IR_SUBOP_EXTBF_REV;
+  mkOp1(OP_BFIND, TYPE_U32, val0, val0)->subOp = NV50_IR_SUBOP_BFIND_SAMT;
+  src1 = val0;
+  /* fallthrough */
+   case TGSI_OPCODE_READ_INVOC:
+  if (tgsi.getOpcode() == TGSI_OPCODE_READ_INVOC)
+ src1 = fetchSrc(1, 0);
+  FOR_EACH_DST_ENABLED_CHANNEL(0, c, tgsi) {
+ geni = mkOp3(op, dstTy, dst0[c], fetchSrc(0, c), src1, mkImm(0x1f));
+ geni->subOp = NV50_IR_SUBOP_SHFL_IDX;
+  }
+  break;
case TGSI_OPCODE_KILL_IF:
   val0 = new_LValue(func, FILE_PREDICATE);
   mask = 0;
-- 
2.12.1

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


[Mesa-dev] [PATCH 2/9] nvc0/ir: Properly handle a "split form" of predicate destination

2017-04-08 Thread Boyan Ding
GF100's ISA encoding has a weird form of predicate destination where its
3 bits are split across whole the instruction. Use a dedicated setPDSTL
function instead of original defId which is incorrect in this case.
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
index 5467447e35..d5a310f88c 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
@@ -58,6 +58,7 @@ private:
void setImmediateS8(const ValueRef&);
void setSUConst16(const Instruction *, const int s);
void setSUPred(const Instruction *, const int s);
+   inline void setPDSTL(const ValueDef&);
 
void emitCondCode(CondCode cc, int pos);
void emitInterpMode(const Instruction *);
@@ -375,6 +376,14 @@ void CodeEmitterNVC0::setImmediateS8(const ValueRef &ref)
code[0] |= (s8 >> 6) << 8;
 }
 
+void CodeEmitterNVC0::setPDSTL(const ValueDef &def)
+{
+   uint32_t pred = (def.get() && def.getFile() != FILE_FLAGS ? DDATA(def).id : 
7);
+
+   code[0] |= (pred & 3) << 8;
+   code[1] |= !!(pred & 7) << 26;
+}
+
 void
 CodeEmitterNVC0::emitForm_A(const Instruction *i, uint64_t opc)
 {
@@ -1873,7 +1882,7 @@ CodeEmitterNVC0::emitSTORE(const Instruction *i)
   if (i->src(0).getFile() == FILE_MEMORY_SHARED &&
   i->subOp == NV50_IR_SUBOP_STORE_UNLOCKED) {
  assert(i->defExists(0));
- defId(i->def(0), 8);
+ setPDSTL(i->def(0));
   }
}
 
@@ -1945,7 +1954,7 @@ CodeEmitterNVC0::emitLOAD(const Instruction *i)
 
if (p >= 0) {
   if (targ->getChipset() >= NVISA_GK104_CHIPSET)
- defId(i->def(p), 8);
+ setPDSTL(i->def(p));
   else
  defId(i->def(p), 32 + 18);
}
-- 
2.12.1

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


[Mesa-dev] [PATCH 6/9] nvc0/ir: Add SV_LANEMASK_* system values.

2017-04-08 Thread Boyan Ding
---
 src/gallium/drivers/nouveau/codegen/nv50_ir.h  | 5 +
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 5 +
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 5 +
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp  | 5 +
 4 files changed, 20 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h 
b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
index e161a5a049..ac9791e2f5 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
@@ -470,6 +470,11 @@ enum SVSemantic
SV_BASEINSTANCE,
SV_DRAWID,
SV_WORK_DIM,
+   SV_LANEMASK_EQ,
+   SV_LANEMASK_LT,
+   SV_LANEMASK_LE,
+   SV_LANEMASK_GT,
+   SV_LANEMASK_GE,
SV_UNDEFINED,
SV_LAST
 };
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
index 31af6dcc17..457ae47ef4 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
@@ -2291,6 +2291,11 @@ CodeEmitterGK110::getSRegEncoding(const ValueRef& ref)
case SV_NCTAID:return 0x2d + SDATA(ref).sv.index;
case SV_LBASE: return 0x34;
case SV_SBASE: return 0x30;
+   case SV_LANEMASK_EQ:   return 0x38;
+   case SV_LANEMASK_LT:   return 0x39;
+   case SV_LANEMASK_LE:   return 0x3a;
+   case SV_LANEMASK_GT:   return 0x3b;
+   case SV_LANEMASK_GE:   return 0x3c;
case SV_CLOCK: return 0x50 + SDATA(ref).sv.index;
default:
   assert(!"no sreg for system value");
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index ee1046fea0..1733437b57 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
@@ -269,6 +269,11 @@ CodeEmitterGM107::emitSYS(int pos, const Value *val)
case SV_INVOCATION_INFO: id = 0x1d; break;
case SV_TID: id = 0x21 + val->reg.data.sv.index; break;
case SV_CTAID  : id = 0x25 + val->reg.data.sv.index; break;
+   case SV_LANEMASK_EQ: id = 0x38; break;
+   case SV_LANEMASK_LT: id = 0x39; break;
+   case SV_LANEMASK_LE: id = 0x3a; break;
+   case SV_LANEMASK_GT: id = 0x3b; break;
+   case SV_LANEMASK_GE: id = 0x3c; break;
default:
   assert(!"invalid system value");
   id = 0;
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
index fafb65743e..903319c763 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
@@ -1989,6 +1989,11 @@ CodeEmitterNVC0::getSRegEncoding(const ValueRef& ref)
case SV_NCTAID:return 0x2d + SDATA(ref).sv.index;
case SV_LBASE: return 0x34;
case SV_SBASE: return 0x30;
+   case SV_LANEMASK_EQ:   return 0x38;
+   case SV_LANEMASK_LT:   return 0x39;
+   case SV_LANEMASK_LE:   return 0x3a;
+   case SV_LANEMASK_GT:   return 0x3b;
+   case SV_LANEMASK_GE:   return 0x3c;
case SV_CLOCK: return 0x50 + SDATA(ref).sv.index;
default:
   assert(!"no sreg for system value");
-- 
2.12.1

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


[Mesa-dev] [PATCH 0/9] nvc0: ARB_shader_ballot for Kepler+

2017-04-08 Thread Boyan Ding
This series implements ARB_shader_ballot for Kepler+. I have tested
it on GK208, 8 of 9 of piglit execution tests passed against current
master. The only failed test is because of the test's wrong assumption
when thread group size is less than 64, which is the case for nvidia
hardware. Other architectures (GK104 and GM107) are not tested because
of my lack of hareware, but I have validated the code generated on both
architectures, and it seems correct.

Patches 1-4 implement OP_SHFL emission, with a fix for nvc0 in patch 2.
Patch 5 extends nv50 ir's OP_VOTE to translate readFirstInvocationARB.
Patches 6-8 hook up the logic with tgsi, and the extension is eventually
flipped on in the last patch.

Boyan Ding (9):
  gm107/ir: Emit third src 'bound' and optional predicate output of SHFL
  nvc0/ir: Properly handle a "split form" of predicate destination
  nvc0/ir: Emit OP_SHFL
  gk110/ir: Emit OP_SHFL
  nvc0/ir: Allow 0/1 immediate value as source of OP_VOTE
  nvc0/ir: Add SV_LANEMASK_* system values.
  nvc0/ir: Implement TGSI_SEMANTIC_SUBGROUP_*
  nvc0/ir: Implement TGSI_OPCODE_BALLOT and TGSI_OPCODE_READ_*
  nvc0: Enable ARB_shader_ballot on Kepler+

 docs/features.txt  |  2 +-
 docs/relnotes/17.1.0.html  |  2 +-
 src/gallium/drivers/nouveau/codegen/nv50_ir.h  |  5 ++
 .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 76 +-
 .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 47 +--
 .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp  | 90 --
 .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp  | 55 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c |  3 +-
 8 files changed, 260 insertions(+), 20 deletions(-)

-- 
2.12.1

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


[Mesa-dev] [PATCH 5/9] nvc0/ir: Allow 0/1 immediate value as source of OP_VOTE

2017-04-08 Thread Boyan Ding
Implementation of readFirstInvocationARB() on nvidia hardware needs a
ballotARB(true) used to decide the first active thread. This expressed
in gm107 asm as (supposing output is $r0):
vote any $r0 0x1 0x1

To model the always true input, which corresponds to the second 0x1
above, we make OP_VOTE accept immediate value 0/1 and emit "0x1" and
"not 0x1" in the src field respectively.
---
 .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp  | 21 +
 .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp  | 19 ---
 .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp   | 21 +
 3 files changed, 50 insertions(+), 11 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
index e82e3684b0..31af6dcc17 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
@@ -1615,7 +1615,7 @@ CodeEmitterGK110::emitSHFL(const Instruction *i)
 void
 CodeEmitterGK110::emitVOTE(const Instruction *i)
 {
-   assert(i->src(0).getFile() == FILE_PREDICATE);
+   uint32_t imm;
 
code[0] = 0x0002;
code[1] = 0x86c0 | (i->subOp << 19);
@@ -1640,9 +1640,22 @@ CodeEmitterGK110::emitVOTE(const Instruction *i)
   code[0] |= 255 << 2;
if (!(rp & 2))
   code[1] |= 7 << 16;
-   if (i->src(0).mod == Modifier(NV50_IR_MOD_NOT))
-  code[1] |= 1 << 13;
-   srcId(i->src(0), 42);
+
+   switch (i->src(0).getFile()) {
+   case FILE_PREDICATE:
+  if (i->src(0).mod == Modifier(NV50_IR_MOD_NOT))
+ code[0] |= 1 << 13;
+  srcId(i->src(0), 42);
+  break;
+   case FILE_IMMEDIATE:
+  imm = i->src(0).get()->asImm()->reg.data.u32;
+  assert(imm == 0 || imm == 1);
+  code[1] |= (imm == 1 ? 0x7 : 0xf) << 10;
+  break;
+   default:
+  assert(!"Unhandled src");
+  break;
+   }
 }
 
 void
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index 4a741bf45b..ee1046fea0 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
@@ -2930,7 +2930,7 @@ CodeEmitterGM107::emitMEMBAR()
 void
 CodeEmitterGM107::emitVOTE()
 {
-   assert(insn->src(0).getFile() == FILE_PREDICATE);
+   uint32_t imm;
 
int r = -1, p = -1;
for (int i = 0; insn->defExists(i); i++) {
@@ -2950,8 +2950,21 @@ CodeEmitterGM107::emitVOTE()
   emitPRED (0x2d, insn->def(p));
else
   emitPRED (0x2d);
-   emitField(0x2a, 1, insn->src(0).mod == Modifier(NV50_IR_MOD_NOT));
-   emitPRED (0x27, insn->src(0));
+
+   switch (insn->src(0).getFile()) {
+   case FILE_PREDICATE:
+  emitField(0x2a, 1, insn->src(0).mod == Modifier(NV50_IR_MOD_NOT));
+  emitPRED (0x27, insn->src(0));
+  break;
+   case FILE_IMMEDIATE:
+  imm = insn->src(0).get()->asImm()->reg.data.u32;
+  assert(imm == 0 || imm == 1);
+  emitField(0x27, 4, imm == 1 ? 0x7 : 0xf);
+  break;
+   default:
+  assert(!"Unhandled src");
+  break;
+   }
 }
 
 void
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
index 8dd73bd77d..fafb65743e 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
@@ -2579,7 +2579,7 @@ CodeEmitterNVC0::emitSHFL(const Instruction *i)
 void
 CodeEmitterNVC0::emitVOTE(const Instruction *i)
 {
-   assert(i->src(0).getFile() == FILE_PREDICATE);
+   uint32_t imm;
 
code[0] = 0x0004 | (i->subOp << 5);
code[1] = 0x4800;
@@ -2604,9 +2604,22 @@ CodeEmitterNVC0::emitVOTE(const Instruction *i)
   code[0] |= 63 << 14;
if (!(rp & 2))
   code[1] |= 7 << 22;
-   if (i->src(0).mod == Modifier(NV50_IR_MOD_NOT))
-  code[0] |= 1 << 23;
-   srcId(i->src(0), 20);
+
+   switch (i->src(0).getFile()) {
+   case FILE_PREDICATE:
+  if (i->src(0).mod == Modifier(NV50_IR_MOD_NOT))
+ code[0] |= 1 << 23;
+  srcId(i->src(0), 20);
+  break;
+   case FILE_IMMEDIATE:
+  imm = i->src(0).get()->asImm()->reg.data.u32;
+  assert(imm == 0 || imm == 1);
+  code[0] |= (imm == 1 ? 0x7 : 0xf) << 20;
+  break;
+   default:
+  assert(!"Unhandled src");
+  break;
+   }
 }
 
 bool
-- 
2.12.1

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


[Mesa-dev] [PATCH 1/9] gm107/ir: Emit third src 'bound' and optional predicate output of SHFL

2017-04-08 Thread Boyan Ding
---
 .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 23 ++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index 6903132efa..4a741bf45b 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
@@ -966,11 +966,26 @@ CodeEmitterGM107::emitSHFL()
   break;
}
 
-   /*XXX: what is this arg? hardcode immediate for now */
-   emitField(0x22, 13, 0x1c03);
-   type |= 2;
+   switch (insn->src(2).getFile()) {
+   case FILE_GPR:
+  emitGPR(0x27, insn->src(2));
+  break;
+   case FILE_IMMEDIATE:
+  emitIMMD(0x22, 13, insn->src(2));
+  type |= 2;
+  break;
+   default:
+  assert(!"invalid src2 file");
+  break;
+   }
+
+   if (!insn->defExists(1))
+  emitPRED(0x30);
+   else {
+  assert(insn->def(1).getFile() == FILE_PREDICATE);
+  emitPRED(0x30, insn->def(1));
+   }
 
-   emitPRED (0x30);
emitField(0x1e, 2, insn->subOp);
emitField(0x1c, 2, type);
emitGPR  (0x08, insn->src(0));
-- 
2.12.1

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


[Mesa-dev] [PATCH 4/9] gk110/ir: Emit OP_SHFL

2017-04-08 Thread Boyan Ding
---
 .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 50 ++
 1 file changed, 50 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
index 1121ae0912..e82e3684b0 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
@@ -135,6 +135,8 @@ private:
 
void emitFlow(const Instruction *);
 
+   void emitSHFL(const Instruction *);
+
void emitVOTE(const Instruction *);
 
void emitSULDGB(const TexInstruction *);
@@ -1566,6 +1568,51 @@ CodeEmitterGK110::emitFlow(const Instruction *i)
 }
 
 void
+CodeEmitterGK110::emitSHFL(const Instruction *i)
+{
+   code[0] = 0x0002;
+   code[1] = 0x7880 | (i->subOp << 1);
+
+   emitPredicate(i);
+
+   defId(i->def(0), 2);
+   srcId(i->src(0), 10);
+
+   switch (i->src(1).getFile()) {
+   case FILE_GPR:
+  srcId(i->src(1), 23);
+  break;
+   case FILE_IMMEDIATE:
+  code[0] |= (i->src(1).get()->asImm()->reg.data.u32 & 0x1f) << 23;
+  code[0] |= 1 << 31;
+  break;
+   default:
+  assert(!"invalid src1 file");
+  break;
+   }
+
+   switch (i->src(2).getFile()) {
+   case FILE_GPR:
+  srcId(i->src(2), 42);
+  break;
+   case FILE_IMMEDIATE:
+  code[1] |= (i->src(2).get()->asImm()->reg.data.u32 & 0x1fff) << 5;
+  code[1] |= 1;
+  break;
+   default:
+  assert(!"invalid src2 file");
+  break;
+   }
+
+   if (!i->defExists(1))
+  code[1] |= 7 << 19;
+   else {
+  assert(i->def(1).getFile() == FILE_PREDICATE);
+  defId(i->def(1), 51);
+   }
+}
+
+void
 CodeEmitterGK110::emitVOTE(const Instruction *i)
 {
assert(i->src(0).getFile() == FILE_PREDICATE);
@@ -2642,6 +2689,9 @@ CodeEmitterGK110::emitInstruction(Instruction *insn)
case OP_CCTL:
   emitCCTL(insn);
   break;
+   case OP_SHFL:
+  emitSHFL(insn);
+  break;
case OP_VOTE:
   emitVOTE(insn);
   break;
-- 
2.12.1

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


[Mesa-dev] [PATCH 3/9] nvc0/ir: Emit OP_SHFL

2017-04-08 Thread Boyan Ding
---
 .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp  | 51 ++
 1 file changed, 51 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
index d5a310f88c..8dd73bd77d 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
@@ -150,6 +150,8 @@ private:
 
void emitPIXLD(const Instruction *);
 
+   void emitSHFL(const Instruction *);
+
void emitVOTE(const Instruction *);
 
inline void defId(const ValueDef&, const int pos);
@@ -2529,6 +2531,52 @@ CodeEmitterNVC0::emitPIXLD(const Instruction *i)
 }
 
 void
+CodeEmitterNVC0::emitSHFL(const Instruction *i)
+{
+   code[0] = 0x0005;
+   code[1] = 0x8800 | (i->subOp << 23);
+
+   emitPredicate(i);
+
+   defId(i->def(0), 14);
+   srcId(i->src(0), 20);
+
+   switch (i->src(1).getFile()) {
+   case FILE_GPR:
+  srcId(i->src(1), 26);
+  break;
+   case FILE_IMMEDIATE:
+  code[0] |= (i->src(1).get()->asImm()->reg.data.u32 & 0x1f) << 26;
+  code[0] |= 1 << 5;
+  break;
+   default:
+  assert(!"invalid src1 file");
+  break;
+   }
+
+   switch (i->src(2).getFile()) {
+   case FILE_GPR:
+  srcId(i->src(2), 49);
+  break;
+   case FILE_IMMEDIATE:
+  code[1] |= (i->src(2).get()->asImm()->reg.data.u32 & 0x1fff) << 10;
+  code[0] |= 1 << 6;
+  break;
+   default:
+  assert(!"invalid src2 file");
+  break;
+   }
+
+   if (!i->defExists(1)) {
+  code[0] |= 3 << 8;
+  code[1] |= 1 << 26;
+   } else {
+  assert(i->def(1).getFile() == FILE_PREDICATE);
+  setPDSTL(i->def(1));
+   }
+}
+
+void
 CodeEmitterNVC0::emitVOTE(const Instruction *i)
 {
assert(i->src(0).getFile() == FILE_PREDICATE);
@@ -2837,6 +2885,9 @@ CodeEmitterNVC0::emitInstruction(Instruction *insn)
case OP_PIXLD:
   emitPIXLD(insn);
   break;
+   case OP_SHFL:
+  emitSHFL(insn);
+  break;
case OP_VOTE:
   emitVOTE(insn);
   break;
-- 
2.12.1

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


Re: [Mesa-dev] Mesa master: 'current' 'git fsck' version catching content which was always bad but not reported before

2017-04-08 Thread Nicolai Hähnle

On 08.04.2017 02:54, Dieter Nützel wrote:

Hello all,

'current' git version here: git version 2.12.2

https://github.com/collectd/collectd/issues/2115
Comment from: philpennock commented on 27 Dec 2016

[-]
This is a git fsck change dating from around git 2.5ish, catching
content which was always bad but not reported before. Anyone not seeing
this is working with ancient git(1). Current release is 2.11.0.

The repo has bad content which may continue to work for old clients, or
anyone not doing repo integrity checks, but is really now in "technical
debt" status. There are scripts floating around to rewrite git history
to fix this date formatting issue; pushing that will then become a
"force push" and so require the usual "oh no not another force-push flag
day" song and dance.
[-]

Output looks like this:
/opt/mesa> git fsck
Prüfe Objekt-Verzeichnisse: 100% (256/256), Fertig.
error in tag feb356caff82e996ba0b898c02383fdfa3effc5f:
missingSpaceBeforeDate: invalid author/committer line - missing space
before date
error in tag 5562545645baea8e3d8409d712ab0a5da90e355c:
missingSpaceBeforeDate: invalid author/committer line - missing space
before date
error in tag 81cbf07eddf3bb65866db8baa1be47cd4f417088:
missingSpaceBeforeDate: invalid author/committer line - missing space
before date
error in tag 9d03a22875b313388d28b211a5751e037d9a45c9:
missingSpaceBeforeDate: invalid author/committer line - missing space
before date
error in tag ee54d15473093647dc2c9a3d0718537f2db64323:
missingSpaceBeforeDate: invalid author/committer line - missing space
before date
[-]


I see this too. As long as it just concerns tags, we can probably just 
go through them, see if any of them are still relevant, and delete the rest?


Some of them seem to be tags of old Mesa releases, e.g. 
d3d91230e1fbceda678c125c66c16ee910337e08. Those could perhaps be deleted 
and re-created.


Cheers,
Nicolai




Any hints?

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



--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev