date:20150525

Re: [Nouveau] [PATCH 5/8] acpi: Check returned object type by Optimus _DSM locally

2015-05-25 Thread Ilia Mirkin

On Tue, May 26, 2015 at 1:10 AM, Pierre Moreau  wrote:
>> On 26 May 2015, at 00:39, Ilia Mirkin  wrote:
>>
>>> On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau  
>>> wrote:
>>> Most _DSM will return an integer value of 0x8002 when given an unknown
>>> UUID, revision ID or function ID. Checking locally allows us to 
>>> differentiate
>>> that case from other ACPI errors, and to not report a "failed to evaluate 
>>> _DSM"
>>> if 0x8002 is returned which was confusing.
>>>
>>> Signed-off-by: Pierre Moreau 
>>> ---
>>> drm/nouveau/nouveau_acpi.c | 15 ---
>>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
>>> index 073f7d7..7aeaf7d 100644
>>> --- a/drm/nouveau/nouveau_acpi.c
>>> +++ b/drm/nouveau/nouveau_acpi.c
>>> @@ -88,12 +88,12 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle 
>>> handle, int func, int arg, u
>>>for (i = 0; i < 4; i++)
>>>args_buff[i] = (arg >> i * 8) & 0xFF;
>>>
>>> -   obj = acpi_evaluate_dsm_typed(handle, nouveau_op_dsm_muid, 
>>> nouveau_op_dsm_rid,
>>> - func, &argv4, ACPI_TYPE_BUFFER);
>>> +   obj = acpi_evaluate_dsm(handle, nouveau_op_dsm_muid, 
>>> nouveau_op_dsm_rid,
>>> +   func, &argv4);
>>>if (!obj) {
>>>acpi_handle_info(handle, "failed to evaluate _DSM\n");
>>>return AE_ERROR;
>>> -   } else {
>>> +   } else if (obj->type == ACPI_TYPE_BUFFER) {
>>>if (!result && obj->buffer.length == 4) {
>>>*result  = obj->buffer.pointer[0];
>>>*result |= (obj->buffer.pointer[1] << 8);
>>> @@ -101,6 +101,15 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle 
>>> handle, int func, int arg, u
>>>*result |= (obj->buffer.pointer[3] << 24);
>>>}
>>>ACPI_FREE(obj);
>>> +   } else if (obj->type == ACPI_TYPE_INTEGER &&
>>> +  obj->integer.value == 0x8002) {
>>> +   acpi_handle_debug(handle, "failed to query Optimus _DSM\n");
>>> +   ACPI_FREE(obj);
>>> +   return -ENODEV;
>>
>> should this be AE_ERROR?
>
> I would say no, because ACPI was parsed correctly, just that we didn't it 
> give the correct arguments, or rather, the _DSM we tested isn't an Optimus 
> one, but it could a mux or gmux. And I used ENODEV as it is the value 
> returned by nouveau_evaluate_mux_dsm in the same context.

Hm ok. It just seemed odd to be returning AE_* in one context, and
-ENODEV in another context -- they're different types of errors.
However if the caller handles it, I guess it's OK... I haven't looked
at the API in depth.

>
>>
>>> +   } else {
>>> +   acpi_handle_err(handle, "unexpected returned value by 
>>> Optimus _DSM\n");
>>> +   ACPI_FREE(obj);
>>> +   return AE_ERROR;
>>>}
>>>
>>>return 0;
>>> --
>>> 2.4.1
>>>
>>> ___
>>> Nouveau mailing list
>>> Nouveau@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 5/8] acpi: Check returned object type by Optimus _DSM locally

2015-05-25 Thread Pierre Moreau





> On 26 May 2015, at 00:39, Ilia Mirkin  wrote:
> 
>> On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau  wrote:
>> Most _DSM will return an integer value of 0x8002 when given an unknown
>> UUID, revision ID or function ID. Checking locally allows us to differentiate
>> that case from other ACPI errors, and to not report a "failed to evaluate 
>> _DSM"
>> if 0x8002 is returned which was confusing.
>> 
>> Signed-off-by: Pierre Moreau 
>> ---
>> drm/nouveau/nouveau_acpi.c | 15 ---
>> 1 file changed, 12 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
>> index 073f7d7..7aeaf7d 100644
>> --- a/drm/nouveau/nouveau_acpi.c
>> +++ b/drm/nouveau/nouveau_acpi.c
>> @@ -88,12 +88,12 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle 
>> handle, int func, int arg, u
>>for (i = 0; i < 4; i++)
>>args_buff[i] = (arg >> i * 8) & 0xFF;
>> 
>> -   obj = acpi_evaluate_dsm_typed(handle, nouveau_op_dsm_muid, 
>> nouveau_op_dsm_rid,
>> - func, &argv4, ACPI_TYPE_BUFFER);
>> +   obj = acpi_evaluate_dsm(handle, nouveau_op_dsm_muid, 
>> nouveau_op_dsm_rid,
>> +   func, &argv4);
>>if (!obj) {
>>acpi_handle_info(handle, "failed to evaluate _DSM\n");
>>return AE_ERROR;
>> -   } else {
>> +   } else if (obj->type == ACPI_TYPE_BUFFER) {
>>if (!result && obj->buffer.length == 4) {
>>*result  = obj->buffer.pointer[0];
>>*result |= (obj->buffer.pointer[1] << 8);
>> @@ -101,6 +101,15 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle 
>> handle, int func, int arg, u
>>*result |= (obj->buffer.pointer[3] << 24);
>>}
>>ACPI_FREE(obj);
>> +   } else if (obj->type == ACPI_TYPE_INTEGER &&
>> +  obj->integer.value == 0x8002) {
>> +   acpi_handle_debug(handle, "failed to query Optimus _DSM\n");
>> +   ACPI_FREE(obj);
>> +   return -ENODEV;
> 
> should this be AE_ERROR?

I would say no, because ACPI was parsed correctly, just that we didn't it give 
the correct arguments, or rather, the _DSM we tested isn't an Optimus one, but 
it could a mux or gmux. And I used ENODEV as it is the value returned by 
nouveau_evaluate_mux_dsm in the same context. 

> 
>> +   } else {
>> +   acpi_handle_err(handle, "unexpected returned value by 
>> Optimus _DSM\n");
>> +   ACPI_FREE(obj);
>> +   return AE_ERROR;
>>}
>> 
>>return 0;
>> --
>> 2.4.1
>> 
>> ___
>> Nouveau mailing list
>> Nouveau@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH v2 4/4] nv30: falling back to draw path for edgeflag does no good

2015-05-25 Thread Ilia Mirkin

The problem is that the EDGEFLAG has to be toggled at vertex submission
time. This can be done from either the draw or the regular paths. Avoid
falling back to draw just because there's an edgeflag.

Signed-off-by: Ilia Mirkin 
Cc: "10.5 10.6" 
---
 src/gallium/drivers/nouveau/nv30/nvfx_vertprog.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv30/nvfx_vertprog.c 
b/src/gallium/drivers/nouveau/nv30/nvfx_vertprog.c
index c8960db..1ce0589 100644
--- a/src/gallium/drivers/nouveau/nv30/nvfx_vertprog.c
+++ b/src/gallium/drivers/nouveau/nv30/nvfx_vertprog.c
@@ -872,9 +872,8 @@ nvfx_vertprog_parse_decl_output(struct nvfx_vpc *vpc,
   }
   break;
case TGSI_SEMANTIC_EDGEFLAG:
-  /* not really an error just a fallback */
-  NOUVEAU_ERR("cannot handle edgeflag output\n");
-  return FALSE;
+  vpc->r_result[idx] = nvfx_reg(NVFXSR_NONE, 0);
+  return TRUE;
default:
   NOUVEAU_ERR("bad output semantic\n");
   return FALSE;
-- 
2.3.6

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH v2 2/4] nv30/draw: allocate vertex buffers in gart

2015-05-25 Thread Ilia Mirkin

These are only used once per draw, so it makes sense to keep them in
GART. Also take this opportunity to modernize the buffer mapping API
usage.

Signed-off-by: Ilia Mirkin 
Cc: "10.5 10.6" 
---
 src/gallium/drivers/nouveau/nv30/nv30_draw.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv30/nv30_draw.c 
b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
index b0557b0..7ae1a1b 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_draw.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
@@ -71,12 +71,12 @@ nv30_render_allocate_vertices(struct vbuf_render *render,
struct nv30_render *r = nv30_render(render);
struct nv30_context *nv30 = r->nv30;
 
-   r->length = vertex_size * nr_vertices;
+   r->length = (uint32_t)vertex_size * (uint32_t)nr_vertices;
 
if (r->offset + r->length >= render->max_vertex_buffer_bytes) {
   pipe_resource_reference(&r->buffer, NULL);
   r->buffer = pipe_buffer_create(&nv30->screen->base.base,
- PIPE_BIND_VERTEX_BUFFER, 0,
+ PIPE_BIND_VERTEX_BUFFER, 
PIPE_USAGE_STREAM,
  render->max_vertex_buffer_bytes);
   if (!r->buffer)
  return FALSE;
@@ -91,10 +91,14 @@ static void *
 nv30_render_map_vertices(struct vbuf_render *render)
 {
struct nv30_render *r = nv30_render(render);
-   char *map = pipe_buffer_map(&r->nv30->base.pipe, r->buffer,
-   PIPE_TRANSFER_WRITE |
-   PIPE_TRANSFER_UNSYNCHRONIZED, &r->transfer);
-   return map + r->offset;
+   char *map = pipe_buffer_map_range(
+ &r->nv30->base.pipe, r->buffer,
+ r->offset, r->length,
+ PIPE_TRANSFER_WRITE |
+ PIPE_TRANSFER_DISCARD_RANGE,
+ &r->transfer);
+   assert(map);
+   return map;
 }
 
 static void
-- 
2.3.6

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH v2 1/4] nv30/draw: only use the DMA1 object (GART) if the bo is not in VRAM

2015-05-25 Thread Ilia Mirkin

Instead of always having it in the data, let the bo placement decide it.
This fixes glxgears with swtnl forced on.

Signed-off-by: Ilia Mirkin 
Cc: "10.5 10.6" 
---
 src/gallium/drivers/nouveau/nv30/nv30_draw.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv30/nv30_draw.c 
b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
index 340474a..b0557b0 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_draw.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
@@ -127,7 +127,7 @@ nv30_render_draw_elements(struct vbuf_render *render,
for (i = 0; i < r->vertex_info.num_attribs; i++) {
   PUSH_RESRC(push, NV30_3D(VTXBUF(i)), BUFCTX_VTXTMP,
nv04_resource(r->buffer), r->offset + r->vtxptr[i],
-   NOUVEAU_BO_LOW | NOUVEAU_BO_RD, 0, 0);
+   NOUVEAU_BO_LOW | NOUVEAU_BO_RD, 0, NV30_3D_VTXBUF_DMA1);
}
 
if (!nv30_state_validate(nv30, ~0, FALSE))
@@ -172,7 +172,7 @@ nv30_render_draw_arrays(struct vbuf_render *render, 
unsigned start, uint nr)
for (i = 0; i < r->vertex_info.num_attribs; i++) {
   PUSH_RESRC(push, NV30_3D(VTXBUF(i)), BUFCTX_VTXTMP,
nv04_resource(r->buffer), r->offset + r->vtxptr[i],
-   NOUVEAU_BO_LOW | NOUVEAU_BO_RD, 0, 0);
+   NOUVEAU_BO_LOW | NOUVEAU_BO_RD, 0, NV30_3D_VTXBUF_DMA1);
}
 
if (!nv30_state_validate(nv30, ~0, FALSE))
@@ -245,7 +245,7 @@ vroute_add(struct nv30_render *r, uint attrib, uint sem, 
uint *idx)
format = draw_translate_vinfo_format(emit);
 
r->vtxfmt[attrib] = nv30_vtxfmt(pscreen, format)->hw;
-   r->vtxptr[attrib] = vinfo->size | NV30_3D_VTXBUF_DMA1;
+   r->vtxptr[attrib] = vinfo->size;
vinfo->size += draw_translate_vinfo_size(emit);
 
if (nv30_screen(pscreen)->eng3d->oclass < NV40_3D_CLASS) {
-- 
2.3.6

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH v2 3/4] nv30/draw: switch varying hookup logic to know about texcoords

2015-05-25 Thread Ilia Mirkin

Commit 8acaf862dfe switched things over to use TEXCOORD instead of
GENERIC, but did not update the nv30 swtnl draw paths. This teaches the
draw logic about TEXCOORD.

Among other things, this fixes a crash in demos/arbocclude when using
swtnl. Curiously enough, the point-sprite piglit works without this.

Signed-off-by: Ilia Mirkin 
Cc: "10.5 10.6" 
---
 src/gallium/drivers/nouveau/nv30/nv30_draw.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv30/nv30_draw.c 
