Re: [Mesa-dev] [PATCH 3/4] radeon, r200: allow hyperz for radeon DRM module v2

2015-07-13 Thread Alex Deucher 
On Sat, Jul 11, 2015 at 8:48 AM, Roland Scheidegger  wrote:
> Am 11.07.2015 um 11:25 schrieb Marek Olšák:
>> On Fri, Jul 10, 2015 at 11:02 PM, Roland Scheidegger  
>> wrote:
>>> Am 10.07.2015 um 19:41 schrieb Emil Velikov:
 On 10 July 2015 at 13:18, Roland Scheidegger  wrote:
> Am 10.07.2015 um 05:44 schrieb Michel Dänzer:
>> On 10.07.2015 05:13, Emil Velikov wrote:
>>> The original code only half considered hyperz as an option. As per
>>> previous commit "major != 2 cannot occur" we can simply things, and
>>> allow users to set the option if they choose to do so.
>>>
>>> Signed-off-by: Emil Velikov 
>>> ---
>>>  src/mesa/drivers/dri/r200/r200_context.c | 10 ++
>>>  src/mesa/drivers/dri/radeon/radeon_context.c |  9 ++---
>>>  2 files changed, 4 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/r200/r200_context.c 
>>> b/src/mesa/drivers/dri/r200/r200_context.c
>>> index 40cc50a..2a42ab3 100644
>>> --- a/src/mesa/drivers/dri/r200/r200_context.c
>>> +++ b/src/mesa/drivers/dri/r200/r200_context.c
>>> @@ -225,14 +225,8 @@ GLboolean r200CreateContext( gl_api api,
>>> rmesa->radeon.initialMaxAnisotropy = 
>>> driQueryOptionf(&rmesa->radeon.optionCache,
>>>  
>>> "def_max_anisotropy");
>>>
>>> -   if ( sPriv->drm_version.major == 1
>>> -   && driQueryOptionb( &rmesa->radeon.optionCache, "hyperz" ) ) {
>>> -  if ( sPriv->drm_version.minor < 13 )
>>> - fprintf( stderr, "DRM version 1.%d too old to support HyperZ, "
>>> -  "disabling.\n", sPriv->drm_version.minor );
>>> -  else
>>> - rmesa->using_hyperz = GL_TRUE;
>>> -   }
>>
>> This code only set rmesa->using_hyperz = GL_TRUE if
>> sPriv->drm_version.major == 1. It was disabled for KMS in commit
>> e541845959761e9f47d14ade6b58a32db04ef7e4 ("r200: Fix piglit paths 
>> test.").
>>
>>
>>> +   if (driQueryOptionb( &rmesa->radeon.optionCache, "hyperz"))
>>> +  rmesa->using_hyperz = GL_TRUE;
>>
>> This enables it again for KMS. Maybe that's okay though, especially if
>> the driconf option is disabled by default.
>
>
> Oh you're right. The reason given though why it was disabled looks bogus
> to me ("Piglit doesn't like HyperZ warning so disable it for kms." ???),
> and I can't see why that would have only applied to r200, not r100. So
> it should be fine. (Of course, you will get more failures with that
> enabled with piglit, some things just plain won't work, but that was
> just the case with UMS too, and the reason why it never was enabled by
> default.)
>
 Yes without Roland's knowledge if hyperz is supposed to work for KMS
 the current code is quite ambiguous. If you guys prefer I can simply
 rip out the whole thing, then again hyperz is disabled by default so
 no harm should follow with this patch.

 I don't mind either way.
 Emil

>>>
>>> I'd say keep the option (for both drivers) for now.
>>> I've got some r200 in a dust bin actually, haven't touched it in years...
>>> I think it should work in the same way as it does on r100.
>>> The depth buffer metadata (i.e. the bits saying if a tile is compressed
>>> or not etc.) is really fixed onchip cache, and there's no attempt to
>>> grab or restore that data when the depth buffer is changed, which
>>> obviously isn't quite right... The other limitation is that you cannot
>>> read or write the depth buffer directly (well you can but you get back
>>> garbage - not being able to do a glReadPixel on the depth buffer alone
>>> will cause lots of piglit failures). UMS could also do fast z clear,
>>> this is pretty simple as the command would just set the on-chip tile
>>> bits to the "cleared" state, but this never made it to KMS - the rest of
>>> hyperz should work without this, however, though I'm not entirely sure.
>>> IIRC the r300 has actually pretty much the same hw limitations, however
>>> the driver there fixes these issues (though I think that chip had some
>>> nicer way of fast z clear).
>>
>> Not really, there is just a packet to clear the on-chip tile bits and
>> we always clear the whole surface.
> Yes but for r100/r200 I don't know if such a packet exists. The kernel
> did all the effort for figuring out the actual on-chip addresses to
> clear (of course, with the shared z buffer of late, that way actually
> multiple apps ran with hyperz enabled in parallel correctly, as long as
> they were placed "far enough apart" on the screen (so the tiles wouldn't
> intersect).
> It is possible though such a packet exists on r100/r200 too, and we just
> never figured it out :-).

If there wasn't a special packet, I think you could just write to some
registers to get the same effect.

Alex

>
> Roland
>
>>
>> For reading back zbuffers, a full-sc

Re: [Mesa-dev] [PATCH] r600/sb: Fix an &/&& mistake

2015-07-21 Thread Alex Deucher 
On Tue, Jul 21, 2015 at 12:12 PM, Adam Jackson  wrote:
> gcc says:
>
> sb/sb_sched.cpp: In member function 'bool 
> r600_sb::alu_group_tracker::try_reserve(r600_sb::alu_node*)':
> sb/sb_sched.cpp:492:7: warning: suggest parentheses around operand of '!' 
> or change '&' to '&&' or '!' to '~' [-Wparentheses]
>   if (!trans & fbs)
>
> It happens to be harmless; if fbs is ever non-zero, it will be VEC_210,
> which is 5, so (!trans & 5) == 1 and the branch works as expected.  But
> logical AND is clearly what was meant.
>
> Signed-off-by: Adam Jackson 

Reviewed-by: Alex Deucher 

> ---
>  src/gallium/drivers/r600/sb/sb_sched.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/r600/sb/sb_sched.cpp 
> b/src/gallium/drivers/r600/sb/sb_sched.cpp
> index 2e38a62..6268078 100644
> --- a/src/gallium/drivers/r600/sb/sb_sched.cpp
> +++ b/src/gallium/drivers/r600/sb/sb_sched.cpp
> @@ -489,7 +489,7 @@ bool alu_group_tracker::try_reserve(alu_node* n) {
>
> n->bc.bank_swizzle = 0;
>
> -   if (!trans & fbs)
> +   if (!trans && fbs)
> n->bc.bank_swizzle = VEC_210;
>
> if (gpr.try_reserve(n)) {
> --
> 2.4.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Using the right context in st_texture_release_all_sampler_views()

2015-07-23 Thread Alex Deucher 
On Wed, Jul 22, 2015 at 6:32 PM, Brian Paul  wrote:
> Hi Marek,
>
> This is regarding your commit "st/mesa: use pipe_sampler_view_release for
> releasing sampler views" from last October.
>
> Basically, we have:
>
> void
> st_texture_release_all_sampler_views(struct st_context *st,
>  struct st_texture_object *stObj)
> {
>GLuint i;
>
>/* XXX This should use sampler_views[i]->pipe, not st->pipe */
>for (i = 0; i < stObj->num_sampler_views; ++i)
>   pipe_sampler_view_release(st->pipe, &stObj->sampler_views[i]);
> }
>
> Our VMware/svga driver has an issue when
> pipe_context::sampler_view_destroy() is called with one context and a
> sampler view which was created with another context.  I can hack around it
> in our driver code, but it would be nice to fix this in the state tracker.
>
> Ideally, the above code should be something like:
>
>for (i = 0; i < stObj->num_sampler_views; ++i)
>   pipe_sampler_view_reference(&stObj->sampler_views[i], NULL);
>
> The current code which uses the st->pipe context came from the bug
> https://bugs.freedesktop.org/show_bug.cgi?id=81680
>
> AFAICT, you were just working around an R600 driver issue.  Any chance we
> could fix the state tracker and re-test Firefox on R600?

I seem to recall Stéphane seeing something similar with the i915g
driver on Chromium, but I can't find the thread now.

Alex

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

Re: [Mesa-dev] [PATCH] u_vbuf: fix vb slot assignment for translated buffers

2015-10-12 Thread Alex Deucher 
On Mon, Oct 12, 2015 at 7:10 AM, Nicolai Hähnle  wrote:
> On 09.10.2015 23:57, Marek Olšák wrote:
>>
>> Do you still have commit access and should somebody else push this?
>
>
> I have to figure out how to get somebody to pay attention to
> https://bugs.freedesktop.org/show_bug.cgi?id=92281
>
> Feel free to push this in the meantime; otherwise I'll eventually do it once
> I have access again.

You should be all set.

Alex

>
> Nicolai
>
>
>>
>> Marek
>>
>> On Sun, Oct 4, 2015 at 2:19 PM, Marek Olšák  wrote:
>>>
>>> Oh, I forgot this:
>>>
>>> Reviewed-by: Marek Olšák 
>>>
>>> Marek
>>>
>>> On Sun, Oct 4, 2015 at 2:03 PM, Marek Olšák  wrote:

 Nice catch. Please add this to the commit message:

 Cc: mesa-sta...@lists.freedesktop.org

 It will be automatically picked for 11.0 after you push it.

 Marek

 On Sun, Oct 4, 2015 at 12:09 PM, Nicolai Hähnle 
 wrote:
>
> Vertex attributes of different categories (constant/per-instance/
> per-vertex) go into different buffers for translation, and this is now
> properly reflected in the vertex buffers passed to the driver.
>
> Fixes e.g. piglit's point-vertex-id divisor test.
> ---
>   src/gallium/auxiliary/util/u_vbuf.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/auxiliary/util/u_vbuf.c
> b/src/gallium/auxiliary/util/u_vbuf.c
> index 3d2193c..b31ada1 100644
> --- a/src/gallium/auxiliary/util/u_vbuf.c
> +++ b/src/gallium/auxiliary/util/u_vbuf.c
> @@ -544,6 +544,7 @@ u_vbuf_translate_find_free_vb_slots(struct u_vbuf
> *mgr,
>
>index = ffs(unused_vb_mask) - 1;
>fallback_vbs[type] = index;
> + unused_vb_mask &= ~(1 << index);
>/*printf("found slot=%i for type=%i\n", index, type);*/
> }
>  }
> --
> 2.1.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] r600/vce: enable VCE for trinity/richland

2015-10-12 Thread Alex Deucher 
On Mon, Oct 12, 2015 at 4:53 AM, Christian König
 wrote:
> From: Christian König 
>
> Signed-off-by: Christian König 

For the series:
Reviewed-by: Alex Deucher 

> ---
>  src/gallium/drivers/r600/r600_uvd.c | 22 +-
>  1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/r600/r600_uvd.c 
> b/src/gallium/drivers/r600/r600_uvd.c
> index 3a94a5a..e2e9033 100644
> --- a/src/gallium/drivers/r600/r600_uvd.c
> +++ b/src/gallium/drivers/r600/r600_uvd.c
> @@ -47,6 +47,7 @@
>  #include "r600_pipe.h"
>  #include "radeon/radeon_video.h"
>  #include "radeon/radeon_uvd.h"
> +#include "radeon/radeon_vce.h"
>  #include "r600d.h"
>
>  #define R600_UVD_ENABLE_TILING 0
> @@ -168,9 +169,28 @@ static struct radeon_winsys_cs_handle* 
> r600_uvd_set_dtb(struct ruvd_msg *msg, st
> return luma->resource.cs_buf;
>  }
>
> +/* get the radeon resources for VCE */
> +static void r600_vce_get_buffer(struct pipe_resource *resource,
> +   struct radeon_winsys_cs_handle **handle,
> +   struct radeon_surf **surface)
> +{
> +   struct r600_texture *res = (struct r600_texture *)resource;
> +
> +   if (handle)
> +   *handle = res->resource.cs_buf;
> +
> +   if (surface)
> +   *surface = &res->surface;
> +}
> +
>  /* create decoder */
>  struct pipe_video_codec *r600_uvd_create_decoder(struct pipe_context 
> *context,
> -  const struct 
> pipe_video_codec *templat)
> +const struct 
> pipe_video_codec *templat)
>  {
> +   struct r600_context *ctx = (struct r600_context *)context;
> +
> +if (templat->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE)
> +return rvce_create_encoder(context, templat, ctx->b.ws, 
> r600_vce_get_buffer);
> +
> return ruvd_create_decoder(context, templat, r600_uvd_set_dtb);
>  }
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600g: Pass conservative depth parameters to hw

2015-10-17 Thread Alex Deucher 
On Fri, Oct 16, 2015 at 6:52 PM, Glenn Kennard  wrote:
> Supported on R700 and up.
>
> Signed-off-by: Glenn Kennard 
> ---
> Not exactly a commonly used extension, but might as well set the
> hardware registers rather than just dropping the hint on the floor.
>
>  src/gallium/drivers/r600/evergreen_state.c | 13 +
>  src/gallium/drivers/r600/evergreend.h  |  7 +++
>  src/gallium/drivers/r600/r600_shader.c |  1 +
>  src/gallium/drivers/r600/r600_shader.h |  2 ++
>  src/gallium/drivers/r600/r600_state.c  | 15 +++
>  src/gallium/drivers/r600/r600d.h   |  8 
>  6 files changed, 46 insertions(+)
>
> diff --git a/src/gallium/drivers/r600/evergreen_state.c 
> b/src/gallium/drivers/r600/evergreen_state.c
> index c6702a9..96c6b11 100644
> --- a/src/gallium/drivers/r600/evergreen_state.c
> +++ b/src/gallium/drivers/r600/evergreen_state.c
> @@ -2940,6 +2940,19 @@ void evergreen_update_ps_state(struct pipe_context 
> *ctx, struct r600_pipe_shader
> db_shader_control |= S_02880C_STENCIL_EXPORT_ENABLE(stencil_export);
> db_shader_control |= S_02880C_MASK_EXPORT_ENABLE(mask_export);
>
> +   switch (rshader->ps_conservative_z) {
> +   default: /* fall through */
> +   case TGSI_FS_DEPTH_LAYOUT_ANY:
> +   db_shader_control |= 
> S_02880C_CONSERVATIVE_Z_EXPORT(V_02880C_EXPORT_ANY_Z);
> +   break;
> +   case TGSI_FS_DEPTH_LAYOUT_GREATER:
> +   db_shader_control |= 
> S_02880C_CONSERVATIVE_Z_EXPORT(V_02880C_EXPORT_GREATER_THAN_Z);
> +   break;
> +   case TGSI_FS_DEPTH_LAYOUT_LESS:
> +   db_shader_control |= 
> S_02880C_CONSERVATIVE_Z_EXPORT(V_02880C_EXPORT_LESS_THAN_Z);
> +   break;
> +   }
> +
> exports_ps = 0;
> for (i = 0; i < rshader->noutput; i++) {
> if (rshader->output[i].name == TGSI_SEMANTIC_POSITION ||
> diff --git a/src/gallium/drivers/r600/evergreend.h 
> b/src/gallium/drivers/r600/evergreend.h
> index 937ffcb..a9a65f7 100644
> --- a/src/gallium/drivers/r600/evergreend.h
> +++ b/src/gallium/drivers/r600/evergreend.h
> @@ -815,6 +815,13 @@
>  #define V_02880C_EXPORT_DB_FOUR16  0x01
>  #define V_02880C_EXPORT_DB_TWO 0x02
>  #define   S_02880C_ALPHA_TO_MASK_DISABLE(x)(((x) & 0x1) << 12)
> +#define   S_02880C_CONSERVATIVE_Z_EXPORT(x)(((x) & 0x03) << 16)
> +#define   G_02880C_CONSERVATIVE_Z_EXPORT(x)(((x) >> 16) & 0x03)
> +#define   C_02880C_CONSERVATIVE_Z_EXPORT   0xFFFC
> +#define V_02880C_EXPORT_ANY_Z  0
> +#define V_02880C_EXPORT_LESS_THAN_Z1
> +#define V_02880C_EXPORT_GREATER_THAN_Z 2
> +#define V_02880C_EXPORT_RESERVED   3
>
>  #define R_028A00_PA_SU_POINT_SIZE0x028A00
>  #define   S_028A00_HEIGHT(x)   (((x) & 0x) << 0)
> diff --git a/src/gallium/drivers/r600/r600_shader.c 
> b/src/gallium/drivers/r600/r600_shader.c
> index 8efe902..560696d 100644
> --- a/src/gallium/drivers/r600/r600_shader.c
> +++ b/src/gallium/drivers/r600/r600_shader.c
> @@ -2048,6 +2048,7 @@ static int r600_shader_from_tgsi(struct r600_context 
> *rctx,
>
> shader->fs_write_all = 
> ctx.info.properties[TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS];
> shader->vs_position_window_space = 
> ctx.info.properties[TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION];
> +   shader->ps_conservative_z = 
> ctx.info.properties[TGSI_PROPERTY_FS_DEPTH_LAYOUT];
>
> if (shader->vs_as_gs_a)
> vs_add_primid_output(&ctx, key.vs.prim_id_out);
> diff --git a/src/gallium/drivers/r600/r600_shader.h 
> b/src/gallium/drivers/r600/r600_shader.h
> index c240e71..e085263 100644
> --- a/src/gallium/drivers/r600/r600_shader.h
> +++ b/src/gallium/drivers/r600/r600_shader.h
> @@ -76,6 +76,8 @@ struct r600_shader {
> boolean uses_tex_buffers;
> boolean gs_prim_id_input;
>
> +   unsignedps_conservative_z;
> +
> /* Size in bytes of a data item in the ring(s) (single vertex data).
>Stages with only one ring items 123 will be set to 0. */
> unsignedring_item_sizes[4];
> diff --git a/src/gallium/drivers/r600/r600_state.c 
> b/src/gallium/drivers/r600/r600_state.c
> index 1be3e1b..09b2325 100644
> --- a/src/gallium/drivers/r600/r600_state.c
> +++ b/src/gallium/drivers/r600/r600_state.c
> @@ -2533,6 +2533,21 @@ void r600_update_ps_state(struct pipe_context *ctx, 
> struct r600_pipe_shader *sha
> if (rshader->uses_kill)
> db_shader_control |= S_02880C_KILL_ENABLE(1);
>
> +   if (rctx->b.chip_class >= R700) {
> +   switch (rshader->ps_conservative_z) {
> +   default: /* fall through */
> +   case TGSI_FS_DEPTH_LAYOUT_ANY:
> +   db_shader_contro

[Mesa-dev] [PATCH 1/2] radeonsi: add support for Stoney asics (v2)

2015-10-22 Thread Alex Deucher 
From: Samuel Li 

v2 (agd): rebase on mesa master, split pci ids to
separate commit

Signed-off-by: Samuel Li 
---
 src/gallium/drivers/radeon/r600_pipe_common.c | 2 ++
 src/gallium/drivers/radeon/radeon_winsys.h| 1 +
 src/gallium/drivers/radeonsi/si_state.c   | 1 +
 src/gallium/winsys/amdgpu/drm/amdgpu_id.h | 8 ++--
 src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 6 +-
 5 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 7ac94ca..6dc27b3 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -416,6 +416,7 @@ static const char* r600_get_chip_name(struct 
r600_common_screen *rscreen)
case CHIP_ICELAND: return "AMD ICELAND";
case CHIP_CARRIZO: return "AMD CARRIZO";
case CHIP_FIJI: return "AMD FIJI";
+   case CHIP_STONEY: return "AMD STONEY";
default: return "AMD unknown";
}
 }
@@ -540,6 +541,7 @@ const char *r600_get_llvm_processor_name(enum radeon_family 
family)
case CHIP_ICELAND: return "iceland";
case CHIP_CARRIZO: return "carrizo";
case CHIP_FIJI: return "fiji";
+   case CHIP_STONEY: return "stoney";
default: return "";
}
 }
diff --git a/src/gallium/drivers/radeon/radeon_winsys.h 
b/src/gallium/drivers/radeon/radeon_winsys.h
index b91e1ad..5f13c1e 100644
--- a/src/gallium/drivers/radeon/radeon_winsys.h
+++ b/src/gallium/drivers/radeon/radeon_winsys.h
@@ -137,6 +137,7 @@ enum radeon_family {
 CHIP_ICELAND,
 CHIP_CARRIZO,
 CHIP_FIJI,
+CHIP_STONEY,
 CHIP_LAST,
 };
 
diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 243bdc6..a71ff49 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3336,6 +3336,7 @@ static void si_init_config(struct si_context *sctx)
break;
case CHIP_KABINI:
case CHIP_MULLINS:
+   case CHIP_STONEY:
raster_config = 0x;
raster_config_1 = 0x;
break;
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_id.h 
b/src/gallium/winsys/amdgpu/drm/amdgpu_id.h
index 8882c41..90fe0cd 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_id.h
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_id.h
@@ -151,11 +151,15 @@ enum {
 
 /* CZ specific rev IDs */
 enum {
-   CZ_CARRIZO_A0  = 0x01,
+   CARRIZO_A0   = 0x01,
+STONEY_A0= 0x61,
CZ_UNKNOWN  = 0xFF
 };
 
 #define ASICREV_IS_CARRIZO(eChipRev) \
-   (eChipRev >= CARRIZO_A0)
+   ((eChipRev >= CARRIZO_A0) && (eChipRev < STONEY_A0))
+
+#define ASICREV_IS_STONEY(eChipRev) \
+   ((eChipRev >= STONEY_A0) && (eChipRev < CZ_UNKNOWN))
 
 #endif /* AMDGPU_ID_H */
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
index c877249..32cd9d9 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
@@ -226,7 +226,11 @@ static boolean do_winsys_init(struct amdgpu_winsys *ws)
   break;
case CHIP_CARRIZO:
   ws->family = FAMILY_CZ;
-  ws->rev_id = CZ_CARRIZO_A0;
+  ws->rev_id = CARRIZO_A0;
+  break;
+   case CHIP_STONEY:
+  ws->family = FAMILY_CZ;
+  ws->rev_id = STONEY_A0;
   break;
case CHIP_FIJI:
   ws->family = FAMILY_VI;
-- 
1.8.3.1

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

[Mesa-dev] [PATCH 2/2] radeonsi: add Stoney pci ids

2015-10-22 Thread Alex Deucher 
From: Samuel Li 

Signed-off-by: Samuel Li 
---
 include/pci_ids/radeonsi_pci_ids.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/pci_ids/radeonsi_pci_ids.h 
b/include/pci_ids/radeonsi_pci_ids.h
index 52eada1..bcf15a1 100644
--- a/include/pci_ids/radeonsi_pci_ids.h
+++ b/include/pci_ids/radeonsi_pci_ids.h
@@ -181,3 +181,5 @@ CHIPSET(0x9876, CARRIZO_, CARRIZO)
 CHIPSET(0x9877, CARRIZO_, CARRIZO)
 
 CHIPSET(0x7300, FIJI_, FIJI)
+
+CHIPSET(0x98E4, STONEY_, STONEY)
-- 
1.8.3.1

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

[Mesa-dev] [PATCH] radeon/uvd: don't expose HEVC on old UVD hw

2015-10-22 Thread Alex Deucher 
The section for UVD 2 and older was not updated
when HEVC support was added. Reported by Kano
on irc.

Signed-off-by: Alex Deucher 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/radeon/radeon_video.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/radeon_video.c 
b/src/gallium/drivers/radeon/radeon_video.c
index 3a1834b..722f446 100644
--- a/src/gallium/drivers/radeon/radeon_video.c
+++ b/src/gallium/drivers/radeon/radeon_video.c
@@ -237,8 +237,9 @@ int rvid_get_video_param(struct pipe_screen *screen,
enum pipe_video_format codec = u_reduce_video_profile(profile);
switch (param) {
case PIPE_VIDEO_CAP_SUPPORTED:
-   /* no support for MPEG4 */
+   /* no support for MPEG4, HEVC */
return codec != PIPE_VIDEO_FORMAT_MPEG4 &&
+  codec != PIPE_VIDEO_FORMAT_HEVC &&
   /* FIXME: VC-1 simple/main profile is broken */
   profile != PIPE_VIDEO_PROFILE_VC1_SIMPLE &&
   profile != PIPE_VIDEO_PROFILE_VC1_MAIN;
-- 
1.8.3.1

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

[Mesa-dev] [PATCH] radeon/uvd: don't expose HEVC on old UVD hw (v2)

2015-10-22 Thread Alex Deucher 
The section for UVD 2 and older was not updated
when HEVC support was added. Reported by Kano
on irc.

v2: integrate the UVD2 and older checks into the
main switch statement.

Signed-off-by: Alex Deucher 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/radeon/radeon_video.c | 46 ---
 1 file changed, 17 insertions(+), 29 deletions(-)

diff --git a/src/gallium/drivers/radeon/radeon_video.c 
b/src/gallium/drivers/radeon/radeon_video.c
index 3a1834b..a874270 100644
--- a/src/gallium/drivers/radeon/radeon_video.c
+++ b/src/gallium/drivers/radeon/radeon_video.c
@@ -205,6 +205,7 @@ int rvid_get_video_param(struct pipe_screen *screen,
 enum pipe_video_cap param)
 {
struct r600_common_screen *rscreen = (struct r600_common_screen 
*)screen;
+   enum pipe_video_format codec = u_reduce_video_profile(profile);
 
if (entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
switch (param) {
@@ -232,34 +233,17 @@ int rvid_get_video_param(struct pipe_screen *screen,
}
}
 
-   /* UVD 2.x limits */
-   if (rscreen->family < CHIP_PALM) {
-   enum pipe_video_format codec = u_reduce_video_profile(profile);
-   switch (param) {
-   case PIPE_VIDEO_CAP_SUPPORTED:
-   /* no support for MPEG4 */
-   return codec != PIPE_VIDEO_FORMAT_MPEG4 &&
-  /* FIXME: VC-1 simple/main profile is broken */
-  profile != PIPE_VIDEO_PROFILE_VC1_SIMPLE &&
-  profile != PIPE_VIDEO_PROFILE_VC1_MAIN;
-   case PIPE_VIDEO_CAP_PREFERS_INTERLACED:
-   case PIPE_VIDEO_CAP_SUPPORTS_INTERLACED:
-   /* MPEG2 only with shaders and no support for
-  interlacing on R6xx style UVD */
-   return codec != PIPE_VIDEO_FORMAT_MPEG12 &&
-  rscreen->family > CHIP_RV770;
-   default:
-   break;
-   }
-   }
-
switch (param) {
case PIPE_VIDEO_CAP_SUPPORTED:
-   switch (u_reduce_video_profile(profile)) {
+   switch (codec) {
case PIPE_VIDEO_FORMAT_MPEG12:
case PIPE_VIDEO_FORMAT_MPEG4:
case PIPE_VIDEO_FORMAT_MPEG4_AVC:
-   return entrypoint != PIPE_VIDEO_ENTRYPOINT_ENCODE;
+   if (rscreen->family < CHIP_PALM)
+   /* no support for MPEG4 */
+   return codec != PIPE_VIDEO_FORMAT_MPEG4;
+   else
+   return entrypoint != 
PIPE_VIDEO_ENTRYPOINT_ENCODE;
case PIPE_VIDEO_FORMAT_VC1:
/* FIXME: VC-1 simple/main profile is broken */
return profile == PIPE_VIDEO_PROFILE_VC1_ADVANCED &&
@@ -280,13 +264,17 @@ int rvid_get_video_param(struct pipe_screen *screen,
case PIPE_VIDEO_CAP_PREFERED_FORMAT:
return PIPE_FORMAT_NV12;
case PIPE_VIDEO_CAP_PREFERS_INTERLACED:
-   if (u_reduce_video_profile(profile) == PIPE_VIDEO_FORMAT_HEVC)
-   return false; //The hardware doesn't support interlaced 
HEVC.
-   return true;
case PIPE_VIDEO_CAP_SUPPORTS_INTERLACED:
-   if (u_reduce_video_profile(profile) == PIPE_VIDEO_FORMAT_HEVC)
-   return false; //The hardware doesn't support interlaced 
HEVC.
-   return true;
+   if (rscreen->family < CHIP_PALM) {
+   /* MPEG2 only with shaders and no support for
+  interlacing on R6xx style UVD */
+   return codec != PIPE_VIDEO_FORMAT_MPEG12 &&
+  rscreen->family > CHIP_RV770;
+   } else {
+   if (u_reduce_video_profile(profile) == 
PIPE_VIDEO_FORMAT_HEVC)
+   return false; //The hardware doesn't support 
interlaced HEVC.
+   return true;
+   }
case PIPE_VIDEO_CAP_SUPPORTS_PROGRESSIVE:
return true;
case PIPE_VIDEO_CAP_MAX_LEVEL:
-- 
1.8.3.1

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

[Mesa-dev] [PATCH] radeon/uvd: don't expose HEVC on old UVD hw (v3)

2015-10-22 Thread Alex Deucher 
The section for UVD 2 and older was not updated
when HEVC support was added. Reported by Kano
on irc.

v2: integrate the UVD2 and older checks into the
main switch statement.
v3: handle encode checking as well.  Encode is
already checked in the top case statement, so
drop encode checks in the lower case statement.

Signed-off-by: Alex Deucher 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/radeon/radeon_video.c | 50 +++
 1 file changed, 18 insertions(+), 32 deletions(-)

diff --git a/src/gallium/drivers/radeon/radeon_video.c 
b/src/gallium/drivers/radeon/radeon_video.c
index 3a1834b..32bfc32 100644
--- a/src/gallium/drivers/radeon/radeon_video.c
+++ b/src/gallium/drivers/radeon/radeon_video.c
@@ -205,11 +205,12 @@ int rvid_get_video_param(struct pipe_screen *screen,
 enum pipe_video_cap param)
 {
struct r600_common_screen *rscreen = (struct r600_common_screen 
*)screen;
+   enum pipe_video_format codec = u_reduce_video_profile(profile);
 
if (entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
switch (param) {
case PIPE_VIDEO_CAP_SUPPORTED:
-   return u_reduce_video_profile(profile) == 
PIPE_VIDEO_FORMAT_MPEG4_AVC &&
+   return codec == PIPE_VIDEO_FORMAT_MPEG4_AVC &&
rvce_is_fw_version_supported(rscreen);
case PIPE_VIDEO_CAP_NPOT_TEXTURES:
return 1;
@@ -232,38 +233,19 @@ int rvid_get_video_param(struct pipe_screen *screen,
}
}
 
-   /* UVD 2.x limits */
-   if (rscreen->family < CHIP_PALM) {
-   enum pipe_video_format codec = u_reduce_video_profile(profile);
-   switch (param) {
-   case PIPE_VIDEO_CAP_SUPPORTED:
-   /* no support for MPEG4 */
-   return codec != PIPE_VIDEO_FORMAT_MPEG4 &&
-  /* FIXME: VC-1 simple/main profile is broken */
-  profile != PIPE_VIDEO_PROFILE_VC1_SIMPLE &&
-  profile != PIPE_VIDEO_PROFILE_VC1_MAIN;
-   case PIPE_VIDEO_CAP_PREFERS_INTERLACED:
-   case PIPE_VIDEO_CAP_SUPPORTS_INTERLACED:
-   /* MPEG2 only with shaders and no support for
-  interlacing on R6xx style UVD */
-   return codec != PIPE_VIDEO_FORMAT_MPEG12 &&
-  rscreen->family > CHIP_RV770;
-   default:
-   break;
-   }
-   }
-
switch (param) {
case PIPE_VIDEO_CAP_SUPPORTED:
-   switch (u_reduce_video_profile(profile)) {
+   switch (codec) {
case PIPE_VIDEO_FORMAT_MPEG12:
case PIPE_VIDEO_FORMAT_MPEG4:
case PIPE_VIDEO_FORMAT_MPEG4_AVC:
-   return entrypoint != PIPE_VIDEO_ENTRYPOINT_ENCODE;
+   if (rscreen->family < CHIP_PALM)
+   /* no support for MPEG4 */
+   return codec != PIPE_VIDEO_FORMAT_MPEG4;
+   return true;
case PIPE_VIDEO_FORMAT_VC1:
/* FIXME: VC-1 simple/main profile is broken */
-   return profile == PIPE_VIDEO_PROFILE_VC1_ADVANCED &&
-  entrypoint != PIPE_VIDEO_ENTRYPOINT_ENCODE;
+   return profile == PIPE_VIDEO_PROFILE_VC1_ADVANCED;
case PIPE_VIDEO_FORMAT_HEVC:
/* Carrizo only supports HEVC Main */
return rscreen->family >= CHIP_CARRIZO &&
@@ -280,13 +262,17 @@ int rvid_get_video_param(struct pipe_screen *screen,
case PIPE_VIDEO_CAP_PREFERED_FORMAT:
return PIPE_FORMAT_NV12;
case PIPE_VIDEO_CAP_PREFERS_INTERLACED:
-   if (u_reduce_video_profile(profile) == PIPE_VIDEO_FORMAT_HEVC)
-   return false; //The hardware doesn't support interlaced 
HEVC.
-   return true;
case PIPE_VIDEO_CAP_SUPPORTS_INTERLACED:
-   if (u_reduce_video_profile(profile) == PIPE_VIDEO_FORMAT_HEVC)
-   return false; //The hardware doesn't support interlaced 
HEVC.
-   return true;
+   if (rscreen->family < CHIP_PALM) {
+   /* MPEG2 only with shaders and no support for
+  interlacing on R6xx style UVD */
+   return codec != PIPE_VIDEO_FORMAT_MPEG12 &&
+  rscreen->family > CHIP_RV770;
+   } else {
+   if (u_reduce_video_profile(profile) == 
PIPE_VIDEO_FORMAT_HEVC)
+   return false; //The

Re: [Mesa-dev] [PATCH 1/2] radeonsi: add support for Stoney asics (v2)

2015-10-23 Thread Alex Deucher 
On Thu, Oct 22, 2015 at 10:44 PM, Michel Dänzer  wrote:
> On 23.10.2015 01:09, Alex Deucher wrote:
>> From: Samuel Li 
>>
>> v2 (agd): rebase on mesa master, split pci ids to
>> separate commit
>>
>> Signed-off-by: Samuel Li 
>
> [...]
>
>> @@ -540,6 +541,7 @@ const char *r600_get_llvm_processor_name(enum 
>> radeon_family family)
>>   case CHIP_ICELAND: return "iceland";
>>   case CHIP_CARRIZO: return "carrizo";
>>   case CHIP_FIJI: return "fiji";
>> + case CHIP_STONEY: return "stoney";
>>   default: return "";
>>   }
>>  }
>
> Do we need a fallback here for existing versions of LLVM which don't
> recognize "stoney" yet?

Is there a way to check if a particular llvm version supports a
specific processor name?  Or should we just do something like return
carrizo for llvm 3.7 and stoney for newer versions?

Alex

>
> Other than that, looks good to me.
>
>
> Patch 2 is
>
> Reviewed-by: Michel Dänzer 
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] radeonsi: add support for Stoney asics (v3)

2015-10-23 Thread Alex Deucher 
From: Samuel Li 

v2 (agd): rebase on mesa master, split pci ids to
separate commit
v3 (agd): use carrizo for llvm processor name for
llvm 3.7 and older

Signed-off-by: Samuel Li 
---
 src/gallium/drivers/radeon/r600_pipe_common.c | 6 ++
 src/gallium/drivers/radeon/radeon_winsys.h| 1 +
 src/gallium/drivers/radeonsi/si_state.c   | 1 +
 src/gallium/winsys/amdgpu/drm/amdgpu_id.h | 8 ++--
 src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 6 +-
 5 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 7ac94ca..4ce0c6a 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -416,6 +416,7 @@ static const char* r600_get_chip_name(struct 
r600_common_screen *rscreen)
case CHIP_ICELAND: return "AMD ICELAND";
case CHIP_CARRIZO: return "AMD CARRIZO";
case CHIP_FIJI: return "AMD FIJI";
+   case CHIP_STONEY: return "AMD STONEY";
default: return "AMD unknown";
}
 }
@@ -540,6 +541,11 @@ const char *r600_get_llvm_processor_name(enum 
radeon_family family)
case CHIP_ICELAND: return "iceland";
case CHIP_CARRIZO: return "carrizo";
case CHIP_FIJI: return "fiji";
+#if HAVE_LLVM <= 0x0307
+   case CHIP_STONEY: return "carrizo";
+#else
+   case CHIP_STONEY: return "stoney";
+#endif
default: return "";
}
 }
diff --git a/src/gallium/drivers/radeon/radeon_winsys.h 
b/src/gallium/drivers/radeon/radeon_winsys.h
index b91e1ad..5f13c1e 100644
--- a/src/gallium/drivers/radeon/radeon_winsys.h
+++ b/src/gallium/drivers/radeon/radeon_winsys.h
@@ -137,6 +137,7 @@ enum radeon_family {
 CHIP_ICELAND,
 CHIP_CARRIZO,
 CHIP_FIJI,
+CHIP_STONEY,
 CHIP_LAST,
 };
 
diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 243bdc6..a71ff49 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3336,6 +3336,7 @@ static void si_init_config(struct si_context *sctx)
break;
case CHIP_KABINI:
case CHIP_MULLINS:
+   case CHIP_STONEY:
raster_config = 0x;
raster_config_1 = 0x;
break;
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_id.h 
b/src/gallium/winsys/amdgpu/drm/amdgpu_id.h
index 8882c41..90fe0cd 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_id.h
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_id.h
@@ -151,11 +151,15 @@ enum {
 
 /* CZ specific rev IDs */
 enum {
-   CZ_CARRIZO_A0  = 0x01,
+   CARRIZO_A0   = 0x01,
+STONEY_A0= 0x61,
CZ_UNKNOWN  = 0xFF
 };
 
 #define ASICREV_IS_CARRIZO(eChipRev) \
-   (eChipRev >= CARRIZO_A0)
+   ((eChipRev >= CARRIZO_A0) && (eChipRev < STONEY_A0))
+
+#define ASICREV_IS_STONEY(eChipRev) \
+   ((eChipRev >= STONEY_A0) && (eChipRev < CZ_UNKNOWN))
 
 #endif /* AMDGPU_ID_H */
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
index c877249..32cd9d9 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
@@ -226,7 +226,11 @@ static boolean do_winsys_init(struct amdgpu_winsys *ws)
   break;
case CHIP_CARRIZO:
   ws->family = FAMILY_CZ;
-  ws->rev_id = CZ_CARRIZO_A0;
+  ws->rev_id = CARRIZO_A0;
+  break;
+   case CHIP_STONEY:
+  ws->family = FAMILY_CZ;
+  ws->rev_id = STONEY_A0;
   break;
case CHIP_FIJI:
   ws->family = FAMILY_VI;
-- 
1.8.3.1

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

[Mesa-dev] [PATCH] radeonsi: add Stoney to si_init_gs_info()

2015-10-23 Thread Alex Deucher 
This patch was originally written before stoney support
was merged.  Add stoney.

Signed-off-by: Alex Deucher 
---
 src/gallium/drivers/radeonsi/si_pipe.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index e653799..047bbf4 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -586,6 +586,7 @@ static bool si_init_gs_info(struct si_screen *sscreen)
case CHIP_MULLINS:
case CHIP_ICELAND:
case CHIP_CARRIZO:
+   case CHIP_STONEY:
sscreen->gs_table_depth = 16;
return true;
case CHIP_TAHITI:
-- 
1.8.3.1

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

[Mesa-dev] [PATCH] AMDGPU: add stoney support

2015-10-27 Thread Alex Deucher 
Signed-off-by: Alex Deucher 
---
 lib/Target/AMDGPU/Processors.td | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/Target/AMDGPU/Processors.td b/lib/Target/AMDGPU/Processors.td
index d9a0723..a1584a2 100644
--- a/lib/Target/AMDGPU/Processors.td
+++ b/lib/Target/AMDGPU/Processors.td
@@ -142,3 +142,7 @@ def : ProcessorModel<"carrizo", SIQuarterSpeedModel,
 def : ProcessorModel<"fiji", SIQuarterSpeedModel,
   [FeatureVolcanicIslands, FeatureISAVersion8_0_1]
 >;
+
+def : ProcessorModel<"stoney", SIQuarterSpeedModel,
+  [FeatureVolcanicIslands, FeatureISAVersion8_0_1]
+>;
-- 
1.8.3.1

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

Re: [Mesa-dev] [PATCH] radeonsi: add basic glClearBufferSubData acceleration

2015-11-03 Thread Alex Deucher 
On Tue, Nov 3, 2015 at 6:47 PM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> ---
>  src/gallium/drivers/radeonsi/si_blit.c | 55 
> ++
>  1 file changed, 55 insertions(+)
>
> diff --git a/src/gallium/drivers/radeonsi/si_blit.c 
> b/src/gallium/drivers/radeonsi/si_blit.c
> index fce014a..e934146 100644
> --- a/src/gallium/drivers/radeonsi/si_blit.c
> +++ b/src/gallium/drivers/radeonsi/si_blit.c
> @@ -731,9 +731,64 @@ static void si_flush_resource(struct pipe_context *ctx,
> }
>  }
>
> +static void si_pipe_clear_buffer(struct pipe_context *ctx,
> +struct pipe_resource *dst,
> +unsigned offset, unsigned size,
> +const void *clear_value,
> +int clear_value_size)
> +{
> +   struct si_context *sctx = (struct si_context*)ctx;
> +   const uint32_t *u32 = clear_value;
> +   unsigned i;
> +   bool clear_value_fits_dword = true;
> +   uint8_t *map;
> +
> +   if (clear_value_size > 4)
> +   for (i = 1; i < clear_value_size / 4; i++)
> +   if (u32[0] != u32[i]) {
> +   clear_value_fits_dword = false;
> +   break;
> +   }
> +
> +   /* Use CP DMA for the simple case. */
> +   if (offset % 4 == 0 && size % 4 == 0 && clear_value_fits_dword) {
> +   uint32_t value = u32[0];
> +
> +   switch (clear_value_size) {
> +   case 1:
> +   value &= 0xff;
> +   value |= (value << 8) | (value << 16) | (value << 24);
> +   break;
> +   case 2:
> +   value &= 0x;
> +   value |= value << 16;
> +   break;
> +   }
> +
> +   sctx->b.clear_buffer(ctx, dst, offset, size, value, false);
> +   return;
> +   }
> +
> +   /* TODO: use a compute shader for other cases. */

What about using SDMA?  It supports byte aligned constant fills at
least on CIK+.

Alex


> +
> +   /* Software fallback. */
> +   map = r600_buffer_map_sync_with_rings(&sctx->b, r600_resource(dst),
> + PIPE_TRANSFER_WRITE);
> +   if (!map)
> +   return;
> +
> +   map += offset;
> +   size /= clear_value_size;
> +   for (i = 0; i < size; i++) {
> +   memcpy(map, clear_value, clear_value_size);
> +   map += clear_value_size;
> +   }
> +}
> +
>  void si_init_blit_functions(struct si_context *sctx)
>  {
> sctx->b.b.clear = si_clear;
> +   sctx->b.b.clear_buffer = si_pipe_clear_buffer;
> sctx->b.b.clear_render_target = si_clear_render_target;
> sctx->b.b.clear_depth_stencil = si_clear_depth_stencil;
> sctx->b.b.resource_copy_region = si_resource_copy_region;
> --
> 2.1.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: add register definitions for Stoney

2015-11-04 Thread Alex Deucher 
On Tue, Nov 3, 2015 at 6:46 PM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> There are a few non-stoney changes too.

Reviewed-by: Alex Deucher 

> ---
>  src/gallium/drivers/radeonsi/sid.h | 322 
> +
>  1 file changed, 322 insertions(+)
>
> diff --git a/src/gallium/drivers/radeonsi/sid.h 
> b/src/gallium/drivers/radeonsi/sid.h
> index 49d8e2c..3a5101a 100644
> --- a/src/gallium/drivers/radeonsi/sid.h
> +++ b/src/gallium/drivers/radeonsi/sid.h
> @@ -3608,6 +3608,9 @@
>  #define   S_00B854_WAVES_PER_SH(x)(((x) 
> & 0x3F) << 0) /* mask is 0x3FF on CIK */
>  #define   G_00B854_WAVES_PER_SH(x)(((x) 
> >> 0) & 0x3F) /* mask is 0x3FF on CIK */
>  #define   C_00B854_WAVES_PER_SH   
> 0xFFC0 /* mask is 0x3FF on CIK */
> +#define   S_00B854_WAVES_PER_SH_CIK(x)(((x) 
> & 0x3FF) << 0)
> +#define   G_00B854_WAVES_PER_SH_CIK(x)(((x) 
> >> 0) & 0x3FF)
> +#define   C_00B854_WAVES_PER_SH_CIK   
> 0xFC00
>  #define   S_00B854_TG_PER_CU(x)   (((x) 
> & 0x0F) << 12)
>  #define   G_00B854_TG_PER_CU(x)   (((x) 
> >> 12) & 0x0F)
>  #define   C_00B854_TG_PER_CU  
> 0x0FFF
> @@ -5211,6 +5214,296 @@
>  #define V_028714_SPI_SHADER_UINT16_ABGR 0x07
>  #define V_028714_SPI_SHADER_SINT16_ABGR 0x08
>  #define V_028714_SPI_SHADER_32_ABGR 0x09
> +/* Stoney */
> +#define R_028754_SX_PS_DOWNCONVERT  
> 0x028754
> +#define   S_028754_MRT0(x)(((x) 
> & 0x0F) << 0)
> +#define   G_028754_MRT0(x)(((x) 
> >> 0) & 0x0F)
> +#define   C_028754_MRT0   
> 0xFFF0
> +#define V_028754_SX_RT_EXPORT_NO_CONVERSION  
>   0
> +#define V_028754_SX_RT_EXPORT_32_R 1
> +#define V_028754_SX_RT_EXPORT_32_A 2
> +#define V_028754_SX_RT_EXPORT_10_11_11 3
> +#define V_028754_SX_RT_EXPORT_2_10_10_10   4
> +#define V_028754_SX_RT_EXPORT_8_8_8_8  5
> +#define V_028754_SX_RT_EXPORT_5_6_5  
>   6
> +#define V_028754_SX_RT_EXPORT_1_5_5_5  7
> +#define V_028754_SX_RT_EXPORT_4_4_4_4  8
> +#define V_028754_SX_RT_EXPORT_16_16_GR 9
> +#define V_028754_SX_RT_EXPORT_16_16_AR 10
> +#define   S_028754_MRT1(x)(((x) 
> & 0x0F) << 4)
> +#define   G_028754_MRT1(x)(((x) 
> >> 4) & 0x0F)
> +#define   C_028754_MRT1   
> 0xFF0F
> +#define   S_028754_MRT2(x)(((x) 
> & 0x0F) << 8)
> +#define   G_028754_MRT2(x)(((x) 
> >> 8) & 0x0F)
> +#define   C_028754_MRT2   
> 0xF0FF
> +#define   S_028754_MRT3(x)(((x) 
> & 0x0F) << 12)
> +#define   G_028754_MRT3(x)(((x) 
> >> 12) & 0x0F)
> +#define   C_028754_MRT3   
> 0x0FFF
> +#define   S_028754_MRT4(x)(((x) 
> & 0x0F) << 16)
> +#define   G_028754_MRT4(x)(((x) 
> >> 16) & 0x0F)
> +#define   C_028754_MRT4   
> 0xFFF0
> +#define   S_028754_MRT5(x)(((x) 
> & 0x0F) << 20)
> +#define   G_028754_MRT5(x)(((x) 
> >> 20) & 0x0F)
> +#define   C_028754_MRT5   
> 0xFF0F
> +#define   S_028754_MRT6(x)(((x) 
> & 0x0F) << 24)
> +#define   G_028754_MRT6(x)(((x) 
> >> 24) &

