Re: [Mesa-dev] [PATCH 2/2] radeonsi: clamp point size to the limit

[Jakob Bornecrantz]

Tested-by: Jakob Bornecrantz 
On Wed, Oct 17, 2018 at 5:29 PM Marek Olšák  wrote:
>
> From: Marek Olšák 
>
> This fixes dEQP-GLES2.functional.rasterization.limits.points.
> Broken by: ea039f789d9b54e1bd1d644b6a29863ca3500314
> ---
>  src/gallium/drivers/radeonsi/si_get.c   | 5 +++--
>  src/gallium/drivers/radeonsi/si_pipe.h  | 1 +
>  src/gallium/drivers/radeonsi/si_state.c | 2 +-
>  3 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_get.c 
> b/src/gallium/drivers/radeonsi/si_get.c
> index ac302b8a946..804276b3eda 100644
> --- a/src/gallium/drivers/radeonsi/si_get.c
> +++ b/src/gallium/drivers/radeonsi/si_get.c
> @@ -326,25 +326,26 @@ static int si_get_param(struct pipe_screen *pscreen, 
> enum pipe_cap param)
> default:
> return u_pipe_screen_get_param_defaults(pscreen, param);
> }
>  }
>
>  static float si_get_paramf(struct pipe_screen* pscreen, enum pipe_capf param)
>  {
> switch (param) {
> case PIPE_CAPF_MAX_LINE_WIDTH:
> case PIPE_CAPF_MAX_LINE_WIDTH_AA:
> -   case PIPE_CAPF_MAX_POINT_WIDTH:
> -   case PIPE_CAPF_MAX_POINT_WIDTH_AA:
> /* This depends on the quant mode, though the precise 
> interactions
>  * are unknown. */
> return 2048;
> +   case PIPE_CAPF_MAX_POINT_WIDTH:
> +   case PIPE_CAPF_MAX_POINT_WIDTH_AA:
> +   return SI_MAX_POINT_SIZE;
> case PIPE_CAPF_MAX_TEXTURE_ANISOTROPY:
> return 16.0f;
> case PIPE_CAPF_MAX_TEXTURE_LOD_BIAS:
> return 16.0f;
> case PIPE_CAPF_MIN_CONSERVATIVE_RASTER_DILATE:
> case PIPE_CAPF_MAX_CONSERVATIVE_RASTER_DILATE:
> case PIPE_CAPF_CONSERVATIVE_RASTER_DILATE_GRANULARITY:
> return 0.0f;
> }
> return 0.0f;
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.h 
> b/src/gallium/drivers/radeonsi/si_pipe.h
> index 6edc06cece7..dc95afb7421 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.h
> +++ b/src/gallium/drivers/radeonsi/si_pipe.h
> @@ -41,20 +41,21 @@
>  #define ATI_VENDOR_ID  0x1002
>
>  #define SI_NOT_QUERY   0x
>
>  /* The base vertex and primitive restart can be any number, but we must pick
>   * one which will mean "unknown" for the purpose of state tracking and
>   * the number shouldn't be a commonly-used one. */
>  #define SI_BASE_VERTEX_UNKNOWN INT_MIN
>  #define SI_RESTART_INDEX_UNKNOWN   INT_MIN
>  #define SI_NUM_SMOOTH_AA_SAMPLES   8
> +#define SI_MAX_POINT_SIZE  2048
>  #define SI_GS_PER_ES   128
>  /* Alignment for optimal CP DMA performance. */
>  #define SI_CPDMA_ALIGNMENT 32
>
>  /* Tunables for compute-based clear_buffer and copy_buffer: */
>  #define SI_COMPUTE_CLEAR_DW_PER_THREAD 4
>  #define SI_COMPUTE_COPY_DW_PER_THREAD  4
>  #define SI_COMPUTE_DST_CACHE_POLICYL2_STREAM
>
>  /* Pipeline & streamout query controls. */
> diff --git a/src/gallium/drivers/radeonsi/si_state.c 
> b/src/gallium/drivers/radeonsi/si_state.c
> index 8b2e6e57f45..176ec749148 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -891,21 +891,21 @@ static void *si_create_rs_state(struct pipe_context 
> *ctx,
> S_0286D4_PNT_SPRITE_OVRD_Z(V_0286D4_SPI_PNT_SPRITE_SEL_0) |
> S_0286D4_PNT_SPRITE_OVRD_W(V_0286D4_SPI_PNT_SPRITE_SEL_1) |
> S_0286D4_PNT_SPRITE_TOP_1(state->sprite_coord_mode != 
> PIPE_SPRITE_COORD_UPPER_LEFT));
>
> /* point size 12.4 fixed point */
> tmp = (unsigned)(state->point_size * 8.0);
> si_pm4_set_reg(pm4, R_028A00_PA_SU_POINT_SIZE, S_028A00_HEIGHT(tmp) | 
> S_028A00_WIDTH(tmp));
>
> if (state->point_size_per_vertex) {
> psize_min = util_get_min_point_size(state);
> -   psize_max = 8192;
> +   psize_max = SI_MAX_POINT_SIZE;
> } else {
> /* Force the point size to be as if the vertex output was 
> disabled. */
> psize_min = state->point_size;
> psize_max = state->point_size;
> }
> rs->max_point_size = psize_max;
>
> /* Divide by two, because 0.5 = 1 pixel. */
> si_pm4_set_reg(pm4, R_028A04_PA_SU_POINT_MINMAX,
> S_028A04_MIN_SIZE(si_pack_float_12p4(psize_min/2)) |
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] radeonsi: fix a VGT hang with primitive restart on Polaris10 and later

[Jakob Bornecrantz]

Tested-by: Jakob Bornecrantz 
On Wed, Oct 17, 2018 at 5:29 PM Marek Olšák  wrote:
>
> From: Marek Olšák 
>
> Cc: 18.1 18.2 
> ---
>  src/gallium/drivers/radeonsi/si_state_draw.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
> b/src/gallium/drivers/radeonsi/si_state_draw.c
> index 83eb646b791..612ca910cb9 100644
> --- a/src/gallium/drivers/radeonsi/si_state_draw.c
> +++ b/src/gallium/drivers/radeonsi/si_state_draw.c
> @@ -376,21 +376,21 @@ si_get_init_multi_vgt_param(struct si_screen *sscreen,
> }
>
> if (sscreen->info.chip_class >= CIK) {
> /* WD_SWITCH_ON_EOP has no effect on GPUs with less than
>  * 4 shader engines. Set 1 to pass the assertion below.
>  * The other cases are hardware requirements.
>  *
>  * Polaris supports primitive restart with WD_SWITCH_ON_EOP=0
>  * for points, line strips, and tri strips.
>  */
> -   if (sscreen->info.max_se < 4 ||
> +   if (sscreen->info.max_se <= 2 ||
> key->u.prim == PIPE_PRIM_POLYGON ||
> key->u.prim == PIPE_PRIM_LINE_LOOP ||
> key->u.prim == PIPE_PRIM_TRIANGLE_FAN ||
> key->u.prim == PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY ||
> (key->u.primitive_restart &&
>  (sscreen->info.family < CHIP_POLARIS10 ||
>   (key->u.prim != PIPE_PRIM_POINTS &&
>key->u.prim != PIPE_PRIM_LINE_STRIP &&
>key->u.prim != PIPE_PRIM_TRIANGLE_STRIP))) ||
> key->u.count_from_stream_output)
> @@ -407,35 +407,41 @@ si_get_init_multi_vgt_param(struct si_screen *sscreen,
>  * instances are smaller than a primgroup.
>  * Assume indirect draws always use small instances.
>  * This is needed for good VS wave utilization.
>  */
> if (sscreen->info.chip_class <= VI &&
> sscreen->info.max_se == 4 &&
> key->u.multi_instances_smaller_than_primgroup)
> wd_switch_on_eop = true;
>
> /* Required on CIK and later. */
> -   if (sscreen->info.max_se > 2 && !wd_switch_on_eop)
> +   if (sscreen->info.max_se == 4 && !wd_switch_on_eop)
> ia_switch_on_eoi = true;
>
> /* Required by Hawaii and, for some special cases, by VI. */
> if (ia_switch_on_eoi &&
> (sscreen->info.family == CHIP_HAWAII ||
>  (sscreen->info.chip_class == VI &&
>   (key->u.uses_gs || max_primgroup_in_wave != 2
> partial_vs_wave = true;
>
> /* Instancing bug on Bonaire. */
> if (sscreen->info.family == CHIP_BONAIRE && ia_switch_on_eoi 
> &&
> key->u.uses_instancing)
> partial_vs_wave = true;
>
> +   /* This only applies to Polaris10 and later 4 SE chips.
> +* wd_switch_on_eop is already true on all other chips.
> +*/
> +   if (!wd_switch_on_eop && key->u.primitive_restart)
> +   partial_vs_wave = true;
> +
> /* If the WD switch is false, the IA switch must be false 
> too. */
> assert(wd_switch_on_eop || !ia_switch_on_eop);
> }
>
> /* If SWITCH_ON_EOI is set, PARTIAL_ES_WAVE must be set too. */
> if (sscreen->info.chip_class <= VI && ia_switch_on_eoi)
> partial_es_wave = true;
>
> return S_028AA8_SWITCH_ON_EOP(ia_switch_on_eop) |
> S_028AA8_SWITCH_ON_EOI(ia_switch_on_eoi) |
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: only update framebuffer-state for clears

[Jakob Bornecrantz]

On Wed, Sep 19, 2018 at 1:48 PM Ilia Mirkin  wrote:
>
> On Wed, Sep 19, 2018 at 7:04 AM, Jakob Bornecrantz  
> wrote:
> > This patch regresses about 3000 dEQP [2,3,3.1] tests on virgl. Full
> > setup is dEQP running on virgl with vtest that is running RadeonSI. So
> > QEMU is not in the picture. All instances of the Mesa driver is from
> > the same tree and have the patch applied.
>
> Does this happen with dEQP on just radeonsi? If not, that definitely
> points in the virglrenderer direction for bugs...

Yeah, just tested and I get about the same amount of failures on just
RadeonSI. So I'll revert the patch soon so Erik can respin it.

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

Re: [Mesa-dev] [PATCH] mesa: only update framebuffer-state for clears

[Jakob Bornecrantz]

This patch regresses about 3000 dEQP [2,3,3.1] tests on virgl. Full
setup is dEQP running on virgl with vtest that is running RadeonSI. So
QEMU is not in the picture. All instances of the Mesa driver is from
the same tree and have the patch applied.

Cheers, Jakob.
On Wed, Sep 12, 2018 at 12:05 PM Erik Faye-Lund
 wrote:
>
> If we update the program-state etc, we risk compiling needless shaders,
> which can cost quite a bit of performance.
>
> Signed-off-by: Erik Faye-Lund 
> ---
> This was motivated by seeing an unexpected shader-compile with
> nonsensical state on start-up in glxgears.
>
>  src/mesa/main/clear.c | 34 --
>  1 file changed, 20 insertions(+), 14 deletions(-)
>
> diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
> index 6beff9ed84..3d2ca490c9 100644
> --- a/src/mesa/main/clear.c
> +++ b/src/mesa/main/clear.c
> @@ -35,6 +35,7 @@
>  #include "context.h"
>  #include "enums.h"
>  #include "fbobject.h"
> +#include "framebuffer.h"
>  #include "get.h"
>  #include "macros.h"
>  #include "mtypes.h"
> @@ -135,10 +136,10 @@ color_buffer_writes_enabled(const struct gl_context 
> *ctx, unsigned idx)
>   * \param mask bit-mask indicating the buffers to be cleared.
>   *
>   * Flushes the vertices and verifies the parameter.
> - * If __struct gl_contextRec::NewState is set then calls _mesa_update_state()
> - * to update gl_frame_buffer::_Xmin, etc.  If the rasterization mode is set 
> to
> - * GL_RENDER then requests the driver to clear the buffers, via the
> - * dd_function_table::Clear callback.
> + * If __struct gl_contextRec::NewState contains _NEW_BUFFERS then calls
> + * _mesa_update_framebuffer() to update gl_frame_buffer::_Xmin, etc. If the
> + * rasterization mode is set to GL_RENDER then requests the driver to clear
> + * the buffers, via the dd_function_table::Clear callback.
>   */
>  static ALWAYS_INLINE void
>  clear(struct gl_context *ctx, GLbitfield mask, bool no_error)
> @@ -165,8 +166,9 @@ clear(struct gl_context *ctx, GLbitfield mask, bool 
> no_error)
>}
> }
>
> -   if (ctx->NewState) {
> -  _mesa_update_state( ctx );   /* update _Xmin, etc */
> +   if (ctx->NewState & _NEW_BUFFERS) {
> +  _mesa_update_framebuffer(ctx, ctx->ReadBuffer, ctx->DrawBuffer); /* 
> update _Xmin, etc */
> +  ctx->NewState &= ~_NEW_BUFFERS;
> }
>
> if (!no_error && ctx->DrawBuffer->_Status != GL_FRAMEBUFFER_COMPLETE_EXT) 
> {
> @@ -346,8 +348,9 @@ clear_bufferiv(struct gl_context *ctx, GLenum buffer, 
> GLint drawbuffer,
> FLUSH_VERTICES(ctx, 0);
> FLUSH_CURRENT(ctx, 0);
>
> -   if (ctx->NewState) {
> -  _mesa_update_state( ctx );
> +   if (ctx->NewState & _NEW_BUFFERS) {
> +  _mesa_update_framebuffer(ctx, ctx->ReadBuffer, ctx->DrawBuffer);
> +  ctx->NewState &= ~_NEW_BUFFERS;
> }
>
> switch (buffer) {
> @@ -460,8 +463,9 @@ clear_bufferuiv(struct gl_context *ctx, GLenum buffer, 
> GLint drawbuffer,
> FLUSH_VERTICES(ctx, 0);
> FLUSH_CURRENT(ctx, 0);
>
> -   if (ctx->NewState) {
> -  _mesa_update_state( ctx );
> +   if (ctx->NewState & _NEW_BUFFERS) {
> +  _mesa_update_framebuffer(ctx, ctx->ReadBuffer, ctx->DrawBuffer);
> +  ctx->NewState &= ~_NEW_BUFFERS;
> }
>
> switch (buffer) {
> @@ -549,8 +553,9 @@ clear_bufferfv(struct gl_context *ctx, GLenum buffer, 
> GLint drawbuffer,
> FLUSH_VERTICES(ctx, 0);
> FLUSH_CURRENT(ctx, 0);
>
> -   if (ctx->NewState) {
> -  _mesa_update_state( ctx );
> +   if (ctx->NewState & _NEW_BUFFERS) {
> +  _mesa_update_framebuffer(ctx, ctx->ReadBuffer, ctx->DrawBuffer);
> +  ctx->NewState &= ~_NEW_BUFFERS;
> }
>
> switch (buffer) {
> @@ -691,8 +696,9 @@ clear_bufferfi(struct gl_context *ctx, GLenum buffer, 
> GLint drawbuffer,
> if (ctx->RasterDiscard)
>return;
>
> -   if (ctx->NewState) {
> -  _mesa_update_state( ctx );
> +   if (ctx->NewState & _NEW_BUFFERS) {
> +  _mesa_update_framebuffer(ctx, ctx->ReadBuffer, ctx->DrawBuffer);
> +  ctx->NewState &= ~_NEW_BUFFERS;
> }
>
> if (ctx->DrawBuffer->Attachment[BUFFER_DEPTH].Renderbuffer)
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 07/14] st/mesa: set ctx->Const.SubPixelBits

[Jakob Bornecrantz]

On Thu, Aug 9, 2018 at 12:57 AM Marek Olšák  wrote:
>
> From: Marek Olšák 

This patch causes regressions in dEQP[1] on virgl running on a
radeonSI device. Not a lot of drivers set
PIPE_CAP_VIEWPORT_SUBPIXEL_BITS but SubPixelBits is by default set to
4, but this overwrites it without checking if the returned value is
zero or not. Looking around it seems that a lot of other drivers just
returns zero for PIPE_CAP_VIEWPORT_SUBPIXEL_BITS not just virgl, so
this probably causes regressions on more drivers then virgl.

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

Re: [Mesa-dev] [PATCH 2/2] virgl: report actual max-texture sizes

[Jakob Bornecrantz]

Reviewed-by: Jakob Bornecrantz 

On Tue, Aug 14, 2018 at 2:02 PM, Erik Faye-Lund
 wrote:
> Instead of doing conservative guesses, we should report the max levels
> based on the max sizes we get from GL on the host.
>
> Signed-off-by: Erik Faye-Lund 
> ---
>  src/gallium/drivers/virgl/virgl_hw.h | 3 +++
>  src/gallium/drivers/virgl/virgl_screen.c | 7 +++
>  2 files changed, 10 insertions(+)
>
> diff --git a/src/gallium/drivers/virgl/virgl_hw.h 
> b/src/gallium/drivers/virgl/virgl_hw.h
> index b56f554b00..787452d328 100644
> --- a/src/gallium/drivers/virgl/virgl_hw.h
> +++ b/src/gallium/drivers/virgl/virgl_hw.h
> @@ -347,6 +347,9 @@ struct virgl_caps_v2 {
>  uint32_t max_compute_shared_memory_size;
>  uint32_t max_compute_grid_size[3];
>  uint32_t max_compute_block_size[3];
> +uint32_t max_texture_2d_size;
> +uint32_t max_texture_3d_size;
> +uint32_t max_texture_cube_size;
>  };
>
>  union virgl_caps {
> diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
> b/src/gallium/drivers/virgl/virgl_screen.c
> index 0ac976acbd..86063c66aa 100644
> --- a/src/gallium/drivers/virgl/virgl_screen.c
> +++ b/src/gallium/drivers/virgl/virgl_screen.c
> @@ -24,6 +24,7 @@
>  #include "util/u_format.h"
>  #include "util/u_format_s3tc.h"
>  #include "util/u_video.h"
> +#include "util/u_math.h"
>  #include "util/os_time.h"
>  #include "pipe/p_defines.h"
>  #include "pipe/p_screen.h"
> @@ -72,10 +73,16 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
> param)
> case PIPE_CAP_TEXTURE_SWIZZLE:
>return 1;
> case PIPE_CAP_MAX_TEXTURE_2D_LEVELS:
> +  if (vscreen->caps.caps.v2.max_texture_2d_size)
> + return 1 + util_logbase2(vscreen->caps.caps.v2.max_texture_2d_size);
>return 15; /* 16K x 16K */
> case PIPE_CAP_MAX_TEXTURE_3D_LEVELS:
> +  if (vscreen->caps.caps.v2.max_texture_3d_size)
> + return 1 + util_logbase2(vscreen->caps.caps.v2.max_texture_3d_size);
>return 9; /* 256 x 256 x 256 */
> case PIPE_CAP_MAX_TEXTURE_CUBE_LEVELS:
> +  if (vscreen->caps.caps.v2.max_texture_cube_size)
> + return 1 + 
> util_logbase2(vscreen->caps.caps.v2.max_texture_cube_size);
>return 13; /* 4K x 4K */
> case PIPE_CAP_BLEND_EQUATION_SEPARATE:
>return 1;
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] virgl: do not use SP_MAX_TEXTURE_*_LEVELS defines

[Jakob Bornecrantz]

Reviewed-by: Jakob Bornecrantz 

On Tue, Aug 14, 2018 at 2:02 PM, Erik Faye-Lund
 wrote:
> These macro-names are also used for softpipe, so let's avoid confusion
> by avoiding them. Besides, they are just used in one place in virgl, so
> let's just inline them into the place they are used instead.
>
> While we're at it, fixup an error in the comment for the 3D version.
> Mesa subtracts computes max-size by doing by 2^(n-1), which means this
> should be 256 cubed, not 512 cubed. The other comments are correct.
>
> Signed-off-by: Erik Faye-Lund 
> ---
>  src/gallium/drivers/virgl/virgl_screen.c | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
> b/src/gallium/drivers/virgl/virgl_screen.c
> index 87ce3b7355..0ac976acbd 100644
> --- a/src/gallium/drivers/virgl/virgl_screen.c
> +++ b/src/gallium/drivers/virgl/virgl_screen.c
> @@ -35,10 +35,6 @@
>  #include "virgl_public.h"
>  #include "virgl_context.h"
>
> -#define SP_MAX_TEXTURE_2D_LEVELS 15  /* 16K x 16K */
> -#define SP_MAX_TEXTURE_3D_LEVELS 9   /* 512 x 512 x 512 */
> -#define SP_MAX_TEXTURE_CUBE_LEVELS 13  /* 4K x 4K */
> -
>  static const char *
>  virgl_get_vendor(struct pipe_screen *screen)
>  {
> @@ -76,11 +72,11 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
> param)
> case PIPE_CAP_TEXTURE_SWIZZLE:
>return 1;
> case PIPE_CAP_MAX_TEXTURE_2D_LEVELS:
> -  return SP_MAX_TEXTURE_2D_LEVELS;
> +  return 15; /* 16K x 16K */
> case PIPE_CAP_MAX_TEXTURE_3D_LEVELS:
> -  return SP_MAX_TEXTURE_3D_LEVELS;
> +  return 9; /* 256 x 256 x 256 */
> case PIPE_CAP_MAX_TEXTURE_CUBE_LEVELS:
> -  return SP_MAX_TEXTURE_CUBE_LEVELS;
> +  return 13; /* 4K x 4K */
> case PIPE_CAP_BLEND_EQUATION_SEPARATE:
>return 1;
> case PIPE_CAP_INDEP_BLEND_ENABLE:
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [virglrenderer-devel] [PATCH] virgl/vtest: add support to vtest for new cap getting.

[Jakob Bornecrantz]

On 2018-06-27 23:26, Dave Airlie wrote:

On 28 June 2018 at 03:25, Jakob Bornecrantz  wrote:

On 2018-06-08 07:22, Dave Airlie wrote:


From: Dave Airlie 

The vtest protocol is pretty simple but also pretty dumb, and
the v1 caps query was fixed size, with no nice way to expand it,
however the server also ignores any command it doesn't understand.

So we can query v2 caps by sending a v2 followed by a v1, if the
v2 is ignored we know it's an old vtest server, and the we get
a v2 answer then we can just read the v1 answer and discard it.
---
   .../winsys/virgl/vtest/virgl_vtest_socket.c| 30
+++---
   src/gallium/winsys/virgl/vtest/vtest_protocol.h|  2 ++
   2 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
index adec26b66b8..d25f9a3bd9e 100644
--- a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
+++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
@@ -129,12 +129,14 @@ int virgl_vtest_connect(struct virgl_vtest_winsys
*vws)
   int virgl_vtest_send_get_caps(struct virgl_vtest_winsys *vws,
 struct virgl_drm_caps *caps)
   {
-   uint32_t get_caps_buf[VTEST_HDR_SIZE];
+   uint32_t get_caps_buf[VTEST_HDR_SIZE * 2];
  uint32_t resp_buf[VTEST_HDR_SIZE];
-
+   uint32_t caps_size = sizeof(struct virgl_caps_v2);
  int ret;
  get_caps_buf[VTEST_CMD_LEN] = 0;
-   get_caps_buf[VTEST_CMD_ID] = VCMD_GET_CAPS;
+   get_caps_buf[VTEST_CMD_ID] = VCMD_GET_CAPS2;
+   get_caps_buf[VTEST_CMD_LEN + 2] = 0;
+   get_caps_buf[VTEST_CMD_ID + 2] = VCMD_GET_CAPS;
virgl_block_write(vws->sock_fd, _caps_buf,
sizeof(get_caps_buf));
   @@ -142,7 +144,27 @@ int virgl_vtest_send_get_caps(struct
virgl_vtest_winsys *vws,
  if (ret <= 0)
 return 0;
   -   ret = virgl_block_read(vws->sock_fd, >caps, sizeof(struct
virgl_caps_v1));
+   if (resp_buf[1] == 2) {
+   struct virgl_caps_v1 dummy;
+   uint32_t resp_size = resp_buf[0] - 1;
+   uint32_t dummy_size = 0;
+   if (resp_size > caps_size) {
+  dummy_size = resp_size - caps_size;
+  resp_size = caps_size;
+   }
+
+   ret = virgl_block_read(vws->sock_fd, >caps, resp_size);
+
+   if (dummy_size)
+  ret = virgl_block_read(vws->sock_fd, , dummy_size);



Isn't there a risk that the "dummy_size" is larger then the struct
virgl_caps_v1 dummy and cause it to write over the stack? (I am assuming you
are using the dummy here as a place to put the extra caps the host is
exposing but the driver isn't supporting).


We've pretty much fixed caps_v1 size for ever, the protocol won't return
anything other than the 308 byte struct we have now.


I may be wrong here, but isn't the "if (dummy_size)" read dealing with 
the case when the "struct virgl_caps_v2" has grown on the host but not 
the guest size? And has nothing to do with caps_v1 other then that is 
what dummy happens to be.


So in the case the host has extended the v2 caps struct with more then 
308 bytes and the driver hasn't been updated. Wont that cause the 
dummy_size to be larger then sizeof(struct virgl_caps_v1) and cause it 
to smash the stack? I mean it is doubtful to ever happen but it seems a 
bit of a repeat of what happened with the v1 to v2 switch.






Wouldn't it be better if we had a virgl_block_skip function?


We don't really know what a block is, it's just a unix socket, if we find
ourselves doing this more then maybe a dummy refactor might be neeeded
but hopefully this is a once off bad protocol design fix. We may want a new
protocol here anyways that is more robust anyways.


Okay sounds good.

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

Re: [Mesa-dev] [virglrenderer-devel] [PATCH] virgl/vtest: add support to vtest for new cap getting.

[Jakob Bornecrantz]

On 2018-06-08 07:22, Dave Airlie wrote:

From: Dave Airlie 

The vtest protocol is pretty simple but also pretty dumb, and
the v1 caps query was fixed size, with no nice way to expand it,
however the server also ignores any command it doesn't understand.

So we can query v2 caps by sending a v2 followed by a v1, if the
v2 is ignored we know it's an old vtest server, and the we get
a v2 answer then we can just read the v1 answer and discard it.
---
  .../winsys/virgl/vtest/virgl_vtest_socket.c| 30 +++---
  src/gallium/winsys/virgl/vtest/vtest_protocol.h|  2 ++
  2 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c 
b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
index adec26b66b8..d25f9a3bd9e 100644
--- a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
+++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
@@ -129,12 +129,14 @@ int virgl_vtest_connect(struct virgl_vtest_winsys *vws)
  int virgl_vtest_send_get_caps(struct virgl_vtest_winsys *vws,
struct virgl_drm_caps *caps)
  {
-   uint32_t get_caps_buf[VTEST_HDR_SIZE];
+   uint32_t get_caps_buf[VTEST_HDR_SIZE * 2];
 uint32_t resp_buf[VTEST_HDR_SIZE];
-
+   uint32_t caps_size = sizeof(struct virgl_caps_v2);
 int ret;
 get_caps_buf[VTEST_CMD_LEN] = 0;
-   get_caps_buf[VTEST_CMD_ID] = VCMD_GET_CAPS;
+   get_caps_buf[VTEST_CMD_ID] = VCMD_GET_CAPS2;
+   get_caps_buf[VTEST_CMD_LEN + 2] = 0;
+   get_caps_buf[VTEST_CMD_ID + 2] = VCMD_GET_CAPS;
  
 virgl_block_write(vws->sock_fd, _caps_buf, sizeof(get_caps_buf));
  
@@ -142,7 +144,27 @@ int virgl_vtest_send_get_caps(struct virgl_vtest_winsys *vws,

 if (ret <= 0)
return 0;
  
-   ret = virgl_block_read(vws->sock_fd, >caps, sizeof(struct virgl_caps_v1));

+   if (resp_buf[1] == 2) {
+   struct virgl_caps_v1 dummy;
+   uint32_t resp_size = resp_buf[0] - 1;
+   uint32_t dummy_size = 0;
+   if (resp_size > caps_size) {
+  dummy_size = resp_size - caps_size;
+  resp_size = caps_size;
+   }
+
+   ret = virgl_block_read(vws->sock_fd, >caps, resp_size);
+
+   if (dummy_size)
+  ret = virgl_block_read(vws->sock_fd, , dummy_size);


Isn't there a risk that the "dummy_size" is larger then the struct 
virgl_caps_v1 dummy and cause it to write over the stack? (I am assuming 
you are using the dummy here as a place to put the extra caps the host 
is exposing but the driver isn't supporting).


Wouldn't it be better if we had a virgl_block_skip function?

Cheers, Jakob.


+
+   /* now read back the pointless caps v1 we requested */
+   ret = virgl_block_read(vws->sock_fd, resp_buf, sizeof(resp_buf));
+   if (ret <= 0)
+  return 0;
+   ret = virgl_block_read(vws->sock_fd, , sizeof(struct 
virgl_caps_v1));
+   } else
+   ret = virgl_block_read(vws->sock_fd, >caps, sizeof(struct 
virgl_caps_v1));
  
 return 0;

  }
diff --git a/src/gallium/winsys/virgl/vtest/vtest_protocol.h 
b/src/gallium/winsys/virgl/vtest/vtest_protocol.h
index 86d197f006c..95bd8c1d0bd 100644
--- a/src/gallium/winsys/virgl/vtest/vtest_protocol.h
+++ b/src/gallium/winsys/virgl/vtest/vtest_protocol.h
@@ -47,6 +47,8 @@
  
  /* pass the process cmd line for debugging */

  #define VCMD_CREATE_RENDERER 8
+
+#define VCMD_GET_CAPS2 9
  /* get caps */
  /* 0 length cmd */
  /* resp VCMD_GET_CAPS + caps */



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

Re: [Mesa-dev] [PATCH] Plumb invariant output attrib thru TGSI

[Jakob Bornecrantz]

On Mon, Jun 18, 2018 at 1:06 PM Elie Tournier  wrote:
>
> On Mon, Jun 18, 2018 at 12:06:42PM +0100, Jakob Bornecrantz wrote:
> > TGSI already has a invariant field on declarations, we are running
> > into a bug with virgl because st_glsl_to_tgsi completely drops the
> > invariant flag on the floor when it comes to declarations (tho precise
> > is added to the ops). But virgl can't express precise ops (only
> > invariant and precise declarations) only declarations.
> >
> > Going to do some testing on this patch soon.
> >
> > Cheers, Jakob.
> Supposing that it doesn't brake any gallium driver.
> Maybe Marek can confirm. I only test on qemu with virgl.
>
> Reviewed-by: Elie Tournier 

Did a run with this patch using r600 on the host and virgl in the
guest, ran the Android GLES[2-3] CTS in the host and the guest, saw no
regressions so patch is
Tested-by: Jakob Bornecrantz 

As Elie said we might want to get somebody else to look at this as
this will no plumb down invariant where it in the past did not.

Cheers, Jakob.

>
> >
> > On Tue, Apr 10, 2018 at 7:02 PM Marek Olšák  wrote:
> > >
> > > This doesn't change TGSI. It only changes utilities around it.
> > >
> > > Marek
> > >
> > > On Mon, Apr 9, 2018 at 6:02 PM, Joe M. Kniss  wrote:
> > >>
> > >> Add support for glsl 'invariant' modifier for output data declarations.
> > >> Gallium drivers that use TGSI serialization currently loose invariant
> > >> modifiers in glsl shaders.
> > >>
> > >> Tested: chromiumos on qemu with virglrenderer.
> > >> Signed-off-by: Joe M. Kniss 
> > >> ---
> > >>  src/gallium/auxiliary/tgsi/tgsi_strings.c  |  2 ++
> > >>  src/gallium/auxiliary/tgsi/tgsi_strings.h  |  2 ++
> > >>  src/gallium/auxiliary/tgsi/tgsi_text.c | 18 +++
> > >>  src/gallium/auxiliary/tgsi/tgsi_ureg.c | 27 ++
> > >>  src/gallium/auxiliary/tgsi/tgsi_ureg.h |  4 +++-
> > >>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp |  8 +--
> > >>  6 files changed, 45 insertions(+), 16 deletions(-)
> > >>
> > >> diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c 
> > >> b/src/gallium/auxiliary/tgsi/tgsi_strings.c
> > >> index 4f28b49ce8..434871273f 100644
> > >> --- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
> > >> +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
> > >> @@ -185,6 +185,8 @@ const char 
> > >> *tgsi_interpolate_locations[TGSI_INTERPOLATE_LOC_COUNT] =
> > >> "SAMPLE",
> > >>  };
> > >>
> > >> +const char *tgsi_invariant_name = "INVARIANT";
> > >> +
> > >>  const char *tgsi_primitive_names[PIPE_PRIM_MAX] =
> > >>  {
> > >> "POINTS",
> > >> diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.h 
> > >> b/src/gallium/auxiliary/tgsi/tgsi_strings.h
> > >> index bb2d3458dd..20e3f7127f 100644
> > >> --- a/src/gallium/auxiliary/tgsi/tgsi_strings.h
> > >> +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.h
> > >> @@ -52,6 +52,8 @@ extern const char 
> > >> *tgsi_interpolate_names[TGSI_INTERPOLATE_COUNT];
> > >>
> > >>  extern const char 
> > >> *tgsi_interpolate_locations[TGSI_INTERPOLATE_LOC_COUNT];
> > >>
> > >> +extern const char *tgsi_invariant_name;
> > >> +
> > >>  extern const char *tgsi_primitive_names[PIPE_PRIM_MAX];
> > >>
> > >>  extern const char *tgsi_fs_coord_origin_names[2];
> > >> diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c 
> > >> b/src/gallium/auxiliary/tgsi/tgsi_text.c
> > >> index 02241a66bf..815b1ee65d 100644
> > >> --- a/src/gallium/auxiliary/tgsi/tgsi_text.c
> > >> +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c
> > >> @@ -1586,10 +1586,6 @@ static boolean parse_declaration( struct 
> > >> translate_ctx *ctx )
> > >>  break;
> > >>   }
> > >>}
> > >> -  if (i == TGSI_INTERPOLATE_COUNT) {
> > >> - report_error( ctx, "Expected semantic or interpolate 
> > >> attribute" );
> > >> - return FALSE;
> > >> -  }
> > >> }
> > >>
> > >> cur = ctx->cur;
> > >> @@ -1609,6 +1605,20 @@ static boolean parse_declaration( struct 
> > >> translate_ctx *ctx )
> >

Re: [Mesa-dev] [PATCH] Plumb invariant output attrib thru TGSI

[Jakob Bornecrantz]

TGSI already has a invariant field on declarations, we are running
into a bug with virgl because st_glsl_to_tgsi completely drops the
invariant flag on the floor when it comes to declarations (tho precise
is added to the ops). But virgl can't express precise ops (only
invariant and precise declarations) only declarations.

Going to do some testing on this patch soon.

Cheers, Jakob.

On Tue, Apr 10, 2018 at 7:02 PM Marek Olšák  wrote:
>
> This doesn't change TGSI. It only changes utilities around it.
>
> Marek
>
> On Mon, Apr 9, 2018 at 6:02 PM, Joe M. Kniss  wrote:
>>
>> Add support for glsl 'invariant' modifier for output data declarations.
>> Gallium drivers that use TGSI serialization currently loose invariant
>> modifiers in glsl shaders.
>>
>> Tested: chromiumos on qemu with virglrenderer.
>> Signed-off-by: Joe M. Kniss 
>> ---
>>  src/gallium/auxiliary/tgsi/tgsi_strings.c  |  2 ++
>>  src/gallium/auxiliary/tgsi/tgsi_strings.h  |  2 ++
>>  src/gallium/auxiliary/tgsi/tgsi_text.c | 18 +++
>>  src/gallium/auxiliary/tgsi/tgsi_ureg.c | 27 ++
>>  src/gallium/auxiliary/tgsi/tgsi_ureg.h |  4 +++-
>>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp |  8 +--
>>  6 files changed, 45 insertions(+), 16 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c 
>> b/src/gallium/auxiliary/tgsi/tgsi_strings.c
>> index 4f28b49ce8..434871273f 100644
>> --- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
>> +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
>> @@ -185,6 +185,8 @@ const char 
>> *tgsi_interpolate_locations[TGSI_INTERPOLATE_LOC_COUNT] =
>> "SAMPLE",
>>  };
>>
>> +const char *tgsi_invariant_name = "INVARIANT";
>> +
>>  const char *tgsi_primitive_names[PIPE_PRIM_MAX] =
>>  {
>> "POINTS",
>> diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.h 
>> b/src/gallium/auxiliary/tgsi/tgsi_strings.h
>> index bb2d3458dd..20e3f7127f 100644
>> --- a/src/gallium/auxiliary/tgsi/tgsi_strings.h
>> +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.h
>> @@ -52,6 +52,8 @@ extern const char 
>> *tgsi_interpolate_names[TGSI_INTERPOLATE_COUNT];
>>
>>  extern const char *tgsi_interpolate_locations[TGSI_INTERPOLATE_LOC_COUNT];
>>
>> +extern const char *tgsi_invariant_name;
>> +
>>  extern const char *tgsi_primitive_names[PIPE_PRIM_MAX];
>>
>>  extern const char *tgsi_fs_coord_origin_names[2];
>> diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c 
>> b/src/gallium/auxiliary/tgsi/tgsi_text.c
>> index 02241a66bf..815b1ee65d 100644
>> --- a/src/gallium/auxiliary/tgsi/tgsi_text.c
>> +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c
>> @@ -1586,10 +1586,6 @@ static boolean parse_declaration( struct 
>> translate_ctx *ctx )
>>  break;
>>   }
>>}
>> -  if (i == TGSI_INTERPOLATE_COUNT) {
>> - report_error( ctx, "Expected semantic or interpolate attribute" );
>> - return FALSE;
>> -  }
>> }
>>
>> cur = ctx->cur;
>> @@ -1609,6 +1605,20 @@ static boolean parse_declaration( struct 
>> translate_ctx *ctx )
>>}
>> }
>>
>> +   cur = ctx->cur;
>> +   eat_opt_white(  );
>> +   if (*cur == ',' && !is_vs_input) {
>> +  cur++;
>> +  eat_opt_white(  );
>> +  if (str_match_nocase_whole( , tgsi_invariant_name )) {
>> + decl.Declaration.Invariant = 1;
>> + ctx->cur = cur;
>> +  } else {
>> + report_error( ctx, "Expected semantic, interpolate attribute, or 
>> invariant ");
>> + return FALSE;
>> +  }
>> +   }
>> +
>> advance = tgsi_build_full_declaration(
>>,
>>ctx->tokens_cur,
>> diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c 
>> b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
>> index 393e015001..f54e2229a7 100644
>> --- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
>> +++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
>> @@ -140,6 +140,7 @@ struct ureg_program
>>unsigned first;
>>unsigned last;
>>unsigned array_id;
>> +  unsigned invariant;
>> } output[UREG_MAX_OUTPUT];
>> unsigned nr_outputs, nr_output_regs;
>>
>> @@ -427,7 +428,8 @@ ureg_DECL_output_layout(struct ureg_program *ureg,
>>  unsigned index,
>>  unsigned usage_mask,
>>  unsigned array_id,
>> -unsigned array_size)
>> +unsigned array_size,
>> +unsigned invariant)
>>  {
>> unsigned i;
>>
>> @@ -455,6 +457,7 @@ ureg_DECL_output_layout(struct ureg_program *ureg,
>>ureg->output[i].first = index;
>>ureg->output[i].last = index + array_size - 1;
>>ureg->output[i].array_id = array_id;
>> +  ureg->output[i].invariant = invariant;
>>ureg->nr_output_regs = MAX2(ureg->nr_output_regs, index + array_size);
>>ureg->nr_outputs++;
>> }
>> @@ -480,7 +483,7 @@ ureg_DECL_output_masked(struct ureg_program *ureg,
>>  unsigned array_size)
>>  {
>> return 

Re: [Mesa-dev] [PATCH v2] mesa: handle a bunch of formats in IMPLEMENTATION_COLOR_READ_*

[Jakob Bornecrantz]

I have run this patch on my Intel host running various CTS in a virgl
guest. Not sure if this constitutes as a Tested-by or a Acked-by, but
at least it is a datapoint.

Cheers, Jakob.

On Fri, May 18, 2018 at 11:04 AM, Tomeu Vizoso
 wrote:
> Virgl could save a lot of work converting buffers in the host side
> between formats if Mesa supported a bunch of other formats when reading
> pixels.
>
> This commit adds cases to handle specific formats so that the values
> reported by the two calls match more closely the underlying native
> formats.
>
> In GLES is important that IMPLEMENTATION_COLOR_READ_* return the native
> format and data type because the spec only allows reading with those,
> besides GL_RGBA or GL_RGBA_INTEGER.
>
> Additionally, because virgl currently doesn't implement such
> conversions, this commit fixes several tests in
> dEQP-GLES3.functional.fbo.color.clear.*, when using virgl in the guest
> side.
>
> Additionally, assert that those functions' result match
> _mesa_format_matches_format_and_type, so both functions are kept in
> sync.
>
> Signed-off-by: Tomeu Vizoso 
>
> v2: * Let R10G10B10A2_UINT fall back to GL_RGBA_INTEGER (Eric Anholt)
> * Assert with _mesa_format_matches_format_and_type (Eric Anholt)
> ---
>  src/mesa/main/framebuffer.c | 117 
>  1 file changed, 80 insertions(+), 37 deletions(-)
>
> diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
> index 8e751b453b75..6be4ecbc58f9 100644
> --- a/src/mesa/main/framebuffer.c
> +++ b/src/mesa/main/framebuffer.c
> @@ -834,22 +834,72 @@ _mesa_get_color_read_format(struct gl_context *ctx,
> }
> else {
>const mesa_format format = fb->_ColorReadBuffer->Format;
> -  const GLenum data_type = _mesa_get_format_datatype(format);
> -
> -  if (format == MESA_FORMAT_B8G8R8A8_UNORM)
> - return GL_BGRA;
> -  else if (format == MESA_FORMAT_B5G6R5_UNORM)
> - return GL_RGB;
> -  else if (format == MESA_FORMAT_R_UNORM8)
> - return GL_RED;
> -
> -  switch (data_type) {
> -  case GL_UNSIGNED_INT:
> -  case GL_INT:
> - return GL_RGBA_INTEGER;
> +  GLenum gl_format, data_type;
> +  GLuint comps;
> +
> +  _mesa_uncompressed_format_to_type_and_comps(format, _type, 
> );
> +
> +  switch(format) {
> +  case MESA_FORMAT_RGBA_UINT8:
> + gl_format = GL_RGBA_INTEGER;
> + break;
> +  case MESA_FORMAT_B8G8R8A8_UNORM:
> + gl_format = GL_BGRA;
> + break;
> +  case MESA_FORMAT_B5G6R5_UNORM:
> +  case MESA_FORMAT_R11G11B10_FLOAT:
> + gl_format = GL_RGB;
> + break;
> +  case MESA_FORMAT_RG_FLOAT32:
> +  case MESA_FORMAT_RG_FLOAT16:
> +  case MESA_FORMAT_R8G8_UNORM:
> + gl_format = GL_RG;
> + break;
> +  case MESA_FORMAT_RG_SINT32:
> +  case MESA_FORMAT_RG_UINT32:
> +  case MESA_FORMAT_RG_SINT16:
> +  case MESA_FORMAT_RG_UINT16:
> +  case MESA_FORMAT_RG_SINT8:
> +  case MESA_FORMAT_RG_UINT8:
> + gl_format = GL_RG_INTEGER;
> + break;
> +  case MESA_FORMAT_R_FLOAT32:
> +  case MESA_FORMAT_R_FLOAT16:
> +  case MESA_FORMAT_R_UNORM8:
> + gl_format = GL_RED;
> + break;
> +  case MESA_FORMAT_R_SINT32:
> +  case MESA_FORMAT_R_UINT32:
> +  case MESA_FORMAT_R_SINT16:
> +  case MESA_FORMAT_R_UINT16:
> +  case MESA_FORMAT_R_SINT8:
> +  case MESA_FORMAT_R_UINT8:
> + gl_format = GL_RED_INTEGER;
> + break;
>default:
> - return GL_RGBA;
> + switch (data_type) {
> + case GL_UNSIGNED_INT:
> + case GL_UNSIGNED_INT_2_10_10_10_REV:
> + case GL_UNSIGNED_SHORT:
> + case GL_INT:
> + case GL_SHORT:
> + case GL_BYTE:
> +gl_format = GL_RGBA_INTEGER;
> +break;
> + default:
> +gl_format = GL_RGBA;
> +break;
> + }
>}
> +
> +  /* GL_RGBA and GL_RGBA_INTEGER should be always valid */
> +  assert(gl_format == GL_RGBA ||
> + gl_format == GL_RGBA_INTEGER ||
> + _mesa_format_matches_format_and_type(format, gl_format,
> +  data_type,
> +  ctx->Pack.SwapBytes, 
> NULL));
> +
> +  return gl_format;
> }
>  }
>
> @@ -882,29 +932,22 @@ _mesa_get_color_read_type(struct gl_context *ctx,
>return GL_NONE;
> }
> else {
> -  const GLenum format = fb->_ColorReadBuffer->Format;
> -  const GLenum data_type = _mesa_get_format_datatype(format);
> -
> -  if (format == MESA_FORMAT_B5G6R5_UNORM)
> - return GL_UNSIGNED_SHORT_5_6_5;
> -
> -  if (format == MESA_FORMAT_B10G10R10A2_UNORM ||
> -  format == MESA_FORMAT_B10G10R10X2_UNORM ||
> -  format == MESA_FORMAT_R10G10B10A2_UNORM ||
> -  format 

Re: [Mesa-dev] [PATCH] mesa: handle a bunch of formats in IMPLEMENTATION_COLOR_READ_*

[Jakob Bornecrantz]

Tested-by: Jakob Bornecrantz <ja...@collabora.com>

On Mon, May 14, 2018 at 3:14 PM, Tomeu Vizoso
<tomeu.viz...@collabora.com> wrote:
> Virgl could save a lot of work converting buffers in the host side
> between formats if Mesa supported a bunch of other formats when reading
> pixels.
>
> This commit adds cases to handle specific formats so that the values
> reported by the two calls match more closely the underlying native
> formats.
>
> In GLES is important that IMPLEMENTATION_COLOR_READ_* return the native
> format and data type because the spec only allows reading with those,
> besides GL_RGBA or GL_RGBA_INTEGER.
>
> Additionally, because virgl currently doesn't implement such conversions,
> this commit fixes several tests in
> dEQP-GLES3.functional.fbo.color.clear.*, when using virgl in the guest
> side.
>
> Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
> ---
>  src/mesa/main/framebuffer.c | 73 -
>  1 file changed, 64 insertions(+), 9 deletions(-)
>
> diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
> index 8e751b453b75..a22c66b349f2 100644
> --- a/src/mesa/main/framebuffer.c
> +++ b/src/mesa/main/framebuffer.c
> @@ -836,15 +836,43 @@ _mesa_get_color_read_format(struct gl_context *ctx,
>const mesa_format format = fb->_ColorReadBuffer->Format;
>const GLenum data_type = _mesa_get_format_datatype(format);
>
> -  if (format == MESA_FORMAT_B8G8R8A8_UNORM)
> +  switch(format) {
> +  case MESA_FORMAT_B8G8R8A8_UNORM:
>   return GL_BGRA;
> -  else if (format == MESA_FORMAT_B5G6R5_UNORM)
> +  case MESA_FORMAT_R10G10B10A2_UINT:
> + return GL_BGRA_INTEGER;
> +  case MESA_FORMAT_B5G6R5_UNORM:
> +  case MESA_FORMAT_R11G11B10_FLOAT:
>   return GL_RGB;
> -  else if (format == MESA_FORMAT_R_UNORM8)
> +  case MESA_FORMAT_RG_FLOAT32:
> +  case MESA_FORMAT_RG_FLOAT16:
> +  case MESA_FORMAT_R8G8_UNORM:
> + return GL_RG;
> +  case MESA_FORMAT_RG_SINT32:
> +  case MESA_FORMAT_RG_UINT32:
> +  case MESA_FORMAT_RG_SINT16:
> +  case MESA_FORMAT_RG_UINT16:
> +  case MESA_FORMAT_RG_SINT8:
> +  case MESA_FORMAT_RG_UINT8:
> + return GL_RG_INTEGER;
> +  case MESA_FORMAT_R_FLOAT32:
> +  case MESA_FORMAT_R_FLOAT16:
> +  case MESA_FORMAT_R_UNORM8:
>   return GL_RED;
> +  case MESA_FORMAT_R_SINT32:
> +  case MESA_FORMAT_R_UINT32:
> +  case MESA_FORMAT_R_SINT16:
> +  case MESA_FORMAT_R_UINT16:
> +  case MESA_FORMAT_R_SINT8:
> +  case MESA_FORMAT_R_UINT8:
> + return GL_RED_INTEGER;
> +  default:
> + break;
> +  }
>
>switch (data_type) {
>case GL_UNSIGNED_INT:
> +  case GL_UNSIGNED_BYTE:
>case GL_INT:
>   return GL_RGBA_INTEGER;
>default:
> @@ -885,14 +913,41 @@ _mesa_get_color_read_type(struct gl_context *ctx,
>const GLenum format = fb->_ColorReadBuffer->Format;
>const GLenum data_type = _mesa_get_format_datatype(format);
>
> -  if (format == MESA_FORMAT_B5G6R5_UNORM)
> +  switch(format) {
> +  case MESA_FORMAT_B5G6R5_UNORM:
>   return GL_UNSIGNED_SHORT_5_6_5;
> -
> -  if (format == MESA_FORMAT_B10G10R10A2_UNORM ||
> -  format == MESA_FORMAT_B10G10R10X2_UNORM ||
> -  format == MESA_FORMAT_R10G10B10A2_UNORM ||
> -  format == MESA_FORMAT_R10G10B10X2_UNORM)
> +  case MESA_FORMAT_B10G10R10A2_UNORM:
> +  case MESA_FORMAT_B10G10R10X2_UNORM:
> +  case MESA_FORMAT_R10G10B10A2_UNORM:
> +  case MESA_FORMAT_R10G10B10X2_UNORM:
> +  case MESA_FORMAT_B10G10R10A2_UINT:
> +  case MESA_FORMAT_R10G10B10A2_UINT:
>   return GL_UNSIGNED_INT_2_10_10_10_REV;
> +  case MESA_FORMAT_R11G11B10_FLOAT:
> + return GL_UNSIGNED_INT_10F_11F_11F_REV;
> +  case MESA_FORMAT_RGBA_FLOAT16:
> +  case MESA_FORMAT_RG_FLOAT16:
> +  case MESA_FORMAT_R_FLOAT16:
> + return GL_HALF_FLOAT;
> +  case MESA_FORMAT_RGBA_SINT16:
> +  case MESA_FORMAT_RG_SINT16:
> +  case MESA_FORMAT_R_SINT16:
> + return GL_SHORT;
> +  case MESA_FORMAT_RGBA_UINT16:
> +  case MESA_FORMAT_RG_UINT16:
> +  case MESA_FORMAT_R_UINT16:
> + return GL_UNSIGNED_SHORT;
> +  case MESA_FORMAT_RGBA_SINT8:
> +  case MESA_FORMAT_RG_SINT8:
> +  case MESA_FORMAT_R_SINT8:
> + return GL_BYTE;
> +  case MESA_FORMAT_RG_UINT8:
> +  case MESA_FORMAT_RGBA_UINT8:
> +  case MESA_FORMAT_R_UINT8:
> + return GL_UNSIGNED_BYTE;
> +  default:
> + 

Re: [Mesa-dev] [PATCH] st/mesa: Also use PIPE_FORMAT_R8G8B8A8_SRGB for framebuffer_sRGB.

[Jakob Bornecrantz]

Thanks for the review.

Cheers, Jakob.

On Tue, Apr 3, 2018 at 5:37 PM, Brian Paul <bri...@vmware.com> wrote:
> On 04/03/2018 10:06 AM, Jakob Bornecrantz wrote:
>>
>> When running virgl on a GLES host the only sRGB formats that support
>> rendering is RGBA and RGBX. That pipe format is in the sRGB default
>> lists that the state tracker uses when mapping mesa formats.
>>
>> Cheers, Jakob.
>>
>> Signed-off-by: Jakob Bornecrantz <ja...@collabora.com>
>> ---
>>   src/mesa/state_tracker/st_extensions.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/state_tracker/st_extensions.c
>> b/src/mesa/state_tracker/st_extensions.c
>> index bea61f21cb..0dc8adb262 100644
>> --- a/src/mesa/state_tracker/st_extensions.c
>> +++ b/src/mesa/state_tracker/st_extensions.c
>> @@ -711,7 +711,8 @@ void st_init_extensions(struct pipe_screen *screen,
>>   { { o(EXT_framebuffer_sRGB) },
>>   { PIPE_FORMAT_A8B8G8R8_SRGB,
>> -  PIPE_FORMAT_B8G8R8A8_SRGB },
>> +  PIPE_FORMAT_B8G8R8A8_SRGB,
>> +  PIPE_FORMAT_R8G8B8A8_SRGB },
>>GL_TRUE }, /* at least one format must be supported */
>>   { { o(EXT_packed_float) },
>>
>
> LGTM.
>
> Reviewed-by: Brian Paul <bri...@vmware.com>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] virgl: Update virgl_hw.h

[Jakob Bornecrantz]

Signed-off-by: Jakob Bornecrantz <ja...@collabora.com>
---
 src/gallium/drivers/virgl/virgl_hw.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/virgl/virgl_hw.h 
b/src/gallium/drivers/virgl/virgl_hw.h
index 93849c03dd..180dead80a 100644
--- a/src/gallium/drivers/virgl/virgl_hw.h
+++ b/src/gallium/drivers/virgl/virgl_hw.h
@@ -83,6 +83,7 @@ enum virgl_formats {
VIRGL_FORMAT_L8A8_SRGB   = 96,
VIRGL_FORMAT_B8G8R8A8_SRGB   = 100,
VIRGL_FORMAT_B8G8R8X8_SRGB   = 101,
+   VIRGL_FORMAT_R8G8B8A8_SRGB   = 104,
 
/* compressed formats */
VIRGL_FORMAT_DXT1_RGB= 105,
-- 
2.14.1

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

[Mesa-dev] [PATCH] st/mesa: Also use PIPE_FORMAT_R8G8B8A8_SRGB for framebuffer_sRGB.

[Jakob Bornecrantz]

When running virgl on a GLES host the only sRGB formats that support
rendering is RGBA and RGBX. That pipe format is in the sRGB default
lists that the state tracker uses when mapping mesa formats.

Cheers, Jakob.

Signed-off-by: Jakob Bornecrantz <ja...@collabora.com>
---
 src/mesa/state_tracker/st_extensions.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index bea61f21cb..0dc8adb262 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -711,7 +711,8 @@ void st_init_extensions(struct pipe_screen *screen,
 
   { { o(EXT_framebuffer_sRGB) },
 { PIPE_FORMAT_A8B8G8R8_SRGB,
-  PIPE_FORMAT_B8G8R8A8_SRGB },
+  PIPE_FORMAT_B8G8R8A8_SRGB,
+  PIPE_FORMAT_R8G8B8A8_SRGB },
  GL_TRUE }, /* at least one format must be supported */
 
   { { o(EXT_packed_float) },
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH] vbo: MaxVertexAttribStride is not always set

[Jakob Bornecrantz]

On 2018-03-30 16:49, Mathias Fröhlich wrote:

On Friday, 30 March 2018 17:38:39 CEST Jakob Bornecrantz wrote:

This assert is hit on hardware which does expose GL 4.4 or GLES 3.1.


Uff - sorry!

Reviewed-by: Mathias Fröhlich <mathias.froehl...@web.de>


Thanks, tho that should be "which does NOT expose" but you got the gist.

Cheers, Jakob.



Mathias



Signed-off-by: Jakob Bornecrantz <ja...@collabora.com>
---
  src/mesa/vbo/vbo_save_api.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index a367a569c8..71304ede49 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -492,8 +492,13 @@ update_vao(struct gl_context *ctx,
 _mesa_reference_vao(ctx, vao, NULL);
 *vao = _mesa_new_vao(ctx, ~((GLuint)0));
  
+   /*

+* assert(stride <= ctx->Const.MaxVertexAttribStride);
+* MaxVertexAttribStride is not set for drivers that does not
+* expose GL 44 or GLES 31.
+*/
+
 /* Bind the buffer object at binding point 0 */
-   assert(stride <= ctx->Const.MaxVertexAttribStride);
 _mesa_bind_vertex_buffer(ctx, *vao, 0, bo, buffer_offset, stride,

false);
  
 /* Retrieve the mapping from VBO_ATTRIB to VERT_ATTRIB space









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

[Mesa-dev] [PATCH] vbo: MaxVertexAttribStride is not always set

[Jakob Bornecrantz]

This assert is hit on hardware which does expose GL 4.4 or GLES 3.1.

Signed-off-by: Jakob Bornecrantz <ja...@collabora.com>
---
 src/mesa/vbo/vbo_save_api.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index a367a569c8..71304ede49 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -492,8 +492,13 @@ update_vao(struct gl_context *ctx,
_mesa_reference_vao(ctx, vao, NULL);
*vao = _mesa_new_vao(ctx, ~((GLuint)0));
 
+   /*
+* assert(stride <= ctx->Const.MaxVertexAttribStride);
+* MaxVertexAttribStride is not set for drivers that does not
+* expose GL 44 or GLES 31.
+*/
+
/* Bind the buffer object at binding point 0 */
-   assert(stride <= ctx->Const.MaxVertexAttribStride);
_mesa_bind_vertex_buffer(ctx, *vao, 0, bo, buffer_offset, stride, false);
 
/* Retrieve the mapping from VBO_ATTRIB to VERT_ATTRIB space
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH 1/2] meson: provide Makefile.sources variables to meson build

[Jakob Bornecrantz]

On Mon, Oct 16, 2017 at 6:58 PM, Scott D Phillips
<scott.d.phill...@intel.com> wrote:
> Dylan Baker <dy...@pnwbakers.com> writes:
>
>> Quoting Scott D Phillips (2017-10-16 10:04:45)
>> > Dylan Baker <dy...@pnwbakers.com> writes:
>> >
>> > > Quoting Jakob Bornecrantz (2017-10-14 13:03:14)
>> > > > On Sat, Oct 14, 2017 at 1:36 AM, Dylan Baker <dy...@pnwbakers.com> 
>> > > > wrote:
>> > > > > I'm not sure about this approach, we would need a way to add
>> > > > > depends to meson,
>> >
>> > 'add depends' meaning having a way for the build steps themselves to
>> > depend on modifications to Makefile.sources files? If so, I think
>> > there's a pretty good solution in:
>> >
>> > https://github.com/mesonbuild/meson/pull/2490
>> >
>> > It doesn't have anything to do with makefiles or anything, but just
>> > adds a regenerate-the-build-steps dependency on scripts and script
>> > arguments to run_command() that are within the srcdir. I would say
>> > it is a bug that that functionality is missing as it is.
>>
>> I agree, and if upstream won't take the module approach this is
>> probably the best solution, unless the community decides the
>> duplication is okay in the long term. That's what Xorg did.
>>
>> >
>> > > > > but I'm also worried that calling make adds another dependency
>> > > > > that could be problematic for windows,
>> >
>> > afaict, getting a copy of make on windows isn't really too odious,
>> > the problem is just that using autotools sucks really bad there.
>> >
>> > > > > and I really don't like the idea of having a half-and-half
>> > > > > approach with the sources.
>> >
>> > I agree and many more patches are in order if we go this route. I
>> > just didn't want to do the work of making those if the idea itself
>> > didn't sound good to folks.
>> >
>> > > > > Here's what I've been playing with:
>> > > > > https://github.com/dcbaker/meson/tree/make-import-module
>> > > > > https://github.com/dcbaker/mesa/tree/wip/meson-makefile-sources
>> > > > >
>> > > > > How would you feel about that?
>> >
>> > I would suggest changing the naming from a "Makefile parser" to an
>> > "Automake Makefile parser". That way your parser goes from
>> > very-incomplete to almost-complete for the source format.
>> >
>> > How confident are you that this extension would be accepted in
>> > meson? I got the notion from somewhere that dealing with makefiles
>> > is an antigoal for meson, but maybe that's not right.
>>
>> I'm not extremely confident of anything with meson, upstream can be a
>> bit odd, but I'm more confident of getting a module in than anything
>> else. I think it's pretty close to proposing, but I wanted to get a
>> patch for mesa so I could point to it and say, "look, this is why we
>> need this".
>>
>> What they are extremely adverse to is a make backend, whether they
>> would accept this parser (under any name) I don't know yet, but I'm
>> going to make a heck of an argument for it.
>
> Cool, I agree trying to get your parser upstream is the way to go here.

Since people are starting to convert more and more to meson support
for this should go in ASAP. So that conversions are done correctly from
the start. I don't think it's smart to wait how many months it will take to
get this upstreamed in meson and then released.

This should have been here from the beginning not some after thought.

Cheers, Jakob.

>> > > > Couldn't you just use the Makefile parser José wrote for the
>> > > > scons build, that would avoid running make and waiting for a new
>> > > > version of Meson. Or is there something it is lacking?
>> > > >
>> > > > We could start out with our own Makefile parser and then move
>> > > > onto one in Meson once it is upstreamed and that version of
>> > > > meson is commonly available?
>> > > >
>> > > > Cheers, Jakob.
>> > >
>> > > In the short term I don't know how much it really hurts to
>> > > duplicate the sources in meson vs reading the makefiles,
>> >
>> > That's the question really. If nobody cares about the duplication,
>> > then this patch or any other like it probably isn't worth it.
>> >
>> > I've seen a

Re: [Mesa-dev] [PATCH 06/10] gbm: remove incorrect DRIImage version check in gbm_dri_bo_import()

[Jakob Bornecrantz]

On Mon, Oct 16, 2017 at 5:04 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
>
> The version of the extension does not imply success for the
> queryImage(... WIDTH/HEIGHT ...) calls.
>
> With that properly handled (as of last commit), we can drop the check.
>
> Fixes: 93ebec87ed4 ("dri: Make query image WIDTH and HEIGHT be version 4")
> Cc: Jakob Bornecrantz <jakob.bornecra...@collabora.co.uk>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>

Reviewed-by: Jakob Bornecrantz <jakob.bornecra...@collabora.com>

Cheers, Jakob.

> ---
>  src/gbm/backends/dri/gbm_dri.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
> index a6c80cf1ec7..d7cf01fc6b4 100644
> --- a/src/gbm/backends/dri/gbm_dri.c
> +++ b/src/gbm/backends/dri/gbm_dri.c
> @@ -893,8 +893,7 @@ gbm_dri_bo_import(struct gbm_device *gbm,
> int gbm_format;
> unsigned query; /* EGLBoolean, but we cannot include the header */
>
> -   /* Required for query image WIDTH & HEIGHT */
> -   if (dri->image == NULL || dri->image->base.version < 4) {
> +   if (dri->image == NULL) {
>errno = ENOSYS;
>return NULL;
> }
> --
> 2.14.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 05/10] gbm: handle queryImage() failure through rest of gbm_dri_bo_import()

[Jakob Bornecrantz]

On Mon, Oct 16, 2017 at 5:04 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
>
> Fixes: 6a7dea93fa7 ("dri: Rework planar image interface")
> Cc: Jakob Bornecrantz <jakob.bornecra...@collabora.co.uk>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>

Reviewed-by: Jakob Bornecrantz <jakob.bornecra...@collabora.com>

Cheers, Jakob.

> ---
>  src/gbm/backends/dri/gbm_dri.c | 23 +++
>  1 file changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
> index 9c9066e6661..a6c80cf1ec7 100644
> --- a/src/gbm/backends/dri/gbm_dri.c
> +++ b/src/gbm/backends/dri/gbm_dri.c
> @@ -1048,14 +1048,21 @@ gbm_dri_bo_import(struct gbm_device *gbm,
> bo->base.gbm = gbm;
> bo->base.format = gbm_format;
>
> -   dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_WIDTH,
> -  (int*)>base.width);
> -   dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_HEIGHT,
> -  (int*)>base.height);
> -   dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_STRIDE,
> -  (int*)>base.stride);
> -   dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_HANDLE,
> -  >base.handle.s32);
> +   query = dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_WIDTH,
> +  (int*)>base.width);
> +   query &= dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_HEIGHT,
> +   (int*)>base.height);
> +   query &= dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_STRIDE,
> +   (int*)>base.stride);
> +   query &= dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_HANDLE,
> +   >base.handle.s32);
> +
> +   if (!query) {
> +  errno = EINVAL;
> +  dri->image->destroyImage(bo->image);
> +  free(bo);
> +  return NULL;
> +   }
>
> return >base;
>  }
> --
> 2.14.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] docs: Add EXT_memory_objects extensions to features.txt

[Jakob Bornecrantz]

These extensions are important for Vulkan interop and various
other use cases. So it would be nice if we tracked them.

Cheers, Jakob.

Signed-off-by: Jakob Bornecrantz <jakob.bornecra...@collabora.com>
---
 docs/features.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/docs/features.txt b/docs/features.txt
index 18dddc1aa3..338a22c6c6 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -313,6 +313,12 @@ Khronos, ARB, and OES extensions that are not part of any 
OpenGL or OpenGL ES ve
   GL_ARB_sparse_texture2not started
   GL_ARB_sparse_texture_clamp   not started
   GL_ARB_texture_filter_minmax  not started
+  GL_EXT_memory_object  DONE (radeonsi)
+  GL_EXT_memory_object_fd   DONE (radeonsi)
+  GL_EXT_memory_object_win32not started
+  GL_EXT_semaphore  not started
+  GL_EXT_semaphore_fd   not started
+  GL_EXT_semaphore_win32not started
   GL_KHR_blend_equation_advanced_coherent   DONE (i965/gen9+)
   GL_KHR_texture_compression_astc_hdr   DONE (i965/bxt)
   GL_KHR_texture_compression_astc_sliced_3d DONE (i965/gen9+)
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH 1/2] meson: provide Makefile.sources variables to meson build

[Jakob Bornecrantz]

On Sat, Oct 14, 2017 at 1:36 AM, Dylan Baker  wrote:
> I'm not sure about this approach, we would need a way to add depends to meson,
> but I'm also worried that calling make adds another dependency that could be
> problematic for windows, and I really don't like the idea of having a
> half-and-half approach with the sources.
>
> Here's what I've been playing with:
> https://github.com/dcbaker/meson/tree/make-import-module
> https://github.com/dcbaker/mesa/tree/wip/meson-makefile-sources
>
> How would you feel about that?

Couldn't you just use the Makefile parser José wrote for the scons
build, that would avoid running make and waiting for a new version of
Meson. Or is there something it is lacking?

We could start out with our own Makefile parser and then move onto one
in Meson once it is upstreamed and that version of meson is commonly
available?

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

Re: [Mesa-dev] initial meson port

[Jakob Bornecrantz]

On Thu, Sep 21, 2017 at 2:20 AM, Eric Anholt  wrote:
> Dylan Baker  writes:
>> Results
>> autotools : sh -c   535.34s user 30.33s system 310% cpu 3:02.05 total
>> meson : sh -c   136.58s user 11.98s system 372% cpu 39.895 total
>
> I just want to point at these numbers again.  meson is so transformative
> for your normal build/test cycles that it's worth it even if we have to
> duplicate source lists.  I know these aren't quite representative
> because of all of automake's checks that haven't been done for meson,
> but here's what we had for the X server conversion:
>
> autotools:   meson:
> no-op build  0.83 0.49
> touch Makefile.am1.28
> touch configure.ac  16.68
> touch meson.build 2.92
> clean ccache build  16.74 1.44
> clean build 52.2427.84
>
> Hopefully we can replace two of our build systems (hopefully android and
> scons?) with this one, and then I think it will definitely be less
> developer build system maintenance, even with duplicated source lists.
> I'd be curious to hear what the vmware folks would need from meson in
> order to drop scons, and I'd be willing to put in a good bit of work to
> make it happen.
>
> Additionally, meson doesn't need the .hs listed in its source lists, so
> these meson.builds are actually more verbose than we need and would drop
> a huge source of our "fix up the build system" patches for automake's
> stupid distcheck.

Wasn't lacking distcheck support one of the arguments against moving
to only a scons build when this was brought up all those years ago?
Does Meson provide something similar, or do people just now get all
of the source from git nowadays?

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

Re: [Mesa-dev] [PATCH v2] glsl: reuse main extension table to appropriate restrict extensions

[Jakob Bornecrantz]

So I have encountered bug that should be fixed by this. In my case its
a happy little accident that I can use GL_ARB_gpu_shader5 in a
compatibility context (since I want the textureGatherOffset
functions). So while one part of me is happy that the bug exist.

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

Re: [Mesa-dev] [PATCH] gallium/tests: add missing arg to util_make_vertex_passthrough_shader()

[Jakob Bornecrantz]

Reviewed-by: Jakob Bornecrantz ja...@vmware.com
On 17 Nov 2014 18:11, Brian Paul bri...@vmware.com wrote:

 Fix oversights from the add a window_space option to the passthrough
 vertex shader patch.
 ---
  src/gallium/tests/trivial/quad-tex.c |2 +-
  src/gallium/tests/trivial/tri.c  |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/src/gallium/tests/trivial/quad-tex.c
 b/src/gallium/tests/trivial/quad-tex.c
 index c09e09a..0d38012 100644
 --- a/src/gallium/tests/trivial/quad-tex.c
 +++ b/src/gallium/tests/trivial/quad-tex.c
 @@ -266,7 +266,7 @@ static void init_prog(struct program *p)
 const uint semantic_names[] = { TGSI_SEMANTIC_POSITION,
 TGSI_SEMANTIC_GENERIC };
 const uint semantic_indexes[] = { 0, 0 };
 -   p-vs = util_make_vertex_passthrough_shader(p-pipe, 2,
 semantic_names, semantic_indexes);
 +   p-vs = util_make_vertex_passthrough_shader(p-pipe, 2,
 semantic_names, semantic_indexes, FALSE);
 }

 /* fragment shader */
 diff --git a/src/gallium/tests/trivial/tri.c
 b/src/gallium/tests/trivial/tri.c
 index dcc5a22..13cc801 100644
 --- a/src/gallium/tests/trivial/tri.c
 +++ b/src/gallium/tests/trivial/tri.c
 @@ -211,7 +211,7 @@ static void init_prog(struct program *p)
 const uint semantic_names[] = {
 TGSI_SEMANTIC_POSITION,

 TGSI_SEMANTIC_COLOR };
 const uint semantic_indexes[] = { 0, 0 };
 -   p-vs =
 util_make_vertex_passthrough_shader(p-pipe, 2, semantic_names,
 semantic_indexes);
 +   p-vs =
 util_make_vertex_passthrough_shader(p-pipe, 2, semantic_names,
 semantic_indexes, FALSE);
 }

 /* fragment shader */
 --
 1.7.10.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] rbug-gui: add a spin button to select the layer index to display

[Jakob Bornecrantz]

On Sun, Aug 24, 2014 at 2:16 PM, Marek Olšák mar...@gmail.com wrote:
 From: Marek Olšák marek.ol...@amd.com

 ---
  res/main.xml  | 144 
 +-
  src/main.c|   9 +++-
  src/program.h |   4 +-
  src/texture.c |  17 +--
  4 files changed, 136 insertions(+), 38 deletions(-)

I'm assuming most of those random changes in the xml are due to the
editing app doing stupid stuff. If that is the case and since the code
changes looks good to me, this patch is

Reviewed-by: Jakob Bornecrantz ja...@vmware.com


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

Re: [Mesa-dev] [PATCH 2/3] rbug-gui: print texture target and format in the info column

[Jakob Bornecrantz]

On Sun, Aug 24, 2014 at 2:16 PM, Marek Olšák mar...@gmail.com wrote:
 From: Marek Olšák marek.ol...@amd.com

 ---
  src/texture.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

Reviewed-by: Jakob Bornecrantz ja...@vmware.com


 diff --git a/src/texture.c b/src/texture.c
 index 659d0de..40e6f29 100644
 --- a/src/texture.c
 +++ b/src/texture.c
 @@ -28,6 +28,9 @@

  #include pipe/p_format.h
  #include util/u_format.h
 +#undef CLAMP
 +#include util/u_inlines.h
 +#include tgsi/tgsi_strings.h

  /* needed for u_tile */
  #include pipe/p_state.h
 @@ -437,7 +440,7 @@ static gboolean texture_action_read_info(struct 
 rbug_event *e,
 struct rbug_proto_texture_info_reply *info;
 struct texture_action_read *action;
 uint32_t serial = 0;
 -   char info_short_string[64];
 +   char info_short_string[128];
 char info_long_string[128];
 GdkPixbuf *buf = NULL;

 @@ -598,7 +601,10 @@ static gboolean texture_action_read_info(struct 
 rbug_event *e,
 case PIPE_FORMAT_B4G4R4X4_UNORM: break;
 }

 -   snprintf(info_short_string, 64, %ux%ux%u, info-width[0], 
 info-height[0], info-depth[0]);
 +   snprintf(info_short_string, 128, %s, %ux%ux%u, %s,
 +tgsi_texture_names[util_pipe_tex_to_tgsi_tex(info-target, 
 info-nr_samples)],
 +info-width[0], info-height[0], info-depth[0],
 +util_format_name(info-format)+12);
 snprintf(info_long_string, 128, %s (%ux%ux%u) %u, 
 util_format_name(info-format), info-width[0], info-height[0], 
 info-depth[0], info-last_level);

 gtk_tree_store_set(p-main.treestore, action-iter,
 --
 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 1/3] rbug-gui: fix build for latest Mesa

[Jakob Bornecrantz]

On Sun, Aug 24, 2014 at 2:16 PM, Marek Olšák mar...@gmail.com wrote:
 From: Marek Olšák marek.ol...@amd.com

 set c99 because u_math.h fails to compile without it with gcc
 ---
  Makefile.in  | 5 +++--
  configure.ac | 2 +-
  2 files changed, 4 insertions(+), 3 deletions(-)

Reviewed-by: Jakob Bornecrantz ja...@vmware.com


 diff --git a/Makefile.in b/Makefile.in
 index 8cca095..07ce2e0 100644
 --- a/Makefile.in
 +++ b/Makefile.in
 @@ -18,8 +18,9 @@ MESA_INCLUDES = \
 -I$(MESA)src/gallium/drivers

  MESA_LIBS = \
 -   -lm -ldl \
 -   $(MESA)/src/gallium/auxiliary/.libs/libgallium.a
 +   $(MESA)/src/gallium/auxiliary/.libs/libgallium.a \
 +   $(MESA)/src/util/.libs/libmesautil.a \
 +   -lm -ldl

  TARGET  := rbug-gui
  ODIR:= .obj
 diff --git a/configure.ac b/configure.ac
 index 4502b20..952f1e4 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -5,7 +5,7 @@ PKG_PROG_PKG_CONFIG()
  PKG_CHECK_MODULES(GTK,[gtkglext-1.0])

  if test $CC = gcc; then
 -   GCC_CFLAGS+= -Wall -W -Werror -Wmissing-prototypes
 +   GCC_CFLAGS+= -Wall -W -Werror -Wmissing-prototypes -std=c99
 GCC_CFLAGS+= -fvisibility=hidden -fPIC
 GCC_LDFLAGS=

 --
 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] st/xa: Don't close the drm fd on failure v2

[Jakob Bornecrantz]

- Original Message -
 If XA fails to initialize with pipe_loader enabled, the pipe_loader's
 cleanup function will close the drm file descriptor. That's pretty bad
 because the file descriptor will probably be the X server driver's only
 connection to drm. Temporarily solve this by dup()'ing the file descriptor
 before handing it over to the pipe loader.
 
 This fixes freedesktop.org bugzilla bug #80645.
 
 v2: Fix CC addresses.
 
 Cc: 10.2 mesa-sta...@lists.freedesktop.org
 Signed-off-by: Thomas Hellstrom thellst...@vmware.com
 ---
  src/gallium/state_trackers/xa/xa_tracker.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

Reviewed-by: Jakob Bornecrantz ja...@vmware.com

Cheers, Jakob.

 
 diff --git a/src/gallium/state_trackers/xa/xa_tracker.c
 b/src/gallium/state_trackers/xa/xa_tracker.c
 index 6e4312e..268d56b 100644
 --- a/src/gallium/state_trackers/xa/xa_tracker.c
 +++ b/src/gallium/state_trackers/xa/xa_tracker.c
 @@ -26,6 +26,7 @@
   * Thomas Hellstrom thellstrom-at-vmware-dot-com
   */
  
 +#include unistd.h
  #include xa_tracker.h
  #include xa_priv.h
  #include pipe/p_state.h
 @@ -140,6 +141,7 @@ xa_tracker_create(int drm_fd)
  struct xa_tracker *xa = calloc(1, sizeof(struct xa_tracker));
  enum xa_surface_type stype;
  unsigned int num_formats;
 +int loader_fd;
  
  if (!xa)
   return NULL;
 @@ -147,7 +149,10 @@ xa_tracker_create(int drm_fd)
  #if GALLIUM_STATIC_TARGETS
  xa-screen = dd_create_screen(drm_fd);
  #else
 -if (pipe_loader_drm_probe_fd(xa-dev, drm_fd, false))
 +loader_fd = dup(drm_fd);
 +if (loader_fd == -1)
 +return NULL;
 +if (pipe_loader_drm_probe_fd(xa-dev, loader_fd, false))
   xa-screen = pipe_loader_create_screen(xa-dev, PIPE_SEARCH_DIR);
  #endif
  if (!xa-screen)
 --
 2.0.0
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] scons: avoid building any piece of i915

[Jakob Bornecrantz]

On Thu, Jun 19, 2014 at 9:02 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
 Leftover from commit c21fca8bf24.

 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
 ---
  src/gallium/SConscript| 11 ---
  src/gallium/drivers/i915/SConscript   | 12 
  src/gallium/winsys/i915/sw/SConscript | 12 
  3 files changed, 35 deletions(-)
  delete mode 100644 src/gallium/drivers/i915/SConscript
  delete mode 100644 src/gallium/winsys/i915/sw/SConscript

Reviewed-by: Jakob Bornecrantz wallbra...@gmail.com


 diff --git a/src/gallium/SConscript b/src/gallium/SConscript
 index d6ca993..2ce8a46 100644
 --- a/src/gallium/SConscript
 +++ b/src/gallium/SConscript
 @@ -21,12 +21,6 @@ SConscript([
  'drivers/trace/SConscript',
  ])

 -if not env['msvc']:
 -# These drivers do not build on MSVC compilers
 -SConscript([
 -'drivers/i915/SConscript',
 -])
 -
  #
  # State trackers
  #
 @@ -62,11 +56,6 @@ if env['platform'] == 'windows':
  'winsys/sw/gdi/SConscript',
  ])

 -if not env['msvc']:
 -SConscript([
 -'winsys/i915/sw/SConscript',
 -])
 -
  if env['platform'] == 'haiku':
  SConscript([
  'winsys/sw/hgl/SConscript',
 diff --git a/src/gallium/drivers/i915/SConscript 
 b/src/gallium/drivers/i915/SConscript
 deleted file mode 100644
 index 22de67d..000
 --- a/src/gallium/drivers/i915/SConscript
 +++ /dev/null
 @@ -1,12 +0,0 @@
 -Import('*')
 -
 -env = env.Clone()
 -
 -i915 = env.ConvenienceLibrary(
 -   target = 'i915',
 -   source = env.ParseSourceList('Makefile.sources', 'C_SOURCES')
 -   )
 -
 -env.Alias('i915', i915)
 -
 -Export('i915')
 diff --git a/src/gallium/winsys/i915/sw/SConscript 
 b/src/gallium/winsys/i915/sw/SConscript
 deleted file mode 100644
 index 9d78519..000
 --- a/src/gallium/winsys/i915/sw/SConscript
 +++ /dev/null
 @@ -1,12 +0,0 @@
 -Import('*')
 -
 -env = env.Clone()
 -
 -i915_sw_sources = env.ParseSourceList('Makefile.sources', 'C_SOURCES')
 -
 -i915sw = env.ConvenienceLibrary(
 -target ='i915sw',
 -source = i915_sw_sources,
 -)
 -
 -Export('i915sw')
 --
 2.0.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 00/23] Megadrivers galore

[Jakob Bornecrantz]

On Tue, Jun 17, 2014 at 8:38 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
 Hi all,

 As a follow up to the static/shared pipe-drivers series here is the final
 series (if anyone is interested I may take a look at egl + opencl) of
 refactoring the gallium dri targets into a single library/provider.

 In a nutshell:
  - Convert one target per patch.
  - Merge the drm and sw backends of our dri state-tracker.
  - Adds __driDriverGetExtensions_$drivername symbol for each driver.
  - Megadrivers.
  - ***
  - Profit.

 Things works like a charm for nouveau and swrast, and testing on other
 platforms is greatly appreciated.

 The complete series can be found in the static-or-shared-pipe-drivers-v2
 branch at my github repo.

 I would like to get this reviewed/pushed over the next month, although
 that depends on the number of bugs that come up with the previous batch.

 As always comments, suggestions and flame is welcome.

I'm trying to get a better grasp of the resulting set of binaries will look like
on a distro, correct me if I'm wrong, by default we will get one gallium_dri.so
that is linked against shared dri core and glapi correct. And then hardlinks
from say vmwgfx_dri.so to gallium_dri.so?

Also looking at the patch it looks like stdri can still be build without
DRM installed on the system? I remember the Hurd people being
quite vocal about this.

Cheers, Jakob.


 Cheers,
 Emil

 Emil Velikov (23):
   targets/dri-swrast: use drm aware dricommon when building more than 
 swrast
   st/dri: Allow separate dri-targets
   st/dri/drm: Add a second libdridrm library
   targets/dri-nouveau: Convert to static/shared pipe-drivers
   targets/(r300|r600|radeonsi)/dri: Convert to static/shared pipe-drivers
   targets/dri-freedreno: Convert to static/shared pipe-drivers
   targets/dri-i915: Convert to static/shared pipe-drivers
   targets/dri-ilo: Convert to static/shared pipe-driver
   targets/dri-vmwgfx: Convert to static/shared pipe-drivers
   st/dri: Remove the old libdridrm library
   targets/dri: Add __driDriverGetExtensions_nouveau symbol
   targets/dri: Add __driDriverGetExtensions_(r300|r600|radeonsi) symbols
   targets/dri: Add __driDriverGetExtensions_freedreno symbol
   targets/dri: Add __driDriverGetExtensions_i915 symbol
   targets/dri: Add __driDriverGetExtensions_i965 symbol
   targets/dri: Add __driDriverGetExtensions_vmwgfx
   targets/dri: update scons build to handle 
 __driDriverGetExtensions_vmwgfx
   targets/dri: cleanup conversion leftovers
   st/dri/drm: remove __driDriverExtensions and driDriverAPI
   scons: build and use a single dri_common library
   targets/dri-swrast: convert to gallium megadrivers :)
   st/dri: merge dri/drm and dri/sw backends
   targets/dri-swrast: Convert to static/shared pipe-driver

  61 files changed, 536 insertions(+), 1375 deletions(-)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/23] Megadrivers galore

[Jakob Bornecrantz]

On Thu, Jun 19, 2014 at 1:08 PM, Marek Olšák mar...@gmail.com wrote:
 Hi Jakob,

 libdricore was nuked quite some time ago. What classic drivers now use
 is all drivers in mesa_dri_drivers.so and the _dri.so files are
 hardlinks to that file.

Ah, thanks for the info. Wouldn't that mean that mesa core code like the
glsl compiler is duplicated in gallium_dri.so and mesa_dri_drivers.so?

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

Re: [Mesa-dev] [PATCH 00/23] Megadrivers galore

[Jakob Bornecrantz]

Thanks again, and fair enough. :)

Cheers, Jakob.

On Thu, Jun 19, 2014 at 1:22 PM, Marek Olšák mar...@gmail.com wrote:
 Yes, that's correct. However, it's better to duplicate the same code
 twice than ten times.

 Marek

 On Thu, Jun 19, 2014 at 1:12 PM, Jakob Bornecrantz wallbra...@gmail.com 
 wrote:
 On Thu, Jun 19, 2014 at 1:08 PM, Marek Olšák mar...@gmail.com wrote:
 Hi Jakob,

 libdricore was nuked quite some time ago. What classic drivers now use
 is all drivers in mesa_dri_drivers.so and the _dri.so files are
 hardlinks to that file.

 Ah, thanks for the info. Wouldn't that mean that mesa core code like the
 glsl compiler is duplicated in gallium_dri.so and mesa_dri_drivers.so?

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

Re: [Mesa-dev] [PATCH] rbug: add missing pipe-blit() entrypoint

[Jakob Bornecrantz]

Reviewed-by: Jakob Bornecrantz ja...@vmware.com

On Wed, May 21, 2014 at 1:44 PM, Rob Clark robdcl...@gmail.com wrote:
 From: Rob Clark robcl...@freedesktop.org

 Signed-off-by: Rob Clark robcl...@freedesktop.org
 ---
  src/gallium/drivers/rbug/rbug_context.c | 21 +
  1 file changed, 21 insertions(+)

 diff --git a/src/gallium/drivers/rbug/rbug_context.c 
 b/src/gallium/drivers/rbug/rbug_context.c
 index 0e7badb..2b99ddd 100644
 --- a/src/gallium/drivers/rbug/rbug_context.c
 +++ b/src/gallium/drivers/rbug/rbug_context.c
 @@ -831,6 +831,26 @@ rbug_resource_copy_region(struct pipe_context *_pipe,
  }

  static void
 +rbug_blit(struct pipe_context *_pipe, const struct pipe_blit_info 
 *_blit_info)
 +{
 +   struct rbug_context *rb_pipe = rbug_context(_pipe);
 +   struct rbug_resource *rb_resource_dst = 
 rbug_resource(_blit_info-dst.resource);
 +   struct rbug_resource *rb_resource_src = 
 rbug_resource(_blit_info-src.resource);
 +   struct pipe_context *pipe = rb_pipe-pipe;
 +   struct pipe_resource *dst = rb_resource_dst-resource;
 +   struct pipe_resource *src = rb_resource_src-resource;
 +   struct pipe_blit_info blit_info;
 +
 +   blit_info = *_blit_info;
 +   blit_info.dst.resource = dst;
 +   blit_info.src.resource = src;
 +
 +   pipe_mutex_lock(rb_pipe-call_mutex);
 +   pipe-blit(pipe, blit_info);
 +   pipe_mutex_unlock(rb_pipe-call_mutex);
 +}
 +
 +static void
  rbug_flush_resource(struct pipe_context *_pipe,
  struct pipe_resource *_res)
  {
 @@ -1151,6 +1171,7 @@ rbug_context_create(struct pipe_screen *_screen, struct 
 pipe_context *pipe)
 rb_pipe-base.set_index_buffer = rbug_set_index_buffer;
 rb_pipe-base.set_sample_mask = rbug_set_sample_mask;
 rb_pipe-base.resource_copy_region = rbug_resource_copy_region;
 +   rb_pipe-base.blit = rbug_blit;
 rb_pipe-base.flush_resource = rbug_flush_resource;
 rb_pipe-base.clear = rbug_clear;
 rb_pipe-base.clear_render_target = rbug_clear_render_target;
 --
 1.9.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 03/23] scons: remove dri-i915 build target

[Jakob Bornecrantz]

Acked-by: Jakob Bornecrantz wallbra...@gmail.com

On Sun, May 18, 2014 at 9:07 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
 Unmaintained and broken.

 Cc: Jakob Bornecrantz ja...@vmware.com
 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
 ---
  scons/gallium.py  |  1 -
  src/gallium/SConscript|  9 -
  src/gallium/targets/dri-i915/SConscript   | 29 -
  src/gallium/targets/egl-static/SConscript |  9 -
  src/gallium/winsys/i915/drm/SConscript| 14 --
  5 files changed, 62 deletions(-)
  delete mode 100644 src/gallium/targets/dri-i915/SConscript
  delete mode 100644 src/gallium/winsys/i915/drm/SConscript

 diff --git a/scons/gallium.py b/scons/gallium.py
 index 5109ebf..4c194aa 100755
 --- a/scons/gallium.py
 +++ b/scons/gallium.py
 @@ -591,7 +591,6 @@ def generate(env):
  env.PkgCheckModules('XCB', ['x11-xcb', 'xcb-glx = 1.8.1'])
  env.PkgCheckModules('XF86VIDMODE', ['xxf86vm'])
  env.PkgCheckModules('DRM', ['libdrm = 2.4.38'])
 -env.PkgCheckModules('DRM_INTEL', ['libdrm_intel = 2.4.52'])
  env.PkgCheckModules('UDEV', ['libudev = 151'])

  env['dri'] = env['x11'] and env['drm']
 diff --git a/src/gallium/SConscript b/src/gallium/SConscript
 index 32bbdbe..816c79c 100644
 --- a/src/gallium/SConscript
 +++ b/src/gallium/SConscript
 @@ -85,11 +85,6 @@ if env['dri']:
  'winsys/svga/drm/SConscript',
  ])

 -if env['drm_intel']:
 -SConscript([
 -'winsys/i915/drm/SConscript',
 -])
 -
  #
  # Targets
  #
 @@ -126,10 +121,6 @@ if not env['embedded']:
  'targets/dri-swrast/SConscript',
  'targets/dri-vmwgfx/SConscript',
  ])
 -if env['drm_intel']:
 -SConscript([
 -'targets/dri-i915/SConscript',
 -])


  #
 diff --git a/src/gallium/targets/dri-i915/SConscript 
 b/src/gallium/targets/dri-i915/SConscript
 deleted file mode 100644
 index b3bd3dd..000
 --- a/src/gallium/targets/dri-i915/SConscript
 +++ /dev/null
 @@ -1,29 +0,0 @@
 -Import('*')
 -
 -env = drienv.Clone()
 -
 -env.PkgUseModules('DRM_INTEL')
 -
 -env.Append(CPPDEFINES = ['GALLIUM_RBUG', 'GALLIUM_TRACE', 'GALLIUM_GALAHAD'])
 -
 -env.Prepend(LIBS = [
 -ws_wrapper,
 -st_dri,
 -i915drm,
 -i915,
 -galahad,
 -trace,
 -rbug,
 -mesa,
 -glsl,
 -gallium,
 -COMMON_DRI_DRM_OBJECTS
 -])
 -
 -module = env.LoadableModule(
 -target = 'i915_dri.so',
 -source = 'target.c',
 -SHLIBPREFIX = '',
 -)
 -
 -env.Alias('dri-i915', module)
 diff --git a/src/gallium/targets/egl-static/SConscript 
 b/src/gallium/targets/egl-static/SConscript
 index 83937fe..afb5c11 100644
 --- a/src/gallium/targets/egl-static/SConscript
 +++ b/src/gallium/targets/egl-static/SConscript
 @@ -91,15 +91,6 @@ if env['HAVE_X11']:
  if env['HAVE_DRM']:
  env.PkgUseModules('DRM')

 -if env['HAVE_DRM_INTEL']:
 -env.PkgUseModules('DRM_INTEL')
 -env.Append(CPPDEFINES = ['_EGL_PIPE_I915'])
 -env.Prepend(LIBS = [
 -i915drm,
 -i915,
 -ws_wrapper,
 -])
 -
  env.Append(CPPDEFINES = ['_EGL_PIPE_VMWGFX'])
  env.Prepend(LIBS = [
  svgadrm,
 diff --git a/src/gallium/winsys/i915/drm/SConscript 
 b/src/gallium/winsys/i915/drm/SConscript
 deleted file mode 100644
 index 3d27628..000
 --- a/src/gallium/winsys/i915/drm/SConscript
 +++ /dev/null
 @@ -1,14 +0,0 @@
 -Import('*')
 -
 -env = env.Clone()
 -
 -env.PkgUseModules('DRM')
 -
 -i915drm_sources = env.ParseSourceList('Makefile.sources', 'C_SOURCES')
 -
 -i915drm = env.ConvenienceLibrary(
 -target ='i915drm',
 -source = i915drm_sources,
 -)
 -
 -Export('i915drm')
 --
 1.9.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] st/xa: Fix performance regression introduced by commit Cache render target surface

[Jakob Bornecrantz]

On Thu, May 8, 2014 at 9:15 AM, Thomas Hellstrom thellst...@vmware.com wrote:
 The mentioned commit has the nasty side-effect of turning off accelerated
 copies.

 Cc: 10.1 10.2 mesa-sta...@lists.freedekstop.org
 Signed-off-by: Thomas Hellstrom thellst...@vmware.com
 ---
  src/gallium/state_trackers/xa/xa_context.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Reviewed-by: Jakob Bornecrantz ja...@vmware.com

 diff --git a/src/gallium/state_trackers/xa/xa_context.c 
 b/src/gallium/state_trackers/xa/xa_context.c
 index 37de45b..df3043c 100644
 --- a/src/gallium/state_trackers/xa/xa_context.c
 +++ b/src/gallium/state_trackers/xa/xa_context.c
 @@ -223,7 +223,7 @@ XA_EXPORT int
  xa_copy_prepare(struct xa_context *ctx,
 struct xa_surface *dst, struct xa_surface *src)
  {
 -if (src == dst || ctx-srf != NULL)
 +if (src == dst)
 return -XA_ERR_INVAL;

  if (src-tex-format != dst-tex-format) {
 --
 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

Re: [Mesa-dev] [PATCH] st/xa: Fix performance regression introduced by commit Cache render target surface

[Jakob Bornecrantz]

On Thu, May 8, 2014 at 9:15 AM, Thomas Hellstrom thellst...@vmware.com wrote:
 The mentioned commit has the nasty side-effect of turning off accelerated
 copies.

 Cc: 10.1 10.2 mesa-sta...@lists.freedekstop.org
 Signed-off-by: Thomas Hellstrom thellst...@vmware.com
 ---
  src/gallium/state_trackers/xa/xa_context.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Jakob Bornecrantz ja...@vmware.com

 diff --git a/src/gallium/state_trackers/xa/xa_context.c 
 b/src/gallium/state_trackers/xa/xa_context.c
 index 37de45b..df3043c 100644
 --- a/src/gallium/state_trackers/xa/xa_context.c
 +++ b/src/gallium/state_trackers/xa/xa_context.c
 @@ -223,7 +223,7 @@ XA_EXPORT int
  xa_copy_prepare(struct xa_context *ctx,
 struct xa_surface *dst, struct xa_surface *src)
  {
 -if (src == dst || ctx-srf != NULL)
 +if (src == dst)
 return -XA_ERR_INVAL;

  if (src-tex-format != dst-tex-format) {
 --
 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

Re: [Mesa-dev] [PATCH 1/5] mesa: use malloc/free instead of MALLOC/FREE in attrib stack code

[Jakob Bornecrantz]

On Thu, Apr 10, 2014 at 4:41 AM, Kenneth Graunke kenn...@whitecape.org wrote:
 On 04/09/2014 06:39 PM, Brian Paul wrote:
 We moved away from MALLOC/FREE in the rest of core Mesa a while ago.
 ---
  src/mesa/main/attrib.c |   20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

 Series is:
 Reviewed-by: Kenneth Graunke kenn...@whitecape.org

Was looking trough the series but couldn't find the first patch, but
now I have and also the series is:
Reviewed-by: Jakob Bornecrantz ja...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: fix sampler_view REALLOC/FREE macro mix-up

[Jakob Bornecrantz]

On Thu, Apr 10, 2014 at 3:26 AM, Brian Paul bri...@vmware.com wrote:
 We were using REALLOC() from u_memory.h but FREE() from imports.h.
 This mismatch caused us to trash the heap on Windows after we
 deleted a texture object.

 This fixes a regression from commit 6c59be7776e4d.
 ---
  src/mesa/state_tracker/st_cb_texture.c |2 +-
  src/mesa/state_tracker/st_texture.c|   12 
  src/mesa/state_tracker/st_texture.h|3 +++
  3 files changed, 16 insertions(+), 1 deletion(-)

Is this patch obsoleted by the FREE/MALLOC remove series? Otherwise
this patch is:
Reviewed-by: Jakob Bornecrantz ja...@vmware.com

Cheers, Jakob.


 diff --git a/src/mesa/state_tracker/st_cb_texture.c 
 b/src/mesa/state_tracker/st_cb_texture.c
 index 353415b..304dc91 100644
 --- a/src/mesa/state_tracker/st_cb_texture.c
 +++ b/src/mesa/state_tracker/st_cb_texture.c
 @@ -155,7 +155,7 @@ st_DeleteTextureObject(struct gl_context *ctx,

 pipe_resource_reference(stObj-pt, NULL);
 st_texture_release_all_sampler_views(stObj);
 -   FREE(stObj-sampler_views);
 +   st_texture_free_sampler_views(stObj);
 _mesa_delete_texture_object(ctx, texObj);
  }

 diff --git a/src/mesa/state_tracker/st_texture.c 
 b/src/mesa/state_tracker/st_texture.c
 index 8d559df..cfa0605 100644
 --- a/src/mesa/state_tracker/st_texture.c
 +++ b/src/mesa/state_tracker/st_texture.c
 @@ -483,3 +483,15 @@ st_texture_release_all_sampler_views(struct 
 st_texture_object *stObj)
 for (i = 0; i  stObj-num_sampler_views; ++i)
pipe_sampler_view_reference(stObj-sampler_views[i], NULL);
  }
 +
 +
 +void
 +st_texture_free_sampler_views(struct st_texture_object *stObj)
 +{
 +   /* NOTE:
 +* We use FREE() here to match REALLOC() above.  Both come from
 +* u_memory.h, not imports.h.  If we mis-match MALLOC/FREE from
 +* those two headers we can trash the heap.
 +*/
 +   FREE(stObj-sampler_views);
 +}
 diff --git a/src/mesa/state_tracker/st_texture.h 
 b/src/mesa/state_tracker/st_texture.h
 index 87de9f9..f2afaf1 100644
 --- a/src/mesa/state_tracker/st_texture.h
 +++ b/src/mesa/state_tracker/st_texture.h
 @@ -241,4 +241,7 @@ st_texture_release_sampler_view(struct st_context *st,
  extern void
  st_texture_release_all_sampler_views(struct st_texture_object *stObj);

 +void
 +st_texture_free_sampler_views(struct st_texture_object *stObj);
 +
  #endif
 --
 1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: fix sampler_view REALLOC/FREE macro mix-up

[Jakob Bornecrantz]

On 10 Apr 2014 15:56, Brian Paul bri...@vmware.com wrote:

 On 04/10/2014 01:43 AM, Jakob Bornecrantz wrote:

 On Thu, Apr 10, 2014 at 3:26 AM, Brian Paul bri...@vmware.com wrote:

 We were using REALLOC() from u_memory.h but FREE() from imports.h.
 This mismatch caused us to trash the heap on Windows after we
 deleted a texture object.

 This fixes a regression from commit 6c59be7776e4d.
 ---
   src/mesa/state_tracker/st_cb_texture.c |2 +-
   src/mesa/state_tracker/st_texture.c|   12 
   src/mesa/state_tracker/st_texture.h|3 +++
   3 files changed, 16 insertions(+), 1 deletion(-)


 Is this patch obsoleted by the FREE/MALLOC remove series?


 Not exactly.  If I try to use FREE(stObj-sampler_views) in
st_cb_texture.c I need to include u_memory.h.  But then I get
preprocessor warnings about MALLOC_STRUCT() and CALLOC_STRUCT() being
redefined.  So then I need to insert some #undef MALLOC_STRUCT lines.
 It's just messy.

Ah fair enough.

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

Re: [Mesa-dev] [PATCH] svga: move LIST_INITHEAD(dirty_buffers) earlier in svga_context_create()

[Jakob Bornecrantz]

On Wed, Apr 9, 2014 at 7:40 PM, Brian Paul bri...@vmware.com wrote:
 Fixes a crash in svga_context_flush_buffers() if we use the 'draw' module
 for AA lines (when the device doesn't support that feature).  We need to
 initialize this list before we setup the swtnl pieces.

 Found/fixed by Charmaine Lee.

 Cc: 10.0 mesa-sta...@lists.freedesktop.org
 ---
  src/gallium/drivers/svga/svga_context.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Jakob Bornecrantz ja...@vmware.com

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

Re: [Mesa-dev] [PATCH 1/2] winsys/svga: Update the vmwgfx_drm.h header to latest version from kernel

[Jakob Bornecrantz]

On Mon, Apr 7, 2014 at 11:50 AM, Thomas Hellstrom thellst...@vmware.com wrote:
 Cc: 10.1 mesa-sta...@lists.freedesktop.org
 Signed-off-by: Thomas Hellstrom thellst...@vmware.com

 ---
  src/gallium/winsys/svga/drm/vmwgfx_drm.h | 13 -
  1 file changed, 12 insertions(+), 1 deletion(-)

Both patches are:
Reviewed-by: Jakob Bornecrantz ja...@vmware.com

Cheers, Jakob.


 diff --git a/src/gallium/winsys/svga/drm/vmwgfx_drm.h 
 b/src/gallium/winsys/svga/drm/vmwgfx_drm.h
 index e42b3f5..73ad205 100644
 --- a/src/gallium/winsys/svga/drm/vmwgfx_drm.h
 +++ b/src/gallium/winsys/svga/drm/vmwgfx_drm.h
 @@ -87,6 +87,16 @@
  #define DRM_VMW_PARAM_MAX_SURF_MEMORY  7
  #define DRM_VMW_PARAM_3D_CAPS_SIZE 8
  #define DRM_VMW_PARAM_MAX_MOB_MEMORY   9
 +#define DRM_VMW_PARAM_MAX_MOB_SIZE 10
 +
 +/**
 + * enum drm_vmw_handle_type - handle type for ref ioctls
 + *
 + */
 +enum drm_vmw_handle_type {
 +   DRM_VMW_HANDLE_LEGACY = 0,
 +   DRM_VMW_HANDLE_PRIME = 1
 +};

  /**
   * struct drm_vmw_getparam_arg
 @@ -176,6 +186,7 @@ struct drm_vmw_surface_create_req {
   * struct drm_wmv_surface_arg
   *
   * @sid: Surface id of created surface or surface to destroy or reference.
 + * @handle_type: Handle type for DRM_VMW_REF_SURFACE Ioctl.
   *
   * Output data from the DRM_VMW_CREATE_SURFACE Ioctl.
   * Input argument to the DRM_VMW_UNREF_SURFACE Ioctl.
 @@ -184,7 +195,7 @@ struct drm_vmw_surface_create_req {

  struct drm_vmw_surface_arg {
 int32_t sid;
 -   uint32_t pad64;
 +   enum drm_vmw_handle_type handle_type;
  };

  /**
 --
 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] st/xa: Bind destination before setting new state

[Jakob Bornecrantz]

On Mon, Apr 7, 2014 at 12:32 PM, Thomas Hellstrom thellst...@vmware.com wrote:
 Binding a new destination may cause the svga driver to emit draw calls
 while propagating the surface. Make sure this doesn't happen in the middle
 of sampler state setup where state may be incosistent.

 In practice, surface propagation should never happen here and even if it did,
 it wouldn't be a valid reason for the svga driver to emit partially set up
 state, but to avoid future uncertainties, make sure this doesn't happen
 anyway.

 Found while auditing the state tracker for inconsistent sampler state /
 sampler view setup.

 Signed-off-by: Thomas Hellstrom thellst...@vmware.com
 ---
  src/gallium/state_trackers/xa/xa_renderer.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Jakob Bornecrantz ja...@vmware.com

Cheers, Jakob.


 diff --git a/src/gallium/state_trackers/xa/xa_renderer.c 
 b/src/gallium/state_trackers/xa/xa_renderer.c
 index b775509..d22851f 100644
 --- a/src/gallium/state_trackers/xa/xa_renderer.c
 +++ b/src/gallium/state_trackers/xa/xa_renderer.c
 @@ -406,6 +406,9 @@ renderer_copy_prepare(struct xa_context *r,
PIPE_BIND_RENDER_TARGET));
  (void)screen;

 +renderer_bind_destination(r, dst_surface,
 + dst_surface-width, dst_surface-height);
 +
  /* set misc state we care about */
  {
 struct pipe_blend_state blend;
 @@ -435,9 +438,6 @@ renderer_copy_prepare(struct xa_context *r,
 cso_single_sampler_done(r-cso, PIPE_SHADER_FRAGMENT);
  }

 -renderer_bind_destination(r, dst_surface,
 - dst_surface-width, dst_surface-height);
 -
  /* texture/sampler view */
  {
 struct pipe_sampler_view templ;
 --
 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] gallium/rtasm: handle mmap failures appropriately

[Jakob Bornecrantz]

On Mon, Jan 27, 2014 at 12:57 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
 Ping :)

 On 19/01/14 23:53, Emil Velikov wrote:
 For a variety of reasons mmap (selinux and pax to name
 a few) and can fail and with current code. This will
 result in a crash in the driver, if not worse.

 This has been the case since the inception of the
 gallium copy of rtasm.

 Cc: 9.1 9.2 10.0 mesa-sta...@lists.freedesktop.org
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73473
 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
 ---
 v2: droped the selinux part, leaving only the crucial mmap check

 Gents can someone take a look at this trivial patch.

 Cheers,
 Emil

Reviewed-by: Jakob Bornecrantz ja...@vmware.com

 ---
  src/gallium/auxiliary/rtasm/rtasm_execmem.c | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

 diff --git a/src/gallium/auxiliary/rtasm/rtasm_execmem.c 
 b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
 index edc1b66..8c3dbef 100644
 --- a/src/gallium/auxiliary/rtasm/rtasm_execmem.c
 +++ b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
 @@ -69,7 +69,7 @@ static struct mem_block *exec_heap = NULL;
  static unsigned char *exec_mem = NULL;


 -static void
 +static int
  init_heap(void)
  {
 if (!exec_heap)
 @@ -79,6 +79,8 @@ init_heap(void)
exec_mem = (unsigned char *) mmap(0, EXEC_HEAP_SIZE,
   PROT_EXEC | PROT_READ | PROT_WRITE,
   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
 +
 +   return (exec_mem != MAP_FAILED);
  }


 @@ -90,7 +92,8 @@ rtasm_exec_malloc(size_t size)

 pipe_mutex_lock(exec_mutex);

 -   init_heap();
 +   if (!init_heap())
 +  goto bail;

 if (exec_heap) {
size = (size + 31)  ~31;  /* next multiple of 32 bytes */
 @@ -101,7 +104,8 @@ rtasm_exec_malloc(size_t size)
addr = exec_mem + block-ofs;
 else
debug_printf(rtasm_exec_malloc failed\n);
 -
 +
 +bail:
 pipe_mutex_unlock(exec_mutex);

 return addr;

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

Re: [Mesa-dev] [PATCH] svga: dynamically allocate svga_texture::rendered_to array

[Jakob Bornecrantz]

Reviewed-by: Jakob Bornecrantz ja...@vmware.com

On Sat, Nov 16, 2013 at 4:49 PM, Brian Paul bri...@vmware.com wrote:
 Needs to be larger than 6 to accomodate 3D textures and array textures.
 Fixes a few piglit tests (fbo-3d, copyteximage 3D).
 ---
  src/gallium/drivers/svga/svga_resource_texture.c |9 +
  src/gallium/drivers/svga/svga_resource_texture.h |   41 
 --
  2 files changed, 32 insertions(+), 18 deletions(-)

 diff --git a/src/gallium/drivers/svga/svga_resource_texture.c 
 b/src/gallium/drivers/svga/svga_resource_texture.c
 index 17c87ef..88ab451 100644
 --- a/src/gallium/drivers/svga/svga_resource_texture.c
 +++ b/src/gallium/drivers/svga/svga_resource_texture.c
 @@ -238,6 +238,7 @@ svga_texture_destroy(struct pipe_screen *screen,

 ss-total_resource_bytes -= tex-size;

 +   FREE(tex-rendered_to);
 FREE(tex);
  }

 @@ -735,9 +736,15 @@ svga_texture_create(struct pipe_screen *screen,
 tex-size = util_resource_size(template);
 svgascreen-total_resource_bytes += tex-size;

 +   tex-rendered_to = calloc(template-depth0 * template-array_size,
 + sizeof(tex-rendered_to[0]));
 +   if (!tex-rendered_to)
 +  goto error2;
 +
 return tex-b.b;

  error2:
 +   FREE(tex-rendered_to);
 FREE(tex);
  error1:
 return NULL;
 @@ -796,5 +803,7 @@ svga_texture_from_handle(struct pipe_screen *screen,
 tex-key.cachable = 0;
 tex-handle = srf;

 +   tex-rendered_to = malloc(sizeof(tex-rendered_to[0]));
 +
 return tex-b.b;
  }
 diff --git a/src/gallium/drivers/svga/svga_resource_texture.h 
 b/src/gallium/drivers/svga/svga_resource_texture.h
 index 6c7a754..1ff42fa 100644
 --- a/src/gallium/drivers/svga/svga_resource_texture.h
 +++ b/src/gallium/drivers/svga/svga_resource_texture.h
 @@ -79,7 +79,8 @@ struct svga_texture

 unsigned size;  /** Approximate size in bytes */

 -   unsigned rendered_to[6];  /** six cube faces, one bit per mipmap level */
 +   /** array indexed by cube face or 3D/array slice, one bit per mipmap 
 level */
 +   ushort *rendered_to;
  };


 @@ -157,16 +158,30 @@ svga_is_texture_level_defined(const struct svga_texture 
 *tex,
  }


 -static INLINE void
 -svga_set_texture_rendered_to(struct svga_texture *tex,
 - unsigned face, unsigned level)
 +/** For debugging, check that face and level are legal */
 +static inline void
 +check_face_level(const struct svga_texture *tex,
 + unsigned face, unsigned level)
  {
 if (tex-b.b.target == PIPE_TEXTURE_CUBE) {
 -  assert(face  Elements(tex-rendered_to));
 +  assert(face  6);
 +   }
 +   else if (tex-b.b.target == PIPE_TEXTURE_3D) {
 +  assert(face  tex-b.b.depth0);
 }
 else {
 -  assert(face == 0);
 +  assert(face  tex-b.b.array_size);
 }
 +
 +   assert(level  8 * sizeof(tex-rendered_to[0]));
 +}
 +
 +
 +static INLINE void
 +svga_set_texture_rendered_to(struct svga_texture *tex,
 + unsigned face, unsigned level)
 +{
 +   check_face_level(tex, face, level);
 tex-rendered_to[face] |= 1  level;
  }

 @@ -175,12 +190,7 @@ static INLINE void
  svga_clear_texture_rendered_to(struct svga_texture *tex,
 unsigned face, unsigned level)
  {
 -   if (tex-b.b.target == PIPE_TEXTURE_CUBE) {
 -  assert(face  Elements(tex-rendered_to));
 -   }
 -   else {
 -  assert(face == 0);
 -   }
 +   check_face_level(tex, face, level);
 tex-rendered_to[face] = ~(1  level);
  }

 @@ -189,12 +199,7 @@ static INLINE boolean
  svga_was_texture_rendered_to(const struct svga_texture *tex,
   unsigned face, unsigned level)
  {
 -   if (tex-b.b.target == PIPE_TEXTURE_CUBE) {
 -  assert(face  Elements(tex-rendered_to));
 -   }
 -   else {
 -  assert(face == 0);
 -   }
 +   check_face_level(tex, face, level);
 return !!(tex-rendered_to[face]  (1  level));
  }

 --
 1.7.10.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] Dropping the xorg state tracker

[Jakob Bornecrantz]

On Thu, Nov 7, 2013 at 3:30 AM, Stéphane Marchesin
stephane.marche...@gmail.com wrote:
 On Wed, Nov 6, 2013 at 5:43 PM, Matt Turner matts...@gmail.com wrote:
 With the removal of the r600 and radeonsi xorg targets, the only ones
 left are i915 and nouveau. Does anyone have a compelling reason to
 keep them (and the state tracker code itself) around anymore?

 I'm fine with removing the xorg target for i915g, I have never tested it
 actually.

Sad to see it go, but I'm okay with removing it.

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

Re: [Mesa-dev] [RFC] Consolidate the remaining source files to Makefile.sources

[Jakob Bornecrantz]

On Thu, Aug 15, 2013 at 7:04 PM, Emil Velikov emil.l.veli...@gmail.comwrote:

 Hello list

 Feeling inspired by the automake work done in mesa, I felt like
 finishing a few things that did not receive too much attention
  * use Makefile.sources wherever possible
  * cleanup the duplicated C{,PP,XX}FLAGS and factor out the the common
 ones into Automake.inc

 If anyone is interested I have pushed my preliminary work to the
 makefile.sources branch at https://github.com/evelikov/Mesa/

 Currently I have gone through the following:
  gallium/drivers
  gallium/state_trackers/dri/drm
  gallium/state_trackers/dri/sw
  gallium/state_trackers/vega
  gallium/state_trackers/xorg

 Producing the following diff stat:
  54 files changed, 352 insertions(+), 552 deletions(-)


 Pros:
 * patches such as gallium/dri-targets: hide all symbols except for
 __driDriverExtensions will be brought down to changing only with 2-3 lines
 * one less chance of breaking builds when someone forgets to update the
 SCons/Makefile.am/etc build, after adding/removing a file

 Cons:
 * Non nouveau changes will be only(lacking any other the hardware atm).
 Note that I will check the symbols for all drivers, to ensure that I do
 not cause chaos.

 Curious if anyone is interested and have any comments on this.
 Note: there may be some git rebase fails as I've started this ~3months ago


This seems to be have dropped on the floor.

The Makefile.sources patches looks good, can't comment on the other ones.

If you rebase them and you clobber the Makefile.sources ones, then send that
along with the reset of the patches on that branch out I'm sure they will
get reviewed.

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

Re: [Mesa-dev] [PATCH] gallium/dri-targets: hide all symbols except for __driDriverExtensions

[Jakob Bornecrantz]

On Thu, Aug 15, 2013 at 7:38 AM, Chia-I Wu olva...@gmail.com wrote:

 On Thu, Aug 15, 2013 at 1:26 PM, Chia-I Wu olva...@gmail.com wrote:
  On Sat, Aug 10, 2013 at 2:56 AM, Marek Olšák mar...@gmail.com wrote:
  Most importantly, this hides all LLVM symbols. They shouldn't clash
  with a different LLVM version used by apps (at least in theory).
 
  $ nm -g --defined-only radeonsi_dri.so
  01148f30 D __driDriverExtensions
  I am not familiar with issues regarding LLVM symbols so I am fine with
  the change if this is what needs to be done (except maybe use
  -export-symbols-regex __driDriverExtensions to avoid the version
  script?)
 
  But I ran the nm command on ilo_dri.so, and almost all of the exported
  symbols are from libdricommon or st/dri.  I think those two components
  need VISIBILITY_CFLAGS in their AM_CFLAGS and __driDriverExtensions
  needs to be marked as PUBLIC.  This way other gallium targets can
  benefit.
 There is no other gallium target that uses st/dri :)

 Anyway, in addition to controlling exported symbols using symbol
 files, I still like to see VISIBILITY_CFLAGS be added to st/dri and
 the dri targets, which directly list source files from libdrmcommon in
 their SOURCES.  Besides, it seems __driConfigOptions and
 __dri2ConfigOptions are also marked PUBLIC.  Do they need to be
 exported?


I tested the v2 patch on vmwgfx worked but driconf complained after
adding the above two symbols to dri.versions and driconf worked so:

Tested-by: Jakob Bornecrantz ja...@vmware.com
Reviewed-by: Jakob Bornecrantz ja...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl: Do not export private symbols

[Jakob Bornecrantz]

On Tue, Aug 6, 2013 at 9:21 PM, Chad Versace
chad.vers...@linux.intel.comwrote:

 libEGL was incorrectly exporting *all* symbols, public and private.
 This patch adds -fvisibility=hidden to libEGL's linker flags to ensure
 that only symbols annotated with __attribute__((visibility(default)))
 get exported.

 Sanity-checked on X11/EGL with Piglit, and on Wayland by running
 weston-gears.


You need to test this patch on a non-inbuilt driver, egl_gallium or egl_glx,
none of which require you to have any hardware. Or force egl_dri2 to not
be built in.

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

Re: [Mesa-dev] [PATCH] egl: Do not export private symbols

[Jakob Bornecrantz]

On Wed, Aug 7, 2013 at 12:00 AM, Jakob Bornecrantz wallbra...@gmail.comwrote:

 On Tue, Aug 6, 2013 at 9:21 PM, Chad Versace chad.vers...@linux.intel.com
  wrote:

 libEGL was incorrectly exporting *all* symbols, public and private.
 This patch adds -fvisibility=hidden to libEGL's linker flags to ensure
 that only symbols annotated with __attribute__((visibility(default)))
 get exported.

 Sanity-checked on X11/EGL with Piglit, and on Wayland by running
 weston-gears.


 You need to test this patch on a non-inbuilt driver, egl_gallium or
 egl_glx,
 none of which require you to have any hardware. Or force egl_dri2 to not
 be built in.


Do that and you have my
Reviewed-by: Jakob Bornecrantz ja...@vmware.com

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

Re: [Mesa-dev] [PATCH] egl: Do not export private symbols

[Jakob Bornecrantz]

On Wed, Aug 7, 2013 at 2:00 AM, Chad Versace
chad.vers...@linux.intel.comwrote:

 On 08/06/2013 03:02 PM, Jakob Bornecrantz wrote:

 On Wed, Aug 7, 2013 at 12:00 AM, Jakob Bornecrantz wallbra...@gmail.com
 wrote:

  On Tue, Aug 6, 2013 at 9:21 PM, Chad Versace 
 chad.vers...@linux.intel.com

 wrote:


  libEGL was incorrectly exporting *all* symbols, public and private.
 This patch adds -fvisibility=hidden to libEGL's linker flags to ensure
 that only symbols annotated with __attribute__((visibility(**
 default)))
 get exported.

 Sanity-checked on X11/EGL with Piglit, and on Wayland by running
 weston-gears.


 You need to test this patch on a non-inbuilt driver, egl_gallium or
 egl_glx,
 none of which require you to have any hardware. Or force egl_dri2 to not
 be built in.


 Do that and you have my
 Reviewed-by: Jakob Bornecrantz ja...@vmware.com


 Ok. I'll run this on egl_gallium or egl_glx, and then report back.


Either is fine, tho I have no idea if egl_glx even works.

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

Re: [Mesa-dev] [PATCH vmwgfx] update for XA API changes

[Jakob Bornecrantz]

On Thu, Jul 11, 2013 at 1:58 AM, Jakob Bornecrantz wallbra...@gmail.comwrote:

 Just tried this out, on your XA branch, and I'm getting rendering
 issues in gnome-terminal. It looks like some text is offset by
 one or two lines, and the rest looks a bit like pitch issues.

 http://i.imgur.com/mdivF0q.png

 I can't really see anything in the patch that would cause this,
 going to take a extra look at the xa patches on the mesa sida.


Okay, I did some testing and reverted the commit
b89ac75 xa: fix dma copy function and I saw no rendering errors.

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

Re: [Mesa-dev] [RFC] Mesa 9.2 and release process changes

[Jakob Bornecrantz]

On Fri, Jul 19, 2013 at 7:42 PM, Kenneth Graunke kenn...@whitecape.orgwrote:

 On 07/10/2013 04:38 PM, Ian Romanick wrote:
 [snip]

  Could we just change our Mark the patch with 'NOTE: ...' policy with
 To have the patch automatically included in the stable tree, add the tag
  Cc: 
 mesa-stable@lists.freedesktop.**orgmesa-sta...@lists.freedesktop.org

 in the sign-off area... ?


 This loses a bit of information, sadly.

 These two are interchangeable:
 NOTE: This is a candidate for the stable branches.
 Cc: mesa-stable@lists.freedesktop.**orgmesa-sta...@lists.freedesktop.org

 But what about:
 NOTE: This is a candidate for the 9.2 branch.
 (but not the 9.1 branch, or 9.0 branch...)

 What then?


mesa-stable+9_3+...@lists.freedesktop.org ?

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

Re: [Mesa-dev] [PATCH vmwgfx] update for XA API changes

[Jakob Bornecrantz]

Just tried this out, on your XA branch, and I'm getting rendering
issues in gnome-terminal. It looks like some text is offset by
one or two lines, and the rest looks a bit like pitch issues.

http://i.imgur.com/mdivF0q.png

I can't really see anything in the patch that would cause this,
going to take a extra look at the xa patches on the mesa sida.

Cheers, Jakob.


On Mon, Jun 10, 2013 at 7:31 PM, Rob Clark robdcl...@gmail.com wrote:

 Only just compile tested, as I don't have the hardware for it..

 Signed-off-by: Rob Clark robdcl...@gmail.com
 ---
  configure.ac  |  2 +-
  vmwgfx/vmwgfx_dri2.c  |  5 +++--
  vmwgfx/vmwgfx_driver.c|  3 ++-
  vmwgfx/vmwgfx_saa.c   | 20 ++--
  vmwgfx/vmwgfx_tex_video.c |  5 +++--
  5 files changed, 23 insertions(+), 12 deletions(-)

 diff --git a/configure.ac b/configure.ac
 index 0631bcc..dccfb27 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -118,7 +118,7 @@ if test x$BUILD_VMWGFX = xyes; then
 PKG_CHECK_MODULES([LIBDRM], [libdrm],[],[BUILD_VMWGFX=no])
  fi
  if test x$BUILD_VMWGFX = xyes; then
 -   PKG_CHECK_MODULES([XATRACKER], [xatracker =
 0.4.0],[],[BUILD_VMWGFX=no])
 +   PKG_CHECK_MODULES([XATRACKER], [xatracker =
 2.0.0],[],[BUILD_VMWGFX=no])
  fi

  DRIVER_NAME=vmware
 diff --git a/vmwgfx/vmwgfx_dri2.c b/vmwgfx/vmwgfx_dri2.c
 index 7de0772..2f007f0 100644
 --- a/vmwgfx/vmwgfx_dri2.c
 +++ b/vmwgfx/vmwgfx_dri2.c
 @@ -201,7 +201,8 @@ dri2_do_create_buffer(DrawablePtr pDraw,
 DRI2Buffer2Ptr buffer, unsigned int for
  }

  private-srf = srf;
 -if (xa_surface_handle(srf, buffer-name, buffer-pitch) != 0)
 +if (xa_surface_handle(srf, xa_handle_type_shared,
 +   buffer-name, buffer-pitch) != 0)
 return FALSE;

  buffer-cpp = xa_format_depth(xa_surface_format(srf)) / 8;
 @@ -222,7 +223,7 @@ dri2_do_destroy_buffer(DrawablePtr pDraw,
 DRI2BufferPtr buffer)
  struct vmwgfx_saa_pixmap *vpix = vmwgfx_saa_pixmap(private-pPixmap);

  if (--private-refcount == 0  srf) {
 -   xa_surface_destroy(srf);
 +   xa_surface_unref(srf);
  }

  /*
 diff --git a/vmwgfx/vmwgfx_driver.c b/vmwgfx/vmwgfx_driver.c
 index 7863ba2..3002285 100644
 --- a/vmwgfx/vmwgfx_driver.c
 +++ b/vmwgfx/vmwgfx_driver.c
 @@ -617,7 +617,8 @@ vmwgfx_scanout_present(ScreenPtr pScreen, int drm_fd,
 return FALSE;
  }

 -if (xa_surface_handle(vpix-hw, handle, dummy) != 0) {
 +if (xa_surface_handle(vpix-hw, xa_handle_type_shared,
 +   handle, dummy) != 0) {
 LogMessage(X_ERROR, Could not get present surface handle.\n);
 return FALSE;
  }
 diff --git a/vmwgfx/vmwgfx_saa.c b/vmwgfx/vmwgfx_saa.c
 index 63df3a1..ed3c1ee 100644
 --- a/vmwgfx/vmwgfx_saa.c
 +++ b/vmwgfx/vmwgfx_saa.c
 @@ -140,7 +140,7 @@ vmwgfx_pixmap_free_storage(struct vmwgfx_saa_pixmap
 *vpix)
 vpix-malloc = NULL;
  }
  if (!(vpix-backing  VMWGFX_PIX_SURFACE)  vpix-hw) {
 -   xa_surface_destroy(vpix-hw);
 +   xa_surface_unref(vpix-hw);
 vpix-hw = NULL;
  }
  if (!(vpix-backing  VMWGFX_PIX_GMR)  vpix-gmr) {
 @@ -286,7 +286,8 @@ vmwgfx_saa_dma(struct vmwgfx_saa *vsaa,
  if (vpix-gmr  vsaa-can_optimize_dma) {
 uint32_t handle, dummy;

 -   if (xa_surface_handle(vpix-hw, handle, dummy) != 0)
 +   if (xa_surface_handle(vpix-hw, xa_handle_type_shared,
 +handle, dummy) != 0)
 goto out_err;
 if (vmwgfx_dma(0, 0, reg, vpix-gmr, pixmap-devKind, handle,
to_hw) != 0)
 @@ -305,6 +306,8 @@ vmwgfx_saa_dma(struct vmwgfx_saa *vsaa,
  (int) to_hw,
  (struct xa_box *) REGION_RECTS(reg),
  REGION_NUM_RECTS(reg));
 +   if (to_hw)
 +   xa_context_flush(vsaa-xa_ctx);
 if (vpix-gmr)
 vmwgfx_dmabuf_unmap(vpix-gmr);
 if (ret)
 @@ -441,7 +444,7 @@ vmwgfx_hw_kill(struct vmwgfx_saa *vsaa,
  spix-dirty_hw))
 return FALSE;

 -xa_surface_destroy(vpix-hw);
 +xa_surface_unref(vpix-hw);
  vpix-hw = NULL;

  /*
 @@ -683,7 +686,8 @@ vmwgfx_present_prepare(struct vmwgfx_saa *vsaa,

  (void) pScreen;
  if (src_vpix == dst_vpix || !src_vpix-hw ||
 -   xa_surface_handle(src_vpix-hw, vsaa-src_handle, dummy) != 0)
 +   xa_surface_handle(src_vpix-hw, xa_handle_type_shared,
 +   vsaa-src_handle, dummy) != 0)
 return FALSE;

  REGION_NULL(pScreen, vsaa-present_region);
 @@ -784,7 +788,7 @@ vmwgfx_create_hw(struct vmwgfx_saa *vsaa,
  return TRUE;

  out_no_damage:
 -xa_surface_destroy(hw);
 +xa_surface_unref(hw);
  return FALSE;
  }

 @@ -929,6 +933,7 @@ vmwgfx_copy_prepare(struct saa_driver *driver,

 if (!vmwgfx_hw_validate(src_pixmap, src_reg)) {
 xa_copy_done(vsaa-xa_ctx);
 +   xa_context_flush(vsaa-xa_ctx);
 return FALSE;
 }

 @@ -1029,6 

Re: [Mesa-dev] [RFC] Mesa 9.2 and release process changes

[Jakob Bornecrantz]

On Tue, Jul 2, 2013 at 11:37 PM, Matt Turner matts...@gmail.com wrote:

 On Tue, Jul 2, 2013 at 1:02 PM, Ian Romanick i...@freedesktop.org wrote:
  2. Instead of just posting md5sum for the release tarballs, I think we
  should start GPG signing them.  I'm not sure what sort of process we
 want to
  establish for this.  Should they just be signed by the release managers
 key?
  Is this easier than I think it is?

 GPG sign the git tag (git tag -s) and the announce email which
 contains the md5/sha sums. That's how X.Org releases are done.


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

Re: [Mesa-dev] [PATCH mesa 0/8] XA patches for freedreno/a3xx DDX

[Jakob Bornecrantz]

The changes looks good at a first glance.

There are some thoughts tho,
maybe we should try and make libxatracker.so autodetect
which driver to use so we don't have to create a libxatracker.so
for each driver, at least for linux that should be do-able.
Thoughts?

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

Re: [Mesa-dev] Proposal for an Updated Linux OpenGL ABI, again

[Jakob Bornecrantz]

On Thu, Apr 25, 2013 at 9:59 PM, Andy Ritger arit...@nvidia.com wrote:

 On Thu, Apr 25, 2013 at 05:34:11AM -0700, Ian Romanick wrote:
  On 04/25/2013 11:12 AM, Andy Ritger wrote:
   Hi all,
  
   Last fall, I put together a proposal for an updated Linux OpenGL ABI
   specification:
  
  
 https://github.com/aritger/linux-opengl-abi-proposal/blob/master/linux-opengl-abi-proposal.txt
  
   but then got distracted.  I'd like to try to resurrect the discussion.
  
From the earlier email thread and some discussion at XDC2012, it
 sounded
   like people thought the general ideas were reasonable.  However, there
 are
   a variety of details to work through, called out in the issues section.
  
   To get things moving, I thought I, and a few others from NVIDIA, would
   try to prototype some of the vendor-neutral API Libraries described in
 the
   document.  That might give us all something more concrete to play with.
  
   Feedback on anything in the full proposal welcome, but here are a few
   more specific questions:
  
   * For a prototype, what is a reasonable version of OpenGL to provide
  in libOpenGL.so.1?  There are a variety of options enumerated in the
  full proposal for how to handle sets of entry points, but my sense
 is
  that the simplest solution is for libOpenGL.so.1 to provide a
 reasonable
  base version of OpenGL, and then all entry points for extensions and
  later OpenGL versions to be accessed through
 {egl,glX}GetProcAddress.
 
  If it's just the availability of the entry points (w/o using
  GetProcAddress), I don't see any reason to include less than 4.3 + every
  ARB extension.

 Thanks, Ian.

 Yes, this is just about the availability of entry points as symbols in
 the DSO.  It sounds good to me to cast a wide net and export a large
 set of symbols.

 Do you have a vision for any upgrade of that set of symbols?  My hope
 is that libOpenGL.so.1 will be maintained/distributed independently of
 any specific vendor's OpenGL implementation.  Maybe in an ideal world
 it would get revved everytime Khronos releases a new OpenGL version,
 or a new ARB extension is ratified.  But, then we need to worry about
 (a) someone keeping it up to date, and (b) handling the version number
 in libOpenGL.so's SONAME, so that an application can express which
 symbols it expects the DSO to provide.

 Given tools like GLEW, it may be easier for applications to just assume
 whatever fixed list we lock down initially for the new ABI, and then
 use GetProcAddress for everything else.

 I don't think we need to decide, yet, how frequently to update the
 exported symbol list from libOpenGL.so.  But, it is probably worthing
 thinking about, if we define in the ABI that libOpenGL.so will export
 symbols for 4.3 + every ARB extension, as of April 25, 2013.

   * From some initial reading, Mesa's glapi (src/mapi/glapi/) looks
 useful
  for the basis of libOpenGL.so.1's dispatching.  Would it be
 reasonable
  to use glapi in the prototype libOpenGL.so.1?
 
  Yes.
 
   * The vendor-neutral libEGL.so.1 is intended to be a thin layer that
  would dispatch to the appropriate vendor.  It looks like the
 frontend of
  Mesa's EGL implementation would be a good basis for the
 vendor-neutral
  libEGL.so.1.  Would it be reasonable to use that for the prototype?
 
  Yes.  There is already mechanism to control which backend gets
  dispatched within libEGL.so.  It shouldn't be too hard to make it
  discover additional .so files containing additional backends.  Kristian
  may have some ideas about how to do that.

 Sounds good.


The libEGL.so code in Mesa might not be exactly what you are looking for,
the current dispatching is more like mesas internal driver dispatching then
libGL.so straight up dispatching, as it validates some of the inputs, it
also
assumes a bit about the layout of certain structs and as such requires you
write the driver against the is not opaque that interface is not ABI stable
either. So think you will have to write the dispatching part from scratch to
make it more just directly dispatch into the driver like libGL does.

You can probably reuse some of the per thread state code from there tho
since that needs to be in the libEGL implementation. I'm also uncertain
about the loader code but it might be worth a look.

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

Re: [Mesa-dev] [PATCH 2/2] gallium: add texture update hook to screen

[Jakob Bornecrantz]

On Tue, Mar 19, 2013 at 5:40 AM, Dave Airlie airl...@gmail.com wrote:
 From: Dave Airlie airl...@redhat.com

 We have cases on virtual GPU hw that renders using a wrapped llvmpipe,
 that we can't produce the normal DRI2 semantics having the kernel/hw
 enforce synchronisation semantics. It is also suboptimal to flush
 all surfaces on the server side in the block handler. So there is
 already a dri/st hook to update the texture, so create a screen interface
 and call into it for the texture resource. The sw driver can then
 call into the displaytarget wrapper which will call into the outer
 wrapper driver to actually cause the flush to happen.

 This contains the llvmpipe and wrapper sw changes.

 Signed-off-by: Dave Airlie airl...@redhat.com

Errr, what about using flush_frontbuffer, it seems todo
the exact same thing.

Cheers, Jakob.

 ---
  src/gallium/drivers/llvmpipe/lp_texture.c | 13 +
  src/gallium/drivers/softpipe/sp_texture.h |  2 +-
  src/gallium/include/pipe/p_screen.h   |  3 +++
  src/gallium/include/state_tracker/sw_winsys.h |  6 ++
  src/gallium/state_trackers/dri/drm/dri2.c |  5 -
  src/gallium/winsys/sw/wrapper/wrapper_sw_winsys.c | 11 +++
  6 files changed, 38 insertions(+), 2 deletions(-)

 diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c 
 b/src/gallium/drivers/llvmpipe/lp_texture.c
 index f923292..48242d5 100644
 --- a/src/gallium/drivers/llvmpipe/lp_texture.c
 +++ b/src/gallium/drivers/llvmpipe/lp_texture.c
 @@ -1375,6 +1375,18 @@ llvmpipe_print_resources(void)
  }
  #endif

 +static void
 +llvmpipe_texture_update(struct pipe_screen *pscreen,
 +struct pipe_resource *pt)
 +{
 +   struct llvmpipe_screen *screen = llvmpipe_screen(pscreen);
 +   struct llvmpipe_resource *lpr = llvmpipe_resource(pt);
 +   struct sw_winsys *winsys = screen-winsys;
 +   if (!lpr-dt)
 +  return;
 +
 +   winsys-displaytarget_update(winsys, lpr-dt);
 +}

  void
  llvmpipe_init_screen_resource_funcs(struct pipe_screen *screen)
 @@ -1396,6 +1408,7 @@ llvmpipe_init_screen_resource_funcs(struct pipe_screen 
 *screen)
 screen-resource_from_handle = llvmpipe_resource_from_handle;
 screen-resource_get_handle = llvmpipe_resource_get_handle;
 screen-can_create_resource = llvmpipe_can_create_resource;
 +   screen-texture_update = llvmpipe_texture_update;
  }


 diff --git a/src/gallium/drivers/softpipe/sp_texture.h 
 b/src/gallium/drivers/softpipe/sp_texture.h
 index 533d625..04c6eaf 100644
 --- a/src/gallium/drivers/softpipe/sp_texture.h
 +++ b/src/gallium/drivers/softpipe/sp_texture.h
 @@ -46,7 +46,7 @@ struct softpipe_resource
 struct pipe_resource base;

 unsigned long level_offset[SP_MAX_TEXTURE_2D_LEVELS];
 -   unsigned stride[SP_MAX_TEXTURE_2D_LEVELS];
 +   int stride[SP_MAX_TEXTURE_2D_LEVELS];

Unrelated change...

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

Re: [Mesa-dev] [PATCH 2/2] gallium: add texture update hook to screen

[Jakob Bornecrantz]

On Tue, Mar 19, 2013 at 8:29 AM, Dave Airlie airl...@gmail.com wrote:
 Errr, what about using flush_frontbuffer, it seems todo
 the exact same thing.

 Hmm I wonder if I could overload it actually I hadn't considered that,
 its not exactly the same thing,
 but its pretty close to what I'd want to do alright.

It was used on windows to call the magical present ioctl,
its also used by llvm to flush pixels from the tile cache to the linear
displaytarget store, or at least it used to, not so sure now.

The void* backend thingy is a remnant from the windows days.

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

Re: [Mesa-dev] [PATCH 08/18] build: Move src/mapi/mapi/* to src/mapi/

[Jakob Bornecrantz]

On Mon, Mar 11, 2013 at 4:24 AM, Matt Turner matts...@gmail.com wrote:
 s,mapi/mapi,mapi,g

This is a bit of a silly request, but mesa really sucks with tab completion,
getting to anything g* in src is a PITA, it would be really nice if at least
could fix the m* overload, by just calling the folder api, or something.

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

Re: [Mesa-dev] [PATCH v2 2/5] dri: Add another duplicateImage to DRIimageExtension which allows you to create a sRGB view of a DRI image

[Jakob Bornecrantz]

On Sun, Mar 3, 2013 at 7:03 AM, John Kåre Alsaker
john.kare.alsa...@gmail.com wrote:
 duplicateImage will allow you to create a linear or sRGB view into a DRIimage 
 you have access to.
 This is useful because compositors may want a specific view which doesn't 
 correspond to the one used by applications.
 ---
  include/GL/internal/dri_interface.h | 21 -
  1 file changed, 20 insertions(+), 1 deletion(-)

 diff --git a/include/GL/internal/dri_interface.h 
 b/include/GL/internal/dri_interface.h
 index 42147e9..f4948a8 100644
 --- a/include/GL/internal/dri_interface.h
 +++ b/include/GL/internal/dri_interface.h
 @@ -938,7 +938,7 @@ struct __DRIdri2ExtensionRec {
   * extensions.
   */
  #define __DRI_IMAGE DRI_IMAGE
 -#define __DRI_IMAGE_VERSION 6
 +#define __DRI_IMAGE_VERSION 7

  /**
   * These formats correspond to the similarly named MESA_FORMAT_*
 @@ -1009,6 +1009,15 @@ struct __DRIdri2ExtensionRec {
  #define __DRI_IMAGE_COMPONENTS_Y_UV0x3004
  #define __DRI_IMAGE_COMPONENTS_Y_XUXV  0x3005

 +/**
 + * Flags for duplicateImage.
 + *
 + * \since 7
 + */
 +
 +#define __DRI_IMAGE_FLAG_SRGB_VIEW 0x0001
 +#define __DRI_IMAGE_FLAG_LINEAR_VIEW   0x0002
 +

These really should just be another set of formats, since that is
how they are handled gallium anyways.

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

Re: [Mesa-dev] [PATCH v2 3/5] gallium: Implement DRIimageExtension.duplicateImage

[Jakob Bornecrantz]

On Sun, Mar 3, 2013 at 7:03 AM, John Kåre Alsaker
john.kare.alsa...@gmail.com wrote:
 ---
  src/gallium/include/state_tracker/st_api.h |  1 +
  src/gallium/state_trackers/dri/common/dri_screen.c |  1 +
  src/gallium/state_trackers/dri/common/dri_screen.h |  1 +
  src/gallium/state_trackers/dri/drm/dri2.c  | 39 
 +-
  src/mesa/state_tracker/st_manager.c|  4 +++
  5 files changed, 45 insertions(+), 1 deletion(-)

 diff --git a/src/gallium/include/state_tracker/st_api.h 
 b/src/gallium/include/state_tracker/st_api.h
 index 9f3d2a1..1e63ed3 100644
 --- a/src/gallium/include/state_tracker/st_api.h
 +++ b/src/gallium/include/state_tracker/st_api.h
 @@ -203,6 +203,7 @@ struct st_egl_image
  {
 /* this is owned by the caller */
 struct pipe_resource *texture;
 +   enum pipe_format format;

 unsigned level;
 unsigned layer;
 diff --git a/src/gallium/state_trackers/dri/common/dri_screen.c 
 b/src/gallium/state_trackers/dri/common/dri_screen.c
 index a908e28..92abaf9 100644
 --- a/src/gallium/state_trackers/dri/common/dri_screen.c
 +++ b/src/gallium/state_trackers/dri/common/dri_screen.c
 @@ -315,6 +315,7 @@ dri_get_egl_image(struct st_manager *smapi,

 stimg-texture = NULL;
 pipe_resource_reference(stimg-texture, img-texture);
 +   stimg-format = img-format;
 stimg-level = img-level;
 stimg-layer = img-layer;

 diff --git a/src/gallium/state_trackers/dri/common/dri_screen.h 
 b/src/gallium/state_trackers/dri/common/dri_screen.h
 index 181b22f..d37c393 100644
 --- a/src/gallium/state_trackers/dri/common/dri_screen.h
 +++ b/src/gallium/state_trackers/dri/common/dri_screen.h
 @@ -84,6 +84,7 @@ dri_screen(__DRIscreen * sPriv)

  struct __DRIimageRec {
 struct pipe_resource *texture;
 +   enum pipe_format format;
 unsigned level;
 unsigned layer;
 uint32_t dri_format;
 diff --git a/src/gallium/state_trackers/dri/drm/dri2.c 
 b/src/gallium/state_trackers/dri/drm/dri2.c
 index f8d311c..54339fe 100644
 --- a/src/gallium/state_trackers/dri/drm/dri2.c
 +++ b/src/gallium/state_trackers/dri/drm/dri2.c
 @@ -658,6 +658,7 @@ dri2_dup_image(__DRIimage *image, void *loaderPrivate)
 pipe_resource_reference(img-texture, image-texture);
 img-level = image-level;
 img-layer = image-layer;
 +   img-format = image-format;
 /* This should be 0 for sub images, but dup is also used for base images. 
 */
 img-dri_components = image-dri_components;
 img-loader_private = loaderPrivate;
 @@ -749,6 +750,40 @@ dri2_from_planar(__DRIimage *image, int plane, void 
 *loaderPrivate)
 return img;
  }

 +static __DRIimage *
 +dri2_duplicate_image(__DRIscreen *_screen, __DRIimage *image,
 + unsigned int flags, void *loaderPrivate)
 +{
 +   enum pipe_format format;
 +   struct dri_screen *screen = dri_screen(_screen);
 +   __DRIimage *img = NULL;
 +
 +   if((flags  __DRI_IMAGE_FLAG_SRGB_VIEW)  (flags  
 __DRI_IMAGE_FLAG_LINEAR_VIEW))
 +  return NULL;
 +
 +   if(flags  (__DRI_IMAGE_FLAG_SRGB_VIEW | __DRI_IMAGE_FLAG_LINEAR_VIEW)) {
 +  if(!image-texture)
 + return NULL;
 +
 +  if(flags  __DRI_IMAGE_FLAG_SRGB_VIEW)
 + format = util_format_srgb(image-texture-format);
 +  else
 + format = util_format_linear(image-texture-format);
 +
 +  if(!screen-base.screen-is_format_supported(screen-base.screen, 
 format, PIPE_TEXTURE_2D, 0, PIPE_BIND_SAMPLER_VIEW))
 + return NULL;
 +
 +  img = dri2_dup_image(image, loaderPrivate);
 +
 +  if (img)
 + img-format = format;
 +   } else if (flags == 0) {
 +  img = dri2_dup_image(image, loaderPrivate);
 +   }
 +
 +   return img;
 +}
 +
  static void
  dri2_destroy_image(__DRIimage *img)
  {
 @@ -757,7 +792,7 @@ dri2_destroy_image(__DRIimage *img)
  }

  static struct __DRIimageExtensionRec dri2ImageExtension = {
 -{ __DRI_IMAGE, 5 },
 +{ __DRI_IMAGE, 7 },
  dri2_create_image_from_name,
  dri2_create_image_from_renderbuffer,
  dri2_destroy_image,
 @@ -767,6 +802,8 @@ static struct __DRIimageExtensionRec dri2ImageExtension = 
 {
  dri2_validate_usage,
  dri2_from_names,
  dri2_from_planar,
 +NULL,
 +dri2_duplicate_image,
  };

  /*
 diff --git a/src/mesa/state_tracker/st_manager.c 
 b/src/mesa/state_tracker/st_manager.c
 index a3a6771..3659499 100644
 --- a/src/mesa/state_tracker/st_manager.c
 +++ b/src/mesa/state_tracker/st_manager.c
 @@ -810,6 +810,10 @@ st_manager_get_egl_image_surface(struct st_context *st, 
 void *eglimg)
return NULL;

 u_surface_default_template(surf_tmpl, stimg.texture);
 +
 +   if(stimg.format != PIPE_FORMAT_NONE)
 +  surf_tmpl.format = stimg.format;
 +

Have you tested if this actually works? I would guess it would
render in the right colorspace but for sampling the state tracker
might just drop the format on the floor.

Cheers, Jakob.
___
mesa-dev mailing list

Re: [Mesa-dev] [RFC] New EGL extension: EGL_EXT_platform_display

[Jakob Bornecrantz]

[SNIP]

 Hi,

 is it possible to build a binary, that will use this extension if it is
 present in whatever libEGL is available at runtime, and if it is not,
 fall back gracefully to using the core eglGetDisplay()?

 Or is this specifically not supported, since I cannot see a way for
 runtime detection of this extension?

 Or is the runtime detection left unspecified, so one could do it with
 e.g. getting eglGetPlatformDisplay via dlsym()?

 Just a question that popped in my mind, since there were no comments
 toward that topic.

 Thanks for asking this question. I neglected to address the topic of runtime
 detection, despite it coming it up in face-to-face conversation multiple 
 times.

 The function must be exposed with eglGetProcAddress, and must not be
 exported via dlsym.

 libEGL is not allowed to export new symbols until the EGL specification
 version is bumped. Exporting new symbols would prevent an applications
 compiled against one vendor's libEGL to load with another vendor's libEGL.

I assume that Mesa does not follow this rule?


 In architectures like Android, where the system provides the libEGL to which
 yhe application links and the vendor supplies an EGL driver that the system 
 libEGL
 dlopens, exporting the symbol via dlsym would not expose the function
 to applications. The applications' only method for obtaining vendor-provided
 functions is via eglGetProcAddress.

I don't see this as driver extension and something that would need to be
implemented by the libEGL provider, since the selected platform might have
different set of drivers associated with them.


 Or is this [runtime detection] specifically not supported, since I cannot
 see a way for runtime detection of this extension?

 Since the function must be exposed by eglGetProcAddress, runtime detection
 will be supported. But... it's not obvious how to advertise the extension.

If memory serves me correct getProc can not return null for any string starting
with egl/gl/vg.


 I think the cleanest method by which applications could detect the extension
 is to first to connect to EGL_DEFAULT_DISPLAY; inspect the extension string;
 and, if the extension is available, then all with eglGetPlatformDisplay;
 otherwise, fallback to eglGetDisplay if possible.  The situation isn't ideal
 because it involves an initial roundtrip to the default platform's display
 server, but it's the best solution that I can think of.

That might include setting up a connection to a X server which is quite a
heavy handed thing to do. Less then optimal, also the extension might not
be supported by the loaded driver for the default platform but supported
by other drivers for other platforms.

Just throwing crazy ideas out there, maybe we should just call the function
xeglGetPlatformDisplay allowing implementation to return null if not
supported and as such being able to detection with eglGetProcAddress.

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

Re: [Mesa-dev] [PATCH] targets/xorg-i915: Rename driver to i915_drv.so.

[Jakob Bornecrantz]

Looks good.

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

[Mesa-dev] [PATCH 1/2] dri: Rework planar image interface v2

[Jakob Bornecrantz]

As discussed with Kristian on #wayland. Pushes the decision of components
into the dri driver giving it greater freedom to allow t to implement YUV
samplers in hardware, and which mode to use.

This interface will also allow drivers like SVGA to implement YUV surfaces
without the need to sub-allocate and instead send 3 seperate buffers
for each channel, currently not implemented.

This is only the dri interface and gallium dri state tracker parts of the
changes needed to make this change work, I haven't done the intel parts
of them and I'll do these tomorrow or monday, I wanted to get the dri-
interface changes out as fast as possible for review.

I have tested these changes on SVGA with the previus patch series I sent
out (mines the last one), and everything seem to work just as before.

Cheers, Jakob.

v2: Fix typo in dri2_from_planar.

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 include/GL/internal/dri_interface.h|   67 +-
 src/egl/drivers/dri2/egl_dri2.c|  128 ++--
 src/gallium/state_trackers/dri/common/dri_screen.h |1 +
 src/gallium/state_trackers/dri/drm/dri2.c  |   82 -
 src/gbm/backends/dri/gbm_dri.c |   33 ++---
 5 files changed, 196 insertions(+), 115 deletions(-)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index 09f63ff..1e0f1d0 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -923,6 +923,10 @@ struct __DRIdri2ExtensionRec {
  * __DRI_IMAGE_FORMAT_NONE is for images that aren't directly usable
  * by the driver (YUV planar formats) but serve as a base image for
  * creating sub-images for the different planes within the image.
+ *
+ * R8, GR88 and NONE should not be used with createImageFormName or
+ * createImage, and are returned by query from sub images created with
+ * createImageFromNames (NONE, see above) and fromPlane (R8  GR88).
  */
 #define __DRI_IMAGE_FORMAT_RGB565   0x1001
 #define __DRI_IMAGE_FORMAT_XRGB 0x1002
@@ -937,6 +941,49 @@ struct __DRIdri2ExtensionRec {
 #define __DRI_IMAGE_USE_SCANOUT0x0002
 #define __DRI_IMAGE_USE_CURSOR 0x0004 /* Depricated */
 
+
+/**
+ * Four CC formats that matches with WL_DRM_FORMAT_* from wayland_drm.h
+ * and GBM_FORMAT_* from gbm.h, used with createImageFromNames.
+ *
+ * \since 5
+ */
+
+#define __DRI_IMAGE_FOURCC_RGB565  0x36314752
+#define __DRI_IMAGE_FOURCC_ARGB0x34325241
+#define __DRI_IMAGE_FOURCC_XRGB0x34325258
+#define __DRI_IMAGE_FOURCC_ABGR0x34324241
+#define __DRI_IMAGE_FOURCC_XBGR0x34324258
+#define __DRI_IMAGE_FOURCC_YUV410  0x39565559
+#define __DRI_IMAGE_FOURCC_YUV411  0x31315559
+#define __DRI_IMAGE_FOURCC_YUV420  0x32315559
+#define __DRI_IMAGE_FOURCC_YUV422  0x36315559
+#define __DRI_IMAGE_FOURCC_YUV444  0x34325559
+#define __DRI_IMAGE_FOURCC_NV120x3231564e
+#define __DRI_IMAGE_FOURCC_NV160x3631564e
+#define __DRI_IMAGE_FOURCC_YUYV0x56595559
+
+
+/**
+ * Queryable on images created by createImageFromNames.
+ *
+ * RGB and RGBA are may be usable directly as images but its still
+ * recommended to call fromPlanar with plane == 0.
+ *
+ * Y_U_V, Y_UV and Y_XUXV all requires call to fromPlanar to create
+ * usable sub-images, sampling from images return raw YUV data and
+ * color conversion needs to be done in the shader.
+ *
+ * \since 5
+ */
+
+#define __DRI_IMAGE_COMPONENTS_RGB 0x3001
+#define __DRI_IMAGE_COMPONENTS_RGBA0x3002
+#define __DRI_IMAGE_COMPONENTS_Y_U_V   0x3003
+#define __DRI_IMAGE_COMPONENTS_Y_UV0x3004
+#define __DRI_IMAGE_COMPONENTS_Y_XUXV  0x3005
+
+
 /**
  * queryImage attributes
  */
@@ -947,6 +994,7 @@ struct __DRIdri2ExtensionRec {
 #define __DRI_IMAGE_ATTRIB_FORMAT  0x2003 /* available in versions 3+ */
 #define __DRI_IMAGE_ATTRIB_WIDTH   0x2004 /* available in versions 4+ */
 #define __DRI_IMAGE_ATTRIB_HEIGHT  0x2005
+#define __DRI_IMAGE_ATTRIB_COMPONENTS  0x2006 /* available in versions 5+ */
 
 typedef struct __DRIimageRec  __DRIimage;
 typedef struct __DRIimageExtensionRec __DRIimageExtension;
@@ -984,6 +1032,19 @@ struct __DRIimageExtensionRec {
GLboolean (*validateUsage)(__DRIimage *image, unsigned int use);
 
/**
+* Unlike createImageFromName __DRI_IMAGE_FORMAT is not but instead
+* __DRI_IMAGE_FOURCC and strides are in bytes not pixels. Stride is
+* also per block and not per pixel (for non-RGB, see gallium blocks).
+*
+* \since 5
+*/
+   __DRIimage *(*createImageFromNames)(__DRIscreen *screen,
+   int width, int height, int fourcc,
+   int *names, int num_names,
+   int *strides, int *offsets,
+   void *loaderPrivate);
+
+   /**
 * Create an image out

[Mesa-dev] [PATCH 2/2] intel: Support new dri image interface

[Jakob Bornecrantz]

Follow up to the previous patch, kept seperate for easier viewing,
will be merged with previous patch before commiting.

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 src/mesa/drivers/dri/intel/intel_regions.h |   26 ++
 src/mesa/drivers/dri/intel/intel_screen.c  |  125 ++--
 2 files changed, 146 insertions(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_regions.h 
b/src/mesa/drivers/dri/intel/intel_regions.h
index 4ff0efe..c0fdc95 100644
--- a/src/mesa/drivers/dri/intel/intel_regions.h
+++ b/src/mesa/drivers/dri/intel/intel_regions.h
@@ -141,12 +141,38 @@ uint32_t
 intel_region_get_aligned_offset(struct intel_region *region, uint32_t x,
 uint32_t y);
 
+/**
+ * Used with images created with image_from_names
+ * to help support planar images.
+ */
+typedef struct intel_image_format {
+   int fourcc;
+   int components;
+   int nplanes;
+   struct {
+  int buffer_index;
+  int width_shift;
+  int height_shift;
+  uint32_t dri_format;
+  int cpp;
+   } planes[3];
+} intel_image_format_t;
+
 struct __DRIimageRec {
struct intel_region *region;
GLenum internal_format;
uint32_t dri_format;
GLuint format;
uint32_t offset;
+
+   /*
+* Need to save these here between calls to
+* image_from_names and calls to image_from_planar.
+*/
+   uint32_t strides[3];
+   uint32_t offsets[3];
+   struct intel_image_format *planar_format;
+
void *data;
 };
 
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c 
b/src/mesa/drivers/dri/intel/intel_screen.c
index 55cebac..a788f3e 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -190,6 +190,59 @@ static const struct __DRI2flushExtensionRec 
intelFlushExtension = {
 dri2InvalidateDrawable,
 };
 
+intel_image_format_t intel_image_formats[] = {
+   { __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
+
+   { __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
+
+   { __DRI_IMAGE_FOURCC_YUV410, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
+   { 1, 2, 2, __DRI_IMAGE_FORMAT_R8, 1 },
+   { 2, 2, 2, __DRI_IMAGE_FORMAT_R8, 1 } } },
+
+   { __DRI_IMAGE_FOURCC_YUV411, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
+   { 1, 2, 0, __DRI_IMAGE_FORMAT_R8, 1 },
+   { 2, 2, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
+
+   { __DRI_IMAGE_FOURCC_YUV420, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
+   { 1, 1, 1, __DRI_IMAGE_FORMAT_R8, 1 },
+   { 2, 1, 1, __DRI_IMAGE_FORMAT_R8, 1 } } },
+
+   { __DRI_IMAGE_FOURCC_YUV422, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
+   { 1, 1, 0, __DRI_IMAGE_FORMAT_R8, 1 },
+   { 2, 1, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
+
+   { __DRI_IMAGE_FOURCC_YUV444, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
+   { 1, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
+   { 2, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
+
+   { __DRI_IMAGE_FOURCC_NV12, __DRI_IMAGE_COMPONENTS_Y_UV, 2,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
+   { 1, 1, 1, __DRI_IMAGE_FORMAT_GR88, 2 } } },
+
+   { __DRI_IMAGE_FOURCC_NV16, __DRI_IMAGE_COMPONENTS_Y_UV, 2,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
+   { 1, 1, 0, __DRI_IMAGE_FORMAT_GR88, 2 } } },
+
+   /* For YUYV buffers, we set up two overlapping DRI images and treat
+* them as planar buffers in the compositors.  Plane 0 is GR88 and
+* samples YU or YV pairs and places Y into the R component, while
+* plane 1 is ARGB and samples YUYV clusters and places pairs and
+* places U into the G component and V into A.  This lets the
+* texture sampler interpolate the Y components correctly when
+* sampling from plane 0, and interpolate U and V correctly when
+* sampling from plane 1. */
+   { __DRI_IMAGE_FOURCC_YUYV, __DRI_IMAGE_COMPONENTS_Y_XUXV, 2,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_GR88, 2 },
+   { 0, 1, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } }
+};
+
 static __DRIimage *
 intel_allocate_image(int dri_format, void *loaderPrivate)
 {
@@ -372,6 +425,11 @@ intel_query_image(__DRIimage *image, int attrib, int 
*value)
case __DRI_IMAGE_ATTRIB_HEIGHT:
   *value = image-region-height;
   return true;
+   case __DRI_IMAGE_ATTRIB_COMPONENTS:
+  if (image-planar_format == NULL)
+ return false;
+  *value = image-planar_format-components;
+  return true;
   default:
   return false;
}
@@ -413,16 +471,72 @@ intel_validate_usage(__DRIimage *image, unsigned int use)
 }
 
 static __DRIimage *
-intel_create_sub_image(__DRIimage *parent,
-   int width, int height, int dri_format,
-   int offset, int pitch, void *loaderPrivate

Re: [Mesa-dev] Upcoming Mesa releases

[Jakob Bornecrantz]

On Fri, Aug 24, 2012 at 2:30 PM, Jakob Bornecrantz wallbra...@gmail.com wrote:
 On Mon, Aug 20, 2012 at 6:35 PM, Ian Romanick i...@freedesktop.org wrote:
 Yeah, that is fine... I'm lagging a bit and need a few more days too.

 Me to, I have some DRI interface changes I like to get into the
 release, I'm hoping to send them out for review today but I'm not sure
 I'll get reviews/signoff on them for monday.

Ian, I sent out the last patches for testing/review. Got a RB on the main
interface changes form Kristian. And soreau (from IRC) tested it on another
Gallium driver. Just need a tested by and a review on the last intel changes
and I'm done for the 9.0 release. Thanks for waiting.

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

[Mesa-dev] [PATCH] dri: Rework planar image interface

[Jakob Bornecrantz]

As discussed with Kristian on #wayland. Pushes the decision of components
into the dri driver giving it greater freedom to allow t to implement YUV
samplers in hardware, and which mode to use.

This interface will also allow drivers like SVGA to implement YUV surfaces
without the need to sub-allocate and instead send 3 seperate buffers
for each channel, currently not implemented.

This is only the dri interface and gallium dri state tracker parts of the
changes needed to make this change work, I haven't done the intel parts
of them and I'll do these tomorrow or monday, I wanted to get the dri-
interface changes out as fast as possible for review.

I have tested these changes on SVGA with the previus patch series I sent
out (mines the last one), and everything seem to work just as before.

Cheers, Jakob.

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 include/GL/internal/dri_interface.h|   67 +-
 src/egl/drivers/dri2/egl_dri2.c|  128 ++--
 src/gallium/state_trackers/dri/common/dri_screen.h |1 +
 src/gallium/state_trackers/dri/drm/dri2.c  |   79 +++-
 src/gbm/backends/dri/gbm_dri.c |   33 ++---
 5 files changed, 193 insertions(+), 115 deletions(-)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index 09f63ff..1e0f1d0 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -923,6 +923,10 @@ struct __DRIdri2ExtensionRec {
  * __DRI_IMAGE_FORMAT_NONE is for images that aren't directly usable
  * by the driver (YUV planar formats) but serve as a base image for
  * creating sub-images for the different planes within the image.
+ *
+ * R8, GR88 and NONE should not be used with createImageFormName or
+ * createImage, and are returned by query from sub images created with
+ * createImageFromNames (NONE, see above) and fromPlane (R8  GR88).
  */
 #define __DRI_IMAGE_FORMAT_RGB565   0x1001
 #define __DRI_IMAGE_FORMAT_XRGB 0x1002
@@ -937,6 +941,49 @@ struct __DRIdri2ExtensionRec {
 #define __DRI_IMAGE_USE_SCANOUT0x0002
 #define __DRI_IMAGE_USE_CURSOR 0x0004 /* Depricated */
 
+
+/**
+ * Four CC formats that matches with WL_DRM_FORMAT_* from wayland_drm.h
+ * and GBM_FORMAT_* from gbm.h, used with createImageFromNames.
+ *
+ * \since 5
+ */
+
+#define __DRI_IMAGE_FOURCC_RGB565  0x36314752
+#define __DRI_IMAGE_FOURCC_ARGB0x34325241
+#define __DRI_IMAGE_FOURCC_XRGB0x34325258
+#define __DRI_IMAGE_FOURCC_ABGR0x34324241
+#define __DRI_IMAGE_FOURCC_XBGR0x34324258
+#define __DRI_IMAGE_FOURCC_YUV410  0x39565559
+#define __DRI_IMAGE_FOURCC_YUV411  0x31315559
+#define __DRI_IMAGE_FOURCC_YUV420  0x32315559
+#define __DRI_IMAGE_FOURCC_YUV422  0x36315559
+#define __DRI_IMAGE_FOURCC_YUV444  0x34325559
+#define __DRI_IMAGE_FOURCC_NV120x3231564e
+#define __DRI_IMAGE_FOURCC_NV160x3631564e
+#define __DRI_IMAGE_FOURCC_YUYV0x56595559
+
+
+/**
+ * Queryable on images created by createImageFromNames.
+ *
+ * RGB and RGBA are may be usable directly as images but its still
+ * recommended to call fromPlanar with plane == 0.
+ *
+ * Y_U_V, Y_UV and Y_XUXV all requires call to fromPlanar to create
+ * usable sub-images, sampling from images return raw YUV data and
+ * color conversion needs to be done in the shader.
+ *
+ * \since 5
+ */
+
+#define __DRI_IMAGE_COMPONENTS_RGB 0x3001
+#define __DRI_IMAGE_COMPONENTS_RGBA0x3002
+#define __DRI_IMAGE_COMPONENTS_Y_U_V   0x3003
+#define __DRI_IMAGE_COMPONENTS_Y_UV0x3004
+#define __DRI_IMAGE_COMPONENTS_Y_XUXV  0x3005
+
+
 /**
  * queryImage attributes
  */
@@ -947,6 +994,7 @@ struct __DRIdri2ExtensionRec {
 #define __DRI_IMAGE_ATTRIB_FORMAT  0x2003 /* available in versions 3+ */
 #define __DRI_IMAGE_ATTRIB_WIDTH   0x2004 /* available in versions 4+ */
 #define __DRI_IMAGE_ATTRIB_HEIGHT  0x2005
+#define __DRI_IMAGE_ATTRIB_COMPONENTS  0x2006 /* available in versions 5+ */
 
 typedef struct __DRIimageRec  __DRIimage;
 typedef struct __DRIimageExtensionRec __DRIimageExtension;
@@ -984,6 +1032,19 @@ struct __DRIimageExtensionRec {
GLboolean (*validateUsage)(__DRIimage *image, unsigned int use);
 
/**
+* Unlike createImageFromName __DRI_IMAGE_FORMAT is not but instead
+* __DRI_IMAGE_FOURCC and strides are in bytes not pixels. Stride is
+* also per block and not per pixel (for non-RGB, see gallium blocks).
+*
+* \since 5
+*/
+   __DRIimage *(*createImageFromNames)(__DRIscreen *screen,
+   int width, int height, int fourcc,
+   int *names, int num_names,
+   int *strides, int *offsets,
+   void *loaderPrivate);
+
+   /**
 * Create an image out of a sub-region of a parent image

[Mesa-dev] [PATCH] dri: Rework planar image interface v2

[Jakob Bornecrantz]

As discussed with Kristian on #wayland. Pushes the decision of components
into the dri driver giving it greater freedom to allow t to implement YUV
samplers in hardware, and which mode to use.

This interface will also allow drivers like SVGA to implement YUV surfaces
without the need to sub-allocate and instead send 3 seperate buffers
for each channel, currently not implemented.

This is only the dri interface and gallium dri state tracker parts of the
changes needed to make this change work, I haven't done the intel parts
of them and I'll do these tomorrow or monday, I wanted to get the dri-
interface changes out as fast as possible for review.

I have tested these changes on SVGA with the previus patch series I sent
out (mines the last one), and everything seem to work just as before.

Cheers, Jakob.

v2: Fix typo in dri2_from_planar.

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 include/GL/internal/dri_interface.h|   67 +-
 src/egl/drivers/dri2/egl_dri2.c|  128 ++--
 src/gallium/state_trackers/dri/common/dri_screen.h |1 +
 src/gallium/state_trackers/dri/drm/dri2.c  |   82 -
 src/gbm/backends/dri/gbm_dri.c |   33 ++---
 5 files changed, 196 insertions(+), 115 deletions(-)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index 09f63ff..1e0f1d0 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -923,6 +923,10 @@ struct __DRIdri2ExtensionRec {
  * __DRI_IMAGE_FORMAT_NONE is for images that aren't directly usable
  * by the driver (YUV planar formats) but serve as a base image for
  * creating sub-images for the different planes within the image.
+ *
+ * R8, GR88 and NONE should not be used with createImageFormName or
+ * createImage, and are returned by query from sub images created with
+ * createImageFromNames (NONE, see above) and fromPlane (R8  GR88).
  */
 #define __DRI_IMAGE_FORMAT_RGB565   0x1001
 #define __DRI_IMAGE_FORMAT_XRGB 0x1002
@@ -937,6 +941,49 @@ struct __DRIdri2ExtensionRec {
 #define __DRI_IMAGE_USE_SCANOUT0x0002
 #define __DRI_IMAGE_USE_CURSOR 0x0004 /* Depricated */
 
+
+/**
+ * Four CC formats that matches with WL_DRM_FORMAT_* from wayland_drm.h
+ * and GBM_FORMAT_* from gbm.h, used with createImageFromNames.
+ *
+ * \since 5
+ */
+
+#define __DRI_IMAGE_FOURCC_RGB565  0x36314752
+#define __DRI_IMAGE_FOURCC_ARGB0x34325241
+#define __DRI_IMAGE_FOURCC_XRGB0x34325258
+#define __DRI_IMAGE_FOURCC_ABGR0x34324241
+#define __DRI_IMAGE_FOURCC_XBGR0x34324258
+#define __DRI_IMAGE_FOURCC_YUV410  0x39565559
+#define __DRI_IMAGE_FOURCC_YUV411  0x31315559
+#define __DRI_IMAGE_FOURCC_YUV420  0x32315559
+#define __DRI_IMAGE_FOURCC_YUV422  0x36315559
+#define __DRI_IMAGE_FOURCC_YUV444  0x34325559
+#define __DRI_IMAGE_FOURCC_NV120x3231564e
+#define __DRI_IMAGE_FOURCC_NV160x3631564e
+#define __DRI_IMAGE_FOURCC_YUYV0x56595559
+
+
+/**
+ * Queryable on images created by createImageFromNames.
+ *
+ * RGB and RGBA are may be usable directly as images but its still
+ * recommended to call fromPlanar with plane == 0.
+ *
+ * Y_U_V, Y_UV and Y_XUXV all requires call to fromPlanar to create
+ * usable sub-images, sampling from images return raw YUV data and
+ * color conversion needs to be done in the shader.
+ *
+ * \since 5
+ */
+
+#define __DRI_IMAGE_COMPONENTS_RGB 0x3001
+#define __DRI_IMAGE_COMPONENTS_RGBA0x3002
+#define __DRI_IMAGE_COMPONENTS_Y_U_V   0x3003
+#define __DRI_IMAGE_COMPONENTS_Y_UV0x3004
+#define __DRI_IMAGE_COMPONENTS_Y_XUXV  0x3005
+
+
 /**
  * queryImage attributes
  */
@@ -947,6 +994,7 @@ struct __DRIdri2ExtensionRec {
 #define __DRI_IMAGE_ATTRIB_FORMAT  0x2003 /* available in versions 3+ */
 #define __DRI_IMAGE_ATTRIB_WIDTH   0x2004 /* available in versions 4+ */
 #define __DRI_IMAGE_ATTRIB_HEIGHT  0x2005
+#define __DRI_IMAGE_ATTRIB_COMPONENTS  0x2006 /* available in versions 5+ */
 
 typedef struct __DRIimageRec  __DRIimage;
 typedef struct __DRIimageExtensionRec __DRIimageExtension;
@@ -984,6 +1032,19 @@ struct __DRIimageExtensionRec {
GLboolean (*validateUsage)(__DRIimage *image, unsigned int use);
 
/**
+* Unlike createImageFromName __DRI_IMAGE_FORMAT is not but instead
+* __DRI_IMAGE_FOURCC and strides are in bytes not pixels. Stride is
+* also per block and not per pixel (for non-RGB, see gallium blocks).
+*
+* \since 5
+*/
+   __DRIimage *(*createImageFromNames)(__DRIscreen *screen,
+   int width, int height, int fourcc,
+   int *names, int num_names,
+   int *strides, int *offsets,
+   void *loaderPrivate);
+
+   /**
 * Create an image out

Re: [Mesa-dev] Upcoming Mesa releases

[Jakob Bornecrantz]

On Mon, Aug 20, 2012 at 6:35 PM, Ian Romanick i...@freedesktop.org wrote:
 On 08/20/2012 07:26 AM, Marek Olšák wrote:

 On Fri, Aug 10, 2012 at 4:01 AM, Ian Romanick i...@freedesktop.org wrote:

 After the big announcement at SIGGRAPH, I want to discuss plans for
 upcoming
 Mesa releases.  This is basically inline with what we discussed a few
 months
 ago, but there are a couple changes.  I know a lot of people have been
 doing
 a lot of work all across the graphics stack, so I want to make sure that
 all
 of the work that's almost ready to land has a chance.

 I mostly want to know if the plans for the next couple months work for
 people.  Anything beyond that is just my best guess of how things will
 go.

 8/17: Release Mesa 8.0.5.  I'll send out another pick-list on Friday or
 Saturday, and pick things over on Monday or Tuesday.

 8/20: Make a Mesa 9.0 stablization branch.  It looks like the few
 dangling
 bits of OpenGL 3.1 will get wrapped up pretty quick.  I'm confident that
 we
 can at least enable 3.1 on the hardware where we currently enable 3.0.


 I'd like to finish MSAA support for more R600 chipsets for Mesa 9.0
 (we only support Evergreen at the moment), but I will need a couple
 more days. Could we please postpone making the 9.0 branch until 8/27?
 If not, I'd like to cherry-pick my not-yet-published MSAA work to the
 9.0 branch once it's working.


 Yeah, that is fine... I'm lagging a bit and need a few more days too.

Me to, I have some DRI interface changes I like to get into the
release, I'm hoping to send them out for review today but I'm not sure
I'll get reviews/signoff on them for monday.

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

[Mesa-dev] [PATCH 0/6] Gallium Wayland support

[Jakob Bornecrantz]

This should be the final version of these patches (the last one will not be
pushed as I'm currently working on replacing the interaces it works around).

The libkms patch now completely replaces the cursor implementation with libkms
and the patch following it removes DRI image write completely. I reworked the
interface versioning so that the WIDTH and HEIGHT tokens are now version 4.

I added support for DRI Image version 2-4, while support for the validate usage
is hacked, it allows my to advertise 3 and 4 without gdm crashing.

Cheers, Jakob.

Jakob Bornecrantz (6):
  gbm: Use libkms to replace DRI cursor images
  dri: Remove image write function
  dri: Make query image WIDTH and HEIGHT be version 4
  st/dri: Claim to support validate_usage
  st/dri: Support width and height getters
  egl_dri2: Avoid using createSubImage when not neccassery

 configure.ac   |2 +
 include/GL/internal/dri_interface.h|   12 +
 src/egl/drivers/dri2/Makefile.am   |1 +
 src/egl/drivers/dri2/egl_dri2.c|   22 +---
 src/gallium/state_trackers/dri/drm/dri2.c  |   23 +++-
 src/gbm/Makefile.am|3 +-
 src/gbm/backends/dri/gbm_dri.c |   81 ++--
 src/gbm/backends/dri/gbm_driint.h  |8 +++
 src/mesa/drivers/dri/intel/intel_regions.h |1 -
 src/mesa/drivers/dri/intel/intel_screen.c  |   28 --
 10 files changed, 117 insertions(+), 64 deletions(-)

-- 
1.7.9.5

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

[Mesa-dev] [PATCH 1/6] gbm: Use libkms to replace DRI cursor images

[Jakob Bornecrantz]

Uses libkms instead of dri image cursor. Since this is the only user of the DRI
cursor and the write interface we can remove cursor surfaces entirely from the
DRI interface and as a consequence also from the Gallium interface as well. Tho
to make everybody happy with this it would probably should add a kms_bo_write
function, but that is probably wise in anyways.

The only downside is that it adds a dependancy on libkms, this could however be
replaced with the dumb_bo drm ioctl interface.

Tested-by: Scott Moreau ore...@gmail.com
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 configure.ac  |2 ++
 src/egl/drivers/dri2/Makefile.am  |1 +
 src/gbm/Makefile.am   |3 +-
 src/gbm/backends/dri/gbm_dri.c|   65 ++---
 src/gbm/backends/dri/gbm_driint.h |8 +
 5 files changed, 67 insertions(+), 12 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7dac091..190d71f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1298,6 +1298,8 @@ if test x$enable_gbm = xyes; then
 if test $SHARED_GLAPI -eq 0; then
 AC_MSG_ERROR([gbm_dri requires --enable-shared-glapi])
 fi
+PKG_CHECK_MODULES([LIBKMS], [libkms], [],
+  AC_MSG_ERROR([gbm needs libkms]))
 fi
 fi
 GBM_PC_REQ_PRIV=libudev
diff --git a/src/egl/drivers/dri2/Makefile.am b/src/egl/drivers/dri2/Makefile.am
index 49ec06b..45f7dfa 100644
--- a/src/egl/drivers/dri2/Makefile.am
+++ b/src/egl/drivers/dri2/Makefile.am
@@ -30,6 +30,7 @@ AM_CFLAGS = \
$(DEFINES) \
$(LIBDRM_CFLAGS) \
$(LIBUDEV_CFLAGS) \
+   $(LIBKMS_CFLAGS) \
-DDEFAULT_DRIVER_DIR=\$(DRI_DRIVER_SEARCH_DIR)\
 
 noinst_LTLIBRARIES = libegl_dri2.la
diff --git a/src/gbm/Makefile.am b/src/gbm/Makefile.am
index f079da1..e22c55c 100644
--- a/src/gbm/Makefile.am
+++ b/src/gbm/Makefile.am
@@ -7,6 +7,7 @@ AM_CFLAGS = \
-I$(top_srcdir)/include \
-I$(top_srcdir)/src/gbm/main \
$(LIBUDEV_CFLAGS) \
+   $(LIBKMS_CFLAGS) \
$(DLOPEN_CFLAGS) \
$(DEFINES)
 
@@ -18,7 +19,7 @@ libgbm_la_SOURCES = \
main/backend.c \
main/common.c
 libgbm_la_LDFLAGS = -version-info 1:0
-libgbm_la_LIBADD = $(LIBUDEV_LIBS) $(DLOPEN_LIBS)
+libgbm_la_LIBADD = $(LIBUDEV_LIBS) $(LIBKMS_LIBS) $(DLOPEN_LIBS)
 
 if HAVE_EGL_PLATFORM_WAYLAND
 AM_CPPFLAGS = -DHAVE_WAYLAND_PLATFORM
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 5c332d4..47874ae 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -299,13 +299,21 @@ gbm_dri_is_format_supported(struct gbm_device *gbm,
 static int
 gbm_dri_bo_write(struct gbm_bo *_bo, const void *buf, size_t count)
 {
-   struct gbm_dri_device *dri = gbm_dri_device(_bo-gbm);
struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
+   void *ptr;
+   int ret;
+
+   if (bo-bo == NULL)
+  return -1;
 
-   if (dri-image-base.version  4)
+   ret = kms_bo_map(bo-bo, ptr);
+   if (ret  0)
   return -1;
 
-   return dri-image-write(bo-image, buf, count);
+   memcpy(ptr, buf, count);
+
+   kms_bo_unmap(bo-bo);
+   return 0;
 }
 
 static void
@@ -314,7 +322,10 @@ gbm_dri_bo_destroy(struct gbm_bo *_bo)
struct gbm_dri_device *dri = gbm_dri_device(_bo-gbm);
struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
 
-   dri-image-destroyImage(bo-image);
+   if (bo-image != NULL)
+  dri-image-destroyImage(bo-image);
+   if (bo-bo != NULL)
+  kms_bo_destroy(bo-bo);
free(bo);
 }
 
@@ -446,9 +457,6 @@ gbm_dri_bo_create(struct gbm_device *gbm,
int dri_format;
unsigned dri_use = 0;
 
-   if (dri-image-base.version  4  (usage  GBM_BO_USE_WRITE))
-  return NULL;
-
bo = calloc(1, sizeof *bo);
if (bo == NULL)
   return NULL;
@@ -457,6 +465,33 @@ gbm_dri_bo_create(struct gbm_device *gbm,
bo-base.base.width = width;
bo-base.base.height = height;
 
+   if (usage  GBM_BO_USE_WRITE) {
+  int ret;
+  unsigned attrs[7] = {
+ KMS_WIDTH, 64,
+ KMS_HEIGHT, 64,
+ KMS_BO_TYPE, KMS_BO_TYPE_SCANOUT_X8R8G8B8,
+ KMS_TERMINATE_PROP_LIST,
+  };
+
+  if (!(usage  GBM_BO_USE_CURSOR_64X64))
+ return NULL;
+
+  if (dri-kms == NULL)
+ return NULL;
+
+  ret = kms_bo_create(dri-kms, attrs, bo-bo);
+  if (ret  0) {
+ free(bo);
+ return NULL;
+  }
+
+  kms_bo_get_prop(bo-bo, KMS_PITCH, bo-base.base.stride);
+  kms_bo_get_prop(bo-bo, KMS_HANDLE, (unsigned*)bo-base.base.handle);
+
+  return bo-base.base;
+   }
+
switch (format) {
case GBM_FORMAT_RGB565:
   dri_format =__DRI_IMAGE_FORMAT_RGB565;
@@ -564,13 +599,21 @@ dri_device_create(int fd)
dri-base.type = GBM_DRM_DRIVER_TYPE_DRI;
dri-base.base.name = drm;
 
+   kms_create(fd, dri-kms);
+   if (dri-kms == NULL)
+  goto err_kms;
+
ret = dri_screen_create(dri);
-   if (ret) {
-  free(dri);
-  return NULL;
-   }
+   if (ret)
+  goto err_dri

[Mesa-dev] [PATCH 2/6] dri: Remove image write function

[Jakob Bornecrantz]

Since its not used by anything anymore and no release has gone out where it was
being used.

Tested-by: Scott Moreau ore...@gmail.com
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 include/GL/internal/dri_interface.h|   10 +-
 src/gbm/backends/dri/gbm_dri.c |2 --
 src/mesa/drivers/dri/intel/intel_regions.h |1 -
 src/mesa/drivers/dri/intel/intel_screen.c  |   28 
 4 files changed, 1 insertion(+), 40 deletions(-)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index 97e1a1a..e766226 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -935,8 +935,7 @@ struct __DRIdri2ExtensionRec {
 
 #define __DRI_IMAGE_USE_SHARE  0x0001
 #define __DRI_IMAGE_USE_SCANOUT0x0002
-#define __DRI_IMAGE_USE_CURSOR 0x0004
-#define __DRI_IMAGE_USE_WRITE  0x0008
+#define __DRI_IMAGE_USE_CURSOR 0x0004 /* Depricated */
 
 /**
  * queryImage attributes
@@ -985,13 +984,6 @@ struct __DRIimageExtensionRec {
GLboolean (*validateUsage)(__DRIimage *image, unsigned int use);
 
/**
-* Write data into image.
-*
-* \since 4
-*/
-   int (*write)(__DRIimage *image, const void *buf, size_t count);
-
-   /**
 * Create an image out of a sub-region of a parent image.  This
 * entry point lets us create individual __DRIimages for different
 * planes in a planar buffer (typically yuv), for example.  While a
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 47874ae..59a3d81 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -515,8 +515,6 @@ gbm_dri_bo_create(struct gbm_device *gbm,
   dri_use |= __DRI_IMAGE_USE_SCANOUT;
if (usage  GBM_BO_USE_CURSOR_64X64)
   dri_use |= __DRI_IMAGE_USE_CURSOR;
-   if (usage  GBM_BO_USE_WRITE)
-  dri_use |= __DRI_IMAGE_USE_WRITE;
 
/* Gallium drivers requires shared in order to get the handle/stride */
dri_use |= __DRI_IMAGE_USE_SHARE;
diff --git a/src/mesa/drivers/dri/intel/intel_regions.h 
b/src/mesa/drivers/dri/intel/intel_regions.h
index 782d669..4ff0efe 100644
--- a/src/mesa/drivers/dri/intel/intel_regions.h
+++ b/src/mesa/drivers/dri/intel/intel_regions.h
@@ -144,7 +144,6 @@ intel_region_get_aligned_offset(struct intel_region 
*region, uint32_t x,
 struct __DRIimageRec {
struct intel_region *region;
GLenum internal_format;
-   uint32_t usage;
uint32_t dri_format;
GLuint format;
uint32_t offset;
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c 
b/src/mesa/drivers/dri/intel/intel_screen.c
index f4c1602..103fcd2 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -339,13 +339,7 @@ intel_create_image(__DRIscreen *screen,
   tiling = I915_TILING_NONE;
}
 
-   /* We only support write for cursor drm images */
-   if ((use  __DRI_IMAGE_USE_WRITE) 
-   use != (__DRI_IMAGE_USE_WRITE | __DRI_IMAGE_USE_CURSOR))
-  return NULL;
-
image = intel_allocate_image(format, loaderPrivate);
-   image-usage = use;
cpp = _mesa_get_format_bytes(image-format);
image-region =
   intel_region_alloc(intelScreen, tiling, cpp, width, height, true);
@@ -399,7 +393,6 @@ intel_dup_image(__DRIimage *orig_image, void *loaderPrivate)
}
 
image-internal_format = orig_image-internal_format;
-   image-usage   = orig_image-usage;
image-dri_format  = orig_image-dri_format;
image-format  = orig_image-format;
image-offset  = orig_image-offset;
@@ -416,29 +409,9 @@ intel_validate_usage(__DRIimage *image, unsigned int use)
 return GL_FALSE;
}
 
-   /* We only support write for cursor drm images */
-   if ((use  __DRI_IMAGE_USE_WRITE) 
-   use != (__DRI_IMAGE_USE_WRITE | __DRI_IMAGE_USE_CURSOR))
-  return GL_FALSE;
-
return GL_TRUE;
 }
 
-static int
-intel_image_write(__DRIimage *image, const void *buf, size_t count)
-{
-   if (image-region-map_refcount)
-  return -1;
-   if (!(image-usage  __DRI_IMAGE_USE_WRITE))
-  return -1;
-
-   drm_intel_bo_map(image-region-bo, true);
-   memcpy(image-region-bo-virtual, buf, count);
-   drm_intel_bo_unmap(image-region-bo);
-
-   return 0;
-}
-
 static __DRIimage *
 intel_create_sub_image(__DRIimage *parent,
int width, int height, int dri_format,
@@ -490,7 +463,6 @@ static struct __DRIimageExtensionRec intelImageExtension = {
 intel_query_image,
 intel_dup_image,
 intel_validate_usage,
-intel_image_write,
 intel_create_sub_image
 };
 
-- 
1.7.9.5

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

[Mesa-dev] [PATCH 3/6] dri: Make query image WIDTH and HEIGHT be version 4

[Jakob Bornecrantz]

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 include/GL/internal/dri_interface.h |2 +-
 src/gbm/backends/dri/gbm_dri.c  |4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index e766226..09f63ff 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -945,7 +945,7 @@ struct __DRIdri2ExtensionRec {
 #define __DRI_IMAGE_ATTRIB_HANDLE  0x2001
 #define __DRI_IMAGE_ATTRIB_NAME0x2002
 #define __DRI_IMAGE_ATTRIB_FORMAT  0x2003 /* available in versions 3+ */
-#define __DRI_IMAGE_ATTRIB_WIDTH   0x2004 /* available in versions 5+ */
+#define __DRI_IMAGE_ATTRIB_WIDTH   0x2004 /* available in versions 4+ */
 #define __DRI_IMAGE_ATTRIB_HEIGHT  0x2005
 
 typedef struct __DRIimageRec  __DRIimage;
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 59a3d81..1831f13 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -365,6 +365,10 @@ gbm_dri_bo_import(struct gbm_device *gbm,
unsigned dri_use = 0;
int dri_format, width, height, gbm_format, stride, cpp, offset;
 
+   /* Required for query image WIDTH  HEIGHT */
+   if (dri-image-base.version  4)
+  return NULL;
+
switch (type) {
 #if HAVE_WAYLAND_PLATFORM
case GBM_BO_IMPORT_WL_BUFFER:
-- 
1.7.9.5

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

[Mesa-dev] [PATCH 4/6] st/dri: Claim to support validate_usage

[Jakob Bornecrantz]

Support version 3 as well as 2, since that is only the new format query,
which Jesse added support for to st/dri when he added it to dri_inteface.h.

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 src/gallium/state_trackers/dri/drm/dri2.c |   17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/dri/drm/dri2.c 
b/src/gallium/state_trackers/dri/drm/dri2.c
index 1f14b5c..5c7acfe 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -629,6 +629,20 @@ dri2_dup_image(__DRIimage *image, void *loaderPrivate)
return img;
 }
 
+static GLboolean
+dri2_validate_usage(__DRIimage *image, unsigned int use)
+{
+   /*
+* Gallium drivers are bad at adding usages to the resources
+* once opened again in another process, which is the main use
+* case for this, so we have to lie.
+*/
+   if (image != NULL)
+  return GL_TRUE;
+   else
+  return GL_FALSE;
+}
+
 static void
 dri2_destroy_image(__DRIimage *img)
 {
@@ -637,13 +651,14 @@ dri2_destroy_image(__DRIimage *img)
 }
 
 static struct __DRIimageExtensionRec dri2ImageExtension = {
-{ __DRI_IMAGE, 1 },
+{ __DRI_IMAGE, 3 },
 dri2_create_image_from_name,
 dri2_create_image_from_renderbuffer,
 dri2_destroy_image,
 dri2_create_image,
 dri2_query_image,
 dri2_dup_image,
+dri2_validate_usage,
 };
 
 /*
-- 
1.7.9.5

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

[Mesa-dev] [PATCH 5/6] st/dri: Support width and height getters

[Jakob Bornecrantz]

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 src/gallium/state_trackers/dri/drm/dri2.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/dri/drm/dri2.c 
b/src/gallium/state_trackers/dri/drm/dri2.c
index 5c7acfe..d7f4dd6 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -606,6 +606,12 @@ dri2_query_image(__DRIimage *image, int attrib, int *value)
case __DRI_IMAGE_ATTRIB_FORMAT:
   *value = image-dri_format;
   return GL_TRUE;
+   case __DRI_IMAGE_ATTRIB_WIDTH:
+  *value = image-texture-width0;
+  return GL_TRUE;
+   case __DRI_IMAGE_ATTRIB_HEIGHT:
+  *value = image-texture-height0;
+  return GL_TRUE;
default:
   return GL_FALSE;
}
@@ -651,7 +657,7 @@ dri2_destroy_image(__DRIimage *img)
 }
 
 static struct __DRIimageExtensionRec dri2ImageExtension = {
-{ __DRI_IMAGE, 3 },
+{ __DRI_IMAGE, 4 },
 dri2_create_image_from_name,
 dri2_create_image_from_renderbuffer,
 dri2_destroy_image,
-- 
1.7.9.5

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

[Mesa-dev] [PATCH 6/6] egl_dri2: Avoid using createSubImage when not neccassery

[Jakob Bornecrantz]

Makes it possible to run Wayland on Gallium drivers. This patch will not be
pushed as a interface rewrite will fix it more properly. It is here to
facilitate testing of the other patches.

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 src/egl/drivers/dri2/egl_dri2.c |   22 --
 src/gbm/backends/dri/gbm_dri.c  |   10 ++
 2 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 423d18d..d714dc9 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1197,9 +1197,13 @@ dri2_create_image_wayland_wl_buffer(_EGLDisplay *disp, 
_EGLContext *ctx,
offset = buffer-offset[index];
stride = buffer-stride[index];
 
-   dri_image = dri2_dpy-image-createSubImage(buffer-driver_buffer,
-   width, height, format,
-   offset, stride / cpp, NULL);
+   if (f-nplanes == 1) {
+  dri_image = dri2_dpy-image-dupImage(buffer-driver_buffer, NULL);
+   } else {
+  dri_image = dri2_dpy-image-createSubImage(buffer-driver_buffer,
+  width, height, format,
+  offset, stride / cpp, NULL);
+   }
 
return dri2_create_image(disp, dri_image);
 }
@@ -1360,11 +1364,17 @@ dri2_wl_reference_buffer(void *user_data, uint32_t name,
 {
_EGLDisplay *disp = user_data;
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
-   int i;
+   const struct wl_drm_format_descriptor *f;
+   int i, format = 0;
 
for (i = 0; i  ARRAY_SIZE(wl_drm_formats); i++)
   if (wl_drm_formats[i].wl_format == buffer-format) {
- buffer-driver_format = wl_drm_formats[i];
+ f = wl_drm_formats[i];
+ buffer-driver_format = f;
+ if (f-nplanes == 1)
+format = f-planes[0].dri_format;
+ else
+format = __DRI_IMAGE_FORMAT_NONE;
  break;
   }
 
@@ -1375,7 +1385,7 @@ dri2_wl_reference_buffer(void *user_data, uint32_t name,
   dri2_dpy-image-createImageFromName(dri2_dpy-dri_screen,
buffer-buffer.width,
buffer-buffer.height, 
-   __DRI_IMAGE_FORMAT_NONE, name,
+   format, name,
buffer-stride[0] / 4,
NULL);
 }
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 1831f13..59a0924 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -425,10 +425,12 @@ gbm_dri_bo_import(struct gbm_device *gbm,
dri-image-queryImage(image, __DRI_IMAGE_ATTRIB_WIDTH, width);
dri-image-queryImage(image, __DRI_IMAGE_ATTRIB_HEIGHT, height);
 
-   bo-image = dri-image-createSubImage(image,
-  width, height, dri_format,
-  offset, stride / cpp, NULL);
-
+   if (dri-image-base.version  5)
+  bo-image = dri-image-dupImage(image, NULL);
+   else
+  bo-image = dri-image-createSubImage(image,
+ width, height, dri_format,
+ offset, stride / cpp, NULL);
 
if (usage  GBM_BO_USE_SCANOUT)
   dri_use |= __DRI_IMAGE_USE_SCANOUT;
-- 
1.7.9.5

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

[Mesa-dev] [PATCH 1/6] st/dri: Support width and height getters

[Jakob Bornecrantz]

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 src/gallium/state_trackers/dri/drm/dri2.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/gallium/state_trackers/dri/drm/dri2.c 
b/src/gallium/state_trackers/dri/drm/dri2.c
index d0be710..d5a98a2 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -603,6 +603,12 @@ dri2_query_image(__DRIimage *image, int attrib, int *value)
case __DRI_IMAGE_ATTRIB_FORMAT:
   *value = image-dri_format;
   return GL_TRUE;
+   case __DRI_IMAGE_ATTRIB_WIDTH:
+  *value = image-texture-width0;
+  return GL_TRUE;
+   case __DRI_IMAGE_ATTRIB_HEIGHT:
+  *value = image-texture-height0;
+  return GL_TRUE;
default:
   return GL_FALSE;
}
-- 
1.7.9.5

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

[Mesa-dev] [PATCH 3/6] gbm: Add shared usage on images created

[Jakob Bornecrantz]

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 src/gbm/backends/dri/gbm_dri.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index f09f6ef..5c332d4 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -483,6 +483,9 @@ gbm_dri_bo_create(struct gbm_device *gbm,
if (usage  GBM_BO_USE_WRITE)
   dri_use |= __DRI_IMAGE_USE_WRITE;
 
+   /* Gallium drivers requires shared in order to get the handle/stride */
+   dri_use |= __DRI_IMAGE_USE_SHARE;
+
bo-image =
   dri-image-createImage(dri-screen,
   width, height,
-- 
1.7.9.5

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

[Mesa-dev] [PATCH 4/6] gbm: Use libkms to replace DRI cursor images

[Jakob Bornecrantz]

Uses libkms instead of dri image cursor. Since this is the only user of the
DRI cursor and write interface we can remove cursor surfaces entirely from
the DRI interface and as a consequence also from the Gallium interface as
well. Tho to make everybody happy with this it would probably should add a
kms_bo_write function, but that is probably wise in anyways.

The only downside is that it adds a dependancy on libkms, this could how ever
be replaced with the dumb_bo drm ioctl interface.

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 configure.ac  |2 ++
 src/egl/drivers/dri2/Makefile.am  |1 +
 src/gbm/Makefile.am   |3 ++-
 src/gbm/backends/dri/gbm_dri.c|   52 -
 src/gbm/backends/dri/gbm_driint.h |8 ++
 5 files changed, 59 insertions(+), 7 deletions(-)

diff --git a/configure.ac b/configure.ac
index 2ecedaf..f5836d6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1355,6 +1355,8 @@ if test x$enable_gbm = xyes; then
 if test $SHARED_GLAPI -eq 0; then
 AC_MSG_ERROR([gbm_dri requires --enable-shared-glapi])
 fi
+PKG_CHECK_MODULES([LIBKMS], [libkms], [],
+  AC_MSG_ERROR([gbm needs libkms]))
 fi
 fi
 GBM_PC_REQ_PRIV=libudev
diff --git a/src/egl/drivers/dri2/Makefile.am b/src/egl/drivers/dri2/Makefile.am
index 49ec06b..45f7dfa 100644
--- a/src/egl/drivers/dri2/Makefile.am
+++ b/src/egl/drivers/dri2/Makefile.am
@@ -30,6 +30,7 @@ AM_CFLAGS = \
$(DEFINES) \
$(LIBDRM_CFLAGS) \
$(LIBUDEV_CFLAGS) \
+   $(LIBKMS_CFLAGS) \
-DDEFAULT_DRIVER_DIR=\$(DRI_DRIVER_SEARCH_DIR)\
 
 noinst_LTLIBRARIES = libegl_dri2.la
diff --git a/src/gbm/Makefile.am b/src/gbm/Makefile.am
index f079da1..e22c55c 100644
--- a/src/gbm/Makefile.am
+++ b/src/gbm/Makefile.am
@@ -7,6 +7,7 @@ AM_CFLAGS = \
-I$(top_srcdir)/include \
-I$(top_srcdir)/src/gbm/main \
$(LIBUDEV_CFLAGS) \
+   $(LIBKMS_CFLAGS) \
$(DLOPEN_CFLAGS) \
$(DEFINES)
 
@@ -18,7 +19,7 @@ libgbm_la_SOURCES = \
main/backend.c \
main/common.c
 libgbm_la_LDFLAGS = -version-info 1:0
-libgbm_la_LIBADD = $(LIBUDEV_LIBS) $(DLOPEN_LIBS)
+libgbm_la_LIBADD = $(LIBUDEV_LIBS) $(LIBKMS_LIBS) $(DLOPEN_LIBS)
 
 if HAVE_EGL_PLATFORM_WAYLAND
 AM_CPPFLAGS = -DHAVE_WAYLAND_PLATFORM
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 5c332d4..15a7622 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -301,11 +301,20 @@ gbm_dri_bo_write(struct gbm_bo *_bo, const void *buf, 
size_t count)
 {
struct gbm_dri_device *dri = gbm_dri_device(_bo-gbm);
struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
+   void *ptr;
+   int ret;
+
+   if (bo-bo == NULL)
+  return -1;
 
-   if (dri-image-base.version  4)
+   ret = kms_bo_map(bo-bo, ptr);
+   if (ret  0)
   return -1;
 
-   return dri-image-write(bo-image, buf, count);
+   memcpy(ptr, buf, count);
+
+   kms_bo_unmap(bo-bo);
+   return 0;
 }
 
 static void
@@ -314,7 +323,10 @@ gbm_dri_bo_destroy(struct gbm_bo *_bo)
struct gbm_dri_device *dri = gbm_dri_device(_bo-gbm);
struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
 
-   dri-image-destroyImage(bo-image);
+   if (bo-image != NULL)
+  dri-image-destroyImage(bo-image);
+   if (bo-bo != NULL)
+  kms_bo_destroy(bo-bo);
free(bo);
 }
 
@@ -446,9 +458,6 @@ gbm_dri_bo_create(struct gbm_device *gbm,
int dri_format;
unsigned dri_use = 0;
 
-   if (dri-image-base.version  4  (usage  GBM_BO_USE_WRITE))
-  return NULL;
-
bo = calloc(1, sizeof *bo);
if (bo == NULL)
   return NULL;
@@ -457,6 +466,33 @@ gbm_dri_bo_create(struct gbm_device *gbm,
bo-base.base.width = width;
bo-base.base.height = height;
 
+   if (usage  GBM_BO_USE_WRITE) {
+  int ret;
+  unsigned attrs[7] = {
+ KMS_WIDTH, 64,
+ KMS_HEIGHT, 64,
+ KMS_BO_TYPE, KMS_BO_TYPE_SCANOUT_X8R8G8B8,
+ KMS_TERMINATE_PROP_LIST,
+  };
+
+  if (!(usage  GBM_BO_USE_CURSOR_64X64))
+ return NULL;
+
+  if (dri-kms == NULL)
+ return NULL;
+
+  ret = kms_bo_create(dri-kms, attrs, bo-bo);
+  if (ret  0) {
+ free(bo);
+ return NULL;
+  }
+
+  kms_bo_get_prop(bo-bo, KMS_PITCH, bo-base.base.stride);
+  kms_bo_get_prop(bo-bo, KMS_HANDLE, (unsigned*)bo-base.base.handle);
+
+  return bo-base.base;
+   }
+
switch (format) {
case GBM_FORMAT_RGB565:
   dri_format =__DRI_IMAGE_FORMAT_RGB565;
@@ -570,6 +606,10 @@ dri_device_create(int fd)
   return NULL;
}
 
+   if (dri-image-base.version  4) {
+  kms_create(fd, dri-kms);
+   }
+
return dri-base.base;
 }
 
diff --git a/src/gbm/backends/dri/gbm_driint.h 
b/src/gbm/backends/dri/gbm_driint.h
index f404368..4b619a0 100644
--- a/src/gbm/backends/dri/gbm_driint.h
+++ b/src/gbm/backends/dri/gbm_driint.h
@@ -30,6 +30,8 @@
 
 #include gbmint.h
 
+#include libkms.h

[Mesa-dev] [PATCH 5/6] dri: Remove image write function

[Jakob Bornecrantz]

Since its not used by anything anymore and no release has gone out
where it was being used.

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 include/GL/internal/dri_interface.h|   10 +-
 src/gbm/backends/dri/gbm_dri.c |2 --
 src/mesa/drivers/dri/intel/intel_regions.h |1 -
 src/mesa/drivers/dri/intel/intel_screen.c  |   28 
 4 files changed, 1 insertion(+), 40 deletions(-)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index 97e1a1a..e766226 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -935,8 +935,7 @@ struct __DRIdri2ExtensionRec {
 
 #define __DRI_IMAGE_USE_SHARE  0x0001
 #define __DRI_IMAGE_USE_SCANOUT0x0002
-#define __DRI_IMAGE_USE_CURSOR 0x0004
-#define __DRI_IMAGE_USE_WRITE  0x0008
+#define __DRI_IMAGE_USE_CURSOR 0x0004 /* Depricated */
 
 /**
  * queryImage attributes
@@ -985,13 +984,6 @@ struct __DRIimageExtensionRec {
GLboolean (*validateUsage)(__DRIimage *image, unsigned int use);
 
/**
-* Write data into image.
-*
-* \since 4
-*/
-   int (*write)(__DRIimage *image, const void *buf, size_t count);
-
-   /**
 * Create an image out of a sub-region of a parent image.  This
 * entry point lets us create individual __DRIimages for different
 * planes in a planar buffer (typically yuv), for example.  While a
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 15a7622..1731e4a 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -516,8 +516,6 @@ gbm_dri_bo_create(struct gbm_device *gbm,
   dri_use |= __DRI_IMAGE_USE_SCANOUT;
if (usage  GBM_BO_USE_CURSOR_64X64)
   dri_use |= __DRI_IMAGE_USE_CURSOR;
-   if (usage  GBM_BO_USE_WRITE)
-  dri_use |= __DRI_IMAGE_USE_WRITE;
 
/* Gallium drivers requires shared in order to get the handle/stride */
dri_use |= __DRI_IMAGE_USE_SHARE;
diff --git a/src/mesa/drivers/dri/intel/intel_regions.h 
b/src/mesa/drivers/dri/intel/intel_regions.h
index 782d669..4ff0efe 100644
--- a/src/mesa/drivers/dri/intel/intel_regions.h
+++ b/src/mesa/drivers/dri/intel/intel_regions.h
@@ -144,7 +144,6 @@ intel_region_get_aligned_offset(struct intel_region 
*region, uint32_t x,
 struct __DRIimageRec {
struct intel_region *region;
GLenum internal_format;
-   uint32_t usage;
uint32_t dri_format;
GLuint format;
uint32_t offset;
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c 
b/src/mesa/drivers/dri/intel/intel_screen.c
index f4c1602..103fcd2 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -339,13 +339,7 @@ intel_create_image(__DRIscreen *screen,
   tiling = I915_TILING_NONE;
}
 
-   /* We only support write for cursor drm images */
-   if ((use  __DRI_IMAGE_USE_WRITE) 
-   use != (__DRI_IMAGE_USE_WRITE | __DRI_IMAGE_USE_CURSOR))
-  return NULL;
-
image = intel_allocate_image(format, loaderPrivate);
-   image-usage = use;
cpp = _mesa_get_format_bytes(image-format);
image-region =
   intel_region_alloc(intelScreen, tiling, cpp, width, height, true);
@@ -399,7 +393,6 @@ intel_dup_image(__DRIimage *orig_image, void *loaderPrivate)
}
 
image-internal_format = orig_image-internal_format;
-   image-usage   = orig_image-usage;
image-dri_format  = orig_image-dri_format;
image-format  = orig_image-format;
image-offset  = orig_image-offset;
@@ -416,29 +409,9 @@ intel_validate_usage(__DRIimage *image, unsigned int use)
 return GL_FALSE;
}
 
-   /* We only support write for cursor drm images */
-   if ((use  __DRI_IMAGE_USE_WRITE) 
-   use != (__DRI_IMAGE_USE_WRITE | __DRI_IMAGE_USE_CURSOR))
-  return GL_FALSE;
-
return GL_TRUE;
 }
 
-static int
-intel_image_write(__DRIimage *image, const void *buf, size_t count)
-{
-   if (image-region-map_refcount)
-  return -1;
-   if (!(image-usage  __DRI_IMAGE_USE_WRITE))
-  return -1;
-
-   drm_intel_bo_map(image-region-bo, true);
-   memcpy(image-region-bo-virtual, buf, count);
-   drm_intel_bo_unmap(image-region-bo);
-
-   return 0;
-}
-
 static __DRIimage *
 intel_create_sub_image(__DRIimage *parent,
int width, int height, int dri_format,
@@ -490,7 +463,6 @@ static struct __DRIimageExtensionRec intelImageExtension = {
 intel_query_image,
 intel_dup_image,
 intel_validate_usage,
-intel_image_write,
 intel_create_sub_image
 };
 
-- 
1.7.9.5

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

[Mesa-dev] [PATCH 6/6] egl_dri2: Avoid using createSubImage when not neccassery

[Jakob Bornecrantz]

Makes it possible to run Wayland on Gallium drivers.

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 src/egl/drivers/dri2/egl_dri2.c |   22 --
 src/gbm/backends/dri/gbm_dri.c  |   10 ++
 2 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 423d18d..d714dc9 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1197,9 +1197,13 @@ dri2_create_image_wayland_wl_buffer(_EGLDisplay *disp, 
_EGLContext *ctx,
offset = buffer-offset[index];
stride = buffer-stride[index];
 
-   dri_image = dri2_dpy-image-createSubImage(buffer-driver_buffer,
-   width, height, format,
-   offset, stride / cpp, NULL);
+   if (f-nplanes == 1) {
+  dri_image = dri2_dpy-image-dupImage(buffer-driver_buffer, NULL);
+   } else {
+  dri_image = dri2_dpy-image-createSubImage(buffer-driver_buffer,
+  width, height, format,
+  offset, stride / cpp, NULL);
+   }
 
return dri2_create_image(disp, dri_image);
 }
@@ -1360,11 +1364,17 @@ dri2_wl_reference_buffer(void *user_data, uint32_t name,
 {
_EGLDisplay *disp = user_data;
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
-   int i;
+   const struct wl_drm_format_descriptor *f;
+   int i, format = 0;
 
for (i = 0; i  ARRAY_SIZE(wl_drm_formats); i++)
   if (wl_drm_formats[i].wl_format == buffer-format) {
- buffer-driver_format = wl_drm_formats[i];
+ f = wl_drm_formats[i];
+ buffer-driver_format = f;
+ if (f-nplanes == 1)
+format = f-planes[0].dri_format;
+ else
+format = __DRI_IMAGE_FORMAT_NONE;
  break;
   }
 
@@ -1375,7 +1385,7 @@ dri2_wl_reference_buffer(void *user_data, uint32_t name,
   dri2_dpy-image-createImageFromName(dri2_dpy-dri_screen,
buffer-buffer.width,
buffer-buffer.height, 
-   __DRI_IMAGE_FORMAT_NONE, name,
+   format, name,
buffer-stride[0] / 4,
NULL);
 }
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 1731e4a..dfa5d39 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -422,10 +422,12 @@ gbm_dri_bo_import(struct gbm_device *gbm,
dri-image-queryImage(image, __DRI_IMAGE_ATTRIB_WIDTH, width);
dri-image-queryImage(image, __DRI_IMAGE_ATTRIB_HEIGHT, height);
 
-   bo-image = dri-image-createSubImage(image,
-  width, height, dri_format,
-  offset, stride / cpp, NULL);
-
+   if (dri-image-version  5)
+  bo-image = dri-image-dupImage(image, NULL);
+   else
+  bo-image = dri-image-createSubImage(image,
+ width, height, dri_format,
+ offset, stride / cpp, NULL);
 
if (usage  GBM_BO_USE_SCANOUT)
   dri_use |= __DRI_IMAGE_USE_SCANOUT;
-- 
1.7.9.5

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

[Mesa-dev] [PATCH 1/2] egl_dri2: Avoid using createSubImage when not neccassery

[Jakob Bornecrantz]

Makes it possible to run Wayland on Gallium drivers. At least a bit until
it tries to use gbm cursor bo's.

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 src/egl/drivers/dri2/egl_dri2.c |   22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index a78ee8b..7648e68 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1142,9 +1142,13 @@ dri2_create_image_wayland_wl_buffer(_EGLDisplay *disp, 
_EGLContext *ctx,
offset = buffer-offset[index];
stride = buffer-stride[index];
 
-   dri_image = dri2_dpy-image-createSubImage(buffer-driver_buffer,
-   width, height, format,
-   offset, stride / cpp, NULL);
+   if (f-nplanes == 1) {
+  dri_image = dri2_dpy-image-dupImage(buffer-driver_buffer, NULL);
+   } else {
+  dri_image = dri2_dpy-image-createSubImage(buffer-driver_buffer,
+  width, height, format,
+  offset, stride / cpp, NULL);
+   }
 
return dri2_create_image(disp, dri_image);
 }
@@ -1305,11 +1309,17 @@ dri2_wl_reference_buffer(void *user_data, uint32_t name,
 {
_EGLDisplay *disp = user_data;
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
-   int i;
+   const struct wl_drm_format_descriptor *f;
+   int i, format = 0;
 
for (i = 0; i  ARRAY_SIZE(wl_drm_formats); i++)
   if (wl_drm_formats[i].wl_format == buffer-format) {
- buffer-driver_format = wl_drm_formats[i];
+ f = wl_drm_formats[i];
+ buffer-driver_format = f;
+ if (f-nplanes == 1)
+format = f-planes[0].dri_format;
+ else
+format = __DRI_IMAGE_FORMAT_NONE;
  break;
   }
 
@@ -1320,7 +1330,7 @@ dri2_wl_reference_buffer(void *user_data, uint32_t name,
   dri2_dpy-image-createImageFromName(dri2_dpy-dri_screen,
buffer-buffer.width,
buffer-buffer.height, 
-   __DRI_IMAGE_FORMAT_NONE, name,
+   format, name,
buffer-stride[0] / 4,
NULL);
 }
-- 
1.7.9.5

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

[Mesa-dev] [PATCH 2/2] gbm: Use libkms to work around missing cursor support in dri drivers

[Jakob Bornecrantz]

Uses libkms to work around missing dri image cursor support. One could take
this patch one step futher and removing cursor surfaces entirely from the DRI
interface and as a consequence also from the Gallium interface. Tho to make
everybody happy with this it would probably require adding a kms_bo_write
function, but that is probably wise in anyways.

The only downside is that it adds a dependancy on libkms, this could how ever
be replaced with the dumb_bo drm ioctl interface.

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 configure.ac  |2 ++
 src/egl/drivers/dri2/Makefile.am  |1 +
 src/gbm/Makefile.am   |3 +-
 src/gbm/backends/dri/gbm_dri.c|   56 +
 src/gbm/backends/dri/gbm_driint.h |8 ++
 5 files changed, 63 insertions(+), 7 deletions(-)

diff --git a/configure.ac b/configure.ac
index 2ecedaf..f5836d6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1355,6 +1355,8 @@ if test x$enable_gbm = xyes; then
 if test $SHARED_GLAPI -eq 0; then
 AC_MSG_ERROR([gbm_dri requires --enable-shared-glapi])
 fi
+PKG_CHECK_MODULES([LIBKMS], [libkms], [],
+  AC_MSG_ERROR([gbm needs libkms]))
 fi
 fi
 GBM_PC_REQ_PRIV=libudev
diff --git a/src/egl/drivers/dri2/Makefile.am b/src/egl/drivers/dri2/Makefile.am
index 49ec06b..45f7dfa 100644
--- a/src/egl/drivers/dri2/Makefile.am
+++ b/src/egl/drivers/dri2/Makefile.am
@@ -30,6 +30,7 @@ AM_CFLAGS = \
$(DEFINES) \
$(LIBDRM_CFLAGS) \
$(LIBUDEV_CFLAGS) \
+   $(LIBKMS_CFLAGS) \
-DDEFAULT_DRIVER_DIR=\$(DRI_DRIVER_SEARCH_DIR)\
 
 noinst_LTLIBRARIES = libegl_dri2.la
diff --git a/src/gbm/Makefile.am b/src/gbm/Makefile.am
index f079da1..e22c55c 100644
--- a/src/gbm/Makefile.am
+++ b/src/gbm/Makefile.am
@@ -7,6 +7,7 @@ AM_CFLAGS = \
-I$(top_srcdir)/include \
-I$(top_srcdir)/src/gbm/main \
$(LIBUDEV_CFLAGS) \
+   $(LIBKMS_CFLAGS) \
$(DLOPEN_CFLAGS) \
$(DEFINES)
 
@@ -18,7 +19,7 @@ libgbm_la_SOURCES = \
main/backend.c \
main/common.c
 libgbm_la_LDFLAGS = -version-info 1:0
-libgbm_la_LIBADD = $(LIBUDEV_LIBS) $(DLOPEN_LIBS)
+libgbm_la_LIBADD = $(LIBUDEV_LIBS) $(LIBKMS_LIBS) $(DLOPEN_LIBS)
 
 if HAVE_EGL_PLATFORM_WAYLAND
 AM_CPPFLAGS = -DHAVE_WAYLAND_PLATFORM
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index f09f6ef..784bb93 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -301,11 +301,24 @@ gbm_dri_bo_write(struct gbm_bo *_bo, const void *buf, 
size_t count)
 {
struct gbm_dri_device *dri = gbm_dri_device(_bo-gbm);
struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
+   void *ptr;
+   int ret;
+
+   /* This should be safe as write is guarded in create. */
+   if (bo-image != NULL)
+  return dri-image-write(bo-image, buf, count);
+
+   if (bo-bo == NULL)
+  return -1;
 
-   if (dri-image-base.version  4)
+   ret = kms_bo_map(bo-bo, ptr);
+   if (ret  0)
   return -1;
 
-   return dri-image-write(bo-image, buf, count);
+   memcpy(ptr, buf, count);
+
+   kms_bo_unmap(bo-bo);
+   return 0;
 }
 
 static void
@@ -314,7 +327,10 @@ gbm_dri_bo_destroy(struct gbm_bo *_bo)
struct gbm_dri_device *dri = gbm_dri_device(_bo-gbm);
struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
 
-   dri-image-destroyImage(bo-image);
+   if (bo-image != NULL)
+  dri-image-destroyImage(bo-image);
+   if (bo-bo != NULL)
+  kms_bo_destroy(bo-bo);
free(bo);
 }
 
@@ -446,9 +462,6 @@ gbm_dri_bo_create(struct gbm_device *gbm,
int dri_format;
unsigned dri_use = 0;
 
-   if (dri-image-base.version  4  (usage  GBM_BO_USE_WRITE))
-  return NULL;
-
bo = calloc(1, sizeof *bo);
if (bo == NULL)
   return NULL;
@@ -457,6 +470,33 @@ gbm_dri_bo_create(struct gbm_device *gbm,
bo-base.base.width = width;
bo-base.base.height = height;
 
+   if (dri-image-base.version  4  (usage  GBM_BO_USE_WRITE)) {
+  int ret;
+  unsigned attrs[7] = {
+ KMS_WIDTH, 64,
+ KMS_HEIGHT, 64,
+ KMS_BO_TYPE, KMS_BO_TYPE_SCANOUT_X8R8G8B8,
+ KMS_TERMINATE_PROP_LIST,
+  };
+
+  if (!(usage  GBM_BO_USE_CURSOR_64X64))
+ return NULL;
+
+  if (dri-kms == NULL)
+ return NULL;
+
+  ret = kms_bo_create(dri-kms, attrs, bo-bo);
+  if (ret  0) {
+ free(bo);
+ return NULL;
+  }
+
+  kms_bo_get_prop(bo-bo, KMS_PITCH, bo-base.base.stride);
+  kms_bo_get_prop(bo-bo, KMS_HANDLE, (unsigned*)bo-base.base.handle);
+
+  return bo-base.base;
+   }
+
switch (format) {
case GBM_FORMAT_RGB565:
   dri_format =__DRI_IMAGE_FORMAT_RGB565;
@@ -567,6 +607,10 @@ dri_device_create(int fd)
   return NULL;
}
 
+   if (dri-image-base.version  4) {
+  kms_create(fd, dri-kms);
+   }
+
return dri-base.base;
 }
 
diff --git a/src/gbm/backends/dri/gbm_driint.h 
b/src/gbm/backends/dri/gbm_driint.h
index

Re: [Mesa-dev] Mesa 8.0 branch maintenance

[Jakob Bornecrantz]

- Original Message -
 We've been really crappy about keeping up on stable releases.  The
 biggest problem has been bug fixes sitting on master never getting
 cherry picked over.  Release time comes along, and either I cherry
 pick 57 patches over the day before the release or Jakob sends out
 an email with a similar list.


Slightly OT: my auto-cherry picker found some comments that didn't
apply cleanly, did you ever cherry pick those over?

 
 I think I have a plan that will remedy this situation.  Every time
 I see a patch go by that is marked with the stable note (or
 appears to fix a bugzilla on the stable release), I will pick it
 over to an 8.0-staging branch.  This branch will live in my
 personal repo on fdo.
 
 I will send out a weekly list with the patches on 8.0-staging that
 haven't spawned any bug reports on master.  If there are no
 objections in, say, 24 hours, I'll merge it to the release branch.
 Folks can also notify me about bad commits on the 8.0-staging
 branch at any time.


Sounds like a excellent plan. One nitpick wouldn't just be better of
merging last weeks list the time you send out a new list? Giving
people more time to comment.

 
 The first such list is below.  This is 40% of the patches
 currently on the 8.0-staging branch.
 

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

Re: [Mesa-dev] Upcoming Mesa releases

[Jakob Bornecrantz]

- Original Message -
 On Thu, May 03, 2012 at 02:38:11PM -0700, Ian Romanick wrote:
  To keep in the habit of doing regular releases, I'd like to propose
  the following set of release dates.  We had previously discussed
  doing stable releases monthly and feature releases every six
  months.
  This set of dates basically reflects that.
  
  I should be able to package up most of these, but I will be on
  vacation in June.  Perhaps Jakob can handle that one. :)
  
  I've listed the February 2013 release as 8.2.  I think there's a
  good chance we'll have OpenGL 3.1 by then, so it may end up being
  9.0.
  
  5/18:  Mesa 8.0.3
  6/15:  Mesa 8.0.4
 
 Now that you're appear to be back, could you look at releasing
 a 8.0.4 version?

Yes, but I would like some kind of response from people regarding
the auto picking of patches for the 8.0 branch that I sent out
on Wednesday. Missing over 40 commits that has the NOTE:
annotation on it isn't all that nice.

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

[Mesa-dev] Missing commits on stable

[Jakob Bornecrantz]

Finally got around to writing that script to analyse what should be on
8.0 but is not. I have attached the result.

First list is only there to shame people who have forgotten -x when
cherry picking. The second list is all the commits that we have
forgotten about that is on master. The third is a list of commits
which does not cleanly apply, the scons one turns out to be empty.

I have pushed a branch auto-cherry-for-8.0 with all the commits
cherry-picked, it compiles but I haven't done any real testing on it.
It all looks safe so I like to get them in and the release out ASAP.

Thoughts  comments please?

Cheers, Jakob.

PS: If some of the Intel guys could take a look at the failing cherry
picks that would be awesome.
 Commits from master that have NOTE that also have matching subjects on 
stable but not cherry picks
4a269a8 r300/compiler: Clear loop registers in vertex shaders w/o loops
5beba3d mesa: use _mesa_rebase_rgba_float/uint() in glGetTexImage code
7324923 r300/compiler: Copy all instruction attributes during local transfoms
e2dce7f intel: Fix rendering from textures after RenderTexture().
efd73f7 mapi/glapi: Never use a generic no-op entry-point on Windows.

 Commits from master that have NOTE that do not have matching commits or 
subjects on stable
84c7c14 st/mesa: pass GL_MAP_INVALIDATE_RANGE_BIT to gallium drivers
5abcd19 svga: add 0.5 in float-int conversion of sample min/max lod
fd89087 svga: fix min/max lod clamping
a9eda41 svga: change PIPE_CAPF_MAX_TEXTURE_LOD_BIAS from 16.0 to 15.0
2b4afdb i915g: Don't invert signalled/unsignalled fences
32b07bb i915g: Don't avoid flushing when we have a pending fence.
75f37dd st/mesa: add fallback pipe formats for (compressed) R, RG formats
fdae0ea st/mesa: copy num_immediates field when copying the immediates array
7f2e128 svga: move svga_texture() casts/calls in svga_surface_copy()
bca6cd2 scons: Remove Haiku one-offs for gallium drivers
04341e5 svga: reset vertex buffer offset in svga_release_user_upl_buffers()
07635a4 draw: Ensure that prepare is always run after LLVM garbagge collection.
5a70e12 st/mesa: don't set PIPE_BIND_DISPLAY_TARGET for user-created 
renderbuffers
0315cb9 st/mesa: use private pipe_sampler_view in decompress_with_blit()
03f8a97 st/mesa: add null pointer check in st_texture_image_map()
318669f st/mesa: fix mipmap image size computation w.r.t. texture arrays
7f16246 draw: fix missing immediates bug in polygon stipple code
0405bd0 glsl: Don't trust loop analysis in the presence of function calls.
299c905 st/mesa: fix max_offset computation for base vertex
783e4da r600g: check gpr count limit
70d038e st/mesa: Fix uninitialized members in glsl_to_tgsi_visitor constructor.
8e90913 mesa: require GL_MAX_SAMPLES = 4 for GL 3.0
6178b65 glu: fix two Clang warnings
93594f3 gallium/targets: pass ldflags parameter to MKLIB
f92b2e5 i830: Fix crash for GL_STENCIL_TEST in i830Enable()
1559b2e ralloc: Fix ralloc_parent() of memory allocated out of the NULL context.
adfe531 glsl: Remove spurious printf messages
608c3d2 mesa: Restore depth texture state on glPopAttrib(GL_TEXTURE_BIT).
25edfbf glsl/builtins: Fix textureGrad() for Array samplers.
cb8ed93 mesa: Unbind ARB_copy_buffer and transform feedback buffers on delete.
05b086c mesa: Support BindBuffer{Base,Offset,Range} with a buffer of 0.
3edd2ba mesa: Unbind ARB_transform_feedback2 binding points on Delete too.
7fde071 meta: Fix GL_RENDERBUFFER binding in decompress_texture_image().
217b62b i965/fs: Fix texelFetchOffset() on pre-Gen7.
cb18472 i965/vs: Fix texelFetchOffset() on pre-Gen7.
2f18698 i965/fs: Fix user-defined FS outputs with less than four components.
3603fdc glsl: Hook up loop_variable_state destructor to plug a memory leak.
0256edd glx: Handle a null reply in QueryVersion.
53feb8e meta: Cleanup the resources we allocate.
e2e9b4b mesa: Free uniforms correclty.
4bfdc83 glsl: Fix pi/2 constant in acos built-in function
5e7e7d9 st/mesa: don't do srgb-linear conversion in decompress_with_blit

 Of which these does not apply cleanely
bca6cd2 scons: Remove Haiku one-offs for gallium drivers
cb18472 i965/vs: Fix texelFetchOffset() on pre-Gen7.
2f18698 i965/fs: Fix user-defined FS outputs with less than four components.
4bfdc83 glsl: Fix pi/2 constant in acos built-in function

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

Re: [Mesa-dev] Upcoming Mesa releases

[Jakob Bornecrantz]

On Thu, May 3, 2012 at 11:38 PM, Ian Romanick i...@freedesktop.org wrote:
 To keep in the habit of doing regular releases, I'd like to propose the
 following set of release dates.  We had previously discussed doing stable
 releases monthly and feature releases every six months.  This set of dates
 basically reflects that.

 I should be able to package up most of these, but I will be on vacation in
 June.  Perhaps Jakob can handle that one. :)

 I've listed the February 2013 release as 8.2.  I think there's a good chance
 we'll have OpenGL 3.1 by then, so it may end up being 9.0.

 5/18:  Mesa 8.0.3
 6/15:  Mesa 8.0.4

Hello people, so I was going to do a release today. but currently
there are just three fixes on the 8.0 branch not already in th 8.0.3
release. I would like to see a bit more there before doing a release
especially since I know there are patches that should be cherry picked
over.

So it would be good if people could pick patches over for their area.
People without commit access but who want to nominate fixes please do
so here and I will cherry pick them over. I will take a look on Monday
and see where we are then.

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

Re: [Mesa-dev] [PATCH 04/19] make: Drop HOST_CC and HOST_CFLAGS.

[Jakob Bornecrantz]

- Original Message -
 Except for the deleted linux-cell target, these were just the target
 cc/cflags.  The only usage was for gen_matypes, which wants the
 target's structure packing, not the host, anyway.
 ---
  configs/default   |2 --
  src/mesa/x86/Makefile |2 +-
  2 files changed, 1 insertion(+), 3 deletions(-)
 
 diff --git a/configs/default b/configs/default
 index 20ba796..bf67d34 100644
 --- a/configs/default
 +++ b/configs/default
 @@ -19,11 +19,9 @@ DRM_SOURCE_PATH=$(TOP)/../drm
  # Compiler and flags
  CC = cc
  CXX = CC
 -HOST_CC = $(CC)
  CFLAGS = -O
  CXXFLAGS = -O
  LDFLAGS =
 -HOST_CFLAGS = $(CFLAGS)
  GLU_CFLAGS =
  GLX_TLS = no
  
 diff --git a/src/mesa/x86/Makefile b/src/mesa/x86/Makefile
 index 9716dc2..8107176 100644
 --- a/src/mesa/x86/Makefile
 +++ b/src/mesa/x86/Makefile
 @@ -21,7 +21,7 @@ clean:
  
  
  gen_matypes: gen_matypes.c
 - $(HOST_CC) $(ARCH_FLAGS) $(INCLUDE_DIRS) $(HOST_CFLAGS) gen_matypes.c 
 -o gen_matypes
 + $(CC) $(ARCH_FLAGS) $(INCLUDE_DIRS) $(CFLAGS) gen_matypes.c -o 
 gen_matypes

Wont this explode in a great ball of fire if somebody is doing 32
to 64bit cross compiles? While that might not be the most common
case shouldn't gen_matypes be safe for 64 to 32bit builds?

Do we still run the glslcompiler on builds as well? Doesn't it
need HOST_CC?

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

Re: [Mesa-dev] [PATCH] scons: Fix Haiku binary compatibility

[Jakob Bornecrantz]

On Thu, Jun 7, 2012 at 5:20 PM, Alexander von Gluck IV
kallis...@unixzen.com wrote:
 From 44fa55d3f49884c824306504943ca2a1382601f0 Mon Sep 17 00:00:00 2001

 * Our binary compatibility is targeted to Pentimum or higher,
  these changes ensure we keep proper optimizations
 * Fixes strange if statement
  '! windows or debug or True'

Looks good, or at least it doesn't seem to break anything else can't
really comment on
the Haiku specific parts of this.

Reviewed-by: Jakob Bornecrantz ja...@vmware.com

Lets get you commit access, so these patches doesn't root on the ML for to long.

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

Re: [Mesa-dev] [PATCH] mesa: Build git_sha1.h before computing dependencies.

[Jakob Bornecrantz]

- Original Message -
 Otherwise, version.c doesn't get a dependency on it in a clean build,
 and then it doesn't necessarily get generated before version.c is
 compiled.
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50976

Thanks for fixing this.

Reviewed-by: Jakob Bornecrantz ja...@vmware.com

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

Re: [Mesa-dev] [PATCH] gbm: Add gbm_bo_write entry point

[Jakob Bornecrantz]

Hi Kristian,

s/gbm_bo_write/gbm_bo_write_to_cursor/g and make fail on anything
other then cursors and I'm happy. Not making it just happen
to work on some hardware really sucks for those that it doesn't
work on because people will expect it to work.

Cheers, Jakob.

- Original Message -
 This new gbm entry point allows writing data into a gbm bo.  The bo
 has to be created with the GBM_BO_USE_WRITE flag, and it's only
 required to work for GBM_BO_USE_CURSOR_64X64 bos.
 
 The gbm API is designed to be the glue layer between EGL and KMS, but
 there was never a mechanism initialize a buffer suitable for use with
 KMS hw cursors.  The hw cursor bo is typically not compatible with
 anything EGL can render to, and thus there's no way to get data into
 such a bo.
 
 gbm_bo_write() fills that gap while staying out of the efficient
 cpu-gpu pixel transfer business.
 ---
  include/GL/internal/dri_interface.h   |   10 +-
  src/gbm/backends/dri/gbm_dri.c|   18 ++
  src/gbm/main/gbm.c|   19 +++
  src/gbm/main/gbm.h|9 +
  src/gbm/main/gbmint.h |1 +
  src/mesa/drivers/dri/intel/intel_screen.c |   24
  ++--
  6 files changed, 78 insertions(+), 3 deletions(-)
 
 diff --git a/include/GL/internal/dri_interface.h
 b/include/GL/internal/dri_interface.h
 index eafbe10..e37917e 100644
 --- a/include/GL/internal/dri_interface.h
 +++ b/include/GL/internal/dri_interface.h
 @@ -894,7 +894,7 @@ struct __DRIdri2ExtensionRec {
   * extensions.
   */
  #define __DRI_IMAGE DRI_IMAGE
 -#define __DRI_IMAGE_VERSION 3
 +#define __DRI_IMAGE_VERSION 4
  
  /**
   * These formats correspond to the similarly named MESA_FORMAT_*
 @@ -911,6 +911,7 @@ struct __DRIdri2ExtensionRec {
  #define __DRI_IMAGE_USE_SHARE0x0001
  #define __DRI_IMAGE_USE_SCANOUT  0x0002
  #define __DRI_IMAGE_USE_CURSOR   0x0004
 +#define __DRI_IMAGE_USE_WRITE0x0008
  
  /**
   * queryImage attributes
 @@ -955,6 +956,13 @@ struct __DRIimageExtensionRec {
  * \since 2
  */
 GLboolean (*validateUsage)(__DRIimage *image, unsigned int use);
 +
 +   /**
 +* Write data into image.
 +*
 +* \since 4
 +*/
 +   int (*write)(__DRIimage *image, const void *buf, size_t count);
  };
  
  
 diff --git a/src/gbm/backends/dri/gbm_dri.c
 b/src/gbm/backends/dri/gbm_dri.c
 index 4df6e8f..e5ddfb6 100644
 --- a/src/gbm/backends/dri/gbm_dri.c
 +++ b/src/gbm/backends/dri/gbm_dri.c
 @@ -291,6 +291,18 @@ gbm_dri_is_format_supported(struct gbm_device
 *gbm,
 return 1;
  }
  
 +static int
 +gbm_dri_bo_write(struct gbm_bo *_bo, const void *buf, size_t count)
 +{
 +   struct gbm_dri_device *dri = gbm_dri_device(_bo-gbm);
 +   struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
 +
 +   if (dri-image-base.version  4)
 +  return -1;
 +
 +   return dri-image-write(bo-image, buf, count);
 +}
 +
  static void
  gbm_dri_bo_destroy(struct gbm_bo *_bo)
  {
 @@ -390,6 +402,9 @@ gbm_dri_bo_create(struct gbm_device *gbm,
 int dri_format;
 unsigned dri_use = 0;
  
 +   if (dri-image-base.version  4  (usage  GBM_BO_USE_WRITE))
 +  return NULL;
 +
 bo = calloc(1, sizeof *bo);
 if (bo == NULL)
return NULL;
 @@ -421,6 +436,8 @@ gbm_dri_bo_create(struct gbm_device *gbm,
dri_use |= __DRI_IMAGE_USE_SCANOUT;
 if (usage  GBM_BO_USE_CURSOR_64X64)
dri_use |= __DRI_IMAGE_USE_CURSOR;
 +   if (usage  GBM_BO_USE_WRITE)
 +  dri_use |= __DRI_IMAGE_USE_WRITE;
  
 bo-image =
dri-image-createImage(dri-screen,
 @@ -491,6 +508,7 @@ dri_device_create(int fd)
 dri-base.base.bo_create = gbm_dri_bo_create;
 dri-base.base.bo_create_from_egl_image =
 gbm_dri_bo_create_from_egl_image;
 dri-base.base.is_format_supported = gbm_dri_is_format_supported;
 +   dri-base.base.bo_write = gbm_dri_bo_write;
 dri-base.base.bo_destroy = gbm_dri_bo_destroy;
 dri-base.base.destroy = dri_destroy;
 dri-base.base.surface_create = gbm_dri_surface_create;
 diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
 index 987e965..3994f86 100644
 --- a/src/gbm/main/gbm.c
 +++ b/src/gbm/main/gbm.c
 @@ -231,6 +231,25 @@ gbm_bo_get_handle(struct gbm_bo *bo)
 return bo-handle;
  }
  
 +/** Write data into the buffer object
 + *
 + * If the buffer object was created with the GBM_BO_USE_WRITE flag,
 + * this function can used to write data into the buffer object.  The
 + * data is copied directly into the object and it's the
 responsiblity
 + * of the caller to make sure the data represents valid pixel data,
 + * according to the width, height, stride and format of the buffer
 object.
 + *
 + * \param bo The buffer object
 + * \param buf The data to write
 + * \param count The number of bytes to write
 + * \return Returns -1 on error, 0 otherwise
 + */
 +GBM_EXPORT int
 +gbm_bo_write(struct gbm_bo *bo, const void *buf, size_t count)
 +{
 

Re: [Mesa-dev] [PATCH] gbm: Add gbm_bo_write entry point

[Jakob Bornecrantz]

- Ursprungligt meddelande -
 On Thu, May 3, 2012 at 7:47 AM, Jakob Bornecrantz ja...@vmware.com
 wrote:
  Hi Kristian,
 
  s/gbm_bo_write/gbm_bo_write_to_cursor/g and make fail on anything
  other then cursors and I'm happy. Not making it just happen
  to work on some hardware really sucks for those that it doesn't
  work on because people will expect it to work.
 
 I think we have a good compromise the way the patch is.  I don't want
 to restrict the write entrypoint to only cursors.  Not because I
 think
 it should work with generic gbm bos, but becase I don't want to
 preclude gbm_bo_write from working with a future similar restricted,
 special case bo type.

Fair enough.

Can you put the if use != WRITE return -1; snippet in the
gbm_bo_write function or all the drivers supposed to validate the args?

Cheers, Jakob.

 
 Kristian
 
  Cheers, Jakob.
 
  - Original Message -
  This new gbm entry point allows writing data into a gbm bo.  The
  bo
  has to be created with the GBM_BO_USE_WRITE flag, and it's only
  required to work for GBM_BO_USE_CURSOR_64X64 bos.
 
  The gbm API is designed to be the glue layer between EGL and KMS,
  but
  there was never a mechanism initialize a buffer suitable for use
  with
  KMS hw cursors.  The hw cursor bo is typically not compatible with
  anything EGL can render to, and thus there's no way to get data
  into
  such a bo.
 
  gbm_bo_write() fills that gap while staying out of the efficient
  cpu-gpu pixel transfer business.
  ---
   include/GL/internal/dri_interface.h       |   10 +-
   src/gbm/backends/dri/gbm_dri.c            |   18
   ++
   src/gbm/main/gbm.c                        |   19
   +++
   src/gbm/main/gbm.h                        |    9 +
   src/gbm/main/gbmint.h                     |    1 +
   src/mesa/drivers/dri/intel/intel_screen.c |   24
   ++--
   6 files changed, 78 insertions(+), 3 deletions(-)
 
  diff --git a/include/GL/internal/dri_interface.h
  b/include/GL/internal/dri_interface.h
  index eafbe10..e37917e 100644
  --- a/include/GL/internal/dri_interface.h
  +++ b/include/GL/internal/dri_interface.h
  @@ -894,7 +894,7 @@ struct __DRIdri2ExtensionRec {
    * extensions.
    */
   #define __DRI_IMAGE DRI_IMAGE
  -#define __DRI_IMAGE_VERSION 3
  +#define __DRI_IMAGE_VERSION 4
 
   /**
    * These formats correspond to the similarly named MESA_FORMAT_*
  @@ -911,6 +911,7 @@ struct __DRIdri2ExtensionRec {
   #define __DRI_IMAGE_USE_SHARE                0x0001
   #define __DRI_IMAGE_USE_SCANOUT              0x0002
   #define __DRI_IMAGE_USE_CURSOR               0x0004
  +#define __DRI_IMAGE_USE_WRITE                0x0008
 
   /**
    * queryImage attributes
  @@ -955,6 +956,13 @@ struct __DRIimageExtensionRec {
       * \since 2
       */
      GLboolean (*validateUsage)(__DRIimage *image, unsigned int
      use);
  +
  +   /**
  +    * Write data into image.
  +    *
  +    * \since 4
  +    */
  +   int (*write)(__DRIimage *image, const void *buf, size_t
  count);
   };
 
 
  diff --git a/src/gbm/backends/dri/gbm_dri.c
  b/src/gbm/backends/dri/gbm_dri.c
  index 4df6e8f..e5ddfb6 100644
  --- a/src/gbm/backends/dri/gbm_dri.c
  +++ b/src/gbm/backends/dri/gbm_dri.c
  @@ -291,6 +291,18 @@ gbm_dri_is_format_supported(struct gbm_device
  *gbm,
      return 1;
   }
 
  +static int
  +gbm_dri_bo_write(struct gbm_bo *_bo, const void *buf, size_t
  count)
  +{
  +   struct gbm_dri_device *dri = gbm_dri_device(_bo-gbm);
  +   struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
  +
  +   if (dri-image-base.version  4)
  +      return -1;
  +
  +   return dri-image-write(bo-image, buf, count);
  +}
  +
   static void
   gbm_dri_bo_destroy(struct gbm_bo *_bo)
   {
  @@ -390,6 +402,9 @@ gbm_dri_bo_create(struct gbm_device *gbm,
      int dri_format;
      unsigned dri_use = 0;
 
  +   if (dri-image-base.version  4  (usage 
  GBM_BO_USE_WRITE))
  +      return NULL;
  +
      bo = calloc(1, sizeof *bo);
      if (bo == NULL)
         return NULL;
  @@ -421,6 +436,8 @@ gbm_dri_bo_create(struct gbm_device *gbm,
         dri_use |= __DRI_IMAGE_USE_SCANOUT;
      if (usage  GBM_BO_USE_CURSOR_64X64)
         dri_use |= __DRI_IMAGE_USE_CURSOR;
  +   if (usage  GBM_BO_USE_WRITE)
  +      dri_use |= __DRI_IMAGE_USE_WRITE;
 
      bo-image =
         dri-image-createImage(dri-screen,
  @@ -491,6 +508,7 @@ dri_device_create(int fd)
      dri-base.base.bo_create = gbm_dri_bo_create;
      dri-base.base.bo_create_from_egl_image =
      gbm_dri_bo_create_from_egl_image;
      dri-base.base.is_format_supported =
      gbm_dri_is_format_supported;
  +   dri-base.base.bo_write = gbm_dri_bo_write;
      dri-base.base.bo_destroy = gbm_dri_bo_destroy;
      dri-base.base.destroy = dri_destroy;
      dri-base.base.surface_create = gbm_dri_surface_create;
  diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
  index 987e965..3994f86 100644
  --- a/src/gbm/main/gbm.c
  +++ b/src/gbm/main/gbm.c
  @@ -231,6

Re: [Mesa-dev] [PATCH] gbm: Add gbm_bo_write entry point

[Jakob Bornecrantz]

- Ursprungligt meddelande -
 This new gbm entry point allows writing data into a gbm bo.  The bo
 has to be created with the GBM_BO_USE_WRITE flag, and it's only
 required to work for GBM_BO_USE_CURSOR_64X64 bos.
 
 The gbm API is designed to be the glue layer between EGL and KMS, but
 there was never a mechanism initialize a buffer suitable for use with
 KMS hw cursors.  The hw cursor bo is typically not compatible with
 anything EGL can render to, and thus there's no way to get data into
 such a bo.
 
 gbm_bo_write() fills that gap while staying out of the efficient
 cpu-gpu pixel transfer business.

Actually I was thinking of libkms when reviewing this patch.

Sorry but I'm going to strongly NAK this patch, if you had done the
gallium part of this you would have known why.

The reason is that there is no way to upload data to a buffer in
Gallium without a context and there is a big chance that the
context will try to get into the efficient cpu-gpu business
whether you like it or not.

This all means that the gbm_device is a rendering context and
if we ever want to do something better of synchronizing between
context then the FIFO approach we have now we all of a sudden
need to add fences to gbm. And I'm strongly opposed to this.

Can we work out something else for this?

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

Re: [Mesa-dev] [PATCH 1/3] gbm: Add gbm_surface interface

[Jakob Bornecrantz]

 +
 +   struct gbm_surface *(*surface_create)(struct gbm_device *gbm,
 +                                         uint32_t width, uint32_t height,
 +                                         uint32_t format);
 +   struct gbm_bo *(*surface_lock_front_buffer)(struct gbm_surface *surface);
 +   void (*surface_release_buffer)(struct gbm_surface *surface,
 +                                  struct gbm_bo *bo);
 +   int (*surface_has_free_buffers)(struct gbm_surface *surface);
 +   void (*surface_destroy)(struct gbm_surface *surface);


Surface map and unmap needs a pipe_context for gallium,
and as such dri_context. I don't know what the best way to solve
that in gbm, either via a hidden dri_context[1] or via a
new gbm_context.

Cheers, Jakob.

[1] which I don't like since we can't get to it if with
fences since if we actually want to support better command
scheduling then what we currently have.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 00/12] gallium: Misc. changes from gallium-compute.

[Jakob Bornecrantz]

- Original Message -
 Jakob Bornecrantz ja...@vmware.com writes:
 
  - Original Message -
  Jakob Bornecrantz ja...@vmware.com writes:
  
   +libws_loader_la_LIBADD = \
   + $(top_srcdir)/src/gallium/winsys/sw/null/libws_null.la
   +
   +if HAVE_XLIB_LOADER_GALLIUM
   +libws_loader_la_LIBADD += \
   + $(top_srcdir)/src/gallium/winsys/sw/xlib/libws_xlib.la
   +AM_CFLAGS += -DHAVE_WS_LOADER_XLIB
   +endif
  
   Ah so this explains the not sorting winsys dir, this shouldn't
   be done on the winsys this is for the target to keep track of.
   Just as it is the targets job to link libdrm.
  
  
  I had the feeling that letting a winsys link to another wouldn't
  be
  much of a problem, especially if all the winsys build system is
  going to be converted to automake and we're going to get a more
  automated dependency tracking.  But, if we don't want to relax
  that restriction anyway, the other possibility would be to define
  a GALLIUM_WS_LOADER_LIBS variable at configure time containing all
  the objects a target has to pull in order to link to the winsys
  loader.  Would that be OK with you?
 
  Sounds good with me. Under the scons build we usually put that
  calculation in the targets [1][2], but I guess for automake we
  want a more centralized approach.
 
 
 Updated patch series follows.  I've used the configure variable
 approach to avoid having to replicate the same logic in every target
 that makes use of winsys/loader.  '[PATCH 09/15] configure.ac: Don't
 sort GALLIUM_WINSYS_DIRS' isn't necessary now.
 
 Jakob Bornecrantz ja...@vmware.com writes:
 
  I'm not against this and the other change per say, I just
  wished all of the winsys's where converted at the same time.
 
 OK, I'm also leaving out the automake conversion of winsys/null and
 winsys/xlib for a future patch series.

Patches 1, 10, 11  12 are
Reviewed-by: Jakob Bornecrantz ja...@vmware.com

I know to little about the TGSI code to feel comfortable to give a RB,
but code wise the look good.

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

Re: [Mesa-dev] Doing 8.0.1 release?

[Jakob Bornecrantz]

- Original Message -
 On Tue, Mar 13, 2012 at 10:28 AM, Jakob Bornecrantz
 ja...@vmware.com wrote:
  - Original Message -
  On Mon, Mar 12, 2012 at 8:05 PM, Jakob Bornecrantz
  ja...@vmware.com wrote:
   Hi all
  
   We well over due for a 8.0.1 release, so I thought
   we do it aggressively this week. A quick rc tomorrow
   and a release on Thursday or Friday? Is that okay with
   people, comments please?
 
  This should be cherry-picked, right?
 
  commit b60120608f6ddf4098bc324363197c979ee04cb7
  Author: David Fries da...@fries.net
 
      Set close on exec flag FD_CLOEXEC
 
  I think most of the marked candidates since the branch that show
  up
  in
  `git log origin/8.0..origin/master --grep=NOTE` are still only in
  master...
 
  And this in particular is reportedly vital[1] for llvmpipe FBO
  rendering:
 
  commit 5a70e12fc0897a3178c73b20d99fc0f11b180374
  Author: Brian Paul bri...@vmware.com
 
      st/mesa: don't set PIPE_BIND_DISPLAY_TARGET for user-created
      renderbuffers
 
  [1]
  http://lists.freedesktop.org/archives/mesa-dev/2012-March/019690.html
 
  Thanks, I'll make sure they get picked.
 Did these not make it in?

No, missed those sorry.

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

Re: [Mesa-dev] [PATCH 09/15] configure.ac: Don't sort GALLIUM_WINSYS_DIRS

[Jakob Bornecrantz]

- Original Message -
 From: Tom Stellard thomas.stell...@amd.com
 
 This allows targets to order winsys directories, so dependencies are
 built in the correct order.

This makes me think you have done something wrong in winsys, can
you please tell my why this is needed, the theory behind it is that
winsys's aren't dependent on each other, and thats what targets
are for.

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

Re: [Mesa-dev] [PATCH 10/15] winsys/sw/null: Convert to automake.

[Jakob Bornecrantz]

I'm not against this and the other change per say, I just
wished all of the winsys's where converted at the same time.

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