b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
index 7ae1a1b..c1665b7 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_draw.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
@@ -218,22 +218,24 @@ static const struct {
[TGSI_SEMANTIC_BCOLOR  ] = { EMIT_4F, INTERP_LINEAR , 1, 3, 0x0004 
},
[TGSI_SEMANTIC_FOG ] = { EMIT_4F, INTERP_PERSPECTIVE, 5, 5, 0x0010 
},
[TGSI_SEMANTIC_PSIZE   ] = { EMIT_1F_PSIZE, INTERP_POS  , 6, 6, 0x0020 
},
-   [TGSI_SEMANTIC_GENERIC ] = { EMIT_4F, INTERP_PERSPECTIVE, 8, 7, 0x4000 }
+   [TGSI_SEMANTIC_TEXCOORD] = { EMIT_4F, INTERP_PERSPECTIVE, 8, 7, 0x4000 
},
 };
 
 static boolean
 vroute_add(struct nv30_render *r, uint attrib, uint sem, uint *idx)
 {
-   struct pipe_screen *pscreen = &r->nv30->screen->base.base;
+   struct nv30_screen *screen = r->nv30->screen;
struct nv30_fragprog *fp = r->nv30->fragprog.program;
struct vertex_info *vinfo = &r->vertex_info;
enum pipe_format format;
uint emit = EMIT_OMIT;
uint result = *idx;
 
-   if (sem == TGSI_SEMANTIC_GENERIC && result >= 8) {
-  for (result = 0; result < 8; result++) {
- if (fp->texcoord[result] == *idx) {
+   if (sem == TGSI_SEMANTIC_GENERIC) {
+  uint num_texcoords = (screen->eng3d->oclass < NV40_3D_CLASS) ? 8 : 10;
+  for (result = 0; result < num_texcoords; result++) {
+ if (fp->texcoord[result] == *idx + 8) {
+sem = TGSI_SEMANTIC_TEXCOORD;
 emit = vroute[sem].emit;
 break;
  }
@@ -248,11 +250,11 @@ vroute_add(struct nv30_render *r, uint attrib, uint sem, 
uint *idx)
draw_emit_vertex_attr(vinfo, emit, vroute[sem].interp, attrib);
format = draw_translate_vinfo_format(emit);
 
-   r->vtxfmt[attrib] = nv30_vtxfmt(pscreen, format)->hw;
+   r->vtxfmt[attrib] = nv30_vtxfmt(&screen->base.base, format)->hw;
r->vtxptr[attrib] = vinfo->size;
vinfo->size += draw_translate_vinfo_size(emit);
 
-   if (nv30_screen(pscreen)->eng3d->oclass < NV40_3D_CLASS) {
+   if (screen->eng3d->oclass < NV40_3D_CLASS) {
   r->vtxprog[attrib][0] = 0x001f38d8;
   r->vtxprog[attrib][1] = 0x0080001b | (attrib << 9);
   r->vtxprog[attrib][2] = 0x0836106c;
@@ -264,7 +266,12 @@ vroute_add(struct nv30_render *r, uint attrib, uint sem, 
uint *idx)
   r->vtxprog[attrib][3] = 0x6041ff80 | (result + vroute[sem].vp40) << 2;
}
 
-   *idx = vroute[sem].ow40 << result;
+   if (result < 8)
+  *idx = vroute[sem].ow40 << result;
+   else {
+  assert(sem == TGSI_SEMANTIC_TEXCOORD);
+  *idx = 0x1000 << (result - 8);
+   }
return TRUE;
 }
 
@@ -318,7 +325,7 @@ nv30_render_validate(struct nv30_context *nv30)
 
while (pntc && attrib < 16) {
   uint index = ffs(pntc) - 1; pntc &= ~(1 << index);
-  if (vroute_add(r, attrib, TGSI_SEMANTIC_GENERIC, &index)) {
+  if (vroute_add(r, attrib, TGSI_SEMANTIC_TEXCOORD, &index)) {
  vp_attribs |= (1 << attrib++);
  vp_results |= index;
   }
-- 
2.3.6

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/2] nv30/draw: switch varying hookup logic to know about texcoords

2015-05-25 Thread Ilia Mirkin

On Mon, May 25, 2015 at 8:55 PM, Tobias Klausmann
 wrote:
>
>
> On 26.05.2015 02:49, Ilia Mirkin wrote:
>>
>> On Mon, May 25, 2015 at 8:37 PM, Tobias Klausmann
>>  wrote:
>>>
>>>
>>> On 25.05.2015 21:29, Ilia Mirkin wrote:

 Commit 8acaf862dfe switched things over to use TEXCOORD instead of
 GENERIC, but did not update the nv30 swtnl draw paths. This teaches the
 draw logic about TEXCOORD.

 Among other things, this fixes a crash in demos/arbocclude when using
 swtnl. Curiously enough, the point-sprite piglit works without this.

 Signed-off-by: Ilia Mirkin 
 Cc: "10.5 10.6" 
 ---
src/gallium/drivers/nouveau/nv30/nv30_draw.c | 25
 -
1 file changed, 16 insertions(+), 9 deletions(-)

 diff --git a/src/gallium/drivers/nouveau/nv30/nv30_draw.c
 b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
 index a681135..03c0c70 100644
 --- a/src/gallium/drivers/nouveau/nv30/nv30_draw.c
 +++ b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
 @@ -230,22 +230,24 @@ static const struct {
   [TGSI_SEMANTIC_BCOLOR  ] = { EMIT_4F, INTERP_LINEAR , 1, 3,
 0x0004 },
   [TGSI_SEMANTIC_FOG ] = { EMIT_4F, INTERP_PERSPECTIVE, 5, 5,
 0x0010 },
   [TGSI_SEMANTIC_PSIZE   ] = { EMIT_1F_PSIZE, INTERP_POS  , 6, 6,
 0x0020 },
 -   [TGSI_SEMANTIC_GENERIC ] = { EMIT_4F, INTERP_PERSPECTIVE, 8, 7,
 0x4000 }
 +   [TGSI_SEMANTIC_TEXCOORD] = { EMIT_4F, INTERP_PERSPECTIVE, 8, 7,
 0x4000 },
};
  static boolean
vroute_add(struct nv30_render *r, uint attrib, uint sem, uint *idx)
{
 -   struct pipe_screen *pscreen = &r->nv30->screen->base.base;
 +   struct nv30_screen *screen = r->nv30->screen;
   struct nv30_fragprog *fp = r->nv30->fragprog.program;
   struct vertex_info *vinfo = &r->vertex_info;
   enum pipe_format format;
   uint emit = EMIT_OMIT;
   uint result = *idx;
-   if (sem == TGSI_SEMANTIC_GENERIC && result >= 8) {
 -  for (result = 0; result < 8; result++) {
 - if (fp->texcoord[result] == *idx) {
 +   if (sem == TGSI_SEMANTIC_GENERIC) {
 +  uint num_texcoords = (screen->eng3d->oclass < NV40_3D_CLASS) ? 8
 :
 10;
 +  for (result = 0; result < num_texcoords; result++) {
 + if (fp->texcoord[result] == *idx + 8) {
>>>
>>>
>>> maybe i'm too tired, but why exactly *idx + 8 ?
>>
>> See nvfx_fragprog.c:
>>
>> fpc->fp->texcoord[hw] = fdec->Semantic.Index + 8;
>>
>> when the semantic is GENERIC. (and 0xfffe when it's PCOORD). This is
>> because there can be up to 8 TEXCOORD's.
>
>
> yet you run for 8 or 10 texcoords. Wont this cause problems on nv40+?

this is just the handle... it could just as well be + 1000. As long as
it's > 8, since that's what gets stored for the TEXCOORD semantics.

>
>
>>
 +sem = TGSI_SEMANTIC_TEXCOORD;
emit = vroute[sem].emit;
break;
 }
 @@ -260,11 +262,11 @@ vroute_add(struct nv30_render *r, uint attrib,
 uint
 sem, uint *idx)
   draw_emit_vertex_attr(vinfo, emit, vroute[sem].interp, attrib);
   format = draw_translate_vinfo_format(emit);
-   r->vtxfmt[attrib] = nv30_vtxfmt(pscreen, format)->hw;
 +   r->vtxfmt[attrib] = nv30_vtxfmt(&screen->base.base, format)->hw;
   r->vtxptr[attrib] = vinfo->size | NV30_3D_VTXBUF_DMA1;
   vinfo->size += draw_translate_vinfo_size(emit);
-   if (nv30_screen(pscreen)->eng3d->oclass < NV40_3D_CLASS) {
 +   if (screen->eng3d->oclass < NV40_3D_CLASS) {
  r->vtxprog[attrib][0] = 0x001f38d8;
  r->vtxprog[attrib][1] = 0x0080001b | (attrib << 9);
  r->vtxprog[attrib][2] = 0x0836106c;
 @@ -276,7 +278,12 @@ vroute_add(struct nv30_render *r, uint attrib, uint
 sem, uint *idx)
  r->vtxprog[attrib][3] = 0x6041ff80 | (result +
 vroute[sem].vp40)
 << 2;
   }
-   *idx = vroute[sem].ow40 << result;
 +   if (result < 8)
 +  *idx = vroute[sem].ow40 << result;
 +   else {
 +  assert(sem == TGSI_SEMANTIC_TEXCOORD);
 +  *idx = 0x1000 << (result - 8);
 +   }
   return TRUE;
}
@@ -330,7 +337,7 @@ nv30_render_validate(struct nv30_context *nv30)
 while (pntc && attrib < 16) {
  uint index = ffs(pntc) - 1; pntc &= ~(1 << index);
 -  if (vroute_add(r, attrib, TGSI_SEMANTIC_GENERIC, &index)) {
 +  if (vroute_add(r, attrib, TGSI_SEMANTIC_TEXCOORD, &index)) {
 vp_attribs |= (1 << attrib++);
 vp_results |= index;
  }
>>>
>>>
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/2] nv30/draw: switch varying hookup logic to know about texcoords

2015-05-25 Thread Tobias Klausmann




On 26.05.2015 02:49, Ilia Mirkin wrote:

On Mon, May 25, 2015 at 8:37 PM, Tobias Klausmann
 wrote:


On 25.05.2015 21:29, Ilia Mirkin wrote:

Commit 8acaf862dfe switched things over to use TEXCOORD instead of
GENERIC, but did not update the nv30 swtnl draw paths. This teaches the
draw logic about TEXCOORD.

Among other things, this fixes a crash in demos/arbocclude when using
swtnl. Curiously enough, the point-sprite piglit works without this.

Signed-off-by: Ilia Mirkin 
Cc: "10.5 10.6" 
---
   src/gallium/drivers/nouveau/nv30/nv30_draw.c | 25
-
   1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv30/nv30_draw.c
b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
index a681135..03c0c70 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_draw.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
@@ -230,22 +230,24 @@ static const struct {
  [TGSI_SEMANTIC_BCOLOR  ] = { EMIT_4F, INTERP_LINEAR , 1, 3,
0x0004 },
  [TGSI_SEMANTIC_FOG ] = { EMIT_4F, INTERP_PERSPECTIVE, 5, 5,
0x0010 },
  [TGSI_SEMANTIC_PSIZE   ] = { EMIT_1F_PSIZE, INTERP_POS  , 6, 6,
0x0020 },
-   [TGSI_SEMANTIC_GENERIC ] = { EMIT_4F, INTERP_PERSPECTIVE, 8, 7,
0x4000 }
+   [TGSI_SEMANTIC_TEXCOORD] = { EMIT_4F, INTERP_PERSPECTIVE, 8, 7,
0x4000 },
   };
 static boolean
   vroute_add(struct nv30_render *r, uint attrib, uint sem, uint *idx)
   {
-   struct pipe_screen *pscreen = &r->nv30->screen->base.base;
+   struct nv30_screen *screen = r->nv30->screen;
  struct nv30_fragprog *fp = r->nv30->fragprog.program;
  struct vertex_info *vinfo = &r->vertex_info;
  enum pipe_format format;
  uint emit = EMIT_OMIT;
  uint result = *idx;
   -   if (sem == TGSI_SEMANTIC_GENERIC && result >= 8) {
-  for (result = 0; result < 8; result++) {
- if (fp->texcoord[result] == *idx) {
+   if (sem == TGSI_SEMANTIC_GENERIC) {
+  uint num_texcoords = (screen->eng3d->oclass < NV40_3D_CLASS) ? 8 :
10;
+  for (result = 0; result < num_texcoords; result++) {
+ if (fp->texcoord[result] == *idx + 8) {


maybe i'm too tired, but why exactly *idx + 8 ?

See nvfx_fragprog.c:

fpc->fp->texcoord[hw] = fdec->Semantic.Index + 8;

when the semantic is GENERIC. (and 0xfffe when it's PCOORD). This is
because there can be up to 8 TEXCOORD's.


yet you run for 8 or 10 texcoords. Wont this cause problems on nv40+?




+sem = TGSI_SEMANTIC_TEXCOORD;
   emit = vroute[sem].emit;
   break;
}
@@ -260,11 +262,11 @@ vroute_add(struct nv30_render *r, uint attrib, uint
sem, uint *idx)
  draw_emit_vertex_attr(vinfo, emit, vroute[sem].interp, attrib);
  format = draw_translate_vinfo_format(emit);
   -   r->vtxfmt[attrib] = nv30_vtxfmt(pscreen, format)->hw;
+   r->vtxfmt[attrib] = nv30_vtxfmt(&screen->base.base, format)->hw;
  r->vtxptr[attrib] = vinfo->size | NV30_3D_VTXBUF_DMA1;
  vinfo->size += draw_translate_vinfo_size(emit);
   -   if (nv30_screen(pscreen)->eng3d->oclass < NV40_3D_CLASS) {
+   if (screen->eng3d->oclass < NV40_3D_CLASS) {
 r->vtxprog[attrib][0] = 0x001f38d8;
 r->vtxprog[attrib][1] = 0x0080001b | (attrib << 9);
 r->vtxprog[attrib][2] = 0x0836106c;
@@ -276,7 +278,12 @@ vroute_add(struct nv30_render *r, uint attrib, uint
sem, uint *idx)
 r->vtxprog[attrib][3] = 0x6041ff80 | (result + vroute[sem].vp40)
<< 2;
  }
   -   *idx = vroute[sem].ow40 << result;
+   if (result < 8)
+  *idx = vroute[sem].ow40 << result;
+   else {
+  assert(sem == TGSI_SEMANTIC_TEXCOORD);
+  *idx = 0x1000 << (result - 8);
+   }
  return TRUE;
   }
   @@ -330,7 +337,7 @@ nv30_render_validate(struct nv30_context *nv30)
while (pntc && attrib < 16) {
 uint index = ffs(pntc) - 1; pntc &= ~(1 << index);
-  if (vroute_add(r, attrib, TGSI_SEMANTIC_GENERIC, &index)) {
+  if (vroute_add(r, attrib, TGSI_SEMANTIC_TEXCOORD, &index)) {
vp_attribs |= (1 << attrib++);
vp_results |= index;
 }




___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/2] nv30/draw: switch varying hookup logic to know about texcoords

2015-05-25 Thread Ilia Mirkin

On Mon, May 25, 2015 at 8:37 PM, Tobias Klausmann
 wrote:
>
>
> On 25.05.2015 21:29, Ilia Mirkin wrote:
>>
>> Commit 8acaf862dfe switched things over to use TEXCOORD instead of
>> GENERIC, but did not update the nv30 swtnl draw paths. This teaches the
>> draw logic about TEXCOORD.
>>
>> Among other things, this fixes a crash in demos/arbocclude when using
>> swtnl. Curiously enough, the point-sprite piglit works without this.
>>
>> Signed-off-by: Ilia Mirkin 
>> Cc: "10.5 10.6" 
>> ---
>>   src/gallium/drivers/nouveau/nv30/nv30_draw.c | 25
>> -
>>   1 file changed, 16 insertions(+), 9 deletions(-)
>>
>> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_draw.c
>> b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
>> index a681135..03c0c70 100644
>> --- a/src/gallium/drivers/nouveau/nv30/nv30_draw.c
>> +++ b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
>> @@ -230,22 +230,24 @@ static const struct {
>>  [TGSI_SEMANTIC_BCOLOR  ] = { EMIT_4F, INTERP_LINEAR , 1, 3,
>> 0x0004 },
>>  [TGSI_SEMANTIC_FOG ] = { EMIT_4F, INTERP_PERSPECTIVE, 5, 5,
>> 0x0010 },
>>  [TGSI_SEMANTIC_PSIZE   ] = { EMIT_1F_PSIZE, INTERP_POS  , 6, 6,
>> 0x0020 },
>> -   [TGSI_SEMANTIC_GENERIC ] = { EMIT_4F, INTERP_PERSPECTIVE, 8, 7,
>> 0x4000 }
>> +   [TGSI_SEMANTIC_TEXCOORD] = { EMIT_4F, INTERP_PERSPECTIVE, 8, 7,
>> 0x4000 },
>>   };
>> static boolean
>>   vroute_add(struct nv30_render *r, uint attrib, uint sem, uint *idx)
>>   {
>> -   struct pipe_screen *pscreen = &r->nv30->screen->base.base;
>> +   struct nv30_screen *screen = r->nv30->screen;
>>  struct nv30_fragprog *fp = r->nv30->fragprog.program;
>>  struct vertex_info *vinfo = &r->vertex_info;
>>  enum pipe_format format;
>>  uint emit = EMIT_OMIT;
>>  uint result = *idx;
>>   -   if (sem == TGSI_SEMANTIC_GENERIC && result >= 8) {
>> -  for (result = 0; result < 8; result++) {
>> - if (fp->texcoord[result] == *idx) {
>> +   if (sem == TGSI_SEMANTIC_GENERIC) {
>> +  uint num_texcoords = (screen->eng3d->oclass < NV40_3D_CLASS) ? 8 :
>> 10;
>> +  for (result = 0; result < num_texcoords; result++) {
>> + if (fp->texcoord[result] == *idx + 8) {
>
>
> maybe i'm too tired, but why exactly *idx + 8 ?

See nvfx_fragprog.c:

   fpc->fp->texcoord[hw] = fdec->Semantic.Index + 8;

when the semantic is GENERIC. (and 0xfffe when it's PCOORD). This is
because there can be up to 8 TEXCOORD's.

>
>> +sem = TGSI_SEMANTIC_TEXCOORD;
>>   emit = vroute[sem].emit;
>>   break;
>>}
>> @@ -260,11 +262,11 @@ vroute_add(struct nv30_render *r, uint attrib, uint
>> sem, uint *idx)
>>  draw_emit_vertex_attr(vinfo, emit, vroute[sem].interp, attrib);
>>  format = draw_translate_vinfo_format(emit);
>>   -   r->vtxfmt[attrib] = nv30_vtxfmt(pscreen, format)->hw;
>> +   r->vtxfmt[attrib] = nv30_vtxfmt(&screen->base.base, format)->hw;
>>  r->vtxptr[attrib] = vinfo->size | NV30_3D_VTXBUF_DMA1;
>>  vinfo->size += draw_translate_vinfo_size(emit);
>>   -   if (nv30_screen(pscreen)->eng3d->oclass < NV40_3D_CLASS) {
>> +   if (screen->eng3d->oclass < NV40_3D_CLASS) {
>> r->vtxprog[attrib][0] = 0x001f38d8;
>> r->vtxprog[attrib][1] = 0x0080001b | (attrib << 9);
>> r->vtxprog[attrib][2] = 0x0836106c;
>> @@ -276,7 +278,12 @@ vroute_add(struct nv30_render *r, uint attrib, uint
>> sem, uint *idx)
>> r->vtxprog[attrib][3] = 0x6041ff80 | (result + vroute[sem].vp40)
>> << 2;
>>  }
>>   -   *idx = vroute[sem].ow40 << result;
>> +   if (result < 8)
>> +  *idx = vroute[sem].ow40 << result;
>> +   else {
>> +  assert(sem == TGSI_SEMANTIC_TEXCOORD);
>> +  *idx = 0x1000 << (result - 8);
>> +   }
>>  return TRUE;
>>   }
>>   @@ -330,7 +337,7 @@ nv30_render_validate(struct nv30_context *nv30)
>>while (pntc && attrib < 16) {
>> uint index = ffs(pntc) - 1; pntc &= ~(1 << index);
>> -  if (vroute_add(r, attrib, TGSI_SEMANTIC_GENERIC, &index)) {
>> +  if (vroute_add(r, attrib, TGSI_SEMANTIC_TEXCOORD, &index)) {
>>vp_attribs |= (1 << attrib++);
>>vp_results |= index;
>> }
>
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 1/2] nv30/draw: rework some of the output vertex buffer logic

2015-05-25 Thread Tobias Klausmann




On 25.05.2015 21:29, Ilia Mirkin wrote:

This makes the vertex buffer go to GART, not VRAM, and redoes the
mapping to not use the UNSYNCHRONIZED access (which is meaningless on a
VRAM buffer anyways). While we're at it, add some flushes for VBO data.

Moving the vertex buffer from VRAM to GART makes glxgears work fully
with NV30_SWTNL=1. The other changes just seem like a good idea. I'm not
sure *why* moving the buffer from VRAM makes it work... perhaps
something doesn't get flushed in time? However this is a single use by
the GPU buffer, so STREAM seems like the correct usage semantic for it.


i'm not really happy moving things to gart and don't see why this 
resolves the issue but granted if it works out :-)


Reviewed-by: Tobias Klausmann 


Signed-off-by: Ilia Mirkin 
Cc: "10.5 10.6" 
---
  src/gallium/drivers/nouveau/nv30/nv30_draw.c | 30 +---
  1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv30/nv30_draw.c 
b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
index 6a0d06f..a681135 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_draw.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
@@ -71,12 +71,12 @@ nv30_render_allocate_vertices(struct vbuf_render *render,
 struct nv30_render *r = nv30_render(render);
 struct nv30_context *nv30 = r->nv30;
  
-   r->length = vertex_size * nr_vertices;

+   r->length = (uint32_t)vertex_size * (uint32_t)nr_vertices;
  
 if (r->offset + r->length >= render->max_vertex_buffer_bytes) {

pipe_resource_reference(&r->buffer, NULL);
r->buffer = pipe_buffer_create(&nv30->screen->base.base,
- PIPE_BIND_VERTEX_BUFFER, 0,
+ PIPE_BIND_VERTEX_BUFFER, 
PIPE_USAGE_STREAM,
   render->max_vertex_buffer_bytes);
if (!r->buffer)
   return FALSE;
@@ -91,10 +91,14 @@ static void *
  nv30_render_map_vertices(struct vbuf_render *render)
  {
 struct nv30_render *r = nv30_render(render);
-   char *map = pipe_buffer_map(&r->nv30->base.pipe, r->buffer,
-   PIPE_TRANSFER_WRITE |
-   PIPE_TRANSFER_UNSYNCHRONIZED, &r->transfer);
-   return map + r->offset;
+   char *map = pipe_buffer_map_range(
+ &r->nv30->base.pipe, r->buffer,
+ r->offset, r->length,
+ PIPE_TRANSFER_WRITE |
+ PIPE_TRANSFER_DISCARD_RANGE,
+ &r->transfer);
+   assert(map);
+   return map;
  }
  
  static void

@@ -127,12 +131,18 @@ nv30_render_draw_elements(struct vbuf_render *render,
 for (i = 0; i < r->vertex_info.num_attribs; i++) {
PUSH_RESRC(push, NV30_3D(VTXBUF(i)), BUFCTX_VTXTMP,
 nv04_resource(r->buffer), r->offset + r->vtxptr[i],
-   NOUVEAU_BO_LOW | NOUVEAU_BO_RD, 0, 0);
+   NOUVEAU_BO_LOW | NOUVEAU_BO_RD, 0, NV30_3D_VTXBUF_DMA1);
 }
  
 if (!nv30_state_validate(nv30, ~0, FALSE))

return;
  
+   if (nv30->base.vbo_dirty) {

+  BEGIN_NV04(push, NV30_3D(VTX_CACHE_INVALIDATE_1710), 1);
+  PUSH_DATA (push, 0);
+  nv30->base.vbo_dirty = FALSE;
+   }
+
 BEGIN_NV04(push, NV30_3D(VERTEX_BEGIN_END), 1);
 PUSH_DATA (push, r->prim);
  
@@ -178,6 +188,12 @@ nv30_render_draw_arrays(struct vbuf_render *render, unsigned start, uint nr)

 if (!nv30_state_validate(nv30, ~0, FALSE))
return;
  
+   if (nv30->base.vbo_dirty) {

+  BEGIN_NV04(push, NV30_3D(VTX_CACHE_INVALIDATE_1710), 1);
+  PUSH_DATA (push, 0);
+  nv30->base.vbo_dirty = FALSE;
+   }
+
 BEGIN_NV04(push, NV30_3D(VERTEX_BEGIN_END), 1);
 PUSH_DATA (push, r->prim);
  


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/2] nv30/draw: switch varying hookup logic to know about texcoords

2015-05-25 Thread Tobias Klausmann




On 25.05.2015 21:29, Ilia Mirkin wrote:

Commit 8acaf862dfe switched things over to use TEXCOORD instead of
GENERIC, but did not update the nv30 swtnl draw paths. This teaches the
draw logic about TEXCOORD.

Among other things, this fixes a crash in demos/arbocclude when using
swtnl. Curiously enough, the point-sprite piglit works without this.

Signed-off-by: Ilia Mirkin 
Cc: "10.5 10.6" 
---
  src/gallium/drivers/nouveau/nv30/nv30_draw.c | 25 -
  1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv30/nv30_draw.c 
b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
index a681135..03c0c70 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_draw.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
@@ -230,22 +230,24 @@ static const struct {
 [TGSI_SEMANTIC_BCOLOR  ] = { EMIT_4F, INTERP_LINEAR , 1, 3, 0x0004 
},
 [TGSI_SEMANTIC_FOG ] = { EMIT_4F, INTERP_PERSPECTIVE, 5, 5, 0x0010 
},
 [TGSI_SEMANTIC_PSIZE   ] = { EMIT_1F_PSIZE, INTERP_POS  , 6, 6, 0x0020 
},
-   [TGSI_SEMANTIC_GENERIC ] = { EMIT_4F, INTERP_PERSPECTIVE, 8, 7, 0x4000 }
+   [TGSI_SEMANTIC_TEXCOORD] = { EMIT_4F, INTERP_PERSPECTIVE, 8, 7, 0x4000 
},
  };
  
  static boolean

  vroute_add(struct nv30_render *r, uint attrib, uint sem, uint *idx)
  {
-   struct pipe_screen *pscreen = &r->nv30->screen->base.base;
+   struct nv30_screen *screen = r->nv30->screen;
 struct nv30_fragprog *fp = r->nv30->fragprog.program;
 struct vertex_info *vinfo = &r->vertex_info;
 enum pipe_format format;
 uint emit = EMIT_OMIT;
 uint result = *idx;
  
-   if (sem == TGSI_SEMANTIC_GENERIC && result >= 8) {

-  for (result = 0; result < 8; result++) {
- if (fp->texcoord[result] == *idx) {
+   if (sem == TGSI_SEMANTIC_GENERIC) {
+  uint num_texcoords = (screen->eng3d->oclass < NV40_3D_CLASS) ? 8 : 10;
+  for (result = 0; result < num_texcoords; result++) {
+ if (fp->texcoord[result] == *idx + 8) {


maybe i'm too tired, but why exactly *idx + 8 ?

+sem = TGSI_SEMANTIC_TEXCOORD;
  emit = vroute[sem].emit;
  break;
   }
@@ -260,11 +262,11 @@ vroute_add(struct nv30_render *r, uint attrib, uint sem, 
uint *idx)
 draw_emit_vertex_attr(vinfo, emit, vroute[sem].interp, attrib);
 format = draw_translate_vinfo_format(emit);
  
-   r->vtxfmt[attrib] = nv30_vtxfmt(pscreen, format)->hw;

+   r->vtxfmt[attrib] = nv30_vtxfmt(&screen->base.base, format)->hw;
 r->vtxptr[attrib] = vinfo->size | NV30_3D_VTXBUF_DMA1;
 vinfo->size += draw_translate_vinfo_size(emit);
  
-   if (nv30_screen(pscreen)->eng3d->oclass < NV40_3D_CLASS) {

+   if (screen->eng3d->oclass < NV40_3D_CLASS) {
r->vtxprog[attrib][0] = 0x001f38d8;
r->vtxprog[attrib][1] = 0x0080001b | (attrib << 9);
r->vtxprog[attrib][2] = 0x0836106c;
@@ -276,7 +278,12 @@ vroute_add(struct nv30_render *r, uint attrib, uint sem, 
uint *idx)
r->vtxprog[attrib][3] = 0x6041ff80 | (result + vroute[sem].vp40) << 2;
 }
  
-   *idx = vroute[sem].ow40 << result;

+   if (result < 8)
+  *idx = vroute[sem].ow40 << result;
+   else {
+  assert(sem == TGSI_SEMANTIC_TEXCOORD);
+  *idx = 0x1000 << (result - 8);
+   }
 return TRUE;
  }
  
@@ -330,7 +337,7 @@ nv30_render_validate(struct nv30_context *nv30)
  
 while (pntc && attrib < 16) {

uint index = ffs(pntc) - 1; pntc &= ~(1 << index);
-  if (vroute_add(r, attrib, TGSI_SEMANTIC_GENERIC, &index)) {
+  if (vroute_add(r, attrib, TGSI_SEMANTIC_TEXCOORD, &index)) {
   vp_attribs |= (1 << attrib++);
   vp_results |= index;
}


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 5/8] acpi: Check returned object type by Optimus _DSM locally

2015-05-25 Thread Ilia Mirkin

On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau  wrote:
> Most _DSM will return an integer value of 0x8002 when given an unknown
> UUID, revision ID or function ID. Checking locally allows us to differentiate
> that case from other ACPI errors, and to not report a "failed to evaluate 
> _DSM"
> if 0x8002 is returned which was confusing.
>
> Signed-off-by: Pierre Moreau 
> ---
>  drm/nouveau/nouveau_acpi.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
> index 073f7d7..7aeaf7d 100644
> --- a/drm/nouveau/nouveau_acpi.c
> +++ b/drm/nouveau/nouveau_acpi.c
> @@ -88,12 +88,12 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle 
> handle, int func, int arg, u
> for (i = 0; i < 4; i++)
> args_buff[i] = (arg >> i * 8) & 0xFF;
>
> -   obj = acpi_evaluate_dsm_typed(handle, nouveau_op_dsm_muid, 
> nouveau_op_dsm_rid,
> - func, &argv4, ACPI_TYPE_BUFFER);
> +   obj = acpi_evaluate_dsm(handle, nouveau_op_dsm_muid, 
> nouveau_op_dsm_rid,
> +   func, &argv4);
> if (!obj) {
> acpi_handle_info(handle, "failed to evaluate _DSM\n");
> return AE_ERROR;
> -   } else {
> +   } else if (obj->type == ACPI_TYPE_BUFFER) {
> if (!result && obj->buffer.length == 4) {
> *result  = obj->buffer.pointer[0];
> *result |= (obj->buffer.pointer[1] << 8);
> @@ -101,6 +101,15 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle 
> handle, int func, int arg, u
> *result |= (obj->buffer.pointer[3] << 24);
> }
> ACPI_FREE(obj);
> +   } else if (obj->type == ACPI_TYPE_INTEGER &&
> +  obj->integer.value == 0x8002) {
> +   acpi_handle_debug(handle, "failed to query Optimus _DSM\n");
> +   ACPI_FREE(obj);
> +   return -ENODEV;

should this be AE_ERROR?

> +   } else {
> +   acpi_handle_err(handle, "unexpected returned value by Optimus 
> _DSM\n");
> +   ACPI_FREE(obj);
> +   return AE_ERROR;
> }
>
> return 0;
> --
> 2.4.1
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 8/8] acpi: Use booleans when probing different _DSM types

2015-05-25 Thread Pierre Moreau

Signed-off-by: Pierre Moreau 
---
 drm/nouveau/nouveau_acpi.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index 3d6a1ea..5d63621 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -297,8 +297,8 @@ static bool nouveau_dsm_detect(void)
char acpi_method_name[255] = { 0 };
struct acpi_buffer buffer = {sizeof(acpi_method_name), 
acpi_method_name};
struct pci_dev *pdev = NULL;
-   int has_dsm = 0;
-   int has_optimus = 0;
+   bool has_mux = false;
+   bool has_optimus = false;
bool has_gmux = false;
int vga_count = 0;
bool guid_valid;
@@ -317,9 +317,9 @@ static bool nouveau_dsm_detect(void)
 
retval = nouveau_dsm_pci_probe(pdev);
if (retval & NOUVEAU_DSM_HAS_MUX)
-   has_dsm |= 1;
+   has_mux = true;
if (retval & NOUVEAU_DSM_HAS_OPT)
-   has_optimus = 1;
+   has_optimus = true;
if (retval & NOUVEAU_DSM_HAS_GMUX)
has_gmux = true;
}
@@ -329,9 +329,9 @@ static bool nouveau_dsm_detect(void)
 
retval = nouveau_dsm_pci_probe(pdev);
if (retval & NOUVEAU_DSM_HAS_MUX)
-   has_dsm |= 1;
+   has_mux = true;
if (retval & NOUVEAU_DSM_HAS_OPT)
-   has_optimus = 1;
+   has_optimus = true;
if (retval & NOUVEAU_DSM_HAS_GMUX)
has_gmux = true;
}
@@ -344,7 +344,7 @@ static bool nouveau_dsm_detect(void)
acpi_method_name);
nouveau_dsm_priv.optimus_detected = true;
ret = true;
-   } else if (vga_count == 2 && has_dsm && guid_valid) {
+   } else if (vga_count == 2 && has_mux && guid_valid) {
acpi_get_name(nouveau_dsm_priv.dhandle, ACPI_FULL_PATHNAME,
&buffer);
printk(KERN_INFO "VGA switcheroo: detected mux DSM switching 
method %s handle\n",
-- 
2.4.1

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 6/8] acpi: Improve some messages level and content

2015-05-25 Thread Pierre Moreau

Signed-off-by: Pierre Moreau 
---
 drm/nouveau/nouveau_acpi.c | 8 
 drm/nouveau/nouveau_vga.c  | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index 7aeaf7d..104d291 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -91,7 +91,7 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle handle, 
int func, int arg, u
obj = acpi_evaluate_dsm(handle, nouveau_op_dsm_muid, nouveau_op_dsm_rid,
func, &argv4);
if (!obj) {
-   acpi_handle_info(handle, "failed to evaluate _DSM\n");
+   acpi_handle_err(handle, "failed to evaluate Optimus _DSM\n");
return AE_ERROR;
} else if (obj->type == ACPI_TYPE_BUFFER) {
if (!result && obj->buffer.length == 4) {
@@ -150,7 +150,7 @@ static int nouveau_evaluate_mux_dsm(acpi_handle handle, int 
func, int arg)
obj = acpi_evaluate_dsm_typed(handle, nouveau_mux_dsm_muid, 
nouveau_mux_dsm_rid,
  func, &argv4, ACPI_TYPE_INTEGER);
if (!obj) {
-   acpi_handle_info(handle, "failed to evaluate _DSM\n");
+   acpi_handle_err(handle, "failed to evaluate mux _DSM\n");
return AE_ERROR;
} else {
if (obj->integer.value == 0x8002)
@@ -272,7 +272,7 @@ static bool nouveau_dsm_detect(void)
guid_valid = mxm_wmi_supported();
 
if (guid_valid)
-   printk("MXM: GUID detected in BIOS\n");
+   printk(KERN_INFO "MXM: GUID detected in BIOS\n");
 
/* now do DSM detection */
while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev)) != 
NULL) {
@@ -375,7 +375,7 @@ static int nouveau_rom_call(acpi_handle rom_handle, uint8_t 
*bios,
 
status = acpi_evaluate_object(rom_handle, NULL, &rom_arg, &buffer);
if (ACPI_FAILURE(status)) {
-   printk(KERN_INFO "failed to evaluate ROM got %s\n", 
acpi_format_exception(status));
+   printk(KERN_ERR "ACPI: failed to evaluate ROM got %s\n", 
acpi_format_exception(status));
return -ENODEV;
}
obj = (union acpi_object *)buffer.pointer;
diff --git a/drm/nouveau/nouveau_vga.c b/drm/nouveau/nouveau_vga.c
index 6297566..9a6328f 100644
--- a/drm/nouveau/nouveau_vga.c
+++ b/drm/nouveau/nouveau_vga.c
@@ -40,13 +40,13 @@ nouveau_switcheroo_set_state(struct pci_dev *pdev,
return;
 
if (state == VGA_SWITCHEROO_ON) {
-   printk(KERN_ERR "VGA switcheroo: switched nouveau on\n");
+   printk(KERN_INFO "VGA switcheroo: switched nouveau on\n");
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
nouveau_pmops_resume(&pdev->dev);
drm_kms_helper_poll_enable(dev);
dev->switch_power_state = DRM_SWITCH_POWER_ON;
} else {
-   printk(KERN_ERR "VGA switcheroo: switched nouveau off\n");
+   printk(KERN_INFO "VGA switcheroo: switched nouveau off\n");
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
drm_kms_helper_poll_disable(dev);
nouveau_switcheroo_optimus_dsm();
-- 
2.4.1

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 5/8] acpi: Check returned object type by Optimus _DSM locally

2015-05-25 Thread Pierre Moreau

Most _DSM will return an integer value of 0x8002 when given an unknown
UUID, revision ID or function ID. Checking locally allows us to differentiate
that case from other ACPI errors, and to not report a "failed to evaluate _DSM"
if 0x8002 is returned which was confusing.

Signed-off-by: Pierre Moreau 
---
 drm/nouveau/nouveau_acpi.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index 073f7d7..7aeaf7d 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -88,12 +88,12 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle handle, 
int func, int arg, u
for (i = 0; i < 4; i++)
args_buff[i] = (arg >> i * 8) & 0xFF;
 
-   obj = acpi_evaluate_dsm_typed(handle, nouveau_op_dsm_muid, 
nouveau_op_dsm_rid,
- func, &argv4, ACPI_TYPE_BUFFER);
+   obj = acpi_evaluate_dsm(handle, nouveau_op_dsm_muid, nouveau_op_dsm_rid,
+   func, &argv4);
if (!obj) {
acpi_handle_info(handle, "failed to evaluate _DSM\n");
return AE_ERROR;
-   } else {
+   } else if (obj->type == ACPI_TYPE_BUFFER) {
if (!result && obj->buffer.length == 4) {
*result  = obj->buffer.pointer[0];
*result |= (obj->buffer.pointer[1] << 8);
@@ -101,6 +101,15 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle 
handle, int func, int arg, u
*result |= (obj->buffer.pointer[3] << 24);
}
ACPI_FREE(obj);
+   } else if (obj->type == ACPI_TYPE_INTEGER &&
+  obj->integer.value == 0x8002) {
+   acpi_handle_debug(handle, "failed to query Optimus _DSM\n");
+   ACPI_FREE(obj);
+   return -ENODEV;
+   } else {
+   acpi_handle_err(handle, "unexpected returned value by Optimus 
_DSM\n");
+   ACPI_FREE(obj);
+   return AE_ERROR;
}
 
return 0;
-- 
2.4.1

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 3/8] acpi: Define static variables for revision ids

2015-05-25 Thread Pierre Moreau

Signed-off-by: Pierre Moreau 
---
 drm/nouveau/nouveau_acpi.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index 1f18018..36f4a40 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -61,11 +61,13 @@ bool nouveau_has_mux(void) {
 #define NOUVEAU_DSM_HAS_OPT 0x2
 
 #ifdef CONFIG_VGA_SWITCHEROO
+static const uint32_t nouveau_mux_dsm_rid = 0x0102;
 static const char nouveau_mux_dsm_muid[] = {
0xA0, 0xA0, 0x95, 0x9D, 0x60, 0x00, 0x48, 0x4D,
0xB3, 0x4D, 0x7E, 0x5F, 0xEA, 0x12, 0x9F, 0xD4,
 };
 
+static const uint32_t nouveau_op_dsm_rid = 0x0100;
 static const char nouveau_op_dsm_muid[] = {
0xF8, 0xD8, 0x86, 0xA4, 0xDA, 0x0B, 0x1B, 0x47,
0xA7, 0x2B, 0x60, 0x42, 0xA6, 0xB5, 0xBE, 0xE0,
@@ -87,7 +89,7 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle handle, 
int func, int arg, u
args_buff[i] = (arg >> i * 8) & 0xFF;
 
*result = 0;
-   obj = acpi_evaluate_dsm_typed(handle, nouveau_op_dsm_muid, 0x0100,
+   obj = acpi_evaluate_dsm_typed(handle, nouveau_op_dsm_muid, 
nouveau_op_dsm_rid,
  func, &argv4, ACPI_TYPE_BUFFER);
if (!obj) {
acpi_handle_info(handle, "failed to evaluate _DSM\n");
@@ -137,7 +139,7 @@ static int nouveau_evaluate_mux_dsm(acpi_handle handle, int 
func, int arg)
.integer.value = arg,
};
 
-   obj = acpi_evaluate_dsm_typed(handle, nouveau_mux_dsm_muid, 0x0102,
+   obj = acpi_evaluate_dsm_typed(handle, nouveau_mux_dsm_muid, 
nouveau_mux_dsm_rid,
  func, &argv4, ACPI_TYPE_INTEGER);
if (!obj) {
acpi_handle_info(handle, "failed to evaluate _DSM\n");
@@ -224,7 +226,7 @@ static int nouveau_dsm_pci_probe(struct pci_dev *pdev)
if (!acpi_has_method(dhandle, "_DSM"))
return false;
 
-   if (acpi_check_dsm(dhandle, nouveau_mux_dsm_muid, 0x0102,
+   if (acpi_check_dsm(dhandle, nouveau_mux_dsm_muid, nouveau_mux_dsm_rid,
   1 << NOUVEAU_DSM_MUX_POWER))
retval |= NOUVEAU_DSM_HAS_MUX;
 
-- 
2.4.1

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 7/8] acpi: Add support for Apple Gmux _DMS

2015-05-25 Thread Pierre Moreau

Signed-off-by: Pierre Moreau 
---
 drm/nouveau/nouveau_acpi.c | 53 --
 drm/nouveau/nouveau_acpi.h |  2 ++
 drm/nouveau/nouveau_drm.c  |  6 --
 drm/nouveau/nouveau_vga.c  | 10 +
 4 files changed, 63 insertions(+), 8 deletions(-)

diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index 104d291..3d6a1ea 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -29,6 +29,10 @@
 
 #define NOUVEAU_DSM_OPTIMUS_SET_POWERDOWN (NOUVEAU_DSM_OPTIMUS_POWERDOWN_PS3 | 
NOUVEAU_DSM_OPTIMUS_FLAGS_CHANGED)
 
+#define NOUVEAU_DSM_GMUX_V1_CAPS (3 << 6)
+
+#define NOUVEAU_DSM_GMUX_V2_CAPS (1 << 1)
+
 /* result of the optimus caps function */
 #define OPTIMUS_ENABLED (1 << 0)
 #define OPTIMUS_STATUS_MASK (3 << 3)
@@ -45,6 +49,7 @@
 static struct nouveau_dsm_priv {
bool mux_detected;
bool optimus_detected;
+   bool gmux_detected;
acpi_handle dhandle;
acpi_handle rom_handle;
 } nouveau_dsm_priv;
@@ -57,8 +62,13 @@ bool nouveau_has_mux(void) {
return nouveau_dsm_priv.mux_detected;
 }
 
+bool nouveau_has_gmux(void) {
+   return nouveau_dsm_priv.gmux_detected;
+}
+
 #define NOUVEAU_DSM_HAS_MUX 0x1
 #define NOUVEAU_DSM_HAS_OPT 0x2
+#define NOUVEAU_DSM_HAS_GMUX 0x4
 
 #ifdef CONFIG_VGA_SWITCHEROO
 static const uint32_t nouveau_mux_dsm_rid = 0x0102;
@@ -73,6 +83,18 @@ static const char nouveau_op_dsm_muid[] = {
0xA7, 0x2B, 0x60, 0x42, 0xA6, 0xB5, 0xBE, 0xE0,
 };
 
+static const uint32_t nouveau_gmux_v1_dsm_rid = 0x101;
+static const char nouveau_gmux_v1_dsm_muid[] = {
+   0xA6, 0x69, 0x86, 0x99, 0xE9, 0x8B, 0xFB, 0x49,
+   0xBD, 0xDB, 0x51, 0xA1, 0xEF, 0xE1, 0x9C, 0x3D,
+};
+
+static const uint32_t nouveau_gmux_v2_dsm_rid = 0x001;
+static const char nouveau_gmux_v2_dsm_muid[] = {
+   0xC6, 0xB7, 0xB5, 0xA0, 0x18, 0x13, 0x1C, 0x44,
+   0xB0, 0xC9, 0xFE, 0x69, 0x5E, 0xAF, 0x94, 0x9B,
+};
+
 static int nouveau_evaluate_optimus_dsm(acpi_handle handle, int func, int arg, 
uint32_t *result)
 {
int i;
@@ -161,6 +183,17 @@ static int nouveau_evaluate_mux_dsm(acpi_handle handle, 
int func, int arg)
return ret;
 }
 
+static int nouveau_check_gmux_dsm(acpi_handle handle)
+{
+   bool has_v1 = acpi_check_dsm(handle, nouveau_gmux_v1_dsm_muid,
+nouveau_gmux_v1_dsm_rid,
+NOUVEAU_DSM_GMUX_V1_CAPS);
+   bool has_v2 = acpi_check_dsm(handle, nouveau_gmux_v2_dsm_muid,
+nouveau_gmux_v2_dsm_rid,
+NOUVEAU_DSM_GMUX_V2_CAPS);
+   return has_v1 || has_v2;
+}
+
 static int nouveau_dsm_switch_mux(acpi_handle handle, int mux_id)
 {
mxm_wmi_call_mxmx(mux_id == NOUVEAU_DSM_MUX_LED_STAMINA ? 
MXM_MXDS_ADAPTER_IGD : MXM_MXDS_ADAPTER_0);
@@ -238,6 +271,9 @@ static int nouveau_dsm_pci_probe(struct pci_dev *pdev)
   1 << NOUVEAU_DSM_MUX_POWER))
retval |= NOUVEAU_DSM_HAS_MUX;
 
+   if (nouveau_check_gmux_dsm(dhandle))
+   retval |= NOUVEAU_DSM_HAS_GMUX;
+
if (nouveau_check_optimus_dsm(dhandle))
retval |= NOUVEAU_DSM_HAS_OPT;
 
@@ -263,6 +299,7 @@ static bool nouveau_dsm_detect(void)
struct pci_dev *pdev = NULL;
int has_dsm = 0;
int has_optimus = 0;
+   bool has_gmux = false;
int vga_count = 0;
bool guid_valid;
int retval;
@@ -283,6 +320,8 @@ static bool nouveau_dsm_detect(void)
has_dsm |= 1;
if (retval & NOUVEAU_DSM_HAS_OPT)
has_optimus = 1;
+   if (retval & NOUVEAU_DSM_HAS_GMUX)
+   has_gmux = true;
}
 
while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_3D << 8, pdev)) != NULL) 
{
@@ -293,9 +332,11 @@ static bool nouveau_dsm_detect(void)
has_dsm |= 1;
if (retval & NOUVEAU_DSM_HAS_OPT)
has_optimus = 1;
+   if (retval & NOUVEAU_DSM_HAS_GMUX)
+   has_gmux = true;
}
 
-   /* find the optimus DSM or the mux DSM */
+   /* find the optimus DSM, the mux DSM or the gmux DSM */
if (has_optimus == 1) {
acpi_get_name(nouveau_dsm_priv.dhandle, ACPI_FULL_PATHNAME,
&buffer);
@@ -310,6 +351,13 @@ static bool nouveau_dsm_detect(void)
acpi_method_name);
nouveau_dsm_priv.mux_detected = true;
ret = true;
+   } else if (has_gmux) {
+   acpi_get_name(nouveau_dsm_priv.dhandle, ACPI_FULL_PATHNAME,
+   &buffer);
+   printk(KERN_INFO "VGA switcheroo: detected gmux DSM switching 
method %s handle\n",
+   acpi_method_name);
+   nouveau_dsm_priv.gmux_detected = true;
+   ret = true;
}
 
 
@@ -321,7 +369,8

[Nouveau] [PATCH 4/8] acpi: Allow evaluate_optimus_dsm to take NULL results

2015-05-25 Thread Pierre Moreau

Signed-off-by: Pierre Moreau 
---
 drm/nouveau/nouveau_acpi.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index 36f4a40..073f7d7 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -88,15 +88,14 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle handle, 
int func, int arg, u
for (i = 0; i < 4; i++)
args_buff[i] = (arg >> i * 8) & 0xFF;
 
-   *result = 0;
obj = acpi_evaluate_dsm_typed(handle, nouveau_op_dsm_muid, 
nouveau_op_dsm_rid,
  func, &argv4, ACPI_TYPE_BUFFER);
if (!obj) {
acpi_handle_info(handle, "failed to evaluate _DSM\n");
return AE_ERROR;
} else {
-   if (obj->buffer.length == 4) {
-   *result |= obj->buffer.pointer[0];
+   if (!result && obj->buffer.length == 4) {
+   *result  = obj->buffer.pointer[0];
*result |= (obj->buffer.pointer[1] << 8);
*result |= (obj->buffer.pointer[2] << 16);
*result |= (obj->buffer.pointer[3] << 24);
@@ -322,18 +321,17 @@ void nouveau_register_dsm_handler(void)
 /* Must be called for Optimus models before the card can be turned off */
 void nouveau_switcheroo_optimus_dsm(void)
 {
-   u32 result = 0;
if (!nouveau_dsm_priv.optimus_detected)
return;
 
nouveau_evaluate_optimus_dsm(nouveau_dsm_priv.dhandle,
 NOUVEAU_DSM_OPTIMUS_FLAGS,
-0x3, &result);
+0x3, NULL);
 
nouveau_evaluate_optimus_dsm(nouveau_dsm_priv.dhandle,
 NOUVEAU_DSM_OPTIMUS_CAPS,
 NOUVEAU_DSM_OPTIMUS_SET_POWERDOWN,
-&result);
+NULL);
 
 }
 
-- 
2.4.1

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 2/8] acpi: Add evaluate to functons evaluating _DSM

2015-05-25 Thread Pierre Moreau

This makes it clearer when reading the function name, as well as following the
names of the related ACPI function.

Signed-off-by: Pierre Moreau 
---
 drm/nouveau/nouveau_acpi.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index 4a48e21..1f18018 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -71,7 +71,7 @@ static const char nouveau_op_dsm_muid[] = {
0xA7, 0x2B, 0x60, 0x42, 0xA6, 0xB5, 0xBE, 0xE0,
 };
 
-static int nouveau_optimus_dsm(acpi_handle handle, int func, int arg, uint32_t 
*result)
+static int nouveau_evaluate_optimus_dsm(acpi_handle handle, int func, int arg, 
uint32_t *result)
 {
int i;
union acpi_object *obj;
@@ -118,7 +118,7 @@ static int nouveau_check_optimus_dsm(acpi_handle handle)
 * Function 0 returns a Buffer containing available functions.
 * The args parameter is ignored for function 0, so just put 0 in it
 */
-   if (nouveau_optimus_dsm(handle, 0, 0, &result))
+   if (nouveau_evaluate_optimus_dsm(handle, 0, 0, &result))
return 0;
 
/*
@@ -128,7 +128,7 @@ static int nouveau_check_optimus_dsm(acpi_handle handle)
return result & 1 && result & (1 << NOUVEAU_DSM_OPTIMUS_CAPS);
 }
 
-static int nouveau_mux_dsm(acpi_handle handle, int func, int arg)
+static int nouveau_evaluate_mux_dsm(acpi_handle handle, int func, int arg)
 {
int ret = 0;
union acpi_object *obj;
@@ -155,7 +155,7 @@ static int nouveau_dsm_switch_mux(acpi_handle handle, int 
mux_id)
 {
mxm_wmi_call_mxmx(mux_id == NOUVEAU_DSM_MUX_LED_STAMINA ? 
MXM_MXDS_ADAPTER_IGD : MXM_MXDS_ADAPTER_0);
mxm_wmi_call_mxds(mux_id == NOUVEAU_DSM_MUX_LED_STAMINA ? 
MXM_MXDS_ADAPTER_IGD : MXM_MXDS_ADAPTER_0);
-   return nouveau_mux_dsm(handle, NOUVEAU_DSM_MUX_LED, mux_id);
+   return nouveau_evaluate_mux_dsm(handle, NOUVEAU_DSM_MUX_LED, mux_id);
 }
 
 static int nouveau_dsm_set_discrete_state(acpi_handle handle, enum 
vga_switcheroo_state state)
@@ -165,7 +165,7 @@ static int nouveau_dsm_set_discrete_state(acpi_handle 
handle, enum vga_switchero
arg = NOUVEAU_DSM_MUX_POWER_SPEED;
else
arg = NOUVEAU_DSM_MUX_POWER_STAMINA;
-   nouveau_mux_dsm(handle, NOUVEAU_DSM_MUX_POWER, arg);
+   nouveau_evaluate_mux_dsm(handle, NOUVEAU_DSM_MUX_POWER, arg);
return 0;
 }
 
@@ -233,8 +233,8 @@ static int nouveau_dsm_pci_probe(struct pci_dev *pdev)
 
if (retval & NOUVEAU_DSM_HAS_OPT) {
uint32_t result;
-   nouveau_optimus_dsm(dhandle, NOUVEAU_DSM_OPTIMUS_CAPS, 0,
-   &result);
+   nouveau_evaluate_optimus_dsm(dhandle, NOUVEAU_DSM_OPTIMUS_CAPS,
+0, &result);
dev_info(&pdev->dev, "optimus capabilities: %s, status %s%s\n",
 (result & OPTIMUS_ENABLED) ? "enabled" : "disabled",
 (result & OPTIMUS_DYNAMIC_PWR_CAP) ? "dynamic power, " 
: "",
@@ -324,11 +324,14 @@ void nouveau_switcheroo_optimus_dsm(void)
if (!nouveau_dsm_priv.optimus_detected)
return;
 
-   nouveau_optimus_dsm(nouveau_dsm_priv.dhandle, NOUVEAU_DSM_OPTIMUS_FLAGS,
-   0x3, &result);
+   nouveau_evaluate_optimus_dsm(nouveau_dsm_priv.dhandle,
+NOUVEAU_DSM_OPTIMUS_FLAGS,
+0x3, &result);
 
-   nouveau_optimus_dsm(nouveau_dsm_priv.dhandle, NOUVEAU_DSM_OPTIMUS_CAPS,
-   NOUVEAU_DSM_OPTIMUS_SET_POWERDOWN, &result);
+   nouveau_evaluate_optimus_dsm(nouveau_dsm_priv.dhandle,
+NOUVEAU_DSM_OPTIMUS_CAPS,
+NOUVEAU_DSM_OPTIMUS_SET_POWERDOWN,
+&result);
 
 }
 
-- 
2.4.1

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 1/8] acpi: Rename v1 DSM to mux to avoid ambiguity

2015-05-25 Thread Pierre Moreau

This is especially true when variables or functions are just called dsm without
precising the v1.

Signed-off-by: Pierre Moreau 
---
 drm/nouveau/nouveau_acpi.c | 64 +++---
 drm/nouveau/nouveau_acpi.h |  4 +--
 drm/nouveau/nouveau_drm.c  |  4 +--
 drm/nouveau/nouveau_vga.c  | 10 
 4 files changed, 41 insertions(+), 41 deletions(-)

diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index 6224246..4a48e21 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -9,16 +9,16 @@
 #include "nouveau_drm.h"
 #include "nouveau_acpi.h"
 
-#define NOUVEAU_DSM_LED 0x02
-#define NOUVEAU_DSM_LED_STATE 0x00
-#define NOUVEAU_DSM_LED_OFF 0x10
-#define NOUVEAU_DSM_LED_STAMINA 0x11
-#define NOUVEAU_DSM_LED_SPEED 0x12
+#define NOUVEAU_DSM_MUX_LED 0x02
+#define NOUVEAU_DSM_MUX_LED_STATE 0x00
+#define NOUVEAU_DSM_MUX_LED_OFF 0x10
+#define NOUVEAU_DSM_MUX_LED_STAMINA 0x11
+#define NOUVEAU_DSM_MUX_LED_SPEED 0x12
 
-#define NOUVEAU_DSM_POWER 0x03
-#define NOUVEAU_DSM_POWER_STATE 0x00
-#define NOUVEAU_DSM_POWER_SPEED 0x01
-#define NOUVEAU_DSM_POWER_STAMINA 0x02
+#define NOUVEAU_DSM_MUX_POWER 0x03
+#define NOUVEAU_DSM_MUX_POWER_STATE 0x00
+#define NOUVEAU_DSM_MUX_POWER_SPEED 0x01
+#define NOUVEAU_DSM_MUX_POWER_STAMINA 0x02
 
 #define NOUVEAU_DSM_OPTIMUS_CAPS 0x1A
 #define NOUVEAU_DSM_OPTIMUS_FLAGS 0x1B
@@ -43,7 +43,7 @@
 #define OPTIMUS_HDA_CODEC_MASK (2 << 27) /* hda bios control */
 
 static struct nouveau_dsm_priv {
-   bool dsm_detected;
+   bool mux_detected;
bool optimus_detected;
acpi_handle dhandle;
acpi_handle rom_handle;
@@ -53,15 +53,15 @@ bool nouveau_is_optimus(void) {
return nouveau_dsm_priv.optimus_detected;
 }
 
-bool nouveau_is_v1_dsm(void) {
-   return nouveau_dsm_priv.dsm_detected;
+bool nouveau_has_mux(void) {
+   return nouveau_dsm_priv.mux_detected;
 }
 
 #define NOUVEAU_DSM_HAS_MUX 0x1
 #define NOUVEAU_DSM_HAS_OPT 0x2
 
 #ifdef CONFIG_VGA_SWITCHEROO
-static const char nouveau_dsm_muid[] = {
+static const char nouveau_mux_dsm_muid[] = {
0xA0, 0xA0, 0x95, 0x9D, 0x60, 0x00, 0x48, 0x4D,
0xB3, 0x4D, 0x7E, 0x5F, 0xEA, 0x12, 0x9F, 0xD4,
 };
@@ -128,7 +128,7 @@ static int nouveau_check_optimus_dsm(acpi_handle handle)
return result & 1 && result & (1 << NOUVEAU_DSM_OPTIMUS_CAPS);
 }
 
-static int nouveau_dsm(acpi_handle handle, int func, int arg)
+static int nouveau_mux_dsm(acpi_handle handle, int func, int arg)
 {
int ret = 0;
union acpi_object *obj;
@@ -137,7 +137,7 @@ static int nouveau_dsm(acpi_handle handle, int func, int 
arg)
.integer.value = arg,
};
 
-   obj = acpi_evaluate_dsm_typed(handle, nouveau_dsm_muid, 0x0102,
+   obj = acpi_evaluate_dsm_typed(handle, nouveau_mux_dsm_muid, 0x0102,
  func, &argv4, ACPI_TYPE_INTEGER);
if (!obj) {
acpi_handle_info(handle, "failed to evaluate _DSM\n");
@@ -153,30 +153,30 @@ static int nouveau_dsm(acpi_handle handle, int func, int 
arg)
 
 static int nouveau_dsm_switch_mux(acpi_handle handle, int mux_id)
 {
-   mxm_wmi_call_mxmx(mux_id == NOUVEAU_DSM_LED_STAMINA ? 
MXM_MXDS_ADAPTER_IGD : MXM_MXDS_ADAPTER_0);
-   mxm_wmi_call_mxds(mux_id == NOUVEAU_DSM_LED_STAMINA ? 
MXM_MXDS_ADAPTER_IGD : MXM_MXDS_ADAPTER_0);
-   return nouveau_dsm(handle, NOUVEAU_DSM_LED, mux_id);
+   mxm_wmi_call_mxmx(mux_id == NOUVEAU_DSM_MUX_LED_STAMINA ? 
MXM_MXDS_ADAPTER_IGD : MXM_MXDS_ADAPTER_0);
+   mxm_wmi_call_mxds(mux_id == NOUVEAU_DSM_MUX_LED_STAMINA ? 
MXM_MXDS_ADAPTER_IGD : MXM_MXDS_ADAPTER_0);
+   return nouveau_mux_dsm(handle, NOUVEAU_DSM_MUX_LED, mux_id);
 }
 
 static int nouveau_dsm_set_discrete_state(acpi_handle handle, enum 
vga_switcheroo_state state)
 {
int arg;
if (state == VGA_SWITCHEROO_ON)
-   arg = NOUVEAU_DSM_POWER_SPEED;
+   arg = NOUVEAU_DSM_MUX_POWER_SPEED;
else
-   arg = NOUVEAU_DSM_POWER_STAMINA;
-   nouveau_dsm(handle, NOUVEAU_DSM_POWER, arg);
+   arg = NOUVEAU_DSM_MUX_POWER_STAMINA;
+   nouveau_mux_dsm(handle, NOUVEAU_DSM_MUX_POWER, arg);
return 0;
 }
 
 static int nouveau_dsm_switchto(enum vga_switcheroo_client_id id)
 {
-   if (!nouveau_dsm_priv.dsm_detected)
+   if (!nouveau_dsm_priv.mux_detected)
return 0;
if (id == VGA_SWITCHEROO_IGD)
-   return nouveau_dsm_switch_mux(nouveau_dsm_priv.dhandle, 
NOUVEAU_DSM_LED_STAMINA);
+   return nouveau_dsm_switch_mux(nouveau_dsm_priv.dhandle, 
NOUVEAU_DSM_MUX_LED_STAMINA);
else
-   return nouveau_dsm_switch_mux(nouveau_dsm_priv.dhandle, 
NOUVEAU_DSM_LED_SPEED);
+   return nouveau_dsm_switch_mux(nouveau_dsm_priv.dhandle, 
NOUVEAU_DSM_MUX_LED_SPEED);
 }
 
 static int nouveau_dsm_power_state(enum vga_switcheroo_client_id id,
@@ -187,7 +187,7 @@ static int nouveau_dsm_pow

[Nouveau] [Bug 90632] [NVE6] grctx template channel unload timeout

2015-05-25 Thread bugzilla-daemon

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

--- Comment #3 from Willem Mulder <14mrh4x0r+f...@gmail.com> ---
mmiotrace sent to mmio.du...@gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 90632] [NVE6] grctx template channel unload timeout

2015-05-25 Thread bugzilla-daemon

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

Ilia Mirkin  changed:

   What|Removed |Added

Summary|DRI_PRIME=1 has no effect   |[NVE6] grctx template
   |with GK106M |channel unload timeout

--- Comment #2 from Ilia Mirkin  ---
The issue here is with the bringup... the driver doesn't load, which means X
doesn't see it, etc.

[   15.063868] nouveau E[PBUS][:01:00.0] MMIO write of 0x0004 FAULT
at 0x620018 [ IBUS ]
[   15.149993] nouveau E[PBUS][:01:00.0] MMIO read of 0x FAULT
at 0x500c30 [ IBUS ]

Not sure if those are (semi-)expected.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 90632] DRI_PRIME=1 has no effect with GK106M

2015-05-25 Thread bugzilla-daemon

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

--- Comment #1 from Willem Mulder <14mrh4x0r+f...@gmail.com> ---
Created attachment 116034
  --> https://bugs.freedesktop.org/attachment.cgi?id=116034&action=edit
dmesg output

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 90632] New: DRI_PRIME=1 has no effect with GK106M

2015-05-25 Thread bugzilla-daemon

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

Bug ID: 90632
   Summary: DRI_PRIME=1 has no effect with GK106M
   Product: xorg
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: 14mrh4x0r+f...@gmail.com
QA Contact: xorg-t...@lists.x.org

Created attachment 116033
  --> https://bugs.freedesktop.org/attachment.cgi?id=116033&action=edit
Xorg.0.log

When running xrandr --listproviders, both nouveau and Intel are listed.
However, after using xrandr --setprovideroffloadsink nouveau Intel, running
DRI_PRIME=1 glxinfo | fgrep "OpenGL vendor" still shows Intel.

dmesg includes the following line:
[   21.537016] nouveau E[ PGR][:01:00.0] grctx template channel unload
timeout

Attached are Xorg.0.log, dmesg, and an mmiotrace of glxinfo running through
bumblebee.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 90567] Display freeze when starting League of Legends (Wine)

2015-05-25 Thread bugzilla-daemon

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

--- Comment #13 from Detlev Casanova  ---
I'll get that in place tomorrow.

Note that the first bug could have been reported using 2.4.60, I upgrade
packages almost everyday.

For the rest, this is out of my comprehension scope :) I'll do my best to give
you all you need :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 90567] Display freeze when starting League of Legends (Wine)

2015-05-25 Thread bugzilla-daemon

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

--- Comment #12 from Ilia Mirkin  ---
OK, well this is phenomenally bad then:

nouveau E[League of Legen[1565]] Unknown handle 0x0017
nouveau E[League of Legen[1565]] validate_init
nouveau E[League of Legen[1565]] validate: -2

And in your earlier logs:

nouveau E[League of Legen[2046]] Unknown handle 0x020e
nouveau E[League of Legen[2046]] validate_init
nouveau E[League of Legen[2046]] validate: -2
nouveau E[League of Legen[2046]] multiple instances of buffer 3 on validation
list
nouveau E[League of Legen[2046]] validate_init
nouveau E[League of Legen[2046]] validate: -22

I guess the earlier log may have happened with 2.4.60 -- that one would trigger
the "multiple instances" error. Unknown handle is really really bad though.

Ben (or anyone)? I don't see how this can happen... Are we not holding on to
some buffer that we should be? Should pushbuf_refn take a ref on the bo?

Detlev, could you create an apitrace that reproduces the issue? I think that
could ease debugging. (https://github.com/apitrace/apitrace)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 90567] Display freeze when starting League of Legends (Wine)

2015-05-25 Thread bugzilla-daemon

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

--- Comment #11 from Detlev Casanova  ---
No, this is libdrm 2.4.61, the latest version in archlinux.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 90567] Display freeze when starting League of Legends (Wine)

2015-05-25 Thread bugzilla-daemon

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

--- Comment #10 from Ilia Mirkin  ---
Are you using libdrm 2.4.60? If so, don't. Either use 2.4.59 or 2.4.61.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 90567] Display freeze when starting League of Legends (Wine)

2015-05-25 Thread bugzilla-daemon

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

--- Comment #9 from Detlev Casanova  ---
Created attachment 116032
  --> https://bugs.freedesktop.org/attachment.cgi?id=116032&action=edit
begining of errors with mesa git and nvc0 shader validation patch

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 90567] Display freeze when starting League of Legends (Wine)

2015-05-25 Thread bugzilla-daemon

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

--- Comment #8 from Detlev Casanova  ---
Unfortunately, the patch did not fix the problem. Though now, I can Alt-Tab to
switch to other windows and even kill the app with Ctrl-Alt-Esc.

I attach the log for the start of the game.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 1/2] nv30/draw: rework some of the output vertex buffer logic

2015-05-25 Thread Ilia Mirkin

This makes the vertex buffer go to GART, not VRAM, and redoes the
mapping to not use the UNSYNCHRONIZED access (which is meaningless on a
VRAM buffer anyways). While we're at it, add some flushes for VBO data.

Moving the vertex buffer from VRAM to GART makes glxgears work fully
with NV30_SWTNL=1. The other changes just seem like a good idea. I'm not
sure *why* moving the buffer from VRAM makes it work... perhaps
something doesn't get flushed in time? However this is a single use by
the GPU buffer, so STREAM seems like the correct usage semantic for it.

Signed-off-by: Ilia Mirkin 
Cc: "10.5 10.6" 
---
 src/gallium/drivers/nouveau/nv30/nv30_draw.c | 30 +---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv30/nv30_draw.c 
b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
index 6a0d06f..a681135 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_draw.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
@@ -71,12 +71,12 @@ nv30_render_allocate_vertices(struct vbuf_render *render,
struct nv30_render *r = nv30_render(render);
struct nv30_context *nv30 = r->nv30;
 
-   r->length = vertex_size * nr_vertices;
+   r->length = (uint32_t)vertex_size * (uint32_t)nr_vertices;
 
if (r->offset + r->length >= render->max_vertex_buffer_bytes) {
   pipe_resource_reference(&r->buffer, NULL);
   r->buffer = pipe_buffer_create(&nv30->screen->base.base,
- PIPE_BIND_VERTEX_BUFFER, 0,
+ PIPE_BIND_VERTEX_BUFFER, 
PIPE_USAGE_STREAM,
  render->max_vertex_buffer_bytes);
   if (!r->buffer)
  return FALSE;
@@ -91,10 +91,14 @@ static void *
 nv30_render_map_vertices(struct vbuf_render *render)
 {
struct nv30_render *r = nv30_render(render);
-   char *map = pipe_buffer_map(&r->nv30->base.pipe, r->buffer,
-   PIPE_TRANSFER_WRITE |
-   PIPE_TRANSFER_UNSYNCHRONIZED, &r->transfer);
-   return map + r->offset;
+   char *map = pipe_buffer_map_range(
+ &r->nv30->base.pipe, r->buffer,
+ r->offset, r->length,
+ PIPE_TRANSFER_WRITE |
+ PIPE_TRANSFER_DISCARD_RANGE,
+ &r->transfer);
+   assert(map);
+   return map;
 }
 
 static void
@@ -127,12 +131,18 @@ nv30_render_draw_elements(struct vbuf_render *render,
for (i = 0; i < r->vertex_info.num_attribs; i++) {
   PUSH_RESRC(push, NV30_3D(VTXBUF(i)), BUFCTX_VTXTMP,
nv04_resource(r->buffer), r->offset + r->vtxptr[i],
-   NOUVEAU_BO_LOW | NOUVEAU_BO_RD, 0, 0);
+   NOUVEAU_BO_LOW | NOUVEAU_BO_RD, 0, NV30_3D_VTXBUF_DMA1);
}
 
if (!nv30_state_validate(nv30, ~0, FALSE))
   return;
 
+   if (nv30->base.vbo_dirty) {
+  BEGIN_NV04(push, NV30_3D(VTX_CACHE_INVALIDATE_1710), 1);
+  PUSH_DATA (push, 0);
+  nv30->base.vbo_dirty = FALSE;
+   }
+
BEGIN_NV04(push, NV30_3D(VERTEX_BEGIN_END), 1);
PUSH_DATA (push, r->prim);
 
@@ -178,6 +188,12 @@ nv30_render_draw_arrays(struct vbuf_render *render, 
unsigned start, uint nr)
if (!nv30_state_validate(nv30, ~0, FALSE))
   return;
 
+   if (nv30->base.vbo_dirty) {
+  BEGIN_NV04(push, NV30_3D(VTX_CACHE_INVALIDATE_1710), 1);
+  PUSH_DATA (push, 0);
+  nv30->base.vbo_dirty = FALSE;
+   }
+
BEGIN_NV04(push, NV30_3D(VERTEX_BEGIN_END), 1);
PUSH_DATA (push, r->prim);
 
-- 
2.3.6

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 2/2] nv30/draw: switch varying hookup logic to know about texcoords

2015-05-25 Thread Ilia Mirkin

Commit 8acaf862dfe switched things over to use TEXCOORD instead of
GENERIC, but did not update the nv30 swtnl draw paths. This teaches the
draw logic about TEXCOORD.

Among other things, this fixes a crash in demos/arbocclude when using
swtnl. Curiously enough, the point-sprite piglit works without this.

Signed-off-by: Ilia Mirkin 
Cc: "10.5 10.6" 
---
 src/gallium/drivers/nouveau/nv30/nv30_draw.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv30/nv30_draw.c 
b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
index a681135..03c0c70 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_draw.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_draw.c
@@ -230,22 +230,24 @@ static const struct {
[TGSI_SEMANTIC_BCOLOR  ] = { EMIT_4F, INTERP_LINEAR , 1, 3, 0x0004 
},
[TGSI_SEMANTIC_FOG ] = { EMIT_4F, INTERP_PERSPECTIVE, 5, 5, 0x0010 
},
[TGSI_SEMANTIC_PSIZE   ] = { EMIT_1F_PSIZE, INTERP_POS  , 6, 6, 0x0020 
},
-   [TGSI_SEMANTIC_GENERIC ] = { EMIT_4F, INTERP_PERSPECTIVE, 8, 7, 0x4000 }
+   [TGSI_SEMANTIC_TEXCOORD] = { EMIT_4F, INTERP_PERSPECTIVE, 8, 7, 0x4000 
},
 };
 
 static boolean
 vroute_add(struct nv30_render *r, uint attrib, uint sem, uint *idx)
 {
-   struct pipe_screen *pscreen = &r->nv30->screen->base.base;
+   struct nv30_screen *screen = r->nv30->screen;
struct nv30_fragprog *fp = r->nv30->fragprog.program;
struct vertex_info *vinfo = &r->vertex_info;
enum pipe_format format;
uint emit = EMIT_OMIT;
uint result = *idx;
 
-   if (sem == TGSI_SEMANTIC_GENERIC && result >= 8) {
-  for (result = 0; result < 8; result++) {
- if (fp->texcoord[result] == *idx) {
+   if (sem == TGSI_SEMANTIC_GENERIC) {
+  uint num_texcoords = (screen->eng3d->oclass < NV40_3D_CLASS) ? 8 : 10;
+  for (result = 0; result < num_texcoords; result++) {
+ if (fp->texcoord[result] == *idx + 8) {
+sem = TGSI_SEMANTIC_TEXCOORD;
 emit = vroute[sem].emit;
 break;
  }
@@ -260,11 +262,11 @@ vroute_add(struct nv30_render *r, uint attrib, uint sem, 
uint *idx)
draw_emit_vertex_attr(vinfo, emit, vroute[sem].interp, attrib);
format = draw_translate_vinfo_format(emit);
 
-   r->vtxfmt[attrib] = nv30_vtxfmt(pscreen, format)->hw;
+   r->vtxfmt[attrib] = nv30_vtxfmt(&screen->base.base, format)->hw;
r->vtxptr[attrib] = vinfo->size | NV30_3D_VTXBUF_DMA1;
vinfo->size += draw_translate_vinfo_size(emit);
 
-   if (nv30_screen(pscreen)->eng3d->oclass < NV40_3D_CLASS) {
+   if (screen->eng3d->oclass < NV40_3D_CLASS) {
   r->vtxprog[attrib][0] = 0x001f38d8;
   r->vtxprog[attrib][1] = 0x0080001b | (attrib << 9);
   r->vtxprog[attrib][2] = 0x0836106c;
@@ -276,7 +278,12 @@ vroute_add(struct nv30_render *r, uint attrib, uint sem, 
uint *idx)
   r->vtxprog[attrib][3] = 0x6041ff80 | (result + vroute[sem].vp40) << 2;
}
 
-   *idx = vroute[sem].ow40 << result;
+   if (result < 8)
+  *idx = vroute[sem].ow40 << result;
+   else {
+  assert(sem == TGSI_SEMANTIC_TEXCOORD);
+  *idx = 0x1000 << (result - 8);
+   }
return TRUE;
 }
 
@@ -330,7 +337,7 @@ nv30_render_validate(struct nv30_context *nv30)
 
while (pntc && attrib < 16) {
   uint index = ffs(pntc) - 1; pntc &= ~(1 << index);
-  if (vroute_add(r, attrib, TGSI_SEMANTIC_GENERIC, &index)) {
+  if (vroute_add(r, attrib, TGSI_SEMANTIC_TEXCOORD, &index)) {
  vp_attribs |= (1 << attrib++);
  vp_results |= index;
   }
-- 
2.3.6

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 90567] Display freeze when starting League of Legends (Wine)

2015-05-25 Thread bugzilla-daemon

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

--- Comment #7 from Detlev Casanova  ---
Mesa git won't solve the issue. I'm trying the patch as soon as possible :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [Mesa-dev] [PATCH 09/11] gallium: add support for arb_cull_distance

2015-05-25 Thread Tobias Klausmann




On 25.05.2015 20:36, Roland Scheidegger wrote:

This doesn't really do what the commit message claims - it just adds a
cap bit, not actual support for arb_cull_distance (which was already
there), so the log should be changed accordingly.


Yep, you are completely right here, will change it to better represent 
what was done here.



Apart from what was already mentioned (that is, the cap bit isn't used
by st/mesa which instead mistakenly uses glsl13),


will change it for v2


  it would be nice if
you could test softpipe/llvmpipe with this enabled, as it should already
work (at least for llvmpipe, I'm not entirely sure for softpipe) if not
there's some unaccounted difference somewhere how we'd thought of how
this should work for dx10 vs. opengl).


Hey nice to know llvmpipe already supports this, i'll test it!

Tobias



Roland


Am 24.05.2015 um 19:58 schrieb Tobias Klausmann:

Add another pipe cap so we can savely enable of disable this extension

Signed-off-by: Tobias Klausmann 
---
  src/gallium/auxiliary/cso_cache/cso_context.c| 3 +++
  src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
  src/gallium/drivers/i915/i915_screen.c   | 1 +
  src/gallium/drivers/ilo/ilo_screen.c | 1 +
  src/gallium/drivers/llvmpipe/lp_screen.c | 2 ++
  src/gallium/drivers/nouveau/nv30/nv30_screen.c   | 1 +
  src/gallium/drivers/nouveau/nv50/nv50_screen.c   | 1 +
  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   | 1 +
  src/gallium/drivers/r300/r300_screen.c   | 1 +
  src/gallium/drivers/r600/r600_pipe.c | 1 +
  src/gallium/drivers/radeonsi/si_pipe.c   | 1 +
  src/gallium/drivers/softpipe/sp_screen.c | 2 ++
  src/gallium/drivers/svga/svga_screen.c   | 1 +
  src/gallium/drivers/vc4/vc4_screen.c | 1 +
  src/gallium/include/pipe/p_defines.h | 1 +
  15 files changed, 19 insertions(+)

diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
b/src/gallium/auxiliary/cso_cache/cso_context.c
index 744b00c..7612b43 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -119,6 +119,9 @@ struct cso_context {
 struct pipe_clip_state clip;
 struct pipe_clip_state clip_saved;
  
+   struct pipe_clip_state cull;

+   struct pipe_clip_state cull_saved;
+
 struct pipe_framebuffer_state fb, fb_saved;
 struct pipe_viewport_state vp, vp_saved;
 struct pipe_blend_color blend_color;
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
b/src/gallium/drivers/freedreno/freedreno_screen.c
index c596d03..986a942 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -221,6 +221,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
+   case PIPE_CAP_CULL_DISTANCE:
return 0;
  
  	case PIPE_CAP_MAX_VIEWPORTS:

diff --git a/src/gallium/drivers/i915/i915_screen.c 
b/src/gallium/drivers/i915/i915_screen.c
index 03fecd1..678347d 100644
--- a/src/gallium/drivers/i915/i915_screen.c
+++ b/src/gallium/drivers/i915/i915_screen.c
@@ -242,6 +242,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap 
cap)
 case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
 case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
 case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
+   case PIPE_CAP_CULL_DISTANCE:
return 0;
  
 case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:

diff --git a/src/gallium/drivers/ilo/ilo_screen.c 
b/src/gallium/drivers/ilo/ilo_screen.c
index b0fed73..f92d5de 100644
--- a/src/gallium/drivers/ilo/ilo_screen.c
+++ b/src/gallium/drivers/ilo/ilo_screen.c
@@ -459,6 +459,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
 case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
 case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
 case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
+   case PIPE_CAP_CULL_DISTANCE:
return 0;
  
 case PIPE_CAP_VENDOR_ID:

diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c 
b/src/gallium/drivers/llvmpipe/lp_screen.c
index 09ac9af..c90c405 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -293,6 +293,8 @@ llvmpipe_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
 case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
 case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
return 0;
+   case PIPE_CAP_CULL_DISTANCE:
+  return 0;
 }
 /* should only get here on unhandled cases */
 debug_printf("Unexpected PIPE_CAP %d query\n", param);
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c 
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index bb79ccc..fc33ddf 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -162,6 +162,7 @@ nv30_screen_get_param(struct pipe_scr

Re: [Nouveau] [Mesa-dev] [PATCH 09/11] gallium: add support for arb_cull_distance

2015-05-25 Thread Roland Scheidegger

This doesn't really do what the commit message claims - it just adds a
cap bit, not actual support for arb_cull_distance (which was already
there), so the log should be changed accordingly.
Apart from what was already mentioned (that is, the cap bit isn't used
by st/mesa which instead mistakenly uses glsl13), it would be nice if
you could test softpipe/llvmpipe with this enabled, as it should already
work (at least for llvmpipe, I'm not entirely sure for softpipe) if not
there's some unaccounted difference somewhere how we'd thought of how
this should work for dx10 vs. opengl).

Roland


Am 24.05.2015 um 19:58 schrieb Tobias Klausmann:
> Add another pipe cap so we can savely enable of disable this extension
> 
> Signed-off-by: Tobias Klausmann 
> ---
>  src/gallium/auxiliary/cso_cache/cso_context.c| 3 +++
>  src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
>  src/gallium/drivers/i915/i915_screen.c   | 1 +
>  src/gallium/drivers/ilo/ilo_screen.c | 1 +
>  src/gallium/drivers/llvmpipe/lp_screen.c | 2 ++
>  src/gallium/drivers/nouveau/nv30/nv30_screen.c   | 1 +
>  src/gallium/drivers/nouveau/nv50/nv50_screen.c   | 1 +
>  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   | 1 +
>  src/gallium/drivers/r300/r300_screen.c   | 1 +
>  src/gallium/drivers/r600/r600_pipe.c | 1 +
>  src/gallium/drivers/radeonsi/si_pipe.c   | 1 +
>  src/gallium/drivers/softpipe/sp_screen.c | 2 ++
>  src/gallium/drivers/svga/svga_screen.c   | 1 +
>  src/gallium/drivers/vc4/vc4_screen.c | 1 +
>  src/gallium/include/pipe/p_defines.h | 1 +
>  15 files changed, 19 insertions(+)
> 
> diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
> b/src/gallium/auxiliary/cso_cache/cso_context.c
> index 744b00c..7612b43 100644
> --- a/src/gallium/auxiliary/cso_cache/cso_context.c
> +++ b/src/gallium/auxiliary/cso_cache/cso_context.c
> @@ -119,6 +119,9 @@ struct cso_context {
> struct pipe_clip_state clip;
> struct pipe_clip_state clip_saved;
>  
> +   struct pipe_clip_state cull;
> +   struct pipe_clip_state cull_saved;
> +
> struct pipe_framebuffer_state fb, fb_saved;
> struct pipe_viewport_state vp, vp_saved;
> struct pipe_blend_color blend_color;
> diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
> b/src/gallium/drivers/freedreno/freedreno_screen.c
> index c596d03..986a942 100644
> --- a/src/gallium/drivers/freedreno/freedreno_screen.c
> +++ b/src/gallium/drivers/freedreno/freedreno_screen.c
> @@ -221,6 +221,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
>   case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
>   case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
>   case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
> + case PIPE_CAP_CULL_DISTANCE:
>   return 0;
>  
>   case PIPE_CAP_MAX_VIEWPORTS:
> diff --git a/src/gallium/drivers/i915/i915_screen.c 
> b/src/gallium/drivers/i915/i915_screen.c
> index 03fecd1..678347d 100644
> --- a/src/gallium/drivers/i915/i915_screen.c
> +++ b/src/gallium/drivers/i915/i915_screen.c
> @@ -242,6 +242,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap 
> cap)
> case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
> case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
> case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
> +   case PIPE_CAP_CULL_DISTANCE:
>return 0;
>  
> case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
> diff --git a/src/gallium/drivers/ilo/ilo_screen.c 
> b/src/gallium/drivers/ilo/ilo_screen.c
> index b0fed73..f92d5de 100644
> --- a/src/gallium/drivers/ilo/ilo_screen.c
> +++ b/src/gallium/drivers/ilo/ilo_screen.c
> @@ -459,6 +459,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap 
> param)
> case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
> case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
> case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
> +   case PIPE_CAP_CULL_DISTANCE:
>return 0;
>  
> case PIPE_CAP_VENDOR_ID:
> diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c 
> b/src/gallium/drivers/llvmpipe/lp_screen.c
> index 09ac9af..c90c405 100644
> --- a/src/gallium/drivers/llvmpipe/lp_screen.c
> +++ b/src/gallium/drivers/llvmpipe/lp_screen.c
> @@ -293,6 +293,8 @@ llvmpipe_get_param(struct pipe_screen *screen, enum 
> pipe_cap param)
> case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
> case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
>return 0;
> +   case PIPE_CAP_CULL_DISTANCE:
> +  return 0;
> }
> /* should only get here on unhandled cases */
> debug_printf("Unexpected PIPE_CAP %d query\n", param);
> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c 
> b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> index bb79ccc..fc33ddf 100644
> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> @@ -162,6 +162,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
> case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
> case PIPE_CAP_RESOU

[Nouveau] [Bug 89558] [NV118] GM108 not supported by nouveau

2015-05-25 Thread bugzilla-daemon

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

--- Comment #34 from SMF  ---
Created attachment 116031
  --> https://bugs.freedesktop.org/attachment.cgi?id=116031&action=edit
kernel 4.1-rc5 nouveau driver with patches applied

For interest tested patches against kernel 4.1-rc5 (with nouveau debug on).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC PATCH 00/11] Implement ARB_cull_distance

2015-05-25 Thread Ilia Mirkin

On Mon, May 25, 2015 at 9:40 AM, Tobias Klausmann
 wrote:
>
> On 25.05.2015 07:17, Dave Airlie wrote:
>>
>> On 25 May 2015 at 08:11, Marek Olšák  wrote:
>>>
>>> It's the same on Radeon. There are 2x ClipOrCullDistance output
>>> vectors and a mask saying it should clip or cull or do nothing.
>>>
>>> Marek
>>>
>> My thinking was gallium should have a single semantic and a mask in
>> the shader definition maybe.
>>
>> though it doesn't solve the does nvidia do the right thing with
>> cull[0] and clip[0], and what is the right thing.
>>
>> Dave.
>
>
> I'm still convinced that both clip[0] and cull[0] should be possible. Plus i
> have written a shader_test for this a while ago which you pushed to piglit
> (fs-cull-and-clip-distance-different.shader_test). If i remember right
> nvidia passed that test just fine.

My take (and note that I last read the extension many months ago) is
that you're supposed to figure out the max gl_ClipDistance[] written,
and then write all your cull distances above that. So if you, e.g.,
have something like

gl_ClipDistance[5] = 1;
gl_CullDistance[0] = 1;

Then it would decide that there are 6 clip distances (or if there's an
explicit out float gl_ClipDistance[n], then use that), and 1 cull
distance. In the TGSI, I'm thinking this might look approximately like

PROPERTY CULL_MASK (1<<6)
DCL OUT[0], CLIPDIST[0]
DCL OUT[1], CLIPDIST[1]
MOV OUT[1].y, 1 (clip distance[5])
MOV OUT[1].z, 1 (cull distance[0])

Then basically you'd have

(rast->clip_enable & shader->actual_clip_writes_mask) | cull_mask =
the enabled distances
cull_mask = cull mask

This would work *very* well for nouveau, not sure how suitable it is
for other hardware.

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 90630] New: random driver crashes mostly after screen lock

2015-05-25 Thread bugzilla-daemon

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

Bug ID: 90630
   Summary: random driver crashes mostly after screen lock
   Product: xorg
   Version: 7.7 (2012.06)
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: fd_mi...@ptaff.ca
QA Contact: xorg-t...@lists.x.org

Created attachment 116026
  --> https://bugs.freedesktop.org/attachment.cgi?id=116026&action=edit
Kernel dmesg output after boot

Hello,

Since my upgrade to Kubuntu 15.04, I have had multiple freezes due to the
nouveau driver. Most of them happen when I am away from my computer, once the
screen is locked. I disabled the screen switch off feature, but kept the dim
screen after 15 minutes feature. I do not have any suspend or hibernate
features enabled. I still get the freezes.

When the freeze occurs, whatever was on the screen is frozen (so I can see the
time at which the freeze occured). My keyboard and mouse are unresponsive
(numlock led doesn't turn on/off). I can remote in (ssh) to my computer and
restart X and everything works correctly.

I do get some nouveau errors in dmesg, though it seems to be after I restart X.
See below the Xorg.0.log backtrace.

I am using the nouveau driver v1.0.11 with Xorg v7.7 (with ubuntu patches). 

uname -a gives:
Linux chum30182linux 3.19.0-18-generic #18-Ubuntu SMP Tue May 19 18:31:35 UTC
2015 x86_64 x86_64 x86_64 GNU/Linux

lspci -v for my video card is as follows:
02:00.0 VGA compatible controller: NVIDIA Corporation G96GL [Quadro FX 380]
(rev a1) (prog-if 00 [VGA controller])
Subsystem: NVIDIA Corporation Device 063b
Flags: bus master, fast devsel, latency 0, IRQ 33
Memory at ca00 (32-bit, non-prefetchable) [size=16M]
Memory at d000 (64-bit, prefetchable) [size=256M]
Memory at cc00 (64-bit, non-prefetchable) [size=32M]
I/O ports at 3000 [size=128]
[virtual] Expansion ROM at cb00 [disabled] [size=512K]
Capabilities: 
Kernel driver in use: nouveau

I have included my dmesg output (kernel_log.txt).

Here is the backtrace in my Xorg.0.log after a freeze.

(EE) Backtrace:
(EE) 0: /usr/bin/X (xorg_backtrace+0x56) [0x7fbea7fc2556]
(EE) 1: /usr/bin/X (QueuePointerEvents+0x52) [0x7fbea7e7eae2]
(EE) 2: /usr/lib/xorg/modules/input/evdev_drv.so (0x7fbe9d265000+0x60ca)
[0x7fbe9d26b0ca]
(EE) 3: /usr/lib/xorg/modules/input/evdev_drv.so (0x7fbe9d265000+0x658d)
[0x7fbe9d26b58d]
(EE) 4: /usr/bin/X (0x7fbea7e0f000+0x96708) [0x7fbea7ea5708]
(EE) 5: /usr/bin/X (0x7fbea7e0f000+0xbfa79) [0x7fbea7ecea79]
(EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (0x7fbea5ad5000+0x352f0)
[0x7fbea5b0a2f0]
(EE) 7: /lib/x86_64-linux-gnu/libc.so.6 (ioctl+0x7) [0x7fbea5bd20b7]
(EE) 8: /usr/lib/x86_64-linux-gnu/libdrm.so.2 (drmIoctl+0x28) [0x7fbea6eb97e8]
(EE) 9: /usr/lib/x86_64-linux-gnu/libdrm.so.2 (drmCommandWrite+0x1b)
[0x7fbea6ebc4ab]
(EE) 10: /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2 (nouveau_bo_wait+0x8c)
[0x7fbea200c53c]
(EE) 11: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0x7fbea2211000+0xceb9)
[0x7fbea221deb9]
(EE) 12: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0x7fbea2211000+0xd90d)
[0x7fbea221e90d]
(EE) 13: /usr/bin/X (DRI2SwapBuffers+0x1d0) [0x7fbea7f95100]
(EE) 14: /usr/bin/X (0x7fbea7e0f000+0x187a7c) [0x7fbea7f96a7c]
(EE) 15: /usr/bin/X (0x7fbea7e0f000+0x580a7) [0x7fbea7e670a7]
(EE) 16: /usr/bin/X (0x7fbea7e0f000+0x5c29b) [0x7fbea7e6b29b]
(EE) 17: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf0)
[0x7fbea5af5a40]
(EE) 18: /usr/bin/X (0x7fbea7e0f000+0x4662e) [0x7fbea7e5562e]
(EE) 
(EE) [mi] EQ overflow continuing.  1000 events have been dropped.
(EE) [mi] No further overflow reports will be reported until the clog is
cleared.
(EE) 
(EE) Backtrace:
(EE) 0: /usr/bin/X (xorg_backtrace+0x56) [0x7fbea7fc2556]
(EE) 1: /usr/bin/X (QueuePointerEvents+0x52) [0x7fbea7e7eae2]
(EE) 2: /usr/lib/xorg/modules/input/evdev_drv.so (0x7fbe9d265000+0x60ca)
[0x7fbe9d26b0ca]
(EE) 3: /usr/lib/xorg/modules/input/evdev_drv.so (0x7fbe9d265000+0x658d)
[0x7fbe9d26b58d]
(EE) 4: /usr/bin/X (0x7fbea7e0f000+0x96708) [0x7fbea7ea5708]
(EE) 5: /usr/bin/X (0x7fbea7e0f000+0xbfa79) [0x7fbea7ecea79]
(EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (0x7fbea5ad5000+0x352f0)
[0x7fbea5b0a2f0]
(EE) 7: /lib/x86_64-linux-gnu/libc.so.6 (ioctl+0x7) [0x7fbea5bd20b7]
(EE) 8: /usr/lib/x86_64-linux-gnu/libdrm.so.2 (drmIoctl+0x28) [0x7fbea6eb97e8]
(EE) 9: /usr/lib/x86_64-linux-gnu/libdrm.so.2 (drmCommandWrite+0x1b)
[0x7fbea6ebc4ab]
(EE) 10: /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2 (nouveau_bo_wait+0x8c)
[0x7fbea200c53c]
(EE) 11: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0x7fbea2211000+0xceb9)
[0x7fbea221deb9]
(EE) 12: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0x7fbea2211000+0xd90d)
[0x7fbea221e90d]
(EE) 13: /usr/bin/X (DRI2SwapBuffers+0x1d0)

[Nouveau] [PATCH] docs: Mark ARB_cull_distance as in progress

2015-05-25 Thread Tobias Klausmann

Signed-off-by: Tobias Klausmann 
---

I'm already getting emails wanting me to do this, so just mark it,
wont change anything really

 docs/GL3.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index 44a824b..8e1c8cd 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -190,7 +190,7 @@ GL 4.5, GLSL 4.50:
   GL_ARB_ES3_1_compatibility   not started
   GL_ARB_clip_control  DONE (i965, nv50, nvc0, 
r600, radeonsi, llvmpipe, softpipe)
   GL_ARB_conditional_render_inverted   DONE (i965, nv50, nvc0, 
llvmpipe, softpipe)
-  GL_ARB_cull_distance not started
+  GL_ARB_cull_distance in progress (Tobias)
   GL_ARB_derivative_controlDONE (i965, nv50, nvc0, 
r600)
   GL_ARB_direct_state_access   DONE (all drivers)
   - Transform Feedback object  DONE
-- 
2.4.1

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC PATCH 00/11] Implement ARB_cull_distance

2015-05-25 Thread Tobias Klausmann



On 25.05.2015 07:17, Dave Airlie wrote:

On 25 May 2015 at 08:11, Marek Olšák  wrote:

It's the same on Radeon. There are 2x ClipOrCullDistance output
vectors and a mask saying it should clip or cull or do nothing.

Marek


My thinking was gallium should have a single semantic and a mask in
the shader definition maybe.

though it doesn't solve the does nvidia do the right thing with
cull[0] and clip[0], and what is the right thing.

Dave.


I'm still convinced that both clip[0] and cull[0] should be possible. 
Plus i have written a shader_test for this a while ago which you pushed 
to piglit (fs-cull-and-clip-distance-different.shader_test). If i 
remember right nvidia passed that test just fine.

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [Mesa-dev] [PATCH 07/11] glsl: Add arb_cull_distance support

2015-05-25 Thread Timothy Arceri

On Mon, 2015-05-25 at 00:46 +0200, Tobias Klausmann wrote:
> hi,
> replay inline.
> 
> On 25.05.2015 00:34, Timothy Arceri wrote:
> > On Sun, 2015-05-24 at 19:58 +0200, Tobias Klausmann wrote:
> >> Signed-off-by: Tobias Klausmann 
> >> ---
> >>   src/glsl/ast_to_hir.cpp |  14 +
> >>   src/glsl/builtin_variables.cpp  |  13 +++-
> >>   src/glsl/glcpp/glcpp-parse.y|   3 +
> >>   src/glsl/glsl_parser_extras.cpp |   1 +
> >>   src/glsl/glsl_parser_extras.h   |   3 +
> >>   src/glsl/link_varyings.cpp  |   2 +-
> >>   src/glsl/linker.cpp | 121 
> >> +---
> >>   src/glsl/standalone_scaffolding.cpp |   1 +
> >>   src/glsl/tests/varyings_test.cpp|  27 
> >>   9 files changed, 145 insertions(+), 40 deletions(-)
> >>
> >> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> >> index 8aebb13..4db2b2e 100644
> >> --- a/src/glsl/ast_to_hir.cpp
> >> +++ b/src/glsl/ast_to_hir.cpp
> >> @@ -1045,6 +1045,20 @@ check_builtin_array_max_size(const char *name, 
> >> unsigned size,
> >> _mesa_glsl_error(&loc, state, "`gl_ClipDistance' array size cannot 
> >> "
> >>  "be larger than gl_MaxClipDistances (%u)",
> >>  state->Const.MaxClipPlanes);
> >> +   } else if (strcmp("gl_CullDistance", name) == 0
> >> +  && size > state->Const.MaxClipPlanes) {
> >> +  /* From the ARB_cull_distance spec:
> >> +   *
> >> +   *   "The gl_CullDistance array is predeclared as unsized and
> >> +   *must be sized by the shader either redeclaring it with
> >> +   *a size or indexing it only with integral constant
> >> +   *expressions. The size determines the number and set of
> >> +   *enabled cull distances and can be at most
> >> +   *gl_MaxCullDistances."
> >> +   */
> >> +  _mesa_glsl_error(&loc, state, "`gl_CullDistance' array size cannot "
> >> +   "be larger than gl_MaxCullDistances (%u)",
> >> +   state->Const.MaxClipPlanes);
> >>  }
> >>   }
> >>   
> >> diff --git a/src/glsl/builtin_variables.cpp 
> >> b/src/glsl/builtin_variables.cpp
> >> index 6806aa1..78c8db2 100644
> >> --- a/src/glsl/builtin_variables.cpp
> >> +++ b/src/glsl/builtin_variables.cpp
> >> @@ -298,7 +298,7 @@ public:
> >>  const glsl_type *construct_interface_instance() const;
> >>   
> >>   private:
> >> -   glsl_struct_field fields[10];
> >> +   glsl_struct_field fields[11];
> >>  unsigned num_fields;
> >>   };
> >>   
> >> @@ -600,6 +600,12 @@ builtin_variable_generator::generate_constants()
> >> add_const("gl_MaxVaryingComponents", state->ctx->Const.MaxVarying 
> >> * 4);
> >>  }
> >>   
> >> +   if (state->is_version(450, 0) || state->ARB_cull_distance_enable) {
> >> +  add_const("gl_MaxCullDistances", state->Const.MaxClipPlanes);
> >> +  add_const("gl_MaxCombinedClipAndCullDistances",
> >> +state->Const.MaxClipPlanes);
> >> +   }
> >> +
> >>  if (state->is_version(150, 0)) {
> >> add_const("gl_MaxVertexOutputComponents",
> >>   state->Const.MaxVertexOutputComponents);
> >> @@ -1029,6 +1035,11 @@ builtin_variable_generator::generate_varyings()
> >>  "gl_ClipDistance");
> >>  }
> >>   
> >> +   if (state->is_version(450, 0) || state->ARB_cull_distance_enable) {
> >> +   ADD_VARYING(VARYING_SLOT_CULL_DIST0, array(float_t, 0),
> >> +   "gl_CullDistance");
> >> +   }
> >> +
> >>  if (compatibility) {
> >> ADD_VARYING(VARYING_SLOT_TEX0, array(vec4_t, 0), "gl_TexCoord");
> >> ADD_VARYING(VARYING_SLOT_FOGC, float_t, "gl_FogFragCoord");
> >> diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
> >> index a11b6b2..536c17f 100644
> >> --- a/src/glsl/glcpp/glcpp-parse.y
> >> +++ b/src/glsl/glcpp/glcpp-parse.y
> >> @@ -2483,6 +2483,9 @@ 
> >> _glcpp_parser_handle_version_declaration(glcpp_parser_t *parser, intmax_t 
> >> versio
> >>   
> >> if (extensions->ARB_shader_precision)
> >>add_builtin_define(parser, "GL_ARB_shader_precision", 
> >> 1);
> >> +
> >> +  if (extensions->ARB_cull_distance)
> >> +   add_builtin_define(parser, "GL_ARB_cull_distance", 1);
> >>   }
> >>}
> >>   
> >> diff --git a/src/glsl/glsl_parser_extras.cpp 
> >> b/src/glsl/glsl_parser_extras.cpp
> >> index 046d5d7..d1cd8ff 100644
> >> --- a/src/glsl/glsl_parser_extras.cpp
> >> +++ b/src/glsl/glsl_parser_extras.cpp
> >> @@ -554,6 +554,7 @@ static const _mesa_glsl_extension 
> >> _mesa_glsl_supported_extensions[] = {
> >>  EXT(ARB_arrays_of_arrays,   true,  false, 
> >> ARB_arrays_of_arrays),
> >>  EXT(ARB_compute_shader, true,  false, 
> >> ARB_compute_shader),
> >>  EXT(ARB_conservative_depth, true,  false, 
> >> ARB_conservative_depth),
> >> +   EXT(ARB_cull_distan

Re: [Nouveau] [Mesa-dev] [PATCH 07/11] glsl: Add arb_cull_distance support

2015-05-25 Thread Timothy Arceri

On Sun, 2015-05-24 at 19:58 +0200, Tobias Klausmann wrote:
> Signed-off-by: Tobias Klausmann 
> ---
>  src/glsl/ast_to_hir.cpp |  14 +
>  src/glsl/builtin_variables.cpp  |  13 +++-
>  src/glsl/glcpp/glcpp-parse.y|   3 +
>  src/glsl/glsl_parser_extras.cpp |   1 +
>  src/glsl/glsl_parser_extras.h   |   3 +
>  src/glsl/link_varyings.cpp  |   2 +-
>  src/glsl/linker.cpp | 121 
> +---
>  src/glsl/standalone_scaffolding.cpp |   1 +
>  src/glsl/tests/varyings_test.cpp|  27 
>  9 files changed, 145 insertions(+), 40 deletions(-)
> 
> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> index 8aebb13..4db2b2e 100644
> --- a/src/glsl/ast_to_hir.cpp
> +++ b/src/glsl/ast_to_hir.cpp
> @@ -1045,6 +1045,20 @@ check_builtin_array_max_size(const char *name, 
> unsigned size,
>_mesa_glsl_error(&loc, state, "`gl_ClipDistance' array size cannot "
> "be larger than gl_MaxClipDistances (%u)",
> state->Const.MaxClipPlanes);
> +   } else if (strcmp("gl_CullDistance", name) == 0
> +  && size > state->Const.MaxClipPlanes) {
> +  /* From the ARB_cull_distance spec:
> +   *
> +   *   "The gl_CullDistance array is predeclared as unsized and
> +   *must be sized by the shader either redeclaring it with
> +   *a size or indexing it only with integral constant
> +   *expressions. The size determines the number and set of
> +   *enabled cull distances and can be at most
> +   *gl_MaxCullDistances."
> +   */
> +  _mesa_glsl_error(&loc, state, "`gl_CullDistance' array size cannot "
> +   "be larger than gl_MaxCullDistances (%u)",
> +   state->Const.MaxClipPlanes);
> }
>  }
>  
> diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
> index 6806aa1..78c8db2 100644
> --- a/src/glsl/builtin_variables.cpp
> +++ b/src/glsl/builtin_variables.cpp
> @@ -298,7 +298,7 @@ public:
> const glsl_type *construct_interface_instance() const;
>  
>  private:
> -   glsl_struct_field fields[10];
> +   glsl_struct_field fields[11];
> unsigned num_fields;
>  };
>  
> @@ -600,6 +600,12 @@ builtin_variable_generator::generate_constants()
>add_const("gl_MaxVaryingComponents", state->ctx->Const.MaxVarying * 4);
> }
>  
> +   if (state->is_version(450, 0) || state->ARB_cull_distance_enable) {
> +  add_const("gl_MaxCullDistances", state->Const.MaxClipPlanes);
> +  add_const("gl_MaxCombinedClipAndCullDistances",
> +state->Const.MaxClipPlanes);
> +   }
> +
> if (state->is_version(150, 0)) {
>add_const("gl_MaxVertexOutputComponents",
>  state->Const.MaxVertexOutputComponents);
> @@ -1029,6 +1035,11 @@ builtin_variable_generator::generate_varyings()
> "gl_ClipDistance");
> }
>  
> +   if (state->is_version(450, 0) || state->ARB_cull_distance_enable) {
> +   ADD_VARYING(VARYING_SLOT_CULL_DIST0, array(float_t, 0),
> +   "gl_CullDistance");
> +   }
> +
> if (compatibility) {
>ADD_VARYING(VARYING_SLOT_TEX0, array(vec4_t, 0), "gl_TexCoord");
>ADD_VARYING(VARYING_SLOT_FOGC, float_t, "gl_FogFragCoord");
> diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
> index a11b6b2..536c17f 100644
> --- a/src/glsl/glcpp/glcpp-parse.y
> +++ b/src/glsl/glcpp/glcpp-parse.y
> @@ -2483,6 +2483,9 @@ _glcpp_parser_handle_version_declaration(glcpp_parser_t 
> *parser, intmax_t versio
>  
>if (extensions->ARB_shader_precision)
>   add_builtin_define(parser, "GL_ARB_shader_precision", 1);
> +
> +  if (extensions->ARB_cull_distance)
> +  add_builtin_define(parser, "GL_ARB_cull_distance", 1);
>  }
>   }
>  
> diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
> index 046d5d7..d1cd8ff 100644
> --- a/src/glsl/glsl_parser_extras.cpp
> +++ b/src/glsl/glsl_parser_extras.cpp
> @@ -554,6 +554,7 @@ static const _mesa_glsl_extension 
> _mesa_glsl_supported_extensions[] = {
> EXT(ARB_arrays_of_arrays,   true,  false, 
> ARB_arrays_of_arrays),
> EXT(ARB_compute_shader, true,  false, ARB_compute_shader),
> EXT(ARB_conservative_depth, true,  false, 
> ARB_conservative_depth),
> +   EXT(ARB_cull_distance,  true,  false, ARB_cull_distance),
> EXT(ARB_derivative_control, true,  false, 
> ARB_derivative_control),
> EXT(ARB_draw_buffers,   true,  false, dummy_true),
> EXT(ARB_draw_instanced, true,  false, ARB_draw_instanced),
> diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
> index 9a0c24e..8572905 100644
> --- a/src/glsl/glsl_parser_extras.h
> +++ b/src/glsl/glsl_parser_extras.h
> @@ -378,6 +378,7 @@ struct _mesa_glsl_

[Nouveau] [Bug 90567] Display freeze when starting League of Legends (Wine)

2015-05-25 Thread bugzilla-daemon

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

--- Comment #6 from Samuel Pitoiset  ---
Created attachment 116021
  --> https://bugs.freedesktop.org/attachment.cgi?id=116021&action=edit
0001-nvc0-prevent-using-unvalidated-vertex-programs.patch

Hello Detlev,

Did you test with mesa git?
In any cases, could you please try this attached patch ?

I'm absolutely not sure it will fix your issue but let's try. :-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 90567] Display freeze when starting League of Legends (Wine)

2015-05-25 Thread bugzilla-daemon

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

--- Comment #4 from Detlev Casanova  ---
Hello, thanks for your response.

The version of mesa was just updated by my distro (archlinux) to version : 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.5.6
OpenGL version string: 3.0 Mesa 10.5.6
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.5.6

I'll attach a log that shows the journal when the game freezes. I just realized
that only the game freezes. Once it's been killed by SSH, I get the control of
the system back.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 90567] Display freeze when starting League of Legends (Wine)

2015-05-25 Thread bugzilla-daemon

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

--- Comment #5 from Detlev Casanova  ---
Created attachment 116019
  --> https://bugs.freedesktop.org/attachment.cgi?id=116019&action=edit
Nouveau log from beginning

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] grey screen of death

2015-05-25 Thread john francis lee

HI,

I have an old motherboard ...

Base Board Information
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: M61PME-S2P
Version: x.x
Serial Number: 

Processor Information
Socket Designation: Socket M2
Type: Central Processor
Family: Athlon
Manufacturer: AMD
ID: B2 0F 06 00 FF FB 8B 17
Signature: Family 15, Model 107, Stepping 2

00:0d.0 VGA compatible controller: NVIDIA Corporation C61 [GeForce
6150SE nForce 430] (rev a2)

... and since I've upgraded from debian 7 wheezy to debian 8 jessie
(reinstalled, actually) I've been experiencing a grey screen of death,
at unpredictable intervals ... usually associated (I think) with using
iceweasel or icedove. The screen goes grey and the whole machine is
locked up tight. I have to powerdown and power back up. Just like a
microsoft box.

I don't like this at all. Has anyone else had this problem? Any and all
help greatly appreciated.

Never any problem with wheezy or unbuntu 8 - 11 before now.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 90626] New: HP ZBook 15 nouveau driver hangup for kernel >= 3.19

2015-05-25 Thread bugzilla-daemon

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

Bug ID: 90626
   Summary: HP ZBook 15 nouveau driver hangup for kernel >= 3.19
   Product: xorg
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: critical
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: renda.kr...@gmail.com
QA Contact: xorg-t...@lists.x.org

This is not a duplicate of bug #89047, but just another bug after a driver fix.

For bug #89047 there has been obviously made the following fix:
-
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4195f40685a5f2783b4decece13ed740b61ee038

I tried this on my HP ZBook 15 using 4.1.rc4 (OpenSUSE HEAD kernel,
kernel-desktop) where this fix definitely went and run into another issue:

2015-05-25T08:26:17.054291+02:00 rkrell kernel: [4.681436] nouveau  [ 
DEVICE][:01:00.0] BOOT0  : 0x108390a1
2015-05-25T08:26:17.054293+02:00 rkrell kernel: [4.681438] nouveau  [ 
DEVICE][:01:00.0] Chipset: GK208 (NV108)
2015-05-25T08:26:17.054293+02:00 rkrell kernel: [4.681440] nouveau  [ 
DEVICE][:01:00.0] Family : NVE0
2015-05-25T08:26:17.054294+02:00 rkrell kernel: [4.686763] nouveau  [  
VBIOS][:01:00.0] using image from ACPI
2015-05-25T08:26:17.054294+02:00 rkrell kernel: [4.686921] nouveau  [  
VBIOS][:01:00.0] BIT signature found
2015-05-25T08:26:17.054352+02:00 rkrell kernel: [4.686924] nouveau  [  
VBIOS][:01:00.0] version 80.28.52.00.09
2015-05-25T08:26:17.054353+02:00 rkrell kernel: [4.686931] nouveau W[  
VBIOS][:01:00.0] DCB contains no useful data
2015-05-25T08:26:17.054356+02:00 rkrell kernel: [4.686932] nouveau W[  
VBIOS][:01:00.0] DCB contains no useful data
2015-05-25T08:26:17.054356+02:00 rkrell kernel: [4.686938] nouveau E[  
VBIOS][:01:00.0] 0xce73[ ]: unknown opcode 0xff
2015-05-25T08:26:17.054357+02:00 rkrell kernel: [4.686942] nouveau E[
DEVINIT][:01:00.0] init failed, -22
2015-05-25T08:26:17.054357+02:00 rkrell kernel: [4.686944] nouveau E[
DRM] failed to create 0x0080, -22
2015-05-25T08:26:17.054358+02:00 rkrell kernel: [4.687221] nouveau: probe
of :01:00.0 failed with error -22

The kernel still hangs up, CTRL-ALT-BACKSPACE does not work.
The BIOS of the HP ZBook 15 is set to Legacy Mode, no UEFI is used.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 90626] HP ZBook 15 nouveau driver hangup for kernel >= 4.1

2015-05-25 Thread bugzilla-daemon

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

René  changed:

   What|Removed |Added

Summary|HP ZBook 15 nouveau driver  |HP ZBook 15 nouveau driver
   |hangup for kernel >= 3.19   |hangup for kernel >= 4.1

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

48 matches

Mail list logo