Re: [Mesa-dev] [PATCH] radeon/uvd: add H.265/HEVC to legal notes

2015-11-06 Thread Alex Deucher 
On Fri, Nov 6, 2015 at 5:45 AM, Christian König  wrote:
> From: Christian König 
>
> Signed-off-by: Christian König 
CC stable?  Was HEVC in 11?

Reviewed-by: Alex Deucher 

> ---
>  docs/README.UVD | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/docs/README.UVD b/docs/README.UVD
> index 38ea864..b0f4b9d 100644
> --- a/docs/README.UVD
> +++ b/docs/README.UVD
> @@ -2,8 +2,8 @@ The software may implement third party technologies (e.g. 
> third party
>  libraries) that are not licensed to you by AMD and for which you may need
>  to obtain licenses from other parties.  Unless explicitly stated otherwise,
>  these third party technologies are not licensed hereunder.  Such third
> -party technologies include, but are not limited, to H.264, MPEG-2, MPEG-4,
> -AVC, and VC-1.
> +party technologies include, but are not limited, to H.264, H.265, HEVC, 
> MPEG-2,
> +MPEG-4, AVC, and VC-1.
>
>  For MPEG-2 Encoding Products ANY USE OF THIS PRODUCT IN ANY MANNER OTHER
>  THAN PERSONAL USE THAT COMPLIES WITH THE MPEG-2 STANDARD FOR ENCODING VIDEO
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] radeon/uvd: fix VC-1 simple/main profile decode v2

2015-11-06 Thread Alex Deucher 
On Fri, Nov 6, 2015 at 5:58 AM, Christian König  wrote:
> From: Boyuan Zhang 
>
> We just needed to set the extra width/height fields to get this working.
>
> v2 (chk): rebased, CC stable added, commit message added, fixed coding style
>
> Signed-off-by: Boyuan Zhang 
> Signed-off-by: Christian König 
> Cc: "10.6 11.0" 

For the series:
Reviewed-by: Alex Deucher 

> ---
>  src/gallium/drivers/radeon/radeon_uvd.c   | 6 ++
>  src/gallium/drivers/radeon/radeon_video.c | 3 +--
>  2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_uvd.c 
> b/src/gallium/drivers/radeon/radeon_uvd.c
> index 33b0136..0c643e5 100644
> --- a/src/gallium/drivers/radeon/radeon_uvd.c
> +++ b/src/gallium/drivers/radeon/radeon_uvd.c
> @@ -947,6 +947,12 @@ static void ruvd_end_frame(struct pipe_video_codec 
> *decoder,
> dec->msg->body.decode.width_in_samples = dec->base.width;
> dec->msg->body.decode.height_in_samples = dec->base.height;
>
> +   if ((picture->profile == PIPE_VIDEO_PROFILE_VC1_SIMPLE) ||
> +   (picture->profile == PIPE_VIDEO_PROFILE_VC1_MAIN)) {
> +   dec->msg->body.decode.width_in_samples = 
> align(dec->msg->body.decode.width_in_samples, 16) / 16;
> +   dec->msg->body.decode.height_in_samples = 
> align(dec->msg->body.decode.height_in_samples, 16) / 16;
> +   }
> +
> dec->msg->body.decode.dpb_size = dec->dpb.res->buf->size;
> dec->msg->body.decode.bsd_size = bs_size;
> dec->msg->body.decode.db_pitch = dec->base.width;
> diff --git a/src/gallium/drivers/radeon/radeon_video.c 
> b/src/gallium/drivers/radeon/radeon_video.c
> index 32bfc32..f56c6cf 100644
> --- a/src/gallium/drivers/radeon/radeon_video.c
> +++ b/src/gallium/drivers/radeon/radeon_video.c
> @@ -244,8 +244,7 @@ int rvid_get_video_param(struct pipe_screen *screen,
> return codec != PIPE_VIDEO_FORMAT_MPEG4;
> return true;
> case PIPE_VIDEO_FORMAT_VC1:
> -   /* FIXME: VC-1 simple/main profile is broken */
> -   return profile == PIPE_VIDEO_PROFILE_VC1_ADVANCED;
> +   return true;
> case PIPE_VIDEO_FORMAT_HEVC:
> /* Carrizo only supports HEVC Main */
> return rscreen->family >= CHIP_CARRIZO &&
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa/copyimage: allow width/height to not be multiples of block

2015-11-10 Thread Alex Deucher 
On Sun, Nov 8, 2015 at 4:50 AM, Ilia Mirkin  wrote:
> For compressed textures, the image size is not necessarily a multiple of
> the block size (e.g. the last mip levels). For example the RGTC spec
> calls out this condition as legal, saying to error only when:
>
> *  is not a multiple of four, and  plus 
> * is not equal to TEXTURE_WIDTH;
>
> While the GL_ARB_copy_image spec does not call this out explicitly, it
> appears that some games rely on this. Also it seems like it should be
> possible to copy in the last miplevels of a compressed texture's
> miptree.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92860
> Signed-off-by: Ilia Mirkin 
> Cc: mesa-sta...@lists.freedesktop.org

Seems reasonable to me.
Acked-by: Alex Deucher 

> ---
>  src/mesa/main/copyimage.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/main/copyimage.c b/src/mesa/main/copyimage.c
> index f02e842..974de7f 100644
> --- a/src/mesa/main/copyimage.c
> +++ b/src/mesa/main/copyimage.c
> @@ -62,6 +62,8 @@ prepare_target(struct gl_context *ctx, GLuint name, GLenum 
> target,
> struct gl_renderbuffer **renderbuffer,
> mesa_format *format,
> GLenum *internalFormat,
> +   GLuint *width,
> +   GLuint *height,
> const char *dbg_prefix)
>  {
> if (name == 0) {
> @@ -126,6 +128,8 @@ prepare_target(struct gl_context *ctx, GLuint name, 
> GLenum target,
>*renderbuffer = rb;
>*format = rb->Format;
>*internalFormat = rb->InternalFormat;
> +  *width = rb->Width;
> +  *height = rb->Height;
>*tex_image = NULL;
> } else {
>struct gl_texture_object *texObj = _mesa_lookup_texture(ctx, name);
> @@ -194,6 +198,8 @@ prepare_target(struct gl_context *ctx, GLuint name, 
> GLenum target,
>*renderbuffer = NULL;
>*format = (*tex_image)->TexFormat;
>*internalFormat = (*tex_image)->InternalFormat;
> +  *width = (*tex_image)->Width;
> +  *height = (*tex_image)->Height;
> }
>
> return true;
> @@ -423,6 +429,7 @@ _mesa_CopyImageSubData(GLuint srcName, GLenum srcTarget, 
> GLint srcLevel,
> struct gl_renderbuffer *srcRenderbuffer, *dstRenderbuffer;
> mesa_format srcFormat, dstFormat;
> GLenum srcIntFormat, dstIntFormat;
> +   GLuint src_w, src_h, dst_w, dst_h;
> GLuint src_bw, src_bh, dst_bw, dst_bh;
> int dstWidth, dstHeight, dstDepth;
> int i;
> @@ -445,17 +452,18 @@ _mesa_CopyImageSubData(GLuint srcName, GLenum 
> srcTarget, GLint srcLevel,
>
> if (!prepare_target(ctx, srcName, srcTarget, srcLevel, srcZ, srcDepth,
> &srcTexImage, &srcRenderbuffer, &srcFormat,
> -   &srcIntFormat, "src"))
> +   &srcIntFormat, &src_w, &src_h, "src"))
>return;
>
> if (!prepare_target(ctx, dstName, dstTarget, dstLevel, dstZ, srcDepth,
> &dstTexImage, &dstRenderbuffer, &dstFormat,
> -   &dstIntFormat, "dst"))
> +   &dstIntFormat, &dst_w, &dst_h, "dst"))
>return;
>
> _mesa_get_format_block_size(srcFormat, &src_bw, &src_bh);
> if ((srcX % src_bw != 0) || (srcY % src_bh != 0) ||
> -   (srcWidth % src_bw != 0) || (srcHeight % src_bh != 0)) {
> +   (srcWidth % src_bw != 0 && (srcX + srcWidth) != src_w) ||
> +   (srcHeight % src_bh != 0 && (srcY + srcHeight) != src_h)) {
>_mesa_error(ctx, GL_INVALID_VALUE,
>"glCopyImageSubData(unaligned src rectangle)");
>return;
> --
> 2.4.10
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/13] auxiliary/vl: winsys' galore

2015-11-10 Thread Alex Deucher 
On Mon, Nov 9, 2015 at 8:31 AM, Emil Velikov  wrote:
> Hi all,
>
> Inspired by the resent interest in alternative vl winsys, I've decided
> to rework the winsys into a traditional gallium fashion.
>
> Namely: add the destroy() and other functions into struct vl_screen.
> This will allow users (state-trackers) to call the
> vl_foo_screen_create() entry point and do the rest in a generic manner.
>
> It will also ease the introduction of other winsys (dri3, wayland,
> android anyone ?) into the module. As a follow up one can even remove
> the static linking to xcb and friends, with a dlopen/dlsym combo.
>
> The lot can be found in branch 'hello-vl' at
> https://github.com/evelikov/mesa
>
> Comments, suggestions and bikeshed wars are welcome.

Not really my area of expertise, but it seems like a nice cleanup.

Acked-by: Alex Deucher 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600: initialised PGM_RESOURCES_2 for ES/GS

2015-11-11 Thread Alex Deucher 
On Wed, Nov 11, 2015 at 5:42 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This fixes the corruption on rendering that we are seeing in
> certain geometry shaders.
>
> Signed-off-by: Dave Airlie 

Reviewed-by: Alex Deucher 

> ---
>  src/gallium/drivers/r600/evergreen_state.c | 4 
>  src/gallium/drivers/r600/evergreend.h  | 2 ++
>  2 files changed, 6 insertions(+)
>
> diff --git a/src/gallium/drivers/r600/evergreen_state.c 
> b/src/gallium/drivers/r600/evergreen_state.c
> index c6702a9..a3bbbcc 100644
> --- a/src/gallium/drivers/r600/evergreen_state.c
> +++ b/src/gallium/drivers/r600/evergreen_state.c
> @@ -2362,6 +2362,8 @@ static void cayman_init_atom_start_cs(struct 
> r600_context *rctx)
>
> r600_store_context_reg(cb, R_028848_SQ_PGM_RESOURCES_2_PS, 
> S_028848_SINGLE_ROUND(V_SQ_ROUND_NEAREST_EVEN));
> r600_store_context_reg(cb, R_028864_SQ_PGM_RESOURCES_2_VS, 
> S_028864_SINGLE_ROUND(V_SQ_ROUND_NEAREST_EVEN));
> +   r600_store_context_reg(cb, R_02887C_SQ_PGM_RESOURCES_2_GS, 
> S_028848_SINGLE_ROUND(V_SQ_ROUND_NEAREST_EVEN));
> +   r600_store_context_reg(cb, R_028894_SQ_PGM_RESOURCES_2_ES, 
> S_028848_SINGLE_ROUND(V_SQ_ROUND_NEAREST_EVEN));
> r600_store_context_reg(cb, R_0288A8_SQ_PGM_RESOURCES_FS, 0);
>
> /* to avoid GPU doing any preloading of constant from random address 
> */
> @@ -2801,6 +2803,8 @@ void evergreen_init_atom_start_cs(struct r600_context 
> *rctx)
>
> r600_store_context_reg(cb, R_028848_SQ_PGM_RESOURCES_2_PS, 
> S_028848_SINGLE_ROUND(V_SQ_ROUND_NEAREST_EVEN));
> r600_store_context_reg(cb, R_028864_SQ_PGM_RESOURCES_2_VS, 
> S_028864_SINGLE_ROUND(V_SQ_ROUND_NEAREST_EVEN));
> +   r600_store_context_reg(cb, R_02887C_SQ_PGM_RESOURCES_2_GS, 
> S_028848_SINGLE_ROUND(V_SQ_ROUND_NEAREST_EVEN));
> +   r600_store_context_reg(cb, R_028894_SQ_PGM_RESOURCES_2_ES, 
> S_028848_SINGLE_ROUND(V_SQ_ROUND_NEAREST_EVEN));
> r600_store_context_reg(cb, R_0288A8_SQ_PGM_RESOURCES_FS, 0);
>
> /* to avoid GPU doing any preloading of constant from random address 
> */
> diff --git a/src/gallium/drivers/r600/evergreend.h 
> b/src/gallium/drivers/r600/evergreend.h
> index 937ffcb..cf8906c 100644
> --- a/src/gallium/drivers/r600/evergreend.h
> +++ b/src/gallium/drivers/r600/evergreend.h
> @@ -1497,6 +1497,7 @@
>  #define   S_028878_UNCACHED_FIRST_INST(x)  (((x) & 0x1) << 28)
>  #define   G_028878_UNCACHED_FIRST_INST(x)  (((x) >> 28) & 0x1)
>  #define   C_028878_UNCACHED_FIRST_INST 0xEFFF
> +#define R_02887C_SQ_PGM_RESOURCES_2_GS 0x02887C
>
>  #define R_028890_SQ_PGM_RESOURCES_ES 0x028890
>  #define   S_028890_NUM_GPRS(x) (((x) & 0xFF) << 0)
> @@ -1511,6 +1512,7 @@
>  #define   S_028890_UNCACHED_FIRST_INST(x)  (((x) & 0x1) << 28)
>  #define   G_028890_UNCACHED_FIRST_INST(x)  (((x) >> 28) & 0x1)
>  #define   C_028890_UNCACHED_FIRST_INST 0xEFFF
> +#define R_028894_SQ_PGM_RESOURCES_2_ES 0x028894
>
>  #define R_028864_SQ_PGM_RESOURCES_2_VS   0x028864
>  #define   S_028864_SINGLE_ROUND(x) (((x) & 0x3) << 0)
> --
> 2.1.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radeonsi: enable optimal raster config setting for fiji

2015-11-13 Thread Alex Deucher 
Requires proper kernel tiling configurarion so check the tiling
config registers.

Signed-off-by: Alex Deucher 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/radeonsi/si_state.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 384c8e2..ff4d612 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3278,6 +3278,7 @@ si_write_harvested_raster_configs(struct si_context *sctx,
 
 static void si_init_config(struct si_context *sctx)
 {
+   struct si_screen *sscreen = sctx->screen;
unsigned num_rb = MIN2(sctx->screen->b.info.r600_num_backends, 16);
unsigned rb_mask = sctx->screen->b.info.si_backend_enabled_mask;
unsigned raster_config, raster_config_1;
@@ -3348,9 +3349,14 @@ static void si_init_config(struct si_context *sctx)
raster_config_1 = 0x002e;
break;
case CHIP_FIJI:
-   /* Fiji should be same as Hawaii, but that causes corruption in 
some cases */
-   raster_config = 0x1612; /* 0x3a00161a */
-   raster_config_1 = 0x002a; /* 0x002e */
+   if (sscreen->b.info.cik_macrotile_mode_array[0] == 0x00e4) {
+   /* old kernels with old tiling config */
+   raster_config = 0x1612;
+   raster_config_1 = 0x002a;
+   } else {
+   raster_config = 0x3a00161a;
+   raster_config_1 = 0x002e;
+   }
break;
case CHIP_TONGA:
raster_config = 0x1612;
-- 
1.8.3.1

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

[Mesa-dev] [PATCH] radeonsi: use proper GRBM_GFX_INDEX offset for CI+

2015-11-13 Thread Alex Deucher 
The offset is different on CI and newer.

Signed-off-by: Alex Deucher 
---
 src/gallium/drivers/radeonsi/si_state.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index ff4d612..14763f7 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3259,21 +3259,29 @@ si_write_harvested_raster_configs(struct si_context 
*sctx,
}
}
 
-   /* GRBM_GFX_INDEX is privileged on VI */
-   if (sctx->b.chip_class <= CIK)
+   /* GRBM_GFX_INDEX has a different offset on SI and CI+ */
+   if (sctx->b.chip_class < CIK)
si_pm4_set_reg(pm4, GRBM_GFX_INDEX,
   SE_INDEX(se) | SH_BROADCAST_WRITES |
   INSTANCE_BROADCAST_WRITES);
+   else
+   si_pm4_set_reg(pm4, R_030800_GRBM_GFX_INDEX,
+  S_030800_SE_INDEX(se) | 
S_030800_SH_BROADCAST_WRITES(1) |
+  S_030800_INSTANCE_BROADCAST_WRITES(1));
si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG, 
raster_config_se);
if (sctx->b.chip_class >= CIK)
si_pm4_set_reg(pm4, R_028354_PA_SC_RASTER_CONFIG_1, 
raster_config_1);
}
 
-   /* GRBM_GFX_INDEX is privileged on VI */
-   if (sctx->b.chip_class <= CIK)
+   /* GRBM_GFX_INDEX has a different offset on SI and CI+ */
+   if (sctx->b.chip_class < CIK)
si_pm4_set_reg(pm4, GRBM_GFX_INDEX,
   SE_BROADCAST_WRITES | SH_BROADCAST_WRITES |
   INSTANCE_BROADCAST_WRITES);
+   else
+   si_pm4_set_reg(pm4, R_030800_GRBM_GFX_INDEX,
+  S_030800_SE_BROADCAST_WRITES(1) | 
S_030800_SH_BROADCAST_WRITES(1) |
+  S_030800_INSTANCE_BROADCAST_WRITES(1));
 }
 
 static void si_init_config(struct si_context *sctx)
-- 
1.8.3.1

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

[Mesa-dev] [PATCH] radeonsi: enable optimal raster config setting for fiji (v2)

2015-11-13 Thread Alex Deucher 
Requires proper kernel tiling configurarion so check the tiling
config registers.

v2: send the right version of the patch

Signed-off-by: Alex Deucher 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/radeonsi/si_state.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 1b5ea35..f8168d3 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3286,6 +3286,7 @@ si_write_harvested_raster_configs(struct si_context *sctx,
 
 static void si_init_config(struct si_context *sctx)
 {
+   struct si_screen *sscreen = sctx->screen;
unsigned num_rb = MIN2(sctx->screen->b.info.r600_num_backends, 16);
unsigned rb_mask = sctx->screen->b.info.si_backend_enabled_mask;
unsigned raster_config, raster_config_1;
@@ -3356,9 +3357,14 @@ static void si_init_config(struct si_context *sctx)
raster_config_1 = 0x002e;
break;
case CHIP_FIJI:
-   /* Fiji should be same as Hawaii, but that causes corruption in 
some cases */
-   raster_config = 0x1612; /* 0x3a00161a */
-   raster_config_1 = 0x002a; /* 0x002e */
+   if (sscreen->b.info.cik_macrotile_mode_array[0] == 0x00e8) {
+   /* old kernels with old tiling config */
+   raster_config = 0x1612;
+   raster_config_1 = 0x002a;
+   } else {
+   raster_config = 0x3a00161a;
+   raster_config_1 = 0x002e;
+   }
break;
case CHIP_TONGA:
raster_config = 0x1612;
-- 
1.8.3.1

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

Re: [Mesa-dev] [PATCH] gallium/docs: fix docs wrt ARL/ARR/FLR

2015-01-29 Thread Alex Deucher 
On Thu, Jan 29, 2015 at 2:40 PM,   wrote:
> From: Roland Scheidegger 
>
> since the address reg holds integer values, ARL/ARR do an implicit 
> float-to-int
> conversion, so clarify that. Thus it is also incorrect to say that FLR really
> does the same as ARL.

Reviewed-by: Alex Deucher 

> ---
>  src/gallium/docs/source/tgsi.rst | 18 --
>  1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/docs/source/tgsi.rst 
> b/src/gallium/docs/source/tgsi.rst
> index ff322e8..84b0ed6 100644
> --- a/src/gallium/docs/source/tgsi.rst
> +++ b/src/gallium/docs/source/tgsi.rst
> @@ -48,13 +48,13 @@ used.
>
>  .. math::
>
> -  dst.x = \lfloor src.x\rfloor
> +  dst.x = (int) \lfloor src.x\rfloor
>
> -  dst.y = \lfloor src.y\rfloor
> +  dst.y = (int) \lfloor src.y\rfloor
>
> -  dst.z = \lfloor src.z\rfloor
> +  dst.z = (int) \lfloor src.z\rfloor
>
> -  dst.w = \lfloor src.w\rfloor
> +  dst.w = (int) \lfloor src.w\rfloor
>
>
>  .. opcode:: MOV - Move
> @@ -313,8 +313,6 @@ This instruction replicates its result.
>
>  .. opcode:: FLR - Floor
>
> -This is identical to :opcode:`ARL`.
> -
>  .. math::
>
>dst.x = \lfloor src.x\rfloor
> @@ -637,13 +635,13 @@ This instruction replicates its result.
>
>  .. math::
>
> -  dst.x = round(src.x)
> +  dst.x = (int) round(src.x)
>
> -  dst.y = round(src.y)
> +  dst.y = (int) round(src.y)
>
> -  dst.z = round(src.z)
> +  dst.z = (int) round(src.z)
>
> -  dst.w = round(src.w)
> +  dst.w = (int) round(src.w)
>
>
>  .. opcode:: SSG - Set Sign
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Removing out of date Mesa wiki pages

2015-02-05 Thread Alex Deucher 
On Thu, Feb 5, 2015 at 2:47 PM, Benjamin Bellec  wrote:
> And what about removing the "RadeonProgram" page [1] ?
>
> From my point of view, this page depicts a wrong picture of the Radeon Mesa
> driver. While I'm pretty sure most of the current and past games runs fine
> today with r300g/r600g/radeonsi, this is not what one could think at a first
> look when reading this page. Moreover, the table stops to the Radeon HD6000
> series.
>
> This page is useful if user can update their input, but the wiki access is
> restricted.
>
> [1] http://xorg.freedesktop.org/wiki/RadeonProgram/

I'm fine with removing it.  It's mostly out of date anyway.

Alex

>
>
> 2015-01-14 9:52 GMT+01:00 Kenneth Graunke :
>>
>> On Wednesday, January 14, 2015 04:27:30 PM Timothy Arceri wrote:
>> > Hi all,
>> >
>> > Not sure how many of you have come across the webpage "Major Linux
>> > Problems on the Desktop 2015 edition" [1]. Accurate or not it seems to
>> > be getting a bit of attention. Anyway Mesa gets a bit of a bashing in
>> > there although most of the information the author uses to backup their
>> > claims are out of date Phoronix articles and this Mesa wiki page [2].
>> >
>> > Anyway getting to my point maybe the wiki page should be removed as it
>> > seems its no longer useful and is being used to spread misinformation.
>> >
>> > Tim
>> >
>> > [1]
>> >
>> > http://linuxfonts.narod.ru/why.linux.is.not.ready.for.the.desktop.current.html
>> > [2] http://dri.freedesktop.org/wiki/MissingFunctionality/
>>
>> Hooray for fact checking!  I'm all for replacing that page - it hasn't
>> been
>> useful in years.  How about replacing it with links to other places:
>>
>> Ilia's glxinfo site - shows accurate information about what specific GPUs
>> support in actual Mesa releases:
>> http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html
>>
>> Current feature development status:
>> http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt
>>
>> which can be helpfully visualized at:
>> http://mesamatrix.net/
>>
>> --Ken
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] winsys/radeon: add user pointer support

2015-02-09 Thread Alex Deucher 
On Mon, Feb 9, 2015 at 7:29 PM, Marek Olšák  wrote:
> Hi Christian,
>
> What hardware is this supported on? SI and later? Or even r600? r300?

Theoretically r300 and newer hardware, however, the kernel currently
only allows it on r600 and newer since we never tested it on r300
class hardware.

Alex

>
> Thanks,
>
> Marek
>
> On Thu, Feb 5, 2015 at 6:34 PM, Christian König  
> wrote:
>> From: Christian König 
>>
>> Signed-off-by: Christian König 
>> ---
>>  src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 102 
>> ++
>>  src/gallium/winsys/radeon/drm/radeon_winsys.h |  11 +++
>>  2 files changed, 113 insertions(+)
>>
>> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
>> b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
>> index 1ebec10..2605ca6 100644
>> --- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
>> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
>> @@ -42,6 +42,24 @@
>>  #include 
>>  #include 
>>
>> +#ifndef DRM_RADEON_GEM_USERPTR
>> +
>> +#define DRM_RADEON_GEM_USERPTR 0x2d
>> +
>> +#define RADEON_GEM_USERPTR_READONLY(1 << 0)
>> +#define RADEON_GEM_USERPTR_ANONONLY(1 << 1)
>> +#define RADEON_GEM_USERPTR_VALIDATE(1 << 2)
>> +#define RADEON_GEM_USERPTR_REGISTER(1 << 3)
>> +
>> +struct drm_radeon_gem_userptr {
>> +   uint64_taddr;
>> +   uint64_tsize;
>> +   uint32_tflags;
>> +   uint32_thandle;
>> +};
>> +
>> +#endif
>> +
>>  extern const struct pb_vtbl radeon_bo_vtbl;
>>
>>  static INLINE struct radeon_bo *radeon_bo(struct pb_buffer *bo)
>> @@ -846,6 +864,89 @@ radeon_winsys_bo_create(struct radeon_winsys *rws,
>>  return (struct pb_buffer*)buffer;
>>  }
>>
>> +static struct pb_buffer *radeon_winsys_bo_from_ptr(struct radeon_winsys 
>> *rws,
>> +   void *pointer, unsigned 
>> size)
>> +{
>> +struct radeon_drm_winsys *ws = radeon_drm_winsys(rws);
>> +struct radeon_bomgr *mgr = radeon_bomgr(ws->kman);
>> +struct drm_radeon_gem_userptr args;
>> +struct radeon_bo *bo;
>> +int r;
>> +
>> +bo = CALLOC_STRUCT(radeon_bo);
>> +if (!bo)
>> +return NULL;
>> +
>> +memset(&args, 0, sizeof(args));
>> +args.addr = (uintptr_t)pointer;
>> +args.size = size;
>> +args.flags = RADEON_GEM_USERPTR_ANONONLY |
>> +RADEON_GEM_USERPTR_VALIDATE |
>> +RADEON_GEM_USERPTR_REGISTER;
>> +if (drmCommandWriteRead(ws->fd, DRM_RADEON_GEM_USERPTR,
>> +&args, sizeof(args))) {
>> +FREE(bo);
>> +return NULL;
>> +}
>> +
>> +pipe_mutex_lock(mgr->bo_handles_mutex);
>> +
>> +/* Initialize it. */
>> +pipe_reference_init(&bo->base.reference, 1);
>> +bo->handle = args.handle;
>> +bo->base.alignment = 0;
>> +bo->base.usage = PB_USAGE_GPU_WRITE | PB_USAGE_GPU_READ;
>> +bo->base.size = size;
>> +bo->base.vtbl = &radeon_bo_vtbl;
>> +bo->mgr = mgr;
>> +bo->rws = mgr->rws;
>> +bo->va = 0;
>> +bo->initial_domain = RADEON_DOMAIN_GTT;
>> +pipe_mutex_init(bo->map_mutex);
>> +
>> +util_hash_table_set(mgr->bo_handles, (void*)(uintptr_t)bo->handle, bo);
>> +
>> +pipe_mutex_unlock(mgr->bo_handles_mutex);
>> +
>> +if (mgr->va) {
>> +struct drm_radeon_gem_va va;
>> +
>> +bo->va = radeon_bomgr_find_va(mgr, bo->base.size, 1 << 20);
>> +
>> +va.handle = bo->handle;
>> +va.operation = RADEON_VA_MAP;
>> +va.vm_id = 0;
>> +va.offset = bo->va;
>> +va.flags = RADEON_VM_PAGE_READABLE |
>> +   RADEON_VM_PAGE_WRITEABLE |
>> +   RADEON_VM_PAGE_SNOOPED;
>> +va.offset = bo->va;
>> +r = drmCommandWriteRead(ws->fd, DRM_RADEON_GEM_VA, &va, sizeof(va));
>> +if (r && va.operation == RADEON_VA_RESULT_ERROR) {
>> +fprintf(stderr, "radeon: Failed to assign virtual address 
>> space\n");
>> +radeon_bo_destroy(&bo->base);
>> +return NULL;
>> +}
>> +pipe_mutex_lock(mgr->bo_handles_mutex);
>> +if (va.operation == RADEON_VA_RESULT_VA_EXIST) {
>> +struct pb_buffer *b = &bo->base;
>> +struct radeon_bo *old_bo =
>> +util_hash_table_get(mgr->bo_vas, 
>> (void*)(uintptr_t)va.offset);
>> +
>> +pipe_mutex_unlock(mgr->bo_handles_mutex);
>> +pb_reference(&b, &old_bo->base);
>> +return b;
>> +}
>> +
>> +util_hash_table_set(mgr->bo_vas, (void*)(uintptr_t)bo->va, bo);
>> +pipe_mutex_unlock(mgr->bo_handles_mutex);
>> +}
>> +
>> +ws->allocated_gtt += align(bo->base.size, 4096);
>> +
>> +return (struct pb_buffer*)bo;
>> +}
>> +
>>  static struct pb_buffer *radeon_winsys_bo_from_handle(struct radeon_winsys 
>> *rws,
>>struct winsys_handle 
>> *whandle,
>>

[Mesa-dev] GSoC Ideas!

2015-02-11 Thread Alex Deucher 
Hi everyone!

It's that time of year again.  Time to start coming up with GSoC
ideas.  Martin and I are organizing this year's Xorg entry.  We need
to fill in our ideas page with some good possible projects for
students.  The project ideas should be something that a student could
accomplish over the summer so keep the scope focused.  Please use the
templates on
http://www.x.org/wiki/SummerOfCodeIdeas/ and update the wiki or post
the ideas on the mailing list.  Martin and I will update the page as
the ideas come in.

Thanks!

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

Re: [Mesa-dev] [PATCH 5/5] r200: Drop unused variable.

2015-02-11 Thread Alex Deucher 
On Wed, Feb 11, 2015 at 7:42 PM, Eric Anholt  wrote:
> Quiets compiler warning since e7f2f2dea5acdbd1a12ed88914e64a38a97432f0.

Reviewed-by: Alex Deucher 

> ---
>  src/mesa/drivers/dri/r200/r200_ioctl.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/r200/r200_ioctl.c 
> b/src/mesa/drivers/dri/r200/r200_ioctl.c
> index 515be92..d665c8b 100644
> --- a/src/mesa/drivers/dri/r200/r200_ioctl.c
> +++ b/src/mesa/drivers/dri/r200/r200_ioctl.c
> @@ -56,7 +56,6 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
> SOFTWARE.
>   */
>  static void r200Clear( struct gl_context *ctx, GLbitfield mask )
>  {
> -   r200ContextPtr rmesa = R200_CONTEXT(ctx);
> GLuint hwmask, swmask;
> GLuint hwbits = BUFFER_BIT_FRONT_LEFT | BUFFER_BIT_BACK_LEFT |
> BUFFER_BIT_DEPTH | BUFFER_BIT_STENCIL |
> --
> 2.1.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] opengles2: fix building without X11

2015-02-12 Thread Alex Deucher 
On Thu, Feb 12, 2015 at 8:23 AM, Emil Velikov  wrote:
> Humble ping.

Reviewed-by: Alex Deucher 

>
> On 22/01/15 18:28, Emil Velikov wrote:
>> From: Michael Olbrich 
>>
>> es2_info, es2gears_x11 and es2tri require X11, so don't build them if X11
>> is disabled.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88618
>> Reviewed-by: Emil Velikov 
>> ---
>>
>> Noticed this patch in bugzilla. Not sure how many people keep an eye on
>> it so I've decided to send it to the ML.
>>
>> -Emil
>>
>>  src/egl/opengles2/Makefile.am | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/egl/opengles2/Makefile.am b/src/egl/opengles2/Makefile.am
>> index 41c1b80..36d6059 100644
>> --- a/src/egl/opengles2/Makefile.am
>> +++ b/src/egl/opengles2/Makefile.am
>> @@ -36,10 +36,13 @@ AM_LDFLAGS = \
>>  if HAVE_EGL
>>  if HAVE_GLESV2
>>  bin_PROGRAMS = \
>> + es2gears_screen
>> +if HAVE_X11
>> +bin_PROGRAMS += \
>>   es2_info \
>> - es2gears_screen \
>>   es2gears_x11 \
>>   es2tri
>> +endif
>>  if HAVE_WAYLAND
>>  bin_PROGRAMS += es2gears_wayland
>>  endif
>>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: don't use SQC_CACHES to flush ICACHE and KCACHE on SI

2015-02-19 Thread Alex Deucher 
On Thu, Feb 19, 2015 at 7:10 AM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> This reverts 73c2b0d18c51459697d8ec194ecfc4438c98c139.
>
> It doesn't seem to be reliable. It's probably missing a wait packet or
> something, because it's just a register write and doesn't wait for anything.
> SURFACE_SYNC at least seems to wait until the flush is done. Just guessing.
>
> Let's not complicate things and revert this.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88561
>
> Cc: 10.5 

Reviewed-by: Alex Deucher 

> ---
>  src/gallium/drivers/radeonsi/si_state_draw.c | 29 
> +++-
>  1 file changed, 11 insertions(+), 18 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
> b/src/gallium/drivers/radeonsi/si_state_draw.c
> index 128ea04..511bea2 100644
> --- a/src/gallium/drivers/radeonsi/si_state_draw.c
> +++ b/src/gallium/drivers/radeonsi/si_state_draw.c
> @@ -367,24 +367,21 @@ void si_emit_cache_flush(struct r600_common_context 
> *sctx, struct r600_atom *ato
>  {
> struct radeon_winsys_cs *cs = sctx->rings.gfx.cs;
> uint32_t cp_coher_cntl = 0;
> -   uint32_t sqc_caches = 0;
> uint32_t compute =
> PKT3_SHADER_TYPE_S(!!(sctx->flags & SI_CONTEXT_FLAG_COMPUTE));
>
> /* SI has a bug that it always flushes ICACHE and KCACHE if either
> -* bit is set. An alternative way is to write SQC_CACHES. */
> -   if (sctx->chip_class == SI &&
> -   sctx->flags & BOTH_ICACHE_KCACHE &&
> -   (sctx->flags & BOTH_ICACHE_KCACHE) != BOTH_ICACHE_KCACHE) {
> -   sqc_caches =
> -   S_008C08_INST_INVALIDATE(!!(sctx->flags & 
> SI_CONTEXT_INV_ICACHE)) |
> -   S_008C08_DATA_INVALIDATE(!!(sctx->flags & 
> SI_CONTEXT_INV_KCACHE));
> -   } else {
> -   if (sctx->flags & SI_CONTEXT_INV_ICACHE)
> -   cp_coher_cntl |= S_0085F0_SH_ICACHE_ACTION_ENA(1);
> -   if (sctx->flags & SI_CONTEXT_INV_KCACHE)
> -   cp_coher_cntl |= S_0085F0_SH_KCACHE_ACTION_ENA(1);
> -   }
> +* bit is set. An alternative way is to write SQC_CACHES, but that
> +* doesn't seem to work reliably. Since the bug doesn't affect
> +* correctness (it only does more work than necessary) and
> +* the performance impact is likely negligible, there is no plan
> +* to fix it.
> +*/
> +
> +   if (sctx->flags & SI_CONTEXT_INV_ICACHE)
> +   cp_coher_cntl |= S_0085F0_SH_ICACHE_ACTION_ENA(1);
> +   if (sctx->flags & SI_CONTEXT_INV_KCACHE)
> +   cp_coher_cntl |= S_0085F0_SH_KCACHE_ACTION_ENA(1);
>
> if (sctx->flags & SI_CONTEXT_INV_TC_L1)
> cp_coher_cntl |= S_0085F0_TCL1_ACTION_ENA(1);
> @@ -451,10 +448,6 @@ void si_emit_cache_flush(struct r600_common_context 
> *sctx, struct r600_atom *ato
>  * It looks like SURFACE_SYNC flushes caches immediately and doesn't
>  * wait for any engines. This should be last.
>  */
> -   if (sqc_caches) {
> -   r600_write_config_reg(cs, R_008C08_SQC_CACHES, sqc_caches);
> -   cs->buf[cs->cdw-3] |= compute; /* set the compute bit in the 
> header */
> -   }
> if (cp_coher_cntl) {
> if (sctx->chip_class >= CIK) {
> radeon_emit(cs, PKT3(PKT3_ACQUIRE_MEM, 5, 0) | 
> compute);
> --
> 2.1.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 6/6] mesa: remove unused INLINE macro from compiler.h

2015-02-26 Thread Alex Deucher 
On Thu, Feb 26, 2015 at 12:47 PM, Brian Paul  wrote:
> We now use 'inline' everywhere in Mesa.

For the series:
Reviewed-by: Alex Deucher 

> ---
>  src/mesa/main/compiler.h | 7 ---
>  1 file changed, 7 deletions(-)
>
> diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
> index cf9a686..dd65d07 100644
> --- a/src/mesa/main/compiler.h
> +++ b/src/mesa/main/compiler.h
> @@ -91,13 +91,6 @@ extern "C" {
>  #endif
>
>
> -
> -/* XXX: Use standard `inline` keyword instead */
> -#ifndef INLINE
> -#  define INLINE inline
> -#endif
> -
> -
>  /**
>   * PUBLIC/USED macros
>   *
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl: Report correct GBM formats

2015-03-03 Thread Alex Deucher 
On Mon, Mar 2, 2015 at 9:23 AM, Tom Stellard  wrote:
> From: Daniel Stone 
>
> This fixes almost all piglit regressions when running with
> PIGLIT_PLATFORM=gbm
>
> Tom Stellard:
>   - Fix ARGB2101010 format
>
> Cc: "10.4 10.5" 

Looks reasonable to me.

Reviewed-by: Alex Deucher 

> ---
>
> I'm not sure if the commit message makes sense, I'm open to suggestions.
>
> src/egl/drivers/dri2/platform_drm.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/platform_drm.c 
> b/src/egl/drivers/dri2/platform_drm.c
> index 02e87f7..bf205be 100644
> --- a/src/egl/drivers/dri2/platform_drm.c
> +++ b/src/egl/drivers/dri2/platform_drm.c
> @@ -668,15 +668,21 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
>
> for (i = 0; dri2_dpy->driver_configs[i]; i++) {
>EGLint format, attr_list[3];
> -  unsigned int mask;
> +  unsigned int red, alpha;
>
>dri2_dpy->core->getConfigAttrib(dri2_dpy->driver_configs[i],
> -   __DRI_ATTRIB_RED_MASK, &mask);
> -  if (mask == 0x3ff0)
> +   __DRI_ATTRIB_RED_MASK, &red);
> +  dri2_dpy->core->getConfigAttrib(dri2_dpy->driver_configs[i],
> +   __DRI_ATTRIB_ALPHA_MASK, &alpha);
> +  if (red == 0x3ff0 && alpha == 0x)
>   format = GBM_FORMAT_XRGB2101010;
> -  else if (mask == 0x00ff)
> +  else if (red == 0x3ff0 && alpha == 0xc000)
> + format = GBM_FORMAT_ARGB2101010;
> +  else if (red == 0x00ff && alpha == 0x)
>   format = GBM_FORMAT_XRGB;
> -  else if (mask == 0xf800)
> +  else if (red == 0x00ff && alpha == 0xff00)
> + format = GBM_FORMAT_ARGB;
> +  else if (red == 0xf800)
>   format = GBM_FORMAT_RGB565;
>else
>   continue;
> --
> 2.0.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] gallium/radeon: add new HUD queries for monitoring the CP

2017-01-27 Thread Alex Deucher 
On Fri, Jan 27, 2017 at 1:49 PM, Marek Olšák  wrote:
> CP_STAT is only readable on amdgpu and only VI.
>

It can be added to other chips if anyone wants to send me a patch.

Alex

> It's OK to expose the queries on other chips if it simplies things
> even if they don't update.
>
> Marek
>
> On Thu, Jan 26, 2017 at 8:54 PM, Samuel Pitoiset
>  wrote:
>> There are even more counters in the CP_STAT register but I think
>> these ones are enough for now.
>>
>> Signed-off-by: Samuel Pitoiset 
>> ---
>>  src/gallium/drivers/radeon/r600_gpu_load.c| 34 
>> +++
>>  src/gallium/drivers/radeon/r600_pipe_common.h |  9 +++
>>  src/gallium/drivers/radeon/r600_query.c   | 23 +-
>>  src/gallium/drivers/radeon/r600_query.h   |  7 ++
>>  4 files changed, 72 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/drivers/radeon/r600_gpu_load.c 
>> b/src/gallium/drivers/radeon/r600_gpu_load.c
>> index 5bea6e2643..588442bebd 100644
>> --- a/src/gallium/drivers/radeon/r600_gpu_load.c
>> +++ b/src/gallium/drivers/radeon/r600_gpu_load.c
>> @@ -61,6 +61,15 @@
>>  #define SRBM_STATUS2   0x0e4c
>>  #define SDMA_BUSY(x)   (((x) >> 5) & 0x1)
>>
>> +#define CP_STAT 0x8680
>> +#define PFP_BUSY(x)(((x) >> 15) & 0x1)
>> +#define MEQ_BUSY(x)(((x) >> 16) & 0x1)
>> +#define ME_BUSY(x) (((x) >> 17) & 0x1)
>> +#define SURFACE_SYNC_BUSY(x)   (((x) >> 21) & 0x1)
>> +#define DMA_BUSY(x)(((x) >> 22) & 0x1)
>> +#define SCRATCH_RAM_BUSY(x)(((x) >> 24) & 0x1)
>> +#define CE_BUSY(x) (((x) >> 26) & 0x1)
>> +
>>  #define UPDATE_COUNTER(field, mask)\
>> do {\
>> if (mask(value))\
>> @@ -96,6 +105,17 @@ static void r600_update_mmio_counters(struct 
>> r600_common_screen *rscreen,
>> rscreen->ws->read_registers(rscreen->ws, SRBM_STATUS2, 1, &value);
>>
>> UPDATE_COUNTER(sdma, SDMA_BUSY);
>> +
>> +   /* CP_STAT */
>> +   rscreen->ws->read_registers(rscreen->ws, CP_STAT, 1, &value);
>> +
>> +   UPDATE_COUNTER(pfp, PFP_BUSY);
>> +   UPDATE_COUNTER(meq, MEQ_BUSY);
>> +   UPDATE_COUNTER(me, ME_BUSY);
>> +   UPDATE_COUNTER(surf_sync, SURFACE_SYNC_BUSY);
>> +   UPDATE_COUNTER(dma, DMA_BUSY);
>> +   UPDATE_COUNTER(scratch_ram, SCRATCH_RAM_BUSY);
>> +   UPDATE_COUNTER(ce, CE_BUSY);
>>  }
>>
>>  #undef UPDATE_COUNTER
>> @@ -221,6 +241,20 @@ static unsigned busy_index_from_type(struct 
>> r600_common_screen *rscreen,
>> return BUSY_INDEX(rscreen, cb);
>> case R600_QUERY_GPU_SDMA_BUSY:
>> return BUSY_INDEX(rscreen, sdma);
>> +   case R600_QUERY_GPU_PFP_BUSY:
>> +   return BUSY_INDEX(rscreen, pfp);
>> +   case R600_QUERY_GPU_MEQ_BUSY:
>> +   return BUSY_INDEX(rscreen, meq);
>> +   case R600_QUERY_GPU_ME_BUSY:
>> +   return BUSY_INDEX(rscreen, me);
>> +   case R600_QUERY_GPU_SURF_SYNC_BUSY:
>> +   return BUSY_INDEX(rscreen, surf_sync);
>> +   case R600_QUERY_GPU_DMA_BUSY:
>> +   return BUSY_INDEX(rscreen, dma);
>> +   case R600_QUERY_GPU_SCRATCH_RAM_BUSY:
>> +   return BUSY_INDEX(rscreen, scratch_ram);
>> +   case R600_QUERY_GPU_CE_BUSY:
>> +   return BUSY_INDEX(rscreen, ce);
>> default:
>> unreachable("invalid query type");
>> }
>> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h 
>> b/src/gallium/drivers/radeon/r600_pipe_common.h
>> index 08de238bba..a1576c49a4 100644
>> --- a/src/gallium/drivers/radeon/r600_pipe_common.h
>> +++ b/src/gallium/drivers/radeon/r600_pipe_common.h
>> @@ -377,6 +377,15 @@ union r600_mmio_counters {
>>
>> /* SRBM_STATUS2 */
>> struct r600_mmio_counter sdma;
>> +
>> +   /* CP_STAT */
>> +   struct r600_mmio_counter pfp;
>> +   struct r600_mmio_counter meq;
>> +   struct r600_mmio_counter me;
>> +   struct r600_mmio_counter surf_sync;
>> +   struct r600_mmio_counter dma;
>> +   struct r600_mmio_counter scratch_ram;
>> +   struct r600_mmio_counter ce;
>> } named;
>> unsigned array[0];
>>  };
>> diff --git a/src/gallium/drivers/radeon/r600_query.c 
>> b/src/gallium/drivers/radeon/r600_query.c
>> index ef73323bae..83c1c60211 100644
>> --- a/src/gallium/drivers/radeon/r600_query.c
>> +++ b/src/gallium/drivers/radeon/r600_query.c
>> @@ -163,6 +163,13 @@ static bool r600_query_sw_begin(struct 
>> r600_common_context *rctx,
>> case R600_QUERY_GPU_CP_BUSY:
>> case R600_QUERY_GPU_CB_BUSY:
>> case R600_QUERY_GPU_SDMA_BUSY:
>> +   case R600_QUERY_GPU_PFP_BUSY:
>> +   case R600_QUERY_GPU_MEQ_BUSY:
>> +   case R600_QUERY_GPU_M

Re: [Mesa-dev] [PATCH] drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl

2017-01-31 Thread Alex Deucher 
On Tue, Jan 31, 2017 at 5:06 PM, Emil Velikov  wrote:
> On 31 January 2017 at 15:43, Deucher, Alexander
>  wrote:
>>> -Original Message-
>>> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
>>> Of Dieter Nützel
>>> Sent: Tuesday, January 31, 2017 6:25 AM
>>> To: Michel Dänzer
>>> Cc: Alex Deucher; mesa-dev@lists.freedesktop.org; amd-
>>> g...@lists.freedesktop.org
>>> Subject: Re: [Mesa-dev] [PATCH] drm/radeon: Fix vram_size/visible values in
>>> DRM_RADEON_GEM_INFO ioctl
>>>
>>> Hello Michel,
>>>
>>> as this is for radeon, do you think this could/should fix
>>> the wrong reported VRAM size with Unigine_Heaven/-Valley, too?
>>> Maybe speed things up? ;-)
>>>
>>> Unigine_Valley-1.0
>>>
>>> GPU: Unknown GPU x1
>>> System memory: 24102 MB
>>> Video memory:  256 MB
>>> Sync threads:  7
>>> Async threads: 8
>>>
>>> I'll try patching openSUSE Kernel:stable 4.9.6-2 with this
>>> and maybe this could then go into 4.10-rc7 'cause it is a
>>> bugfix. - Alex?
>>
>> This patch just fixes the case of the HUD reporting the wrong amount of 
>> visible vram.  Most 3D apps just default to 256MB if they don't know how 
>> much vram is.  The problem is GL never provided a core way to determine how 
>> much vram is available on a GPU so lots of vendor specific extensions and 
>> driver specific methods popped up to address this.
>>
> vram_size is used for available_texture_mem in st/nine and
> GLX_RENDERER_VIDEO_MEMORY_MESA via GLX_MESA_query_renderer.
> So maybe we want this in older/stable kernel and mesa releases ? Not
> sure how many apps use/honour these though ;-)

vram_size was always correct.  it was just visible vram size that was wrong.

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

[Mesa-dev] X.Org Foundation Membership Renewal

2017-02-02 Thread Alex Deucher 
On January 19th all xorg members were expired as part of the regular
process to remove inactive members.  If you would still like to be a
member of the X.Org Foundation, please renew your membership.  To
renew or to become a first time member, go to https://members.x.org/ .
For renewals, log in and click the renewal link.  For new members,
click the Join Now link.  The X.org Foundation is a non-profit
organization under the SPI umbrella which acts as a steward for the X
Window System and related projects.  Board elections are coming up so
renew or join today!

Thanks!

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

Re: [Mesa-dev] features.txt & EXT_debug_label extension

2017-02-09 Thread Alex Deucher 
On Thu, Feb 9, 2017 at 12:19 PM, Eero Tamminen
 wrote:
> Hi,
>
> When checking GL errors for "Unturned" (Steam top-20 Unity3D based game), I
> noticed that it uses functions from extension unsupported by Mesa, and
> missing from "features.txt":
> https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_debug_label.txt
>
> Could it be added to "features.txt" file?

Sure.  features.txt was originally GL3.txt and as a list of the
extensions missing for GL 3.x and 4.x compliance.  Now that a number
of drivers support all of those extensions, it has also become a list
of useful extensions and their status in mesa.

Alex

>
>
> - Eero
>
> PS. Apitrace already outputs those debug labels in the replay output, but I
> didn't check whether its GUI could also make use of them.
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r300g: only allow byteswapped formats on big endian

2017-02-14 Thread Alex Deucher 
On Tue, Feb 14, 2017 at 10:27 PM, Michel Dänzer  wrote:
> On 14/02/17 08:25 PM, Marek Olšák wrote:
>> I've changed my mind. The patch can be merged if nobody disagrees.
>
> It would be nice to better understand what exactly the problem is. It
> seems unlikely that it's actually an endianness specific problem in the
> driver code, more likely an endianness specific problem in state tracker
> code, or maybe a non-endianness-specific problem in the driver code
> (which may or may not be possible to hit on big endian hosts as well).
>
> In other words, I suspect this isn't a fix for the actual problem, but
> just a workaround. That said, if you guys are happy with that, I'm not
> holding it up.

I tend to agree, but OTOH, r300 is pretty old and BE systems are
pretty few and far between these days.  Neither of which are conducive
to spending much time on them.  Someone with an interest in BE systems
really needs to step up and fix up endian handling in mesa for real.

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

Re: [Mesa-dev] [PATCH] radeonsi: fix broken tessellation on Carrizo and Stoney

2017-02-23 Thread Alex Deucher 
On Thu, Feb 23, 2017 at 1:48 PM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> Cc: 13.0 17.0 

Reviewed-by: Alex Deucher 

> ---
>  src/gallium/drivers/radeonsi/si_state_shaders.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
> b/src/gallium/drivers/radeonsi/si_state_shaders.c
> index f615aa8..750cdd6 100644
> --- a/src/gallium/drivers/radeonsi/si_state_shaders.c
> +++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
> @@ -2305,21 +2305,23 @@ static bool si_update_spi_tmpring_size(struct 
> si_context *sctx)
>S_0286E8_WAVESIZE(scratch_bytes_per_wave >> 10);
> if (spi_tmpring_size != sctx->spi_tmpring_size) {
> sctx->spi_tmpring_size = spi_tmpring_size;
> si_mark_atom_dirty(sctx, &sctx->scratch_state);
> }
> return true;
>  }
>
>  static void si_init_tess_factor_ring(struct si_context *sctx)
>  {
> -   bool double_offchip_buffers = sctx->b.chip_class >= CIK;
> +   bool double_offchip_buffers = sctx->b.chip_class >= CIK &&
> + sctx->b.family != CHIP_CARRIZO &&
> + sctx->b.family != CHIP_STONEY;
> unsigned max_offchip_buffers_per_se = double_offchip_buffers ? 128 : 
> 64;
> unsigned max_offchip_buffers = max_offchip_buffers_per_se *
>sctx->screen->b.info.max_se;
> unsigned offchip_granularity;
>
> switch (sctx->screen->tess_offchip_block_dw_size) {
> default:
> assert(0);
> /* fall through */
> case 8192:
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] winsys/radeon: don't leak the fd when it is 0

2015-07-29 Thread Alex Deucher 
On Wed, Jul 29, 2015 at 10:44 AM, Emil Velikov  wrote:
> Earlier commit added an extra dup(fd) to fix a ZaphodHeads issue.
> Although it did not consider the (very unlikely) case where we might end
> up with the valid fd == 0.
>
> Fixes: 28dda47ae4d(winsys/radeon: Use dup fd as key in drm-winsys hash
> table to fix ZaphodHeads.)
>
> Cc: Mario Kleiner 
> Signed-off-by: Emil Velikov 

Reviewed-by: Alex Deucher 

> ---
>
> Perhaps we should CC mesa-stable as the offending commit, yet
> considering how unlikely the above case is I'm ambivalent,
>
> -Emil
>
>  src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c 
> b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> index 41f8826..f7784fb 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> @@ -493,7 +493,7 @@ static void radeon_winsys_destroy(struct radeon_winsys 
> *rws)
>  radeon_surface_manager_free(ws->surf_man);
>  }
>
> -if (ws->fd)
> +if (ws->fd >= 0)
>  close(ws->fd);
>
>  FREE(rws);
> @@ -786,7 +786,7 @@ fail:
>  ws->kman->destroy(ws->kman);
>  if (ws->surf_man)
>  radeon_surface_manager_free(ws->surf_man);
> -if (ws->fd)
> +if (ws->fd >= 0)
>  close(ws->fd);
>
>  FREE(ws);
> --
> 2.4.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/6] egl/x11: bail out if we cannot fetch the xcb connection

2015-07-29 Thread Alex Deucher 
On Wed, Jul 29, 2015 at 12:19 PM, Emil Velikov  wrote:
> Strictly speaking the xcb_connection_has_error() might be sufficient,
> yet the documentation does not mention what will happen if NULL is fed
> to the function.
>
> Keep things explicit, which will allow us to remove the dri2_dpy->conn
> checking with the next commit.
>
> Signed-off-by: Emil Velikov 

I'm not really an expert when it comes to the egl code, but the series
looks like a nice improvement.  For the series:

Acked-by: Alex Deucher 

> ---
>  src/egl/drivers/dri2/platform_x11.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/egl/drivers/dri2/platform_x11.c 
> b/src/egl/drivers/dri2/platform_x11.c
> index fecd36b..7a28318 100644
> --- a/src/egl/drivers/dri2/platform_x11.c
> +++ b/src/egl/drivers/dri2/platform_x11.c
> @@ -1222,7 +1222,7 @@ dri2_initialize_x11_dri2(_EGLDriver *drv, _EGLDisplay 
> *disp)
>dri2_dpy->screen = DefaultScreen(dpy);
> }
>
> -   if (xcb_connection_has_error(dri2_dpy->conn)) {
> +   if (!dri2_dpy->conn || xcb_connection_has_error(dri2_dpy->conn)) {
>_eglLog(_EGL_WARNING, "DRI2: xcb_connect failed");
>goto cleanup_dpy;
> }
> --
> 2.4.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] winsys/radeon: don't leak the fd when it is 0

2015-07-29 Thread Alex Deucher 
On Wed, Jul 29, 2015 at 2:48 PM, Mario Kleiner
 wrote:
>
>
> On 07/29/2015 05:46 PM, Alex Deucher wrote:
>>
>> On Wed, Jul 29, 2015 at 10:44 AM, Emil Velikov 
>> wrote:
>>>
>>> Earlier commit added an extra dup(fd) to fix a ZaphodHeads issue.
>>> Although it did not consider the (very unlikely) case where we might end
>>> up with the valid fd == 0.
>>>
>>> Fixes: 28dda47ae4d(winsys/radeon: Use dup fd as key in drm-winsys hash
>>> table to fix ZaphodHeads.)
>>>
>>> Cc: Mario Kleiner 
>>> Signed-off-by: Emil Velikov 
>>
>>
>> Reviewed-by: Alex Deucher 
>>
>
> Looks good, thanks for catching this.
>
> Reviewed-by: Mario Kleiner 
>
> cc stable seems safe, so can't hurt, no?
>
> I have a similar patch for the amdgpu Zaphodheads fix floating on the list.
> v1 (just the dup(fd) fix, but not checking for fd >= 0) already reviewed,
> but v2 fixes the same problem on amdgpu you just fixed for radeon, but so
> far lacks a reviewed by - and i don't know who can push stuff to libdrm?
>
> The patch was "[PATCH] libdrm/amdgpu: Use private fd for amdgpu_device and
> winsys hash table to fix ZaphodHeads. (v2)"
>
> Maybe you can have a quick look to get all these into the next mesa release?

I already picked it up in my libdrm tree:
http://cgit.freedesktop.org/~agd5f/drm/commit/?h=amdgpu&id=e2b18a1300313912aeaecf5ba8dd896b5853f6d4

Alex

>
> thanks,
> -mario
>
>>> ---
>>>
>>> Perhaps we should CC mesa-stable as the offending commit, yet
>>> considering how unlikely the above case is I'm ambivalent,
>>>
>>> -Emil
>>>
>>>   src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>>> b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>>> index 41f8826..f7784fb 100644
>>> --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>>> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>>> @@ -493,7 +493,7 @@ static void radeon_winsys_destroy(struct
>>> radeon_winsys *rws)
>>>   radeon_surface_manager_free(ws->surf_man);
>>>   }
>>>
>>> -if (ws->fd)
>>> +if (ws->fd >= 0)
>>>   close(ws->fd);
>>>
>>>   FREE(rws);
>>> @@ -786,7 +786,7 @@ fail:
>>>   ws->kman->destroy(ws->kman);
>>>   if (ws->surf_man)
>>>   radeon_surface_manager_free(ws->surf_man);
>>> -if (ws->fd)
>>> +if (ws->fd >= 0)
>>>   close(ws->fd);
>>>
>>>   FREE(ws);
>>> --
>>> 2.4.5
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] winsys/radeon: don't leak the fd when it is 0

2015-07-29 Thread Alex Deucher 
On Wed, Jul 29, 2015 at 2:55 PM, Mario Kleiner
 wrote:
> On 07/29/2015 08:50 PM, Alex Deucher wrote:
>>
>> On Wed, Jul 29, 2015 at 2:48 PM, Mario Kleiner
>>  wrote:
>>>
>>>
>>>
>>> On 07/29/2015 05:46 PM, Alex Deucher wrote:
>>>>
>>>>
>>>> On Wed, Jul 29, 2015 at 10:44 AM, Emil Velikov
>>>> 
>>>> wrote:
>>>>>
>>>>>
>>>>> Earlier commit added an extra dup(fd) to fix a ZaphodHeads issue.
>>>>> Although it did not consider the (very unlikely) case where we might
>>>>> end
>>>>> up with the valid fd == 0.
>>>>>
>>>>> Fixes: 28dda47ae4d(winsys/radeon: Use dup fd as key in drm-winsys hash
>>>>> table to fix ZaphodHeads.)
>>>>>
>>>>> Cc: Mario Kleiner 
>>>>> Signed-off-by: Emil Velikov 
>>>>
>>>>
>>>>
>>>> Reviewed-by: Alex Deucher 
>>>>
>>>
>>> Looks good, thanks for catching this.
>>>
>>> Reviewed-by: Mario Kleiner 
>>>
>>> cc stable seems safe, so can't hurt, no?
>>>
>>> I have a similar patch for the amdgpu Zaphodheads fix floating on the
>>> list.
>>> v1 (just the dup(fd) fix, but not checking for fd >= 0) already reviewed,
>>> but v2 fixes the same problem on amdgpu you just fixed for radeon, but so
>>> far lacks a reviewed by - and i don't know who can push stuff to libdrm?
>>>
>>> The patch was "[PATCH] libdrm/amdgpu: Use private fd for amdgpu_device
>>> and
>>> winsys hash table to fix ZaphodHeads. (v2)"
>>>
>>> Maybe you can have a quick look to get all these into the next mesa
>>> release?
>>
>>
>> I already picked it up in my libdrm tree:
>>
>> http://cgit.freedesktop.org/~agd5f/drm/commit/?h=amdgpu&id=e2b18a1300313912aeaecf5ba8dd896b5853f6d4
>>
>> Alex
>>
>
> Ah ok. Could you get (v2) instead? It has the same fix as Emil's to make
> sure we accept fd == 0 as a valid descriptor.

Sure.  Can you send it to me?  I can't seem to find it in my email.

Alex

>
> thanks,
> -mario
>
>
>
>
>
>
>
>>>
>>> thanks,
>>> -mario
>>>
>>>>> ---
>>>>>
>>>>> Perhaps we should CC mesa-stable as the offending commit, yet
>>>>> considering how unlikely the above case is I'm ambivalent,
>>>>>
>>>>> -Emil
>>>>>
>>>>>src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 4 ++--
>>>>>1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>>>>> b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>>>>> index 41f8826..f7784fb 100644
>>>>> --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>>>>> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>>>>> @@ -493,7 +493,7 @@ static void radeon_winsys_destroy(struct
>>>>> radeon_winsys *rws)
>>>>>radeon_surface_manager_free(ws->surf_man);
>>>>>}
>>>>>
>>>>> -if (ws->fd)
>>>>> +if (ws->fd >= 0)
>>>>>close(ws->fd);
>>>>>
>>>>>FREE(rws);
>>>>> @@ -786,7 +786,7 @@ fail:
>>>>>ws->kman->destroy(ws->kman);
>>>>>if (ws->surf_man)
>>>>>radeon_surface_manager_free(ws->surf_man);
>>>>> -if (ws->fd)
>>>>> +if (ws->fd >= 0)
>>>>>close(ws->fd);
>>>>>
>>>>>FREE(ws);
>>>>> --
>>>>> 2.4.5
>>>>>
>>>>> ___
>>>>> mesa-dev mailing list
>>>>> mesa-dev@lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>>
>>>>
>>>> ___
>>>> mesa-dev mailing list
>>>> mesa-dev@lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] radeonsi: add fiji pci id

2015-08-03 Thread Alex Deucher 
Reviewed-by: Marek Olšák 
Reviewed-by: Christian König 
Reviewed-by: David Zhang 
Signed-off-by: Alex Deucher 
---
 include/pci_ids/radeonsi_pci_ids.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/pci_ids/radeonsi_pci_ids.h 
b/include/pci_ids/radeonsi_pci_ids.h
index 197ce8e..c01ee20 100644
--- a/include/pci_ids/radeonsi_pci_ids.h
+++ b/include/pci_ids/radeonsi_pci_ids.h
@@ -178,3 +178,5 @@ CHIPSET(0x9874, CARRIZO_, CARRIZO)
 CHIPSET(0x9875, CARRIZO_, CARRIZO)
 CHIPSET(0x9876, CARRIZO_, CARRIZO)
 CHIPSET(0x9877, CARRIZO_, CARRIZO)
+
+CHIPSET(0x7300, FIJI_, FIJI)
-- 
1.8.3.1

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

[Mesa-dev] [PATCH 2/3] radeonsi: add support for FIJI (v4)

2015-08-03 Thread Alex Deucher 
v2: incorporate comments from Marek
v3: add missing fiji case in winsys init
use tonga raster config (double check this)
v4: rebase on harvest patch

Reviewed-by: Marek Olšák  (v3)
Reviewed-by: Christian König  (v3)
Reviewed-by: David Zhang  (v3)
Signed-off-by: Alex Deucher 
---
 src/gallium/drivers/radeon/r600_pipe_common.c | 2 ++
 src/gallium/drivers/radeon/radeon_winsys.h| 1 +
 src/gallium/drivers/radeonsi/si_state.c   | 5 +
 src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 4 
 4 files changed, 12 insertions(+)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 57a752f..f657adb 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -405,6 +405,7 @@ static const char* r600_get_name(struct pipe_screen* 
pscreen)
case CHIP_TONGA: return "AMD TONGA";
case CHIP_ICELAND: return "AMD ICELAND";
case CHIP_CARRIZO: return "AMD CARRIZO";
+   case CHIP_FIJI: return "AMD FIJI";
default: return "AMD unknown";
}
 }
@@ -525,6 +526,7 @@ const char *r600_get_llvm_processor_name(enum radeon_family 
family)
case CHIP_TONGA: return "tonga";
case CHIP_ICELAND: return "iceland";
case CHIP_CARRIZO: return "carrizo";
+   case CHIP_FIJI: return "fiji";
default: return "";
}
 }
diff --git a/src/gallium/drivers/radeon/radeon_winsys.h 
b/src/gallium/drivers/radeon/radeon_winsys.h
index b1e91eb..513c2f9 100644
--- a/src/gallium/drivers/radeon/radeon_winsys.h
+++ b/src/gallium/drivers/radeon/radeon_winsys.h
@@ -136,6 +136,7 @@ enum radeon_family {
 CHIP_TONGA,
 CHIP_ICELAND,
 CHIP_CARRIZO,
+CHIP_FIJI,
 CHIP_LAST,
 };
 
diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index daa3131..d16f402 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3149,6 +3149,11 @@ void si_init_config(struct si_context *sctx)
raster_config = 0x3a00161a;
raster_config_1 = 0x002e;
break;
+   case CHIP_FIJI:
+   /* Fiji should be same as Hawaii, but that causes corruption in 
some cases */
+   raster_config = 0x1612; /* 0x3a00161a */
+   raster_config_1 = 0x002a; /* 0x002e */
+   break;
case CHIP_TONGA:
raster_config = 0x1612;
raster_config_1 = 0x002a;
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
index e3b7577..7e003e4 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
@@ -228,6 +228,10 @@ static boolean do_winsys_init(struct amdgpu_winsys *ws)
   ws->family = FAMILY_CZ;
   ws->rev_id = CZ_CARRIZO_A0;
   break;
+   case CHIP_FIJI:
+  ws->family = FAMILY_VI;
+  ws->rev_id = VI_FIJI_P_A0;
+  break;
default:
   fprintf(stderr, "amdgpu: Unknown family.\n");
   goto fail;
-- 
1.8.3.1

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

[Mesa-dev] [PATCH 1/3] addrlib: add support for Fiji (v2)

2015-08-03 Thread Alex Deucher 
v2: fix tonga chip check

Reviewed-by: Marek Olšák 
Reviewed-by: Christian König 
Reviewed-by: David Zhang 
Signed-off-by: Alex Deucher 
---
 src/gallium/winsys/amdgpu/drm/addrlib/r800/ciaddrlib.cpp | 5 +
 src/gallium/winsys/amdgpu/drm/addrlib/r800/ciaddrlib.h   | 1 +
 src/gallium/winsys/amdgpu/drm/amdgpu_id.h| 6 +-
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/gallium/winsys/amdgpu/drm/addrlib/r800/ciaddrlib.cpp 
b/src/gallium/winsys/amdgpu/drm/addrlib/r800/ciaddrlib.cpp
index 264e2ef..7393953 100644
--- a/src/gallium/winsys/amdgpu/drm/addrlib/r800/ciaddrlib.cpp
+++ b/src/gallium/winsys/amdgpu/drm/addrlib/r800/ciaddrlib.cpp
@@ -350,6 +350,7 @@ AddrChipFamily CIAddrLib::HwlConvertChipFamily(
 m_settings.isVolcanicIslands = 1;
 m_settings.isIceland = ASICREV_IS_ICELAND_M(uChipRevision);
 m_settings.isTonga   = ASICREV_IS_TONGA_P(uChipRevision);
+m_settings.isFiji= ASICREV_IS_FIJI_P(uChipRevision);
 break;
 case FAMILY_CZ:
 m_settings.isCarrizo = 1;
@@ -410,6 +411,10 @@ BOOL_32 CIAddrLib::HwlInitGlobalParams(
 {
 m_pipes = 2;
 }
+else if (m_settings.isFiji)
+{
+m_pipes = 16;
+}
 
 if (valid)
 {
diff --git a/src/gallium/winsys/amdgpu/drm/addrlib/r800/ciaddrlib.h 
b/src/gallium/winsys/amdgpu/drm/addrlib/r800/ciaddrlib.h
index 0220736..4515086 100644
--- a/src/gallium/winsys/amdgpu/drm/addrlib/r800/ciaddrlib.h
+++ b/src/gallium/winsys/amdgpu/drm/addrlib/r800/ciaddrlib.h
@@ -59,6 +59,7 @@ struct CIChipSettings
 UINT_32 isVolcanicIslands : 1;
 UINT_32 isIceland : 1;
 UINT_32 isTonga   : 1;
+UINT_32 isFiji: 1;
 // VI fusion (Carrizo)
 UINT_32 isCarrizo : 1;
 };
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_id.h 
b/src/gallium/winsys/amdgpu/drm/amdgpu_id.h
index 08a1591..8882c41 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_id.h
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_id.h
@@ -136,6 +136,8 @@ enum {
VI_TONGA_P_A0 = 20,
VI_TONGA_P_A1 = 21,
 
+   VI_FIJI_P_A0  = 60,
+
VI_UNKNOWN= 0xFF
 };
 
@@ -143,7 +145,9 @@ enum {
 #define ASICREV_IS_ICELAND_M(eChipRev) \
(eChipRev < VI_TONGA_P_A0)
 #define ASICREV_IS_TONGA_P(eChipRev)   \
-   (eChipRev >= VI_TONGA_P_A0)
+   ((eChipRev >= VI_TONGA_P_A0) && (eChipRev < VI_FIJI_P_A0))
+#define ASICREV_IS_FIJI_P(eChipRev)\
+   (eChipRev >= VI_FIJI_P_A0)
 
 /* CZ specific rev IDs */
 enum {
-- 
1.8.3.1

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

[Mesa-dev] [PATCH] amdgpu: add Fiji support

2015-08-03 Thread Alex Deucher 
Signed-off-by: Alex Deucher 
---

This should be 1/16 speed model.  Not sure how to adjust that.  Tom?

 lib/Target/AMDGPU/Processors.td | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/Target/AMDGPU/Processors.td b/lib/Target/AMDGPU/Processors.td
index c0ffede..0eac121 100644
--- a/lib/Target/AMDGPU/Processors.td
+++ b/lib/Target/AMDGPU/Processors.td
@@ -135,3 +135,5 @@ def : ProcessorModel<"iceland", SIQuarterSpeedModel,
 >;
 
 def : ProcessorModel<"carrizo", SIQuarterSpeedModel, [FeatureVolcanicIslands]>;
+
+def : ProcessorModel<"fiji", SIQuarterSpeedModel, [FeatureVolcanicIslands]>;
-- 
1.8.3.1

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

[Mesa-dev] [PATCH] radeonsi: add new OLAND pci id

2015-08-10 Thread Alex Deucher 
Signed-off-by: Alex Deucher 
Cc: mesa-sta...@lists.freedesktop.org
---
 include/pci_ids/radeonsi_pci_ids.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/pci_ids/radeonsi_pci_ids.h 
b/include/pci_ids/radeonsi_pci_ids.h
index c01ee20..52eada1 100644
--- a/include/pci_ids/radeonsi_pci_ids.h
+++ b/include/pci_ids/radeonsi_pci_ids.h
@@ -63,6 +63,7 @@ CHIPSET(0x6608, OLAND_6608, OLAND)
 CHIPSET(0x6610, OLAND_6610, OLAND)
 CHIPSET(0x6611, OLAND_6611, OLAND)
 CHIPSET(0x6613, OLAND_6613, OLAND)
+CHIPSET(0x6617, OLAND_6617, OLAND)
 CHIPSET(0x6620, OLAND_6620, OLAND)
 CHIPSET(0x6621, OLAND_6621, OLAND)
 CHIPSET(0x6623, OLAND_6623, OLAND)
-- 
1.8.3.1

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

Re: [Mesa-dev] [PATCH 1/2] r600g: fix polygon offset scale

2015-08-12 Thread Alex Deucher 
On Tue, Aug 11, 2015 at 7:02 PM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> The value was copied from r300g, which uses 1/12 subpixels, but this hw
> uses 1/16 subpixels.
>
> Should fix piglit: gl-1.4-polygon-offset (formerly a glean test)
> (untested, ported from radeonsi)


For the series:

Reviewed-by: Alex Deucher 

CC stable?

> ---
>  src/gallium/drivers/r600/evergreen_state.c | 2 +-
>  src/gallium/drivers/r600/r600_state.c  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/evergreen_state.c 
> b/src/gallium/drivers/r600/evergreen_state.c
> index f7a76f6..95987ee 100644
> --- a/src/gallium/drivers/r600/evergreen_state.c
> +++ b/src/gallium/drivers/r600/evergreen_state.c
> @@ -485,7 +485,7 @@ static void *evergreen_create_rs_state(struct 
> pipe_context *ctx,
>
> /* offset */
> rs->offset_units = state->offset_units;
> -   rs->offset_scale = state->offset_scale * 12.0f;
> +   rs->offset_scale = state->offset_scale * 16.0f;
> rs->offset_enable = state->offset_point || state->offset_line || 
> state->offset_tri;
>
> if (state->point_size_per_vertex) {
> diff --git a/src/gallium/drivers/r600/r600_state.c 
> b/src/gallium/drivers/r600/r600_state.c
> index 8488188..5cc2283 100644
> --- a/src/gallium/drivers/r600/r600_state.c
> +++ b/src/gallium/drivers/r600/r600_state.c
> @@ -473,7 +473,7 @@ static void *r600_create_rs_state(struct pipe_context 
> *ctx,
>
> /* offset */
> rs->offset_units = state->offset_units;
> -   rs->offset_scale = state->offset_scale * 12.0f;
> +   rs->offset_scale = state->offset_scale * 16.0f;
> rs->offset_enable = state->offset_point || state->offset_line || 
> state->offset_tri;
>
> if (state->point_size_per_vertex) {
> --
> 2.1.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeonsi: add new OLAND pci id

2015-08-13 Thread Alex Deucher 
On Thu, Aug 13, 2015 at 11:11 AM, Emil Velikov  wrote:
> Hi Alex,
>
> On 10 August 2015 at 20:36, Alex Deucher  wrote:
>> Signed-off-by: Alex Deucher 
>> Cc: mesa-sta...@lists.freedesktop.org
>> ---
>>  include/pci_ids/radeonsi_pci_ids.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/include/pci_ids/radeonsi_pci_ids.h 
>> b/include/pci_ids/radeonsi_pci_ids.h
>> index c01ee20..52eada1 100644
>> --- a/include/pci_ids/radeonsi_pci_ids.h
>> +++ b/include/pci_ids/radeonsi_pci_ids.h
>> @@ -63,6 +63,7 @@ CHIPSET(0x6608, OLAND_6608, OLAND)
>>  CHIPSET(0x6610, OLAND_6610, OLAND)
>>  CHIPSET(0x6611, OLAND_6611, OLAND)
>>  CHIPSET(0x6613, OLAND_6613, OLAND)
>> +CHIPSET(0x6617, OLAND_6617, OLAND)
> Has there been any ideas/plans on getting this information
> consolidated in a single place ?
>
> It feels a bit "dirty" having the same information in four places -
> kernel, libdrm, ddx, mesa.

There's not really a good solution that I know of due to the way X
works.  Using xf86-video-modesetting saves one at least. And for
amdgpu, we merged the surface manager into mesa rather than having it
on libdrm since we always use glamor so we didn't need access to it in
the ddx to support EXA.

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeonsi: add new OLAND pci id

2015-08-13 Thread Alex Deucher 
On Thu, Aug 13, 2015 at 12:06 PM, Emil Velikov  wrote:
> On 13 August 2015 at 16:42, Alex Deucher  wrote:
>> On Thu, Aug 13, 2015 at 11:11 AM, Emil Velikov  
>> wrote:
>>> Hi Alex,
>>>
>>> On 10 August 2015 at 20:36, Alex Deucher  wrote:
>>>> Signed-off-by: Alex Deucher 
>>>> Cc: mesa-sta...@lists.freedesktop.org
>>>> ---
>>>>  include/pci_ids/radeonsi_pci_ids.h | 1 +
>>>>  1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/include/pci_ids/radeonsi_pci_ids.h 
>>>> b/include/pci_ids/radeonsi_pci_ids.h
>>>> index c01ee20..52eada1 100644
>>>> --- a/include/pci_ids/radeonsi_pci_ids.h
>>>> +++ b/include/pci_ids/radeonsi_pci_ids.h
>>>> @@ -63,6 +63,7 @@ CHIPSET(0x6608, OLAND_6608, OLAND)
>>>>  CHIPSET(0x6610, OLAND_6610, OLAND)
>>>>  CHIPSET(0x6611, OLAND_6611, OLAND)
>>>>  CHIPSET(0x6613, OLAND_6613, OLAND)
>>>> +CHIPSET(0x6617, OLAND_6617, OLAND)
>>> Has there been any ideas/plans on getting this information
>>> consolidated in a single place ?
>>>
>>> It feels a bit "dirty" having the same information in four places -
>>> kernel, libdrm, ddx, mesa.
>>
>> There's not really a good solution that I know of due to the way X
>> works.
> If I have to guess, obtaining OLAND via DRM_IOCTL_RADEON_INFO won't be
> impacted by (nor have any impact on) how X works. Shouldn't this "just
> work" or there is something subtly off with the idea ? Can you
> elaborate what part of X might be an obstacle ?

IIRC, X decides what driver to load based on the pci ids they support
rather than letting drivers claim their devices.  It's remnant of the
UMS days.

Alex

>
>> Using xf86-video-modesetting saves one at least. And for
>> amdgpu, we merged the surface manager into mesa rather than having it
>> on libdrm since we always use glamor so we didn't need access to it in
>> the ddx to support EXA.
>>
> True. Even if one day you want/have to do EXA xf86-video-amdgpu one
> can always re-factor it out into libdrm_amdgpu. So the surface manager
> is a win-win atm :)
>
> Thanks
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeonsi: add new OLAND pci id

2015-08-13 Thread Alex Deucher 
On Thu, Aug 13, 2015 at 5:29 PM, Emil Velikov  wrote:
> On 13/08/15 22:22, Emil Velikov wrote:
>> On 13/08/15 18:11, Alex Deucher wrote:
>>> On Thu, Aug 13, 2015 at 12:06 PM, Emil Velikov  
>>> wrote:
>>>> On 13 August 2015 at 16:42, Alex Deucher  wrote:
>>>>> On Thu, Aug 13, 2015 at 11:11 AM, Emil Velikov  
>>>>> wrote:
>>>>>> Hi Alex,
>>>>>>
>>>>>> On 10 August 2015 at 20:36, Alex Deucher  wrote:
>>>>>>> Signed-off-by: Alex Deucher 
>>>>>>> Cc: mesa-sta...@lists.freedesktop.org
>>>>>>> ---
>>>>>>>  include/pci_ids/radeonsi_pci_ids.h | 1 +
>>>>>>>  1 file changed, 1 insertion(+)
>>>>>>>
>>>>>>> diff --git a/include/pci_ids/radeonsi_pci_ids.h 
>>>>>>> b/include/pci_ids/radeonsi_pci_ids.h
>>>>>>> index c01ee20..52eada1 100644
>>>>>>> --- a/include/pci_ids/radeonsi_pci_ids.h
>>>>>>> +++ b/include/pci_ids/radeonsi_pci_ids.h
>>>>>>> @@ -63,6 +63,7 @@ CHIPSET(0x6608, OLAND_6608, OLAND)
>>>>>>>  CHIPSET(0x6610, OLAND_6610, OLAND)
>>>>>>>  CHIPSET(0x6611, OLAND_6611, OLAND)
>>>>>>>  CHIPSET(0x6613, OLAND_6613, OLAND)
>>>>>>> +CHIPSET(0x6617, OLAND_6617, OLAND)
>>>>>> Has there been any ideas/plans on getting this information
>>>>>> consolidated in a single place ?
>>>>>>
>>>>>> It feels a bit "dirty" having the same information in four places -
>>>>>> kernel, libdrm, ddx, mesa.
>>>>>
>>>>> There's not really a good solution that I know of due to the way X
>>>>> works.
>>>> If I have to guess, obtaining OLAND via DRM_IOCTL_RADEON_INFO won't be
>>>> impacted by (nor have any impact on) how X works. Shouldn't this "just
>>>> work" or there is something subtly off with the idea ? Can you
>>>> elaborate what part of X might be an obstacle ?
>>>
>>> IIRC, X decides what driver to load based on the pci ids they support
>>> rather than letting drivers claim their devices.  It's remnant of the
>>> UMS days.
>>>
>> I think we're talking about different things here.
>>
>> * The (dare I say it) detection code used to determine the ddx/dri
>> module name happens before (and afaics is unrelated to) the driver
>> internals, which depend on the OLAND{,_foo} values.
>>
>> Obviously there is a handfull of extra information about "all the
>> supported vendor/device ids" in the ddx that you're thinking about, that
>> I'm afraid one cannot get rid of, unless...
>>
>> * The DDX uses a nouveau-like approach, accepting every device id. At
>> PreInit stage, one does a quick check with libdrm_radeon/amdgpu
>> (amdgpu_device_initialize?). The latter of which already has a
>> comprehensive enough list of device ids.
>>
> Actually scratch this part, libdrm_radeon does have a list of the
> devices, but does not have a "device_init" type API. On the other hand
> amdgpu has the API, but doesn't have the device ids.
>
> The earlier (original) idea still stands though:
> By the time OLAND* is queried/used in the ddx/mesa, the ddx/dri module
> has already been picked up, irrespective of that extra info

I don't think that will work.  The X server attempts to load the ddxes
based on the pci vendor id unless you manually specify the driver in
your xorg.conf.  In the case of 0x1002 AMD/ATI, there are 5 drivers
for device ids for that vendor id: ati_misc, mach64, r128, radeon, and
amdgpu.  The ddx then tells mesa what driver to load via dri2 based on
the pci id in the ddx.

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

Re: [Mesa-dev] [PATCH] winsys/amdgpu: fix the type of memory usage counters

2015-08-18 Thread Alex Deucher 
On Tue, Aug 18, 2015 at 12:43 PM, Marek Olšák  wrote:
> From: Marek Olšák 

Reviewed-by: Alex Deucher 

>
> ---
>  src/gallium/winsys/amdgpu/drm/amdgpu_cs.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.h 
> b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.h
> index 0842259..12c6b62 100644
> --- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.h
> +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.h
> @@ -77,8 +77,8 @@ struct amdgpu_cs {
>
> int buffer_indices_hashlist[512];
>
> -   unsignedused_vram;
> -   unsignedused_gart;
> +   uint64_tused_vram;
> +   uint64_tused_gart;
>
> unsignedmax_dependencies;
>  };
> --
> 2.1.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] New stable-branch 10.6 candidate pushed

2015-08-20 Thread Alex Deucher 
On Thu, Aug 20, 2015 at 11:08 AM, Emil Velikov  wrote:
> Hello list,
>
> The candidate for the Mesa 10.6.5 is now available. Currently we have:
>  - 20 queued
>  - 16 nominated (outstanding)
>  - and 3 rejected/obsolete patches
>
> Apart from the usual nouveau, i965 and radeon driver fixes, the series
> resolves a few serious issues with nouveau_vieux users and big endian 
> platforms.
>
>
> Take a look at section "Mesa stable queue" for more information.
>
> Testing
> ---
> The following results are against piglit 246791c51ec.
>
>
> Changes - classic i965(snb)
> ---
> None.
>
>
> Changes - swrast classic
> 
> None.
>
>
> Changes - gallium softpipe
> --
> None.
>
>
> Changes - gallium llvmpipe (LLVM 3.6.2)
> ---
> None.
>
>
> Testing reports/general approval
> 
> Any testing reports (or general approval of the state of the branch)
> will be greatly appreciated.
>
>
> Trivial merge conflicts
> ---
> None.
>
>
> The plan is to have 10.6.5 this Monday(21th of August).
>
> If you have any questions or comments that you would like to share
> before the release, please go ahead.
>
>
> Cheers,
> Emil
>
>
> Mesa stable queue
> -
>
> Nominated (16)
> ==
>
> Boyan Ding (1):
>   i915: Add XRGB format to intel_screen_make_configs
>
> Brian Paul (1):
>   configure: don't try to build gallium DRI drivers if --disable-dri is 
> set
>
> Chris Wilson (1):
>   i965: Prevent coordinate overflow in intel_emit_linear_blit
>
> David Heidelberg (1):
>   st/nine: Require gcc >= 4.6
>
> Emil Velikov (2):
>   mapi: automake: inline glapi_gen_mapi define
>   xmlpool: remove LOCALEDIR variable/fix bmake
>
> Jason Ekstrand (1):
>   i965/fs: Split VGRFs after lowering pull constants
>
> Neil Roberts (2):
>   i965: Swap the order of the vertex ID and edge flag attributes
>   i965/bdw: Fix 3DSTATE_VF_INSTANCING when the edge flag is used
>
> Rob Clark (1):
>   xa: add xa_surface_from_handle2
>
> Tapani Pälli (1):
>   mesa: update fbo state in glTexStorage
>
> Timothy Arceri (1):
>   glsl: fix atomic buffer index for bindings other than 0
>
> Tom Stellard (4):
>   clover: Call clBuildProgram() notification function when build 
> completes v2
>   gallium/drivers: Add threadsafe wrappers for pipe_context v2
>   clover: Use threadsafe wrappers for pipe_context v2
>   clover: Properly initialize LLVM targets when linking with component 
> libs
>
>
>
> Queued (20)
> ===
>
> Adam Jackson (1):
>   glx: Fix __glXWireToEvent for BufferSwapComplete
>
> Alex Deucher (2):
>   radeonsi: add new OLAND pci id
>   radeonsi: properly set the raster_config for KV

Please drop "radeonsi: properly set the raster_config for KV" for stable.

Alex


>
> Emil Velikov (2):
>   docs: add sha256 checksums for 10.6.4
>   vc4: add missing nir include, to fix the build
>
> Frank Binns (1):
>   egl/x11: don't abort when creating a DRI2 drawable fails
>
> Ilia Mirkin (3):
>   nouveau: no need to do tnl wakeup, state updates are always hooked up
>   gm107/ir: indirect handle goes first on maxwell also
>   nv50,nvc0: take level into account when doing eng2d multi-layer blits
>
> Jason Ekstrand (4):
>   meta/copy_image: Stash off the scissor
>   mesa/formats: Only do byteswapping for packed formats
>   mesa/formats: Fix swizzle flipping for big-endian targets
>   mesa/formats: Don't flip channels of null array formats
>
> Marek Olšák (3):
>   radeonsi: fix polygon offset scale
>   r600g: fix polygon offset scale
>   r600g: allow setting geometry shader sampler states
>
> Neil Roberts (1):
>   i965/bdw: Fix setting the instancing state for the SGVS element
>
> Oded Gabbay (2):
>   mesa: clear existing swizzle info before bitwise-OR
>   mesa/formats: don't byteswap when building array formats
>
> Renaud Gaubert (1):
>   glsl: avoid compiler's segfault when processing operators with void 
> arguments
>
>
> Obsolete (1)
> 
>
> Oded Gabbay (1):
>   mesa/formats: don't byteswap when building array formats
>
>
> Rejected (2)
> 
>
> Oded Gabbay (1):
>   mesa: _mesa_format_convert should be endian agnostic
>
> Anuj Phogat (1):
>   i965: Fix {src, dst}_pitch alignment check for XY_SRC_COPY_BLT
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/15] gallium/radeonsi hang debugging and IB parser

2015-08-24 Thread Alex Deucher 
On Mon, Aug 24, 2015 at 3:41 AM, Christian König
 wrote:
> Nice work! Finally something that goes into the direction of proper hang
> debugging for end users.
>
> I don't have time to completely review it but the whole set is Acked-by:
> Christian König 

Yes, this looks awesome.  Series is:
Acked-by: Alex Deucher 

>
> Regards,
> Christian.
>
>
> On 23.08.2015 14:04, Marek Olšák wrote:
>>
>> Hi,
>>
>> Setting GALLIUM_DDEBUG=800 (timeout=800ms) enables the new ddebug module,
>> which records all gallium states. The module tries to detect a hang and if
>> it occurs, it prints all gallium states to a file, and calls
>> pipe_context->dump_debug_state, which prints driver-specific state to the
>> same file. The module exactly pinpoints the problematic draw call, because
>> it waits for every draw call to finish within the given timeout.
>>
>> The result on the radeonsi driver is a report that contains the following:
>> - the problematic draw call with all gallium states
>> - memory mapped status registers for hang debugging (GRBM_STATUS, etc.)
>> - disassembled shaders
>> - the indirect buffer (IB, AKA command buffer or CS) in a human-readable
>> form
>>
>> The driver also adds trace points to indirect buffers, and it prints where
>> the CP stopped executing the IB. You can either read it with "less -R" or
>> convert to html with "aha".
>>
>> This is the html report from one GPU hang. You can see the trace points in
>> the IB there. The CP is probably stuck at PS_PARTIAL_FLUSH, waiting for the
>> 3D engine to go idle:
>> http://people.freedesktop.org/~mareko/ddebug_heaven_hung.html
>>
>> Most of the IB parser is automatically generated from sid.h using a python
>> script invoked during a Mesa build, so it understands all packets and all
>> registers which are defined there. It's regenerated when sid.h is changed.
>>
>> One more html report just showing how many status registers are printed on
>> VI:
>> http://people.freedesktop.org/~mareko/ddebug_dump.html
>>
>> Please review.
>>
>> Marek
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] winsys/radeon: handle non-zero finite timeout when waiting for buffers

2015-08-26 Thread Alex Deucher 
On Wed, Aug 26, 2015 at 7:09 AM, Marek Olšák  wrote:
> Ping

for the series:
Reviewed-by: Alex Deucher 

>
> On Sun, Aug 23, 2015 at 2:13 PM, Marek Olšák  wrote:
>> From: Marek Olšák 
>>
>> ---
>>  src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 54 
>> +++
>>  src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 25 +
>>  2 files changed, 41 insertions(+), 38 deletions(-)
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gallium state tracker calls calloc for 0 sizes arrays ?

2015-08-27 Thread Alex Deucher 
On Thu, Aug 27, 2015 at 1:55 PM, Hans de Goede  wrote:
> Hi,
>
> On 27-08-15 15:46, Marek Olšák wrote:
>>
>> On Thu, Aug 27, 2015 at 3:09 PM, Hans de Goede 
>> wrote:
>>>
>>> Hi All,
>>>
>>> While debugging: https://bugzilla.redhat.com/show_bug.cgi?id=1008089
>>>
>>> I made a apitrace recording of the a single slide transition
>>> animation, and since I suspected memory corruption replayed
>>> it using ElectrFence + glretrace, this finds a 0 sized array
>>> allocation at src/mesa/state_tracker/st_glsl_to_tgsi.cpp: 5565:
>>>
>>> if (proginfo->Parameters) {
>>>t->constants = (struct ureg_src *)
>>>   calloc(proginfo->Parameters->NumParameters,
>>> sizeof(t->constants[0]));
>>>
>>> And if I protect the code against that one, another one at 5618:
>>>
>>> t->immediates = (struct ureg_src *)
>>>calloc(program->num_immediates, sizeof(struct ureg_src));
>>>
>>> With the regular glibc malloc these both succeed as it actually
>>> returns a valid memory address (posix says it may also return NULL)
>>>
>>> I believe that the fragment program in question comes from:
>>>
>>> src/mesa/main/state.c update_program() and then from the
>>>
>>> else if (ctx->FragmentProgram._MaintainTexEnvProgram) {
>>>/* Use fragment program generated from fixed-function state */
>>>
>>> }
>>>
>>> block.
>>>
>>> Interestingly enough if I allow malloc(0) to proceed from ElectricFence,
>>> then the glretrace runs fine, and even renders correctly, where as
>>> running the same gl command stream from libreoffice impress leads
>>> to missrendering on nv3c.
>>>
>>> So 2 questions:
>>>
>>> 1) Is it normal / expected for st_translate_program() to get called
>>> with an empty but not NULL proginfo->Parameters resp. num_immediates == 0
>>> ?
>>>
>>> If not where would I begin to look for finding the culprit of this ?
>>
>>
>> Yes, it's normal.
>
>
> OK, thanks for the clear answer on this.
>
>>> 2) Since the glretrace does work outside of libreoffice impress, I think
>>> it may have something to do with the visual chosen by libreoffice
>>> impress,
>>> is there an easy way to find out what visual lo is choosing?
>>
>>
>> No, it's not because of the visual. It seems to me that libreoffice
>> changed the behavior of malloc and calloc.
>
>
> I'm pretty sure that this is not libreoffice changing malloc / calloc,
> it links normally to libc, and the same slide transition works fine
> with an nv84 card which also has a gallium based mesa driver.
>
> I really believe this is due to libreoffice doing something opengl
> related differently then glretrace, be it the visual or something else
> back buffer related ...
>

Does libreoffice use llvm?  I have vague recollections of there being
issues with llvm and libreoffice in the past because radeonsi uses
llvm as well.

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

Re: [Mesa-dev] [PATCH] r600g: add proper support for VGT_FLUSH

2015-08-28 Thread Alex Deucher 
On Fri, Aug 28, 2015 at 12:35 AM, Ilia Mirkin  wrote:
> Just an observation... this was previously only done for EG+, while
> now R600/R700 will get this too.

VGT flush is valid on r6xx/r7xx too and probably should have been
applied for them as well originally.

Alex


>
> On Fri, Aug 28, 2015 at 12:31 AM, Dave Airlie  wrote:
>> From: Dave Airlie 
>>
>> The geom shader rings require a VGT FLUSH, but up until now
>> it was just hacked into the function, add proper support for it.
>>
>> Signed-off-by: Dave Airlie 
>> ---
>>  src/gallium/drivers/r600/evergreen_state.c | 9 +
>>  src/gallium/drivers/r600/r600_hw_context.c | 5 +
>>  src/gallium/drivers/r600/r600_pipe.h   | 3 ++-
>>  3 files changed, 8 insertions(+), 9 deletions(-)
>>
>> diff --git a/src/gallium/drivers/r600/evergreen_state.c 
>> b/src/gallium/drivers/r600/evergreen_state.c
>> index 6a91d47..a44646a 100644
>> --- a/src/gallium/drivers/r600/evergreen_state.c
>> +++ b/src/gallium/drivers/r600/evergreen_state.c
>> @@ -2173,10 +2173,6 @@ static void evergreen_emit_gs_rings(struct 
>> r600_context *rctx, struct r600_atom
>> struct r600_gs_rings_state *state = (struct r600_gs_rings_state*)a;
>> struct r600_resource *rbuffer;
>>
>> -   r600_write_config_reg(cs, R_008040_WAIT_UNTIL, 
>> S_008040_WAIT_3D_IDLE(1));
>> -   radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
>> -   radeon_emit(cs, EVENT_TYPE(EVENT_TYPE_VGT_FLUSH));
>> -
>> if (state->enable) {
>> rbuffer =(struct r600_resource*)state->esgs_ring.buffer;
>> r600_write_config_reg(cs, R_008C40_SQ_ESGS_RING_BASE,
>> @@ -2201,10 +2197,7 @@ static void evergreen_emit_gs_rings(struct 
>> r600_context *rctx, struct r600_atom
>> r600_write_config_reg(cs, R_008C44_SQ_ESGS_RING_SIZE, 0);
>> r600_write_config_reg(cs, R_008C4C_SQ_GSVS_RING_SIZE, 0);
>> }
>> -
>> -   r600_write_config_reg(cs, R_008040_WAIT_UNTIL, 
>> S_008040_WAIT_3D_IDLE(1));
>> -   radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
>> -   radeon_emit(cs, EVENT_TYPE(EVENT_TYPE_VGT_FLUSH));
>> +   rctx->b.flags |= R600_CONTEXT_WAIT_3D_IDLE | R600_CONTEXT_VGT_FLUSH;
>>  }
>>
>>  void cayman_init_common_regs(struct r600_command_buffer *cb,
>> diff --git a/src/gallium/drivers/r600/r600_hw_context.c 
>> b/src/gallium/drivers/r600/r600_hw_context.c
>> index 6445151..5cef9dd 100644
>> --- a/src/gallium/drivers/r600/r600_hw_context.c
>> +++ b/src/gallium/drivers/r600/r600_hw_context.c
>> @@ -128,6 +128,11 @@ void r600_flush_emit(struct r600_context *rctx)
>> cs->buf[cs->cdw++] = EVENT_TYPE(EVENT_TYPE_PS_PARTIAL_FLUSH) 
>> | EVENT_INDEX(4);
>> }
>>
>> +   if (rctx->b.flags & R600_CONTEXT_VGT_FLUSH) {
>> +   cs->buf[cs->cdw++] = PKT3(PKT3_EVENT_WRITE, 0, 0);
>> +   cs->buf[cs->cdw++] = EVENT_TYPE(EVENT_TYPE_VGT_FLUSH) | 
>> EVENT_INDEX(0);
>> +   }
>> +
>> if (rctx->b.chip_class >= R700 &&
>> (rctx->b.flags & R600_CONTEXT_FLUSH_AND_INV_CB_META)) {
>> cs->buf[cs->cdw++] = PKT3(PKT3_EVENT_WRITE, 0, 0);
>> diff --git a/src/gallium/drivers/r600/r600_pipe.h 
>> b/src/gallium/drivers/r600/r600_pipe.h
>> index 3247aba..b77d136 100644
>> --- a/src/gallium/drivers/r600/r600_pipe.h
>> +++ b/src/gallium/drivers/r600/r600_pipe.h
>> @@ -54,9 +54,10 @@
>>  #define R600_CONTEXT_PS_PARTIAL_FLUSH  (R600_CONTEXT_PRIVATE_FLAG 
>> << 8)
>>  #define R600_CONTEXT_WAIT_3D_IDLE  (R600_CONTEXT_PRIVATE_FLAG 
>> << 9)
>>  #define R600_CONTEXT_WAIT_CP_DMA_IDLE  (R600_CONTEXT_PRIVATE_FLAG 
>> << 10)
>> +#define R600_CONTEXT_VGT_FLUSH (R600_CONTEXT_PRIVATE_FLAG << 11)
>>
>>  /* the number of CS dwords for flushing and drawing */
>> -#define R600_MAX_FLUSH_CS_DWORDS   16
>> +#define R600_MAX_FLUSH_CS_DWORDS   18
>>  #define R600_MAX_DRAW_CS_DWORDS47
>>  #define R600_TRACE_CS_DWORDS   7
>>
>> --
>> 2.4.3
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/42] RadeonSI cleaning up states

2015-08-30 Thread Alex Deucher 
On Sun, Aug 30, 2015 at 3:11 PM, Marek Olšák  wrote:
> Hi,
>
> Nothing special here, just a lot of cosmetic changes and a few 
> micro-optimizations.
>
> This series starts with some fixes for 11.0 (patches 3-5).
>
> Then it converts a half of pm4 states into atoms. All direct states are 
> converted (set_* functions and derived states). All CSOs (init_config, blend, 
> DSA, rasterizer, shaders) will remain as pm4 states.
>
> The viewport and scissor states are optimized. The main thing is that setting 
> non-zero viewports and scissors is delayed until a shader that writes 
> VIEWPORT_INDEX appears (which is typically never).
>
> The geometry and tessellation ring registers and border color registers are 
> moved to the init_config state, removing 3 more states.
>
> All shared functions for writing registers are renamed to radeon_xxx, e.g. 
> radeon_set_context_reg instead of r600_write_context_reg. 
> r600_context_bo_reloc is renamed to radeon_add_to_buffer_list. It now makes 
> sense when you're reading it.
>
> Radeonsi no longer counts how much CS space it needs for draw calls and CP 
> DMA. One need_cs_space call will make sure there are at least 2048 dwords and 
> that's it. Even that is too many, but it's safe.
>
> Uploading border colors is rewritten. Now it's using a static buffer, so the 
> limit is 4096 unique border colors per context. Thanks to that, sampler 
> states are finally immutable, which will be useful for the constant engine.
>
> Lastly, the INDIRECT_BUFFER packet is used for the init_config state on CIK 
> and later.

For the series:
Reviewed-by: Alex Deucher 

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

Re: [Mesa-dev] [PATCH] r600/sb: emit vertex clauses properly on all gpu classes.

2015-08-30 Thread Alex Deucher 
On Sun, Aug 30, 2015 at 11:43 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> I've no idea why this is restricted to r600 only, but we should
> use vertex fetches anywhere the input shader would use them from
> what I can see.

IIRC, the only difference between a vertex fetch and a texture fetch
is which cache is used (VC or TC).  Various asics only have a TC and
eventually the VC was removed for everything.

Alex

>
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/drivers/r600/sb/sb_shader.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/r600/sb/sb_shader.cpp 
> b/src/gallium/drivers/r600/sb/sb_shader.cpp
> index 6f4f784..7121b64 100644
> --- a/src/gallium/drivers/r600/sb/sb_shader.cpp
> +++ b/src/gallium/drivers/r600/sb/sb_shader.cpp
> @@ -601,7 +601,7 @@ sched_queue_id shader::get_queue_id(node* n) {
> return SQ_ALU;
> case NST_FETCH_INST: {
> fetch_node *f = static_cast(n);
> -   if (ctx.is_r600() && (f->bc.op_ptr->flags & FF_VTX))
> +   if ((f->bc.op_ptr->flags & FF_VTX))
> return SQ_VTX;
> return SQ_TEX;
> }
> --
> 2.1.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600g: fix calculation for gpr allocation

2015-08-31 Thread Alex Deucher 
On Mon, Aug 31, 2015 at 10:34 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> I've been chasing a geom shader hang on rv635 since I wrote
> r600 geom code, and finally I hacked some values from fglrx
> in and I could run texelfetch without failures.
>
> This is totally my fault as well, maths fail 101.
>
> This makes geom shaders on r600 not fail heavily.
>
> Cc: "10.6" "11.0" 
> Signed-off-by: Dave Airlie 

Reviewed-by: Alex Deucher 

> ---
>  src/gallium/drivers/r600/r600_state.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/r600/r600_state.c 
> b/src/gallium/drivers/r600/r600_state.c
> index dcbddf3..680051f 100644
> --- a/src/gallium/drivers/r600/r600_state.c
> +++ b/src/gallium/drivers/r600/r600_state.c
> @@ -2051,7 +2051,7 @@ bool r600_adjust_gprs(struct r600_context *rctx)
> /* always privilege vs stage so that at worst we have 
> the
>  * pixel stage producing wrong output (not the vertex
>  * stage) */
> -   new_num_ps_gprs = max_gprs - ((new_num_vs_gprs - 
> new_num_es_gprs - new_num_gs_gprs) + def_num_clause_temp_gprs * 2);
> +   new_num_ps_gprs = max_gprs - ((new_num_vs_gprs + 
> new_num_es_gprs + new_num_gs_gprs) + def_num_clause_temp_gprs * 2);
> new_num_vs_gprs = num_vs_gprs;
> new_num_gs_gprs = num_gs_gprs;
> new_num_es_gprs = num_es_gprs;
> --
> 2.1.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Revert "st/vdpau: use linear layout for output surfaces"

2016-09-16 Thread Alex Deucher 
On Fri, Sep 16, 2016 at 4:03 AM, Christian König
 wrote:
> Am 16.09.2016 um 09:50 schrieb Michel Dänzer:
>>
>> On 16/09/16 04:33 PM, Christian König wrote:
>>>
>>> Am 15.09.2016 um 21:43 schrieb Dave Airlie:

 On 15 September 2016 at 17:43, Christian König
  wrote:
>
> Am 15.09.2016 um 06:00 schrieb Ilia Mirkin:
>>
>> On Wed, Sep 14, 2016 at 11:58 PM, Dave Airlie 
>> wrote:
>>>
>>> From: Dave Airlie 
>>>
>>> This reverts commit d180de35320eafa3df3d76f0e82b332656530126.
>>>
>>> This is a radeon specific hack that causes problems on nouveau
>>> when combined with the SHARED flag later. If radeonsi needs a fix
>>> for this, please fix it in the driver.
>
> Actually it isn't radeon specific. Using linear surfaces for this makes
> sense because tilling isn't beneficial and the surfaces can
> potentially be
> shared with other GPUs using the VDPAU OpenGL interop.

 Who says tiling isn't beneficial though? Maybe on other GPUs tiling
 might be, it
 still seems like a radeon centric view to me.
>>>
>>> Tiling helps with the memory throughput because it makes pixels which
>>> are rendered together appear near to each other in the memory layout as
>>> well.
>>>
>>> Since multimedia as well as compute applications usually always render
>>> to the whole texture/array/matrix it usually makes no sense at all to
>>> enable it for those tasks.
>>
>> Are you sure about that? Tiling also affects the order of memory accesses,
>> which could affect performance even when all pixels of a surface are
>> written.
>
>
> I can't 100% rule that out, but the hardware I've encountered so far orders
> the execution by the memory layout of the output buffer which is written to
> maximize throughput.
>
> On the other hand I never double checked how the MC on AMD hardware really
> works in the documentation, just toke some measurements and it didn't seemed
> to be beneficial at all.
>
> tiling/shuffling can actually hurt performance quite a bit when the whole
> buffer is written and the execution order doesn't follow the memory pattern,
> so I think we would have noticed that.

Tiling also hurts with GTT buffers due to the way pcie transactions work.

Alex

>
> Where tilling could help quite a bit is with the video surfaces, cause the
> deinterlacing shaders need to read them quite extensively, but unfortunately
> our decoding hardware can't fill it in the way it is needed.
>
> Regards,
> Christian.
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: emit TA_CS_BC_BASE_ADDR on SI only if the kernel allows it

2016-10-10 Thread Alex Deucher 
On Mon, Oct 10, 2016 at 7:25 AM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> The kernel patch has been sent to amd-gfx.

Reviewed-by: Alex Deucher 

> ---
>  src/gallium/drivers/radeonsi/si_compute.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
> b/src/gallium/drivers/radeonsi/si_compute.c
> index 1d1df2f..8a803c9 100644
> --- a/src/gallium/drivers/radeonsi/si_compute.c
> +++ b/src/gallium/drivers/radeonsi/si_compute.c
> @@ -244,21 +244,26 @@ static void si_initialize_compute(struct si_context 
> *sctx)
> }
>
> /* Set the pointer to border colors. */
> bc_va = sctx->border_color_buffer->gpu_address;
>
> if (sctx->b.chip_class >= CIK) {
> radeon_set_uconfig_reg_seq(cs, R_030E00_TA_CS_BC_BASE_ADDR, 
> 2);
> radeon_emit(cs, bc_va >> 8);  /* R_030E00_TA_CS_BC_BASE_ADDR 
> */
> radeon_emit(cs, bc_va >> 40); /* 
> R_030E04_TA_CS_BC_BASE_ADDR_HI */
> } else {
> -   radeon_set_config_reg(cs, R_00950C_TA_CS_BC_BASE_ADDR, bc_va 
> >> 8);
> +   if (sctx->screen->b.info.drm_major == 3 ||
> +   (sctx->screen->b.info.drm_major == 2 &&
> +sctx->screen->b.info.drm_minor >= 48)) {
> +   radeon_set_config_reg(cs, R_00950C_TA_CS_BC_BASE_ADDR,
> + bc_va >> 8);
> +   }
> }
>
> sctx->cs_shader_state.emitted_program = NULL;
> sctx->cs_shader_state.initialized = true;
>  }
>
>  static bool si_setup_compute_scratch_buffer(struct si_context *sctx,
>  struct si_shader *shader,
>  struct si_shader_config *config)
>  {
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/6] gallium/radeon: change the vendor string to Advanced Micro Devices, Inc.

2016-08-08 Thread Alex Deucher 
On Sat, Aug 6, 2016 at 2:04 PM, Marek Olšák  wrote:
> From: Marek Olšák 

If we want to display the marking names for each asic, we could add
the marketing name api from libdrm_amdgpu that the closed driver uses.
It would also reduce the delta between open and pro.

Alex

>
> ---
>  src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
> b/src/gallium/drivers/radeon/r600_pipe_common.c
> index 1c56e6e..8a9ab94 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
> @@ -598,21 +598,21 @@ static const struct debug_named_value 
> common_debug_options[] = {
> { "mono", DBG_MONOLITHIC_SHADERS, "Use old-style monolithic shaders 
> compiled on demand" },
> { "noce", DBG_NO_CE, "Disable the constant engine"},
> { "unsafemath", DBG_UNSAFE_MATH, "Enable unsafe math shader 
> optimizations" },
> { "nodccfb", DBG_NO_DCC_FB, "Disable separate DCC on the main 
> framebuffer" },
>
> DEBUG_NAMED_VALUE_END /* must be last */
>  };
>
>  static const char* r600_get_vendor(struct pipe_screen* pscreen)
>  {
> -   return "X.Org";
> +   return "Advanced Micro Devices, Inc.";
>  }
>
>  static const char* r600_get_device_vendor(struct pipe_screen* pscreen)
>  {
> return "AMD";
>  }
>
>  static const char* r600_get_chip_name(struct r600_common_screen *rscreen)
>  {
> switch (rscreen->info.family) {
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] winsys/amdgpu: initial SI support

2016-08-22 Thread Alex Deucher 
On Fri, Aug 19, 2016 at 5:11 AM, Marek Olšák  wrote:
> From: Ronie Salgado 
>
> ---
>  src/gallium/winsys/amdgpu/drm/amdgpu_cs.c  | 18 ++
>  src/gallium/winsys/amdgpu/drm/amdgpu_surface.c |  9 +++--
>  src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c  | 25 +
>  3 files changed, 46 insertions(+), 6 deletions(-)
>
> diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c 
> b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
> index b171cc5..bf3e306 100644
> --- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
> +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
> @@ -973,27 +973,37 @@ static int amdgpu_cs_flush(struct radeon_winsys_cs *rcs,
>  {
> struct amdgpu_cs *cs = amdgpu_cs(rcs);
> struct amdgpu_winsys *ws = cs->ctx->ws;
> int error_code = 0;
>
> rcs->current.max_dw += amdgpu_cs_epilog_dws(cs->ring_type);
>
> switch (cs->ring_type) {
> case RING_DMA:
>/* pad DMA ring to 8 DWs */
> -  while (rcs->current.cdw & 7)
> - OUT_CS(rcs, 0x); /* NOP packet */
> +  if (ws->info.chip_class <= SI) {
> + while (rcs->current.cdw & 7)
> +OUT_CS(rcs, 0xf000); /* NOP packet */
> +  } else {
> + while (rcs->current.cdw & 7)
> +OUT_CS(rcs, 0x); /* NOP packet */
> +  }
>break;
> case RING_GFX:
>/* pad GFX ring to 8 DWs to meet CP fetch alignment requirements */
> -  while (rcs->current.cdw & 7)
> - OUT_CS(rcs, 0x1000); /* type3 nop packet */
> +  if (ws->info.gfx_ib_pad_with_type2) {

Do we need gfx_ib_pad_with_type2?  Can we just check
ws->info.chip_class <= SI here?  That would be cleaner and more
consistent IMHO.

Alex

> + while (rcs->current.cdw & 7)
> +OUT_CS(rcs, 0x8000); /* type2 nop packet */
> +  } else {
> + while (rcs->current.cdw & 7)
> +OUT_CS(rcs, 0x1000); /* type3 nop packet */
> +  }
>
>/* Also pad the const IB. */
>if (cs->const_ib.ib_mapped)
>   while (!cs->const_ib.base.current.cdw || 
> (cs->const_ib.base.current.cdw & 7))
>  OUT_CS(&cs->const_ib.base, 0x1000); /* type3 nop packet */
>
>if (cs->const_preamble_ib.ib_mapped)
>   while (!cs->const_preamble_ib.base.current.cdw || 
> (cs->const_preamble_ib.base.current.cdw & 7))
>  OUT_CS(&cs->const_preamble_ib.base, 0x1000);
>break;
> diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_surface.c 
> b/src/gallium/winsys/amdgpu/drm/amdgpu_surface.c
> index 615d5a2..60c3cb9 100644
> --- a/src/gallium/winsys/amdgpu/drm/amdgpu_surface.c
> +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_surface.c
> @@ -119,22 +119,27 @@ ADDR_HANDLE amdgpu_addr_create(struct amdgpu_winsys *ws)
> addrCreateInput.size = sizeof(ADDR_CREATE_INPUT);
> addrCreateOutput.size = sizeof(ADDR_CREATE_OUTPUT);
>
> regValue.noOfBanks = ws->amdinfo.mc_arb_ramcfg & 0x3;
> regValue.gbAddrConfig = ws->amdinfo.gb_addr_cfg;
> regValue.noOfRanks = (ws->amdinfo.mc_arb_ramcfg & 0x4) >> 2;
>
> regValue.backendDisables = ws->amdinfo.backend_disable[0];
> regValue.pTileConfig = ws->amdinfo.gb_tile_mode;
> regValue.noOfEntries = ARRAY_SIZE(ws->amdinfo.gb_tile_mode);
> -   regValue.pMacroTileConfig = ws->amdinfo.gb_macro_tile_mode;
> -   regValue.noOfMacroEntries = ARRAY_SIZE(ws->amdinfo.gb_macro_tile_mode);
> +   if(ws->info.chip_class == SI) {
> +  regValue.pMacroTileConfig = NULL;
> +  regValue.noOfMacroEntries = 0;
> +   } else {
> +  regValue.pMacroTileConfig = ws->amdinfo.gb_macro_tile_mode;
> +  regValue.noOfMacroEntries = ARRAY_SIZE(ws->amdinfo.gb_macro_tile_mode);
> +   }
>
> createFlags.value = 0;
> createFlags.useTileIndex = 1;
> createFlags.degradeBaseLevel = 1;
>
> addrCreateInput.chipEngine = CIASICIDGFXENGINE_SOUTHERNISLAND;
> addrCreateInput.chipFamily = ws->family;
> addrCreateInput.chipRevision = ws->rev_id;
> addrCreateInput.createFlags = createFlags;
> addrCreateInput.callbacks.allocSysMem = allocSysMem;
> diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c 
> b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
> index d8aed8b..1aa662c 100644
> --- a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
> +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
> @@ -208,35 +208,57 @@ static bool do_winsys_init(struct amdgpu_winsys *ws, 
> int fd)
>
> default:
>fprintf(stderr, "amdgpu: Invalid PCI ID.\n");
>goto fail;
> }
>
> if (ws->info.family >= CHIP_TONGA)
>ws->info.chip_class = VI;
> else if (ws->info.family >= CHIP_BONAIRE)
>ws->info.chip_class = CIK;
> +   else if(ws->info.family >= CHIP_TAHITI)
> +  ws->info.chip_class = SI;
> else {
>fprintf(stderr, "amdgpu: Unknown family.\n");
>goto fail;
> }
>
> /* LLVM 3.6.1 is required for VI. */
> if (ws->info.chip_class >= VI &&
> HAVE_LLVM == 0x0306 && MESA_LLVM_VERSION_

Re: [Mesa-dev] [PATCH] gallium/util: fix error detection in s3tc init

2016-08-22 Thread Alex Deucher 
On Mon, Aug 22, 2016 at 1:57 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> On Mon, Aug 22, 2016 at 7:47 PM, Matt Turner  wrote:
>> On Mon, Aug 22, 2016 at 10:41 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>>> On Mon, Aug 22, 2016 at 7:24 PM, Rob Clark  wrote:
 On Mon, Aug 22, 2016 at 12:58 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> I am marking this patch as rejected at Patchwork.
>
> Reason: The patch moved from the 1st page to the 2nd page of
> https://patchwork.freedesktop.org/project/mesa/series/?ordering=-last_updated
>
> Although I am letting it go you can still merge it to master if you want 
> to.

 btw, you might just need to ask Jose to push the patch for you, since
 he already reviewed it
>>>
>>> Will it lower the probability of reappearance of the same situation in
>>> the future?
>>
>> The world does not revolve around you.
>>
>> If you're unable or unwilling to accept that, you may not be capable
>> of working collaboratively on free software projects like Mesa.
>
> If you are incapable of merging trivial patches sent by me then how
> can I expect you to merge 100 times more complex patches in the
> future?

We are all busy and don't necessarily remember who all has commit
access; sometimes things fall through the cracks.  If you don't, you
will need to make sure you patch gets applied by someone with commit
access.  A gentle reminder is usually all you need.

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

Re: [Mesa-dev] [PATCH 1/4] winsys/amdgpu: initial SI support

2016-08-22 Thread Alex Deucher 
On Mon, Aug 22, 2016 at 4:20 PM, Marek Olšák  wrote:
> On Mon, Aug 22, 2016 at 5:00 PM, Alex Deucher  wrote:
>> On Fri, Aug 19, 2016 at 5:11 AM, Marek Olšák  wrote:
>>> From: Ronie Salgado 
>>>
>>> ---
>>>  src/gallium/winsys/amdgpu/drm/amdgpu_cs.c  | 18 ++
>>>  src/gallium/winsys/amdgpu/drm/amdgpu_surface.c |  9 +++--
>>>  src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c  | 25 
>>> +
>>>  3 files changed, 46 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c 
>>> b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
>>> index b171cc5..bf3e306 100644
>>> --- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
>>> +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
>>> @@ -973,27 +973,37 @@ static int amdgpu_cs_flush(struct radeon_winsys_cs 
>>> *rcs,
>>>  {
>>> struct amdgpu_cs *cs = amdgpu_cs(rcs);
>>> struct amdgpu_winsys *ws = cs->ctx->ws;
>>> int error_code = 0;
>>>
>>> rcs->current.max_dw += amdgpu_cs_epilog_dws(cs->ring_type);
>>>
>>> switch (cs->ring_type) {
>>> case RING_DMA:
>>>/* pad DMA ring to 8 DWs */
>>> -  while (rcs->current.cdw & 7)
>>> - OUT_CS(rcs, 0x); /* NOP packet */
>>> +  if (ws->info.chip_class <= SI) {
>>> + while (rcs->current.cdw & 7)
>>> +OUT_CS(rcs, 0xf000); /* NOP packet */
>>> +  } else {
>>> + while (rcs->current.cdw & 7)
>>> +OUT_CS(rcs, 0x); /* NOP packet */
>>> +  }
>>>break;
>>> case RING_GFX:
>>>/* pad GFX ring to 8 DWs to meet CP fetch alignment requirements */
>>> -  while (rcs->current.cdw & 7)
>>> - OUT_CS(rcs, 0x1000); /* type3 nop packet */
>>> +  if (ws->info.gfx_ib_pad_with_type2) {
>>
>> Do we need gfx_ib_pad_with_type2?  Can we just check
>> ws->info.chip_class <= SI here?  That would be cleaner and more
>> consistent IMHO.
>
> Yeah, it would be somewhat cleaner from the winsys point of view.
> However, radeonsi already uses gfx_ib_pad_with_type2 for padding IBs
> within an IB.

Ah, ok, I didn't realize it was already used elsewhere.

>
> Maybe we can pad IBs with type3 unconditionally? Does the latest
> firmware support that? (if we used the latest firmware, that is)

You'll have to double check with the CP guys, but I don't think the
new type3 single dw nop is supported on SI.  I think the motivation
for it was actually for compute (CIK+ has separate MEC engines, SI is
still unified).  They didn't want to support type2 packets on the MEC.

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

Re: [Mesa-dev] [PATCH] gallium/postprocess: Fix resource freeing

2016-08-31 Thread Alex Deucher 
On Wed, Aug 31, 2016 at 2:22 AM, Thomas Hellstrom  wrote:
> The code was triggering asserts in DEBUG builds of the SVGA driver since
> the reference count of the resource was never decremented before destroy.
>
> Signed-off-by: Thomas Hellstrom 
> Reviewed-by: Brian Paul 

Reviewed-by: Alex Deucher 


> ---
>  src/gallium/auxiliary/postprocess/pp_mlaa.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/auxiliary/postprocess/pp_mlaa.c 
> b/src/gallium/auxiliary/postprocess/pp_mlaa.c
> index 502fcf1..0edd01f 100644
> --- a/src/gallium/auxiliary/postprocess/pp_mlaa.c
> +++ b/src/gallium/auxiliary/postprocess/pp_mlaa.c
> @@ -353,13 +353,11 @@ void
>  pp_jimenezmlaa_free(struct pp_queue_t *ppq, unsigned int n)
>  {
> if (ppq->areamaptex) {
> -  ppq->p->screen->resource_destroy(ppq->p->screen, ppq->areamaptex);
> -  ppq->areamaptex = NULL;
> +  pipe_resource_reference(&ppq->areamaptex, NULL);
> }
>
> if (ppq->constbuf) {
> -  ppq->p->screen->resource_destroy(ppq->p->screen, ppq->constbuf);
> -  ppq->constbuf = NULL;
> +  pipe_resource_reference(&ppq->constbuf, NULL);
> }
>  }
>
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] loader/dri3: Overhaul dri3_update_num_back

2016-09-01 Thread Alex Deucher 
On Thu, Sep 1, 2016 at 11:28 AM, Jason Ekstrand  wrote:
> On Aug 31, 2016 11:39 PM, "Michel Dänzer"  wrote:
>>
>> On 01/09/16 02:05 PM, Jason Ekstrand wrote:
>> >
>> >
>> > On Wed, Aug 31, 2016 at 7:00 PM, Michel Dänzer > > > wrote:
>> >
>> > On 31/08/16 11:21 PM, Jason Ekstrand wrote:
>> > > On Aug 19, 2016 12:07 AM, "Michel Dänzer" > > 
>> > > >> wrote:
>> > >> From: Michel Dänzer > > 
>> > > >>
>> > >>
>> > >> Always use 3 buffers when flipping. With only 2 buffers, we have
>> > to wait
>> > >> for a flip to complete (which takes non-0 time even with
>> > asynchronous
>> > >> flips) before we can start working on the next frame. We were
>> > previously
>> > >> only using 2 buffers for flipping if the X server supports
>> > asynchronous
>> > >> flips, even when we're not using asynchronous flips. This could
>> > result
>> > >> in bad performance (the referenced bug report is an extreme case,
>> > where
>> > >> the inter-frame stalls were preventing the GPU from reaching its
>> > maximum
>> > >> clocks).
>> > >
>> > > Sorry for the post-push review but I don't usually pay much
>> > attention to
>> > > the window system code.  In any case, I believe you're doing your
>> > > counting wrong.  When flipping with swapinterval=0, you need 4
>> > buffers:
>> > >
>> > > 1. The buffer currently being scanned out  (will be released at
>> > next vblank)
>> > > 2. The buffer X has queued for scanout but is waiting on vblank
>> >
>> > s/vblank/flip/g, since async flips may not wait for vblank, but
>> > yeah.
>> >
>> > > 3. The buffer the application has just submitted which X will
>> > queue next
>> > > of it doesn't get another before the window closes.
>> > > 4. The buffer the application is using for rendering.
>> > >
>> > > With only 3, you get a stall during that window in which X has
>> > queued
>> > > another flip but we're waiting on vblank before the flip begins.
>> > An I
>> > > missing something?
>> >
>> > Nothing, except maybe the paragraph below stating that I couldn't
>> > measure any benefit from using 4 buffers. :) I'm not exactly sure
>> > why,
>> > but I suspect it might be because even with just 3 buffers, the GPU
>> > can
>> > always work on at least one frame ahead of time.
>> >
>> > Also note that even before my change, we were only using 3 buffers
>> > when
>> > the X driver supports async flips (with swap interval 0; only 2
>> > buffers
>> > with swap interval > 0).
>> >
>> >
>> > Yes, because with async flips you don't have a buffer sitting queued in
>> > the kernel waiting to be flipped which you can't cancel.
>>
>> Actually, there is. Even async flips take non-0 time to complete.
>>
>>
>> > that makes perfect sense.
>>
>> What exactly does? My change may not be perfect, but the logic before it
>> was mostly backwards.
>
> I think perhaps the problem here is that I don't know what you mean by
> "async flips".  It's an X term that obviously does not mean what I thought
> it meant.

Async means immediate (or as close to it as possibly, maybe hsync
depending on the hw) not at vsync.

Alex

>
>> > That said, I'd be interested in hearing about any test cases where 4
>> > buffers provide a significant boost over 3.
>> >
>> >
>> > A little history that may be useful: Quadbuffering was originally added
>> > for DRI3+present here:
>> >
>> >
>> > https://cgit.freedesktop.org/mesa/mesa/commit/?id=f7a36ef5fe23056299a77414f9ad8b5e5a1d
>>
>> So the commit message claims. If you look at the code after that change
>> though, it's basically impossible to end up with 4 buffers (at least
>> permanently), since it would require all these conditions to be true at
>> the same:
>>
>> 1. priv->flipping (the last Present request was completed as a flip)
>> 2. !(priv->present_capabilities & XCB_PRESENT_CAPABILITY_ASYNC) (the X
>>driver doesn't support async flips)
>> 3. priv->swap_interval == 0
>>
>> Given 2, 1 & 3 are mutually exclusive.
>
> I'm not seeing how 1 & 3 are mutually exclusive.  priv->swap_interval
> doesn't seem to have anything to do with whether or not you're flipping.
>
>> > Unfortunately, neither of those specify precise metrics.  Eero's bug had
>> > some very concrete numbers.  Hopefully he can provide you with the
>> > details you need for further analysis.
>>
>> Indeed. FWIW, my feeling is that my change most likely just exposed
>> issues elsewhere.
>>
>>
>> --
>> Earthling Michel Dänzer   |   http://www.amd.com
>> Libre software enthusiast | Mesa and X developer
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesk

Re: [Mesa-dev] [PATCH] st/va: force to flush the last p frame in idr period

2016-10-17 Thread Alex Deucher 
On Mon, Oct 17, 2016 at 4:16 PM,   wrote:
> From: Boyuan Zhang 
>
> During dual instance encoding submission, if the second encode task and first
> encode task have no reference dependency, e.g. p following with idr-frame,
> there is a chance the second task will use for its reconstructed picture
> buffer the same buffer used by first task for its reference/reconstructed
> picture. In this case, buffer corruption may occur depending on encoding
> speed. Fix is to force flush these two tasks separately to avoid race 
> condition

Please reference the bug when this is committed.
https://bugs.freedesktop.org/show_bug.cgi?id=98005

Alex

>
> Signed-off-by: Boyuan Zhang 
> ---
>  src/gallium/state_trackers/va/picture.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/gallium/state_trackers/va/picture.c 
> b/src/gallium/state_trackers/va/picture.c
> index 7f3d96d..eae5dc4 100644
> --- a/src/gallium/state_trackers/va/picture.c
> +++ b/src/gallium/state_trackers/va/picture.c
> @@ -578,6 +578,9 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID 
> context_id)
> }
>
> context->decoder->end_frame(context->decoder, context->target, 
> &context->desc.base);
> +   if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE &&
> +   context->desc.h264enc.p_remain == 1)
> +  context->decoder->flush(context->decoder);
> pipe_mutex_unlock(drv->mutex);
> return VA_STATUS_SUCCESS;
>  }
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: set VGT_GS_ONCHIP_CNTL on CIK and later

2016-10-27 Thread Alex Deucher 
On Thu, Oct 27, 2016 at 9:40 AM, Nicolai Hähnle  wrote:
> On 26.10.2016 01:16, Marek Olšák wrote:
>>
>> From: Marek Olšák 
>>
>> ---
>>  src/gallium/drivers/radeonsi/si_state.c | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/src/gallium/drivers/radeonsi/si_state.c
>> b/src/gallium/drivers/radeonsi/si_state.c
>> index 42689da..0633b64 100644
>> --- a/src/gallium/drivers/radeonsi/si_state.c
>> +++ b/src/gallium/drivers/radeonsi/si_state.c
>> @@ -3918,20 +3918,28 @@ static void si_init_config(struct si_context
>> *sctx)
>> si_pm4_set_reg(pm4, R_028AC0_DB_SRESULTS_COMPARE_STATE0, 0x0);
>> si_pm4_set_reg(pm4, R_028AC4_DB_SRESULTS_COMPARE_STATE1, 0x0);
>> si_pm4_set_reg(pm4, R_028AC8_DB_PRELOAD_CONTROL, 0x0);
>> si_pm4_set_reg(pm4, R_02800C_DB_RENDER_OVERRIDE, 0);
>>
>> si_pm4_set_reg(pm4, R_028400_VGT_MAX_VTX_INDX, ~0);
>> si_pm4_set_reg(pm4, R_028404_VGT_MIN_VTX_INDX, 0);
>> si_pm4_set_reg(pm4, R_028408_VGT_INDX_OFFSET, 0);
>>
>> if (sctx->b.chip_class >= CIK) {
>> +   /* If this is 0, Bonaire can hang even if GS isn't being
>> used.
>> +* Other chips are unaffected. These are suboptimal
>> values,
>> +* but we don't use on-chip GS.
>> +*/
>> +   si_pm4_set_reg(pm4, R_028A44_VGT_GS_ONCHIP_CNTL,
>> +  S_028A44_ES_VERTS_PER_SUBGRP(64) |
>> +  S_028A44_GS_PRIMS_PER_SUBGRP(4));
>
>
> *sigh* Good find.
>
> Reviewed-by: Nicolai Hähnle 

CC stable?

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

Re: [Mesa-dev] [PATCH] gbm: set up the interop extension for egl/drm

2016-10-31 Thread Alex Deucher 
On Sat, Oct 29, 2016 at 7:18 AM, Marek Olšák  wrote:
> From: Marek Olšák 

Acked-by: Alex Deucher 

>
> breaking libgbm -> libEGL ABI?
> ---
>  src/egl/drivers/dri2/platform_drm.c | 1 +
>  src/gbm/backends/dri/gbm_dri.c  | 1 +
>  src/gbm/backends/dri/gbm_driint.h   | 1 +
>  3 files changed, 3 insertions(+)
>
> diff --git a/src/egl/drivers/dri2/platform_drm.c 
> b/src/egl/drivers/dri2/platform_drm.c
> index ea1a7f1..2099314 100644
> --- a/src/egl/drivers/dri2/platform_drm.c
> +++ b/src/egl/drivers/dri2/platform_drm.c
> @@ -705,20 +705,21 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
> dri2_dpy->driver_name = strdup(dri2_dpy->gbm_dri->base.driver_name);
>
> dri2_dpy->dri_screen = dri2_dpy->gbm_dri->screen;
> dri2_dpy->core = dri2_dpy->gbm_dri->core;
> dri2_dpy->dri2 = dri2_dpy->gbm_dri->dri2;
> dri2_dpy->fence = dri2_dpy->gbm_dri->fence;
> dri2_dpy->image = dri2_dpy->gbm_dri->image;
> dri2_dpy->flush = dri2_dpy->gbm_dri->flush;
> dri2_dpy->swrast = dri2_dpy->gbm_dri->swrast;
> dri2_dpy->driver_configs = dri2_dpy->gbm_dri->driver_configs;
> +   dri2_dpy->interop = dri2_dpy->gbm_dri->interop;
>
> dri2_dpy->gbm_dri->lookup_image = dri2_lookup_egl_image;
> dri2_dpy->gbm_dri->lookup_user_data = disp;
>
> dri2_dpy->gbm_dri->get_buffers = dri2_drm_get_buffers;
> dri2_dpy->gbm_dri->flush_front_buffer = dri2_drm_flush_front_buffer;
> dri2_dpy->gbm_dri->get_buffers_with_format = 
> dri2_drm_get_buffers_with_format;
> dri2_dpy->gbm_dri->image_get_buffers = dri2_drm_image_get_buffers;
> dri2_dpy->gbm_dri->swrast_put_image2 = swrast_put_image2;
> dri2_dpy->gbm_dri->swrast_get_image = swrast_get_image;
> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
> index 51c4117..5cd7318 100644
> --- a/src/gbm/backends/dri/gbm_dri.c
> +++ b/src/gbm/backends/dri/gbm_dri.c
> @@ -239,20 +239,21 @@ struct dri_extension_match {
> const char *name;
> int version;
> int offset;
> int optional;
>  };
>
>  static struct dri_extension_match dri_core_extensions[] = {
> { __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
> { __DRI_IMAGE, 1, offsetof(struct gbm_dri_device, image) },
> { __DRI2_FENCE, 2, offsetof(struct gbm_dri_device, fence), 1 },
> +   { __DRI2_INTEROP, 1, offsetof(struct gbm_dri_device, interop), 1 },
> { NULL, 0, 0 }
>  };
>
>  static struct dri_extension_match gbm_dri_device_extensions[] = {
> { __DRI_CORE, 1, offsetof(struct gbm_dri_device, core) },
> { __DRI_DRI2, 1, offsetof(struct gbm_dri_device, dri2) },
> { NULL, 0, 0 }
>  };
>
>  static struct dri_extension_match gbm_swrast_device_extensions[] = {
> diff --git a/src/gbm/backends/dri/gbm_driint.h 
> b/src/gbm/backends/dri/gbm_driint.h
> index 26376ef..29a8ec2 100644
> --- a/src/gbm/backends/dri/gbm_driint.h
> +++ b/src/gbm/backends/dri/gbm_driint.h
> @@ -51,20 +51,21 @@ struct gbm_dri_device {
> __DRIcontext *context;
> mtx_t mutex;
>
> const __DRIcoreExtension   *core;
> const __DRIdri2Extension   *dri2;
> const __DRI2fenceExtension *fence;
> const __DRIimageExtension  *image;
> const __DRIswrastExtension *swrast;
> const __DRI2flushExtension *flush;
> const __DRIdri2LoaderExtension *loader;
> +   const __DRI2interopExtension *interop;
>
> const __DRIconfig   **driver_configs;
> const __DRIextension **loader_extensions;
> const __DRIextension **driver_extensions;
>
> __DRIimage *(*lookup_image)(__DRIscreen *screen, void *image, void *data);
> void *lookup_user_data;
>
> __DRIbuffer *(*get_buffers)(__DRIdrawable * driDrawable,
> int *width, int *height,
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] glx: make interop ABI visible again

2016-11-02 Thread Alex Deucher 
On Wed, Nov 2, 2016 at 2:07 PM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> This was broken when the GLAPI use was removed from mesa_glinterop.h.
>
> Cc: 12.0 13.0 

Series is:
Acked-by: Alex Deucher 

> ---
>  src/glx/glxcmds.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
> index 6abe0b9..8980de3 100644
> --- a/src/glx/glxcmds.c
> +++ b/src/glx/glxcmds.c
> @@ -2706,21 +2706,21 @@ __glXGetUST(int64_t * ust)
>return 0;
> }
> else {
>return -errno;
> }
>  }
>  #endif /* GLX_DIRECT_RENDERING */
>
>  #if defined(GLX_DIRECT_RENDERING) && !defined(GLX_USE_APPLEGL)
>
> -int
> +PUBLIC int
>  MesaGLInteropGLXQueryDeviceInfo(Display *dpy, GLXContext context,
>  struct mesa_glinterop_device_info *out)
>  {
> struct glx_context *gc = (struct glx_context*)context;
> int ret;
>
> __glXLock();
>
> if (!gc || gc->xid == None || !gc->isDirect) {
>__glXUnlock();
> @@ -2730,21 +2730,21 @@ MesaGLInteropGLXQueryDeviceInfo(Display *dpy, 
> GLXContext context,
> if (!gc->vtable->interop_query_device_info) {
>__glXUnlock();
>return MESA_GLINTEROP_UNSUPPORTED;
> }
>
> ret = gc->vtable->interop_query_device_info(gc, out);
> __glXUnlock();
> return ret;
>  }
>
> -int
> +PUBLIC int
>  MesaGLInteropGLXExportObject(Display *dpy, GLXContext context,
>   struct mesa_glinterop_export_in *in,
>   struct mesa_glinterop_export_out *out)
>  {
> struct glx_context *gc = (struct glx_context*)context;
> int ret;
>
> __glXLock();
>
> if (!gc || gc->xid == None || !gc->isDirect) {
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Revert "st/vdpau: use linear layout for output surfaces"

2016-11-04 Thread Alex Deucher 
On Fri, Nov 4, 2016 at 10:57 AM, Marek Olšák  wrote:
> On Nov 4, 2016 3:29 PM, "Emil Velikov"  wrote:
>>
>> On 31 October 2016 at 15:12, Marek Olšák  wrote:
>> > First, DRI_PRIME should work OK on radeon & amdgpu. I've been testing
>> > it with 2 GPUs in 2 PCIe slots. (only OpenGL though)
>> >
>> > I think the thread got derailed at the beginning and nobody asked the
>> > important question:
>> >
>> > Does radeonsi need PIPE_BIND_VIDEO_DECODE_OUTPUT that it would
>> > translate into linear?
>> >
>> Agreed things got derailed a bit.
>>
>> On the patch itself, can we get an ack/r-b, please?
>> It'll be nice to have nouveau working again, until a
>> better/alternative solution is found.
>
> I'm okay with the patch. My only concern is decoding performance. If the
> decoder works in 64x1 blocks, tiling will hurt. That's the theory. I don't
> know how the decoder works.

Linear definitely performs better.  Some early UVD blocks didn't even
support tiling IIRC.

Alex

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

Re: [Mesa-dev] [PATCH] Revert "st/vdpau: use linear layout for output surfaces"

2016-11-04 Thread Alex Deucher 
On Fri, Nov 4, 2016 at 12:43 PM, Marek Olšák  wrote:
> On Fri, Nov 4, 2016 at 5:23 PM, Alex Deucher  wrote:
>> On Fri, Nov 4, 2016 at 10:57 AM, Marek Olšák  wrote:
>>> On Nov 4, 2016 3:29 PM, "Emil Velikov"  wrote:
>>>>
>>>> On 31 October 2016 at 15:12, Marek Olšák  wrote:
>>>> > First, DRI_PRIME should work OK on radeon & amdgpu. I've been testing
>>>> > it with 2 GPUs in 2 PCIe slots. (only OpenGL though)
>>>> >
>>>> > I think the thread got derailed at the beginning and nobody asked the
>>>> > important question:
>>>> >
>>>> > Does radeonsi need PIPE_BIND_VIDEO_DECODE_OUTPUT that it would
>>>> > translate into linear?
>>>> >
>>>> Agreed things got derailed a bit.
>>>>
>>>> On the patch itself, can we get an ack/r-b, please?
>>>> It'll be nice to have nouveau working again, until a
>>>> better/alternative solution is found.
>>>
>>> I'm okay with the patch. My only concern is decoding performance. If the
>>> decoder works in 64x1 blocks, tiling will hurt. That's the theory. I don't
>>> know how the decoder works.
>>
>> Linear definitely performs better.  Some early UVD blocks didn't even
>> support tiling IIRC.
>
> I've looked at the code and it looks like VdpOutputSurface is only
> used for final 3D passes and not as a decoding output, while
> VdpVideoSurface is used as a decoding output. Is that correct?

I think so, but I'm not that familiar with the video code.

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

Re: [Mesa-dev] Potentially EOL ilo gallium driver

2016-12-06 Thread Alex Deucher 
On Tue, Dec 6, 2016 at 8:42 AM, Emil Velikov  wrote:
> On 6 December 2016 at 03:16, Edward O'Callaghan
>  wrote:
>> This patch is to potentially remove ourself from the maintaince
>> burden of the ilo driver that appears to now be essentially
>> unmaintained?
>>
>> I am not sure of our policy here or if there are too many
>> users so this patch is really only to gauge a response of
>> how folks feel?
>>
> Surely you want to CC the core/sole developer of the driver when
> considering its removal.
> Maybe mailman was "nice" and hid his email in the header ;-)
>
> Either way adding Chia-I Wu to the list.
>
> -Emil
> P.S. Not sure/sold how much of an actual burden the driver is, yet I
> don't make serious gallium infra changes.

I don't know that there is that much burden.  One could argue that
pretty much all drivers for old hw are largely unmaintained.  Consider
the r300 or i915 on the gallium side or radeon or r200 or i915 on the
classic mesa side.  That said, I don't do that much work in mesa so I
defer to those that do.

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

[Mesa-dev] [PATCH 1/2] radeonsi: add Polaris12 support

2016-12-19 Thread Alex Deucher 
From: Junwei Zhang 

Signed-off-by: Junwei Zhang 
Reviewed-by: Nicolai Hähnle 
Acked-by: Christian König 
---
 src/amd/addrlib/r800/ciaddrlib.cpp| 3 ++-
 src/amd/addrlib/r800/ciaddrlib.h  | 1 +
 src/amd/common/amd_family.h   | 1 +
 src/amd/common/amdgpu_id.h| 4 
 src/gallium/drivers/radeon/r600_pipe_common.c | 6 ++
 src/gallium/drivers/radeon/radeon_vce.c   | 3 ++-
 src/gallium/drivers/radeonsi/si_pipe.c| 1 +
 src/gallium/drivers/radeonsi/si_state.c   | 1 +
 src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 4 
 9 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/src/amd/addrlib/r800/ciaddrlib.cpp 
b/src/amd/addrlib/r800/ciaddrlib.cpp
index 7c5d29a..c726c4d 100644
--- a/src/amd/addrlib/r800/ciaddrlib.cpp
+++ b/src/amd/addrlib/r800/ciaddrlib.cpp
@@ -353,6 +353,7 @@ AddrChipFamily CIAddrLib::HwlConvertChipFamily(
 m_settings.isFiji= ASICREV_IS_FIJI_P(uChipRevision);
 m_settings.isPolaris10   = 
ASICREV_IS_POLARIS10_P(uChipRevision);
 m_settings.isPolaris11   = 
ASICREV_IS_POLARIS11_M(uChipRevision);
+m_settings.isPolaris12   = 
ASICREV_IS_POLARIS12_V(uChipRevision);
 break;
 case FAMILY_CZ:
 m_settings.isCarrizo = 1;
@@ -417,7 +418,7 @@ BOOL_32 CIAddrLib::HwlInitGlobalParams(
 {
 m_pipes = 16;
 }
-else if (m_settings.isPolaris11)
+else if (m_settings.isPolaris11 || m_settings.isPolaris12)
 {
 m_pipes = 4;
 }
diff --git a/src/amd/addrlib/r800/ciaddrlib.h b/src/amd/addrlib/r800/ciaddrlib.h
index de995fa..2c9a4cc 100644
--- a/src/amd/addrlib/r800/ciaddrlib.h
+++ b/src/amd/addrlib/r800/ciaddrlib.h
@@ -62,6 +62,7 @@ struct CIChipSettings
 UINT_32 isFiji: 1;
 UINT_32 isPolaris10   : 1;
 UINT_32 isPolaris11   : 1;
+UINT_32 isPolaris12   : 1;
 // VI fusion (Carrizo)
 UINT_32 isCarrizo : 1;
 };
diff --git a/src/amd/common/amd_family.h b/src/amd/common/amd_family.h
index 6a713ad..b09bbb8 100644
--- a/src/amd/common/amd_family.h
+++ b/src/amd/common/amd_family.h
@@ -91,6 +91,7 @@ enum radeon_family {
 CHIP_STONEY,
 CHIP_POLARIS10,
 CHIP_POLARIS11,
+CHIP_POLARIS12,
 CHIP_LAST,
 };
 
diff --git a/src/amd/common/amdgpu_id.h b/src/amd/common/amdgpu_id.h
index f91df55..1683a5a 100644
--- a/src/amd/common/amdgpu_id.h
+++ b/src/amd/common/amdgpu_id.h
@@ -142,6 +142,8 @@ enum {
 
VI_POLARIS11_M_A0 = 90,
 
+   VI_POLARIS12_V_A0 = 100,
+
VI_UNKNOWN= 0xFF
 };
 
@@ -156,6 +158,8 @@ enum {
((eChipRev >= VI_POLARIS10_P_A0) && (eChipRev < VI_POLARIS11_M_A0))
 #define ASICREV_IS_POLARIS11_M(eChipRev)   \
(eChipRev >= VI_POLARIS11_M_A0)
+#define ASICREV_IS_POLARIS12_V(eChipRev)\
+   (eChipRev >= VI_POLARIS12_V_A0)
 
 /* CZ specific rev IDs */
 enum {
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 0b5c6dc..033e59c 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -755,6 +755,7 @@ static const char* r600_get_chip_name(struct 
r600_common_screen *rscreen)
case CHIP_FIJI: return "AMD FIJI";
case CHIP_POLARIS10: return "AMD POLARIS10";
case CHIP_POLARIS11: return "AMD POLARIS11";
+   case CHIP_POLARIS12: return "AMD POLARIS12";
case CHIP_STONEY: return "AMD STONEY";
default: return "AMD unknown";
}
@@ -893,6 +894,11 @@ const char *r600_get_llvm_processor_name(enum 
radeon_family family)
case CHIP_POLARIS10: return "polaris10";
case CHIP_POLARIS11: return "polaris11";
 #endif
+#if HAVE_LLVM <= 0x0309
+   case CHIP_POLARIS12: return "polaris11";
+#else
+   case CHIP_POLARIS12: return "polaris12";
+#endif
default: return "";
}
 }
diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
b/src/gallium/drivers/radeon/radeon_vce.c
index aad2ec1..dcd56ea 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -413,7 +413,8 @@ struct pipe_video_codec *rvce_create_encoder(struct 
pipe_context *context,
enc->use_vui = true;
if (rscreen->info.family >= CHIP_TONGA &&
rscreen->info.family != CHIP_STONEY &&
-   rscreen->info.family != CHIP_POLARIS11)
+   rscreen->info.family != CHIP_POLARIS11 &&
+   rscreen->info.family != CHIP_POLARIS12)
enc->dual_pipe = true;
/* TODO enable B frame with dual instance */
if ((rscreen->info.family >= CHIP_TONGA) &&
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 88685f9..11cca6f 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -734,6 +734,7 @@ static bool si_init_gs_info(struc

[Mesa-dev] [PATCH 2/2] radeonsi: add Polaris12 PCI ID

2016-12-19 Thread Alex Deucher 
From: Junwei Zhang 

Signed-off-by: Junwei Zhang 
Reviewed-by: Nicolai Hähnle 
---
 include/pci_ids/radeonsi_pci_ids.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/pci_ids/radeonsi_pci_ids.h 
b/include/pci_ids/radeonsi_pci_ids.h
index 20c1583..fca47b0 100644
--- a/include/pci_ids/radeonsi_pci_ids.h
+++ b/include/pci_ids/radeonsi_pci_ids.h
@@ -205,3 +205,10 @@ CHIPSET(0x67CF, POLARIS10_, POLARIS10)
 CHIPSET(0x67DF, POLARIS10_, POLARIS10)
 
 CHIPSET(0x98E4, STONEY_, STONEY)
+
+CHIPSET(0x6980, POLARIS12_, POLARIS12)
+CHIPSET(0x6981, POLARIS12_, POLARIS12)
+CHIPSET(0x6985, POLARIS12_, POLARIS12)
+CHIPSET(0x6986, POLARIS12_, POLARIS12)
+CHIPSET(0x6987, POLARIS12_, POLARIS12)
+CHIPSET(0x699F, POLARIS12_, POLARIS12)
-- 
2.5.5

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

[Mesa-dev] [PATCH 1/2] radeonsi: add Polaris12 support (v2)

2016-12-19 Thread Alex Deucher 
From: Junwei Zhang 

v2: use gfxip names for llvm 4.0+

Signed-off-by: Junwei Zhang 
Reviewed-by: Nicolai Hähnle 
Acked-by: Christian König 
---
 src/amd/addrlib/r800/ciaddrlib.cpp| 3 ++-
 src/amd/addrlib/r800/ciaddrlib.h  | 1 +
 src/amd/common/amd_family.h   | 1 +
 src/amd/common/amdgpu_id.h| 4 
 src/gallium/drivers/radeon/r600_pipe_common.c | 6 ++
 src/gallium/drivers/radeon/radeon_vce.c   | 3 ++-
 src/gallium/drivers/radeonsi/si_pipe.c| 1 +
 src/gallium/drivers/radeonsi/si_state.c   | 1 +
 src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 4 
 9 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/src/amd/addrlib/r800/ciaddrlib.cpp 
b/src/amd/addrlib/r800/ciaddrlib.cpp
index 7c5d29a..c726c4d 100644
--- a/src/amd/addrlib/r800/ciaddrlib.cpp
+++ b/src/amd/addrlib/r800/ciaddrlib.cpp
@@ -353,6 +353,7 @@ AddrChipFamily CIAddrLib::HwlConvertChipFamily(
 m_settings.isFiji= ASICREV_IS_FIJI_P(uChipRevision);
 m_settings.isPolaris10   = 
ASICREV_IS_POLARIS10_P(uChipRevision);
 m_settings.isPolaris11   = 
ASICREV_IS_POLARIS11_M(uChipRevision);
+m_settings.isPolaris12   = 
ASICREV_IS_POLARIS12_V(uChipRevision);
 break;
 case FAMILY_CZ:
 m_settings.isCarrizo = 1;
@@ -417,7 +418,7 @@ BOOL_32 CIAddrLib::HwlInitGlobalParams(
 {
 m_pipes = 16;
 }
-else if (m_settings.isPolaris11)
+else if (m_settings.isPolaris11 || m_settings.isPolaris12)
 {
 m_pipes = 4;
 }
diff --git a/src/amd/addrlib/r800/ciaddrlib.h b/src/amd/addrlib/r800/ciaddrlib.h
index de995fa..2c9a4cc 100644
--- a/src/amd/addrlib/r800/ciaddrlib.h
+++ b/src/amd/addrlib/r800/ciaddrlib.h
@@ -62,6 +62,7 @@ struct CIChipSettings
 UINT_32 isFiji: 1;
 UINT_32 isPolaris10   : 1;
 UINT_32 isPolaris11   : 1;
+UINT_32 isPolaris12   : 1;
 // VI fusion (Carrizo)
 UINT_32 isCarrizo : 1;
 };
diff --git a/src/amd/common/amd_family.h b/src/amd/common/amd_family.h
index 6a713ad..b09bbb8 100644
--- a/src/amd/common/amd_family.h
+++ b/src/amd/common/amd_family.h
@@ -91,6 +91,7 @@ enum radeon_family {
 CHIP_STONEY,
 CHIP_POLARIS10,
 CHIP_POLARIS11,
+CHIP_POLARIS12,
 CHIP_LAST,
 };
 
diff --git a/src/amd/common/amdgpu_id.h b/src/amd/common/amdgpu_id.h
index f91df55..1683a5a 100644
--- a/src/amd/common/amdgpu_id.h
+++ b/src/amd/common/amdgpu_id.h
@@ -142,6 +142,8 @@ enum {
 
VI_POLARIS11_M_A0 = 90,
 
+   VI_POLARIS12_V_A0 = 100,
+
VI_UNKNOWN= 0xFF
 };
 
@@ -156,6 +158,8 @@ enum {
((eChipRev >= VI_POLARIS10_P_A0) && (eChipRev < VI_POLARIS11_M_A0))
 #define ASICREV_IS_POLARIS11_M(eChipRev)   \
(eChipRev >= VI_POLARIS11_M_A0)
+#define ASICREV_IS_POLARIS12_V(eChipRev)\
+   (eChipRev >= VI_POLARIS12_V_A0)
 
 /* CZ specific rev IDs */
 enum {
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 0b5c6dc..76a34fe 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -755,6 +755,7 @@ static const char* r600_get_chip_name(struct 
r600_common_screen *rscreen)
case CHIP_FIJI: return "AMD FIJI";
case CHIP_POLARIS10: return "AMD POLARIS10";
case CHIP_POLARIS11: return "AMD POLARIS11";
+   case CHIP_POLARIS12: return "AMD POLARIS12";
case CHIP_STONEY: return "AMD STONEY";
default: return "AMD unknown";
}
@@ -893,6 +894,11 @@ const char *r600_get_llvm_processor_name(enum 
radeon_family family)
case CHIP_POLARIS10: return "polaris10";
case CHIP_POLARIS11: return "polaris11";
 #endif
+#if HAVE_LLVM <= 0x0309
+   case CHIP_POLARIS12: return "polaris11";
+#else
+   case CHIP_POLARIS12: return "gfx803";
+#endif
default: return "";
}
 }
diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
b/src/gallium/drivers/radeon/radeon_vce.c
index aad2ec1..dcd56ea 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -413,7 +413,8 @@ struct pipe_video_codec *rvce_create_encoder(struct 
pipe_context *context,
enc->use_vui = true;
if (rscreen->info.family >= CHIP_TONGA &&
rscreen->info.family != CHIP_STONEY &&
-   rscreen->info.family != CHIP_POLARIS11)
+   rscreen->info.family != CHIP_POLARIS11 &&
+   rscreen->info.family != CHIP_POLARIS12)
enc->dual_pipe = true;
/* TODO enable B frame with dual instance */
if ((rscreen->info.family >= CHIP_TONGA) &&
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 88685f9..11cca6f 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -734,6 +734,7 @@ s

[Mesa-dev] [PATCH 1/2] radeonsi: add Polaris12 support (v3)

2016-12-19 Thread Alex Deucher 
From: Junwei Zhang 

v2: use gfxip names for llvm 4.0+
v3: use tonga for llvm <= 3.8

Signed-off-by: Junwei Zhang 
Reviewed-by: Nicolai Hähnle 
Acked-by: Christian König 
---
 src/amd/addrlib/r800/ciaddrlib.cpp| 3 ++-
 src/amd/addrlib/r800/ciaddrlib.h  | 1 +
 src/amd/common/amd_family.h   | 1 +
 src/amd/common/amdgpu_id.h| 4 
 src/gallium/drivers/radeon/r600_pipe_common.c | 3 +++
 src/gallium/drivers/radeon/radeon_vce.c   | 3 ++-
 src/gallium/drivers/radeonsi/si_pipe.c| 1 +
 src/gallium/drivers/radeonsi/si_state.c   | 1 +
 src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 4 
 9 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/src/amd/addrlib/r800/ciaddrlib.cpp 
b/src/amd/addrlib/r800/ciaddrlib.cpp
index 7c5d29a..c726c4d 100644
--- a/src/amd/addrlib/r800/ciaddrlib.cpp
+++ b/src/amd/addrlib/r800/ciaddrlib.cpp
@@ -353,6 +353,7 @@ AddrChipFamily CIAddrLib::HwlConvertChipFamily(
 m_settings.isFiji= ASICREV_IS_FIJI_P(uChipRevision);
 m_settings.isPolaris10   = 
ASICREV_IS_POLARIS10_P(uChipRevision);
 m_settings.isPolaris11   = 
ASICREV_IS_POLARIS11_M(uChipRevision);
+m_settings.isPolaris12   = 
ASICREV_IS_POLARIS12_V(uChipRevision);
 break;
 case FAMILY_CZ:
 m_settings.isCarrizo = 1;
@@ -417,7 +418,7 @@ BOOL_32 CIAddrLib::HwlInitGlobalParams(
 {
 m_pipes = 16;
 }
-else if (m_settings.isPolaris11)
+else if (m_settings.isPolaris11 || m_settings.isPolaris12)
 {
 m_pipes = 4;
 }
diff --git a/src/amd/addrlib/r800/ciaddrlib.h b/src/amd/addrlib/r800/ciaddrlib.h
index de995fa..2c9a4cc 100644
--- a/src/amd/addrlib/r800/ciaddrlib.h
+++ b/src/amd/addrlib/r800/ciaddrlib.h
@@ -62,6 +62,7 @@ struct CIChipSettings
 UINT_32 isFiji: 1;
 UINT_32 isPolaris10   : 1;
 UINT_32 isPolaris11   : 1;
+UINT_32 isPolaris12   : 1;
 // VI fusion (Carrizo)
 UINT_32 isCarrizo : 1;
 };
diff --git a/src/amd/common/amd_family.h b/src/amd/common/amd_family.h
index 6a713ad..b09bbb8 100644
--- a/src/amd/common/amd_family.h
+++ b/src/amd/common/amd_family.h
@@ -91,6 +91,7 @@ enum radeon_family {
 CHIP_STONEY,
 CHIP_POLARIS10,
 CHIP_POLARIS11,
+CHIP_POLARIS12,
 CHIP_LAST,
 };
 
diff --git a/src/amd/common/amdgpu_id.h b/src/amd/common/amdgpu_id.h
index f91df55..1683a5a 100644
--- a/src/amd/common/amdgpu_id.h
+++ b/src/amd/common/amdgpu_id.h
@@ -142,6 +142,8 @@ enum {
 
VI_POLARIS11_M_A0 = 90,
 
+   VI_POLARIS12_V_A0 = 100,
+
VI_UNKNOWN= 0xFF
 };
 
@@ -156,6 +158,8 @@ enum {
((eChipRev >= VI_POLARIS10_P_A0) && (eChipRev < VI_POLARIS11_M_A0))
 #define ASICREV_IS_POLARIS11_M(eChipRev)   \
(eChipRev >= VI_POLARIS11_M_A0)
+#define ASICREV_IS_POLARIS12_V(eChipRev)\
+   (eChipRev >= VI_POLARIS12_V_A0)
 
 /* CZ specific rev IDs */
 enum {
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 0b5c6dc..e0b914c 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -755,6 +755,7 @@ static const char* r600_get_chip_name(struct 
r600_common_screen *rscreen)
case CHIP_FIJI: return "AMD FIJI";
case CHIP_POLARIS10: return "AMD POLARIS10";
case CHIP_POLARIS11: return "AMD POLARIS11";
+   case CHIP_POLARIS12: return "AMD POLARIS12";
case CHIP_STONEY: return "AMD STONEY";
default: return "AMD unknown";
}
@@ -889,9 +890,11 @@ const char *r600_get_llvm_processor_name(enum 
radeon_family family)
 #if HAVE_LLVM <= 0x0308
case CHIP_POLARIS10: return "tonga";
case CHIP_POLARIS11: return "tonga";
+   case CHIP_POLARIS12: return "tonga";
 #else
case CHIP_POLARIS10: return "polaris10";
case CHIP_POLARIS11: return "polaris11";
+   case CHIP_POLARIS12: return "polaris11";
 #endif
default: return "";
}
diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
b/src/gallium/drivers/radeon/radeon_vce.c
index aad2ec1..dcd56ea 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -413,7 +413,8 @@ struct pipe_video_codec *rvce_create_encoder(struct 
pipe_context *context,
enc->use_vui = true;
if (rscreen->info.family >= CHIP_TONGA &&
rscreen->info.family != CHIP_STONEY &&
-   rscreen->info.family != CHIP_POLARIS11)
+   rscreen->info.family != CHIP_POLARIS11 &&
+   rscreen->info.family != CHIP_POLARIS12)
enc->dual_pipe = true;
/* TODO enable B frame with dual instance */
if ((rscreen->info.family >= CHIP_TONGA) &&
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 88685f9..11cca6f 100644
--- a/

Re: [Mesa-dev] [PATCH 1/2] radeonsi: add Polaris12 support (v3)

2016-12-20 Thread Alex Deucher 
On Tue, Dec 20, 2016 at 6:49 AM, Andreas Boll
 wrote:
> 2016-12-19 23:45 GMT+01:00 Alex Deucher :
>> From: Junwei Zhang 
>>
>> v2: use gfxip names for llvm 4.0+
>> v3: use tonga for llvm <= 3.8
>>
>> Signed-off-by: Junwei Zhang 
>> Reviewed-by: Nicolai Hähnle 
>> Acked-by: Christian König 
>> ---
>
> snip
>
>> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
>> b/src/gallium/drivers/radeon/r600_pipe_common.c
>> index 0b5c6dc..e0b914c 100644
>> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
>> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
>> @@ -755,6 +755,7 @@ static const char* r600_get_chip_name(struct 
>> r600_common_screen *rscreen)
>> case CHIP_FIJI: return "AMD FIJI";
>> case CHIP_POLARIS10: return "AMD POLARIS10";
>> case CHIP_POLARIS11: return "AMD POLARIS11";
>> +   case CHIP_POLARIS12: return "AMD POLARIS12";
>> case CHIP_STONEY: return "AMD STONEY";
>> default: return "AMD unknown";
>> }
>> @@ -889,9 +890,11 @@ const char *r600_get_llvm_processor_name(enum 
>> radeon_family family)
>>  #if HAVE_LLVM <= 0x0308
>> case CHIP_POLARIS10: return "tonga";
>> case CHIP_POLARIS11: return "tonga";
>> +   case CHIP_POLARIS12: return "tonga";
>>  #else
>> case CHIP_POLARIS10: return "polaris10";
>> case CHIP_POLARIS11: return "polaris11";
>> +   case CHIP_POLARIS12: return "polaris11";
>>  #endif
>
> You've dropped the processor name for LLVM 4.0+.
> I guess that wasn't intended.

That was intended.  It didn't seem worth adding all of the additional
special cases.  If/when we convert the other asics to use gfxip names,
we can convert polaris12 as well.

Alex

> Something like this should work:
>
> #if HAVE_LLVM <= 0x0308
> // return processor names for LLVM <= 3.8
> #elif HAVE_LLVM == 0x0309
> // return processor names for LLVM 3.9
> #else
> // return processor names for LLVM > 3.9
> #endif
>
> Andreas
>
>> default: return "";
>> }
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] radeonsi: add Polaris12 support (v3)

2016-12-20 Thread Alex Deucher 
On Tue, Dec 20, 2016 at 1:34 PM, Marek Olšák  wrote:
> For the series:
>
> Reviewed-by: Marek Olšák 
>
> Has it ever been tested with Mesa?

It was tested when the code was originally written and the hybrid
stack (including mesa MM) has been tested recently.  I don't have a
polaris12 card at the moment.

Alex

>
> Marek
>
> On Mon, Dec 19, 2016 at 11:45 PM, Alex Deucher  wrote:
>> From: Junwei Zhang 
>>
>> v2: use gfxip names for llvm 4.0+
>> v3: use tonga for llvm <= 3.8
>>
>> Signed-off-by: Junwei Zhang 
>> Reviewed-by: Nicolai Hähnle 
>> Acked-by: Christian König 
>> ---
>>  src/amd/addrlib/r800/ciaddrlib.cpp| 3 ++-
>>  src/amd/addrlib/r800/ciaddrlib.h  | 1 +
>>  src/amd/common/amd_family.h   | 1 +
>>  src/amd/common/amdgpu_id.h| 4 
>>  src/gallium/drivers/radeon/r600_pipe_common.c | 3 +++
>>  src/gallium/drivers/radeon/radeon_vce.c   | 3 ++-
>>  src/gallium/drivers/radeonsi/si_pipe.c| 1 +
>>  src/gallium/drivers/radeonsi/si_state.c   | 1 +
>>  src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 4 
>>  9 files changed, 19 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/amd/addrlib/r800/ciaddrlib.cpp 
>> b/src/amd/addrlib/r800/ciaddrlib.cpp
>> index 7c5d29a..c726c4d 100644
>> --- a/src/amd/addrlib/r800/ciaddrlib.cpp
>> +++ b/src/amd/addrlib/r800/ciaddrlib.cpp
>> @@ -353,6 +353,7 @@ AddrChipFamily CIAddrLib::HwlConvertChipFamily(
>>  m_settings.isFiji= ASICREV_IS_FIJI_P(uChipRevision);
>>  m_settings.isPolaris10   = 
>> ASICREV_IS_POLARIS10_P(uChipRevision);
>>  m_settings.isPolaris11   = 
>> ASICREV_IS_POLARIS11_M(uChipRevision);
>> +m_settings.isPolaris12   = 
>> ASICREV_IS_POLARIS12_V(uChipRevision);
>>  break;
>>  case FAMILY_CZ:
>>  m_settings.isCarrizo = 1;
>> @@ -417,7 +418,7 @@ BOOL_32 CIAddrLib::HwlInitGlobalParams(
>>  {
>>  m_pipes = 16;
>>  }
>> -else if (m_settings.isPolaris11)
>> +else if (m_settings.isPolaris11 || m_settings.isPolaris12)
>>  {
>>  m_pipes = 4;
>>  }
>> diff --git a/src/amd/addrlib/r800/ciaddrlib.h 
>> b/src/amd/addrlib/r800/ciaddrlib.h
>> index de995fa..2c9a4cc 100644
>> --- a/src/amd/addrlib/r800/ciaddrlib.h
>> +++ b/src/amd/addrlib/r800/ciaddrlib.h
>> @@ -62,6 +62,7 @@ struct CIChipSettings
>>  UINT_32 isFiji: 1;
>>  UINT_32 isPolaris10   : 1;
>>  UINT_32 isPolaris11   : 1;
>> +UINT_32 isPolaris12   : 1;
>>  // VI fusion (Carrizo)
>>  UINT_32 isCarrizo : 1;
>>  };
>> diff --git a/src/amd/common/amd_family.h b/src/amd/common/amd_family.h
>> index 6a713ad..b09bbb8 100644
>> --- a/src/amd/common/amd_family.h
>> +++ b/src/amd/common/amd_family.h
>> @@ -91,6 +91,7 @@ enum radeon_family {
>>  CHIP_STONEY,
>>  CHIP_POLARIS10,
>>  CHIP_POLARIS11,
>> +CHIP_POLARIS12,
>>  CHIP_LAST,
>>  };
>>
>> diff --git a/src/amd/common/amdgpu_id.h b/src/amd/common/amdgpu_id.h
>> index f91df55..1683a5a 100644
>> --- a/src/amd/common/amdgpu_id.h
>> +++ b/src/amd/common/amdgpu_id.h
>> @@ -142,6 +142,8 @@ enum {
>>
>> VI_POLARIS11_M_A0 = 90,
>>
>> +   VI_POLARIS12_V_A0 = 100,
>> +
>> VI_UNKNOWN= 0xFF
>>  };
>>
>> @@ -156,6 +158,8 @@ enum {
>> ((eChipRev >= VI_POLARIS10_P_A0) && (eChipRev < VI_POLARIS11_M_A0))
>>  #define ASICREV_IS_POLARIS11_M(eChipRev)   \
>> (eChipRev >= VI_POLARIS11_M_A0)
>> +#define ASICREV_IS_POLARIS12_V(eChipRev)\
>> +   (eChipRev >= VI_POLARIS12_V_A0)
>>
>>  /* CZ specific rev IDs */
>>  enum {
>> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
>> b/src/gallium/drivers/radeon/r600_pipe_common.c
>> index 0b5c6dc..e0b914c 100644
>> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
>> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
>> @@ -755,6 +755,7 @@ static const char* r600_get_chip_name(struct 
>> r600_common_screen *rscreen)
>> case CHIP_FIJI: return "AMD FIJI";
>> case CHIP_POLARIS10: return "AMD POLARIS10";
>> case CHIP_POLARIS11: return "AMD POLARIS11";
>> +   case CHIP_POLARIS12: return "AMD POLARIS12";
>> case CHIP_STONEY: r

Re: [Mesa-dev] [PATCH 1/2] radeonsi: add Polaris12 support (v3)

2016-12-21 Thread Alex Deucher 
On Wed, Dec 21, 2016 at 9:40 AM, Andreas Boll
 wrote:
> 2016-12-20 16:31 GMT+01:00 Alex Deucher :
>> On Tue, Dec 20, 2016 at 6:49 AM, Andreas Boll
>>  wrote:
>>> 2016-12-19 23:45 GMT+01:00 Alex Deucher :
>>>> From: Junwei Zhang 
>>>>
>>>> v2: use gfxip names for llvm 4.0+
>>>> v3: use tonga for llvm <= 3.8
>>>>
>>>> Signed-off-by: Junwei Zhang 
>>>> Reviewed-by: Nicolai Hähnle 
>>>> Acked-by: Christian König 
>>>> ---
>>>
>>> snip
>>>
>>>> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
>>>> b/src/gallium/drivers/radeon/r600_pipe_common.c
>>>> index 0b5c6dc..e0b914c 100644
>>>> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
>>>> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
>>>> @@ -755,6 +755,7 @@ static const char* r600_get_chip_name(struct 
>>>> r600_common_screen *rscreen)
>>>> case CHIP_FIJI: return "AMD FIJI";
>>>> case CHIP_POLARIS10: return "AMD POLARIS10";
>>>> case CHIP_POLARIS11: return "AMD POLARIS11";
>>>> +   case CHIP_POLARIS12: return "AMD POLARIS12";
>>>> case CHIP_STONEY: return "AMD STONEY";
>>>> default: return "AMD unknown";
>>>> }
>>>> @@ -889,9 +890,11 @@ const char *r600_get_llvm_processor_name(enum 
>>>> radeon_family family)
>>>>  #if HAVE_LLVM <= 0x0308
>>>> case CHIP_POLARIS10: return "tonga";
>>>> case CHIP_POLARIS11: return "tonga";
>>>> +   case CHIP_POLARIS12: return "tonga";
>>>>  #else
>>>> case CHIP_POLARIS10: return "polaris10";
>>>> case CHIP_POLARIS11: return "polaris11";
>>>> +   case CHIP_POLARIS12: return "polaris11";
>>>>  #endif
>>>
>>> You've dropped the processor name for LLVM 4.0+.
>>> I guess that wasn't intended.
>>
>> That was intended.  It didn't seem worth adding all of the additional
>> special cases.  If/when we convert the other asics to use gfxip names,
>> we can convert polaris12 as well.
>>
>> Alex
>
> Ok, it just wasn't obvious from the updated commit message. Maybe
> update the v3 comment before pushing.

Will do.

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

Re: [Mesa-dev] [PATCH] radeon uvd add uvd fw version for amdgpu

2016-06-29 Thread Alex Deucher 
On Wed, Jun 29, 2016 at 11:38 AM, Leo Liu  wrote:
> From: sonjiang 
>
> Signed-off-by: sonjiang 
> Cc: "12.0" 

For the series:
Reviewed-by: Alex Deucher 

> ---
>  src/gallium/drivers/radeon/radeon_winsys.h|  1 +
>  src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 11 ++-
>  2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_winsys.h 
> b/src/gallium/drivers/radeon/radeon_winsys.h
> index afb970e..f32edf0 100644
> --- a/src/gallium/drivers/radeon/radeon_winsys.h
> +++ b/src/gallium/drivers/radeon/radeon_winsys.h
> @@ -258,6 +258,7 @@ struct radeon_info {
>  boolgfx_ib_pad_with_type2;
>  boolhas_sdma;
>  boolhas_uvd;
> +uint32_tuvd_fw_version;
>  uint32_tvce_fw_version;
>  uint32_tvce_harvest_config;
>  uint32_tclock_crystal_freq;
> diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c 
> b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
> index 72afc76..b8fb4dd 100644
> --- a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
> +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
> @@ -98,7 +98,7 @@ static bool do_winsys_init(struct amdgpu_winsys *ws, int fd)
> struct amdgpu_buffer_size_alignments alignment_info = {};
> struct amdgpu_heap_info vram, gtt;
> struct drm_amdgpu_info_hw_ip dma = {}, uvd = {}, vce = {};
> -   uint32_t vce_version = 0, vce_feature = 0;
> +   uint32_t vce_version = 0, vce_feature = 0, uvd_version = 0, uvd_feature = 
> 0;
> int r, i, j;
> drmDevicePtr devinfo;
>
> @@ -151,6 +151,13 @@ static bool do_winsys_init(struct amdgpu_winsys *ws, int 
> fd)
>goto fail;
> }
>
> +   r = amdgpu_query_firmware_version(ws->dev, AMDGPU_INFO_FW_UVD, 0, 0,
> +&uvd_version, &uvd_feature);
> +   if (r) {
> +  fprintf(stderr, "amdgpu: amdgpu_query_firmware_version(uvd) 
> failed.\n");
> +  goto fail;
> +   }
> +
> r = amdgpu_query_hw_ip_info(ws->dev, AMDGPU_HW_IP_VCE, 0, &vce);
> if (r) {
>fprintf(stderr, "amdgpu: amdgpu_query_hw_ip_info(vce) failed.\n");
> @@ -268,6 +275,8 @@ static bool do_winsys_init(struct amdgpu_winsys *ws, int 
> fd)
> ws->info.max_se = ws->amdinfo.num_shader_engines;
> ws->info.max_sh_per_se = ws->amdinfo.num_shader_arrays_per_engine;
> ws->info.has_uvd = uvd.available_rings != 0;
> +   ws->info.uvd_fw_version =
> + uvd.available_rings ? uvd_version : 0;
> ws->info.vce_fw_version =
>   vce.available_rings ? vce_version : 0;
> ws->info.has_userptr = true;
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon uvd add uvd fw version for amdgpu

2016-07-06 Thread Alex Deucher 
On Wed, Jul 6, 2016 at 11:09 AM, Jiang, Sonny  wrote:
> Hi Emil,
>
>
> Are you Okay with these?

Without these patches UVD won't work on Polaris.

Alex

>
>
> Thanks,
>
> Sonny
>
> 
> From: Jiang, Sonny
> Sent: Monday, July 4, 2016 5:33:29 PM
> To: Christian König; Emil Velikov
> Cc: 12.0; mesa-dev@lists.freedesktop.org
>
> Subject: Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon uvd add uvd fw version
> for amdgpu
>
>
> Hi Emil,
>
>
> I have added comments for each patch, and applied for branch 12.0.
>
> Please find attached patches.
>
>
> Thanks,
>
> Sonny
>
> 
> From: mesa-dev  on behalf of
> Christian König 
> Sent: Friday, July 1, 2016 8:07:51 AM
> To: Emil Velikov
> Cc: Jiang, Sonny; 12.0; mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon uvd add uvd fw version
> for amdgpu
>
> Am 01.07.2016 um 13:14 schrieb Emil Velikov:
>> Hi all,
>>
>> On 29 June 2016 at 20:20, Christian König  wrote:
>>> Am 29.06.2016 um 18:35 schrieb Alex Deucher:
>>>> On Wed, Jun 29, 2016 at 11:38 AM, Leo Liu  wrote:
>>>>> From: sonjiang 
>>>>>
>>>>> Signed-off-by: sonjiang 
>>>>> Cc: "12.0" 
>>>> For the series:
>>>> Reviewed-by: Alex Deucher 
>>>
>>> Reviewed-by: Christian König  as well.
>>>
>> Here we have three patches, suggesting a bug with absolutely no
>> information what the issue is and/or why this approach is correct.
>>
>> I'm sorry to say this, but as is, this series is not landing in
>> stable. Sonjiang, being the author of these please reply with a brief
>> justification why we want those. Before doing so I would strongly
>> recommend reading this [1] blog post.
>
> Well to put a carrot on the front of your stick: I asked what the
> firmware version patch is all about internally as well when I've seen
> those patches. So it would have even made our internal review much
> easier if Sonny added a commit message in the first place.
>
> My fault to not requesting that his answer is put as a commit message on
> the patches.
>
> On the other hand this is for Polaris, we had time pressure to get it
> out of the door and today is a public holiday in Canada. So you probably
> won't get updated message before Monday.
>
> Is that soon enough? Otherwise UVD will be broken on Polaris in the
> stable branch.
>
> Regards,
> Christian.
>
>>
>> Thanks
>> Emil
>>
>> [1] http://who-t.blogspot.co.uk/2009/12/on-commit-messages.html
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 12/12] gallium/radeon/winsyses: decrease max_alloc_size to 1/3 of largest heap

2016-08-02 Thread Alex Deucher 
On Tue, Aug 2, 2016 at 4:55 AM, Marek Olšák  wrote:
> On Tue, Aug 2, 2016 at 3:13 AM, Michel Dänzer  wrote:
>> On 01.08.2016 16:35, Michel Dänzer wrote:
>>> On 30.07.2016 06:42, Marek Olšák wrote:
 From: Marek Olšák 

 This is controversial, but I don't see a better way out of this.

 Tonga has 2 GB of VRAM and 2 GB of GTT. amdgpu is not capable of submitting
 an IB referencing 1 GB of VRAM and 1 GB of GTT. The CS ioctl never succeeds
 even though it's far below the limits.

 Without this, "dEQP-GLES2.functional.color_clear.single_rgb" fails to
 submit an IB. With this, dEQP throws a framebuffer-incomplete exception
 and kills the process.

 IMO, failing the CS ioctl is worse for stability than failing big
 allocations.
>>>
>>> I can agree with that, but this change can't reliably prevent CS ioctl
>>> failures:
>>>
>>> I believe the problem is mostly due to BOs which are pinned for scanout.
>>> Since up to 6 CRTCs can scan out different buffers at any time, in the
>>> worst case it may not be possible to place any BOs whose size is >= ~1/7
>>> of the VRAM size.
>>>
>>> At the end of the day, this needs to be solved in the kernel one way or
>>> another.
>>
>> Or if you do want to avoid the problem in userspace for now, maybe use 1
>> / (number of CRTCs + 1) instead of hardcoding 1/3?
>
> I don't know.
>
> I could avoid the problem by splitting buffers into 128MB blocks
> mapped into GPUVM consecutively, but that would prevent easy DMABUF
> sharing and CPU mappings would not be consecutive.

I think it could be fixed to a certain extent by handling migrations
to/from vram iteratively rather than trying to move the whole buffer
at once.  E.g., we may have enough room in vram, but not enough
contiguous gtt aperture or system pages to map the whole buffer to do
the transfer in one shot.

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

[Mesa-dev] [PATCH] st/xorg: Include u_surface.h for u_copy_rect

2013-10-01 Thread Alex Deucher 
Fixes build errors.

Signed-off-by: Alex Deucher 
---
 src/gallium/state_trackers/xorg/xorg_crtc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/state_trackers/xorg/xorg_crtc.c 
b/src/gallium/state_trackers/xorg/xorg_crtc.c
index 3cbffb5..0ab41b4 100644
--- a/src/gallium/state_trackers/xorg/xorg_crtc.c
+++ b/src/gallium/state_trackers/xorg/xorg_crtc.c
@@ -53,6 +53,7 @@
 #include "state_tracker/drm_driver.h"
 #include "util/u_inlines.h"
 #include "util/u_rect.h"
+#include "util/u_surface.h"
 
 #ifdef HAVE_LIBKMS
 #include "libkms/libkms.h"
-- 
1.8.3.1

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

Re: [Mesa-dev] [PATCH] radeon/winsys: fix handling in radeon_drm_cs_flush v2

2013-10-09 Thread Alex Deucher 
On Wed, Oct 9, 2013 at 10:32 AM, Christian König
 wrote:
> From: Christian König 
>
> Calling radeon_drm_cs_flush from multiple threads might cause deadlocks,
> fix this by immediately signaling the semaphore after waiting for it.
>
> This is a candidate for the stable branch(es).

Need to add:

CC: "9.2" 
CC: "9.1" 

now for stable branches.

Alex

>
> Partially fixes: https://bugs.freedesktop.org/show_bug.cgi?id=70123
>
> v2: some fixes on commit message
>
> Signed-off-by: Christian König 
> ---
>  src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 8 
>  src/gallium/winsys/radeon/drm/radeon_drm_cs.h | 1 -
>  2 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c 
> b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> index 62f7704..0782e10 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> @@ -178,7 +178,7 @@ static struct radeon_winsys_cs 
> *radeon_drm_cs_create(struct radeon_winsys *rws,
>  if (!cs) {
>  return NULL;
>  }
> -pipe_semaphore_init(&cs->flush_completed, 0);
> +pipe_semaphore_init(&cs->flush_completed, 1);
>
>  cs->ws = ws;
>  cs->trace_buf = (struct radeon_bo*)trace_buf;
> @@ -453,9 +453,9 @@ void radeon_drm_cs_sync_flush(struct radeon_winsys_cs 
> *rcs)
>  struct radeon_drm_cs *cs = radeon_drm_cs(rcs);
>
>  /* Wait for any pending ioctl to complete. */
> -if (cs->ws->thread && cs->flush_started) {
> +if (cs->ws->thread) {
>  pipe_semaphore_wait(&cs->flush_completed);
> -cs->flush_started = 0;
> +pipe_semaphore_signal(&cs->flush_completed);
>  }
>  }
>
> @@ -567,7 +567,7 @@ static void radeon_drm_cs_flush(struct radeon_winsys_cs 
> *rcs, unsigned flags, ui
>  }
>
>  if (cs->ws->thread) {
> -cs->flush_started = 1;
> +pipe_semaphore_wait(&cs->flush_completed);
>  radeon_drm_ws_queue_cs(cs->ws, cs);
>  if (!(flags & RADEON_FLUSH_ASYNC))
>  radeon_drm_cs_sync_flush(rcs);
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.h 
> b/src/gallium/winsys/radeon/drm/radeon_drm_cs.h
> index 7683e96..ebec161 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.h
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.h
> @@ -76,7 +76,6 @@ struct radeon_drm_cs {
>  void (*flush_cs)(void *ctx, unsigned flags);
>  void *flush_data;
>
> -int flush_started;
>  pipe_semaphore flush_completed;
>  struct radeon_bo*trace_buf;
>  };
> --
> 1.8.1.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] PATCH: R600: Fix handling of kernel arguments

2013-10-15 Thread Alex Deucher 
Did you forget the attachments?

On Tue, Oct 15, 2013 at 12:40 PM, Tom Stellard  wrote:
> Hi,
>
> The attached patches fix various bugs in the handling of kernel arguments
> in the R600 backend.  The main problem with the old implementations was
> that it disagreed with clover on type size and alignment, so vector
> arguments were not being loaded correctly into the kernel.
>
> This series depends on this patch:
>
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131014/191252.html
>
> Please review and test.
>
> -Tom
> ___
> llvm-commits mailing list
> llvm-comm...@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallivm: Remove llvm::DisablePrettyStackTrace for LLVM >= 3.4.

2013-11-04 Thread Alex Deucher 
On Mon, Nov 4, 2013 at 9:41 AM, Tom Stellard  wrote:
> On Sun, Nov 03, 2013 at 08:35:47PM -0800, Vinson Lee wrote:
>> LLVM 3.4 r193971 removed llvm::DisablePrettyStackTrace and made the
>> pretty stack trace opt-in rather than opt-out.
>>
>
> Could you add a comment explaining that the default value of
> DisablePrettyStackTrace has changed to true in LLVM 3.4 and newer.
> Otherwise, I think people may be confused about why this change was
> made.
>
> With that change, the patch is:
>
> Reviewed-by: Tom Stellard 

Also apparently fixes this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=60929

Alex

>
>> Signed-off-by: Vinson Lee 
>> ---
>>  src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp 
>> b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
>> index e8d2db2..65c02d8 100644
>> --- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
>> +++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
>> @@ -174,12 +174,14 @@ lp_set_target_options(void)
>> }
>>  #endif
>>
>> +#if HAVE_LLVM < 0x0304
>> /*
>>  * By default LLVM adds a signal handler to output a pretty stack trace.
>>  * This signal handler is never removed, causing problems when unloading 
>> the
>>  * shared object where the gallium driver resides.
>>  */
>> llvm::DisablePrettyStackTrace = true;
>> +#endif
>>
>> // If we have a native target, initialize it to ensure it is linked in 
>> and
>> // usable by the JIT.
>> --
>> 1.8.3.2
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] radeon / r200: Don't pass unused parameters to radeon_viewport

2013-11-04 Thread Alex Deucher 
On Fri, Nov 1, 2013 at 3:44 PM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> The x, y, width, and height parameters aren't used by radeon_viewport,
> so don't pass them.  This should make future changes to the
> dd_function_table::Viewport interface a little easier.
>
> Signed-off-by: Ian Romanick 
> Cc: Courtney Goeltzenleuchter 
> Cc: Jordan Justen 

Seems fine to me.

Acked-by: Alex Deucher 

> ---
>  src/mesa/drivers/dri/r200/r200_state.c  | 7 ++-
>  src/mesa/drivers/dri/radeon/radeon_common.c | 2 +-
>  src/mesa/drivers/dri/radeon/radeon_common.h | 2 +-
>  src/mesa/drivers/dri/radeon/radeon_state.c  | 7 ++-
>  4 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/r200/r200_state.c 
> b/src/mesa/drivers/dri/r200/r200_state.c
> index d3e8114..ee7b945 100644
> --- a/src/mesa/drivers/dri/r200/r200_state.c
> +++ b/src/mesa/drivers/dri/r200/r200_state.c
> @@ -1603,13 +1603,18 @@ void r200_vtbl_update_scissor( struct gl_context *ctx 
> )
>  static void r200Viewport( struct gl_context *ctx, GLint x, GLint y,
> GLsizei width, GLsizei height )
>  {
> +   (void) x;
> +   (void) y;
> +   (void) width;
> +   (void) height;
> +
> /* Don't pipeline viewport changes, conflict with window offset
>  * setting below.  Could apply deltas to rescue pipelined viewport
>  * values, or keep the originals hanging around.
>  */
> r200UpdateWindow( ctx );
>
> -   radeon_viewport(ctx, x, y, width, height);
> +   radeon_viewport(ctx);
>  }
>
>  static void r200DepthRange( struct gl_context *ctx, GLclampd nearval,
> diff --git a/src/mesa/drivers/dri/radeon/radeon_common.c 
> b/src/mesa/drivers/dri/radeon/radeon_common.c
> index 0f0945d..7be0ba7 100644
> --- a/src/mesa/drivers/dri/radeon/radeon_common.c
> +++ b/src/mesa/drivers/dri/radeon/radeon_common.c
> @@ -407,7 +407,7 @@ void radeon_window_moved(radeonContextPtr radeon)
> radeonSetCliprects(radeon);
>  }
>
> -void radeon_viewport(struct gl_context *ctx, GLint x, GLint y, GLsizei 
> width, GLsizei height)
> +void radeon_viewport(struct gl_context *ctx)
>  {
> radeonContextPtr radeon = RADEON_CONTEXT(ctx);
> __DRIcontext *driContext = radeon->dri.context;
> diff --git a/src/mesa/drivers/dri/radeon/radeon_common.h 
> b/src/mesa/drivers/dri/radeon/radeon_common.h
> index 636822f..69a1727 100644
> --- a/src/mesa/drivers/dri/radeon/radeon_common.h
> +++ b/src/mesa/drivers/dri/radeon/radeon_common.h
> @@ -23,7 +23,7 @@ void radeon_window_moved(radeonContextPtr radeon);
>  void radeon_draw_buffer(struct gl_context *ctx, struct gl_framebuffer *fb);
>  void radeonDrawBuffer( struct gl_context *ctx, GLenum mode );
>  void radeonReadBuffer( struct gl_context *ctx, GLenum mode );
> -void radeon_viewport(struct gl_context *ctx, GLint x, GLint y, GLsizei 
> width, GLsizei height);
> +void radeon_viewport(struct gl_context *ctx);
>  void radeon_fbo_init(struct radeon_context *radeon);
>  void
>  radeon_renderbuffer_set_bo(struct radeon_renderbuffer *rb,
> diff --git a/src/mesa/drivers/dri/radeon/radeon_state.c 
> b/src/mesa/drivers/dri/radeon/radeon_state.c
> index 70542f6..625271d 100644
> --- a/src/mesa/drivers/dri/radeon/radeon_state.c
> +++ b/src/mesa/drivers/dri/radeon/radeon_state.c
> @@ -1386,13 +1386,18 @@ void radeonUpdateWindow( struct gl_context *ctx )
>  static void radeonViewport( struct gl_context *ctx, GLint x, GLint y,
> GLsizei width, GLsizei height )
>  {
> +   (void) x;
> +   (void) y;
> +   (void) width;
> +   (void) height;
> +
> /* Don't pipeline viewport changes, conflict with window offset
>  * setting below.  Could apply deltas to rescue pipelined viewport
>  * values, or keep the originals hanging around.
>  */
> radeonUpdateWindow( ctx );
>
> -   radeon_viewport(ctx, x, y, width, height);
> +   radeon_viewport(ctx);
>  }
>
>  static void radeonDepthRange( struct gl_context *ctx, GLclampd nearval,
> --
> 1.8.1.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] radeonsi: add support for Hawaii asics (v2)

2013-11-13 Thread Alex Deucher 
Update additional register fields.

Signed-off-by: Alex Deucher 
---
 src/gallium/drivers/radeonsi/radeonsi_pipe.c  | 2 ++
 src/gallium/drivers/radeonsi/si_state.c   | 4 
 src/gallium/drivers/radeonsi/sid.h| 9 +
 src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 1 +
 src/gallium/winsys/radeon/drm/radeon_winsys.h | 1 +
 5 files changed, 17 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c 
b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
index 6da4c5e..3f5ef30 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
@@ -236,6 +236,7 @@ const char *r600_get_llvm_processor_name(enum radeon_family 
family)
case CHIP_BONAIRE: return "bonaire";
case CHIP_KABINI: return "kabini";
case CHIP_KAVERI: return "kaveri";
+   case CHIP_HAWAII: return "hawaii";
default: return "";
 #endif
}
@@ -252,6 +253,7 @@ static const char *r600_get_family_name(enum radeon_family 
family)
case CHIP_BONAIRE: return "AMD BONAIRE";
case CHIP_KAVERI: return "AMD KAVERI";
case CHIP_KABINI: return "AMD KABINI";
+   case CHIP_HAWAII: return "AMD HAWAII";
default: return "AMD unknown";
}
 }
diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 97710f0..eb47c5b 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3097,6 +3097,10 @@ void si_init_config(struct r600_context *rctx)
si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG, 
0x1612);
si_pm4_set_reg(pm4, R_028354_PA_SC_RASTER_CONFIG_1, 
0x);
break;
+   case CHIP_HAWAII:
+   si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG, 
0x3a00161a);
+   si_pm4_set_reg(pm4, R_028354_PA_SC_RASTER_CONFIG_1, 
0x002e);
+   break;
case CHIP_KAVERI:
/* XXX todo */
case CHIP_KABINI:
diff --git a/src/gallium/drivers/radeonsi/sid.h 
b/src/gallium/drivers/radeonsi/sid.h
index 021f4eb..aab39fc 100644
--- a/src/gallium/drivers/radeonsi/sid.h
+++ b/src/gallium/drivers/radeonsi/sid.h
@@ -5403,6 +5403,8 @@
 #define V_02803C_X_ADDR_SURF_P8_32X32_16X16 0x0C
 #define V_02803C_X_ADDR_SURF_P8_32X32_16X32 0x0D
 #define V_02803C_X_ADDR_SURF_P8_32X64_32X32 0x0E
+#define V_02803C_X_ADDR_SURF_P16_32X32_8X16 0x10
+#define V_02803C_X_ADDR_SURF_P16_32X32_16X160x11
 #define   S_02803C_BANK_WIDTH(x)  (((x) & 
0x03) << 13)
 #define   G_02803C_BANK_WIDTH(x)  (((x) >> 
13) & 0x03)
 #define   C_02803C_BANK_WIDTH 
0x9FFF
@@ -5731,6 +5733,13 @@
 #define V_028350_RASTER_CONFIG_PKR_YSEL_1   0x01
 #define V_028350_RASTER_CONFIG_PKR_YSEL_2   0x02
 #define V_028350_RASTER_CONFIG_PKR_YSEL_3   0x03
+#define   S_028350_PKR_XSEL2(x)   (((x) & 
0x03) << 14)
+#define   G_028350_PKR_XSEL2(x)   (((x) >> 
14) & 0x03)
+#define   C_028350_PKR_XSEL2  
0x3FFF
+#define V_028350_RASTER_CONFIG_PKR_XSEL2_0  0x00
+#define V_028350_RASTER_CONFIG_PKR_XSEL2_1  0x01
+#define V_028350_RASTER_CONFIG_PKR_XSEL2_2  0x02
+#define V_028350_RASTER_CONFIG_PKR_XSEL2_3  0x03
 #define   S_028350_SC_MAP(x)  (((x) & 
0x03) << 16)
 #define   G_028350_SC_MAP(x)  (((x) >> 
16) & 0x03)
 #define   C_028350_SC_MAP 
0xFFFC
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 8a8f180..1860810 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
@@ -330,6 +330,7 @@ static boolean do_winsys_init(struct radeon_drm_winsys *ws)
 case CHIP_BONAIRE:
 case CHIP_KAVERI:
 case CHIP_KABINI:
+case CHIP_HAWAII:
 ws->info.chip_class = CIK;
 break;
 }
diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h 
b/src/gallium/winsys/radeon/drm/radeon_winsys.h
index c000371..d59f48f 100644
--- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
+++ b/src/gallium/winsys/radeon/drm/

[Mesa-dev] [PATCH 2/2] radeonsi: add Hawaii pci ids

2013-11-13 Thread Alex Deucher 
Signed-off-by: Alex Deucher 
---
 include/pci_ids/radeonsi_pci_ids.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/include/pci_ids/radeonsi_pci_ids.h 
b/include/pci_ids/radeonsi_pci_ids.h
index 0fdd1ad..7b42d5e 100644
--- a/include/pci_ids/radeonsi_pci_ids.h
+++ b/include/pci_ids/radeonsi_pci_ids.h
@@ -118,3 +118,16 @@ CHIPSET(0x1317, KAVERI_1317, KAVERI)
 CHIPSET(0x131B, KAVERI_131B, KAVERI)
 CHIPSET(0x131C, KAVERI_131C, KAVERI)
 CHIPSET(0x131D, KAVERI_131D, KAVERI)
+
+CHIPSET(0x67A0, HAWAII_67A0, HAWAII)
+CHIPSET(0x67A1, HAWAII_67A1, HAWAII)
+CHIPSET(0x67A2, HAWAII_67A2, HAWAII)
+CHIPSET(0x67A8, HAWAII_67A8, HAWAII)
+CHIPSET(0x67A9, HAWAII_67A9, HAWAII)
+CHIPSET(0x67AA, HAWAII_67AA, HAWAII)
+CHIPSET(0x67B0, HAWAII_67B0, HAWAII)
+CHIPSET(0x67B1, HAWAII_67B1, HAWAII)
+CHIPSET(0x67B8, HAWAII_67B8, HAWAII)
+CHIPSET(0x67B9, HAWAII_67B9, HAWAII)
+CHIPSET(0x67BA, HAWAII_67BA, HAWAII)
+CHIPSET(0x67BE, HAWAII_67BE, HAWAII)
-- 
1.8.3.1

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

[Mesa-dev] [PATCH] R600/SI: Add processor type for Hawaii

2013-11-13 Thread Alex Deucher 
Signed-off-by: Alex Deucher 
---
 lib/Target/R600/Processors.td | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/Target/R600/Processors.td b/lib/Target/R600/Processors.td
index 31079d3..ee190e4 100644
--- a/lib/Target/R600/Processors.td
+++ b/lib/Target/R600/Processors.td
@@ -51,3 +51,4 @@ def : Proc<"hainan", SI_Itin, [FeatureSouthernIslands]>;
 def : Proc<"bonaire",SI_Itin, [FeatureSeaIslands]>;
 def : Proc<"kabini", SI_Itin, [FeatureSeaIslands]>;
 def : Proc<"kaveri", SI_Itin, [FeatureSeaIslands]>;
+def : Proc<"hawaii", SI_Itin, [FeatureSeaIslands]>;
-- 
1.8.3.1

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

Re: [Mesa-dev] [PATCH 1/2] radeonsi: add support for Hawaii asics (v2)

2013-11-13 Thread Alex Deucher 
On Wed, Nov 13, 2013 at 1:08 PM, Tom Stellard  wrote:
> On Wed, Nov 13, 2013 at 12:29:31PM -0500, Alex Deucher wrote:
>> Update additional register fields.
>>
>> Signed-off-by: Alex Deucher 
>
> Should we CC: mesa-stable on these?

Probably not at this point.  Support is still pretty unstable on
Hawaii.  Should probably wait for things to stabilize first.

Alex

>
>> ---
>>  src/gallium/drivers/radeonsi/radeonsi_pipe.c  | 2 ++
>>  src/gallium/drivers/radeonsi/si_state.c   | 4 
>>  src/gallium/drivers/radeonsi/sid.h| 9 +
>>  src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 1 +
>>  src/gallium/winsys/radeon/drm/radeon_winsys.h | 1 +
>>  5 files changed, 17 insertions(+)
>>
>> diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c 
>> b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
>> index 6da4c5e..3f5ef30 100644
>> --- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
>> +++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
>> @@ -236,6 +236,7 @@ const char *r600_get_llvm_processor_name(enum 
>> radeon_family family)
>>   case CHIP_BONAIRE: return "bonaire";
>>   case CHIP_KABINI: return "kabini";
>>   case CHIP_KAVERI: return "kaveri";
>> + case CHIP_HAWAII: return "hawaii";
>>   default: return "";
>>  #endif
>>   }
>> @@ -252,6 +253,7 @@ static const char *r600_get_family_name(enum 
>> radeon_family family)
>>   case CHIP_BONAIRE: return "AMD BONAIRE";
>>   case CHIP_KAVERI: return "AMD KAVERI";
>>   case CHIP_KABINI: return "AMD KABINI";
>> + case CHIP_HAWAII: return "AMD HAWAII";
>>   default: return "AMD unknown";
>>   }
>>  }
>> diff --git a/src/gallium/drivers/radeonsi/si_state.c 
>> b/src/gallium/drivers/radeonsi/si_state.c
>> index 97710f0..eb47c5b 100644
>> --- a/src/gallium/drivers/radeonsi/si_state.c
>> +++ b/src/gallium/drivers/radeonsi/si_state.c
>> @@ -3097,6 +3097,10 @@ void si_init_config(struct r600_context *rctx)
>>   si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG, 
>> 0x1612);
>>   si_pm4_set_reg(pm4, R_028354_PA_SC_RASTER_CONFIG_1, 
>> 0x);
>>   break;
>> + case CHIP_HAWAII:
>> + si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG, 
>> 0x3a00161a);
>> + si_pm4_set_reg(pm4, R_028354_PA_SC_RASTER_CONFIG_1, 
>> 0x002e);
>> + break;
>>   case CHIP_KAVERI:
>>   /* XXX todo */
>>   case CHIP_KABINI:
>> diff --git a/src/gallium/drivers/radeonsi/sid.h 
>> b/src/gallium/drivers/radeonsi/sid.h
>> index 021f4eb..aab39fc 100644
>> --- a/src/gallium/drivers/radeonsi/sid.h
>> +++ b/src/gallium/drivers/radeonsi/sid.h
>> @@ -5403,6 +5403,8 @@
>>  #define V_02803C_X_ADDR_SURF_P8_32X32_16X16 0x0C
>>  #define V_02803C_X_ADDR_SURF_P8_32X32_16X32 0x0D
>>  #define V_02803C_X_ADDR_SURF_P8_32X64_32X32 0x0E
>> +#define V_02803C_X_ADDR_SURF_P16_32X32_8X16 0x10
>> +#define V_02803C_X_ADDR_SURF_P16_32X32_16X160x11
>>  #define   S_02803C_BANK_WIDTH(x)  (((x) 
>> & 0x03) << 13)
>>  #define   G_02803C_BANK_WIDTH(x)  (((x) 
>> >> 13) & 0x03)
>>  #define   C_02803C_BANK_WIDTH 
>> 0x9FFF
>> @@ -5731,6 +5733,13 @@
>>  #define V_028350_RASTER_CONFIG_PKR_YSEL_1   0x01
>>  #define V_028350_RASTER_CONFIG_PKR_YSEL_2   0x02
>>  #define V_028350_RASTER_CONFIG_PKR_YSEL_3   0x03
>> +#define   S_028350_PKR_XSEL2(x)   (((x) 
>> & 0x03) << 14)
>> +#define   G_028350_PKR_XSEL2(x)   (((x) 
>> >> 14) & 0x03)
>> +#define   C_028350_PKR_XSEL2  
>> 0x3FFF
>> +#define V_028350_RASTER_CONFIG_PKR_XSEL2_0  0x00
>> +#define V_028350_RASTER_CONFIG_PKR_XSEL2_1  0x01
>> +#define V_028350_RASTER_CONFIG_PKR_XSEL2_2  0x02
>> +#define V_028350_RASTER_CONFIG_PKR_XSEL2_3  0x

Re: [Mesa-dev] [PATCH] R600/SI: Add processor type for Hawaii

2013-11-13 Thread Alex Deucher 
On Wed, Nov 13, 2013 at 1:12 PM, Tom Stellard  wrote:
> On Wed, Nov 13, 2013 at 12:27:05PM -0500, Alex Deucher wrote:
>> Signed-off-by: Alex Deucher 
>
> Reviewed-by: Tom Stellard 
>
> Now that we have compute support for Sea Islands, we will also need to
> add the processor to clang.  I can take care of this.

Thanks!

Alex

>
> -Tom
>
>> ---
>>  lib/Target/R600/Processors.td | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/lib/Target/R600/Processors.td b/lib/Target/R600/Processors.td
>> index 31079d3..ee190e4 100644
>> --- a/lib/Target/R600/Processors.td
>> +++ b/lib/Target/R600/Processors.td
>> @@ -51,3 +51,4 @@ def : Proc<"hainan", SI_Itin, 
>> [FeatureSouthernIslands]>;
>>  def : Proc<"bonaire",SI_Itin, [FeatureSeaIslands]>;
>>  def : Proc<"kabini", SI_Itin, [FeatureSeaIslands]>;
>>  def : Proc<"kaveri", SI_Itin, [FeatureSeaIslands]>;
>> +def : Proc<"hawaii", SI_Itin, [FeatureSeaIslands]>;
>> --
>> 1.8.3.1
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] winsys/radeon: cleanup virtual memory nonsense

2013-11-19 Thread Alex Deucher 
On Tue, Nov 19, 2013 at 5:05 AM, Christian König
 wrote:
> From: Christian König 
>
> The alignment of a virtual memory area must always be at least 4096 bytes.
>
> It only worked because size was aligned to 4096 outside of the function.
>
> Signed-off-by: Christian König 

CC the 9.2 and 10.0 branches?  Does this fix the problems you were
looking at last week?

Reviewed-by: Alex Deucher 

> ---
>  src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 37 
> +--
>  src/gallium/winsys/radeon/drm/radeon_drm_bo.h |  1 -
>  2 files changed, 18 insertions(+), 20 deletions(-)
>
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
> b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> index 19e2715..3019a52 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> @@ -202,15 +202,15 @@ static uint64_t radeon_bomgr_find_va(struct 
> radeon_bomgr *mgr, uint64_t size, ui
>  struct radeon_bo_va_hole *hole, *n;
>  uint64_t offset = 0, waste = 0;
>
> +alignment = MAX2(alignment, 4096);
> +size = align(size, 4096);
> +
>  pipe_mutex_lock(mgr->bo_va_mutex);
>  /* first look for a hole */
>  LIST_FOR_EACH_ENTRY_SAFE(hole, n, &mgr->va_holes, list) {
>  offset = hole->offset;
> -waste = 0;
> -if (alignment) {
> -waste = offset % alignment;
> -waste = waste ? alignment - waste : 0;
> -}
> +waste = offset % alignment;
> +waste = waste ? alignment - waste : 0;
>  offset += waste;
>  if (offset >= (hole->offset + hole->size)) {
>  continue;
> @@ -242,11 +242,8 @@ static uint64_t radeon_bomgr_find_va(struct radeon_bomgr 
> *mgr, uint64_t size, ui
>  }
>
>  offset = mgr->va_offset;
> -waste = 0;
> -if (alignment) {
> -waste = offset % alignment;
> -waste = waste ? alignment - waste : 0;
> -}
> +waste = offset % alignment;
> +waste = waste ? alignment - waste : 0;
>  if (waste) {
>  n = CALLOC_STRUCT(radeon_bo_va_hole);
>  n->size = waste;
> @@ -261,6 +258,8 @@ static uint64_t radeon_bomgr_find_va(struct radeon_bomgr 
> *mgr, uint64_t size, ui
>
>  static void radeon_bomgr_force_va(struct radeon_bomgr *mgr, uint64_t va, 
> uint64_t size)
>  {
> +size = align(size, 4096);
> +
>  pipe_mutex_lock(mgr->bo_va_mutex);
>  if (va >= mgr->va_offset) {
>  if (va > mgr->va_offset) {
> @@ -303,6 +302,8 @@ static void radeon_bomgr_free_va(struct radeon_bomgr 
> *mgr, uint64_t va, uint64_t
>  {
>  struct radeon_bo_va_hole *hole;
>
> +size = align(size, 4096);
> +
>  pipe_mutex_lock(mgr->bo_va_mutex);
>  if ((va + size) == mgr->va_offset) {
>  mgr->va_offset = va;
> @@ -385,7 +386,7 @@ static void radeon_bo_destroy(struct pb_buffer *_buf)
>  drmIoctl(bo->rws->fd, DRM_IOCTL_GEM_CLOSE, &args);
>
>  if (mgr->va) {
> -radeon_bomgr_free_va(mgr, bo->va, bo->va_size);
> +radeon_bomgr_free_va(mgr, bo->va, bo->base.size);
>  }
>
>  pipe_mutex_destroy(bo->map_mutex);
> @@ -600,8 +601,7 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct 
> pb_manager *_mgr,
>  if (mgr->va) {
>  struct drm_radeon_gem_va va;
>
> -bo->va_size = align(size,  4096);
> -bo->va = radeon_bomgr_find_va(mgr, bo->va_size, desc->alignment);
> +bo->va = radeon_bomgr_find_va(mgr, size, desc->alignment);
>
>  va.handle = bo->handle;
>  va.vm_id = 0;
> @@ -621,9 +621,9 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct 
> pb_manager *_mgr,
>  return NULL;
>  }
>  if (va.operation == RADEON_VA_RESULT_VA_EXIST) {
> -radeon_bomgr_free_va(mgr, bo->va, bo->va_size);
> +radeon_bomgr_free_va(mgr, bo->va, size);
>  bo->va = va.offset;
> -radeon_bomgr_force_va(mgr, bo->va, bo->va_size);
> +radeon_bomgr_force_va(mgr, bo->va, size);
>  }
>  }
>
> @@ -931,8 +931,7 @@ done:
>  if (mgr->va && !bo->va) {
>  struct drm_radeon_gem_va va;
>
> -bo->va_size = ((bo->base.size + 4095) & ~4095);
> -bo->va = radeon_bomgr_find_va(mgr, bo->va_size, 1 << 20);
> +bo->va = radeon_bomgr_find_va(mgr, bo->base.size, 1 << 20);
>
>  va.handle = bo->handle;
>  va.operation = RADEON_VA_MAP;
> @@ -949,9 +948,9 @@ done:
>

Re: [Mesa-dev] [PATCH] r600g/compute: Add a work-around for flushing issues on Cayman

2013-11-20 Thread Alex Deucher 
On Tue, Nov 19, 2013 at 10:39 PM, Tom Stellard  wrote:
> From: Tom Stellard 
>
> https://bugs.freedesktop.org/show_bug.cgi?id=69321
>
> CC: "10.0" 

Reviewed-by: Alex Deucher 

> ---
>  src/gallium/drivers/r600/evergreen_compute.c |  4 
>  src/gallium/drivers/r600/r600_hw_context.c   |  4 +++-
>  src/gallium/drivers/r600/r600_pipe.h | 10 ++
>  3 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/r600/evergreen_compute.c 
> b/src/gallium/drivers/r600/evergreen_compute.c
> index ffdc5c3..d668c8e 100644
> --- a/src/gallium/drivers/r600/evergreen_compute.c
> +++ b/src/gallium/drivers/r600/evergreen_compute.c
> @@ -474,6 +474,10 @@ static void compute_emit_cs(struct r600_context *ctx, 
> const uint *block_layout,
> r600_flush_emit(ctx);
> ctx->b.flags = 0;
>
> +   if (ctx->b.chip_class >= CAYMAN) {
> +   ctx->skip_surface_sync_on_next_cs_flush = true;
> +   }
> +
>  #if 0
> COMPUTE_DBG(ctx->screen, "cdw: %i\n", cs->cdw);
> for (i = 0; i < cs->cdw; i++) {
> diff --git a/src/gallium/drivers/r600/r600_hw_context.c 
> b/src/gallium/drivers/r600/r600_hw_context.c
> index 5f3a9bd..191a81d 100644
> --- a/src/gallium/drivers/r600/r600_hw_context.c
> +++ b/src/gallium/drivers/r600/r600_hw_context.c
> @@ -293,7 +293,7 @@ void r600_flush_emit(struct r600_context *rctx)
> S_0085F0_SMX_ACTION_ENA(1);
> }
>
> -   if (cp_coher_cntl) {
> +   if (cp_coher_cntl && !rctx->skip_surface_sync_on_next_cs_flush) {
> cs->buf[cs->cdw++] = PKT3(PKT3_SURFACE_SYNC, 3, 0);
> cs->buf[cs->cdw++] = cp_coher_cntl;   /* CP_COHER_CNTL */
> cs->buf[cs->cdw++] = 0x;  /* CP_COHER_SIZE */
> @@ -354,6 +354,8 @@ void r600_context_flush(struct r600_context *ctx, 
> unsigned flags)
>
> /* Flush the CS. */
> ctx->b.ws->cs_flush(ctx->b.rings.gfx.cs, flags, 
> ctx->screen->cs_count++);
> +
> +   ctx->skip_surface_sync_on_next_cs_flush = false;
>  }
>
>  void r600_begin_new_cs(struct r600_context *ctx)
> diff --git a/src/gallium/drivers/r600/r600_pipe.h 
> b/src/gallium/drivers/r600/r600_pipe.h
> index d7af618..f0d4be4 100644
> --- a/src/gallium/drivers/r600/r600_pipe.h
> +++ b/src/gallium/drivers/r600/r600_pipe.h
> @@ -507,6 +507,16 @@ struct r600_context {
>
> void*sb_context;
> struct r600_isa *isa;
> +
> +   /* Work-around for flushing problems with compute shaders on Cayman:
> +* Emitting a SURFACE_SYNC packet with any of the CB*_DEST_BASE_ENA
> +* or DB_DEST_BASE_ENA bits set after dispatching a compute shader
> +* hangs the GPU.
> +*
> +* Setting this to true will prevent r600_flush_emit() from emitting
> +* a SURFACE_SYNC packet.  This field will be cleared by
> +* by r600_context_flush() after flushing the command stream. */
> +   boolean skip_surface_sync_on_next_cs_flush;
>  };
>
>  static INLINE void r600_emit_command_buffer(struct radeon_winsys_cs *cs,
> --
> 1.8.1.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/5] radeon: change last instance of DEBUG_IOCTL to use RADEON_IOCTL

2013-11-24 Thread Alex Deucher 
On Sun, Nov 24, 2013 at 12:13 AM, Chris Forbes  wrote:
> DEBUG_IOCTL comes from i965, and is about to be removed. Both defines
> have the same value (4).
>
> Signed-off-by: Chris Forbes 

Reviewed-by: Alex Deucher 

> ---
>  src/mesa/drivers/dri/radeon/radeon_ioctl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/radeon/radeon_ioctl.c 
> b/src/mesa/drivers/dri/radeon/radeon_ioctl.c
> index d6419f3..a542db1 100644
> --- a/src/mesa/drivers/dri/radeon/radeon_ioctl.c
> +++ b/src/mesa/drivers/dri/radeon/radeon_ioctl.c
> @@ -282,7 +282,7 @@ void radeonEmitVertexAOS( r100ContextPtr rmesa,
>  #else
> BATCH_LOCALS(&rmesa->radeon);
>
> -   if (RADEON_DEBUG & (RADEON_PRIMS|DEBUG_IOCTL))
> +   if (RADEON_DEBUG & (RADEON_PRIMS|RADEON_IOCTL))
>fprintf(stderr, "%s:  vertex_size 0x%x offset 0x%x \n",
>   __FUNCTION__, vertex_size, offset);
>
> --
> 1.8.4.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

  1   2   3   4   5   6   7   8   9   >