gfxstream + Mesa: the deal of the century?

[Gurchetan Singh]

tl;dr

- Interested in porting the gfxstream virtualization solution to
  Mesa and wondering how everyone feels about it

--
| Longer |
--

Dear all,

In an earnings call with investors, Santa Claus shared a grim
outlook for the North Pole. The Q4 2023 holiday season's yield of
milk and cookies  -- the currency of the North Pole economy -- was
once again drastically below expectations.

As everyone knows, Santa Claus delivers presents to the people of
the world, and in return is rewarded with milk and cookies.  The
milk and cookies are then used to feed the elves, who then create
next year's presents.  This arrangement has proved remarkably
resilient since time immemorial: surviving war, feminine, plagues
and even Episodes 7 through 9 of the Star Wars saga.

However, the past few years have seen demand for a rather unusual
present skyrocket.  Letter after letter has arrived, saying: "Dear
Santa, can we get gfxstream Vulkan ported to Mesa .. an upstream
gfxsteam?!?"

Jolly old Saint Nick, despite his considerable powers, is unable
to deliver this most demanded present.  As a result, cookie and
milk reserves have fallen to dangerous levels.

Santa Claus has been offered a leveraged buyout of the North Pole by
Wall Street firm to fix the shortfall.  The firm has a radical plan
to cut costs and increase revenues:

   - instead of nutritious milk and cookies, the Elves will be fed
 doritos, sugary drinks and adderall
   - no more "naughty or nice" lists: presents will now be based
 on a monthly subscription fee.
   - selling ads on the sled
   - a dog food factory to 'process' the reindeer.

There is still hope, my friends.  In consultation with the Easter
Bunny, we have come with a plan that just might work.  With this
RFC, we have a working port of gfxstream in Mesa.  If all goes well,
the Easter Bunny should be able to deliver gfxstream + Mesa in
easter eggs, and generate an unprecedented amount of carrots in
return.

The carrots will be converted to milk and cookies, and the North
Pole's economy will once again be thriving.

But for this plan to work, we must port gfxstream into Mesa..


| Common Questions |


Q: What is gfxstream?

gfxstream is an API-virtualization solution

https://android.googlesource.com/platform/hardware/google/gfxstream/

The history and lore of the project can be found here [a].

Q: Where will this be used and productized?

Pretty much everywhere gfxstream is used now, namely:

- Android Emulator [b]
- Cuttlefish [c]
- Google Play Games [d]
- Fuchsia guests [e]
- AAOS reference guests [f]
- a few other more experimental projects

These projects do reach O(million) users.  Most projects aim for
strong backwards compatibility: i.e, Android images from 2019 still
work on the 2023 host emulator release, and efforts are made to make
sure ABI changes don't break developers.

However, in the non-emulator embedded space, gfxstream-ists do plan to
ship the host driver in the guest.

Q: Is gfxstream upstream in the Linux kernel sense?

gfxstream is officially part of the virtio-gpu spec and supported
on open-source VMMs like QEMU and crosvm.  Recent virtio-gpu additions
like blob resources [g] and context types [h] were first tested/enabled
on gfxstream.

Q: Where is the current MR?

Current MR:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27246

The MR is very dirty at the moment, but do expect to Mesa-ify and
clean it up further.

It's around 216K LoC, but 70K LoC are pre-compiled shaders which we
can do something about.  We also have patches on top of the Vulkan-Docs
repo (around 30K), which can be upstreamed elsewhere too.  It's also one
big mega-commit rather than 1000s of history preserving ones.

But it should be enough to pass deqp-vk, and see the generalized
structure.

We endeavor to meet all coding standards of the Mesa project.  But
first we want see if there are any strong opinions on the general
idea before investing in further Mesa-ification.

Q: What are the reasons for porting gfxstream to Mesa?

- Non-Android developers have expressed desire to decouple gfxstream
from AOSP.  AOSP is gigantic to download and developers also have to
sign a CLA.  Aside from Mesa, the only real option is Github,
which we can all agree is a downgrade from Mesa.

- The Mesa WSI layer uses gfxstream guest Linux support.  Currently
we just rip out parts of Mesa to make it work, but it's better to be
in-tree.  The other option was the ARM Mesa WSI layer, but Mesa
WSI seemed better maintained.

Q: What are the benefits to Mesa?

As gfxstream becomes a Mesa driver, Mesa will be used more than ever
in virtualized environments.

We also see the benefits for improved maintenance of AOSP Mesa, which
is now on a 3-year old commit.  Having a project that is on the official
support path of many Android projects will likely ensure Mesa Vulkan
builds consistently in AOSP (plan is to use ANGLE for GLES).  We
have some Android.bp files 

Re: [Mesa-dev] [PATCH] egl/android: Enable HAL_PIXEL_FORMAT_RGBA_FP16 format

[Gurchetan Singh]

Thanks for the patch and review, merged!

On Thu, Aug 29, 2019 at 3:45 AM Tapani Pälli  wrote:
>
> Reviewed-by: Tapani Pälli 
>
> On 8/29/19 12:18 AM, Nataraj Deshpande wrote:
> > The patch adds support for 64 bit HAL_PIXEL_FORMAT_RGBA_FP16
> > for android platform.
> >
> > Fixes android.graphics.cts.BitmapColorSpaceTest#test16bitHardware
> > which failed in egl due to "Unsupported native buffer format 0x16"
> > on chromebooks.
> >
> > Change-Id: I44f886fce27fe5f738d2dc229eed8b59088cf6d6
> > Signed-off-by: Nataraj Deshpande 
> > ---
> >   src/egl/drivers/dri2/platform_android.c | 5 +
> >   1 file changed, 5 insertions(+)
> >
> > diff --git a/src/egl/drivers/dri2/platform_android.c 
> > b/src/egl/drivers/dri2/platform_android.c
> > index 601b29e..97e7947 100644
> > --- a/src/egl/drivers/dri2/platform_android.c
> > +++ b/src/egl/drivers/dri2/platform_android.c
> > @@ -109,6 +109,9 @@ get_format_bpp(int native)
> >  int bpp;
> >
> >  switch (native) {
> > +   case HAL_PIXEL_FORMAT_RGBA_FP16:
> > +  bpp = 8;
> > +  break;
> >  case HAL_PIXEL_FORMAT_RGBA_:
> >  case HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED:
> > /*
> > @@ -143,6 +146,7 @@ static int get_fourcc(int native)
> >  * TODO: Remove this once https://issuetracker.google.com/32077885 
> > is fixed.
> >  */
> >  case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FOURCC_XBGR;
> > +   case HAL_PIXEL_FORMAT_RGBA_FP16: return 
> > __DRI_IMAGE_FOURCC_ABGR16161616F;
> >  default:
> > _eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", 
> > native);
> >  }
> > @@ -161,6 +165,7 @@ static int get_format(int format)
> >  * TODO: Revert this once https://issuetracker.google.com/32077885 
> > is fixed.
> >  */
> >  case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FORMAT_XBGR;
> > +   case HAL_PIXEL_FORMAT_RGBA_FP16: return 
> > __DRI_IMAGE_FORMAT_ABGR16161616F;
> >  default:
> > _eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", 
> > format);
> >  }
> >
> ___
> 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] virgl: close drm fd when destroying virgl screen.

[Gurchetan Singh]

On Mon, Apr 1, 2019 at 12:39 PM Lepton Wu  wrote:

>
> On Wed, Mar 20, 2019 at 2:26 PM Chia-I Wu  wrote:
>
>> Reviewed-by: Chia-I Wu 
>>
> Anything else to need for merging this? I think this is a straightforward
> leaking fix.
>

Merged.  Thanks for the patch and review!


>
>
>>
>> On Mon, Mar 18, 2019 at 4:40 PM Lepton Wu  wrote:
>>
>>> This fd was create in virgl_drm_screen_create and should be closed
>>> in virgl_drm_screen_destroy.
>>>
>>> Signed-off-by: Lepton Wu 
>>> ---
>>>  src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
>>> b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
>>> index 01811a0e997..5501fe3ed48 100644
>>> --- a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
>>> +++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
>>> @@ -973,6 +973,7 @@ virgl_drm_screen_destroy(struct pipe_screen *pscreen)
>>> if (destroy) {
>>>int fd = virgl_drm_winsys(screen->vws)->fd;
>>>util_hash_table_remove(fd_tab, intptr_to_pointer(fd));
>>> +  close(fd);
>>> }
>>> mtx_unlock(_screen_mutex);
>>>
>>> --
>>> 2.21.0.225.g810b269d1ac-goog
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/util: Fix off-by-one in box intersection

[Gurchetan Singh]

On Thu, Feb 28, 2019 at 8:15 PM Roland Scheidegger  wrote:
>
> Am 01.03.19 um 00:28 schrieb Gurchetan Singh:
> > On Thu, Feb 28, 2019 at 12:39 AM Boris Brezillon
> >  wrote:
> >>
> >> Hello Gurchetan,
> >>
> >> On Wed, 27 Feb 2019 10:34:26 -0800
> >> Gurchetan Singh  wrote:
> >>
> >>> On Mon, Feb 25, 2019 at 12:35 AM Boris Brezillon
> >>>  wrote:
> >>>>
> >>>> From: Daniel Stone 
> >>>>
> >>>> pipe_boxes are x/y + width/height, rather than x0/y0 -> x1/y1. This
> >>>> means that (x+width) is not included in the box.
> >>>>
> >>>> The box intersection check was seemingly written for inclusive regions,
> >>>> and would falsely assert that adjacent boxes would overlap.
> >>>>
> >>>> Fix the off-by-one by being one pixel less greedy.
> >>>
> >>> Is there a reason for this change?  I only see this used in a warning
> >>> in the nine state tracker and virgl (where reporting adjacent
> >>> intersections is preferred).
> >>
> >> This patch was part of a series Daniel worked on to optimize texture
> >> atlas updates on Vivante GPUs [1]. In the end, this work has been put
> >> on hold because the perf optimization was not as high as expected, but
> >> it might be resurrected at some point.
> >> Anyway, back to the point. In this patchset, the pipe_region_overlaps()
> >> helper needs to check when regions overlap and not when they're
> >> adjacent. If other users need u_box_test_intersection_2d() to also
> >> detect when boxes are adjacent, then we should definitely keep the code
> >> unchanged, but maybe it's worth a comment in the code to clarify the
> >> behavior.
> >
> > Thanks for the information.  You can just modify this function to be
> > something like:
> >
> > u_box_test_intersection_2d(const struct pipe_box *a, const struct
> > pipe_box *b, boolean adjacent_allowed)
> >
> > [or add another function --- whatever you prefer]
> >
> > That way we can keep behavior for virgl/nine unchanged.
>
> I can't see why you'd want to know if the regions are adjacent?
> If they are adjacent you can still do blits etc. without having to worry
> about overwriting src regions etc.
> Now for 1d regions (buffers) I could see adjacent being useful - could
> use that to combine multiple ranges into one for instance. But I don't
> think you'd want to use a 2d intersect test for that...

virgl piggybacks off u_box_test_intersection_2d to do 1d adjacency +
intersection tests.  If the preferred approach is to split off an
u_box_test_intersection_1d function, that sounds fine.

>
> Roland
>
>
>
> >
> >>
> >> Regards,
> >>
> >> Boris
> >>
> >> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.collabora.com%2Fbbrezillon%2Fmesa%2Fcommits%2Fetna-texture-atlas-18.2.4data=02%7C01%7Csroland%40vmware.com%7Ce72daea7c212452556f208d69dd47aa1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636869933286320567sdata=lHnhl1gM19Gt%2FU3KVv%2FlpBgPXFoSl4BqwZ93yHgbbRQ%3Dreserved=0
> >>
> >>>
> >>>>
> >>>> Signed-off-by: Daniel Stone 
> >>>> Signed-off-by: Boris Brezillon 
> >>>> ---
> >>>>  src/gallium/auxiliary/util/u_box.h | 16 
> >>>>  1 file changed, 8 insertions(+), 8 deletions(-)
> >>>>
> >>>> diff --git a/src/gallium/auxiliary/util/u_box.h 
> >>>> b/src/gallium/auxiliary/util/u_box.h
> >>>> index b3f478e7bfc4..ead7189ecaf8 100644
> >>>> --- a/src/gallium/auxiliary/util/u_box.h
> >>>> +++ b/src/gallium/auxiliary/util/u_box.h
> >>>> @@ -161,15 +161,15 @@ u_box_test_intersection_2d(const struct pipe_box 
> >>>> *a,
> >>>> unsigned i;
> >>>> int a_l[2], a_r[2], b_l[2], b_r[2];
> >>>>
> >>>> -   a_l[0] = MIN2(a->x, a->x + a->width);
> >>>> -   a_r[0] = MAX2(a->x, a->x + a->width);
> >>>> -   a_l[1] = MIN2(a->y, a->y + a->height);
> >>>> -   a_r[1] = MAX2(a->y, a->y + a->height);
> >>>> +   a_l[0] = MIN2(a->x, a->x + a->width - 1);
> >>>> +   a_r[0] = MAX2(a->x, a->x + a->width - 1);
> >>>> +   a_l[1] = MIN2(a->y, a->y + a->height - 1);
> >>>> +   a_r[1] = MAX2(a->y, a-&g

Re: [Mesa-dev] [PATCH] gallium/util: Fix off-by-one in box intersection

[Gurchetan Singh]

On Thu, Feb 28, 2019 at 12:39 AM Boris Brezillon
 wrote:
>
> Hello Gurchetan,
>
> On Wed, 27 Feb 2019 10:34:26 -0800
> Gurchetan Singh  wrote:
>
> > On Mon, Feb 25, 2019 at 12:35 AM Boris Brezillon
> >  wrote:
> > >
> > > From: Daniel Stone 
> > >
> > > pipe_boxes are x/y + width/height, rather than x0/y0 -> x1/y1. This
> > > means that (x+width) is not included in the box.
> > >
> > > The box intersection check was seemingly written for inclusive regions,
> > > and would falsely assert that adjacent boxes would overlap.
> > >
> > > Fix the off-by-one by being one pixel less greedy.
> >
> > Is there a reason for this change?  I only see this used in a warning
> > in the nine state tracker and virgl (where reporting adjacent
> > intersections is preferred).
>
> This patch was part of a series Daniel worked on to optimize texture
> atlas updates on Vivante GPUs [1]. In the end, this work has been put
> on hold because the perf optimization was not as high as expected, but
> it might be resurrected at some point.
> Anyway, back to the point. In this patchset, the pipe_region_overlaps()
> helper needs to check when regions overlap and not when they're
> adjacent. If other users need u_box_test_intersection_2d() to also
> detect when boxes are adjacent, then we should definitely keep the code
> unchanged, but maybe it's worth a comment in the code to clarify the
> behavior.

Thanks for the information.  You can just modify this function to be
something like:

u_box_test_intersection_2d(const struct pipe_box *a, const struct
pipe_box *b, boolean adjacent_allowed)

[or add another function --- whatever you prefer]

That way we can keep behavior for virgl/nine unchanged.

>
> Regards,
>
> Boris
>
> [1]https://gitlab.collabora.com/bbrezillon/mesa/commits/etna-texture-atlas-18.2.4
>
> >
> > >
> > > Signed-off-by: Daniel Stone 
> > > Signed-off-by: Boris Brezillon 
> > > ---
> > >  src/gallium/auxiliary/util/u_box.h | 16 
> > >  1 file changed, 8 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/src/gallium/auxiliary/util/u_box.h 
> > > b/src/gallium/auxiliary/util/u_box.h
> > > index b3f478e7bfc4..ead7189ecaf8 100644
> > > --- a/src/gallium/auxiliary/util/u_box.h
> > > +++ b/src/gallium/auxiliary/util/u_box.h
> > > @@ -161,15 +161,15 @@ u_box_test_intersection_2d(const struct pipe_box *a,
> > > unsigned i;
> > > int a_l[2], a_r[2], b_l[2], b_r[2];
> > >
> > > -   a_l[0] = MIN2(a->x, a->x + a->width);
> > > -   a_r[0] = MAX2(a->x, a->x + a->width);
> > > -   a_l[1] = MIN2(a->y, a->y + a->height);
> > > -   a_r[1] = MAX2(a->y, a->y + a->height);
> > > +   a_l[0] = MIN2(a->x, a->x + a->width - 1);
> > > +   a_r[0] = MAX2(a->x, a->x + a->width - 1);
> > > +   a_l[1] = MIN2(a->y, a->y + a->height - 1);
> > > +   a_r[1] = MAX2(a->y, a->y + a->height - 1);
> > >
> > > -   b_l[0] = MIN2(b->x, b->x + b->width);
> > > -   b_r[0] = MAX2(b->x, b->x + b->width);
> > > -   b_l[1] = MIN2(b->y, b->y + b->height);
> > > -   b_r[1] = MAX2(b->y, b->y + b->height);
> > > +   b_l[0] = MIN2(b->x, b->x + b->width - 1);
> > > +   b_r[0] = MAX2(b->x, b->x + b->width - 1);
> > > +   b_l[1] = MIN2(b->y, b->y + b->height - 1);
> > > +   b_r[1] = MAX2(b->y, b->y + b->height - 1);
> > >
> > > for (i = 0; i < 2; ++i) {
> > >if (a_l[i] > b_r[i] || a_r[i] < b_l[i])
> > > --
> > > 2.20.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] gallium/util: Fix off-by-one in box intersection

[Gurchetan Singh]

On Mon, Feb 25, 2019 at 12:35 AM Boris Brezillon
 wrote:
>
> From: Daniel Stone 
>
> pipe_boxes are x/y + width/height, rather than x0/y0 -> x1/y1. This
> means that (x+width) is not included in the box.
>
> The box intersection check was seemingly written for inclusive regions,
> and would falsely assert that adjacent boxes would overlap.
>
> Fix the off-by-one by being one pixel less greedy.

Is there a reason for this change?  I only see this used in a warning
in the nine state tracker and virgl (where reporting adjacent
intersections is preferred).

>
> Signed-off-by: Daniel Stone 
> Signed-off-by: Boris Brezillon 
> ---
>  src/gallium/auxiliary/util/u_box.h | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_box.h 
> b/src/gallium/auxiliary/util/u_box.h
> index b3f478e7bfc4..ead7189ecaf8 100644
> --- a/src/gallium/auxiliary/util/u_box.h
> +++ b/src/gallium/auxiliary/util/u_box.h
> @@ -161,15 +161,15 @@ u_box_test_intersection_2d(const struct pipe_box *a,
> unsigned i;
> int a_l[2], a_r[2], b_l[2], b_r[2];
>
> -   a_l[0] = MIN2(a->x, a->x + a->width);
> -   a_r[0] = MAX2(a->x, a->x + a->width);
> -   a_l[1] = MIN2(a->y, a->y + a->height);
> -   a_r[1] = MAX2(a->y, a->y + a->height);
> +   a_l[0] = MIN2(a->x, a->x + a->width - 1);
> +   a_r[0] = MAX2(a->x, a->x + a->width - 1);
> +   a_l[1] = MIN2(a->y, a->y + a->height - 1);
> +   a_r[1] = MAX2(a->y, a->y + a->height - 1);
>
> -   b_l[0] = MIN2(b->x, b->x + b->width);
> -   b_r[0] = MAX2(b->x, b->x + b->width);
> -   b_l[1] = MIN2(b->y, b->y + b->height);
> -   b_r[1] = MAX2(b->y, b->y + b->height);
> +   b_l[0] = MIN2(b->x, b->x + b->width - 1);
> +   b_r[0] = MAX2(b->x, b->x + b->width - 1);
> +   b_l[1] = MIN2(b->y, b->y + b->height - 1);
> +   b_r[1] = MAX2(b->y, b->y + b->height - 1);
>
> for (i = 0; i < 2; ++i) {
>if (a_l[i] > b_r[i] || a_r[i] < b_l[i])
> --
> 2.20.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 10/12] virgl: modify how we handle GL_MAP_FLUSH_EXPLICIT_BIT

[Gurchetan Singh]

On Tue, Dec 11, 2018 at 2:49 PM Elie Tournier 
wrote:

> On Mon, Dec 10, 2018 at 10:20:36AM -0800, Gurchetan Singh wrote:
> > Previously, we ignored the the glUnmap(..) operation and
> > flushed before we flush the cbuf.  Now, let's just flush
> > the data when we unmap.
> >
> > Neither method is optimal, for example:
> >
> > glMapBufferRange(.., 0, 100, GL_MAP_FLUSH_EXPLICIT_BIT)
> > glFlushMappedBufferRange(.., 25, 30)
> > glFlushMappedBufferRange(.., 65, 70)
> >
> > We'll end up flushing 25 --> 70.  Maybe we can fix this later.
> >
> > v2: Add fixme comment in the code (Elie)
> Thanks.
> I still have to run some regressions tests. They are a bit slow on my
> system.
> So for now, the series is:
> Acked-by: Elie Tournier 
>

Thanks!  When your tests are complete, I posted a slightly updated series
on Gitlab:

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/25


> > ---
> >  src/gallium/drivers/virgl/virgl_buffer.c   | 46 +++---
> >  src/gallium/drivers/virgl/virgl_context.c  | 34 +---
> >  src/gallium/drivers/virgl/virgl_context.h  |  1 -
> >  src/gallium/drivers/virgl/virgl_resource.h | 13 --
> >  4 files changed, 25 insertions(+), 69 deletions(-)
> >
> > diff --git a/src/gallium/drivers/virgl/virgl_buffer.c
> b/src/gallium/drivers/virgl/virgl_buffer.c
> > index d5d728735e..a20deab549 100644
> > --- a/src/gallium/drivers/virgl/virgl_buffer.c
> > +++ b/src/gallium/drivers/virgl/virgl_buffer.c
> > @@ -33,7 +33,6 @@ static void virgl_buffer_destroy(struct pipe_screen
> *screen,
> > struct virgl_screen *vs = virgl_screen(screen);
> > struct virgl_buffer *vbuf = virgl_buffer(buf);
> >
> > -   util_range_destroy(>valid_buffer_range);
> > vs->vws->resource_unref(vs->vws, vbuf->base.hw_res);
> > FREE(vbuf);
> >  }
> > @@ -53,7 +52,7 @@ static void *virgl_buffer_transfer_map(struct
> pipe_context *ctx,
> > bool readback;
> > bool doflushwait = false;
> >
> > -   if ((usage & PIPE_TRANSFER_READ) && (vbuf->on_list == TRUE))
> > +   if (usage & PIPE_TRANSFER_READ)
> >doflushwait = true;
> > else
> >doflushwait = virgl_res_needs_flush_wait(vctx, >base,
> usage);
> > @@ -92,13 +91,19 @@ static void virgl_buffer_transfer_unmap(struct
> pipe_context *ctx,
> > struct virgl_buffer *vbuf = virgl_buffer(transfer->resource);
> >
> > if (trans->base.usage & PIPE_TRANSFER_WRITE) {
> > -  if (!(transfer->usage & PIPE_TRANSFER_FLUSH_EXPLICIT)) {
> > - struct virgl_screen *vs = virgl_screen(ctx->screen);
> > - vctx->num_transfers++;
> > - vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
> > -   >box, trans->base.stride,
> trans->base.layer_stride, trans->offset, transfer->level);
> > -
> > +  struct virgl_screen *vs = virgl_screen(ctx->screen);
> > +  if (transfer->usage & PIPE_TRANSFER_FLUSH_EXPLICIT) {
> > + transfer->box.x += trans->range.start;
> > + transfer->box.width = trans->range.end - trans->range.start;
> > + trans->offset = transfer->box.x;
> >}
> > +
> > +  vctx->num_transfers++;
> > +  vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
> > +>box, trans->base.stride,
> > +trans->base.layer_stride, trans->offset,
> > +transfer->level);
> > +
> > }
> >
> > virgl_resource_destroy_transfer(vctx, trans);
> > @@ -108,20 +113,19 @@ static void
> virgl_buffer_transfer_flush_region(struct pipe_context *ctx,
> > struct pipe_transfer
> *transfer,
> > const struct pipe_box
> *box)
> >  {
> > -   struct virgl_context *vctx = virgl_context(ctx);
> > struct virgl_buffer *vbuf = virgl_buffer(transfer->resource);
> > +   struct virgl_transfer *trans = virgl_transfer(transfer);
> >
> > -   if (!vbuf->on_list) {
> > -   struct pipe_resource *res = NULL;
> > -
> > -   list_addtail(>flush_list, >to_flush_bufs);
> > -   vbuf->on_list = TRUE;
> > -   pipe_resource_reference(, >base.u.b);
> > -   }
> > -
> > -   util_range_add(>valid_buffer_range, transfer->box.x + box->x,
> > -  transfer->box.x + 

Re: [Mesa-dev] [PATCH] virgl: force linear texturing support

[Gurchetan Singh]

On Mon, Dec 10, 2018 at 7:05 AM Erik Faye-Lund 
wrote:

> When I made sure that half-float texture-filtering was required for ES3,
> I didn't realize that virgl doesn't report support for this correctly.
> This regressed the GLES version available on top of several drivers,
> including i965 from 3.2 to 2.0.
>
> This is going to need protocol changes to fix properly, so let's just
> restore the previous behavior by enabling floating-point filtering
> unconditionally for now.
>
> Signed-off-by: Erik Faye-Lund 
> Fixes: fcf9fcee3c8 "mesa/main: do not require float-texture filtering for
> es3"
> ---
>  src/gallium/drivers/virgl/virgl_screen.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_screen.c
> b/src/gallium/drivers/virgl/virgl_screen.c
> index 3d6424e39f6..b32c061491c 100644
> --- a/src/gallium/drivers/virgl/virgl_screen.c
> +++ b/src/gallium/drivers/virgl/virgl_screen.c
> @@ -255,6 +255,9 @@ virgl_get_param(struct pipe_screen *screen, enum
> pipe_cap param)
>return vscreen->caps.caps.v2.max_combined_atomic_counters;
> case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER_BUFFERS:
>return vscreen->caps.caps.v2.max_combined_atomic_counter_buffers;
> +   case PIPE_CAP_TEXTURE_FLOAT_LINEAR:
> +   case PIPE_CAP_TEXTURE_HALF_FLOAT_LINEAR:
> +  return 1; /* TODO: need to introduce a hw-cap for this */
> case PIPE_CAP_TEXTURE_GATHER_SM5:
> case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
> case PIPE_CAP_FAKE_SW_MSAA:
> @@ -267,8 +270,6 @@ virgl_get_param(struct pipe_screen *screen, enum
> pipe_cap param)
> case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
> case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
> case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
> -   case PIPE_CAP_TEXTURE_FLOAT_LINEAR:
> -   case PIPE_CAP_TEXTURE_HALF_FLOAT_LINEAR:
>     case PIPE_CAP_DEPTH_BOUNDS_TEST:
> case PIPE_CAP_SHAREABLE_SHADERS:
> case PIPE_CAP_CLEAR_TEXTURE:
>


Reviewed-by: Gurchetan Singh gurchetansi...@chromium.org


> --
> 2.19.2
>
> ___
> 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 10/12] virgl: modify how we handle GL_MAP_FLUSH_EXPLICIT_BIT

[Gurchetan Singh]

Previously, we ignored the the glUnmap(..) operation and
flushed before we flush the cbuf.  Now, let's just flush
the data when we unmap.

Neither method is optimal, for example:

glMapBufferRange(.., 0, 100, GL_MAP_FLUSH_EXPLICIT_BIT)
glFlushMappedBufferRange(.., 25, 30)
glFlushMappedBufferRange(.., 65, 70)

We'll end up flushing 25 --> 70.  Maybe we can fix this later.

v2: Add fixme comment in the code (Elie)
---
 src/gallium/drivers/virgl/virgl_buffer.c   | 46 +++---
 src/gallium/drivers/virgl/virgl_context.c  | 34 +---
 src/gallium/drivers/virgl/virgl_context.h  |  1 -
 src/gallium/drivers/virgl/virgl_resource.h | 13 --
 4 files changed, 25 insertions(+), 69 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
b/src/gallium/drivers/virgl/virgl_buffer.c
index d5d728735e..a20deab549 100644
--- a/src/gallium/drivers/virgl/virgl_buffer.c
+++ b/src/gallium/drivers/virgl/virgl_buffer.c
@@ -33,7 +33,6 @@ static void virgl_buffer_destroy(struct pipe_screen *screen,
struct virgl_screen *vs = virgl_screen(screen);
struct virgl_buffer *vbuf = virgl_buffer(buf);
 
-   util_range_destroy(>valid_buffer_range);
vs->vws->resource_unref(vs->vws, vbuf->base.hw_res);
FREE(vbuf);
 }
@@ -53,7 +52,7 @@ static void *virgl_buffer_transfer_map(struct pipe_context 
*ctx,
bool readback;
bool doflushwait = false;
 
-   if ((usage & PIPE_TRANSFER_READ) && (vbuf->on_list == TRUE))
+   if (usage & PIPE_TRANSFER_READ)
   doflushwait = true;
else
   doflushwait = virgl_res_needs_flush_wait(vctx, >base, usage);
@@ -92,13 +91,19 @@ static void virgl_buffer_transfer_unmap(struct pipe_context 
*ctx,
struct virgl_buffer *vbuf = virgl_buffer(transfer->resource);
 
if (trans->base.usage & PIPE_TRANSFER_WRITE) {
-  if (!(transfer->usage & PIPE_TRANSFER_FLUSH_EXPLICIT)) {
- struct virgl_screen *vs = virgl_screen(ctx->screen);
- vctx->num_transfers++;
- vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
-   >box, trans->base.stride, 
trans->base.layer_stride, trans->offset, transfer->level);
-
+  struct virgl_screen *vs = virgl_screen(ctx->screen);
+  if (transfer->usage & PIPE_TRANSFER_FLUSH_EXPLICIT) {
+ transfer->box.x += trans->range.start;
+ transfer->box.width = trans->range.end - trans->range.start;
+ trans->offset = transfer->box.x;
   }
+
+  vctx->num_transfers++;
+  vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
+>box, trans->base.stride,
+trans->base.layer_stride, trans->offset,
+transfer->level);
+
}
 
virgl_resource_destroy_transfer(vctx, trans);
@@ -108,20 +113,19 @@ static void virgl_buffer_transfer_flush_region(struct 
pipe_context *ctx,
struct pipe_transfer *transfer,
const struct pipe_box *box)
 {
-   struct virgl_context *vctx = virgl_context(ctx);
struct virgl_buffer *vbuf = virgl_buffer(transfer->resource);
+   struct virgl_transfer *trans = virgl_transfer(transfer);
 
-   if (!vbuf->on_list) {
-   struct pipe_resource *res = NULL;
-
-   list_addtail(>flush_list, >to_flush_bufs);
-   vbuf->on_list = TRUE;
-   pipe_resource_reference(, >base.u.b);
-   }
-
-   util_range_add(>valid_buffer_range, transfer->box.x + box->x,
-  transfer->box.x + box->x + box->width);
-
+   /*
+* FIXME: This is not optimal.  For example,
+*
+* glMapBufferRange(.., 0, 100, GL_MAP_FLUSH_EXPLICIT_BIT)
+* glFlushMappedBufferRange(.., 25, 30)
+* glFlushMappedBufferRange(.., 65, 70)
+*
+* We'll end up flushing 25 --> 70.
+*/
+   util_range_add(>range, box->x, box->x + box->width);
vbuf->base.clean = FALSE;
 }
 
@@ -145,7 +149,6 @@ struct pipe_resource *virgl_buffer_create(struct 
virgl_screen *vs,
buf->base.u.b.screen = >base;
buf->base.u.vtbl = _buffer_vtbl;
pipe_reference_init(>base.u.b.reference, 1);
-   util_range_init(>valid_buffer_range);
virgl_resource_layout(>base.u.b, >metadata);
 
vbind = pipe_to_virgl_bind(template->bind);
@@ -155,6 +158,5 @@ struct pipe_resource *virgl_buffer_create(struct 
virgl_screen *vs,
template->width0, 1, 1, 1, 0, 0,
buf->metadata.total_size);
 
-   util_range_set_empty(>valid_buffer_range);
return >base.u.b;
 }
diff --git a/src/gallium/drivers/virgl/virgl_context.c 
b/src/gallium/drivers/virgl/virgl_context.c
index 90a9429fa5..a92fd6115a 100644
--- a/src/gallium/drivers/virgl/virgl_context.c
+++ b/src/gallium/drivers/virgl/virgl_context.c
@@ -54,29 +54,6 @@ uint32_t virgl_object_assign_handle(void)
return ++next_handle;
 }
 
-static void virgl_buffer_flush(struct virgl_context *vctx,
-  struct virgl_buffer *vbuf)
-{
-   

Re: [Mesa-dev] [PATCH 10/12] virgl: modify how we handle GL_MAP_FLUSH_EXPLICIT_BIT

[Gurchetan Singh]

On Mon, Dec 10, 2018 at 7:35 AM Elie Tournier 
wrote:

> On Thu, Dec 06, 2018 at 05:20:42PM -0800, Gurchetan Singh wrote:
> > Previously, we ignored the the glUnmap(..) operation and
> > flushed before we flush the cbuf.  Now, let's just flush
> > the data when we unmap.
> >
> > Neither method is optimal, for example:
> >
> > glMapBufferRange(.., 0, 100, GL_MAP_FLUSH_EXPLICIT_BIT)
> > glFlushMappedBufferRange(.., 25, 30)
> > glFlushMappedBufferRange(.., 65, 70)
> >
> > We'll end up flushing 25 --> 70.  Maybe we can fix this later.
> I don't know how to feel about that.
> We clearly go against the spec.
>
> We currently know the behavor of this piece of code but in few
> months, someone will facing the issue and loose lots of time.
>

I agree, the problem is the kernel transfer API
(drm_virtgpu_3d_transfer_to_host) doesn't pass usage flags
(PIPE_TRANSFER_FLUSH_EXPLICIT) such that the host can use
GL_MAP_FLUSH_EXPLICIT_BIT.  The best method is to use the virgl protocol to
encode the transfer.  This series is a self-contained cleanup for that:

https://gitlab.freedesktop.org/gurchetansingh/mesa/tree/optimize-transfers

In the meantime, I'll add big comment.


> I would prefer that we fix it now.
> If we decide to still upstream that code, we should at least add
> a big warning.
>






> > ---
> >  src/gallium/drivers/virgl/virgl_buffer.c   | 37 +-
> >  src/gallium/drivers/virgl/virgl_context.c  | 34 +---
> >  src/gallium/drivers/virgl/virgl_context.h  |  1 -
> >  src/gallium/drivers/virgl/virgl_resource.h | 13 
> >  4 files changed, 16 insertions(+), 69 deletions(-)
> >
> > diff --git a/src/gallium/drivers/virgl/virgl_buffer.c
> b/src/gallium/drivers/virgl/virgl_buffer.c
> > index d5d728735e..ae828446ec 100644
> > --- a/src/gallium/drivers/virgl/virgl_buffer.c
> > +++ b/src/gallium/drivers/virgl/virgl_buffer.c
> > @@ -33,7 +33,6 @@ static void virgl_buffer_destroy(struct pipe_screen
> *screen,
> > struct virgl_screen *vs = virgl_screen(screen);
> > struct virgl_buffer *vbuf = virgl_buffer(buf);
> >
> > -   util_range_destroy(>valid_buffer_range);
> > vs->vws->resource_unref(vs->vws, vbuf->base.hw_res);
> > FREE(vbuf);
> >  }
> > @@ -53,7 +52,7 @@ static void *virgl_buffer_transfer_map(struct
> pipe_context *ctx,
> > bool readback;
> > bool doflushwait = false;
> >
> > -   if ((usage & PIPE_TRANSFER_READ) && (vbuf->on_list == TRUE))
> > +   if (usage & PIPE_TRANSFER_READ)
> >doflushwait = true;
> > else
> >doflushwait = virgl_res_needs_flush_wait(vctx, >base,
> usage);
> > @@ -92,13 +91,19 @@ static void virgl_buffer_transfer_unmap(struct
> pipe_context *ctx,
> > struct virgl_buffer *vbuf = virgl_buffer(transfer->resource);
> >
> > if (trans->base.usage & PIPE_TRANSFER_WRITE) {
> > -  if (!(transfer->usage & PIPE_TRANSFER_FLUSH_EXPLICIT)) {
> > - struct virgl_screen *vs = virgl_screen(ctx->screen);
> > - vctx->num_transfers++;
> > - vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
> > -   >box, trans->base.stride,
> trans->base.layer_stride, trans->offset, transfer->level);
> > -
> > +  struct virgl_screen *vs = virgl_screen(ctx->screen);
> > +  if (transfer->usage & PIPE_TRANSFER_FLUSH_EXPLICIT) {
> > + transfer->box.x += trans->range.start;
> > + transfer->box.width = trans->range.end - trans->range.start;
> > + trans->offset = transfer->box.x;
> >}
> > +
> > +  vctx->num_transfers++;
> > +  vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
> > +>box, trans->base.stride,
> > +trans->base.layer_stride, trans->offset,
> > +transfer->level);
> > +
> > }
> >
> > virgl_resource_destroy_transfer(vctx, trans);
> > @@ -108,20 +113,10 @@ static void
> virgl_buffer_transfer_flush_region(struct pipe_context *ctx,
> > struct pipe_transfer
> *transfer,
> > const struct pipe_box
> *box)
> >  {
> > -   struct virgl_context *vctx = virgl_context(ctx);
> > struct virgl_buffer *vbuf = virgl_buffer(transfer->resource);
> > +   struct virgl_transfer *trans = virgl_transfer(transfer);
> >

[Mesa-dev] [PATCH 11/12] virgl: move resource metadata into base resource

[Gurchetan Singh]

A resource is just a buffer with some metadata.
---
 src/gallium/drivers/virgl/virgl_buffer.c   | 51 +++--
 src/gallium/drivers/virgl/virgl_context.c  |  5 +-
 src/gallium/drivers/virgl/virgl_resource.h | 21 +-
 src/gallium/drivers/virgl/virgl_texture.c  | 85 +++---
 4 files changed, 71 insertions(+), 91 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
b/src/gallium/drivers/virgl/virgl_buffer.c
index ae828446ec..4c545be63a 100644
--- a/src/gallium/drivers/virgl/virgl_buffer.c
+++ b/src/gallium/drivers/virgl/virgl_buffer.c
@@ -31,9 +31,9 @@ static void virgl_buffer_destroy(struct pipe_screen *screen,
  struct pipe_resource *buf)
 {
struct virgl_screen *vs = virgl_screen(screen);
-   struct virgl_buffer *vbuf = virgl_buffer(buf);
+   struct virgl_resource *vbuf = virgl_resource(buf);
 
-   vs->vws->resource_unref(vs->vws, vbuf->base.hw_res);
+   vs->vws->resource_unref(vs->vws, vbuf->hw_res);
FREE(vbuf);
 }
 
@@ -46,7 +46,7 @@ static void *virgl_buffer_transfer_map(struct pipe_context 
*ctx,
 {
struct virgl_context *vctx = virgl_context(ctx);
struct virgl_screen *vs = virgl_screen(ctx->screen);
-   struct virgl_buffer *vbuf = virgl_buffer(resource);
+   struct virgl_resource *vbuf = virgl_resource(resource);
struct virgl_transfer *trans;
void *ptr;
bool readback;
@@ -55,7 +55,7 @@ static void *virgl_buffer_transfer_map(struct pipe_context 
*ctx,
if (usage & PIPE_TRANSFER_READ)
   doflushwait = true;
else
-  doflushwait = virgl_res_needs_flush_wait(vctx, >base, usage);
+  doflushwait = virgl_res_needs_flush_wait(vctx, vbuf, usage);
 
if (doflushwait)
   ctx->flush(ctx, NULL, 0);
@@ -63,18 +63,18 @@ static void *virgl_buffer_transfer_map(struct pipe_context 
*ctx,
trans = virgl_resource_create_transfer(ctx, resource, >metadata, 
level,
   usage, box);
 
-   readback = virgl_res_needs_readback(vctx, >base, usage);
+   readback = virgl_res_needs_readback(vctx, vbuf, usage);
if (readback)
-  vs->vws->transfer_get(vs->vws, vbuf->base.hw_res, box, 
trans->base.stride,
+  vs->vws->transfer_get(vs->vws, vbuf->hw_res, box, trans->base.stride,
 trans->base.layer_stride, trans->offset, level);
 
if (!(usage & PIPE_TRANSFER_UNSYNCHRONIZED))
   doflushwait = true;
 
if (doflushwait || readback)
-  vs->vws->resource_wait(vs->vws, vbuf->base.hw_res);
+  vs->vws->resource_wait(vs->vws, vbuf->hw_res);
 
-   ptr = vs->vws->resource_map(vs->vws, vbuf->base.hw_res);
+   ptr = vs->vws->resource_map(vs->vws, vbuf->hw_res);
if (!ptr) {
   return NULL;
}
@@ -88,7 +88,7 @@ static void virgl_buffer_transfer_unmap(struct pipe_context 
*ctx,
 {
struct virgl_context *vctx = virgl_context(ctx);
struct virgl_transfer *trans = virgl_transfer(transfer);
-   struct virgl_buffer *vbuf = virgl_buffer(transfer->resource);
+   struct virgl_resource *vbuf = virgl_resource(transfer->resource);
 
if (trans->base.usage & PIPE_TRANSFER_WRITE) {
   struct virgl_screen *vs = virgl_screen(ctx->screen);
@@ -99,7 +99,7 @@ static void virgl_buffer_transfer_unmap(struct pipe_context 
*ctx,
   }
 
   vctx->num_transfers++;
-  vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
+  vs->vws->transfer_put(vs->vws, vbuf->hw_res,
 >box, trans->base.stride,
 trans->base.layer_stride, trans->offset,
 transfer->level);
@@ -113,11 +113,11 @@ static void virgl_buffer_transfer_flush_region(struct 
pipe_context *ctx,
struct pipe_transfer *transfer,
const struct pipe_box *box)
 {
-   struct virgl_buffer *vbuf = virgl_buffer(transfer->resource);
+   struct virgl_resource *vbuf = virgl_resource(transfer->resource);
struct virgl_transfer *trans = virgl_transfer(transfer);
 
util_range_add(>range, box->x, box->x + box->width);
-   vbuf->base.clean = FALSE;
+   vbuf->clean = FALSE;
 }
 
 static const struct u_resource_vtbl virgl_buffer_vtbl =
@@ -132,22 +132,21 @@ static const struct u_resource_vtbl virgl_buffer_vtbl =
 struct pipe_resource *virgl_buffer_create(struct virgl_screen *vs,
   const struct pipe_resource *template)
 {
-   struct virgl_buffer *buf;
+   struct virgl_resource *buf;
uint32_t vbind;
-   buf = CALLOC_STRUCT(virgl_buffer);
-   buf->base.clean = TRUE;
-   buf->base.u.b = *template;
-   buf->base.u.b.screen = >base;
-   buf->base.u.vtbl = _buffer_vtbl;
-   pipe_reference_init(>base.u.b.reference, 1);
-   virgl_resource_layout(>base.u.b, >metadata);
+   buf = CALLOC_STRUCT(virgl_resource);
+   buf->clean = TRUE;
+   buf->u.b = *template;
+   buf->u.b.screen = >base;
+   buf->u.vtbl = _buffer_vtbl;
+   pipe_reference_init(>u.b.reference, 1);
+   

[Mesa-dev] [PATCH 12/12] virgl: move resource creation / import / destruction to common code

[Gurchetan Singh]

We can remove some duplicated code.
---
 src/gallium/drivers/virgl/virgl_buffer.c   | 33 +
 src/gallium/drivers/virgl/virgl_resource.c | 84 +++---
 src/gallium/drivers/virgl/virgl_resource.h | 16 ++---
 src/gallium/drivers/virgl/virgl_texture.c  | 70 ++
 4 files changed, 89 insertions(+), 114 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
b/src/gallium/drivers/virgl/virgl_buffer.c
index 4c545be63a..5d446907c3 100644
--- a/src/gallium/drivers/virgl/virgl_buffer.c
+++ b/src/gallium/drivers/virgl/virgl_buffer.c
@@ -27,16 +27,6 @@
 #include "virgl_resource.h"
 #include "virgl_screen.h"
 
-static void virgl_buffer_destroy(struct pipe_screen *screen,
- struct pipe_resource *buf)
-{
-   struct virgl_screen *vs = virgl_screen(screen);
-   struct virgl_resource *vbuf = virgl_resource(buf);
-
-   vs->vws->resource_unref(vs->vws, vbuf->hw_res);
-   FREE(vbuf);
-}
-
 static void *virgl_buffer_transfer_map(struct pipe_context *ctx,
struct pipe_resource *resource,
unsigned level,
@@ -123,30 +113,13 @@ static void virgl_buffer_transfer_flush_region(struct 
pipe_context *ctx,
 static const struct u_resource_vtbl virgl_buffer_vtbl =
 {
u_default_resource_get_handle,/* get_handle */
-   virgl_buffer_destroy, /* resource_destroy */
+   virgl_resource_destroy,   /* resource_destroy */
virgl_buffer_transfer_map,/* transfer_map */
virgl_buffer_transfer_flush_region,   /* transfer_flush_region */
virgl_buffer_transfer_unmap,  /* transfer_unmap */
 };
 
-struct pipe_resource *virgl_buffer_create(struct virgl_screen *vs,
-  const struct pipe_resource *template)
+void virgl_buffer_init(struct virgl_resource *res)
 {
-   struct virgl_resource *buf;
-   uint32_t vbind;
-   buf = CALLOC_STRUCT(virgl_resource);
-   buf->clean = TRUE;
-   buf->u.b = *template;
-   buf->u.b.screen = >base;
-   buf->u.vtbl = _buffer_vtbl;
-   pipe_reference_init(>u.b.reference, 1);
-   virgl_resource_layout(>u.b, >metadata);
-
-   vbind = pipe_to_virgl_bind(template->bind);
-
-   buf->hw_res = vs->vws->resource_create(vs->vws, template->target,
-  template->format, vbind,
-  template->width0, 1, 1, 1, 0, 0,
-  buf->metadata.total_size);
-   return >u.b;
+   res->u.vtbl = _buffer_vtbl;
 }
diff --git a/src/gallium/drivers/virgl/virgl_resource.c 
b/src/gallium/drivers/virgl/virgl_resource.c
index a0b28e1d02..bcfd527abf 100644
--- a/src/gallium/drivers/virgl/virgl_resource.c
+++ b/src/gallium/drivers/virgl/virgl_resource.c
@@ -22,6 +22,7 @@
  */
 #include "util/u_format.h"
 #include "util/u_inlines.h"
+#include "util/u_memory.h"
 #include "virgl_context.h"
 #include "virgl_resource.h"
 #include "virgl_screen.h"
@@ -56,11 +57,37 @@ bool virgl_res_needs_readback(struct virgl_context *vctx,
 static struct pipe_resource *virgl_resource_create(struct pipe_screen *screen,
const struct pipe_resource 
*templ)
 {
-struct virgl_screen *vs = virgl_screen(screen);
-if (templ->target == PIPE_BUFFER)
-return virgl_buffer_create(vs, templ);
-else
-return virgl_texture_create(vs, templ);
+   unsigned vbind;
+   struct virgl_screen *vs = virgl_screen(screen);
+   struct virgl_resource *res = CALLOC_STRUCT(virgl_resource);
+
+   res->clean = TRUE;
+   res->u.b = *templ;
+   res->u.b.screen = >base;
+   pipe_reference_init(>u.b.reference, 1);
+   vbind = pipe_to_virgl_bind(templ->bind);
+   virgl_resource_layout(>u.b, >metadata);
+   res->hw_res = vs->vws->resource_create(vs->vws, templ->target,
+  templ->format, vbind,
+  templ->width0,
+  templ->height0,
+  templ->depth0,
+  templ->array_size,
+  templ->last_level,
+  templ->nr_samples,
+  res->metadata.total_size);
+   if (!res->hw_res) {
+  FREE(res);
+  return NULL;
+   }
+
+   if (templ->target == PIPE_BUFFER)
+  virgl_buffer_init(res);
+   else
+  virgl_texture_init(res);
+
+   return >u.b;
+
 }
 
 static struct pipe_resource *virgl_resource_from_handle(struct pipe_screen 
*screen,
@@ -68,11 +95,24 @@ static struct pipe_resource 
*virgl_resource_from_handle(struct pipe_screen *scre
 struct winsys_handle 
*whandle,
 unsigned usage)
 {
-struct virgl_screen *vs = 

[Mesa-dev] [PATCH 10/12] virgl: modify how we handle GL_MAP_FLUSH_EXPLICIT_BIT

[Gurchetan Singh]

Previously, we ignored the the glUnmap(..) operation and
flushed before we flush the cbuf.  Now, let's just flush
the data when we unmap.

Neither method is optimal, for example:

glMapBufferRange(.., 0, 100, GL_MAP_FLUSH_EXPLICIT_BIT)
glFlushMappedBufferRange(.., 25, 30)
glFlushMappedBufferRange(.., 65, 70)

We'll end up flushing 25 --> 70.  Maybe we can fix this later.
---
 src/gallium/drivers/virgl/virgl_buffer.c   | 37 +-
 src/gallium/drivers/virgl/virgl_context.c  | 34 +---
 src/gallium/drivers/virgl/virgl_context.h  |  1 -
 src/gallium/drivers/virgl/virgl_resource.h | 13 
 4 files changed, 16 insertions(+), 69 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
b/src/gallium/drivers/virgl/virgl_buffer.c
index d5d728735e..ae828446ec 100644
--- a/src/gallium/drivers/virgl/virgl_buffer.c
+++ b/src/gallium/drivers/virgl/virgl_buffer.c
@@ -33,7 +33,6 @@ static void virgl_buffer_destroy(struct pipe_screen *screen,
struct virgl_screen *vs = virgl_screen(screen);
struct virgl_buffer *vbuf = virgl_buffer(buf);
 
-   util_range_destroy(>valid_buffer_range);
vs->vws->resource_unref(vs->vws, vbuf->base.hw_res);
FREE(vbuf);
 }
@@ -53,7 +52,7 @@ static void *virgl_buffer_transfer_map(struct pipe_context 
*ctx,
bool readback;
bool doflushwait = false;
 
-   if ((usage & PIPE_TRANSFER_READ) && (vbuf->on_list == TRUE))
+   if (usage & PIPE_TRANSFER_READ)
   doflushwait = true;
else
   doflushwait = virgl_res_needs_flush_wait(vctx, >base, usage);
@@ -92,13 +91,19 @@ static void virgl_buffer_transfer_unmap(struct pipe_context 
*ctx,
struct virgl_buffer *vbuf = virgl_buffer(transfer->resource);
 
if (trans->base.usage & PIPE_TRANSFER_WRITE) {
-  if (!(transfer->usage & PIPE_TRANSFER_FLUSH_EXPLICIT)) {
- struct virgl_screen *vs = virgl_screen(ctx->screen);
- vctx->num_transfers++;
- vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
-   >box, trans->base.stride, 
trans->base.layer_stride, trans->offset, transfer->level);
-
+  struct virgl_screen *vs = virgl_screen(ctx->screen);
+  if (transfer->usage & PIPE_TRANSFER_FLUSH_EXPLICIT) {
+ transfer->box.x += trans->range.start;
+ transfer->box.width = trans->range.end - trans->range.start;
+ trans->offset = transfer->box.x;
   }
+
+  vctx->num_transfers++;
+  vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
+>box, trans->base.stride,
+trans->base.layer_stride, trans->offset,
+transfer->level);
+
}
 
virgl_resource_destroy_transfer(vctx, trans);
@@ -108,20 +113,10 @@ static void virgl_buffer_transfer_flush_region(struct 
pipe_context *ctx,
struct pipe_transfer *transfer,
const struct pipe_box *box)
 {
-   struct virgl_context *vctx = virgl_context(ctx);
struct virgl_buffer *vbuf = virgl_buffer(transfer->resource);
+   struct virgl_transfer *trans = virgl_transfer(transfer);
 
-   if (!vbuf->on_list) {
-   struct pipe_resource *res = NULL;
-
-   list_addtail(>flush_list, >to_flush_bufs);
-   vbuf->on_list = TRUE;
-   pipe_resource_reference(, >base.u.b);
-   }
-
-   util_range_add(>valid_buffer_range, transfer->box.x + box->x,
-  transfer->box.x + box->x + box->width);
-
+   util_range_add(>range, box->x, box->x + box->width);
vbuf->base.clean = FALSE;
 }
 
@@ -145,7 +140,6 @@ struct pipe_resource *virgl_buffer_create(struct 
virgl_screen *vs,
buf->base.u.b.screen = >base;
buf->base.u.vtbl = _buffer_vtbl;
pipe_reference_init(>base.u.b.reference, 1);
-   util_range_init(>valid_buffer_range);
virgl_resource_layout(>base.u.b, >metadata);
 
vbind = pipe_to_virgl_bind(template->bind);
@@ -155,6 +149,5 @@ struct pipe_resource *virgl_buffer_create(struct 
virgl_screen *vs,
template->width0, 1, 1, 1, 0, 0,
buf->metadata.total_size);
 
-   util_range_set_empty(>valid_buffer_range);
return >base.u.b;
 }
diff --git a/src/gallium/drivers/virgl/virgl_context.c 
b/src/gallium/drivers/virgl/virgl_context.c
index 90a9429fa5..a92fd6115a 100644
--- a/src/gallium/drivers/virgl/virgl_context.c
+++ b/src/gallium/drivers/virgl/virgl_context.c
@@ -54,29 +54,6 @@ uint32_t virgl_object_assign_handle(void)
return ++next_handle;
 }
 
-static void virgl_buffer_flush(struct virgl_context *vctx,
-  struct virgl_buffer *vbuf)
-{
-   struct virgl_screen *rs = virgl_screen(vctx->base.screen);
-   struct pipe_box box;
-
-   assert(vbuf->on_list);
-
-   box.height = 1;
-   box.depth = 1;
-   box.y = 0;
-   box.z = 0;
-
-   box.x = vbuf->valid_buffer_range.start;
-   box.width = MIN2(vbuf->valid_buffer_range.end - 

[Mesa-dev] [PATCH 09/12] virgl: make virgl_buffers use resource helpers

[Gurchetan Singh]

We reuse the helpers we created.
---
 src/gallium/drivers/virgl/virgl_buffer.c   | 28 +++---
 src/gallium/drivers/virgl/virgl_resource.h |  1 +
 2 files changed, 10 insertions(+), 19 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
b/src/gallium/drivers/virgl/virgl_buffer.c
index d810e9e986..d5d728735e 100644
--- a/src/gallium/drivers/virgl/virgl_buffer.c
+++ b/src/gallium/drivers/virgl/virgl_buffer.c
@@ -51,7 +51,6 @@ static void *virgl_buffer_transfer_map(struct pipe_context 
*ctx,
struct virgl_transfer *trans;
void *ptr;
bool readback;
-   uint32_t offset;
bool doflushwait = false;
 
if ((usage & PIPE_TRANSFER_READ) && (vbuf->on_list == TRUE))
@@ -62,22 +61,13 @@ static void *virgl_buffer_transfer_map(struct pipe_context 
*ctx,
if (doflushwait)
   ctx->flush(ctx, NULL, 0);
 
-   trans = slab_alloc(>transfer_pool);
-   if (!trans)
-  return NULL;
-
-   trans->base.resource = resource;
-   trans->base.level = level;
-   trans->base.usage = usage;
-   trans->base.box = *box;
-   trans->base.stride = 0;
-   trans->base.layer_stride = 0;
-
-   offset = box->x;
+   trans = virgl_resource_create_transfer(ctx, resource, >metadata, 
level,
+  usage, box);
 
readback = virgl_res_needs_readback(vctx, >base, usage);
if (readback)
-  vs->vws->transfer_get(vs->vws, vbuf->base.hw_res, box, 
trans->base.stride, trans->base.layer_stride, offset, level);
+  vs->vws->transfer_get(vs->vws, vbuf->base.hw_res, box, 
trans->base.stride,
+trans->base.layer_stride, trans->offset, level);
 
if (!(usage & PIPE_TRANSFER_UNSYNCHRONIZED))
   doflushwait = true;
@@ -90,9 +80,7 @@ static void *virgl_buffer_transfer_map(struct pipe_context 
*ctx,
   return NULL;
}
 
-   trans->offset = offset;
*transfer = >base;
-
return ptr + trans->offset;
 }
 
@@ -150,7 +138,6 @@ struct pipe_resource *virgl_buffer_create(struct 
virgl_screen *vs,
   const struct pipe_resource *template)
 {
struct virgl_buffer *buf;
-   uint32_t size;
uint32_t vbind;
buf = CALLOC_STRUCT(virgl_buffer);
buf->base.clean = TRUE;
@@ -159,11 +146,14 @@ struct pipe_resource *virgl_buffer_create(struct 
virgl_screen *vs,
buf->base.u.vtbl = _buffer_vtbl;
pipe_reference_init(>base.u.b.reference, 1);
util_range_init(>valid_buffer_range);
+   virgl_resource_layout(>base.u.b, >metadata);
 
vbind = pipe_to_virgl_bind(template->bind);
-   size = template->width0;
 
-   buf->base.hw_res = vs->vws->resource_create(vs->vws, template->target, 
template->format, vbind, template->width0, 1, 1, 1, 0, 0, size);
+   buf->base.hw_res = vs->vws->resource_create(vs->vws, template->target,
+   template->format, vbind,
+   template->width0, 1, 1, 1, 0, 0,
+   buf->metadata.total_size);
 
util_range_set_empty(>valid_buffer_range);
return >base.u.b;
diff --git a/src/gallium/drivers/virgl/virgl_resource.h 
b/src/gallium/drivers/virgl/virgl_resource.h
index 82016741ec..fa985494a7 100644
--- a/src/gallium/drivers/virgl/virgl_resource.h
+++ b/src/gallium/drivers/virgl/virgl_resource.h
@@ -65,6 +65,7 @@ struct virgl_buffer {
 * the unsynchronized map flag and expect the driver to figure it out.
 */
struct util_range valid_buffer_range;
+   struct virgl_resource_metadata metadata;
 };
 
 struct virgl_texture {
-- 
2.18.1

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

[Mesa-dev] [PATCH 05/12] virgl: move vrend_get_tex_image_offset to common code

[Gurchetan Singh]

Will be reused.
---
 src/gallium/drivers/virgl/virgl_resource.c | 24 +++
 src/gallium/drivers/virgl/virgl_resource.h |  3 +++
 src/gallium/drivers/virgl/virgl_texture.c  | 27 +-
 3 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_resource.c 
b/src/gallium/drivers/virgl/virgl_resource.c
index 4608ad0361..b252be1ba3 100644
--- a/src/gallium/drivers/virgl/virgl_resource.c
+++ b/src/gallium/drivers/virgl/virgl_resource.c
@@ -147,3 +147,27 @@ void virgl_resource_layout(struct pipe_resource *pt,
else /* don't create guest backing store for MSAA */
   metadata->total_size = 0;
 }
+
+unsigned virgl_resource_offset(struct pipe_resource *pres,
+   struct virgl_resource_metadata *metadata,
+   unsigned level, unsigned layer)
+{
+   const unsigned hgt = u_minify(pres->height0, level);
+   const unsigned nblocksy = util_format_get_nblocksy(pres->format, hgt);
+   unsigned offset = metadata->level_offset[level];
+
+   if (pres->target == PIPE_TEXTURE_CUBE ||
+   pres->target == PIPE_TEXTURE_CUBE_ARRAY ||
+   pres->target == PIPE_TEXTURE_3D ||
+   pres->target == PIPE_TEXTURE_2D_ARRAY) {
+  offset += layer * nblocksy * metadata->stride[level];
+   }
+   else if (pres->target == PIPE_TEXTURE_1D_ARRAY) {
+  offset += layer * metadata->stride[level];
+   }
+   else {
+  assert(layer == 0);
+   }
+
+   return offset;
+}
diff --git a/src/gallium/drivers/virgl/virgl_resource.h 
b/src/gallium/drivers/virgl/virgl_resource.h
index df53465251..1a43e5ddc5 100644
--- a/src/gallium/drivers/virgl/virgl_resource.h
+++ b/src/gallium/drivers/virgl/virgl_resource.h
@@ -154,4 +154,7 @@ bool virgl_res_needs_readback(struct virgl_context *vctx,
 void virgl_resource_layout(struct pipe_resource *pt,
struct virgl_resource_metadata *metadata);
 
+unsigned virgl_resource_offset(struct pipe_resource *pres,
+   struct virgl_resource_metadata *metadata,
+   unsigned level, unsigned layer);
 #endif
diff --git a/src/gallium/drivers/virgl/virgl_texture.c 
b/src/gallium/drivers/virgl/virgl_texture.c
index 7eba476ff3..c9d8e541f7 100644
--- a/src/gallium/drivers/virgl/virgl_texture.c
+++ b/src/gallium/drivers/virgl/virgl_texture.c
@@ -94,31 +94,6 @@ static void virgl_init_temp_resource_from_box(struct 
pipe_resource *res,
}
 }
 
-static unsigned
-vrend_get_tex_image_offset(const struct virgl_texture *res,
-   unsigned level, unsigned layer)
-{
-   const struct pipe_resource *pres = >base.u.b;
-   const unsigned hgt = u_minify(pres->height0, level);
-   const unsigned nblocksy = util_format_get_nblocksy(pres->format, hgt);
-   unsigned offset = res->metadata.level_offset[level];
-
-   if (pres->target == PIPE_TEXTURE_CUBE ||
-   pres->target == PIPE_TEXTURE_CUBE_ARRAY ||
-   pres->target == PIPE_TEXTURE_3D ||
-   pres->target == PIPE_TEXTURE_2D_ARRAY) {
-  offset += layer * nblocksy * res->metadata.stride[level];
-   }
-   else if (pres->target == PIPE_TEXTURE_1D_ARRAY) {
-  offset += layer * res->metadata.stride[level];
-   }
-   else {
-  assert(layer == 0);
-   }
-
-   return offset;
-}
-
 static void *virgl_texture_transfer_map(struct pipe_context *ctx,
 struct pipe_resource *resource,
 unsigned level,
@@ -179,7 +154,7 @@ static void *virgl_texture_transfer_map(struct pipe_context 
*ctx,
   trans->base.stride = ((struct 
virgl_texture*)trans->resolve_tmp)->metadata.stride[level];
   trans->base.layer_stride = trans->base.stride * nblocksy;
} else {
-  offset = vrend_get_tex_image_offset(vtex, level, box->z);
+  offset = virgl_resource_offset(>base.u.b, >metadata, level, 
box->z);
 
   offset += box->y / util_format_get_blockheight(format) * 
trans->base.stride +
   box->x / util_format_get_blockwidth(format) * 
util_format_get_blocksize(format);
-- 
2.18.1

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

[Mesa-dev] [PATCH 07/12] virgl: consolidate transfer code

[Gurchetan Singh]

We could allocate and destroy transfers in one place.
---
 src/gallium/drivers/virgl/virgl_buffer.c   |  2 +-
 src/gallium/drivers/virgl/virgl_resource.c | 47 +++---
 src/gallium/drivers/virgl/virgl_resource.h | 14 --
 src/gallium/drivers/virgl/virgl_texture.c  | 58 +-
 src/gallium/drivers/virgl/virgl_texture.h  |  0
 5 files changed, 63 insertions(+), 58 deletions(-)
 create mode 100644 src/gallium/drivers/virgl/virgl_texture.h

diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
b/src/gallium/drivers/virgl/virgl_buffer.c
index 7112bcbcfc..d810e9e986 100644
--- a/src/gallium/drivers/virgl/virgl_buffer.c
+++ b/src/gallium/drivers/virgl/virgl_buffer.c
@@ -113,7 +113,7 @@ static void virgl_buffer_transfer_unmap(struct pipe_context 
*ctx,
   }
}
 
-   slab_free(>transfer_pool, trans);
+   virgl_resource_destroy_transfer(vctx, trans);
 }
 
 static void virgl_buffer_transfer_flush_region(struct pipe_context *ctx,
diff --git a/src/gallium/drivers/virgl/virgl_resource.c 
b/src/gallium/drivers/virgl/virgl_resource.c
index fa589187f8..ccbb67889e 100644
--- a/src/gallium/drivers/virgl/virgl_resource.c
+++ b/src/gallium/drivers/virgl/virgl_resource.c
@@ -149,24 +149,55 @@ void virgl_resource_layout(struct pipe_resource *pt,
   metadata->total_size = 0;
 }
 
-unsigned virgl_resource_offset(struct pipe_resource *pres,
-   struct virgl_resource_metadata *metadata,
-   unsigned level, unsigned layer)
+struct virgl_transfer *
+virgl_resource_create_transfer(struct pipe_context *ctx,
+   struct pipe_resource *pres,
+   const struct virgl_resource_metadata *metadata,
+   unsigned level, unsigned usage,
+   const struct pipe_box *box)
 {
-   unsigned offset = metadata->level_offset[level];
+   struct virgl_transfer *trans;
+   enum pipe_format format = pres->format;
+   struct virgl_context *vctx = virgl_context(ctx);
+   const unsigned blocksy = box->y / util_format_get_blockheight(format);
+   const unsigned blocksx = box->x / util_format_get_blockwidth(format);
 
+   unsigned offset = metadata->level_offset[level];
if (pres->target == PIPE_TEXTURE_CUBE ||
pres->target == PIPE_TEXTURE_CUBE_ARRAY ||
pres->target == PIPE_TEXTURE_3D ||
pres->target == PIPE_TEXTURE_2D_ARRAY) {
-  offset += layer * metadata->layer_stride[level];
+  offset += box->z * metadata->layer_stride[level];
}
else if (pres->target == PIPE_TEXTURE_1D_ARRAY) {
-  offset += layer * metadata->stride[level];
+  offset += box->z * metadata->stride[level];
}
else {
-  assert(layer == 0);
+  assert(box->z == 0);
}
 
-   return offset;
+   offset += blocksy * metadata->stride[level];
+   offset += blocksx * util_format_get_blocksize(format);
+
+   trans = slab_alloc(>transfer_pool);
+   if (!trans)
+  return NULL;
+
+   trans->base.resource = pres;
+   trans->base.level = level;
+   trans->base.usage = usage;
+   trans->base.box = *box;
+   trans->base.stride = metadata->stride[level];
+   trans->base.layer_stride = metadata->layer_stride[level];
+   trans->offset = offset;
+   util_range_init(>range);
+
+   return trans;
+}
+
+void virgl_resource_destroy_transfer(struct virgl_context *vctx,
+ struct virgl_transfer *trans)
+{
+   util_range_destroy(>range);
+   slab_free(>transfer_pool, trans);
 }
diff --git a/src/gallium/drivers/virgl/virgl_resource.h 
b/src/gallium/drivers/virgl/virgl_resource.h
index 5faedb4786..82016741ec 100644
--- a/src/gallium/drivers/virgl/virgl_resource.h
+++ b/src/gallium/drivers/virgl/virgl_resource.h
@@ -75,6 +75,7 @@ struct virgl_texture {
 struct virgl_transfer {
struct pipe_transfer base;
uint32_t offset;
+   struct util_range range;
struct virgl_resource *resolve_tmp;
 };
 
@@ -155,7 +156,14 @@ bool virgl_res_needs_readback(struct virgl_context *vctx,
 void virgl_resource_layout(struct pipe_resource *pt,
struct virgl_resource_metadata *metadata);
 
-unsigned virgl_resource_offset(struct pipe_resource *pres,
-   struct virgl_resource_metadata *metadata,
-   unsigned level, unsigned layer);
+struct virgl_transfer *
+virgl_resource_create_transfer(struct pipe_context *ctx,
+   struct pipe_resource *pres,
+   const struct virgl_resource_metadata *metadata,
+   unsigned level, unsigned usage,
+   const struct pipe_box *box);
+
+void virgl_resource_destroy_transfer(struct virgl_context *vctx,
+ struct virgl_transfer *trans);
+
 #endif
diff --git a/src/gallium/drivers/virgl/virgl_texture.c 
b/src/gallium/drivers/virgl/virgl_texture.c
index c9d8e541f7..c576807fd9 100644
--- 

[Mesa-dev] [PATCH 08/12] virgl: make transfer code with PIPE_BUFFER targets

[Gurchetan Singh]

util_format_get_blocksize returns 1 for R8 formats (all
PIPE_BUFFERs are R8).
---
 src/gallium/drivers/virgl/virgl_resource.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_resource.c 
b/src/gallium/drivers/virgl/virgl_resource.c
index ccbb67889e..a0b28e1d02 100644
--- a/src/gallium/drivers/virgl/virgl_resource.c
+++ b/src/gallium/drivers/virgl/virgl_resource.c
@@ -171,8 +171,10 @@ virgl_resource_create_transfer(struct pipe_context *ctx,
}
else if (pres->target == PIPE_TEXTURE_1D_ARRAY) {
   offset += box->z * metadata->stride[level];
-   }
-   else {
+  assert(box->y == 0);
+   } else if (pres->target == PIPE_BUFFER) {
+  assert(box->y == 0 && box->z == 0);
+   } else {
   assert(box->z == 0);
}
 
-- 
2.18.1

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

[Mesa-dev] [PATCH 06/12] virgl: store layer_stride in metadata

[Gurchetan Singh]

The ioctls don't even pass this (though they should).

Let's calculate this correctly in one place and then pass it down.

Note -- If anyone is using vtest with protocol version 1 (why?),
then you'll need this host side CL too since the layer stride
is forwarded for non-array textures.

https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/86
---
 src/gallium/drivers/virgl/virgl_resource.c | 11 +--
 src/gallium/drivers/virgl/virgl_resource.h |  1 +
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_resource.c 
b/src/gallium/drivers/virgl/virgl_resource.c
index b252be1ba3..fa589187f8 100644
--- a/src/gallium/drivers/virgl/virgl_resource.c
+++ b/src/gallium/drivers/virgl/virgl_resource.c
@@ -115,7 +115,7 @@ void virgl_init_context_resource_functions(struct 
pipe_context *ctx)
 void virgl_resource_layout(struct pipe_resource *pt,
struct virgl_resource_metadata *metadata)
 {
-   unsigned level;
+   unsigned level, nblocksy;
unsigned width = pt->width0;
unsigned height = pt->height0;
unsigned depth = pt->depth0;
@@ -131,11 +131,12 @@ void virgl_resource_layout(struct pipe_resource *pt,
   else
  slices = pt->array_size;
 
+  nblocksy = util_format_get_nblocksy(pt->format, height);
   metadata->stride[level] = util_format_get_stride(pt->format, width);
+  metadata->layer_stride[level] = nblocksy * metadata->stride[level];
   metadata->level_offset[level] = buffer_size;
 
-  buffer_size += (util_format_get_nblocksy(pt->format, height) *
-  slices * metadata->stride[level]);
+  buffer_size += slices * metadata->layer_stride[level];
 
   width = u_minify(width, 1);
   height = u_minify(height, 1);
@@ -152,15 +153,13 @@ unsigned virgl_resource_offset(struct pipe_resource *pres,
struct virgl_resource_metadata *metadata,
unsigned level, unsigned layer)
 {
-   const unsigned hgt = u_minify(pres->height0, level);
-   const unsigned nblocksy = util_format_get_nblocksy(pres->format, hgt);
unsigned offset = metadata->level_offset[level];
 
if (pres->target == PIPE_TEXTURE_CUBE ||
pres->target == PIPE_TEXTURE_CUBE_ARRAY ||
pres->target == PIPE_TEXTURE_3D ||
pres->target == PIPE_TEXTURE_2D_ARRAY) {
-  offset += layer * nblocksy * metadata->stride[level];
+  offset += layer * metadata->layer_stride[level];
}
else if (pres->target == PIPE_TEXTURE_1D_ARRAY) {
   offset += layer * metadata->stride[level];
diff --git a/src/gallium/drivers/virgl/virgl_resource.h 
b/src/gallium/drivers/virgl/virgl_resource.h
index 1a43e5ddc5..5faedb4786 100644
--- a/src/gallium/drivers/virgl/virgl_resource.h
+++ b/src/gallium/drivers/virgl/virgl_resource.h
@@ -40,6 +40,7 @@ struct virgl_resource_metadata
 {
unsigned long level_offset[VR_MAX_TEXTURE_2D_LEVELS];
unsigned stride[VR_MAX_TEXTURE_2D_LEVELS];
+   unsigned layer_stride[VR_MAX_TEXTURE_2D_LEVELS];
uint32_t total_size;
 };
 
-- 
2.18.1

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

[Mesa-dev] [PATCH 04/12] virgl: move virgl_resource_layout to common code

[Gurchetan Singh]

Will be reused.
---
 src/gallium/drivers/virgl/virgl_resource.c | 37 +++
 src/gallium/drivers/virgl/virgl_resource.h |  4 ++
 src/gallium/drivers/virgl/virgl_texture.c  | 52 +-
 3 files changed, 51 insertions(+), 42 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_resource.c 
b/src/gallium/drivers/virgl/virgl_resource.c
index 9174ec5cbb..4608ad0361 100644
--- a/src/gallium/drivers/virgl/virgl_resource.c
+++ b/src/gallium/drivers/virgl/virgl_resource.c
@@ -20,6 +20,7 @@
  * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
  * USE OR OTHER DEALINGS IN THE SOFTWARE.
  */
+#include "util/u_format.h"
 #include "util/u_inlines.h"
 #include "virgl_context.h"
 #include "virgl_resource.h"
@@ -110,3 +111,39 @@ void virgl_init_context_resource_functions(struct 
pipe_context *ctx)
 ctx->buffer_subdata = virgl_buffer_subdata;
 ctx->texture_subdata = u_default_texture_subdata;
 }
+
+void virgl_resource_layout(struct pipe_resource *pt,
+   struct virgl_resource_metadata *metadata)
+{
+   unsigned level;
+   unsigned width = pt->width0;
+   unsigned height = pt->height0;
+   unsigned depth = pt->depth0;
+   unsigned buffer_size = 0;
+
+   for (level = 0; level <= pt->last_level; level++) {
+  unsigned slices;
+
+  if (pt->target == PIPE_TEXTURE_CUBE)
+ slices = 6;
+  else if (pt->target == PIPE_TEXTURE_3D)
+ slices = depth;
+  else
+ slices = pt->array_size;
+
+  metadata->stride[level] = util_format_get_stride(pt->format, width);
+  metadata->level_offset[level] = buffer_size;
+
+  buffer_size += (util_format_get_nblocksy(pt->format, height) *
+  slices * metadata->stride[level]);
+
+  width = u_minify(width, 1);
+  height = u_minify(height, 1);
+  depth = u_minify(depth, 1);
+   }
+
+   if (pt->nr_samples <= 1)
+  metadata->total_size = buffer_size;
+   else /* don't create guest backing store for MSAA */
+  metadata->total_size = 0;
+}
diff --git a/src/gallium/drivers/virgl/virgl_resource.h 
b/src/gallium/drivers/virgl/virgl_resource.h
index 100e35922c..df53465251 100644
--- a/src/gallium/drivers/virgl/virgl_resource.h
+++ b/src/gallium/drivers/virgl/virgl_resource.h
@@ -150,4 +150,8 @@ bool virgl_res_needs_flush_wait(struct virgl_context *vctx,
 bool virgl_res_needs_readback(struct virgl_context *vctx,
   struct virgl_resource *res,
   unsigned usage);
+
+void virgl_resource_layout(struct pipe_resource *pt,
+   struct virgl_resource_metadata *metadata);
+
 #endif
diff --git a/src/gallium/drivers/virgl/virgl_texture.c 
b/src/gallium/drivers/virgl/virgl_texture.c
index 4d08da548c..7eba476ff3 100644
--- a/src/gallium/drivers/virgl/virgl_texture.c
+++ b/src/gallium/drivers/virgl/virgl_texture.c
@@ -240,45 +240,6 @@ static void virgl_texture_transfer_unmap(struct 
pipe_context *ctx,
slab_free(>transfer_pool, trans);
 }
 
-
-static void
-vrend_resource_layout(struct virgl_texture *res,
-  uint32_t *total_size)
-{
-   struct pipe_resource *pt = >base.u.b;
-   unsigned level;
-   unsigned width = pt->width0;
-   unsigned height = pt->height0;
-   unsigned depth = pt->depth0;
-   unsigned buffer_size = 0;
-
-   for (level = 0; level <= pt->last_level; level++) {
-  unsigned slices;
-
-  if (pt->target == PIPE_TEXTURE_CUBE)
- slices = 6;
-  else if (pt->target == PIPE_TEXTURE_3D)
- slices = depth;
-  else
- slices = pt->array_size;
-
-  res->metadata.stride[level] = util_format_get_stride(pt->format, width);
-  res->metadata.level_offset[level] = buffer_size;
-
-  buffer_size += (util_format_get_nblocksy(pt->format, height) *
-  slices * res->metadata.stride[level]);
-
-  width = u_minify(width, 1);
-  height = u_minify(height, 1);
-  depth = u_minify(depth, 1);
-   }
-
-   if (pt->nr_samples <= 1)
-  *total_size = buffer_size;
-   else /* don't create guest backing store for MSAA */
-  *total_size = 0;
-}
-
 static boolean virgl_texture_get_handle(struct pipe_screen *screen,
  struct pipe_resource *ptex,
  struct winsys_handle *whandle)
@@ -327,7 +288,6 @@ struct pipe_resource *virgl_texture_create(struct 
virgl_screen *vs,
const struct pipe_resource 
*template)
 {
struct virgl_texture *tex;
-   uint32_t size;
unsigned vbind;
 
tex = CALLOC_STRUCT(virgl_texture);
@@ -336,10 +296,18 @@ struct pipe_resource *virgl_texture_create(struct 
virgl_screen *vs,
tex->base.u.b.screen = >base;
pipe_reference_init(>base.u.b.reference, 1);
tex->base.u.vtbl = _texture_vtbl;
-   vrend_resource_layout(tex, );
+   virgl_resource_layout(>base.u.b, >metadata);
 
vbind = pipe_to_virgl_bind(template->bind);
-   

[Mesa-dev] [PATCH 01/12] virgl: texture_transfer_pool --> transfer_pool

[Gurchetan Singh]

It's used for all types of resources.
---
 src/gallium/drivers/virgl/virgl_buffer.c  | 4 ++--
 src/gallium/drivers/virgl/virgl_context.c | 4 ++--
 src/gallium/drivers/virgl/virgl_context.h | 2 +-
 src/gallium/drivers/virgl/virgl_screen.c  | 4 ++--
 src/gallium/drivers/virgl/virgl_screen.h  | 2 +-
 src/gallium/drivers/virgl/virgl_texture.c | 6 +++---
 6 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
b/src/gallium/drivers/virgl/virgl_buffer.c
index f72c93f499..b662e46ccd 100644
--- a/src/gallium/drivers/virgl/virgl_buffer.c
+++ b/src/gallium/drivers/virgl/virgl_buffer.c
@@ -62,7 +62,7 @@ static void *virgl_buffer_transfer_map(struct pipe_context 
*ctx,
if (doflushwait)
   ctx->flush(ctx, NULL, 0);
 
-   trans = slab_alloc(>texture_transfer_pool);
+   trans = slab_alloc(>transfer_pool);
if (!trans)
   return NULL;
 
@@ -113,7 +113,7 @@ static void virgl_buffer_transfer_unmap(struct pipe_context 
*ctx,
   }
}
 
-   slab_free(>texture_transfer_pool, trans);
+   slab_free(>transfer_pool, trans);
 }
 
 static void virgl_buffer_transfer_flush_region(struct pipe_context *ctx,
diff --git a/src/gallium/drivers/virgl/virgl_context.c 
b/src/gallium/drivers/virgl/virgl_context.c
index f0ee64c145..90a9429fa5 100644
--- a/src/gallium/drivers/virgl/virgl_context.c
+++ b/src/gallium/drivers/virgl/virgl_context.c
@@ -1150,7 +1150,7 @@ virgl_context_destroy( struct pipe_context *ctx )
   u_upload_destroy(vctx->uploader);
util_primconvert_destroy(vctx->primconvert);
 
-   slab_destroy_child(>texture_transfer_pool);
+   slab_destroy_child(>transfer_pool);
FREE(vctx);
 }
 
@@ -1292,7 +1292,7 @@ struct pipe_context *virgl_context_create(struct 
pipe_screen *pscreen,
virgl_init_so_functions(vctx);
 
list_inithead(>to_flush_bufs);
-   slab_create_child(>texture_transfer_pool, >texture_transfer_pool);
+   slab_create_child(>transfer_pool, >transfer_pool);
 
vctx->primconvert = util_primconvert_create(>base, 
rs->caps.caps.v1.prim_mask);
vctx->uploader = u_upload_create(>base, 1024 * 1024,
diff --git a/src/gallium/drivers/virgl/virgl_context.h 
b/src/gallium/drivers/virgl/virgl_context.h
index 20988baa3c..4a6cc09ee5 100644
--- a/src/gallium/drivers/virgl/virgl_context.h
+++ b/src/gallium/drivers/virgl/virgl_context.h
@@ -56,7 +56,7 @@ struct virgl_context {
 
struct pipe_framebuffer_state framebuffer;
 
-   struct slab_child_pool texture_transfer_pool;
+   struct slab_child_pool transfer_pool;
 
struct u_upload_mgr *uploader;
 
diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
b/src/gallium/drivers/virgl/virgl_screen.c
index 3d6424e39f..13c2e85e71 100644
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -742,7 +742,7 @@ virgl_destroy_screen(struct pipe_screen *screen)
struct virgl_screen *vscreen = virgl_screen(screen);
struct virgl_winsys *vws = vscreen->vws;
 
-   slab_destroy_parent(>texture_transfer_pool);
+   slab_destroy_parent(>transfer_pool);
 
if (vws)
   vws->destroy(vws);
@@ -782,7 +782,7 @@ virgl_create_screen(struct virgl_winsys *vws)
 
screen->refcnt = 1;
 
-   slab_create_parent(>texture_transfer_pool, sizeof(struct 
virgl_transfer), 16);
+   slab_create_parent(>transfer_pool, sizeof(struct virgl_transfer), 
16);
 
return >base;
 }
diff --git a/src/gallium/drivers/virgl/virgl_screen.h 
b/src/gallium/drivers/virgl/virgl_screen.h
index 719f5166d7..97a656fe8e 100644
--- a/src/gallium/drivers/virgl/virgl_screen.h
+++ b/src/gallium/drivers/virgl/virgl_screen.h
@@ -43,7 +43,7 @@ struct virgl_screen {
 
struct virgl_drm_caps caps;
 
-   struct slab_parent_pool texture_transfer_pool;
+   struct slab_parent_pool transfer_pool;
 
uint32_t sub_ctx_id;
 };
diff --git a/src/gallium/drivers/virgl/virgl_texture.c 
b/src/gallium/drivers/virgl/virgl_texture.c
index 9edf0ced0c..fd13e8a3a5 100644
--- a/src/gallium/drivers/virgl/virgl_texture.c
+++ b/src/gallium/drivers/virgl/virgl_texture.c
@@ -144,7 +144,7 @@ static void *virgl_texture_transfer_map(struct pipe_context 
*ctx,
if (doflushwait)
   ctx->flush(ctx, NULL, 0);
 
-   trans = slab_alloc(>texture_transfer_pool);
+   trans = slab_alloc(>transfer_pool);
if (!trans)
   return NULL;
 
@@ -196,7 +196,7 @@ static void *virgl_texture_transfer_map(struct pipe_context 
*ctx,
 
ptr = vs->vws->resource_map(vs->vws, hw_res);
if (!ptr) {
-  slab_free(>texture_transfer_pool, trans);
+  slab_free(>transfer_pool, trans);
   return NULL;
}
 
@@ -237,7 +237,7 @@ static void virgl_texture_transfer_unmap(struct 
pipe_context *ctx,
if (trans->resolve_tmp)
   pipe_resource_reference((struct pipe_resource **)>resolve_tmp, 
NULL);
 
-   slab_free(>texture_transfer_pool, trans);
+   slab_free(>transfer_pool, trans);
 }
 
 
-- 
2.18.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

[Mesa-dev] [PATCH 03/12] virgl: move texture metadata to common code

[Gurchetan Singh]

Will be reused.
---
 src/gallium/drivers/virgl/virgl_resource.h | 11 ---
 src/gallium/drivers/virgl/virgl_texture.c  | 19 ++-
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_resource.h 
b/src/gallium/drivers/virgl/virgl_resource.h
index 297bc72e19..100e35922c 100644
--- a/src/gallium/drivers/virgl/virgl_resource.h
+++ b/src/gallium/drivers/virgl/virgl_resource.h
@@ -36,6 +36,13 @@ struct winsys_handle;
 struct virgl_screen;
 struct virgl_context;
 
+struct virgl_resource_metadata
+{
+   unsigned long level_offset[VR_MAX_TEXTURE_2D_LEVELS];
+   unsigned stride[VR_MAX_TEXTURE_2D_LEVELS];
+   uint32_t total_size;
+};
+
 struct virgl_resource {
struct u_resource u;
struct virgl_hw_res *hw_res;
@@ -61,9 +68,7 @@ struct virgl_buffer {
 
 struct virgl_texture {
struct virgl_resource base;
-
-   unsigned long level_offset[VR_MAX_TEXTURE_2D_LEVELS];
-   unsigned stride[VR_MAX_TEXTURE_2D_LEVELS];
+   struct virgl_resource_metadata metadata;
 };
 
 struct virgl_transfer {
diff --git a/src/gallium/drivers/virgl/virgl_texture.c 
b/src/gallium/drivers/virgl/virgl_texture.c
index fd13e8a3a5..4d08da548c 100644
--- a/src/gallium/drivers/virgl/virgl_texture.c
+++ b/src/gallium/drivers/virgl/virgl_texture.c
@@ -101,16 +101,16 @@ vrend_get_tex_image_offset(const struct virgl_texture 
*res,
const struct pipe_resource *pres = >base.u.b;
const unsigned hgt = u_minify(pres->height0, level);
const unsigned nblocksy = util_format_get_nblocksy(pres->format, hgt);
-   unsigned offset = res->level_offset[level];
+   unsigned offset = res->metadata.level_offset[level];
 
if (pres->target == PIPE_TEXTURE_CUBE ||
pres->target == PIPE_TEXTURE_CUBE_ARRAY ||
pres->target == PIPE_TEXTURE_3D ||
pres->target == PIPE_TEXTURE_2D_ARRAY) {
-  offset += layer * nblocksy * res->stride[level];
+  offset += layer * nblocksy * res->metadata.stride[level];
}
else if (pres->target == PIPE_TEXTURE_1D_ARRAY) {
-  offset += layer * res->stride[level];
+  offset += layer * res->metadata.stride[level];
}
else {
   assert(layer == 0);
@@ -152,7 +152,7 @@ static void *virgl_texture_transfer_map(struct pipe_context 
*ctx,
trans->base.level = level;
trans->base.usage = usage;
trans->base.box = *box;
-   trans->base.stride = vtex->stride[level];
+   trans->base.stride = vtex->metadata.stride[level];
trans->base.layer_stride = trans->base.stride * nblocksy;
 
if (resource->target != PIPE_TEXTURE_3D &&
@@ -176,7 +176,7 @@ static void *virgl_texture_transfer_map(struct pipe_context 
*ctx,
   /* we want to do a resolve blit into the temporary */
   hw_res = trans->resolve_tmp->hw_res;
   offset = 0;
-  trans->base.stride = ((struct 
virgl_texture*)trans->resolve_tmp)->stride[level];
+  trans->base.stride = ((struct 
virgl_texture*)trans->resolve_tmp)->metadata.stride[level];
   trans->base.layer_stride = trans->base.stride * nblocksy;
} else {
   offset = vrend_get_tex_image_offset(vtex, level, box->z);
@@ -262,11 +262,11 @@ vrend_resource_layout(struct virgl_texture *res,
   else
  slices = pt->array_size;
 
-  res->stride[level] = util_format_get_stride(pt->format, width);
-  res->level_offset[level] = buffer_size;
+  res->metadata.stride[level] = util_format_get_stride(pt->format, width);
+  res->metadata.level_offset[level] = buffer_size;
 
   buffer_size += (util_format_get_nblocksy(pt->format, height) *
-  slices * res->stride[level]);
+  slices * res->metadata.stride[level]);
 
   width = u_minify(width, 1);
   height = u_minify(height, 1);
@@ -286,7 +286,8 @@ static boolean virgl_texture_get_handle(struct pipe_screen 
*screen,
struct virgl_screen *vs = virgl_screen(screen);
struct virgl_texture *vtex = virgl_texture(ptex);
 
-   return vs->vws->resource_get_handle(vs->vws, vtex->base.hw_res, 
vtex->stride[0], whandle);
+   return vs->vws->resource_get_handle(vs->vws, vtex->base.hw_res,
+   vtex->metadata.stride[0], whandle);
 }
 
 static void virgl_texture_destroy(struct pipe_screen *screen,
-- 
2.18.1

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

[Mesa-dev] [PATCH 02/12] virgl: remove unnessecary code

[Gurchetan Singh]

With commit 89b479, we moved to tracking buffer cleanliness
when binding.

TEST=dEQP-GLES31.functional.image_load_store.buffer.load_store.r32ui
---
 src/gallium/drivers/virgl/virgl_buffer.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
b/src/gallium/drivers/virgl/virgl_buffer.c
index b662e46ccd..7112bcbcfc 100644
--- a/src/gallium/drivers/virgl/virgl_buffer.c
+++ b/src/gallium/drivers/virgl/virgl_buffer.c
@@ -163,9 +163,6 @@ struct pipe_resource *virgl_buffer_create(struct 
virgl_screen *vs,
vbind = pipe_to_virgl_bind(template->bind);
size = template->width0;
 
-   /* SSBOs and texture buffers can written to by host compute shaders. */
-   if (vbind == VIRGL_BIND_SHADER_BUFFER || vbind == VIRGL_BIND_SAMPLER_VIEW)
-  buf->base.clean = FALSE;
buf->base.hw_res = vs->vws->resource_create(vs->vws, template->target, 
template->format, vbind, template->width0, 1, 1, 1, 0, 0, size);
 
util_range_set_empty(>valid_buffer_range);
-- 
2.18.1

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

Re: [Mesa-dev] [PATCH 0/7] EGLDevice, take 2.1

[Gurchetan Singh]

On Mon, Dec 3, 2018 at 8:06 AM Emil Velikov 
wrote:

> Hi Gurchetan,
>
> On Thu, 29 Nov 2018 at 23:41, Gurchetan Singh
>  wrote:
> >
> > Does this require libdrm 2.4.95 for virtio-gpu?  With
> > platform_surfaceless, I keep getting "DRI2: failed to find EGLDevice"
> > and the failure is happening in "drmGetDevice2(fd, 0, )".
>
> virtio-gpu should work fine with libdrm-2.4.93, admittedly I did not
> explicitly test it.
> What setup are you using? Can you provide a strace of simple app - say
> es2_info?
>
> Thanks
> Emil
>

Ah, I probably was using an older libdrm than libdrm-2.4.93.  It works now.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] virgl: quadruple command buffer size

[Gurchetan Singh]

Thanks!  Gentle ping for push from committers..
On Mon, Nov 26, 2018 at 11:52 AM Erik Faye-Lund
 wrote:
>
> On Mon, 2018-11-26 at 09:54 -0800, Gurchetan Singh wrote:
> > Tested running WebGL aquarium on Nvidia host (10,000 fishes)
> >
> > This moves us from 7 fps to 9 fps.  After quadrupling, performance
> > gains diminish.
> >
> > v2: Remove change ID (Erik)
> >
> > Tested-By: Gert Wollny 
> >
>
> For the series:
>
> Reviewed-by: Erik Faye-Lund 
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/7] EGLDevice, take 2.1

[Gurchetan Singh]

Does this require libdrm 2.4.95 for virtio-gpu?  With
platform_surfaceless, I keep getting "DRI2: failed to find EGLDevice"
and the failure is happening in "drmGetDevice2(fd, 0, )".On
Sat, Oct 20, 2018 at 11:46 PM Mathias Fröhlich
 wrote:
>
> Hi Emil,
>
> On Wednesday, 3 October 2018 16:02:40 CEST Emil Velikov wrote:
> > This re-spin of the series includes:
> >  - correct flipped asserts
> >  - cosmetic wording/comment fixes
> >  - drop EGL_EXT_platform_device patches (swrast is broken)
> >  - add the EGL_MESA_device_software spec patch
> >
> > At this point we should be pretty much set, so any formal Ack/Rb will
> > be appreciated.
>
> Sure and sorry for the long delay!
>
> Patch #1-#6 is:
> Reviewed-by: Mathias Fröhlich 
>
> The #7 is already reviewed by Dylan, so the series should be complete now.
>
> Thanks for iterating on that.
> And looking forward to the rest of the patches enabling display
> creation from a device!!
>
> best
> Mathias
>
>
> >
> > Thanks
> > Emil
> >
> > Cc: Adam Jackson 
> > Cc: Eric Engestrom 
> > Cc: Mathias Fröhlich 
> >
> > Adam Jackson (1):
> >   specs: Add EGL_MESA_device_software
> >
> > Emil Velikov (6):
> >   egl: add base EGL_EXT_device_base implementation
> >   egl: add EGL_MESA_device_software support
> >   egl: add EGL_EXT_device_drm support
> >   egl: set the EGLDevice when creating a display
> >   egl: enable EGL_EXT_device_{base,enumeration,query}
> >   meson: egl: group dri2 bits separately from haiku
> >
> >  docs/specs/EGL_MESA_device_software.txt |  82 +
> >  src/egl/Makefile.sources|   2 +
> >  src/egl/drivers/dri2/egl_dri2.h |   1 +
> >  src/egl/drivers/dri2/platform_android.c |   9 +
> >  src/egl/drivers/dri2/platform_drm.c |   9 +
> >  src/egl/drivers/dri2/platform_surfaceless.c |  10 +-
> >  src/egl/drivers/dri2/platform_wayland.c |  18 ++
> >  src/egl/drivers/dri2/platform_x11.c |  27 ++
> >  src/egl/drivers/haiku/egl_haiku.cpp |   8 +
> >  src/egl/main/eglapi.c   |  64 
> >  src/egl/main/egldevice.c| 319 
> >  src/egl/main/egldevice.h|  89 ++
> >  src/egl/main/egldisplay.h   |   1 +
> >  src/egl/main/eglentrypoint.h|   4 +
> >  src/egl/main/eglglobals.c   |  12 +-
> >  src/egl/main/eglglobals.h   |   2 +
> >  src/egl/main/egltypedefs.h  |   2 +
> >  src/egl/meson.build |  73 ++---
> >  18 files changed, 692 insertions(+), 40 deletions(-)
> >  create mode 100644 docs/specs/EGL_MESA_device_software.txt
> >  create mode 100644 src/egl/main/egldevice.c
> >  create mode 100644 src/egl/main/egldevice.h
> >
> >
>
>
>
>
> ___
> 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] egl: add missing #include in egldevice.h

[Gurchetan Singh]

Otherwise, I get this error:

main/egldevice.h:54:13: error: ‘NULL’ undeclared (first use in this function)
   dev = NULL;
 ^~~~
with this config:

./autogen.sh --enable-gles1 --enable-gles2 --with-platforms='surfaceless' 
--disable-glx
 --with-dri-drivers="i965" --with-gallium-drivers="" --enable-gbm

v3: Use stddef.h (Matt)
v4: Modify commit message (Eric)

Reviewed-by: Eric Engestrom 
---
 src/egl/main/egldevice.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/main/egldevice.h b/src/egl/main/egldevice.h
index ddcdcd17f5..83a47d5eac 100644
--- a/src/egl/main/egldevice.h
+++ b/src/egl/main/egldevice.h
@@ -31,9 +31,9 @@
 
 
 #include 
+#include 
 #include "egltypedefs.h"
 
-
 #ifdef __cplusplus
 extern "C" {
 #endif
-- 
2.18.1

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

[Mesa-dev] [PATCH] egl: define NULL in egldevice.h

[Gurchetan Singh]

Otherwise, I get this error:

main/egldevice.h:54:13: error: ‘NULL’ undeclared (first use in this function)
   dev = NULL;
 ^~~~
with this config:

./autogen.sh --enable-gles1 --enable-gles2 --with-platforms='surfaceless' 
--disable-glx
 --with-dri-drivers="i965" --with-gallium-drivers="" --enable-gbm

v3: Use stddef.h (Matt)
---
 src/egl/main/egldevice.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/main/egldevice.h b/src/egl/main/egldevice.h
index ddcdcd17f5..83a47d5eac 100644
--- a/src/egl/main/egldevice.h
+++ b/src/egl/main/egldevice.h
@@ -31,9 +31,9 @@
 
 
 #include 
+#include 
 #include "egltypedefs.h"
 
-
 #ifdef __cplusplus
 extern "C" {
 #endif
-- 
2.18.1

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

[Mesa-dev] [PATCH] egl: define NULL in egldevice.h

[Gurchetan Singh]

Otherwise, I get this error:

main/egldevice.h:54:13: error: ‘NULL’ undeclared (first use in this function)
   dev = NULL;
 ^~~~
with this config:

./autogen.sh --enable-gles1 --enable-gles2 --with-platforms='surfaceless' 
--disable-glx
 --with-dri-drivers="i965" --with-gallium-drivers="" --enable-gbm

v2: remove change id
---
 src/egl/main/egldevice.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/egl/main/egldevice.h b/src/egl/main/egldevice.h
index ddcdcd17f5..f161942d26 100644
--- a/src/egl/main/egldevice.h
+++ b/src/egl/main/egldevice.h
@@ -33,6 +33,9 @@
 #include 
 #include "egltypedefs.h"
 
+#ifndef NULL
+#define NULL 0
+#endif
 
 #ifdef __cplusplus
 extern "C" {
-- 
2.18.1

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

[Mesa-dev] [PATCH] egl: define NULL in egldevice.h

[Gurchetan Singh]

Otherwise, I get this error:

main/egldevice.h:54:13: error: ‘NULL’ undeclared (first use in this function)
   dev = NULL;
 ^~~~
with this config:

./autogen.sh --enable-gles1 --enable-gles2 --with-platforms='surfaceless' 
--disable-glx
 --with-dri-drivers="i965" --with-gallium-drivers="" --enable-gbm

Change-Id: I4332bfcfd19aecf239497591507aad921fffedf1
---
 src/egl/main/egldevice.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/egl/main/egldevice.h b/src/egl/main/egldevice.h
index ddcdcd17f5a..f161942d26f 100644
--- a/src/egl/main/egldevice.h
+++ b/src/egl/main/egldevice.h
@@ -33,6 +33,9 @@
 #include 
 #include "egltypedefs.h"
 
+#ifndef NULL
+#define NULL 0
+#endif
 
 #ifdef __cplusplus
 extern "C" {
-- 
2.18.1

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

[Mesa-dev] [PATCH 2/3] virgl: avoid large inline transfers

[Gurchetan Singh]

We flush everytime the command buffer (16 kB) is full, which is
quite costly.

This improves

dEQP-GLES3.performance.buffer.data_upload.function_call.buffer_data.new_buffer.usage_stream_draw

from 111.16 MB/s to 1930.36 MB/s.

In addition, I made the benchmark produce buffers from 0 --> 
VIRGL_MAX_CMDBUF_DWORDS * 4,
and tried ((VIRGL_MAX_CMDBUF_DWORDS * 4) / 2), ((VIRGL_MAX_CMDBUF_DWORDS * 4) / 
4), etc.

I didn't notice any clear differences, so let's just go with the most obvious
heuristic.

Tested-By: Gert Wollny 
---
 src/gallium/drivers/virgl/virgl_resource.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_resource.c 
b/src/gallium/drivers/virgl/virgl_resource.c
index db5e7dd61a..9174ec5cbb 100644
--- a/src/gallium/drivers/virgl/virgl_resource.c
+++ b/src/gallium/drivers/virgl/virgl_resource.c
@@ -95,7 +95,11 @@ static void virgl_buffer_subdata(struct pipe_context *pipe,
   usage |= PIPE_TRANSFER_DISCARD_RANGE;
 
u_box_1d(offset, size, );
-   virgl_transfer_inline_write(pipe, resource, 0, usage, , data, 0, 0);
+
+   if (size >= (VIRGL_MAX_CMDBUF_DWORDS * 4))
+  u_default_buffer_subdata(pipe, resource, usage, offset, size, data);
+   else
+  virgl_transfer_inline_write(pipe, resource, 0, usage, , data, 0, 0);
 }
 
 void virgl_init_context_resource_functions(struct pipe_context *ctx)
-- 
2.18.1

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

[Mesa-dev] [PATCH 3/3] virgl: don't mark buffers as unclean after a write

[Gurchetan Singh]

We can mark the buffer unclean if it's ever bound as a TBO,
SSBO, ABO, or image.

This improves

dEQP-GLES3.performance.buffer.data_upload.function_call.map_buffer_range.new_specified_buffer.flag_write_full.stream_draw

from 9.58 MB/s to 451.17 MB/s.

v2: Track buffer cleanliness as a function of bindings (Ilia).
v3: virgl_modify_clean --> virgl_dirty_res (Erik)

Tested-By: Gert Wollny 
---
 src/gallium/drivers/virgl/virgl_buffer.c |  1 -
 src/gallium/drivers/virgl/virgl_encode.c | 10 ++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
b/src/gallium/drivers/virgl/virgl_buffer.c
index 88a22b56f9..f72c93f499 100644
--- a/src/gallium/drivers/virgl/virgl_buffer.c
+++ b/src/gallium/drivers/virgl/virgl_buffer.c
@@ -106,7 +106,6 @@ static void virgl_buffer_transfer_unmap(struct pipe_context 
*ctx,
if (trans->base.usage & PIPE_TRANSFER_WRITE) {
   if (!(transfer->usage & PIPE_TRANSFER_FLUSH_EXPLICIT)) {
  struct virgl_screen *vs = virgl_screen(ctx->screen);
- vbuf->base.clean = FALSE;
  vctx->num_transfers++;
  vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
>box, trans->base.stride, 
trans->base.layer_stride, trans->offset, transfer->level);
diff --git a/src/gallium/drivers/virgl/virgl_encode.c 
b/src/gallium/drivers/virgl/virgl_encode.c
index 400ba68474..49d95de835 100644
--- a/src/gallium/drivers/virgl/virgl_encode.c
+++ b/src/gallium/drivers/virgl/virgl_encode.c
@@ -61,6 +61,12 @@ static void virgl_encoder_write_res(struct virgl_context 
*ctx,
}
 }
 
+static void virgl_dirty_res(struct virgl_resource *res)
+{
+   if (res)
+  res->clean = FALSE;
+}
+
 int virgl_encode_bind_object(struct virgl_context *ctx,
 uint32_t handle, uint32_t object)
 {
@@ -615,6 +621,7 @@ int virgl_encode_sampler_view(struct virgl_context *ctx,
if (res->u.b.target == PIPE_BUFFER) {
   virgl_encoder_write_dword(ctx->cbuf, state->u.buf.offset / elem_size);
   virgl_encoder_write_dword(ctx->cbuf, (state->u.buf.offset + 
state->u.buf.size) / elem_size - 1);
+  virgl_dirty_res(res);
} else {
   virgl_encoder_write_dword(ctx->cbuf, state->u.tex.first_layer | 
state->u.tex.last_layer << 16);
   virgl_encoder_write_dword(ctx->cbuf, state->u.tex.first_level | 
state->u.tex.last_level << 8);
@@ -949,6 +956,7 @@ int virgl_encode_set_shader_buffers(struct virgl_context 
*ctx,
  virgl_encoder_write_dword(ctx->cbuf, buffers[i].buffer_offset);
  virgl_encoder_write_dword(ctx->cbuf, buffers[i].buffer_size);
  virgl_encoder_write_res(ctx, res);
+ virgl_dirty_res(res);
   } else {
  virgl_encoder_write_dword(ctx->cbuf, 0);
  virgl_encoder_write_dword(ctx->cbuf, 0);
@@ -972,6 +980,7 @@ int virgl_encode_set_hw_atomic_buffers(struct virgl_context 
*ctx,
  virgl_encoder_write_dword(ctx->cbuf, buffers[i].buffer_offset);
  virgl_encoder_write_dword(ctx->cbuf, buffers[i].buffer_size);
  virgl_encoder_write_res(ctx, res);
+ virgl_dirty_res(res);
   } else {
  virgl_encoder_write_dword(ctx->cbuf, 0);
  virgl_encoder_write_dword(ctx->cbuf, 0);
@@ -999,6 +1008,7 @@ int virgl_encode_set_shader_images(struct virgl_context 
*ctx,
  virgl_encoder_write_dword(ctx->cbuf, images[i].u.buf.offset);
  virgl_encoder_write_dword(ctx->cbuf, images[i].u.buf.size);
  virgl_encoder_write_res(ctx, res);
+ virgl_dirty_res(res);
   } else {
  virgl_encoder_write_dword(ctx->cbuf, 0);
  virgl_encoder_write_dword(ctx->cbuf, 0);
-- 
2.18.1

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

[Mesa-dev] [PATCH 1/3] virgl: quadruple command buffer size

[Gurchetan Singh]

Tested running WebGL aquarium on Nvidia host (10,000 fishes)

This moves us from 7 fps to 9 fps.  After quadrupling, performance
gains diminish.

v2: Remove change ID (Erik)

Tested-By: Gert Wollny 
---
 src/gallium/drivers/virgl/virgl_winsys.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_winsys.h 
b/src/gallium/drivers/virgl/virgl_winsys.h
index d13212c5e8..96726b409d 100644
--- a/src/gallium/drivers/virgl/virgl_winsys.h
+++ b/src/gallium/drivers/virgl/virgl_winsys.h
@@ -31,7 +31,7 @@ struct pipe_fence_handle;
 struct winsys_handle;
 struct virgl_hw_res;
 
-#define VIRGL_MAX_CMDBUF_DWORDS (16*1024)
+#define VIRGL_MAX_CMDBUF_DWORDS (64 * 1024)
 
 struct virgl_drm_caps {
union virgl_caps caps;
-- 
2.18.1

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

[Mesa-dev] [PATCH 2/2] virgl: don't mark buffers as unclean after a write

[Gurchetan Singh]

We can mark the buffer unclean if it's ever bound as a TBO,
SSBO, ABO, or image.

This improves

dEQP-GLES3.performance.buffer.data_upload.function_call.map_buffer_range.new_specified_buffer.flag_write_full.stream_draw

from 9.58 MB/s to 451.17 MB/s.

v2: Using buffer bindings to track cleanliness (Ilia).
---
 src/gallium/drivers/virgl/virgl_buffer.c |  1 -
 src/gallium/drivers/virgl/virgl_encode.c | 10 ++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
b/src/gallium/drivers/virgl/virgl_buffer.c
index 88a22b56f9..f72c93f499 100644
--- a/src/gallium/drivers/virgl/virgl_buffer.c
+++ b/src/gallium/drivers/virgl/virgl_buffer.c
@@ -106,7 +106,6 @@ static void virgl_buffer_transfer_unmap(struct pipe_context 
*ctx,
if (trans->base.usage & PIPE_TRANSFER_WRITE) {
   if (!(transfer->usage & PIPE_TRANSFER_FLUSH_EXPLICIT)) {
  struct virgl_screen *vs = virgl_screen(ctx->screen);
- vbuf->base.clean = FALSE;
  vctx->num_transfers++;
  vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
>box, trans->base.stride, 
trans->base.layer_stride, trans->offset, transfer->level);
diff --git a/src/gallium/drivers/virgl/virgl_encode.c 
b/src/gallium/drivers/virgl/virgl_encode.c
index 400ba68474..6483f47031 100644
--- a/src/gallium/drivers/virgl/virgl_encode.c
+++ b/src/gallium/drivers/virgl/virgl_encode.c
@@ -61,6 +61,12 @@ static void virgl_encoder_write_res(struct virgl_context 
*ctx,
}
 }
 
+static void virgl_modify_clean(struct virgl_resource *res, boolean value)
+{
+   if (res)
+  res->clean = value;
+}
+
 int virgl_encode_bind_object(struct virgl_context *ctx,
 uint32_t handle, uint32_t object)
 {
@@ -615,6 +621,7 @@ int virgl_encode_sampler_view(struct virgl_context *ctx,
if (res->u.b.target == PIPE_BUFFER) {
   virgl_encoder_write_dword(ctx->cbuf, state->u.buf.offset / elem_size);
   virgl_encoder_write_dword(ctx->cbuf, (state->u.buf.offset + 
state->u.buf.size) / elem_size - 1);
+  virgl_modify_clean(res, FALSE);
} else {
   virgl_encoder_write_dword(ctx->cbuf, state->u.tex.first_layer | 
state->u.tex.last_layer << 16);
   virgl_encoder_write_dword(ctx->cbuf, state->u.tex.first_level | 
state->u.tex.last_level << 8);
@@ -949,6 +956,7 @@ int virgl_encode_set_shader_buffers(struct virgl_context 
*ctx,
  virgl_encoder_write_dword(ctx->cbuf, buffers[i].buffer_offset);
  virgl_encoder_write_dword(ctx->cbuf, buffers[i].buffer_size);
  virgl_encoder_write_res(ctx, res);
+ virgl_modify_clean(res, FALSE);
   } else {
  virgl_encoder_write_dword(ctx->cbuf, 0);
  virgl_encoder_write_dword(ctx->cbuf, 0);
@@ -972,6 +980,7 @@ int virgl_encode_set_hw_atomic_buffers(struct virgl_context 
*ctx,
  virgl_encoder_write_dword(ctx->cbuf, buffers[i].buffer_offset);
  virgl_encoder_write_dword(ctx->cbuf, buffers[i].buffer_size);
  virgl_encoder_write_res(ctx, res);
+ virgl_modify_clean(res, FALSE);
   } else {
  virgl_encoder_write_dword(ctx->cbuf, 0);
  virgl_encoder_write_dword(ctx->cbuf, 0);
@@ -999,6 +1008,7 @@ int virgl_encode_set_shader_images(struct virgl_context 
*ctx,
  virgl_encoder_write_dword(ctx->cbuf, images[i].u.buf.offset);
  virgl_encoder_write_dword(ctx->cbuf, images[i].u.buf.size);
  virgl_encoder_write_res(ctx, res);
+ virgl_modify_clean(res, FALSE);
   } else {
  virgl_encoder_write_dword(ctx->cbuf, 0);
  virgl_encoder_write_dword(ctx->cbuf, 0);
-- 
2.18.1

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

[Mesa-dev] [PATCH 1/2] virgl: avoid large inline transfers

[Gurchetan Singh]

We flush everytime the command buffer (16 kB) is full, which is
quite costly.

This improves

dEQP-GLES3.performance.buffer.data_upload.function_call.buffer_data.new_buffer.usage_stream_draw

from 111.16 MB/s to 1930.36 MB/s.

In addition, I made the benchmark produce buffers from 0 --> 
VIRGL_MAX_CMDBUF_DWORDS * 4,
and tried ((VIRGL_MAX_CMDBUF_DWORDS * 4) / 2), ((VIRGL_MAX_CMDBUF_DWORDS * 4) / 
4), etc.

I didn't notice any clear differences, so let's just go with the most obvious
heuristic.
---
 src/gallium/drivers/virgl/virgl_resource.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_resource.c 
b/src/gallium/drivers/virgl/virgl_resource.c
index db5e7dd61a..9174ec5cbb 100644
--- a/src/gallium/drivers/virgl/virgl_resource.c
+++ b/src/gallium/drivers/virgl/virgl_resource.c
@@ -95,7 +95,11 @@ static void virgl_buffer_subdata(struct pipe_context *pipe,
   usage |= PIPE_TRANSFER_DISCARD_RANGE;
 
u_box_1d(offset, size, );
-   virgl_transfer_inline_write(pipe, resource, 0, usage, , data, 0, 0);
+
+   if (size >= (VIRGL_MAX_CMDBUF_DWORDS * 4))
+  u_default_buffer_subdata(pipe, resource, usage, offset, size, data);
+   else
+  virgl_transfer_inline_write(pipe, resource, 0, usage, , data, 0, 0);
 }
 
 void virgl_init_context_resource_functions(struct pipe_context *ctx)
-- 
2.18.1

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

[Mesa-dev] [PATCH] virgl: quadruple command buffer size

[Gurchetan Singh]

Tested running WebGL aquarium on Nvidia host (10,000 fishes)

This moves us from 7 fps to 9 fps.  After quadrupling, performance
gains diminish.

Change-Id: Iba3a9929ba2d17cf5a38233b92391dd413b79bc2
---
 src/gallium/drivers/virgl/virgl_winsys.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_winsys.h 
b/src/gallium/drivers/virgl/virgl_winsys.h
index d13212c5e8..96726b409d 100644
--- a/src/gallium/drivers/virgl/virgl_winsys.h
+++ b/src/gallium/drivers/virgl/virgl_winsys.h
@@ -31,7 +31,7 @@ struct pipe_fence_handle;
 struct winsys_handle;
 struct virgl_hw_res;
 
-#define VIRGL_MAX_CMDBUF_DWORDS (16*1024)
+#define VIRGL_MAX_CMDBUF_DWORDS (64 * 1024)
 
 struct virgl_drm_caps {
union virgl_caps caps;
-- 
2.18.1

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

Re: [Mesa-dev] [PATCH] virgl: don't mark buffers as unclean after a write

[Gurchetan Singh]

On Tue, Nov 20, 2018 at 3:34 PM Ilia Mirkin  wrote:
>
> I'm unfamiliar with the surrounding code, but wanted to point out that
> a single buffer may be mapped as a SSBO, UBO, TBO, etc.
> transfer_map/unmap isn't really aware of how the buffer is used. You
> can, however, keep track of such bindings on either the resource or
> the context, and know that buffer X is currently bound as this and
> this but not that.

Good idea, I'll use virgl_set_shader_images / virgl_set_shader_images
/ virgl_set_sampler_views to mark the relevant buffers as dirty.

> Cheers,
>
>   -ilia
> On Tue, Nov 20, 2018 at 6:11 PM Gurchetan Singh
>  wrote:
> >
> > Texture buffers and SSBOs are always unclean, while other buffers
> > are not modified by compute/rendering.
> >
> > This improves
> >
> > dEQP-GLES3.performance.buffer.data_upload.function_call.map_buffer_range.new_specified_buffer.flag_write_full.stream_draw
> >
> > from 9.58 MB/s to 451.17 MB/s.
> >
> > Regression tested using deqp-gles31 suite.
> > ---
> >  src/gallium/drivers/virgl/virgl_buffer.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
> > b/src/gallium/drivers/virgl/virgl_buffer.c
> > index 88a22b56f9..f72c93f499 100644
> > --- a/src/gallium/drivers/virgl/virgl_buffer.c
> > +++ b/src/gallium/drivers/virgl/virgl_buffer.c
> > @@ -106,7 +106,6 @@ static void virgl_buffer_transfer_unmap(struct 
> > pipe_context *ctx,
> > if (trans->base.usage & PIPE_TRANSFER_WRITE) {
> >if (!(transfer->usage & PIPE_TRANSFER_FLUSH_EXPLICIT)) {
> >   struct virgl_screen *vs = virgl_screen(ctx->screen);
> > - vbuf->base.clean = FALSE;
> >   vctx->num_transfers++;
> >   vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
> > >box, trans->base.stride, 
> > trans->base.layer_stride, trans->offset, transfer->level);
> > --
> > 2.18.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] virgl: don't mark buffers as unclean after a write

[Gurchetan Singh]

Texture buffers and SSBOs are always unclean, while other buffers
are not modified by compute/rendering.

This improves

dEQP-GLES3.performance.buffer.data_upload.function_call.map_buffer_range.new_specified_buffer.flag_write_full.stream_draw

from 9.58 MB/s to 451.17 MB/s.

Regression tested using deqp-gles31 suite.
---
 src/gallium/drivers/virgl/virgl_buffer.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
b/src/gallium/drivers/virgl/virgl_buffer.c
index 88a22b56f9..f72c93f499 100644
--- a/src/gallium/drivers/virgl/virgl_buffer.c
+++ b/src/gallium/drivers/virgl/virgl_buffer.c
@@ -106,7 +106,6 @@ static void virgl_buffer_transfer_unmap(struct pipe_context 
*ctx,
if (trans->base.usage & PIPE_TRANSFER_WRITE) {
   if (!(transfer->usage & PIPE_TRANSFER_FLUSH_EXPLICIT)) {
  struct virgl_screen *vs = virgl_screen(ctx->screen);
- vbuf->base.clean = FALSE;
  vctx->num_transfers++;
  vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
>box, trans->base.stride, 
trans->base.layer_stride, trans->offset, transfer->level);
-- 
2.18.1

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

Re: [Mesa-dev] [PATCH v5 2/2] virgl: Pass resource size and transfer offsets

[Gurchetan Singh]

On Fri, Oct 5, 2018 at 1:04 AM Gert Wollny  wrote:
>
> Am Donnerstag, den 04.10.2018, 10:48 -0700 schrieb Gurchetan Singh:
> >
> > The idea is to get rid of any adjustments on both the Mesa /
> > virglrenderer sides -- so transfer size is just what's needed to
> > transfer the box size, and the offset is the just offset into the
> > iovec from which the transfer will start.  For v1, we can just
> > specify an offset of zero on the virglrenderer side.
>
> I certainly see you point, the problem is (as Tomeu also pointed out)
> we would like to enable the CI *now*, and all what is missing is this
> patch. If we want to correct the protocol it will likely take another
> couple of weeks to get it right and do all the testing, and this while
> facing the more challanging changes regarding memory handling, adding
> more GL extensions etc.
>
> > vtest isn't used in production but it will be used in the CI.  Also,
> > it's a simpler model of virgl3d and is useful for experimenting with
> > new protocol additions (hostmap, vulkan).  We should fix this now --
> > it could take a while to disentangle the workarounds should anyone
> > look at this again ...
> My proposal to unblock this would be open an issue against
> virglrenderer (because the problem is on both sides) and doeument there
> where the problems are. Whether this gets fixed by correcting this
> code, or completely replacing things (like Tomeu proposed) is another
> story.
>
> What do you think?

Opening a new issue on the virglrenderer gitlab sounds fine with me.
We shouldn't need to modify the protocol, so maybe that's why I think
it shouldn't take too long, but we can discuss on the bug.

Reviewed-by: Gurchetan Singh 


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

Re: [Mesa-dev] [PATCH v5 2/2] virgl: Pass resource size and transfer offsets

[Gurchetan Singh]

On Thu, Oct 4, 2018 at 7:41 AM Gert Wollny  wrote:
>
> From: Tomeu Vizoso 
>
> Pass the size of a resource when creating it so a backing can be kept in
> the other side.
>
> Also pass the required offset to transfer commands.
>
> This moves vtest closer to how virtio-gpu works, making it more useful
> for testing.
>
> v2: - Use new messages for creation and transfers, as changing the
>   behavior of the existing messages would be messy given that we don't
>   want to break compatibility with older servers.
>
> v3: - Use correct strides: The resource corresponding to the output display
>   might have a differnt line stride then the IOVs, so when reading back
>   to this resource take the resource stride and the the IOV stride
>   into account.
>
> v4: Fix transfer size calculation (Andrey Simiklit)
>
> v5: Add comment about transfer size value in the PUT commend (Gurchetan).
> Add a comment about the size correction for transfers for reading and
> writing the resource. Fixing this by correctly evaluating the size
> upfront will need some work also  on the virglrenderer side.
>
> Signed-off-by: Tomeu Vizoso  (v2)
> Signed-off-by: Gert Wollny 
> ---
>  .../winsys/virgl/vtest/virgl_vtest_socket.c| 144 
> +++--
>  .../winsys/virgl/vtest/virgl_vtest_winsys.c|  44 +--
>  .../winsys/virgl/vtest/virgl_vtest_winsys.h|  19 ++-
>  src/gallium/winsys/virgl/vtest/vtest_protocol.h|  29 +
>  4 files changed, 208 insertions(+), 28 deletions(-)
>
> diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c 
> b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> index ce565ee76c..ff69accf52 100644
> --- a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> +++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> @@ -221,6 +221,42 @@ int virgl_vtest_send_get_caps(struct virgl_vtest_winsys 
> *vws,
> return 0;
>  }
>
> +static int virgl_vtest_send_resource_create2(struct virgl_vtest_winsys *vws,
> + uint32_t handle,
> + enum pipe_texture_target target,
> + uint32_t format,
> + uint32_t bind,
> + uint32_t width,
> + uint32_t height,
> + uint32_t depth,
> + uint32_t array_size,
> + uint32_t last_level,
> + uint32_t nr_samples,
> + uint32_t size)
> +{
> +   uint32_t res_create_buf[VCMD_RES_CREATE2_SIZE], vtest_hdr[VTEST_HDR_SIZE];
> +
> +   vtest_hdr[VTEST_CMD_LEN] = VCMD_RES_CREATE2_SIZE;
> +   vtest_hdr[VTEST_CMD_ID] = VCMD_RESOURCE_CREATE2;
> +
> +   res_create_buf[VCMD_RES_CREATE2_RES_HANDLE] = handle;
> +   res_create_buf[VCMD_RES_CREATE2_TARGET] = target;
> +   res_create_buf[VCMD_RES_CREATE2_FORMAT] = format;
> +   res_create_buf[VCMD_RES_CREATE2_BIND] = bind;
> +   res_create_buf[VCMD_RES_CREATE2_WIDTH] = width;
> +   res_create_buf[VCMD_RES_CREATE2_HEIGHT] = height;
> +   res_create_buf[VCMD_RES_CREATE2_DEPTH] = depth;
> +   res_create_buf[VCMD_RES_CREATE2_ARRAY_SIZE] = array_size;
> +   res_create_buf[VCMD_RES_CREATE2_LAST_LEVEL] = last_level;
> +   res_create_buf[VCMD_RES_CREATE2_NR_SAMPLES] = nr_samples;
> +   res_create_buf[VCMD_RES_CREATE2_DATA_SIZE] = size;
> +
> +   virgl_block_write(vws->sock_fd, _hdr, sizeof(vtest_hdr));
> +   virgl_block_write(vws->sock_fd, _create_buf, sizeof(res_create_buf));
> +
> +   return 0;
> +}
> +
>  int virgl_vtest_send_resource_create(struct virgl_vtest_winsys *vws,
>   uint32_t handle,
>   enum pipe_texture_target target,
> @@ -231,10 +267,17 @@ int virgl_vtest_send_resource_create(struct 
> virgl_vtest_winsys *vws,
>   uint32_t depth,
>   uint32_t array_size,
>   uint32_t last_level,
> - uint32_t nr_samples)
> + uint32_t nr_samples,
> + uint32_t size)
>  {
> uint32_t res_create_buf[VCMD_RES_CREATE_SIZE], vtest_hdr[VTEST_HDR_SIZE];
>
> +   if (vws->protocol_version >= 1)
> +  return virgl_vtest_send_resource_create2(vws, handle, target, format,
> +   bind, width, height, depth,
> +   array_size, last_level,
> +   nr_samples, size);
> +
> vtest_hdr[VTEST_CMD_LEN] = VCMD_RES_CREATE_SIZE;
> vtest_hdr[VTEST_CMD_ID] = VCMD_RESOURCE_CREATE;
>
> @@ -282,7 +325,7 @@ int 

Re: [Mesa-dev] [PATCH v5 1/2] virgl, vtest: Correct the transfer size calculation

[Gurchetan Singh]

On Thu, Oct 4, 2018 at 7:41 AM Gert Wollny  wrote:
>
> From: Gert Wollny 
>
> The transfer size used in virglrenderer refers to uint32_t, so one
> must add 3 and then divide by 4 instead of adding 3/4 which is a no-op
> with integers.
>
> Fixes: b3b82fe8ea virgl/vtest: add vtest driver
>
> Signed-off-by: Gert Wollny 
> ---
>  src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c 
> b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> index 4d20a63ad6..ce565ee76c 100644
> --- a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> +++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> @@ -295,8 +295,10 @@ int virgl_vtest_send_transfer_cmd(struct 
> virgl_vtest_winsys *vws,
> vtest_hdr[VTEST_CMD_LEN] = VCMD_TRANSFER_HDR_SIZE;
> vtest_hdr[VTEST_CMD_ID] = vcmd;
>
> +   /* The host expects the size in dwords so calculate the rounded up
> +* value here. */
> if (vcmd == VCMD_TRANSFER_PUT)
> -  vtest_hdr[VTEST_CMD_LEN] += data_size + 3 / 4;
> +  vtest_hdr[VTEST_CMD_LEN] += (data_size + 3) / 4;
>
> cmd[0] = handle;
> cmd[1] = level;
> --
> 2.16.4
>

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

Re: [Mesa-dev] [PATCH] i965: fallback RGBX to RGBA in glEGLImageTargetRenderbufferStorageOES

[Gurchetan Singh]

Reviewed-by: Gurchetan Singh 
On Wed, Oct 3, 2018 at 2:53 AM Tapani Pälli  wrote:
>
> From: "Chystiakov, Dmytro" 
>
> In the same fashion as is done for glEGLImageTextureTarget2D.
>
> v2: share the fallback which sets baseformat and internalformat correctly
> which makes both of the tests pass (Tapani)
>
> Fixes android.hardware.nativehardware.cts.AHardwareBufferNativeTests:
>
>#SingleLayer_ColorTest_GpuColorOutputCpuRead_R8G8B8X8_UNORM
>#SingleLayer_ColorTest_GpuColorOutputIsRenderable_R8G8B8X8_UNORM
>
> Signed-off-by: Tapani Pälli 
> ---
>  src/mesa/drivers/dri/i965/intel_fbo.c | 63 ---
>  1 file changed, 37 insertions(+), 26 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c 
> b/src/mesa/drivers/dri/i965/intel_fbo.c
> index 4ad27474100..968d61014e5 100644
> --- a/src/mesa/drivers/dri/i965/intel_fbo.c
> +++ b/src/mesa/drivers/dri/i965/intel_fbo.c
> @@ -328,6 +328,35 @@ intel_alloc_renderbuffer_storage(struct gl_context * 
> ctx, struct gl_renderbuffer
> return intel_alloc_private_renderbuffer_storage(ctx, rb, internalFormat, 
> width, height);
>  }
>
> +static mesa_format
> +fallback_rgbx_to_rgba(struct intel_screen *screen, struct gl_renderbuffer 
> *rb,
> +  mesa_format original_format)
> +{
> +   mesa_format format = original_format;
> +
> +   /* The base format and internal format must be derived from the 
> user-visible
> +* format (that is, the gl_config's format), even if we internally use
> +* choose a different format for the renderbuffer. Otherwise, rendering 
> may
> +* use incorrect channel write masks.
> +*/
> +   rb->_BaseFormat = _mesa_get_format_base_format(original_format);
> +   rb->InternalFormat = rb->_BaseFormat;
> +
> +   if (!screen->mesa_format_supports_render[original_format]) {
> +  /* The glRenderbufferStorage paths in core Mesa detect if the driver
> +   * does not support the user-requested format, and then searches for
> +   * a fallback format. The DRI code bypasses core Mesa, though. So we do
> +   * the fallbacks here.
> +   *
> +   * We must support MESA_FORMAT_R8G8B8X8 on Android because the Android
> +   * framework requires HAL_PIXEL_FORMAT_RGBX winsys surfaces.
> +   */
> +  format = _mesa_format_fallback_rgbx_to_rgba(original_format);
> +  assert(screen->mesa_format_supports_render[format]);
> +   }
> +   return format;
> +}
> +
>  static void
>  intel_image_target_renderbuffer_storage(struct gl_context *ctx,
> struct gl_renderbuffer *rb,
> @@ -350,8 +379,13 @@ intel_image_target_renderbuffer_storage(struct 
> gl_context *ctx,
>return;
> }
>
> +   rb->Format = fallback_rgbx_to_rgba(brw->screen, rb, image->format);
> +
> +   mesa_format chosen_format = rb->Format == image->format ?
> +  image->format : rb->Format;
> +
> /* __DRIimage is opaque to the core so it has to be checked here */
> -   if (!brw->mesa_format_supports_render[image->format]) {
> +   if (!brw->mesa_format_supports_render[chosen_format]) {
>_mesa_error(ctx, GL_INVALID_OPERATION,
>  "glEGLImageTargetRenderbufferStorage(unsupported image format)");
>return;
> @@ -366,15 +400,12 @@ intel_image_target_renderbuffer_storage(struct 
> gl_context *ctx,
>  * content.
>  */
> irb->mt = intel_miptree_create_for_dri_image(brw, image, GL_TEXTURE_2D,
> -image->format, false);
> +rb->Format, false);
> if (!irb->mt)
>return;
>
> -   rb->InternalFormat = image->internal_format;
> rb->Width = image->width;
> rb->Height = image->height;
> -   rb->Format = image->format;
> -   rb->_BaseFormat = _mesa_get_format_base_format(image->format);
> rb->NeedsFinishRenderTexture = true;
> irb->layer_count = 1;
>  }
> @@ -436,27 +467,7 @@ intel_create_winsys_renderbuffer(struct intel_screen 
> *screen,
> rb->NumSamples = num_samples;
> rb->NumStorageSamples = num_samples;
>
> -   /* The base format and internal format must be derived from the 
> user-visible
> -* format (that is, the gl_config's format), even if we internally use
> -* choose a different format for the renderbuffer. Otherwise, rendering 
> may
> -* use incorrect channel write masks.
> -*/
> -   rb->_BaseFormat = _mesa_get_format_base_format(format);
> -   rb->InternalFormat = rb->_BaseFormat;
> -
> -   rb-

Re: [Mesa-dev] [PATCH v4 2/2] virgl: Pass resource size and transfer offsets

[Gurchetan Singh]

On Tue, Oct 2, 2018 at 12:08 AM Gert Wollny  wrote:
>
> From: Tomeu Vizoso 
>
> Pass the size of a resource when creating it so a backing can be kept in
> the other side.
>
> Also pass the required offset to transfer commands.
>
> This moves vtest closer to how virtio-gpu works, making it more useful
> for testing.
>
> v2: - Use new messages for creation and transfers, as changing the
>   behavior of the existing messages would be messy given that we don't
>   want to break compatibility with older servers.
>
> v3: - Use correct strides: The resource corresponding to the output display
>   might have a differnt line stride then the IOVs, so when reading back
>   to this resource take the resource stride and the the IOV stride
>   into account.
>
> v4: Fix transfer size calculation (Andrey Simiklit)
>
> Signed-off-by: Tomeu Vizoso  (v2)
> Signed-off-by: Gert Wollny 
> ---
>  .../winsys/virgl/vtest/virgl_vtest_socket.c| 143 
> +++--
>  .../winsys/virgl/vtest/virgl_vtest_winsys.c|  38 --
>  .../winsys/virgl/vtest/virgl_vtest_winsys.h|  19 ++-
>  src/gallium/winsys/virgl/vtest/vtest_protocol.h|  29 +
>  4 files changed, 201 insertions(+), 28 deletions(-)
>
> diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c 
> b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> index 4d20a63ad6..4fa9632c56 100644
> --- a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> +++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> @@ -221,6 +221,42 @@ int virgl_vtest_send_get_caps(struct virgl_vtest_winsys 
> *vws,
> return 0;
>  }
>
> +static int virgl_vtest_send_resource_create2(struct virgl_vtest_winsys *vws,
> + uint32_t handle,
> + enum pipe_texture_target target,
> + uint32_t format,
> + uint32_t bind,
> + uint32_t width,
> + uint32_t height,
> + uint32_t depth,
> + uint32_t array_size,
> + uint32_t last_level,
> + uint32_t nr_samples,
> + uint32_t size)
> +{
> +   uint32_t res_create_buf[VCMD_RES_CREATE2_SIZE], vtest_hdr[VTEST_HDR_SIZE];
> +
> +   vtest_hdr[VTEST_CMD_LEN] = VCMD_RES_CREATE2_SIZE;
> +   vtest_hdr[VTEST_CMD_ID] = VCMD_RESOURCE_CREATE2;
> +
> +   res_create_buf[VCMD_RES_CREATE2_RES_HANDLE] = handle;
> +   res_create_buf[VCMD_RES_CREATE2_TARGET] = target;
> +   res_create_buf[VCMD_RES_CREATE2_FORMAT] = format;
> +   res_create_buf[VCMD_RES_CREATE2_BIND] = bind;
> +   res_create_buf[VCMD_RES_CREATE2_WIDTH] = width;
> +   res_create_buf[VCMD_RES_CREATE2_HEIGHT] = height;
> +   res_create_buf[VCMD_RES_CREATE2_DEPTH] = depth;
> +   res_create_buf[VCMD_RES_CREATE2_ARRAY_SIZE] = array_size;
> +   res_create_buf[VCMD_RES_CREATE2_LAST_LEVEL] = last_level;
> +   res_create_buf[VCMD_RES_CREATE2_NR_SAMPLES] = nr_samples;
> +   res_create_buf[VCMD_RES_CREATE2_DATA_SIZE] = size;
> +
> +   virgl_block_write(vws->sock_fd, _hdr, sizeof(vtest_hdr));
> +   virgl_block_write(vws->sock_fd, _create_buf, sizeof(res_create_buf));
> +
> +   return 0;
> +}
> +
>  int virgl_vtest_send_resource_create(struct virgl_vtest_winsys *vws,
>   uint32_t handle,
>   enum pipe_texture_target target,
> @@ -231,10 +267,17 @@ int virgl_vtest_send_resource_create(struct 
> virgl_vtest_winsys *vws,
>   uint32_t depth,
>   uint32_t array_size,
>   uint32_t last_level,
> - uint32_t nr_samples)
> + uint32_t nr_samples,
> + uint32_t size)
>  {
> uint32_t res_create_buf[VCMD_RES_CREATE_SIZE], vtest_hdr[VTEST_HDR_SIZE];
>
> +   if (vws->protocol_version >= 1)
> +  return virgl_vtest_send_resource_create2(vws, handle, target, format,
> +   bind, width, height, depth,
> +   array_size, last_level,
> +   nr_samples, size);
> +
> vtest_hdr[VTEST_CMD_LEN] = VCMD_RES_CREATE_SIZE;
> vtest_hdr[VTEST_CMD_ID] = VCMD_RESOURCE_CREATE;
>
> @@ -282,7 +325,7 @@ int virgl_vtest_send_resource_unref(struct 
> virgl_vtest_winsys *vws,
> return 0;
>  }
>
> -int virgl_vtest_send_transfer_cmd(struct virgl_vtest_winsys *vws,
> +static int virgl_vtest_send_transfer_cmd(struct virgl_vtest_winsys *vws,
>uint32_t vcmd,
>

Re: [Mesa-dev] [PATCH 1/2] virgl: Negotiate version with vtest server

[Gurchetan Singh]

Reviewed-by: Gurchetan Singh 

Was there a second patch sent out?
On Thu, Sep 13, 2018 at 4:24 AM Gert Wollny  wrote:
>
> From: Tomeu Vizoso 
>
> Check if server supports version negotation by sending a PING_PROTOCOL_VERSION
> message right before a dummy RESOURCE_BUSY_WAIT. If we don't get a reply
> for the first, we know the server doesn't support it.
>
> If it does support it, we can query the max protocol version supported
> by the server and fall back if needed.
>
>
> v2: - Send a new message to negotiate the protocol version, checking if
>   the server supports this message by immediately sending a busy wait
>   message. (Dave Airlie)
>
> v3: - Send a zero-arg command PING_PROTOCOL_VERSION so we actually keep
>   compatibility with older servers. (Code by Dave Airlie)
>
> Signed-off-by: Tomeu Vizoso 
> Signed-off-by: Gert Wollny 
>
> ---
>  .../winsys/virgl/vtest/virgl_vtest_socket.c| 52 
> ++
>  .../winsys/virgl/vtest/virgl_vtest_winsys.h|  2 +
>  src/gallium/winsys/virgl/vtest/vtest_protocol.h| 10 +
>  3 files changed, 64 insertions(+)
>
> diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c 
> b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> index d25f9a3bd9..4d20a63ad6 100644
> --- a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> +++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> @@ -101,6 +101,57 @@ static int virgl_vtest_send_init(struct 
> virgl_vtest_winsys *vws)
> return 0;
>  }
>
> +static int virgl_vtest_negotiate_version(struct virgl_vtest_winsys *vws)
> +{
> +   uint32_t vtest_hdr[VTEST_HDR_SIZE];
> +   uint32_t version_buf[VCMD_PROTOCOL_VERSION_SIZE];
> +   uint32_t busy_wait_buf[VCMD_BUSY_WAIT_SIZE];
> +   uint32_t busy_wait_result[1];
> +   int ret;
> +
> +   vtest_hdr[VTEST_CMD_LEN] = VCMD_PING_PROTOCOL_VERSION_SIZE;
> +   vtest_hdr[VTEST_CMD_ID] = VCMD_PING_PROTOCOL_VERSION;
> +   virgl_block_write(vws->sock_fd, _hdr, sizeof(vtest_hdr));
> +
> +   vtest_hdr[VTEST_CMD_LEN] = VCMD_BUSY_WAIT_SIZE;
> +   vtest_hdr[VTEST_CMD_ID] = VCMD_RESOURCE_BUSY_WAIT;
> +   busy_wait_buf[VCMD_BUSY_WAIT_HANDLE] = 0;
> +   busy_wait_buf[VCMD_BUSY_WAIT_FLAGS] = 0;
> +   virgl_block_write(vws->sock_fd, _hdr, sizeof(vtest_hdr));
> +   virgl_block_write(vws->sock_fd, _wait_buf, sizeof(busy_wait_buf));
> +
> +   ret = virgl_block_read(vws->sock_fd, vtest_hdr, sizeof(vtest_hdr));
> +   assert(ret);
> +
> +   if (vtest_hdr[VTEST_CMD_ID] == VCMD_PING_PROTOCOL_VERSION) {
> + /* Read dummy busy_wait response */
> + ret = virgl_block_read(vws->sock_fd, vtest_hdr, sizeof(vtest_hdr));
> + assert(ret);
> + ret = virgl_block_read(vws->sock_fd, busy_wait_result, 
> sizeof(busy_wait_result));
> + assert(ret);
> +
> + vtest_hdr[VTEST_CMD_LEN] = VCMD_PROTOCOL_VERSION_SIZE;
> + vtest_hdr[VTEST_CMD_ID] = VCMD_PROTOCOL_VERSION;
> + version_buf[VCMD_PROTOCOL_VERSION_VERSION] = VTEST_PROTOCOL_VERSION;
> + virgl_block_write(vws->sock_fd, _hdr, sizeof(vtest_hdr));
> + virgl_block_write(vws->sock_fd, _buf, sizeof(version_buf));
> +
> + ret = virgl_block_read(vws->sock_fd, vtest_hdr, sizeof(vtest_hdr));
> + assert(ret);
> + ret = virgl_block_read(vws->sock_fd, version_buf, sizeof(version_buf));
> + assert(ret);
> + return version_buf[VCMD_PROTOCOL_VERSION_VERSION];
> +   }
> +
> +   /* Read dummy busy_wait response */
> +   assert(vtest_hdr[VTEST_CMD_ID] == VCMD_RESOURCE_BUSY_WAIT);
> +   ret = virgl_block_read(vws->sock_fd, busy_wait_result, 
> sizeof(busy_wait_result));
> +   assert(ret);
> +
> +   /* Old server, return version 0 */
> +   return 0;
> +}
> +
>  int virgl_vtest_connect(struct virgl_vtest_winsys *vws)
>  {
> struct sockaddr_un un;
> @@ -123,6 +174,7 @@ int virgl_vtest_connect(struct virgl_vtest_winsys *vws)
>
> vws->sock_fd = sock;
> virgl_vtest_send_init(vws);
> +   vws->protocol_version = virgl_vtest_negotiate_version(vws);
> return 0;
>  }
>
> diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h 
> b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h
> index 031037b6b5..3628c74644 100644
> --- a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h
> +++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h
> @@ -49,6 +49,8 @@ struct virgl_vtest_winsys {
> int num_delayed;
> unsigned usecs;
> mtx_t mutex;
> +
> +   unsigned protocol_version;
>  };
>
>  struct virgl_hw_res {
> diff --git a/src/gallium/winsys/virgl/vtest/vtest_protocol.h 
> b/src/gallium/winsys/virgl/vtest/vtest_protocol.h
> index 95bd8c1d0b..8eb904e73f 100644
>

Re: [Mesa-dev] [PATCH v2 0/7] gallium/virgl: use hw-atomic buffers

[Gurchetan Singh]

Series is:

Reviewed-by: Gurchetan Singh 
On Tue, Sep 4, 2018 at 2:09 AM Erik Faye-Lund
 wrote:
>
> OK, so here's a respin of this series, with the following changes:
>
> - [Gurchetan] Use PIPE_MAX_SHADER_BUFFERS instead of
>   PIPE_MAX_HW_ATOMIC_BUFFERS.
> - [Gurchetan] Fixup tabs vs spaces
> - Moved max-value clamping from getter to state-tracker, as that
>   provides better encapsulation of thie state-tracker requirement.
> - [Marek] Added documentation of the new caps
>
> Erik Faye-Lund (6):
>   st/mesa: use real bool for can_ubo
>   st/mesa: clean up atomic vs ssbo code
>   st/mesa: simplify MaxAtomicBufferSize-logic
>   gallium: add PIPE_CAP_MAX_COMBINED_SHADER_BUFFERS
>   gallium: add PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER{S,_BUFFERS}
>   virgl: update minor differences to upstream header
>
> Tomeu Vizoso (1):
>   virgl: use hw-atomics instead of in-ssbo ones
>
>  src/gallium/docs/source/screen.rst|  8 +++
>  src/gallium/drivers/etnaviv/etnaviv_screen.c  |  8 +++
>  .../drivers/freedreno/freedreno_screen.c  |  8 +++
>  .../drivers/nouveau/nv30/nv30_screen.c|  4 ++
>  .../drivers/nouveau/nv50/nv50_screen.c|  4 ++
>  .../drivers/nouveau/nvc0/nvc0_screen.c|  4 ++
>  src/gallium/drivers/r300/r300_screen.c|  8 ++-
>  src/gallium/drivers/r600/r600_pipe.c  | 13 
>  src/gallium/drivers/radeonsi/si_get.c |  4 ++
>  src/gallium/drivers/svga/svga_screen.c|  4 ++
>  src/gallium/drivers/v3d/v3d_screen.c  | 10 ++-
>  src/gallium/drivers/vc4/vc4_screen.c  | 10 ++-
>  src/gallium/drivers/virgl/virgl_context.c | 37 +++
>  src/gallium/drivers/virgl/virgl_context.h |  2 +
>  src/gallium/drivers/virgl/virgl_encode.c  | 23 +++
>  src/gallium/drivers/virgl/virgl_encode.h  |  3 +
>  src/gallium/drivers/virgl/virgl_hw.h  |  5 ++
>  src/gallium/drivers/virgl/virgl_protocol.h| 11 +++-
>  src/gallium/drivers/virgl/virgl_screen.c  | 12 +++-
>  src/gallium/include/pipe/p_defines.h  |  3 +
>  src/mesa/state_tracker/st_extensions.c| 65 ---
>  21 files changed, 214 insertions(+), 32 deletions(-)
>
> --
> 2.17.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/7] gallium: add PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER{S, _BUFFERS}

[Gurchetan Singh]

On Thu, Aug 30, 2018 at 6:41 AM Erik Faye-Lund
 wrote:
>
> This moves the evergreen-specific max-sizes out as a driver-cap, so
> other drivers with less strict requirements also can use hw-atomics.
>
> Remove ssbo_atomic as it's no longer needed.
>
> We should now be able to use hw-atomics for some stages and not for
> other, if needed.
>
> Signed-off-by: Erik Faye-Lund 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_screen.c  |  5 +
>  .../drivers/freedreno/freedreno_screen.c  |  5 +
>  .../drivers/nouveau/nv30/nv30_screen.c|  2 ++
>  .../drivers/nouveau/nv50/nv50_screen.c|  2 ++
>  .../drivers/nouveau/nvc0/nvc0_screen.c|  2 ++
>  src/gallium/drivers/r300/r300_screen.c|  2 ++
>  src/gallium/drivers/r600/r600_pipe.c  |  9 +
>  src/gallium/drivers/radeonsi/si_get.c |  2 ++
>  src/gallium/drivers/svga/svga_screen.c|  2 ++
>  src/gallium/drivers/v3d/v3d_screen.c  |  2 ++
>  src/gallium/drivers/vc4/vc4_screen.c  |  2 ++
>  src/gallium/drivers/virgl/virgl_screen.c  |  2 ++
>  src/gallium/include/pipe/p_defines.h  |  2 ++
>  src/mesa/state_tracker/st_extensions.c| 20 +--
>  14 files changed, 49 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
> b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> index 108b97d35c..95166a2db1 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> @@ -372,6 +372,11 @@ etna_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
>return 0;
> case PIPE_CAP_UMA:
>return 1;
> +
> +   /* hw atomic counters */
> +   case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTERS:
> +   case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER_BUFFERS:
> +  return 0;
> }
>
> debug_printf("unknown param %d", param);
> diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
> b/src/gallium/drivers/freedreno/freedreno_screen.c
> index af44ab698e..e6dfc2e48e 100644
> --- a/src/gallium/drivers/freedreno/freedreno_screen.c
> +++ b/src/gallium/drivers/freedreno/freedreno_screen.c
> @@ -491,6 +491,11 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
> return 1;
> case PIPE_CAP_NATIVE_FENCE_FD:
> return fd_device_version(screen->dev) >= FD_VERSION_FENCE_FD;
> +
> +   /* hw atomic counters */
> +   case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTERS:
> +   case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER_BUFFERS:
> +   return 0;
> }
> debug_printf("unknown param %d\n", param);
> return 0;
> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c 
> b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> index d52d8f3988..3fdbadb6c6 100644
> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> @@ -239,6 +239,8 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
> case PIPE_CAP_CONSERVATIVE_RASTER_POST_DEPTH_COVERAGE:
> case PIPE_CAP_MAX_CONSERVATIVE_RASTER_SUBPIXEL_PRECISION_BIAS:
> case PIPE_CAP_PROGRAMMABLE_SAMPLE_LOCATIONS:
> +   case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTERS:
> +   case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER_BUFFERS:
>return 0;
>
> case PIPE_CAP_MAX_GS_INVOCATIONS:
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c 
> b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
> index cd36795e56..a6dda5dfa0 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
> @@ -293,6 +293,8 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
> case PIPE_CAP_CONSERVATIVE_RASTER_POST_DEPTH_COVERAGE:
> case PIPE_CAP_MAX_CONSERVATIVE_RASTER_SUBPIXEL_PRECISION_BIAS:
> case PIPE_CAP_PROGRAMMABLE_SAMPLE_LOCATIONS:
> +   case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTERS:
> +   case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER_BUFFERS:
>return 0;
>
> case PIPE_CAP_MAX_GS_INVOCATIONS:
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> index 446e30dcc8..b628b24d76 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> @@ -322,6 +322,8 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
> case PIPE_CAP_CONSTBUF0_FLAGS:
> case PIPE_CAP_PACKED_UNIFORMS:
> case PIPE_CAP_CONSERVATIVE_RASTER_PRE_SNAP_POINTS_LINES:
> +   case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTERS:
> +   case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER_BUFFERS:
>return 0;
>
> case PIPE_CAP_VENDOR_ID:
> diff --git a/src/gallium/drivers/r300/r300_screen.c 
> b/src/gallium/drivers/r300/r300_screen.c
> index d27c2b8f1d..f29d5244ff 100644
> --- a/src/gallium/drivers/r300/r300_screen.c
> +++ 

Re: [Mesa-dev] [PATCH 7/7] virgl: use hw-atomics instead of in-ssbo ones

[Gurchetan Singh]

On Thu, Aug 30, 2018 at 6:41 AM Erik Faye-Lund
 wrote:
>
> From: Tomeu Vizoso 
>
> Emulating atomics on top of ssbos can lead to too small max SSBO count,
> so let's use the hw-atomics mechanism to expose atomic buffers instead.
>
> Signed-off-by: Erik Faye-Lund 
> ---
>  src/gallium/drivers/virgl/virgl_context.c  | 37 ++
>  src/gallium/drivers/virgl/virgl_context.h  |  2 ++
>  src/gallium/drivers/virgl/virgl_encode.c   | 23 ++
>  src/gallium/drivers/virgl/virgl_encode.h   |  3 ++
>  src/gallium/drivers/virgl/virgl_hw.h   |  5 +++
>  src/gallium/drivers/virgl/virgl_protocol.h |  9 ++
>  src/gallium/drivers/virgl/virgl_screen.c   | 14 +---
>  7 files changed, 88 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_context.c 
> b/src/gallium/drivers/virgl/virgl_context.c
> index edc03f5dcf..30cd0e4331 100644
> --- a/src/gallium/drivers/virgl/virgl_context.c
> +++ b/src/gallium/drivers/virgl/virgl_context.c
> @@ -196,6 +196,19 @@ static void virgl_attach_res_shader_images(struct 
> virgl_context *vctx,
> }
>  }
>
> +static void virgl_attach_res_atomic_buffers(struct virgl_context *vctx)
> +{
> +   struct virgl_winsys *vws = virgl_screen(vctx->base.screen)->vws;
> +   struct virgl_resource *res;
> +   unsigned i;
> +   for (i = 0; i < PIPE_MAX_SHADER_BUFFERS; i++) {

Why not PIPE_MAX_HW_ATOMIC_BUFFERS?

> +  res = virgl_resource(vctx->atomic_buffers[i]);
> +  if (res) {
> + vws->emit_res(vws, vctx->cbuf, res->hw_res, FALSE);
> +  }
> +   }
> +}
> +
>  /*
>   * after flushing, the hw context still has a bunch of
>   * resources bound, so we need to rebind those here.
> @@ -214,6 +227,7 @@ static void virgl_reemit_res(struct virgl_context *vctx)
>virgl_attach_res_shader_buffers(vctx, shader_type);
>virgl_attach_res_shader_images(vctx, shader_type);
> }
> +   virgl_attach_res_atomic_buffers(vctx);
> virgl_attach_res_vertex_buffers(vctx);
> virgl_attach_res_so_targets(vctx);
>  }
> @@ -952,6 +966,28 @@ static void virgl_blit(struct pipe_context *ctx,
>  blit);
>  }
>
> +static void virgl_set_hw_atomic_buffers(struct pipe_context *ctx,
> +   unsigned start_slot,
> +   unsigned count,
> +   const struct pipe_shader_buffer 
> *buffers)

nit: mixing tabs and spaces

> +{
> +   struct virgl_context *vctx = virgl_context(ctx);
> +
> +   for (unsigned i = 0; i < count; i++) {
> +  unsigned idx = start_slot + i;
> +
> +  if (buffers) {
> + if (buffers[i].buffer) {
> +pipe_resource_reference(>atomic_buffers[idx],
> +buffers[i].buffer);
> +continue;
> + }
> +  }
> +  pipe_resource_reference(>atomic_buffers[idx], NULL);
> +   }
> +   virgl_encode_set_hw_atomic_buffers(vctx, start_slot, count, buffers);
> +}
> +
>  static void virgl_set_shader_buffers(struct pipe_context *ctx,
>   enum pipe_shader_type shader,
>   unsigned start_slot, unsigned count,
> @@ -1209,6 +1245,7 @@ struct pipe_context *virgl_context_create(struct 
> pipe_screen *pscreen,
> vctx->base.blit =  virgl_blit;
>
> vctx->base.set_shader_buffers = virgl_set_shader_buffers;
> +   vctx->base.set_hw_atomic_buffers = virgl_set_hw_atomic_buffers;
> vctx->base.set_shader_images = virgl_set_shader_images;
> vctx->base.memory_barrier = virgl_memory_barrier;
>
> diff --git a/src/gallium/drivers/virgl/virgl_context.h 
> b/src/gallium/drivers/virgl/virgl_context.h
> index 38d1f450e1..20988baa3c 100644
> --- a/src/gallium/drivers/virgl/virgl_context.h
> +++ b/src/gallium/drivers/virgl/virgl_context.h
> @@ -75,6 +75,8 @@ struct virgl_context {
> int num_draws;
> struct list_head to_flush_bufs;
>
> +   struct pipe_resource *atomic_buffers[PIPE_MAX_HW_ATOMIC_BUFFERS];
> +
> struct primconvert_context *primconvert;
> uint32_t hw_sub_ctx_id;
>  };
> diff --git a/src/gallium/drivers/virgl/virgl_encode.c 
> b/src/gallium/drivers/virgl/virgl_encode.c
> index bcb14d8939..c9cc099061 100644
> --- a/src/gallium/drivers/virgl/virgl_encode.c
> +++ b/src/gallium/drivers/virgl/virgl_encode.c
> @@ -958,6 +958,29 @@ int virgl_encode_set_shader_buffers(struct virgl_context 
> *ctx,
> return 0;
>  }
>
> +int virgl_encode_set_hw_atomic_buffers(struct virgl_context *ctx,
> +   unsigned start_slot, unsigned count,
> +   const struct pipe_shader_buffer 
> *buffers)
> +{
> +   int i;
> +   virgl_encoder_write_cmd_dword(ctx, 
> VIRGL_CMD0(VIRGL_CCMD_SET_ATOMIC_BUFFERS, 0, 
> VIRGL_SET_ATOMIC_BUFFER_SIZE(count)));
> +
> +   virgl_encoder_write_dword(ctx->cbuf, start_slot);
> +   for (i = 0; i < count; i++) {
> +  if (buffers) {
> +struct virgl_resource *res = 

[Mesa-dev] [PATCH 1/2] meson: fix egl build for surfaceless

[Gurchetan Singh]

Without this, I get:

 > platform_surfaceless.c:38:10: fatal error: 'loader.h' file not found
 > #include "loader.h"
 >  ^~
 > 1 error generated.

Fixes: 108d257a16859898f5ce02f4759c5c58f9b8c050 ("meson: build libEGL")

v2: Split up patches, modify commit message (Dylan)
---
 src/egl/meson.build | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/egl/meson.build b/src/egl/meson.build
index c7c22d3637..9c0b6b4b4a 100644
--- a/src/egl/meson.build
+++ b/src/egl/meson.build
@@ -114,6 +114,7 @@ if with_platform_drm
 endif
 if with_platform_surfaceless
   files_egl += files('drivers/dri2/platform_surfaceless.c')
+  incs_for_egl += [inc_loader]
 endif
 if with_platform_wayland
   deps_for_egl += [dep_wayland_client, dep_wayland_server, 
dep_wayland_egl_headers]
-- 
2.16.4

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

[Mesa-dev] [PATCH 2/2] meson: fix egl build for android

[Gurchetan Singh]

Haven't tested this, but we do include loader.h
in platform_android.c

Fixes: c5ec1556859b7d33637c9fad13d3473c7b2f9eb3 ("meson: wire up egl/android")
---
 src/egl/meson.build | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/egl/meson.build b/src/egl/meson.build
index 9c0b6b4b4a..06922c6c3c 100644
--- a/src/egl/meson.build
+++ b/src/egl/meson.build
@@ -130,6 +130,7 @@ endif
 if with_platform_android
   deps_for_egl += dep_android
   files_egl += files('drivers/dri2/platform_android.c')
+  incs_for_egl += [inc_loader]
 endif
 if with_platform_haiku
   incs_for_egl += inc_haikugl
-- 
2.16.4

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

[Mesa-dev] [PATCH] meson: fix egl build for surfaceless and android

[Gurchetan Singh]

Without this, I get:

 > platform_surfaceless.c:38:10: fatal error: 'loader.h' file not found
 > #include "loader.h"
 >  ^~
 > 1 error generated.

I also included this for platform_android, but I haven't tested that
case.
---
 src/egl/meson.build | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/egl/meson.build b/src/egl/meson.build
index c7c22d3637..06922c6c3c 100644
--- a/src/egl/meson.build
+++ b/src/egl/meson.build
@@ -114,6 +114,7 @@ if with_platform_drm
 endif
 if with_platform_surfaceless
   files_egl += files('drivers/dri2/platform_surfaceless.c')
+  incs_for_egl += [inc_loader]
 endif
 if with_platform_wayland
   deps_for_egl += [dep_wayland_client, dep_wayland_server, 
dep_wayland_egl_headers]
@@ -129,6 +130,7 @@ endif
 if with_platform_android
   deps_for_egl += dep_android
   files_egl += files('drivers/dri2/platform_android.c')
+  incs_for_egl += [inc_loader]
 endif
 if with_platform_haiku
   incs_for_egl += inc_haikugl
-- 
2.16.4

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

Re: [Mesa-dev] [PATCH] virgl: bump 3D texture limit to 2048, as GL4.1 requires

[Gurchetan Singh]

On Tue, Aug 14, 2018 at 2:59 AM Erik Faye-Lund
 wrote:
>
>
>
> On Tue, Aug 14, 2018 at 5:47 AM, Gurchetan Singh 
>  wrote:
>
> This is virgl analogue to cf6dad. Fixes: 
> dEQP-GLES31.functional.image_load_store.3d.atomic.* Example test cases: 
> dEQP-GLES31.functional.image_load_store.3d.atomic.add_r32ui_return_value 
> dEQP-GLES31.functional.image_load_store.3d.atomic.min_r32ui_return_value 
> dEQP-GLES31.functional.image_load_store.3d.atomic.max_r32ui_return_value 
> dEQP-GLES31.functional.image_load_store.3d.atomic.and_r32ui_return_value --- 
> src/gallium/drivers/virgl/virgl_screen.c | 2 +- 1 file changed, 1 
> insertion(+), 1 deletion(-) diff --git 
> a/src/gallium/drivers/virgl/virgl_screen.c 
> b/src/gallium/drivers/virgl/virgl_screen.c index 421fde5249..745a502189 
> 100644 --- a/src/gallium/drivers/virgl/virgl_screen.c +++ 
> b/src/gallium/drivers/virgl/virgl_screen.c @@ -36,7 +36,7 @@ #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_3D_LEVELS 12 /* 2048 x 2048 x 2048 */ #define 
> SP_MAX_TEXTURE_CUBE_LEVELS 13 /* 4K x 4K */
>
>
> I don't think this is a good idea.
>
> OpenGL ES 3.1 only requires 256^3 support, so this is going to fail when 
> running on such hardware. I'm working on patches that actually pass what the 
> host supports instead.
>
> But, a puzzling details is that these tests don't use more than 512 in either 
> direction. They use max 320 (= 64 * 5). And mesa seems to think 256 is the 
> actual max here.

That's because maxSize in _mesa_legal_texture_dimensions is 256 when
SP_MAX_TEXTURE_3D_LEVELS is 9:

https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/teximage.c#n1024

> So something is going wrong between us reportig this to mesa and
>
> There's also a bug in the test, where it tests size that are out of spec 
> without checking the max-size, it seems. I have a patch for this also.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] virgl: bump 3D texture limit to 2048, as GL4.1 requires

[Gurchetan Singh]

This is virgl analogue to cf6dad.

Fixes:
  dEQP-GLES31.functional.image_load_store.3d.atomic.*

Example test cases:
  dEQP-GLES31.functional.image_load_store.3d.atomic.add_r32ui_return_value
  dEQP-GLES31.functional.image_load_store.3d.atomic.min_r32ui_return_value
  dEQP-GLES31.functional.image_load_store.3d.atomic.max_r32ui_return_value
  dEQP-GLES31.functional.image_load_store.3d.atomic.and_r32ui_return_value
---
 src/gallium/drivers/virgl/virgl_screen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
b/src/gallium/drivers/virgl/virgl_screen.c
index 421fde5249..745a502189 100644
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -36,7 +36,7 @@
 #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_3D_LEVELS 12   /* 2048 x 2048 x 2048 */
 #define SP_MAX_TEXTURE_CUBE_LEVELS 13  /* 4K x 4K */
 
 static const char *
-- 
2.16.4

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

Re: [Mesa-dev] [PATCH 1/3] virgl: add initial ARB_compute_shader support

[Gurchetan Singh]

This series is:

Reviewed-by: Gurchetan Singh 
On Tue, Jul 31, 2018 at 3:29 PM Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> This hooks up compute shader creation and launch grid support.
> ---
>  src/gallium/drivers/virgl/virgl_context.c  | 55 ++--
>  src/gallium/drivers/virgl/virgl_encode.c   | 25 -
>  src/gallium/drivers/virgl/virgl_encode.h   |  3 ++
>  src/gallium/drivers/virgl/virgl_hw.h   |  5 +++
>  src/gallium/drivers/virgl/virgl_protocol.h | 11 ++
>  src/gallium/drivers/virgl/virgl_screen.c   | 59 
> --
>  src/gallium/drivers/virgl/virgl_winsys.h   |  2 +
>  7 files changed, 153 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_context.c 
> b/src/gallium/drivers/virgl/virgl_context.c
> index d224b68cfcd..ae1da337994 100644
> --- a/src/gallium/drivers/virgl/virgl_context.c
> +++ b/src/gallium/drivers/virgl/virgl_context.c
> @@ -506,7 +506,7 @@ static void *virgl_shader_encoder(struct pipe_context 
> *ctx,
> handle = virgl_object_assign_handle();
> /* encode VS state */
> ret = virgl_encode_shader_state(vctx, handle, type,
> -   >stream_output,
> +   >stream_output, 0,
> new_tokens);
> if (ret) {
>return NULL;
> @@ -961,7 +961,7 @@ static void virgl_set_shader_buffers(struct pipe_context 
> *ctx,
>pipe_resource_reference(>ssbos[shader][idx], NULL);
> }
>
> -   uint32_t max_shader_buffer = shader == PIPE_SHADER_FRAGMENT ?
> +   uint32_t max_shader_buffer = (shader == PIPE_SHADER_FRAGMENT || shader == 
> PIPE_SHADER_COMPUTE) ?
>rs->caps.caps.v2.max_shader_buffer_frag_compute :
>rs->caps.caps.v2.max_shader_buffer_other_stages;
> if (!max_shader_buffer)
> @@ -989,7 +989,7 @@ static void virgl_set_shader_images(struct pipe_context 
> *ctx,
>pipe_resource_reference(>images[shader][idx], NULL);
> }
>
> -   uint32_t max_shader_images = shader == PIPE_SHADER_FRAGMENT ?
> +   uint32_t max_shader_images = (shader == PIPE_SHADER_FRAGMENT || shader == 
> PIPE_SHADER_COMPUTE) ?
>   rs->caps.caps.v2.max_shader_image_frag_compute :
>   rs->caps.caps.v2.max_shader_image_other_stages;
> if (!max_shader_images)
> @@ -1008,6 +1008,50 @@ static void virgl_memory_barrier(struct pipe_context 
> *ctx,
> virgl_encode_memory_barrier(vctx, flags);
>  }
>
> +static void *virgl_create_compute_state(struct pipe_context *ctx,
> +const struct pipe_compute_state 
> *state)
> +{
> +   struct virgl_context *vctx = virgl_context(ctx);
> +   uint32_t handle;
> +   const struct tgsi_token *new_tokens = state->prog;
> +   struct pipe_stream_output_info so_info = {};
> +   int ret;
> +
> +   handle = virgl_object_assign_handle();
> +   ret = virgl_encode_shader_state(vctx, handle, PIPE_SHADER_COMPUTE,
> +   _info,
> +   state->req_local_mem,
> +   new_tokens);
> +   if (ret) {
> +  return NULL;
> +   }
> +
> +   return (void *)(unsigned long)handle;
> +}
> +
> +static void virgl_bind_compute_state(struct pipe_context *ctx, void *state)
> +{
> +   uint32_t handle = (unsigned long)state;
> +   struct virgl_context *vctx = virgl_context(ctx);
> +
> +   virgl_encode_bind_shader(vctx, handle, PIPE_SHADER_COMPUTE);
> +}
> +
> +static void virgl_delete_compute_state(struct pipe_context *ctx, void *state)
> +{
> +   uint32_t handle = (unsigned long)state;
> +   struct virgl_context *vctx = virgl_context(ctx);
> +
> +   virgl_encode_delete_object(vctx, handle, VIRGL_OBJECT_SHADER);
> +}
> +
> +static void virgl_launch_grid(struct pipe_context *ctx,
> +  const struct pipe_grid_info *info)
> +{
> +   struct virgl_context *vctx = virgl_context(ctx);
> +   virgl_encode_launch_grid(vctx, info);
> +}
> +
>  static void
>  virgl_context_destroy( struct pipe_context *ctx )
>  {
> @@ -1118,6 +1162,11 @@ struct pipe_context *virgl_context_create(struct 
> pipe_screen *pscreen,
> vctx->base.delete_gs_state = virgl_delete_gs_state;
> vctx->base.delete_fs_state = virgl_delete_fs_state;
>
> +   vctx->base.create_compute_state = virgl_create_compute_state;
> +   vctx->base.bind_compute_state = virgl_bind_compute_state;
> +   vctx->base.delete_compute_state = virgl_delete_compute_state;
> +   vctx->base.launch_grid = virgl_launch_grid;
> +
> vctx->base.clear = virgl_clear;
>

Re: [Mesa-dev] [PATCH] gallium/auxiliary: Fix Autotools on Android (v2)

[Gurchetan Singh]

Reviewed-by: Gurchetan Singh 
On Tue, Jul 24, 2018 at 6:11 PM Chad Versace  wrote:
>
> Problem 1: u_debug_stack_android.cpp transitively included
> "pipe/p_compiler.h", but src/gallium/include was missing from the C++
> include path.
>
> Problem 2: Add -std=c++11 to AM_CXXFLAGS. Android's libbacktrace headers
> require C++11, but the Android toolchain (at least in the Chrome OS SDK)
> does not enable C++11 by default.
>
> v2: Add -std=c++11.
>
> Cc: Gurchetan Singh 
> Cc: Eric Engestrom 
> ---
>  src/gallium/auxiliary/Makefile.am | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/Makefile.am 
> b/src/gallium/auxiliary/Makefile.am
> index 03908198772..4bfa7648389 100644
> --- a/src/gallium/auxiliary/Makefile.am
> +++ b/src/gallium/auxiliary/Makefile.am
> @@ -13,6 +13,7 @@ AM_CFLAGS = \
> $(MSVC2013_COMPAT_CFLAGS)
>
>  AM_CXXFLAGS = \
> +   $(GALLIUM_CFLAGS) \
> $(VISIBILITY_CXXFLAGS) \
> $(MSVC2013_COMPAT_CXXFLAGS)
>
> @@ -22,6 +23,10 @@ libgallium_la_SOURCES = \
> $(GENERATED_SOURCES)
>
>  if HAVE_PLATFORM_ANDROID
> +# Android's libbacktrace headers required C++11, but the Android toolchain 
> (at
> +# least in the Chrome OS SDK) does not enable C++11 by default.
> +AM_CXXFLAGS += $(CXX11_CXXFLAGS)
> +
>  libgallium_la_SOURCES += util/u_debug_stack_android.cpp
>  endif
>
> @@ -41,7 +46,6 @@ AM_CFLAGS += \
> $(LLVM_CFLAGS)
>
>  AM_CXXFLAGS += \
> -   $(GALLIUM_CFLAGS) \
> $(LLVM_CXXFLAGS)
>
>  libgallium_la_SOURCES += \
> --
> 2.18.0.233.g985f88cf7e-goog
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] virgl: Allow RGB32* textures only as buffer objects

[Gurchetan Singh]

On Thu, Jul 12, 2018 at 3:56 AM Gert Wollny  wrote:
>
> When requesting a texture of the internal format GL_RGB32F Gallium will
> try to allocate a renderable texture and returns RGBA32F or RGBX32F, but
> when one requests GL_RGB32I or GL_RGB32UI the according 3-component
> texture will be returned. This leads to problems later, when one wants
> to use glCopyImageSubData to copy data between these textures that should
> be compatible, but given the way virgl and Gallium  handle this the latter
> fails with an assertion, because the per-texel bit size is different.
>
> By allowing the GL_RGB32* only for texture buffers these problems are avoided
> without losing the ARB_tbo_rgb32 extension (thanks Ilia Mirkin).
>
> Signed-off-by: Gert Wollny 
> ---
>  src/gallium/drivers/virgl/virgl_screen.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
> b/src/gallium/drivers/virgl/virgl_screen.c
> index 2a340b004f..1dbd88dee8 100644
> --- a/src/gallium/drivers/virgl/virgl_screen.c
> +++ b/src/gallium/drivers/virgl/virgl_screen.c
> @@ -496,6 +496,13 @@ virgl_is_format_supported( struct pipe_screen *screen,
>return virgl_is_vertex_format_supported(screen, format);
> }
>
> +   /* Allow 3-comp 32 bit texturs only for TBOs (needed for ARB_tbo_rgb32) */

nit: textures

> +   if ((format == PIPE_FORMAT_R32G32B32_FLOAT ||
> +   format == PIPE_FORMAT_R32G32B32_SINT ||
> +   format == PIPE_FORMAT_R32G32B32_UINT) &&
> +   target != PIPE_BUFFER)
> +  return FALSE;
> +
> if (bind & PIPE_BIND_RENDER_TARGET) {
>if (format_desc->colorspace == UTIL_FORMAT_COLORSPACE_ZS)
>   return FALSE;
> --
> 2.17.1

Just one small spelling nit (which a committer can fix), otherwise:

Reviewed-by: Gurchetan Singh 

> ___
> 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] virgl: Expose GL_ARB_copy_image if host supports it

[Gurchetan Singh]

Reviewed-by: Gurchetan Singh 
On Tue, Jul 3, 2018 at 4:32 AM Gert Wollny  wrote:
>
> Signed-off-by: Gert Wollny 
> ---
> Note that I used (1 << 3) instead of (1 << 2) because Dave's experimental 
> patch
> already uses the latter for computer shader caps.
> The host side patch starting to implement this can be found here:
>   https://patchwork.freedesktop.org/series/45064/
>
> Thanks for reviewing,
> Gert
>
>  src/gallium/drivers/virgl/virgl_hw.h | 1 +
>  src/gallium/drivers/virgl/virgl_screen.c | 3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_hw.h 
> b/src/gallium/drivers/virgl/virgl_hw.h
> index d338051d9b..4c23cb18b5 100644
> --- a/src/gallium/drivers/virgl/virgl_hw.h
> +++ b/src/gallium/drivers/virgl/virgl_hw.h
> @@ -201,6 +201,7 @@ enum virgl_formats {
>  #define VIRGL_CAP_NONE 0
>  #define VIRGL_CAP_TGSI_INVARIANT   (1 << 0)
>  #define VIRGL_CAP_TEXTURE_VIEW (1 << 1)
> +#define VIRGL_CAP_COPY_IMAGE   (1 << 3)
>
>  #define VIRGL_BIND_DEPTH_STENCIL (1 << 0)
>  #define VIRGL_BIND_RENDER_TARGET (1 << 1)
> diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
> b/src/gallium/drivers/virgl/virgl_screen.c
> index 8bd6673c3c..2a340b004f 100644
> --- a/src/gallium/drivers/virgl/virgl_screen.c
> +++ b/src/gallium/drivers/virgl/virgl_screen.c
> @@ -219,6 +219,8 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
> param)
>return vscreen->caps.caps.v2.max_shader_patch_varyings;
> case PIPE_CAP_SAMPLER_VIEW_TARGET:
>return vscreen->caps.caps.v2.capability_bits & VIRGL_CAP_TEXTURE_VIEW;
> +   case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
> +  return vscreen->caps.caps.v2.capability_bits & VIRGL_CAP_COPY_IMAGE;
> case PIPE_CAP_TEXTURE_GATHER_SM5:
> case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
> case PIPE_CAP_FAKE_SW_MSAA:
> @@ -246,7 +248,6 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
> param)
> case PIPE_CAP_GENERATE_MIPMAP:
> case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
> case PIPE_CAP_QUERY_BUFFER_OBJECT:
> -   case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
> case PIPE_CAP_STRING_MARKER:
> case PIPE_CAP_QUERY_MEMORY_INFO:
> case PIPE_CAP_PCI_GROUP:
> --
> 2.17.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] virgl: remove unused stride-arguments

[Gurchetan Singh]

Reviewed-by: Gurchetan Singh 
On Wed, Jul 18, 2018 at 4:06 AM Erik Faye-Lund
 wrote:
>
> The IOCTLs doesn't pass this along, so computing them in the first
> place is kinda pointless.
>
> Signed-off-by: Erik Faye-Lund 
> ---
>
> This is just a cleanup I noticed based on some discussion with Gert.
>
> A question is, what code here expects this stride to be respected? The
> call-sites in virgl_*_transfer_map and virgl_*_transfer_unmap kinda
> looks like they do... They'll get a bit of a surprise here, no?
>
> Anyway, this is already broken, so I think this should be OK. But
> perhaps this patch shows some code-paths that need some love?
>
>  src/gallium/drivers/virgl/virgl_buffer.c  |  4 ++--
>  src/gallium/drivers/virgl/virgl_context.c |  2 +-
>  src/gallium/drivers/virgl/virgl_texture.c | 24 ++-
>  src/gallium/drivers/virgl/virgl_winsys.h  |  2 --
>  .../winsys/virgl/drm/virgl_drm_winsys.c   |  6 -
>  5 files changed, 5 insertions(+), 33 deletions(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
> b/src/gallium/drivers/virgl/virgl_buffer.c
> index 2e63aebc72..97b2854b9c 100644
> --- a/src/gallium/drivers/virgl/virgl_buffer.c
> +++ b/src/gallium/drivers/virgl/virgl_buffer.c
> @@ -77,7 +77,7 @@ static void *virgl_buffer_transfer_map(struct pipe_context 
> *ctx,
>
> readback = virgl_res_needs_readback(vctx, >base, usage);
> if (readback)
> -  vs->vws->transfer_get(vs->vws, vbuf->base.hw_res, box, 
> trans->base.stride, trans->base.layer_stride, offset, level);
> +  vs->vws->transfer_get(vs->vws, vbuf->base.hw_res, box, offset, level);
>
> if (!(usage & PIPE_TRANSFER_UNSYNCHRONIZED))
>doflushwait = true;
> @@ -109,7 +109,7 @@ static void virgl_buffer_transfer_unmap(struct 
> pipe_context *ctx,
>   vbuf->base.clean = FALSE;
>   vctx->num_transfers++;
>   vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
> -   >box, trans->base.stride, 
> trans->base.layer_stride, trans->offset, transfer->level);
> +   >box, trans->offset, 
> transfer->level);
>
>}
> }
> diff --git a/src/gallium/drivers/virgl/virgl_context.c 
> b/src/gallium/drivers/virgl/virgl_context.c
> index ee28680b8f..19bc23dd1e 100644
> --- a/src/gallium/drivers/virgl/virgl_context.c
> +++ b/src/gallium/drivers/virgl/virgl_context.c
> @@ -71,7 +71,7 @@ static void virgl_buffer_flush(struct virgl_context *vctx,
>
> vctx->num_transfers++;
> rs->vws->transfer_put(rs->vws, vbuf->base.hw_res,
> - , 0, 0, box.x, 0);
> + , box.x, 0);
>
> util_range_set_empty(>valid_buffer_range);
>  }
> diff --git a/src/gallium/drivers/virgl/virgl_texture.c 
> b/src/gallium/drivers/virgl/virgl_texture.c
> index 150a5ebd8c..485b7cf1a7 100644
> --- a/src/gallium/drivers/virgl/virgl_texture.c
> +++ b/src/gallium/drivers/virgl/virgl_texture.c
> @@ -138,7 +138,6 @@ static void *virgl_texture_transfer_map(struct 
> pipe_context *ctx,
> const unsigned h = u_minify(vtex->base.u.b.height0, level);
> const unsigned nblocksy = util_format_get_nblocksy(format, h);
> bool is_depth = 
> util_format_has_depth(util_format_description(resource->format));
> -   uint32_t l_stride;
> bool doflushwait;
>
> doflushwait = virgl_res_needs_flush_wait(vctx, >base, usage);
> @@ -156,15 +155,6 @@ static void *virgl_texture_transfer_map(struct 
> pipe_context *ctx,
> trans->base.stride = vtex->stride[level];
> trans->base.layer_stride = trans->base.stride * nblocksy;
>
> -   if (resource->target != PIPE_TEXTURE_3D &&
> -   resource->target != PIPE_TEXTURE_CUBE &&
> -   resource->target != PIPE_TEXTURE_1D_ARRAY &&
> -   resource->target != PIPE_TEXTURE_2D_ARRAY &&
> -   resource->target != PIPE_TEXTURE_CUBE_ARRAY)
> -  l_stride = 0;
> -   else
> -  l_stride = trans->base.layer_stride;
> -
> if (is_depth && resource->nr_samples > 1) {
>struct pipe_resource tmp_resource;
>virgl_init_temp_resource_from_box(_resource, resource, box,
> @@ -188,7 +178,7 @@ static void *virgl_texture_transfer_map(struct 
> pipe_context *ctx,
>
> readback = virgl_res_needs_readback(vctx, >base, usage);
> if (readback)
> -  vs->vws->transfer_get(vs->vws, hw_res, box, trans->base.stride, 
> l_stride, offset, level);
> +  vs->vws->transfer_get(vs->vws, hw_res, box, offset, level);
>
> if (doflush

[Mesa-dev] [PATCH] tgsi: add some atomic opcodes to tgsi_opcode_infer_type

[Gurchetan Singh]

We don't have cases for atomic types, some of which are explicitly
signed or unsigned.

The other opcodes could have uint or int return types, based on the
sources.
---
 src/gallium/auxiliary/tgsi/tgsi_info.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.c 
b/src/gallium/auxiliary/tgsi/tgsi_info.c
index 4aa658785cf..6f3cd9c5304 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_info.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_info.c
@@ -253,6 +253,9 @@ tgsi_opcode_infer_src_type(enum tgsi_opcode opcode, uint 
src_idx)
   return TGSI_TYPE_SIGNED;
 
switch (opcode) {
+   case TGSI_OPCODE_ATOMUADD:
+   case TGSI_OPCODE_ATOMUMAX:
+   case TGSI_OPCODE_ATOMUMIN:
case TGSI_OPCODE_UIF:
case TGSI_OPCODE_TXF:
case TGSI_OPCODE_TXF_LZ:
@@ -268,6 +271,8 @@ tgsi_opcode_infer_src_type(enum tgsi_opcode opcode, uint 
src_idx)
case TGSI_OPCODE_U2I64:
case TGSI_OPCODE_MEMBAR:
   return TGSI_TYPE_UNSIGNED;
+   case TGSI_OPCODE_ATOMIMAX:
+   case TGSI_OPCODE_ATOMIMIN:
case TGSI_OPCODE_IMUL_HI:
case TGSI_OPCODE_I2F:
case TGSI_OPCODE_I2D:
-- 
2.13.5

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

Re: [Mesa-dev] [PATCH] virgl: enable ARB_gpu_shader_fp64

[Gurchetan Singh]

Tested-by: Gurchetan Singh 
Reviewed-by: Gurchetan Singh 
On Thu, Jun 7, 2018 at 7:24 PM Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> This enables ARB_gpu_shader_fp64 if the host provides it.
> ---
>  src/gallium/drivers/virgl/virgl_screen.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
> b/src/gallium/drivers/virgl/virgl_screen.c
> index e8d1c751779..2ba9708ebac 100644
> --- a/src/gallium/drivers/virgl/virgl_screen.c
> +++ b/src/gallium/drivers/virgl/virgl_screen.c
> @@ -213,6 +213,8 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
> param)
>return vscreen->caps.caps.v1.bset.transform_feedback_overflow_query;
> case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
>return vscreen->caps.caps.v2.shader_buffer_offset_alignment;
> +   case PIPE_CAP_DOUBLES:
> +  return vscreen->caps.caps.v1.bset.has_fp64;
> case PIPE_CAP_TEXTURE_GATHER_SM5:
> case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
> case PIPE_CAP_FAKE_SW_MSAA:
> @@ -268,7 +270,6 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
> param)
> case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
> case PIPE_CAP_SPARSE_BUFFER_PAGE_SIZE:
> case PIPE_CAP_TGSI_BALLOT:
> -   case PIPE_CAP_DOUBLES:
> case PIPE_CAP_TGSI_TES_LAYER_VIEWPORT:
> case PIPE_CAP_CAN_BIND_CONST_BUFFER_AS_VERTEX:
> case PIPE_CAP_ALLOW_MAPPED_BUFFERS_DURING_EXECUTION:
> --
> 2.14.3
>
> ___
> 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] features: add virgl to the GL features list

[Gurchetan Singh]

Reviewed-by: Gurchetan Singh 
On Wed, Jun 6, 2018 at 5:45 PM Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> This hopefully adds virgl to the correct places and current statuses
> of various extensions.
>
> virgl of course relies on two external things
> a) host driver that can support the features
> b) up to date host virglrenderer library that can support the features.
>
> This list will be maintained as latest (a) + (b) + mesa.
> ---
>  docs/features.txt | 80 +++
>  1 file changed, 40 insertions(+), 40 deletions(-)
>
> diff --git a/docs/features.txt b/docs/features.txt
> index ed4050cf98a..6e5cbc8b11e 100644
> --- a/docs/features.txt
> +++ b/docs/features.txt
> @@ -36,7 +36,7 @@ context as extensions.
>  Feature Status
>  --- 
> 
>
> -GL 3.0, GLSL 1.30 --- all DONE: freedreno, i965, nv50, nvc0, r600, radeonsi, 
> llvmpipe, softpipe, swr
> +GL 3.0, GLSL 1.30 --- all DONE: freedreno, i965, nv50, nvc0, r600, radeonsi, 
> llvmpipe, softpipe, swr, virgl
>
>glBindFragDataLocation, glGetFragDataLocation DONE
>GL_NV_conditional_render (Conditional rendering)  DONE ()
> @@ -68,7 +68,7 @@ GL 3.0, GLSL 1.30 --- all DONE: freedreno, i965, nv50, 
> nvc0, r600, radeonsi, llv
>  (*) freedreno, llvmpipe, softpipe, and swr have fake Multisample 
> anti-aliasing support
>
>
> -GL 3.1, GLSL 1.40 --- all DONE: freedreno, i965, nv50, nvc0, r600, radeonsi, 
> llvmpipe, softpipe, swr
> +GL 3.1, GLSL 1.40 --- all DONE: freedreno, i965, nv50, nvc0, r600, radeonsi, 
> llvmpipe, softpipe, swr, virgl
>
>Forward compatible context support/deprecations   DONE ()
>GL_ARB_draw_instanced (Instanced drawing) DONE ()
> @@ -81,7 +81,7 @@ GL 3.1, GLSL 1.40 --- all DONE: freedreno, i965, nv50, 
> nvc0, r600, radeonsi, llv
>GL_EXT_texture_snorm (Signed normalized textures) DONE ()
>
>
> -GL 3.2, GLSL 1.50 --- all DONE: i965, nv50, nvc0, r600, radeonsi, llvmpipe, 
> softpipe, swr
> +GL 3.2, GLSL 1.50 --- all DONE: i965, nv50, nvc0, r600, radeonsi, llvmpipe, 
> softpipe, swr, virgl
>
>Core/compatibility profiles   DONE
>Geometry shaders  DONE ()
> @@ -96,7 +96,7 @@ GL 3.2, GLSL 1.50 --- all DONE: i965, nv50, nvc0, r600, 
> radeonsi, llvmpipe, soft
>GLX_ARB_create_context_profileDONE
>
>
> -GL 3.3, GLSL 3.30 --- all DONE: i965, nv50, nvc0, r600, radeonsi, llvmpipe, 
> softpipe
> +GL 3.3, GLSL 3.30 --- all DONE: i965, nv50, nvc0, r600, radeonsi, llvmpipe, 
> softpipe, virgl
>
>GL_ARB_blend_func_extendedDONE 
> (freedreno/a3xx, swr)
>GL_ARB_explicit_attrib_location   DONE (all drivers 
> that support GLSL)
> @@ -112,9 +112,9 @@ GL 3.3, GLSL 3.30 --- all DONE: i965, nv50, nvc0, r600, 
> radeonsi, llvmpipe, soft
>
>  GL 4.0, GLSL 4.00 --- all DONE: i965/gen7+, nvc0, r600, radeonsi
>
> -  GL_ARB_draw_buffers_blend DONE (freedreno, 
> i965/gen6+, nv50, llvmpipe, softpipe, swr)
> -  GL_ARB_draw_indirect  DONE (freedreno, 
> i965/gen7+, llvmpipe, softpipe, swr)
> -  GL_ARB_gpu_shader5DONE (i965/gen7+)
> +  GL_ARB_draw_buffers_blend DONE (freedreno, 
> i965/gen6+, nv50, llvmpipe, softpipe, swr, virgl)
> +  GL_ARB_draw_indirect  DONE (freedreno, 
> i965/gen7+, llvmpipe, softpipe, swr, virgl)
> +  GL_ARB_gpu_shader5DONE (i965/gen7+, 
> virgl)
>- 'precise' qualifier DONE
>- Dynamically uniform sampler array indices   DONE (softpipe)
>- Dynamically uniform UBO array indices   DONE ()
> @@ -128,40 +128,40 @@ GL 4.0, GLSL 4.00 --- all DONE: i965/gen7+, nvc0, r600, 
> radeonsi
>- Interpolation functions DONE ()
>- New overload resolution rules   DONE
>GL_ARB_gpu_shader_fp64DONE (i965/gen7+, 
> llvmpipe, softpipe)
> -  GL_ARB_sample_shading DONE (i965/gen6+, 
> nv50)
> -  GL_ARB_shader_subroutine  DONE (freedreno, 
> i965/gen6+, nv50, llvmpipe, softpipe, swr)
> +  GL_ARB_sample_shading DONE (i965/gen6+, 
> nv50, virgl)
> +  GL_ARB_shader_subroutine  DONE (freedreno, 
> i965/gen6+, nv50, llvmpipe, softpipe, swr, virgl)
>GL_ARB_t

Re: [Mesa-dev] [PATCH] virgl: enable ARB_gpu_shader_fp64

[Gurchetan Singh]

Tested-by: Gurchetan Singh 
Reviewed-by: Gurchetan Singh 
On Mon, Jun 4, 2018 at 9:32 PM Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> This enables ARB_gpu_shader_fp64 if the host provides it.
> ---
>  src/gallium/drivers/virgl/virgl_screen.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
> b/src/gallium/drivers/virgl/virgl_screen.c
> index e8d1c751779..2ba9708ebac 100644
> --- a/src/gallium/drivers/virgl/virgl_screen.c
> +++ b/src/gallium/drivers/virgl/virgl_screen.c
> @@ -213,6 +213,8 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
> param)
>return vscreen->caps.caps.v1.bset.transform_feedback_overflow_query;
> case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
>return vscreen->caps.caps.v2.shader_buffer_offset_alignment;
> +   case PIPE_CAP_DOUBLES:
> +  return vscreen->caps.caps.v1.bset.has_fp64;
> case PIPE_CAP_TEXTURE_GATHER_SM5:
> case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
> case PIPE_CAP_FAKE_SW_MSAA:
> @@ -268,7 +270,6 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
> param)
> case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
> case PIPE_CAP_SPARSE_BUFFER_PAGE_SIZE:
> case PIPE_CAP_TGSI_BALLOT:
> -   case PIPE_CAP_DOUBLES:
> case PIPE_CAP_TGSI_TES_LAYER_VIEWPORT:
> case PIPE_CAP_CAN_BIND_CONST_BUFFER_AS_VERTEX:
> case PIPE_CAP_ALLOW_MAPPED_BUFFERS_DURING_EXECUTION:
> --
> 2.14.3
>
> ___
> 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] virgl: add shader offset alignment to to v2 caps struct

[Gurchetan Singh]

I sent out a patch that adds capability bits to this struct, and the
first bit is the tgsi invariant capability.  It's dependent on this
patch to apply correctly to master.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] virgl: add shader offset alignment to to v2 caps struct

[Gurchetan Singh]

Got it, thanks.  Let me send a patch to virglrenderer to change
tgsi_invariant to some sort of bitset, since when it lands it'll just
need one bit.
On Mon, Jun 4, 2018 at 9:39 AM Gert Wollny  wrote:
>
> Am Montag, den 04.06.2018, 09:07 -0700 schrieb Gurchetan Singh:
> > The tgsi_invariant code never landed in the Mesa side.  Is the caps
> > code is resilient enough to handle this case?  From my understanding
> > the guest caps and host caps don't have to match exactly, and the
> > "right thing" will be done.
>
> I don't think so. When I implemented what I sent as RFC to the virgl
> list, the tgsi_invariant and shader_buffer_offset_alignment were in the
> virglrenderer caps.v2 struct but not in the guest side version of the
> struct, and since I added the new values after these two in
> virglrenderer the output was garbage, but after adding these two values
> also in the guest side struct the output was okay.
>
> Brousing through the qemu code it seems to me that the caps structure
> is simply send as a blob, and both sides have to know the layout to
> make sense of it.
>
> Best,
> Gert
>
> > On Mon, Jun 4, 2018 at 6:03 AM Gert Wollny 
> > wrote:
> > >
> > > Am Donnerstag, den 12.04.2018, 18:11 -0700 schrieb
> > > gurchetansi...@chromium.org:
> > > > This is the SSBO analogue to fe0647. User supplied data must
> > > > be a multiple of GL_SHADER_STORAGE_BUFFER_OFFSET_ALIGNMENT.
> > > >
> > > > This fixes 44 GLES31 tests on airlied@'s GLES31 sketch branches
> > > > with
> > > > Nvidia hardware, but this patch standalone can applied to master.
> > > > The
> > > > alignment restriction on Nvidia is 32, hence the default value.
> > > >
> > > > Example tests:
> > > >dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.0
> > > >dEQP-
> > > > GLES31.functional.ssbo.layout.multi_basic_types.single_buffer.std
> > > > 430
> > > >
> > > > v2: Move to a better place in case statement
> > > > ---
> > > >  src/gallium/drivers/virgl/virgl_hw.h | 1 +
> > > >  src/gallium/drivers/virgl/virgl_screen.c | 3 ++-
> > > >  src/gallium/drivers/virgl/virgl_winsys.h | 1 +
> > > >  3 files changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/src/gallium/drivers/virgl/virgl_hw.h
> > > > b/src/gallium/drivers/virgl/virgl_hw.h
> > > > index 93849c03dd..624be3b271 100644
> > > > --- a/src/gallium/drivers/virgl/virgl_hw.h
> > > > +++ b/src/gallium/drivers/virgl/virgl_hw.h
> > > > @@ -286,6 +286,7 @@ struct virgl_caps_v2 {
> > > >  int32_t max_texture_gather_offset;
> > > >  uint32_t texture_buffer_offset_alignment;
> > > >  uint32_t uniform_buffer_offset_alignment;
> > > > +uint32_t shader_buffer_offset_alignment;
> > > >  };
> > >
> > > This conflicts with
> > >
> > >https://patchwork.freedesktop.org/patch/216081/
> > >
> > > (Dave, you wrote there that this landed,  but I don't see it on the
> > > mesa side).
> > >
> > > In virglrenderer the order is
> > > ...
> > > uint32_t uniform_buffer_offset_alignment;
> > > uint32_t tgsi_invariant;
> > > uint32_t shader_buffer_offset_alignment;
> > >
> > > Best,
> > > Gert
> > >
> > > >
> > > >  union virgl_caps {
> > > > diff --git a/src/gallium/drivers/virgl/virgl_screen.c
> > > > b/src/gallium/drivers/virgl/virgl_screen.c
> > > > index 02613f1866..f183752d63 100644
> > > > --- a/src/gallium/drivers/virgl/virgl_screen.c
> > > > +++ b/src/gallium/drivers/virgl/virgl_screen.c
> > > > @@ -198,6 +198,8 @@ virgl_get_param(struct pipe_screen *screen,
> > > > enum
> > > > pipe_cap param)
> > > >return vscreen->caps.caps.v1.bset.has_sample_shading;
> > > > case PIPE_CAP_CULL_DISTANCE:
> > > >return vscreen->caps.caps.v1.bset.has_cull;
> > > > +   case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
> > > > +  return vscreen-
> > > > >caps.caps.v2.shader_buffer_offset_alignment;
> > > > case PIPE_CAP_TEXTURE_GATHER_SM5:
> > > > case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
> > > > case PIPE_CAP_FAKE_SW_MSAA:
> > > > @@ -227,7 +229,6 @@ virgl_get_param(struct pipe_screen *screen,
>

Re: [Mesa-dev] [PATCH] virgl: add shader offset alignment to to v2 caps struct

[Gurchetan Singh]

The tgsi_invariant code never landed in the Mesa side.  Is the caps
code is resilient enough to handle this case?  From my understanding
the guest caps and host caps don't have to match exactly, and the
"right thing" will be done.
On Mon, Jun 4, 2018 at 6:03 AM Gert Wollny  wrote:
>
> Am Donnerstag, den 12.04.2018, 18:11 -0700 schrieb
> gurchetansi...@chromium.org:
> > This is the SSBO analogue to fe0647. User supplied data must
> > be a multiple of GL_SHADER_STORAGE_BUFFER_OFFSET_ALIGNMENT.
> >
> > This fixes 44 GLES31 tests on airlied@'s GLES31 sketch branches with
> > Nvidia hardware, but this patch standalone can applied to master. The
> > alignment restriction on Nvidia is 32, hence the default value.
> >
> > Example tests:
> >dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.0
> >dEQP-
> > GLES31.functional.ssbo.layout.multi_basic_types.single_buffer.std430
> >
> > v2: Move to a better place in case statement
> > ---
> >  src/gallium/drivers/virgl/virgl_hw.h | 1 +
> >  src/gallium/drivers/virgl/virgl_screen.c | 3 ++-
> >  src/gallium/drivers/virgl/virgl_winsys.h | 1 +
> >  3 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/drivers/virgl/virgl_hw.h
> > b/src/gallium/drivers/virgl/virgl_hw.h
> > index 93849c03dd..624be3b271 100644
> > --- a/src/gallium/drivers/virgl/virgl_hw.h
> > +++ b/src/gallium/drivers/virgl/virgl_hw.h
> > @@ -286,6 +286,7 @@ struct virgl_caps_v2 {
> >  int32_t max_texture_gather_offset;
> >  uint32_t texture_buffer_offset_alignment;
> >  uint32_t uniform_buffer_offset_alignment;
> > +uint32_t shader_buffer_offset_alignment;
> >  };
> This conflicts with
>
>https://patchwork.freedesktop.org/patch/216081/
>
> (Dave, you wrote there that this landed,  but I don't see it on the
> mesa side).
>
> In virglrenderer the order is
> ...
> uint32_t uniform_buffer_offset_alignment;
> uint32_t tgsi_invariant;
> uint32_t shader_buffer_offset_alignment;
>
> Best,
> Gert
>
> >
> >  union virgl_caps {
> > diff --git a/src/gallium/drivers/virgl/virgl_screen.c
> > b/src/gallium/drivers/virgl/virgl_screen.c
> > index 02613f1866..f183752d63 100644
> > --- a/src/gallium/drivers/virgl/virgl_screen.c
> > +++ b/src/gallium/drivers/virgl/virgl_screen.c
> > @@ -198,6 +198,8 @@ virgl_get_param(struct pipe_screen *screen, enum
> > pipe_cap param)
> >return vscreen->caps.caps.v1.bset.has_sample_shading;
> > case PIPE_CAP_CULL_DISTANCE:
> >return vscreen->caps.caps.v1.bset.has_cull;
> > +   case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
> > +  return vscreen->caps.caps.v2.shader_buffer_offset_alignment;
> > case PIPE_CAP_TEXTURE_GATHER_SM5:
> > case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
> > case PIPE_CAP_FAKE_SW_MSAA:
> > @@ -227,7 +229,6 @@ virgl_get_param(struct pipe_screen *screen, enum
> > pipe_cap param)
> > case PIPE_CAP_TGSI_PACK_HALF_FLOAT:
> > case PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL:
> > case PIPE_CAP_TGSI_FS_FACE_IS_INTEGER_SYSVAL:
> > -   case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
> > case PIPE_CAP_INVALIDATE_BUFFER:
> > case PIPE_CAP_GENERATE_MIPMAP:
> > case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
> > diff --git a/src/gallium/drivers/virgl/virgl_winsys.h
> > b/src/gallium/drivers/virgl/virgl_winsys.h
> > index 99e98ad9c9..c36b957aba 100644
> > --- a/src/gallium/drivers/virgl/virgl_winsys.h
> > +++ b/src/gallium/drivers/virgl/virgl_winsys.h
> > @@ -134,5 +134,6 @@ static inline void
> > virgl_ws_fill_new_caps_defaults(struct virgl_drm_caps *caps)
> > caps->caps.v2.max_texture_gather_offset = 7;
> > caps->caps.v2.texture_buffer_offset_alignment = 32;
> > caps->caps.v2.uniform_buffer_offset_alignment = 256;
> > +   caps->caps.v2.shader_buffer_offset_alignment = 32;
> >  }
> >  #endif
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Gurchetan Singh]

Reviewed-by: Gurchetan Singh <gurchetansi...@chromium.org>



On Wed, May 23, 2018 at 1:36 AM 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.
>
> The logic is based on knowledge that is shared with
> _mesa_format_matches_format_and_type() but we cannot assert that the
> results match as we don't have all the starting information at both
> points. So leave the assert out and hope CI comes soon to save us all.
>
> v2: * Let R10G10B10A2_UINT fall back to GL_RGBA_INTEGER (Eric Anholt)
> * Assert with _mesa_format_matches_format_and_type (Eric Anholt)
>
> v3: * Remove the assert, as it won't be reliable (Eric Anholt)
>
> Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
> ---
>  src/mesa/main/framebuffer.c | 68 +++--
>  1 file changed, 43 insertions(+), 25 deletions(-)
>
> diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
> index 8e751b453b75..b1a544b5646d 100644
> --- a/src/mesa/main/framebuffer.c
> +++ b/src/mesa/main/framebuffer.c
> @@ -834,18 +834,52 @@ _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);
> +  GLenum data_type;
> +  GLuint comps;
>
> -  if (format == MESA_FORMAT_B8G8R8A8_UNORM)
> +  _mesa_uncompressed_format_to_type_and_comps(format, _type,
> );
> +
> +  switch (format) {
> +  case MESA_FORMAT_RGBA_UINT8:
> + return GL_RGBA_INTEGER;
> +  case MESA_FORMAT_B8G8R8A8_UNORM:
>   return GL_BGRA;
> -  else if (format == MESA_FORMAT_B5G6R5_UNORM)
> +  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_INT_2_10_10_10_REV:
> +  case GL_UNSIGNED_SHORT:
>case GL_INT:
> +  case GL_SHORT:
> +  case GL_BYTE:
>   return GL_RGBA_INTEGER;
>default:
>   return GL_RGBA;
> @@ -882,29 +916,13 @@ _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;
> +  const mesa_format format = fb->_ColorReadBuffer->Format;
> +  GLenum data_type;
> +  GLuint comps;
>
> -  if (format == MESA_FORMAT_B10G10R10A2_UNORM ||
> -  format == MESA_FORMAT_B10G10R10X2_UNORM ||
> -  format == MESA_FORMAT_R10G10B10A2_UNORM ||
> -  format == MESA_FORMAT_R10G10B10X2_UNORM)
> - return GL_UNSIGNED_INT_2_10_10_10_REV;
> +  _mesa_uncompressed_format_to_type_and_comps(format, _type,
> );
>
> -  switch (data_type) {
> -  case GL_SIGNED_NORMALIZED:
> - return GL_BYTE;
> -  case GL_UNSIGNED_INT:
> -   

Re: [Mesa-dev] [RFC PATCH] virgl: Always assume that ORIGIN_UPPER_LEFT and PIXEL_CENTER* are supported

[Gurchetan Singh]

Reviewed-by: Gurchetan Singh <gurchetansi...@chromium.org>


On Mon, May 21, 2018 at 12:37 AM Gert Wollny <gert.wol...@collabora.com>
wrote:

> Am Donnerstag, den 17.05.2018, 12:33 +0200 schrieb Gert Wollny:
> > The driver must support at least one of
> >
> >   PIPE_CAP_TGSI_FS_COORD_ORIGIN_UPPER_LEFT
> >   PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT
> >
> > and one of
> >
> >   PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER
> >   PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER
> >
> > otherwise glsl_to_tgsi will fire an assert.
> >
> > ORIGIN_UPPER_LEFT is the default convention, and is supported by
> > all mesa drivers, hence it seems reasonable to always report the caps
> > to be enabled.  On gles ORIGIN_LOWER_LEFT is generally not supported,
> > so we rely on the caps reported by the host that depend on whether we
> > run on an GL or an EGL host.
> >
> > For PIXEL_CENTER it is completely host driver dependend on what is
> > supported, and since we do not report the actual host driver
> > capabilities
> > it is best to mark both as supported, this is how it works for a GL
> > host too.
> >
> > Fixes:
> >   dEQP-GLES3.functional.shaders.builtin_variable.fragcoord_xyz
> >   dEQP-GLES3.functional.shaders.metamorphic.bubblesort_flag.variant_1
> >   dEQP-GLES3.functional.shaders.metamorphic.bubblesort_flag.variant_2
> >
> > Signed-off-by: Gert Wollny <gert.wol...@collabora.com>
> > ---
> > When I return 1 for  PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT too,
> > the test fail on an r600g gle host. Likewise, when I disable one of
> > the two PIXEL_CENTER caps.
> >
> > However, I send this as an RFC, because there are some of the
> > *texture* tests that flip: some start to pass with this patch and
> > some start to fail, in total 16 test are fixed with this patch and 15
> > regress on Intel. I have not yet established whether these tests are
> > actually unstable.
>
> After quite some testing I've come to the conclusion that the tests
> that flip between Pass and Fail are tests that are generally unstable
> when run inside Qemu, so it should be save to apply it.
>
> Best,
> Gert
>
> >
> > thanks for any comments.
> > Gert
> >
> >  src/gallium/drivers/virgl/virgl_screen.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/drivers/virgl/virgl_screen.c
> > b/src/gallium/drivers/virgl/virgl_screen.c
> > index 1ca9e85de7..f4fdc61b14 100644
> > --- a/src/gallium/drivers/virgl/virgl_screen.c
> > +++ b/src/gallium/drivers/virgl/virgl_screen.c
> > @@ -88,9 +88,10 @@ virgl_get_param(struct pipe_screen *screen, enum
> > pipe_cap param)
> > case PIPE_CAP_INDEP_BLEND_FUNC:
> >return vscreen->caps.caps.v1.bset.indep_blend_func;
> > case PIPE_CAP_TGSI_FS_COORD_ORIGIN_UPPER_LEFT:
> > -   case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
> > case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER:
> > case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER:
> > +  return 1;
> > +   case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
> >return vscreen->caps.caps.v1.bset.fragment_coord_conventions;
> > case PIPE_CAP_DEPTH_CLIP_DISABLE:
> >return vscreen->caps.caps.v1.bset.depth_clip_disable;
> ___
> 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: set texture buffer offset alignment to disable ARB_texture_buffer_range.

[Gurchetan Singh]

Reviewed-by: Gurchetan Singh <gurchetansi...@chromium.org>


On Fri, May 18, 2018 at 6:01 AM Elie Tournier <tournier.e...@gmail.com>
wrote:

> Wrong ML. I add <mesa-dev@lists.freedesktop.org>
>
> On Fri, May 18, 2018 at 10:46:29AM +1000, Dave Airlie wrote:
> > From: Dave Airlie <airl...@redhat.com>
> >
> > The host side hasn't got support for this feature yet, so don't enable it
> > unless we get the caps from the host.
> >
> > This makes the texture buffer range piglit tests skip now.
> >
> > Fixes: fe0647df5a7 (virgl: add offset alignment values to to v2 caps
> struct)
> Acked-by: Elie Tournier <elie.tourn...@collabora.com>
> > ---
> >  src/gallium/drivers/virgl/virgl_winsys.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/drivers/virgl/virgl_winsys.h
> b/src/gallium/drivers/virgl/virgl_winsys.h
> > index 99e98ad9c9c..690e610e199 100644
> > --- a/src/gallium/drivers/virgl/virgl_winsys.h
> > +++ b/src/gallium/drivers/virgl/virgl_winsys.h
> > @@ -132,7 +132,7 @@ static inline void
> virgl_ws_fill_new_caps_defaults(struct virgl_drm_caps *caps)
> > caps->caps.v2.max_texel_offset = 7;
> > caps->caps.v2.min_texture_gather_offset = -8;
> > caps->caps.v2.max_texture_gather_offset = 7;
> > -   caps->caps.v2.texture_buffer_offset_alignment = 32;
> > +   caps->caps.v2.texture_buffer_offset_alignment = 0;
> > caps->caps.v2.uniform_buffer_offset_alignment = 256;
> >  }
> >  #endif
> > --
> > 2.14.3
> >
> > ___
> > virglrenderer-devel mailing list
> > virglrenderer-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel
> ___
> virglrenderer-devel mailing list
> virglrenderer-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Gurchetan Singh]

Yes, it seems needed for the GLES on GLES work.  Still needs to land:

Reviewed-by: Gurchetan Singh <gurchetansi...@chromium.org>
On Wed, May 9, 2018 at 7:15 PM Dave Airlie <airl...@gmail.com> wrote:

> On 4 April 2018 at 02:06, Jakob Bornecrantz <ja...@collabora.com> wrote:
> > Signed-off-by: Jakob Bornecrantz <ja...@collabora.com>

> not sure if still needed or not, but

> Reviewed-by: Dave Airlie <airl...@redhat.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 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] virgl: clear render state before submitting clear command

[Gurchetan Singh]

In vrend_clear, we already save and restore colormasks and stencils:

https://cgit.freedesktop.org/virglrenderer/commit/?id=b75e0a1dabdfbda44c310a69026a9dbd7d980294
https://cgit.freedesktop.org/virglrenderer/commit/?id=252b00d77c30ce39608c1a9de18523cbdcaca623

It would be nice if we can put everything on the host side.  Wouldn't
the following code also solve the RASTERIZER_DISCARD problem?

if (ctx->sub->hw_rs_state.rasterizer_discard)
glDisable(GL_RASTERIZER_DISCARD)

...

glClear(..)

...

if (ctx->sub->hw_rs_state.rasterizer_discard)
glEnable(GL_RASTERIZER_DISCARD)


On Mon, May 7, 2018 at 1:18 AM, Gert Wollny  wrote:
> Virgl/virglrenderer implements the gallium clear command via a call to
> glClear. However, gallium clear does not take render states like e.g.
> RASTERIZER_DISCARD into account, but glClear does, and gallium st_Clear
> does not updated the latest rendering state on the host. Hence, in order
> to properly emulate gallium clear with glClear, all rendering states that
> influence glClear must be set to their default values on the host before
> submitting the actual clear command and restore the original state
> afterwards (Thanks to Ilia Mirkin for helpint me understand this).
>
> This patch implements the according mechanism in virgl_clear, the clear state
> is defined like in mesa/st/st_cb_clear.c: st_init_clear.
>
> Fixes CTS:
>dEQP-GLES3.functional.rasterizer_discard.fbo.*
>
> Signed-off-by: Gert Wollny 
> ---
> PS : I have no mesa commits rights.
>
>  src/gallium/drivers/virgl/virgl_context.c | 24 ++-
>  src/gallium/drivers/virgl/virgl_context.h |  2 ++
>  2 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_context.c 
> b/src/gallium/drivers/virgl/virgl_context.c
> index 8d701bb8f4..55ddbcf7df 100644
> --- a/src/gallium/drivers/virgl/virgl_context.c
> +++ b/src/gallium/drivers/virgl/virgl_context.c
> @@ -305,9 +305,8 @@ static void virgl_bind_rasterizer_state(struct 
> pipe_context *ctx,
>  void *rs_state)
>  {
> struct virgl_context *vctx = virgl_context(ctx);
> -   uint32_t handle = (unsigned long)rs_state;
> -
> -   virgl_encode_bind_object(vctx, handle, VIRGL_OBJECT_RASTERIZER);
> +   vctx->last_render_state = rs_state;
> +   virgl_encode_bind_object(vctx, (unsigned long)rs_state, 
> VIRGL_OBJECT_RASTERIZER);
>  }
>
>  static void virgl_delete_rasterizer_state(struct pipe_context *ctx,
> @@ -568,8 +567,19 @@ static void virgl_clear(struct pipe_context *ctx,
>  double depth, unsigned stencil)
>  {
> struct virgl_context *vctx = virgl_context(ctx);
> +   struct pipe_rasterizer_state *old_state = vctx->last_render_state;
>
> +   if (!vctx->clear_render_state) {
> +  struct pipe_rasterizer_state clear_state;
> +  memset(_state, 0, sizeof(clear_state));
> +  clear_state.depth_clip = 1;
> +  clear_state.bottom_edge_rule = 1;
> +  clear_state.half_pixel_center = 1;
> +  vctx->clear_render_state = virgl_create_rasterizer_state(ctx, 
> _state);
> +   }
> +   virgl_bind_rasterizer_state(ctx, vctx->clear_render_state);
> virgl_encode_clear(vctx, buffers, color, depth, stencil);
> +   virgl_bind_rasterizer_state(ctx, old_state);
>  }
>
>  static void virgl_draw_vbo(struct pipe_context *ctx,
> @@ -844,6 +854,9 @@ virgl_context_destroy( struct pipe_context *ctx )
> struct virgl_context *vctx = virgl_context(ctx);
> struct virgl_screen *rs = virgl_screen(ctx->screen);
>
> +   if (vctx->clear_render_state)
> +  virgl_delete_rasterizer_state(ctx, vctx->clear_render_state);
> +
> vctx->framebuffer.zsbuf = NULL;
> vctx->framebuffer.nr_cbufs = 0;
> virgl_encoder_destroy_sub_ctx(vctx, vctx->hw_sub_ctx_id);
> @@ -948,6 +961,7 @@ struct pipe_context *virgl_context_create(struct 
> pipe_screen *pscreen,
> virgl_encoder_create_sub_ctx(vctx, vctx->hw_sub_ctx_id);
>
> virgl_encoder_set_sub_ctx(vctx, vctx->hw_sub_ctx_id);
> +
> return >base;
>  fail:
> return NULL;
> diff --git a/src/gallium/drivers/virgl/virgl_context.h 
> b/src/gallium/drivers/virgl/virgl_context.h
> index 3492dcfa49..a1c1d1a60c 100644
> --- a/src/gallium/drivers/virgl/virgl_context.h
> +++ b/src/gallium/drivers/virgl/virgl_context.h
> @@ -74,6 +74,8 @@ struct virgl_context {
>
> struct primconvert_context *primconvert;
> uint32_t hw_sub_ctx_id;
> +   void *last_render_state;
> +   void *clear_render_state;
>  };
>
>  static inline struct virgl_sampler_view *
> --
> 2.17.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH] mesa/st/cb_clear: in st_Clear also validate the render state (needed by virgl)

[Gurchetan Singh]

On Fri, May 4, 2018 at 1:11 PM, Ilia Mirkin  wrote:
> On Fri, May 4, 2018 at 2:50 PM, Gert Wollny  wrote:
>> For that reason I think that a render state validation within st_Clear
>> makes sense, because it makes sure that the states like  SCISSOR_TEST
>> or DISCARD_RASTERIZER are properly send to the driver, before clear()
>> is executed that makes use of these states. And while the workaround
>> for DISCARD_RASTERIZER is possible because if it is set then the host
>> should actually never see the clear command, SCISSOR_TEST is different,
>> its state can not be guessed on the host.
>>
>> Anyway, I happily take every hint on how this can be fixed directly in
>> virgl_clear or virgl in general, and thank you for taking the time to
>> answer me,
>
> I thought someone else took care of the scissor thing for clears. At
> least they were asking about it.

Yes, there were similar problems with stencils and scissors.

https://cgit.freedesktop.org/virglrenderer/commit/?id=b75e0a1dabdfbda44c310a69026a9dbd7d980294
https://cgit.freedesktop.org/virglrenderer/commit/?id=252b00d77c30ce39608c1a9de18523cbdcaca623

Essentially, we need save and restore the prior rasterizer state.

> I have to assume that virglrenderer keeps track of the last-set
> rasterizer state. Based on that, you have to turn off scissors,
> rasterizer discard, window rectangles, stencil tests, sample masks(?),
> and anything else which affects clears (have a look at st_Clear --
> anything that causes it to hit the fallback path which draws should be
> something you turn off because calling glClear() in virglrenderer).
>
> If you don't keep track of the last-set rasterizer state, then now may
> be a good time to start :)
>
>   -ilia
> ___
> 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/main/readpix: Correct handling of packed floating point values

[Gurchetan Singh]

For those wondering why the dEQP CTS tests this fixes (for example
dEQP-GLES3.functional.fragment_out.basic.float.r11f_g11f_b10f_lowp_float)
pass outside the VM, it seems it's because the test cases read pixels
with type = GL_FLOAT.  virglrenderer always sets type =
GL_UNSIGNED_INT_10F_11F_11F_REV on the host when reading back
GL_R11F_G11F_B10F and probably converts to GL_FLOAT on the guest.  I
guess nobody, even conformance suites, wanted to deal with
GL_UNSIGNED_INT_10F_11F_11F_REV ...

Reviewed-by: Gurchetan Singh <gurchetansi...@chromium.org>
(don't have commit access so hopefully someone merges this)

On Fri, Apr 27, 2018 at 9:04 AM, Gert Wollny <gw.foss...@gmail.com> wrote:
> From: Gert Wollny <gert.wol...@collabora.com>
>
> Make sure that clamping in the pixel transfer operations is enabled/disabled
> for packed floating point values just like it is done for single normal and
> half precision floating point values.
>
> This fixes a series of CTS tests with virgl that use r11f_g11f_b10f
> buffers as target, and where virglrenderer reads these surfaces back
> using the format GL_UNSIGNED_INT_10F_11F_11F_REV.
>
> Signed-off-by: Gert Wollny <gert.wol...@collabora.com>
> ---
> PS: I don't have write permissions to mesa git
>
>  src/mesa/main/readpix.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
> index a4eea3043d..c5fc66988b 100644
> --- a/src/mesa/main/readpix.c
> +++ b/src/mesa/main/readpix.c
> @@ -106,7 +106,8 @@ _mesa_get_readpixels_transfer_ops(const struct gl_context 
> *ctx,
>/* For blit-based ReadPixels packing, the clamping is done 
> automatically
> * unless the type is float. */
>if (_mesa_get_clamp_read_color(ctx, ctx->ReadBuffer) &&
> -  (type == GL_FLOAT || type == GL_HALF_FLOAT)) {
> +  (type == GL_FLOAT || type == GL_HALF_FLOAT ||
> +   type == GL_UNSIGNED_INT_10F_11F_11F_REV)) {
>   transferOps |= IMAGE_CLAMP_BIT;
>}
> }
> @@ -114,7 +115,8 @@ _mesa_get_readpixels_transfer_ops(const struct gl_context 
> *ctx,
>/* For CPU-based ReadPixels packing, the clamping must always be done
> * for non-float types, */
>if (_mesa_get_clamp_read_color(ctx, ctx->ReadBuffer) ||
> -  (type != GL_FLOAT && type != GL_HALF_FLOAT)) {
> +  (type != GL_FLOAT && type != GL_HALF_FLOAT &&
> +   type != GL_UNSIGNED_INT_10F_11F_11F_REV)) {
>   transferOps |= IMAGE_CLAMP_BIT;
>}
> }
> --
> 2.17.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/10] dri_interface: add __DRI_IMAGE_TRANSFER_USER_STRIDE

[Gurchetan Singh]

On Mon, Apr 30, 2018 at 2:38 PM, Marek Olšák  wrote:
> On Mon, Apr 30, 2018 at 3:11 PM, Eric Anholt  wrote:
>>
>> Marek Olšák  writes:
>>
>> > From: Nicolai Hähnle 
>> >
>> > Allow the caller to specify the row stride (in bytes) with which an
>> > image
>> > should be mapped. Note that completely ignoring USER_STRIDE is a valid
>> > implementation of mapImage.
>> >
>> > This is horrible API design. Unfortunately, cros_gralloc does indeed
>> > have
>> > a horrible API design -- in that arbitrary images should be allowed to
>> > be
>> > mapped with the stride that a linear image of the same width would have.
>> >
>> > There is no separate capability bit because it's unclear how stricter
>> > requirements should be defined.
>>
>> I think that this is a bad interface, and you should just push an extra
>> copy into the caller so that they're encouraged to fix their bad API
>> instead of pushing their mistake down into Mesa ABI that we get stuck
>> with forever.
>
>
> I agree that it's a very bad interface. I would also like cros_gralloc not
> to do silly things. I don't know what kind of hardware gralloc is designed
> around - it's certainly not designed around modern GPUs, that part is clear.
> The emulation of the user-specified stride increases memory usage
> (especially if the stride is larger than necessary), so it's a bad idea by
> definition. I don't know if it's still possible to change gralloc not to use
> it.

You're welcome to submit patches to cros_gralloc / minigbm, but
ultimately we have to conform to these Android gralloc interfaces:

https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc.h
https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h
https://android.googlesource.com/platform/hardware/interfaces/+/master/graphics/allocator/2.0/IAllocator.hal
https://android.googlesource.com/platform/hardware/interfaces/+/master/graphics/mapper/2.0/IMapper.hal

minigbm is still on gralloc0, but I don't think the newer interfaces
will help with your problem (i.e, returning the stride in the lock
function).  The API is better versioned now, so perhaps you could file
a bug on the Google tracker (https://buganizer.corp.google.com/)
explaining the AMD use case?  It might take until the next release (Q)
to see any changes.

> The reason the feature is pushed into the driver is that only the driver can
> efficiently force a certain stride where the stride is much larger than
> box.width*bpp of the mapping, and still only tile/detile box.width*bpp.
>
> Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/10] dri_interface: add __DRI_IMAGE_TRANSFER_USER_STRIDE

[Gurchetan Singh]

On Fri, Apr 27, 2018 at 2:00 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
> On 26.04.2018 04:30, Marek Olšák wrote:
>>
>> On Wed, Apr 25, 2018 at 6:56 PM, Gurchetan Singh
>> <gurchetansi...@chromium.org <mailto:gurchetansi...@chromium.org>> wrote:
>>
>> On Wed, Apr 25, 2018 at 2:16 PM, Marek Olšák <mar...@gmail.com
>> <mailto:mar...@gmail.com>> wrote:
>> > From: Nicolai Hähnle <nicolai.haeh...@amd.com
>> <mailto:nicolai.haeh...@amd.com>>
>> >
>> > Allow the caller to specify the row stride (in bytes) with which an
>> image
>> > should be mapped. Note that completely ignoring USER_STRIDE is a
>> valid
>> > implementation of mapImage.
>> >
>> > This is horrible API design. Unfortunately, cros_gralloc does indeed
>> have
>> > a horrible API design -- in that arbitrary images should be allowed
>> to be
>> > mapped with the stride that a linear image of the same width would
>> have.
>>
>> Yes, unfortunately the gralloc API doesn't return the stride when
>> (*lock) is called.  However, the stride is returned during (*alloc).
>> Currently, for the dri backend, minigbm uses
>> __DRI_IMAGE_ATTRIB_STRIDE to compute the pixel stride given to
>> Android.
>>
>> Is AMD seeing problems with the current approach (I haven't seen any
>> bugs filed for this issue)?
>>
>> Another possible solution is to call mapImage()/unmapImage right after
>> allocating the image, and use the stride returned by mapImage() to
>> compute the pixel stride.  That could also fix whatever bugs AMD is
>> seeing.
>>
>>
>> Thanks. You cleared it up to me. It looks like that everything we've been
>> told so far is BS. This series isn't needed.
>>
>> The solution is to do this in the amdgpu minigbm backend at alloc time:
>> stride = align(width * Bpp, 64);
>>
>> Later chips should change that to:
>> stride = align(width * Bpp, 256);
>>
>> No querying needed. What do you think?
>
>
> I don't see how this approach can possibly work unless we always map the
> whole texture.
>
> The whole problem with the fixed stride is that in many cases, we allocate a
> staging texture. The reasonable thing to do for a sane API (i.e., everything
> except ChromeOS)

Unfortunately, we only control the API for our fork of gbm (gbm.h in
minigbm) and not gralloc
(gralloc.h / gralloc1.h / {IAllocator, IMapper.hal}).

> is to allocate a staging texture that is sized correctly
> for the area that you want to map. But since we don't know at texture
> allocation time what sizes of the texture will be mapped, we cannot do that.
>
> That was the whole point of the USER_STRIDE business. There are two
> alternatives I can see:
>
> 1. Change minigbm so that it always maps the entire texture regardless of
> what the caller requests. This is a very simple fix, but it has the downside
> that the driver will always blit the entire surface to staging even if only
> a single pixel is needed. That can obviously bite us for performance and
> power, which is why I didn't want to go down that route.

The DRI backend maps the entire texture currently:

https://chromium.googlesource.com/chromiumos/platform/minigbm/+/master/dri.c#266

This is consistent with what other drivers do as well, since GEM
ioctls (i.e, DRM_IOCTL_I915_GEM_MMAP_GTT) don't support partial
mappings.  I assume the AMD map ioctl also maps the entire buffer, but
the shadow buffer is smaller.

> 2. Instead of having a USER_STRIDE interface, just simplify the story to
> saying that whenever a transfer allocates a staging texture, it should
> allocate a texture sized for the entire texture, but perform blits only for
> the region that the user has requested.
> This ends up being the same thing in the end, but perhaps it's better as an
> interface because it's more explicit about what's happening.
>
> By the way: the fact that gralloc wants to *cache* mappings will also cause
> us pain, but that's perhaps something we should really just change in
> gralloc.

We modified minigbm to not cache mappings for AMD devices
(crrev.com/c/990892).

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

Re: [Mesa-dev] [PATCH 02/10] dri_interface: add __DRI_IMAGE_TRANSFER_USER_STRIDE

[Gurchetan Singh]

On Thu, Apr 26, 2018 at 3:08 PM, Marek Olšák <mar...@gmail.com> wrote:
> On Thu, Apr 26, 2018 at 2:40 PM, Gurchetan Singh
> <gurchetansi...@chromium.org> wrote:
>>
>> On Thu, Apr 26, 2018 at 10:23 AM, Marek Olšák <mar...@gmail.com> wrote:
>> > Gurchetan, can you confirm that the stride returned at alloc() is only
>> > used
>> > for CPU access and not for display programming?
>>
>> It really depends on how you couple your HWComposer and gralloc HALs
>> together.  For example, drm_hwcomposer calls drmModeAddFB2 from with
>> the allocation time stride:
>>
>> https://anongit.freedesktop.org/git/drm_hwcomposer.git
>>
>> For the minigbm + wayland_hwcomposer use case, we have a
>> GRALLOC_DRM_GET_STRIDE call that returns the allocation time pixel
>> stride to the Wayland client.
>>
>> We could:
>>   - Return the stride that works for display with
>> GRALLOC_DRM_GET_STRIDE
>>   - Return the stride that works for CPU access with the alloc() call.
>>
>> Just curious -- which Android app and/or test case is running into this
>> issue?
>
>
> There is some cros_gralloc test case that is failing, but nobody told me
> which one.

I can't find any bugs filed on the subject either (I've searched our
issue trackers).

> Can you have a look at the attached minigbm patch?

It looks fine.  If it fixes whatever bugs you're seeing, we'll
definitely land this.

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

Re: [Mesa-dev] [PATCH 02/10] dri_interface: add __DRI_IMAGE_TRANSFER_USER_STRIDE

[Gurchetan Singh]

On Thu, Apr 26, 2018 at 10:23 AM, Marek Olšák <mar...@gmail.com> wrote:
> Gurchetan, can you confirm that the stride returned at alloc() is only used
> for CPU access and not for display programming?

It really depends on how you couple your HWComposer and gralloc HALs
together.  For example, drm_hwcomposer calls drmModeAddFB2 from with
the allocation time stride:

https://anongit.freedesktop.org/git/drm_hwcomposer.git

For the minigbm + wayland_hwcomposer use case, we have a
GRALLOC_DRM_GET_STRIDE call that returns the allocation time pixel
stride to the Wayland client.

We could:
  - Return the stride that works for display with GRALLOC_DRM_GET_STRIDE
  - Return the stride that works for CPU access with the alloc() call.

Just curious -- which Android app and/or test case is running into this issue?

> Thanks,
> Marek
>
> On Wed, Apr 25, 2018 at 11:23 PM, Marek Olšák <mar...@gmail.com> wrote:
>>
>> Why would you want to modify it? It's exactly what you get when you map
>> it, but that stride can't be used for modesetting.
>>
>> Marek
>>
>>
>> On Wed, Apr 25, 2018 at 11:14 PM, Gurchetan Singh
>> <gurchetansi...@chromium.org> wrote:
>>>
>>> That sounds fine to me.  We can just modify the stride after
>>> dri_bo_create(..).
>>>
>>> On Wed, Apr 25, 2018 at 7:30 PM, Marek Olšák <mar...@gmail.com> wrote:
>>> > On Wed, Apr 25, 2018 at 6:56 PM, Gurchetan Singh
>>> > <gurchetansi...@chromium.org> wrote:
>>> >>
>>> >> On Wed, Apr 25, 2018 at 2:16 PM, Marek Olšák <mar...@gmail.com> wrote:
>>> >> > From: Nicolai Hähnle <nicolai.haeh...@amd.com>
>>> >> >
>>> >> > Allow the caller to specify the row stride (in bytes) with which an
>>> >> > image
>>> >> > should be mapped. Note that completely ignoring USER_STRIDE is a
>>> >> > valid
>>> >> > implementation of mapImage.
>>> >> >
>>> >> > This is horrible API design. Unfortunately, cros_gralloc does indeed
>>> >> > have
>>> >> > a horrible API design -- in that arbitrary images should be allowed
>>> >> > to
>>> >> > be
>>> >> > mapped with the stride that a linear image of the same width would
>>> >> > have.
>>> >>
>>> >> Yes, unfortunately the gralloc API doesn't return the stride when
>>> >> (*lock) is called.  However, the stride is returned during (*alloc).
>>> >> Currently, for the dri backend, minigbm uses
>>> >> __DRI_IMAGE_ATTRIB_STRIDE to compute the pixel stride given to
>>> >> Android.
>>> >>
>>> >> Is AMD seeing problems with the current approach (I haven't seen any
>>> >> bugs filed for this issue)?
>>> >>
>>> >> Another possible solution is to call mapImage()/unmapImage right after
>>> >> allocating the image, and use the stride returned by mapImage() to
>>> >> compute the pixel stride.  That could also fix whatever bugs AMD is
>>> >> seeing.
>>> >
>>> >
>>> > Thanks. You cleared it up to me. It looks like that everything we've
>>> > been
>>> > told so far is BS. This series isn't needed.
>>> >
>>> > The solution is to do this in the amdgpu minigbm backend at alloc time:
>>> >stride = align(width * Bpp, 64);
>>> >
>>> > Later chips should change that to:
>>> >stride = align(width * Bpp, 256);
>>> >
>>> > No querying needed. What do you think?
>>> >
>>> > Marek
>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/10] dri_interface: add __DRI_IMAGE_TRANSFER_USER_STRIDE

[Gurchetan Singh]

That sounds fine to me.  We can just modify the stride after dri_bo_create(..).

On Wed, Apr 25, 2018 at 7:30 PM, Marek Olšák <mar...@gmail.com> wrote:
> On Wed, Apr 25, 2018 at 6:56 PM, Gurchetan Singh
> <gurchetansi...@chromium.org> wrote:
>>
>> On Wed, Apr 25, 2018 at 2:16 PM, Marek Olšák <mar...@gmail.com> wrote:
>> > From: Nicolai Hähnle <nicolai.haeh...@amd.com>
>> >
>> > Allow the caller to specify the row stride (in bytes) with which an
>> > image
>> > should be mapped. Note that completely ignoring USER_STRIDE is a valid
>> > implementation of mapImage.
>> >
>> > This is horrible API design. Unfortunately, cros_gralloc does indeed
>> > have
>> > a horrible API design -- in that arbitrary images should be allowed to
>> > be
>> > mapped with the stride that a linear image of the same width would have.
>>
>> Yes, unfortunately the gralloc API doesn't return the stride when
>> (*lock) is called.  However, the stride is returned during (*alloc).
>> Currently, for the dri backend, minigbm uses
>> __DRI_IMAGE_ATTRIB_STRIDE to compute the pixel stride given to
>> Android.
>>
>> Is AMD seeing problems with the current approach (I haven't seen any
>> bugs filed for this issue)?
>>
>> Another possible solution is to call mapImage()/unmapImage right after
>> allocating the image, and use the stride returned by mapImage() to
>> compute the pixel stride.  That could also fix whatever bugs AMD is
>> seeing.
>
>
> Thanks. You cleared it up to me. It looks like that everything we've been
> told so far is BS. This series isn't needed.
>
> The solution is to do this in the amdgpu minigbm backend at alloc time:
>stride = align(width * Bpp, 64);
>
> Later chips should change that to:
>stride = align(width * Bpp, 256);
>
> No querying needed. What do you think?
>
> Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/10] dri_interface: add __DRI_IMAGE_TRANSFER_USER_STRIDE

[Gurchetan Singh]

On Wed, Apr 25, 2018 at 2:16 PM, Marek Olšák  wrote:
> From: Nicolai Hähnle 
>
> Allow the caller to specify the row stride (in bytes) with which an image
> should be mapped. Note that completely ignoring USER_STRIDE is a valid
> implementation of mapImage.
>
> This is horrible API design. Unfortunately, cros_gralloc does indeed have
> a horrible API design -- in that arbitrary images should be allowed to be
> mapped with the stride that a linear image of the same width would have.

Yes, unfortunately the gralloc API doesn't return the stride when
(*lock) is called.  However, the stride is returned during (*alloc).
Currently, for the dri backend, minigbm uses
__DRI_IMAGE_ATTRIB_STRIDE to compute the pixel stride given to
Android.

Is AMD seeing problems with the current approach (I haven't seen any
bugs filed for this issue)?

Another possible solution is to call mapImage()/unmapImage right after
allocating the image, and use the stride returned by mapImage() to
compute the pixel stride.  That could also fix whatever bugs AMD is
seeing.

>
> There is no separate capability bit because it's unclear how stricter
> requirements should be defined.
> ---
>  include/GL/internal/dri_interface.h | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/include/GL/internal/dri_interface.h 
> b/include/GL/internal/dri_interface.h
> index 07dfd74f9d8..4247e61415f 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -1213,21 +1213,21 @@ struct __DRIdri2ExtensionRec {
>  */
> __DRIcreateNewScreen2FunccreateNewScreen2;
>  };
>
>
>  /**
>   * This extension provides functionality to enable various EGLImage
>   * extensions.
>   */
>  #define __DRI_IMAGE "DRI_IMAGE"
> -#define __DRI_IMAGE_VERSION 17
> +#define __DRI_IMAGE_VERSION 18
>
>  /**
>   * These formats correspond to the similarly named MESA_FORMAT_*
>   * tokens, except in the native endian of the CPU.  For example, on
>   * little endian __DRI_IMAGE_FORMAT_XRGB corresponds to
>   * MESA_FORMAT_XRGB, but MESA_FORMAT_XRGB_REV on big endian.
>   *
>   * __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.
> @@ -1263,20 +1263,21 @@ struct __DRIdri2ExtensionRec {
>   * in contrary to gbm buffers, front buffers and fake front buffers, which
>   * could be read after a flush."
>   */
>  #define __DRI_IMAGE_USE_BACKBUFFER  0x0010
>
>
>  #define __DRI_IMAGE_TRANSFER_READ0x1
>  #define __DRI_IMAGE_TRANSFER_WRITE   0x2
>  #define __DRI_IMAGE_TRANSFER_READ_WRITE  \
>  (__DRI_IMAGE_TRANSFER_READ | __DRI_IMAGE_TRANSFER_WRITE)
> +#define __DRI_IMAGE_TRANSFER_USER_STRIDE 0x4 /* since version 18 */
>
>  /**
>   * Four CC formats that matches with WL_DRM_FORMAT_* from wayland_drm.h,
>   * GBM_FORMAT_* from gbm.h, and DRM_FORMAT_* from drm_fourcc.h. Used with
>   * createImageFromNames.
>   *
>   * \since 5
>   */
>
>  #define __DRI_IMAGE_FOURCC_R8  0x20203852
> @@ -1554,22 +1555,31 @@ struct __DRIimageExtensionRec {
> /**
>  * Returns a map of the specified region of a __DRIimage for the 
> specified usage.
>  *
>  * flags may include __DRI_IMAGE_TRANSFER_READ, which will populate the
>  * mapping with the current buffer content. If __DRI_IMAGE_TRANSFER_READ
>  * is not included in the flags, the buffer content at map time is
>  * undefined. Users wanting to modify the mapping must include
>  * __DRI_IMAGE_TRANSFER_WRITE; if __DRI_IMAGE_TRANSFER_WRITE is not
>  * included, behaviour when writing the mapping is undefined.
>  *
> -* Returns the byte stride in *stride, and an opaque pointer to data
> -* tracking the mapping in **data, which must be passed to unmapImage().
> +* When __DRI_IMAGE_TRANSFER_USER_STRIDE is set in \p flags (since 
> version 18),
> +* the driver should attempt to map the image with the byte stride given 
> in
> +* *stride. The caller must ensure that *stride is large enough to hold a
> +* row of the mapping. If the requested stride is not supported, the 
> mapping
> +* may fail, or a mapping with a different stride may be created (in which
> +* case the actual stride is returned in *stride).
> +*
> +* Returns an opaque pointer to data tracking the mapping in **data, which
> +* must be passed to unmapImage().
> +*
> +* Returns the byte stride in *stride.
>  *
>  * Returns NULL on error.
>  *
>  * \since 12
>  */
> void *(*mapImage)(__DRIcontext *context, __DRIimage *image,
>   int x0, int y0, int width, int height,
>   unsigned int flags, int *stride, void **data);
>
> /**
> --
> 2.17.0
>
> ___
> mesa-dev 

[Mesa-dev] [PATCH] virgl: add shader offset alignment to to v2 caps struct

[Gurchetan Singh]

From: "gurchetansi...@chromium.org" 

This is the SSBO analogue to fe0647. User supplied data must
be a multiple of GL_SHADER_STORAGE_BUFFER_OFFSET_ALIGNMENT.

This fixes 44 GLES31 tests on airlied@'s GLES31 sketch branches with
Nvidia hardware, but this patch standalone can applied to master. The
alignment restriction on Nvidia is 32, hence the default value.

Example tests:
   dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.0
   dEQP-GLES31.functional.ssbo.layout.multi_basic_types.single_buffer.std430
---
 src/gallium/drivers/virgl/virgl_hw.h | 1 +
 src/gallium/drivers/virgl/virgl_screen.c | 1 +
 src/gallium/drivers/virgl/virgl_winsys.h | 1 +
 3 files changed, 3 insertions(+)

diff --git a/src/gallium/drivers/virgl/virgl_hw.h 
b/src/gallium/drivers/virgl/virgl_hw.h
index 93849c03ddd..624be3b271d 100644
--- a/src/gallium/drivers/virgl/virgl_hw.h
+++ b/src/gallium/drivers/virgl/virgl_hw.h
@@ -286,6 +286,7 @@ struct virgl_caps_v2 {
 int32_t max_texture_gather_offset;
 uint32_t texture_buffer_offset_alignment;
 uint32_t uniform_buffer_offset_alignment;
+uint32_t shader_buffer_offset_alignment;
 };
 
 union virgl_caps {
diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
b/src/gallium/drivers/virgl/virgl_screen.c
index 02613f18663..886ea196bdd 100644
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -228,6 +228,7 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
case PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL:
case PIPE_CAP_TGSI_FS_FACE_IS_INTEGER_SYSVAL:
case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
+  return vscreen->caps.caps.v2.shader_buffer_offset_alignment;
case PIPE_CAP_INVALIDATE_BUFFER:
case PIPE_CAP_GENERATE_MIPMAP:
case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
diff --git a/src/gallium/drivers/virgl/virgl_winsys.h 
b/src/gallium/drivers/virgl/virgl_winsys.h
index 99e98ad9c9c..c36b957abad 100644
--- a/src/gallium/drivers/virgl/virgl_winsys.h
+++ b/src/gallium/drivers/virgl/virgl_winsys.h
@@ -134,5 +134,6 @@ static inline void virgl_ws_fill_new_caps_defaults(struct 
virgl_drm_caps *caps)
caps->caps.v2.max_texture_gather_offset = 7;
caps->caps.v2.texture_buffer_offset_alignment = 32;
caps->caps.v2.uniform_buffer_offset_alignment = 256;
+   caps->caps.v2.shader_buffer_offset_alignment = 32;
 }
 #endif
-- 
2.13.5

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

[Mesa-dev] [PATCH] virgl: add offset alignment values to to v2 caps struct

[Gurchetan Singh]

From: "gurchetansi...@chromium.org" 

glBindBufferRange(..) in vrend_draw_bind_ubo is failing with
more than one uniform block. This is due to improper alignment
of the start of the second block. Let's query the proper
alignment from the driver and pass it back to Mesa.

Let's query for the texture alignment too, even though the Virgl
renderer doesn't call glTexBufferRange yet.

The default values are the widest workable range possible (for example,
GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT on Nvidia is 256).

Fixes:
dEQP-GLES3.functional.ubo.* on Nvidia

Example test:
dEQP-GLES3.functional.ubo.multi_basic_types.single_buffer.shared_vertex

Note: This is based on "virgl: reduce some default capset limits.",
which hasn't landed in Mesa yet but should relatively soon.
---
 src/gallium/drivers/virgl/virgl_hw.h | 2 ++
 src/gallium/drivers/virgl/virgl_screen.c | 4 ++--
 src/gallium/drivers/virgl/virgl_winsys.h | 2 ++
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_hw.h 
b/src/gallium/drivers/virgl/virgl_hw.h
index 833ab91eee..93849c03dd 100644
--- a/src/gallium/drivers/virgl/virgl_hw.h
+++ b/src/gallium/drivers/virgl/virgl_hw.h
@@ -284,6 +284,8 @@ struct virgl_caps_v2 {
 int32_t max_texel_offset;
 int32_t min_texture_gather_offset;
 int32_t max_texture_gather_offset;
+uint32_t texture_buffer_offset_alignment;
+uint32_t uniform_buffer_offset_alignment;
 };
 
 union virgl_caps {
diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
b/src/gallium/drivers/virgl/virgl_screen.c
index 22a694ea27..49a0c57cda 100644
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -140,7 +140,7 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
case PIPE_CAP_USER_VERTEX_BUFFERS:
   return 0;
case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT:
-  return 16;
+  return vscreen->caps.caps.v2.uniform_buffer_offset_alignment;
case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
case PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS:
   return vscreen->caps.caps.v1.bset.streamout_pause_resume;
@@ -163,7 +163,7 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
case PIPE_CAP_TEXTURE_BUFFER_OBJECTS:
   return vscreen->caps.caps.v1.max_tbo_size > 0;
case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT:
-  return 0;
+  return vscreen->caps.caps.v2.texture_buffer_offset_alignment;
case PIPE_CAP_BUFFER_SAMPLER_VIEW_RGBA_ONLY:
   return 0;
case PIPE_CAP_CUBE_MAP_ARRAY:
diff --git a/src/gallium/drivers/virgl/virgl_winsys.h 
b/src/gallium/drivers/virgl/virgl_winsys.h
index 95e21a8afd..99e98ad9c9 100644
--- a/src/gallium/drivers/virgl/virgl_winsys.h
+++ b/src/gallium/drivers/virgl/virgl_winsys.h
@@ -132,5 +132,7 @@ static inline void virgl_ws_fill_new_caps_defaults(struct 
virgl_drm_caps *caps)
caps->caps.v2.max_texel_offset = 7;
caps->caps.v2.min_texture_gather_offset = -8;
caps->caps.v2.max_texture_gather_offset = 7;
+   caps->caps.v2.texture_buffer_offset_alignment = 32;
+   caps->caps.v2.uniform_buffer_offset_alignment = 256;
 }
 #endif
-- 
2.13.5

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

Re: [Mesa-dev] [PATCH] virgl: remap query types to hw support.

[Gurchetan Singh]

This also fixes:

dEQP-GLES3.functional.transform_feedback.array.separate*
dEQP-GLES3.functional.transform_feedback.array_element*
dEQP-GLES3.functional.transform_feedback.interpolation.*

Gallium's p_defines.h and virglrenderer's p_defines.h have diverged
quite a bit, so not including
PIPE_QUERY_OCCLUSION_PREDICATE_CONSERVATIVE there makes sense for now.

Reviewed-by: Gurchetan Singh <gurchetansi...@chromium.org>
Tested-by: Gurchetan Singh <gurchetansi...@chromium.org>

On Tue, Feb 13, 2018 at 6:58 PM, Dave Airlie <airl...@gmail.com> wrote:
> From: Dave Airlie <airl...@redhat.com>
>
> The gallium query types changed, so we need to remap from the
> gallium ones to the virgl ones.
>
> Fixes:
> dEQP-GLES3.functional.transform_feedback.basic_types*
>
> Fixes: 3f6b3d9db (gallium: add PIPE_QUERY_OCCLUSION_PREDICATE_CONSERVATIVE)
>
> Signed-off-by: Dave Airlie <airl...@redhat.com>
> ---
>  src/gallium/drivers/virgl/virgl_query.c | 37 
> +++--
>  1 file changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_query.c 
> b/src/gallium/drivers/virgl/virgl_query.c
> index e6ca4609c03..3a930d29666 100644
> --- a/src/gallium/drivers/virgl/virgl_query.c
> +++ b/src/gallium/drivers/virgl/virgl_query.c
> @@ -37,6 +37,39 @@ struct virgl_query {
> unsigned result_size;
> unsigned result_gotten_sent;
>  };
> +#define VIRGL_QUERY_OCCLUSION_COUNTER 0
> +#define VIRGL_QUERY_OCCLUSION_PREDICATE   1
> +#define VIRGL_QUERY_TIMESTAMP 2
> +#define VIRGL_QUERY_TIMESTAMP_DISJOINT3
> +#define VIRGL_QUERY_TIME_ELAPSED  4
> +#define VIRGL_QUERY_PRIMITIVES_GENERATED  5
> +#define VIRGL_QUERY_PRIMITIVES_EMITTED6
> +#define VIRGL_QUERY_SO_STATISTICS 7
> +#define VIRGL_QUERY_SO_OVERFLOW_PREDICATE 8
> +#define VIRGL_QUERY_GPU_FINISHED  9
> +#define VIRGL_QUERY_PIPELINE_STATISTICS  10
> +
> +static const int pquery_map[] =
> +{
> +   VIRGL_QUERY_OCCLUSION_COUNTER,
> +   VIRGL_QUERY_OCCLUSION_PREDICATE,
> +   -1,
> +   VIRGL_QUERY_TIMESTAMP,
> +   VIRGL_QUERY_TIMESTAMP_DISJOINT,
> +   VIRGL_QUERY_TIME_ELAPSED,
> +   VIRGL_QUERY_PRIMITIVES_GENERATED,
> +   VIRGL_QUERY_PRIMITIVES_EMITTED,
> +   VIRGL_QUERY_SO_STATISTICS,
> +   VIRGL_QUERY_SO_OVERFLOW_PREDICATE,
> +   -1,
> +   VIRGL_QUERY_GPU_FINISHED,
> +   VIRGL_QUERY_PIPELINE_STATISTICS,
> +};
> +
> +static int pipe_to_virgl_query(enum pipe_query_type ptype)
> +{
> +   return pquery_map[ptype];
> +}
>
>  static inline struct virgl_query *virgl_query(struct pipe_query *q)
>  {
> @@ -75,11 +108,11 @@ static struct pipe_query *virgl_create_query(struct 
> pipe_context *ctx,
> }
>
> handle = virgl_object_assign_handle();
> -   query->type = query_type;
> +   query->type = pipe_to_virgl_query(query_type);
> query->index = index;
> query->handle = handle;
> query->buf->clean = FALSE;
> -   virgl_encoder_create_query(vctx, handle, query_type, index, query->buf, 
> 0);
> +   virgl_encoder_create_query(vctx, handle, query->type, index, query->buf, 
> 0);
>
> return (struct pipe_query *)query;
>  }
> --
> 2.14.3
>
> ___
> 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: don't clamp just based on ARB_viewport_array extension

[Gurchetan Singh]

On Wed, Feb 14, 2018 at 3:57 PM, Marek Olšák <mar...@gmail.com> wrote:
> Do you have commit access?

No, would appreciate a merge ;-)

> Marek
>
> On Thu, Feb 15, 2018 at 12:40 AM, gurchetansi...@chromium.org
> <gurchetansi...@chromium.org> wrote:
>> From: Gurchetan Singh <gurchetansi...@chromium.org>
>>
>> The ARB_viewport_array spec says:
>>
>> "Dependencies
>> OpenGL 1.0 is required.
>>
>> OpenGL 3.2 or the EXT_geometry_shader4 or ARB_geometry_shader4 extensions
>> are required.
>>
>> This extension is written against the OpenGL 3.2 (Compatibility)
>> Specification."
>>
>> As such, we should ignore it for GLES2 contexts.
>>
>> Fixes:
>> dEQP-GLES2.functional.state_query.integers.viewport_getinteger
>> dEQP-GLES2.functional.state_query.integers.viewport_getfloat
>>
>> on llvmpipe and virgl.
>>
>> v2: Use _mesa_has_* (Ilia)
>> ---
>>  src/mesa/main/viewport.c | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
>> index fc384909e6..398cc63685 100644
>> --- a/src/mesa/main/viewport.c
>> +++ b/src/mesa/main/viewport.c
>> @@ -51,9 +51,8 @@ clamp_viewport(struct gl_context *ctx, GLfloat *x, GLfloat 
>> *y,
>>  * determined by calling GetFloatv with the symbolic constant
>>  * VIEWPORT_BOUNDS_RANGE (see section 6.1)."
>>  */
>> -   if (ctx->Extensions.ARB_viewport_array ||
>> -   (ctx->Extensions.OES_viewport_array &&
>> -_mesa_is_gles31(ctx))) {
>> +   if (_mesa_has_ARB_viewport_array(ctx) ||
>> +   _mesa_has_OES_viewport_array(ctx)) {
>>*x = CLAMP(*x,
>>   ctx->Const.ViewportBounds.Min, 
>> ctx->Const.ViewportBounds.Max);
>>*y = CLAMP(*y,
>> --
>> 2.13.5
>>
>> ___
>> 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] st/mesa: update the blend before a full color clear

[Gurchetan Singh]

On Thu, Feb 8, 2018 at 6:01 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> On Thu, Feb 8, 2018 at 8:58 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>> On Thu, Feb 8, 2018 at 8:36 PM, Gurchetan Singh
>> <gurchetansi...@chromium.org> wrote:
>>> On Thu, Feb 8, 2018 at 5:15 PM, Marek Olšák <mar...@gmail.com> wrote:
>>>>
>>>> On Fri, Feb 9, 2018 at 2:12 AM, Gurchetan Singh
>>>> <gurchetansi...@chromium.org> wrote:
>>>> > On Thu, Feb 8, 2018 at 4:46 PM, Marek Olšák <mar...@gmail.com> wrote:
>>>> >>
>>>> >> This is not the correct fix.
>>>> >>
>>>> >> clear_with_quad calls cso_set_blend. pipe->clear ignores (and should
>>>> >> ignore) the blend state. There is no scenario where you would have to
>>>> >> call st_update_blend for pipe->clear. I think this is a virgl bug in
>>>> >> pipe->clear.
>>>> >
>>>> >
>>>> > clear_with_quad is only called if a color mask exists (see 
>>>> > is_color_masked).
>>>> > When the state transitions from color-mask exists --> completely unmasked
>>>> > (the clear_buffers case), how is the driver supposed to be notified?
>>>>
>>>> The driver isn't notified. It should ignore the blend state entirely
>>>> and always use the full mask for full clears.
>>>
>>> That was my first approach (see crrev.com/c/909961).  However, that
>>> causes an issue where we:
>>>
>>> 1) Set blendstate B in cso_set_blend, thereby putting it into the cso cache
>>> 2) Do a full clear (thereby altering the colormask on the host side,
>>> but not updating the cso blendstate)
>>> 3) Try to use blendstate B again.  Since the cso context still thinks
>>> we have blendstate B, it never calls ctx->pipe->bind_blend_state.
>>>
>>> Besides updating the cso state, how can I fix this issue?
>>
>> You need to save the original blend state. In the gallium API,
>> ->clear() ignores the blend state. If you're compensating by setting
>> the blend state to something else, you must restore the old one after
>> doing the clear.
>>
>> Although I think you're going about this wrong. The problem isn't with
>> virgl, it's with virglrenderer. It should disable colormask/blend
>> state when processing a clear packet.
>
> BTW, note that glClear() can be also affected by scissors, window
> rectangles, and stencil masks; none of these affect pipe->clear(), so
> if you're implementing it with glClear, then it may not work.

Good tips.  I think save and restore on the virglrender side may work
... I'll look into it ...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: update the blend before a full color clear

[Gurchetan Singh]

On Thu, Feb 8, 2018 at 5:15 PM, Marek Olšák <mar...@gmail.com> wrote:
>
> On Fri, Feb 9, 2018 at 2:12 AM, Gurchetan Singh
> <gurchetansi...@chromium.org> wrote:
> > On Thu, Feb 8, 2018 at 4:46 PM, Marek Olšák <mar...@gmail.com> wrote:
> >>
> >> This is not the correct fix.
> >>
> >> clear_with_quad calls cso_set_blend. pipe->clear ignores (and should
> >> ignore) the blend state. There is no scenario where you would have to
> >> call st_update_blend for pipe->clear. I think this is a virgl bug in
> >> pipe->clear.
> >
> >
> > clear_with_quad is only called if a color mask exists (see is_color_masked).
> > When the state transitions from color-mask exists --> completely unmasked
> > (the clear_buffers case), how is the driver supposed to be notified?
>
> The driver isn't notified. It should ignore the blend state entirely
> and always use the full mask for full clears.

That was my first approach (see crrev.com/c/909961).  However, that
causes an issue where we:

1) Set blendstate B in cso_set_blend, thereby putting it into the cso cache
2) Do a full clear (thereby altering the colormask on the host side,
but not updating the cso blendstate)
3) Try to use blendstate B again.  Since the cso context still thinks
we have blendstate B, it never calls ctx->pipe->bind_blend_state.

Besides updating the cso state, how can I fix this issue?

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

Re: [Mesa-dev] [PATCH] st/mesa: update the blend before a full color clear

[Gurchetan Singh]

On Thu, Feb 8, 2018 at 4:46 PM, Marek Olšák <mar...@gmail.com> wrote:

> This is not the correct fix.
>
> clear_with_quad calls cso_set_blend. pipe->clear ignores (and should
> ignore) the blend state. There is no scenario where you would have to
> call st_update_blend for pipe->clear. I think this is a virgl bug in
> pipe->clear.
>

clear_with_quad is only called if a color mask exists
(see is_color_masked).  When the state transitions from color-mask exists
--> completely unmasked (the clear_buffers case), how is the driver
supposed to be notified?


> Marek
>
> On Fri, Feb 9, 2018 at 1:28 AM, gurchetansi...@chromium.org
> <gurchetansi...@chromium.org> wrote:
> > From: Gurchetan Singh <gurchetansi...@chromium.org>
> >
> > Consider this series of events:
> >
> > glColorMask(GL_FALSE, GL_TRUE, GL_TRUE, GL_TRUE);
> > glClearColor(0.125f, 0.25f, 0.5f, 1.0f);
> > glClear(GL_COLOR_BUFFER_BIT);
> > glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
> > glClearColor(0.1f, 0.1f, 0.1f, 1.0f);
> > glClear(GL_COLOR_BUFFER_BIT);
> >
> > With virgl, this may render an incorrect result.  This is because
> > there our two paths for clears in Gallium -- one for full clears
> > (st->pipe->clear) and another for color-masked/scissored clears
> > (clear_with_quad).  We only encode the color mask in the
> > virgl_encode_blend_state in the clear_with_quad case.
> >
> > We should set the colormask the case of full clears as well, since
> > we need to update the GL state on the host driver.
> >
> > With this patch, the number of dEQP GLES2 failures on Virgl with a
> > nvidia host drivers goes from 260 to 136 with no regressions.
> > Two representative test cases are:
> >
> > dEQP-GLES2.functional.color_clear.masked_scissored_rgb
> > dEQP-GLES2.functional.color_clear.masked_scissored_rgba
> >
> > Note: I tried a virgl specific solution (crrev.com/c/909961), however
> > that caused a regression in dEQP-GLES2.functional.depth_
> stencil_clear.depth
> > since the cso_cache was not updated.
> > ---
> >  src/mesa/state_tracker/st_cb_clear.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/src/mesa/state_tracker/st_cb_clear.c
> b/src/mesa/state_tracker/st_cb_clear.c
> > index 68677182ab..d8ad2b3b4a 100644
> > --- a/src/mesa/state_tracker/st_cb_clear.c
> > +++ b/src/mesa/state_tracker/st_cb_clear.c
> > @@ -444,6 +444,13 @@ st_Clear(struct gl_context *ctx, GLbitfield mask)
> >clear_with_quad(ctx, quad_buffers);
> > }
> > if (clear_buffers) {
> > +  /* The colormask may go from a masked value to being completely
> unmasked.
> > +   * In that case, we should notify the driver via st_update_blend.
> The cso
> > +   * cache should take care of not emitting old states.
> > +   */
> > +  if (clear_buffers & PIPE_CLEAR_COLOR)
> > + st_update_blend(st);
> > +
> >/* We can't translate the clear color to the colorbuffer format,
> > * because different colorbuffers may have different formats.
> > */
> > --
> > 2.13.5
> >
> > ___
> > 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] virgl: also remove dimension on indirect.

[Gurchetan Singh]

Any plans to merge this?  This fixes Chrome not starting with Virgl.

Reviewed-by: Gurchetan Singh <gurchetansi...@chromium.org>
Tested-by: Gurchetan Singh <gurchetansi...@chromium.org>

On Mon, Nov 13, 2017 at 12:53 PM, Dave Airlie <airl...@gmail.com> wrote:
> From: Dave Airlie <airl...@redhat.com>
>
> This fixes some dEQP tests that generated bad shaders.
>
> Fixes: b6f6ead19 (virgl: drop const dimensions on first block.)
> Signed-off-by: Dave Airlie <airl...@redhat.com>
> ---
>  src/gallium/drivers/virgl/virgl_tgsi.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_tgsi.c 
> b/src/gallium/drivers/virgl/virgl_tgsi.c
> index aa483ad..ca05913 100644
> --- a/src/gallium/drivers/virgl/virgl_tgsi.c
> +++ b/src/gallium/drivers/virgl/virgl_tgsi.c
> @@ -76,7 +76,6 @@ virgl_tgsi_transform_instruction(struct 
> tgsi_transform_context *ctx,
> for (unsigned i = 0; i < inst->Instruction.NumSrcRegs; i++) {
>if (inst->Src[i].Register.File == TGSI_FILE_CONSTANT &&
>inst->Src[i].Register.Dimension &&
> -  !inst->Src[i].Register.Indirect &&
>inst->Src[i].Dimension.Index == 0)
>   inst->Src[i].Register.Dimension = 0;
> }
> --
> 2.9.5
>
> ___
> 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] [RFC libdrm 0/5] Move alloc_handle_t from gralloc impls.

[Gurchetan Singh]

>
> We can define accessor functions too (not ptrs), then the struct is opaque
> and you can do your own accessor implementation if aligning is not possible
> or desired.
>

Accessor functions in libdrm sound good to me.

On Fri, Jan 12, 2018 at 11:44 AM, Rob Herring <r...@kernel.org> wrote:

> On Fri, Jan 12, 2018 at 2:29 AM, Tomasz Figa <tf...@chromium.org> wrote:
> > Hi Rob,
> >
> > On Fri, Jan 12, 2018 at 5:26 AM, Robert Foss <robert.f...@collabora.com>
> wrote:
> >> Heya,
> >>
> >>
> >> On 12/22/17 1:09 PM, Tomasz Figa wrote:
> >>>
> >>> On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
> >>> <gurchetansi...@chromium.org> wrote:
> >>>>
> >>>> So the plan is for alloc_handle_t to not be sub-classed by the
> >>>> implementations, but have all necessary information that an
> >>>> implementation
> >>>> would need?
> >>>>
> >>>> If so, how do we reconcile the implementation specific information
> that
> >>>> is
> >>>> often in the handle:
> >>>>
> >>>>
> >>>> https://github.com/intel/minigbm/blob/master/cros_
> gralloc/cros_gralloc_handle.h
> >>>> [consumer_usage, producer_usage, yuv_color_range, is_updated etc.]
> >>>>
> >>>>
> >>>> https://chromium.googlesource.com/chromiumos/platform/
> minigbm/+/master/cros_gralloc/cros_gralloc_handle.h
> >>>> [use_flags, pixel_stride]
> >>>>
> >>>> In our case, removing our minigbm specific use flags from the handle
> >>>> would
> >>>> add complexity to our (*registerBuffer) path.
> >>>>
> >>>> On Thu, Dec 21, 2017 at 10:14 AM, Rob Herring <r...@kernel.org>
> wrote:
> >>>>>
> >>>>>
> >>>>> On Wed, Dec 13, 2017 at 5:02 PM, Gurchetan Singh
> >>>>> <gurchetansi...@chromium.org> wrote:
> >>>>>>
> >>>>>> Hi Robert,
> >>>>>>
> >>>>>> Thanks for looking into this!  We need to decide if we want:
> >>>>>>
> >>>>>> (1) A common struct that implementations can subclass, i.e:
> >>>>>>
> >>>>>> struct blah_gralloc_handle {
> >>>>>>  alloc_handle_t alloc_handle;
> >>>>>>  int x, y, z;
> >>>>>>  
> >>>>>> }
> >>>>>>
> >>>>>> (2) An accessor library that vendors can implement, i.e:
> >>>>>>
> >>>>>> struct drmAndroidHandleInfo {
> >>>>>> uint32_t (*get_fourcc)(buffer_handle_t handle);
> >>>>>> uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
> >>>>>> uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
> >>>>>> uint64_t (*get_modifier)(buffer_handle_t handle);
> >>>>>> };
> >>>>>>
> >>>>>>  From my perspective as someone who has to maintain the minigbm
> gralloc
> >>>>>> implementation, (2) is preferable since:
> >>>>>
> >>>>>
> >>>>> Yeah, I'd prefer not to encourage 1 as the default.
> >>>>>
> >>
> >> So I had a look into implementing this,
> >
> > Thanks!
> >
> >> and using function pointers is
> >> problematic due to this struct being passed between processes which
> would
> >> prevent mesa calling a function assigned in gbm_gralloc for example.
> >
> > Why would be this struct passed between processes?
> >
> > The only data being exchanged between processes using gralloc is the
> > handle and it isn't actually exchanged directly, but the exporting
> > process will flatten it and send through Binder, while the importing
> > one will have it unflattened and then the gralloc implementation
> > called on it (the register buffer operation), which could update any
> > per-process data in the handle. (But still, why would we need to
> > include the function pointers there?)
> >
> >>
> >> It could be used to provide runtime support for multiple gralloc
> >> implementations, but that seems to about the only advantage to adding
> FPs.
> >>
> >> Am I missing a good usecase for FPs? If not I think the added
> >>

Re: [Mesa-dev] [RFC libdrm 0/5] Move alloc_handle_t from gralloc impls.

[Gurchetan Singh]

>
> Alright, so if I understand this correctly importing process would always
> call gralloc registerBuffer(), which means that the FPs would always be
> correct and usable by the importing process?


Yes, the Android framework calls registerBuffer() when importing the buffer
to a different process.  The FPs would introduce a dependency on libdrm on
whichever piece of code would want to use the handle access functions,
though [so would subclassing and sharing a handle].


> So if I'm understanding this correctly, something like this should work:
> https://gitlab.collabora.com/robertfoss/libdrm/commits/gralloc_handle_v1


Not quite.  It looks like you're defining another handle (since you
subclass native_handle_t) to store the function pointers.  If I understand
the logic correctly, this would require the gralloc implementation to point
to the relevant functions in (*registerBuffer()) and when allocating.

The idea was more to take the handle as an input to the accessor library:

// header file

struct drmAndroidHandleInfo {
   uint32_t (*get_fourcc)(buffer_handle_t handle);
...
}

extern const struct drmAndroidHandleInfo my_info;

// blah_gralloc_implementation.c
#ifdef blah_GRALLOC
#include "blah_gralloc_handle.h"

static uint32_t blah_gralloc_get_fourcc(buffer_handle_t handle)
{
struct blah_gralloc_handle *blah_handle = (struct blah_gralloc_handle
*) handle;
return blah_handle->fourcc_format;
}

struct drmAndroidHandleInfo my_info = {
   .get_fourcc = blah_gralloc_get_fourcc,
...


}

#endif

Then Mesa can just call my_info.get_fourcc(handle).

On Fri, Jan 12, 2018 at 5:10 AM, Robert Foss <robert.f...@collabora.com>
wrote:

>
>
> On 1/12/18 9:29 AM, Tomasz Figa wrote:
>
>> Hi Rob,
>>
>> On Fri, Jan 12, 2018 at 5:26 AM, Robert Foss <robert.f...@collabora.com>
>> wrote:
>>
>>> Heya,
>>>
>>>
>>> On 12/22/17 1:09 PM, Tomasz Figa wrote:
>>>
>>>>
>>>> On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
>>>> <gurchetansi...@chromium.org> wrote:
>>>>
>>>>>
>>>>> So the plan is for alloc_handle_t to not be sub-classed by the
>>>>> implementations, but have all necessary information that an
>>>>> implementation
>>>>> would need?
>>>>>
>>>>> If so, how do we reconcile the implementation specific information that
>>>>> is
>>>>> often in the handle:
>>>>>
>>>>>
>>>>> https://github.com/intel/minigbm/blob/master/cros_gralloc/
>>>>> cros_gralloc_handle.h
>>>>> [consumer_usage, producer_usage, yuv_color_range, is_updated etc.]
>>>>>
>>>>>
>>>>> https://chromium.googlesource.com/chromiumos/platform/minigb
>>>>> m/+/master/cros_gralloc/cros_gralloc_handle.h
>>>>> [use_flags, pixel_stride]
>>>>>
>>>>> In our case, removing our minigbm specific use flags from the handle
>>>>> would
>>>>> add complexity to our (*registerBuffer) path.
>>>>>
>>>>> On Thu, Dec 21, 2017 at 10:14 AM, Rob Herring <r...@kernel.org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Dec 13, 2017 at 5:02 PM, Gurchetan Singh
>>>>>> <gurchetansi...@chromium.org> wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi Robert,
>>>>>>>
>>>>>>> Thanks for looking into this!  We need to decide if we want:
>>>>>>>
>>>>>>> (1) A common struct that implementations can subclass, i.e:
>>>>>>>
>>>>>>> struct blah_gralloc_handle {
>>>>>>>   alloc_handle_t alloc_handle;
>>>>>>>   int x, y, z;
>>>>>>>   
>>>>>>> }
>>>>>>>
>>>>>>> (2) An accessor library that vendors can implement, i.e:
>>>>>>>
>>>>>>> struct drmAndroidHandleInfo {
>>>>>>>  uint32_t (*get_fourcc)(buffer_handle_t handle);
>>>>>>>  uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
>>>>>>>  uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
>>>>>>>  uint64_t (*get_modifier)(buffer_handle_t handle);
>>>>>>> };
>>>>>>>
>>>>>>>   From my perspective as someone who has to maintain the minigbm
>>>>>

Re: [Mesa-dev] [RFC libdrm 0/5] Move alloc_handle_t from gralloc impls.

[Gurchetan Singh]

>
> So I had a look into implementing this, and using function pointers is
> problematic due to this struct being passed between processes which would
> prevent mesa calling a function assigned in gbm_gralloc for example.


Which function?  In theory, anything with a dependency on libdrm and a
gralloc handle should be able use the FPs.

It could be used to provide runtime support for multiple gralloc
> implementations, but that seems to about the only advantage to adding FPs.


Yes, that's the main benefit.  The other two options are:

(a) standardize the handle.  I'm still not sure how we're going to
reconcile the implementation specific differences that I pointed out in my
last message.
(b) subclass the handles.  If I'm reading everyone's comments correctly, no
one is in favor of this b/c of alignment/padding issues.
(c) Standard struct in libdrm + a perform call in gralloc.  However, the
issue with that is (*perform) is removed in gralloc1 and HIDL gralloc
(/hardware/interfaces/graphics/mapper/2.0/IMapper.hal
and hardware/interfaces/graphics/allocator/2.0/IAllocator.hal in AOSP).

On Thu, Jan 11, 2018 at 12:26 PM, Robert Foss <robert.f...@collabora.com>
wrote:

> Heya,
>
>
> On 12/22/17 1:09 PM, Tomasz Figa wrote:
>
>> On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
>> <gurchetansi...@chromium.org> wrote:
>>
>>> So the plan is for alloc_handle_t to not be sub-classed by the
>>> implementations, but have all necessary information that an
>>> implementation
>>> would need?
>>>
>>> If so, how do we reconcile the implementation specific information that
>>> is
>>> often in the handle:
>>>
>>> https://github.com/intel/minigbm/blob/master/cros_gralloc/cr
>>> os_gralloc_handle.h
>>> [consumer_usage, producer_usage, yuv_color_range, is_updated etc.]
>>>
>>> https://chromium.googlesource.com/chromiumos/platform/minigb
>>> m/+/master/cros_gralloc/cros_gralloc_handle.h
>>> [use_flags, pixel_stride]
>>>
>>> In our case, removing our minigbm specific use flags from the handle
>>> would
>>> add complexity to our (*registerBuffer) path.
>>>
>>> On Thu, Dec 21, 2017 at 10:14 AM, Rob Herring <r...@kernel.org> wrote:
>>>
>>>>
>>>> On Wed, Dec 13, 2017 at 5:02 PM, Gurchetan Singh
>>>> <gurchetansi...@chromium.org> wrote:
>>>>
>>>>> Hi Robert,
>>>>>
>>>>> Thanks for looking into this!  We need to decide if we want:
>>>>>
>>>>> (1) A common struct that implementations can subclass, i.e:
>>>>>
>>>>> struct blah_gralloc_handle {
>>>>>  alloc_handle_t alloc_handle;
>>>>>  int x, y, z;
>>>>>  
>>>>> }
>>>>>
>>>>> (2) An accessor library that vendors can implement, i.e:
>>>>>
>>>>> struct drmAndroidHandleInfo {
>>>>> uint32_t (*get_fourcc)(buffer_handle_t handle);
>>>>> uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
>>>>> uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
>>>>> uint64_t (*get_modifier)(buffer_handle_t handle);
>>>>> };
>>>>>
>>>>>  From my perspective as someone who has to maintain the minigbm gralloc
>>>>> implementation, (2) is preferable since:
>>>>>
>>>>
>>>> Yeah, I'd prefer not to encourage 1 as the default.
>>>>
>>>>
> So I had a look into implementing this, and using function pointers is
> problematic due to this struct being passed between processes which would
> prevent mesa calling a function assigned in gbm_gralloc for example.
>
> It could be used to provide runtime support for multiple gralloc
> implementations, but that seems to about the only advantage to adding FPs.
>
> Am I missing a good usecase for FPs? If not I think the added
> complexity/cruft is more problematic than good.
>
> Any thoughts?
>
>
> Rob.
>
>
> a) We really don't have a need for fields like data_owner, void *data,
>>>>> etc.
>>>>>
>>>>
>>>> We should be able to get rid of this. It's just for tracking imports.
>>>>
>>>> Also, minigbm puts per plane fds, strides, offsets into the handle.
>>>>> Separating the information for the first plane (for the alloc_handle_t)
>>>>> and
>>>>> then rest of the planes would be annoying.
>>>>>
>>>>
>>&

Re: [Mesa-dev] [RFC libdrm 0/5] Move alloc_handle_t from gralloc impls.

[Gurchetan Singh]

So the plan is for alloc_handle_t to not be sub-classed by the
implementations, but have all necessary information that an implementation
would need?

If so, how do we reconcile the implementation specific information that is
often in the handle:

https://github.com/intel/minigbm/blob/master/cros_
gralloc/cros_gralloc_handle.h [consumer_usage, producer_usage, yuv_color_range,
is_updated etc.]

https://chromium.googlesource.com/chromiumos/platform/
minigbm/+/master/cros_gralloc/cros_gralloc_handle.h [use_flags,
pixel_stride]

In our case, removing our minigbm specific use flags from the handle would
add complexity to our (*registerBuffer) path.

On Thu, Dec 21, 2017 at 10:14 AM, Rob Herring <r...@kernel.org> wrote:

> On Wed, Dec 13, 2017 at 5:02 PM, Gurchetan Singh
> <gurchetansi...@chromium.org> wrote:
> > Hi Robert,
> >
> > Thanks for looking into this!  We need to decide if we want:
> >
> > (1) A common struct that implementations can subclass, i.e:
> >
> > struct blah_gralloc_handle {
> > alloc_handle_t alloc_handle;
> > int x, y, z;
> > 
> > }
> >
> > (2) An accessor library that vendors can implement, i.e:
> >
> > struct drmAndroidHandleInfo {
> >uint32_t (*get_fourcc)(buffer_handle_t handle);
> >uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
> >uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
> >uint64_t (*get_modifier)(buffer_handle_t handle);
> > };
> >
> > From my perspective as someone who has to maintain the minigbm gralloc
> > implementation, (2) is preferable since:
>
> Yeah, I'd prefer not to encourage 1 as the default.
>
> > a) We really don't have a need for fields like data_owner, void *data,
> etc.
>
> We should be able to get rid of this. It's just for tracking imports.
>
> > Also, minigbm puts per plane fds, strides, offsets into the handle.
> > Separating the information for the first plane (for the alloc_handle_t)
> and
> > then rest of the planes would be annoying.
>
> The plan is to add those to alloc_handle_t.
>
> > b) we can avoid the struct within a struct that happens when we subclass,
> > since alignment/padding issues often pop up during
> > serialization/de-serialization.  Using __attribute__((aligned(xx))) is
> less
> > portable than maintaining a POD struct.
>
> Yes. Even just between 32 and 64 bit it's problematic.


> > c) IMO creating the handle should be left to the gralloc implementation.
> > Having accessor functions clearly defines what we need from libdrm -- to
> > make up for shortcomings of the gralloc API for DRM/KMS use cases.
> >
> >
> > On Wed, Dec 13, 2017 at 9:30 AM, Robert Foss <robert.f...@collabora.com>
> > wrote:
> >>
> >> This series moves {gbm,drm,cros}_gralloc_handle_t struct to libdrm,
> >> since at least 4 implementations exist, and share a lot of contents.
> >> The idea is to keep the common stuff defined in one place, and libdrm
> >> is the common codebase to all of these platforms.
> >>
> >> Additionally, having this struct defined in libdrm will make it
> >> easier for mesa and grallocs to communicate.
> >>
> >> Curretly missing is:
> >>  - Planar formats
> >>  - Get/Set functions
> >>
> >>
> >> Planar formats
> >> --
> >> Support for planar formats is needed, but has not been added
> >> yet, mostly since this was not already implemented in {gbm,drm}_gralloc
> >> and the fact the having at least initial backwards compatability would
> >> be nice. Anonymous unions can of course be used later on to provide
> >> backwards compatability if so desired.
> >>
> >>
> >> Get/Set functions
> >> -
> >> During the previous discussion[1] one suggestion was to add accessor
> >> functions. In this RFC I've only provided a alloc_handle_create()
> >> function.
> >>
> >> The Get/Set functions have not been added yet, I was hoping for some
> >> conclusive arguments for them being adeded.
> >>
> >> Lastly it was suggested by Rob Herring that having a fourcc<->android
> >> pixel format conversion function would be useful.
> >>
> >>
> >> [1]
> >> https://lists.freedesktop.org/archives/mesa-dev/2017-
> November/178199.html
> >>
> >> Robert Foss (5):
> >>   android: Move gralloc handle struct to libdrm
> >>   android: Add version variable to alloc_handle_t
> >>   android: Mark alloc_handle_t mag

Re: [Mesa-dev] [RFC libdrm 0/5] Move alloc_handle_t from gralloc impls.

[Gurchetan Singh]

Hi Robert,

Thanks for looking into this!  We need to decide if we want:

(1) A common struct that implementations can subclass, i.e:

struct blah_gralloc_handle {
alloc_handle_t alloc_handle;
int x, y, z;

}

(2) An accessor library that vendors can implement, i.e:

struct drmAndroidHandleInfo {
   uint32_t (*get_fourcc)(buffer_handle_t handle);
   uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
   uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
   uint64_t (*get_modifier)(buffer_handle_t handle);
};

>From my perspective as someone who has to maintain the minigbm gralloc
implementation, (2) is preferable since:

a) We really don't have a need for fields like data_owner, void *data,
etc.  Also, minigbm puts per plane fds, strides, offsets into the handle.
Separating the information for the first plane (for the alloc_handle_t) and
then rest of the planes would be annoying.

b) we can avoid the struct within a struct that happens when we subclass,
since alignment/padding issues often pop up during
serialization/de-serialization.  Using __attribute__((aligned(xx))) is less
portable than maintaining a POD struct.

c) IMO creating the handle should be left to the gralloc implementation.
Having accessor functions clearly defines what we need from libdrm -- to
make up for shortcomings of the gralloc API for DRM/KMS use cases.


On Wed, Dec 13, 2017 at 9:30 AM, Robert Foss 
wrote:

> This series moves {gbm,drm,cros}_gralloc_handle_t struct to libdrm,
> since at least 4 implementations exist, and share a lot of contents.
> The idea is to keep the common stuff defined in one place, and libdrm
> is the common codebase to all of these platforms.
>
> Additionally, having this struct defined in libdrm will make it
> easier for mesa and grallocs to communicate.
>
> Curretly missing is:
>  - Planar formats
>  - Get/Set functions
>
>
> Planar formats
> --
> Support for planar formats is needed, but has not been added
> yet, mostly since this was not already implemented in {gbm,drm}_gralloc
> and the fact the having at least initial backwards compatability would
> be nice. Anonymous unions can of course be used later on to provide
> backwards compatability if so desired.
>
>
> Get/Set functions
> -
> During the previous discussion[1] one suggestion was to add accessor
> functions. In this RFC I've only provided a alloc_handle_create()
> function.
>
> The Get/Set functions have not been added yet, I was hoping for some
> conclusive arguments for them being adeded.
>
> Lastly it was suggested by Rob Herring that having a fourcc<->android
> pixel format conversion function would be useful.
>
>
> [1] https://lists.freedesktop.org/archives/mesa-dev/2017-
> November/178199.html
>
> Robert Foss (5):
>   android: Move gralloc handle struct to libdrm
>   android: Add version variable to alloc_handle_t
>   android: Mark alloc_handle_t magic variable as const
>   android: Remove member name from alloc_handle_t
>   android: Change alloc_handle_t format from Android format to fourcc
>
>  Android.mk   |  8 +++-
>  Makefile.sources |  3 ++
>  android/alloc_handle.h   | 87 ++
> ++
>  android/gralloc_drm_handle.h |  1 +
>  4 files changed, 97 insertions(+), 2 deletions(-)
>  create mode 100644 android/alloc_handle.h
>  create mode 12 android/gralloc_drm_handle.h
>
> --
> 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] egl: add dri2_surface_free_image() helper (v4)

[Gurchetan Singh]

Reviewed-by: Gurchetan Singh <gurchetansi...@chromium.org>

On Wed, Nov 15, 2017 at 7:27 AM, Gwan-gyeong Mun <elong...@gmail.com> wrote:

> To share common free DRIimage code.
>
> In preparation to adding of new platform which uses this helper.
>
> v2:
>  - Fixes from Eric's review:
>a) Split out series of refactor for helpers to a separate series.
>b) Add the new helper function and use them to replace the old code in
> the
>   same patch.
>
> v3: Fixes from Emil and Gurchetan's review
>   - Follow the naming convention which prevents too verbose name of
> functions.
> a) use a dri2_surface_$action_$object naming convention
> b) change a first argument type "struct dri2_egl_surface" to
> "_EGLSurface".
>
> v4: Fixes from Gurchetan's review
>   - add dri2_surface_free_image() helper for refactoring of almost
> identical
> functions. [1]
>
> [1] https://lists.freedesktop.org/archives/mesa-dev/2017-
> October/173219.html
>
> Signed-off-by: Mun Gwan-gyeong <elong...@gmail.com>
> ---
>  src/egl/drivers/dri2/egl_dri2.c | 11 +++
>  src/egl/drivers/dri2/egl_dri2.h |  3 +++
>  src/egl/drivers/dri2/platform_android.c | 18 +++---
>  src/egl/drivers/dri2/platform_surfaceless.c | 14 +-
>  src/egl/drivers/dri2/platform_wayland.c | 26
> --
>  5 files changed, 30 insertions(+), 42 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_
> dri2.c
> index 8861742c17..84367e69fd 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -1085,6 +1085,17 @@ dri2_egl_surface_free_local_buffers(struct
> dri2_egl_surface *dri2_surf)
> }
>  }
>
> +void
> +dri2_surface_free_image(_EGLSurface *surf, __DRIimage **img)
> +{
> +   struct dri2_egl_display *dri2_dpy = dri2_egl_display(surf->
> Resource.Display);
> +
> +   if (*img) {
> +  dri2_dpy->image->destroyImage(*img);
> +  *img = NULL;
> +   }
> +}
> +
>  /**
>   * Called via eglTerminate(), drv->API.Terminate().
>   *
> diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_
> dri2.h
> index cbeedadd4b..dda41117c6 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -452,6 +452,9 @@ dri2_egl_surface_alloc_local_buffer(struct
> dri2_egl_surface *dri2_surf,
>  void
>  dri2_egl_surface_free_local_buffers(struct dri2_egl_surface *dri2_surf);
>
> +void
> +dri2_surface_free_image(_EGLSurface *surf, __DRIimage **img);
> +
>  EGLBoolean
>  dri2_init_surface(_EGLSurface *surf, _EGLDisplay *dpy, EGLint type,
>  _EGLConfig *conf, const EGLint *attrib_list, EGLBoolean
> enable_out_fence);
> diff --git a/src/egl/drivers/dri2/platform_android.c
> b/src/egl/drivers/dri2/platform_android.c
> index 24e5ddebf9..3d6dd2e1e7 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -250,10 +250,7 @@ droid_window_enqueue_buffer(_EGLDisplay *disp,
> struct dri2_egl_surface *dri2_sur
>
> mtx_lock(>Mutex);
>
> -   if (dri2_surf->dri_image_back) {
> -  dri2_dpy->image->destroyImage(dri2_surf->dri_image_back);
> -  dri2_surf->dri_image_back = NULL;
> -   }
> +   dri2_surface_free_image(_surf->base, _surf->dri_image_back);
>
> return EGL_TRUE;
>  }
> @@ -377,17 +374,8 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDisplay
> *disp, _EGLSurface *surf)
>dri2_surf->window->common.decRef(_surf->window->common);
> }
>
> -   if (dri2_surf->dri_image_back) {
> -  _eglLog(_EGL_DEBUG, "%s : %d : destroy dri_image_back", __func__,
> __LINE__);
> -  dri2_dpy->image->destroyImage(dri2_surf->dri_image_back);
> -  dri2_surf->dri_image_back = NULL;
> -   }
> -
> -   if (dri2_surf->dri_image_front) {
> -  _eglLog(_EGL_DEBUG, "%s : %d : destroy dri_image_front", __func__,
> __LINE__);
> -  dri2_dpy->image->destroyImage(dri2_surf->dri_image_front);
> -  dri2_surf->dri_image_front = NULL;
> -   }
> +   dri2_surface_free_image(surf, _surf->dri_image_back);
> +   dri2_surface_free_image(surf, _surf->dri_image_front);
>
> dri2_dpy->core->destroyDrawable(dri2_surf->dri_drawable);
>
> diff --git a/src/egl/drivers/dri2/platform_surfaceless.c
> b/src/egl/drivers/dri2/platform_surfaceless.c
> index 977b046016..959d587c88 100644
> --- a/src/egl/drivers/dri2/platform_surfaceless.c
> +++ b/src/egl/drivers/dri2/platform_surfaceless.c
> @@ -50,18 +50,6 @@ surface

Re: [Mesa-dev] [PATCH v3 01/10] egl: add dri2_surface_fixup() helper (v3)

[Gurchetan Singh]

This patch series was intended to:

a) de-duplicate code across various platforms.
b) do preparatory work for platform_tizen.

There was some confusion[1] on how we want to move forward with
platform_tizen.  Until we can figure that out, I suggest we drop patches
that move stuff out of platform_android in preparation for platform_tizen
[patches {1, 3, 4,  6}] for now.  I would change this suggestion if other
platforms (platform_wayland, platform_drm) start using the new
dri2_surface_* functions and advertising the associated extensions by the
end of the series, i.e EXT_buffer_age.

I think patch 5 can be it's own standalone patch in platform_android for
now.  You can also justify patch 8 if platform_surfaceless starts
using dri2_surface_get_front_image.

So in conclusion, I think we can go forward with patches {2, 5, 7, 8, 9},
with the appropriate changes.

[1] https://www.mail-archive.com/mesa-dev@lists.freedesktop.
org/msg173164.html

On Tue, Oct 24, 2017 at 2:44 PM, Gwan-gyeong Mun  wrote:

> From: "Mun, Gwan-gyeong" 
>
> To share common free outdated buffers and update size code.
> This compares width and height arguments with current egl surface
> dimension,
> if the compared surface dimension is differ, then it free local buffers and
> updates dimension.
>
> In preparation to adding of new platform which uses this helper.
>
> v2: Fixes from Eric's review:
>a) Split out series of refactor for helpers to a separate series.
>b) Add the new helper function and use them to replace the old code in
> the
>   same patch.
>
> v3: Fixes from Emil and Gurchetan's review
>   - Follow the naming convention which prevents too verbose name of
> functions.
> a) use a dri2_surface_$action_$object naming convention
> b) change a first argument type "struct dri2_egl_surface" to
> "_EGLSurface".
>
> Signed-off-by: Mun Gwan-gyeong 
> Reviewed-by: Emil Velikov 
> ---
>  src/egl/drivers/dri2/egl_dri2.c | 13 +
>  src/egl/drivers/dri2/egl_dri2.h |  3 +++
>  src/egl/drivers/dri2/platform_android.c |  8 ++--
>  3 files changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_
> dri2.c
> index 503450542e..238e299aed 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -1079,6 +1079,19 @@ dri2_egl_surface_free_local_buffers(struct
> dri2_egl_surface *dri2_surf)
> }
>  }
>
> +void
> +dri2_surface_fixup(_EGLSurface *surf, int width, int height)
> +{
> +   struct dri2_egl_surface *dri2_surf = dri2_egl_surface(surf);
> +
> +   /* free outdated buffers and update the surface size */
> +   if (surf->Width != width || surf->Height != height) {
> +  dri2_egl_surface_free_local_buffers(dri2_surf);
> +  surf->Width = width;
> +  surf->Height = height;
> +   }
> +}
> +
>  /**
>   * Called via eglTerminate(), drv->API.Terminate().
>   *
> diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_
> dri2.h
> index cd2487ab22..208a03d73a 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -455,6 +455,9 @@ dri2_egl_surface_alloc_local_buffer(struct
> dri2_egl_surface *dri2_surf,
>  void
>  dri2_egl_surface_free_local_buffers(struct dri2_egl_surface *dri2_surf);
>
> +void
> +dri2_surface_fixup(_EGLSurface *surf, int width, int height);
> +
>  EGLBoolean
>  dri2_init_surface(_EGLSurface *surf, _EGLDisplay *dpy, EGLint type,
>  _EGLConfig *conf, const EGLint *attrib_list, EGLBoolean
> enable_out_fence);
> diff --git a/src/egl/drivers/dri2/platform_android.c
> b/src/egl/drivers/dri2/platform_android.c
> index e390365b8b..d00aa2 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -414,12 +414,8 @@ update_buffers(struct dri2_egl_surface *dri2_surf)
> }
>
> /* free outdated buffers and update the surface size */
> -   if (dri2_surf->base.Width != dri2_surf->buffer->width ||
> -   dri2_surf->base.Height != dri2_surf->buffer->height) {
> -  dri2_egl_surface_free_local_buffers(dri2_surf);
> -  dri2_surf->base.Width = dri2_surf->buffer->width;
> -  dri2_surf->base.Height = dri2_surf->buffer->height;
> -   }
> +   dri2_surface_fixup(_surf->base, dri2_surf->buffer->width,
> +  dri2_surf->buffer->height);
>
> return 0;
>  }
> --
> 2.14.2
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 07/10] egl: add dri2_surface_destroy_back_image() helper (v3)

[Gurchetan Singh]

No plans to merge dri2_surface_destroy_back_image
and dri2_surface_destroy_front_image ;-)?  Otherwise, looks consistent with
the previous review comments.  Patches 1-6 are:

Reviewed-by: Gurchetan Singh <gurchetansi...@chromium.org>

On Tue, Oct 24, 2017 at 2:45 PM, Gwan-gyeong Mun <elong...@gmail.com> wrote:

> To share common destroy dri_image_back code.
>
> In preparation to adding of new platform which uses this helper.
>
> v2:
>  - Move dri_image_back to outside of android ifdef block for removing of
>ifdef magic on dri2_egl_surface_destroy_image_back().
>  - Fixes from Eric's review:
>a) Split out series of refactor for helpers to a separate series.
>b) Add the new helper function and use them to replace the old code in
> the
>   same patch.
>
> v3: Fixes from Emil and Gurchetan's review
>   - Follow the naming convention which prevents too verbose name of
> functions.
> a) use a dri2_surface_$action_$object naming convention
> b) change a first argument type "struct dri2_egl_surface" to
> "_EGLSurface".
>
> Signed-off-by: Mun Gwan-gyeong <elong...@gmail.com>
> Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
> ---
>  src/egl/drivers/dri2/egl_dri2.c | 12 
>  src/egl/drivers/dri2/egl_dri2.h |  6 +-
>  src/egl/drivers/dri2/platform_android.c | 11 ++-
>  3 files changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_
> dri2.c
> index d381e52e86..dc2aecef88 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -1142,6 +1142,18 @@ dri2_surface_update_age(_EGLSurface *surf)
>dri2_surf->back->age = 1;
>  }
>
> +void
> +dri2_surface_destroy_back_image(_EGLSurface *surf)
> +{
> +   struct dri2_egl_display *dri2_dpy = dri2_egl_display(surf->
> Resource.Display);
> +   struct dri2_egl_surface *dri2_surf = dri2_egl_surface(surf);
> +
> +   if (dri2_surf->dri_image_back) {
> +  dri2_dpy->image->destroyImage(dri2_surf->dri_image_back);
> +  dri2_surf->dri_image_back = NULL;
> +   }
> +}
> +
>  /**
>   * Called via eglTerminate(), drv->API.Terminate().
>   *
> diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_
> dri2.h
> index 58f8082509..f13bdb6d12 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -303,10 +303,11 @@ struct dri2_egl_surface
>int age;
> } color_buffers[COLOR_BUFFERS_SIZE], *back, *current;
>
> +   __DRIimage *dri_image_back;
> +
>  #ifdef HAVE_ANDROID_PLATFORM
> struct ANativeWindow *window;
> struct ANativeWindowBuffer *buffer;
> -   __DRIimage *dri_image_back;
> __DRIimage *dri_image_front;
>  #endif
>
> @@ -460,6 +461,9 @@ dri2_surface_set_back_buffer(_EGLSurface *surf, void
> *buffer);
>  void
>  dri2_surface_update_age(_EGLSurface *surf);
>
> +void
> +dri2_surface_destroy_back_image(_EGLSurface *surf);
> +
>  EGLBoolean
>  dri2_init_surface(_EGLSurface *surf, _EGLDisplay *dpy, EGLint type,
>  _EGLConfig *conf, const EGLint *attrib_list, EGLBoolean
> enable_out_fence);
> diff --git a/src/egl/drivers/dri2/platform_android.c
> b/src/egl/drivers/dri2/platform_android.c
> index 45af871555..e0896ed1a0 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -228,10 +228,7 @@ droid_window_enqueue_buffer(_EGLDisplay *disp,
> struct dri2_egl_surface *dri2_sur
>
> mtx_lock(>Mutex);
>
> -   if (dri2_surf->dri_image_back) {
> -  dri2_dpy->image->destroyImage(dri2_surf->dri_image_back);
> -  dri2_surf->dri_image_back = NULL;
> -   }
> +   dri2_surface_destroy_back_image(_surf->base);
>
> return EGL_TRUE;
>  }
> @@ -355,11 +352,7 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDisplay
> *disp, _EGLSurface *surf)
>dri2_surf->window->common.decRef(_surf->window->common);
> }
>
> -   if (dri2_surf->dri_image_back) {
> -  _eglLog(_EGL_DEBUG, "%s : %d : destroy dri_image_back", __func__,
> __LINE__);
> -  dri2_dpy->image->destroyImage(dri2_surf->dri_image_back);
> -  dri2_surf->dri_image_back = NULL;
> -   }
> +   dri2_surface_destroy_back_image(surf);
>
> if (dri2_surf->dri_image_front) {
>_eglLog(_EGL_DEBUG, "%s : %d : destroy dri_image_front", __func__,
> __LINE__);
> --
> 2.14.2
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 6/8] egl: add dri2_egl_surface_destroy_image_front() helper (v2)

[Gurchetan Singh]

Hi Gwan-gyeong,

You should use dri2_surface_free_image in the next patchset you send out
(should be pretty easy to implement), but can save the polishing of struct
dri2_egl_surface for later.

On Mon, Oct 23, 2017 at 1:46 PM, Mun, Gwan-gyeong <elong...@gmail.com>
wrote:

> Hi Gurchetan,
>
> 2017-10-18 6:02 GMT+09:00 Gurchetan Singh <gurchetansi...@chromium.org>:
> > dri2_egl_surface_destroy_image_front and dri2_egl_surface_destroy_
> image_back
> > are almost identical.  Why don't you just create a
> > dri2_surface_free_image(struct dri2_egl_surface *dri2_surf, __DRIimage
> > **img) that you will call with both the front and back images?  In
> addition,
>
> As your opinion, we can rafactor more for dri2_surface_free_image.
>
> Nevertheless however, I'd suggest keeping that as separate series.
> these patches started as a way to minimise the duplication we have in
> drivers/dri2.
> So that new platforms such as Tizen do not need to copy the lot. [1]
>
> > only platform_android has dri_image_back and dri_image_front -- please
> keep
>
> In this patch, dri2_egl_surface_destroy_image_front() helper is only
> used for android
> however it will also be used for new platform (Tizen). [2]
>
> [1] https://lists.freedesktop.org/archives/mesa-dev/2017-
> October/173269.html
> [2] https://lists.freedesktop.org/archives/mesa-dev/2017-
> October/172007.html
>
>
> Thanks,
>
> Gwan-gyeong
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 1/8] egl: add dri2_egl_surface_free_outdated_buffers_and_update_size() helper (v2)

[Gurchetan Singh]

Hi Gwan-yeong,

I'm fine with the conventions you suggested -- my main nit was with the
verbosity.  The downside is you're going to have to downcast every single
time.  Your call ..

On Mon, Oct 23, 2017 at 1:22 PM, Mun, Gwan-gyeong <elong...@gmail.com>
wrote:

> Hi Emil and Gurchetan,
>
> Thank you for  reviewing the patches.
>
> 2017-10-20 6:18 GMT+09:00 Gurchetan Singh <gurchetansi...@chromium.org>:
> > De-duplicating and then trimming down works for me.
> >
> > On Thu, Oct 19, 2017 at 3:31 AM, Emil Velikov <emil.l.veli...@gmail.com>
> > wrote:
> >>
> >> On 18 October 2017 at 23:36, Gurchetan Singh
> >> <gurchetansi...@chromium.org> wrote:
> >> >> Then again, I'd suggest keeping that as separate series. These
> patches
> >> >> started as a way to minimise the duplication we have in drivers/dri2.
> >> >
> >> > I'm fine with dri2_$action_$object.  We can modify the existing
> >> > functions
> >> > later, but I recommend adopting more concise conventions in this
> >> > patchset,
> >> > i.e:
> >> >
> >> > dri2_egl_surface_record_buffers_and_update_back_buffer -->
> >> > dri2_set_back_buffer_surface
> >> > dri2_egl_surface_free_outdated_buffers_and_update_size -->
> >> > dri2_fixup_surface
> >> > dri2_egl_surface_update_buffer_age --> dri2_update_age_surface
> >> > dri2_egl_surface_get_image_front --> dri2_get_front_image_surface
> >> >
> >> Sure thing, let's use consistent names with this series.
> >>
>
> It seems great with your suggested helper function names.
>
> nevertheless, egl/driver/dri3/ codes also use such as
> dri2_surface_$action_$object naming conventions.
>
> (ie.
>   __DRIdrawable *dri2_surface_get_dri_drawable(_EGLSurface *surf)
>   void dri2_surface_set_out_fence_fd(_EGLSurface *surf, int fence_fd)
> )
>
> If you are fine with dri2_surface_$action_$object naming convention, I
> suggest these function prototype.
> These have dri2_surface_$action_$object naming convention and change
> type of first argument.
>  (struct dri2_egl_surface => _EGLSurface )
>
> ie.
>   void dri2_egl_surface_record_buffers_and_update_back_buffer(struct
> dri2_egl_surface *dri2_surf, void *buffer)
>=> void dri2_surface_set_back_buffer(_EGLSurface *surf, void *buffer)
>
>   void dri2_egl_surface_free_outdated_buffers_and_update_size(struct
> dri2_egl_surface *dri2_surf, int width, int height)
>=> void dri2_surface_fixup(_EGLSurface *surf, int width, int height)
>
>   void dri2_egl_surface_update_buffer_age(struct dri2_egl_surface
> *dri2_surf)
>=> void dri2_surface_update_age(_EGLSurface *surf)
>
>   int dri2_egl_surface_get_image_front(struct dri2_egl_surface
> *dri2_surf, unsigned int format)
>=> int dri2_surface_get_front_image(_EGLSurface *surf, unsigned int
> format)
>
>
> What do you think about this?
>
> Thanks,
>
> Gwan-gyeong.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 1/8] egl: add dri2_egl_surface_free_outdated_buffers_and_update_size() helper (v2)

[Gurchetan Singh]

De-duplicating and then trimming down works for me.

On Thu, Oct 19, 2017 at 3:31 AM, Emil Velikov <emil.l.veli...@gmail.com>
wrote:

> On 18 October 2017 at 23:36, Gurchetan Singh
> <gurchetansi...@chromium.org> wrote:
> >> Then again, I'd suggest keeping that as separate series. These patches
> >> started as a way to minimise the duplication we have in drivers/dri2.
> >
> > I'm fine with dri2_$action_$object.  We can modify the existing functions
> > later, but I recommend adopting more concise conventions in this
> patchset,
> > i.e:
> >
> > dri2_egl_surface_record_buffers_and_update_back_buffer -->
> > dri2_set_back_buffer_surface
> > dri2_egl_surface_free_outdated_buffers_and_update_size -->
> > dri2_fixup_surface
> > dri2_egl_surface_update_buffer_age --> dri2_update_age_surface
> > dri2_egl_surface_get_image_front --> dri2_get_front_image_surface
> >
> Sure thing, let's use consistent names with this series.
>
> >> goal the series is to a) remove a handful of the ifdef spaghetti and
> >
> > I agree, struct dri2_egl_surface can be refactored. I would advocate a
> > solution where the surface (a) has everything a platform needs but
> nothing
> > else (b) has a minimal amount of duplication.  I would like to look at
> the
> > struct and see if it defines buffers[5], it must mean the platform
> > implements get_buffers_with_format for example.  If a platform doesn't
> > define color_buffers, it means EXT_buffer_age is not used for whatever
> > reason.  Everything has dri_image_front -- then everything must use the
> > image extension.  I think this type of self-consistency is useful, from a
> > code is documentation point of view.  Here's pseudo-code of what I would
> > want:
> >
> I agreed with the goals but I would swap the order/priority -
> de-duplicate, then trim down.
> By de-duplicating/refactoring one could add support for X/Y fairly
> easily. Once all that is done, we can polish ;-)
>
> I fear that otherwise there will be a lot of unnecessary churn.
>
> Thanks
> Emil
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 4/8] egl: add dri2_egl_surface_update_buffer_age() helper (v2)

[Gurchetan Singh]

The comment "we don't use get_back_bo() since ..." only makes sense in
context on droid_swap_buffers.  Why aren't you calling this helper
in dri2_drm_swap_buffers and dri2_wl_swap_buffers_with_damage?  It seems
like you can.


On Tue, Oct 17, 2017 at 7:38 AM, Emil Velikov 
wrote:

> On 6 October 2017 at 22:38, Gwan-gyeong Mun  wrote:
> > To share common update buffer age code.
> > This updates old buffer's age and sets current back buffer's age to 1.
> >
> > In preparation to adding of new platform which uses this helper.
> >
> > v2:
> >  - Fixes from Eric's review:
> >a) Split out series of refactor for helpers to a separate series.
> >b) Add the new helper function and use them to replace the old code
> in the
> >   same patch.
> >  - Fixes from Rob's review:
> >Remove unneeded ifdef block
> >
> Reviewed-by: Emil Velikov 
>
> -Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] egl: set UseFallback if LIBGL_ALWAYS_SOFTWARE is set

[Gurchetan Singh]

Reviewed-by: Gurchetan Singh <gurchetansi...@chromium.org>

On Wed, Oct 18, 2017 at 9:09 AM, Eric Engestrom <eric.engest...@imgtec.com>
wrote:

> Suggested-by: Emil Velikov <emil.l.veli...@gmail.com>
> Signed-off-by: Eric Engestrom <eric.engest...@imgtec.com>
> ---
>  src/egl/drivers/dri2/platform_surfaceless.c | 3 +--
>  src/egl/drivers/dri2/platform_wayland.c | 3 +--
>  src/egl/drivers/dri2/platform_x11.c | 2 +-
>  src/egl/main/egldriver.c| 5 -
>  4 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/platform_surfaceless.c
> b/src/egl/drivers/dri2/platform_surfaceless.c
> index 2af4a40b1a6b87edb9d2..977b046016665aa99148 100644
> --- a/src/egl/drivers/dri2/platform_surfaceless.c
> +++ b/src/egl/drivers/dri2/platform_surfaceless.c
> @@ -36,7 +36,6 @@
>  #include "egl_dri2.h"
>  #include "egl_dri2_fallbacks.h"
>  #include "loader.h"
> -#include "util/debug.h"
>
>  static __DRIimage*
>  surfaceless_alloc_image(struct dri2_egl_display *dri2_dpy,
> @@ -325,7 +324,7 @@ dri2_initialize_surfaceless(_EGLDriver *drv,
> _EGLDisplay *disp)
> dri2_dpy->fd = -1;
> disp->DriverData = (void *) dri2_dpy;
>
> -   if (!env_var_as_boolean("LIBGL_ALWAYS_SOFTWARE", false)) {
> +   if (!disp->Options.UseFallback) {
>driver_loaded = surfaceless_probe_device(disp, false);
>if (!driver_loaded)
>   _eglLog(_EGL_WARNING,
> diff --git a/src/egl/drivers/dri2/platform_wayland.c
> b/src/egl/drivers/dri2/platform_wayland.c
> index 14db55ca747b07fa23f5..b38eb1c3354cfb0c5015 100644
> --- a/src/egl/drivers/dri2/platform_wayland.c
> +++ b/src/egl/drivers/dri2/platform_wayland.c
> @@ -42,7 +42,6 @@
>  #include "egl_dri2.h"
>  #include "egl_dri2_fallbacks.h"
>  #include "loader.h"
> -#include "util/debug.h"
>  #include "util/u_vector.h"
>  #include "eglglobals.h"
>
> @@ -1972,7 +1971,7 @@ dri2_initialize_wayland(_EGLDriver *drv,
> _EGLDisplay *disp)
>  {
> EGLBoolean initialized = EGL_FALSE;
>
> -   if (!env_var_as_boolean("LIBGL_ALWAYS_SOFTWARE", false))
> +   if (!disp->Options.UseFallback)
>initialized = dri2_initialize_wayland_drm(drv, disp);
>
> if (!initialized)
> diff --git a/src/egl/drivers/dri2/platform_x11.c b/src/egl/drivers/dri2/
> platform_x11.c
> index 9c20ea8f8a98c4c2b6bd..5bcdb2dac748cc0e9901 100644
> --- a/src/egl/drivers/dri2/platform_x11.c
> +++ b/src/egl/drivers/dri2/platform_x11.c
> @@ -1460,7 +1460,7 @@ dri2_initialize_x11(_EGLDriver *drv, _EGLDisplay
> *disp)
>  {
> EGLBoolean initialized = EGL_FALSE;
>
> -   if (!env_var_as_boolean("LIBGL_ALWAYS_SOFTWARE", false)) {
> +   if (!disp->Options.UseFallback) {
>  #ifdef HAVE_DRI3
>if (!env_var_as_boolean("LIBGL_DRI3_DISABLE", false))
>   initialized = dri2_initialize_x11_dri3(drv, disp);
> diff --git a/src/egl/main/egldriver.c b/src/egl/main/egldriver.c
> index 33f8f57aeb11e06f92f2..1ff37850e05f729dd35a 100644
> --- a/src/egl/main/egldriver.c
> +++ b/src/egl/main/egldriver.c
> @@ -44,6 +44,8 @@
>  #include "egldriver.h"
>  #include "egllog.h"
>
> +#include "util/debug.h"
> +
>  static mtx_t _eglModuleMutex = _MTX_INITIALIZER_NP;
>  static _EGLDriver *_eglDriver;
>
> @@ -86,7 +88,8 @@ _eglMatchDriver(_EGLDisplay *dpy)
> assert(!dpy->Initialized);
>
> /* set options */
> -   dpy->Options.UseFallback = EGL_FALSE;
> +   dpy->Options.UseFallback =
> +  env_var_as_boolean("LIBGL_ALWAYS_SOFTWARE", false);
>
> best_drv = _eglMatchAndInitialize(dpy);
> if (!best_drv) {
> --
> Cheers,
>   Eric
>
> ___
> 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 v2 1/8] egl: add dri2_egl_surface_free_outdated_buffers_and_update_size() helper (v2)

[Gurchetan Singh]

> Then again, I'd suggest keeping that as separate series. These patches
> started as a way to minimise the duplication we have in drivers/dri2.

I'm fine with dri2_$action_$object.  We can modify the existing functions
later, but I recommend adopting more concise conventions in this patchset,
i.e:

dri2_egl_surface_record_buffers_and_update_back_buffer -->
dri2_set_back_buffer_surface
dri2_egl_surface_free_outdated_buffers_and_update_size -->
dri2_fixup_surface
dri2_egl_surface_update_buffer_age --> dri2_update_age_surface
dri2_egl_surface_get_image_front --> dri2_get_front_image_surface

> goal the series is to a) remove a handful of the ifdef spaghetti and

I agree, struct dri2_egl_surface can be refactored. I would advocate a
solution where the surface (a) has everything a platform needs but nothing
else (b) has a minimal amount of duplication.  I would like to look at the
struct and see if it defines buffers[5], it must mean the platform
implements get_buffers_with_format for example.  If a platform doesn't
define color_buffers, it means EXT_buffer_age is not used for whatever
reason.  Everything has dri_image_front -- then everything must use the
image extension.  I think this type of self-consistency is useful, from a
code is documentation point of view.  Here's pseudo-code of what I would
want:

#if not defined(SURFACELESS)

__DRIbuffer  buffers[5];

#if not defined(PLATFORM_X11)

struct {
 void *native_buffer; // aka wl_buffer/gbm_bo/ANativeWindowBuffer
 boollocked;
 int age;
 void *private // aka dri_image, linear_copy, *data used by platform_wayland
} color_buffers[COLOR_BUFFERS_SIZE], *back, *current;

/* EGL-owned buffers */
__DRIbuffer   *local_buffers[__DRI_BUFFER_COUNT];

#endif
#endif

WDYT?

On Wed, Oct 18, 2017 at 2:55 AM, Emil Velikov <emil.l.veli...@gmail.com>
wrote:

> On 17 October 2017 at 21:38, Gurchetan Singh
> <gurchetansi...@chromium.org> wrote:
> > The naming is verbose and somewhat inconsistent.  We have:
> >
> > dri2_init_surface
> > dri2_fini_surface
> > dri2_egl_surface_alloc_local_buffer
> > dri2_egl_surface_free_local_buffers
> >
> > I suggest you implement the following convention:
> >
> > dri2_surface_init
> > dri2_surface_fini
> > dri2_surface_alloc_attachment (instead of 'local_buffers')
> > dri2_surface_free_attachments  (instead of 'local_buffers')
> >
> Suggestions seems great, although I'm a bit unsure on the naming
> convention - dri2_$object_$action vs dri2_$action_$object.
> Most of src/egl/drivers/dri2/ alongside all of src/egl/main/ use the
> latter.
>
> Then again, I'd suggest keeping that as separate series. These patches
> started as a way to minimise the duplication we have in drivers/dri2.
> So that new platforms such as Tizen do not need to copy the lot, again.
>
> > and instead of dri2_egl_surface_free_outdated_buffers_and_update_size,
> we
> > can just have:
> >
> > dri2_surface_update
> >
> Modulo naming convention (aka dri2_update_surface) I like the name.
>
> > And can you wrap these functions around the:
> >
> > #if defined(HAVE_WAYLAND_PLATFORM) || defined(HAVE_DRM_PLATFORM) ||
> > defined(HAVE_ANDROID_PLATFORM)
> >
> > pre-processors checks just to make clear what platforms use the
> attachment
> > (aka 'local_buffers') functionality.
> >
> While technically correct, I'd opt against this. Sort of a secondary
> goal the series is to a) remove a handful of the ifdef spaghetti and
> b) unify the diverging platforms.
> Of which surfaceless and android being the [rather] odd ones out.
>
> We could continue to minimise the diversion as time goes by, and this
> steers us in the right direction.
>
> Thanks
> Emil
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 6/8] egl: add dri2_egl_surface_destroy_image_front() helper (v2)

[Gurchetan Singh]

dri2_egl_surface_destroy_image_front
and dri2_egl_surface_destroy_image_back are almost identical.  Why don't
you just create a dri2_surface_free_image(struct dri2_egl_surface
*dri2_surf, __DRIimage **img) that you will call with both the front and
back images?  In addition, only platform_android has dri_image_back
and dri_image_front -- please keep the pre-processor checks.  You can,
however, merge the dri_image_front (used by platform_android) and front
(used by platform_surfaceless).

On Fri, Oct 6, 2017 at 2:38 PM, Gwan-gyeong Mun  wrote:

> To share common destroy dri_image_front code.
>
> In preparation to adding of new platform which uses this helper.
>
> v2:
>  - Move dri_image_front to outside of android ifdef block for removing of
>ifdef magic on dri2_egl_surface_destroy_image_front().
>  - Fixes from Eric's review:
>a) Split out series of refactor for helpers to a separate series.
>b) Add the new helper function and use them to replace the old code in
> the
>   same patch.
>
> Signed-off-by: Mun Gwan-gyeong 
> ---
>  src/egl/drivers/dri2/egl_dri2.c | 12 
>  src/egl/drivers/dri2/egl_dri2.h |  5 -
>  src/egl/drivers/dri2/platform_android.c |  7 +--
>  3 files changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_
> dri2.c
> index bb4944358d..67ae33cdc9 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -1127,6 +1127,18 @@ dri2_egl_surface_destroy_image_back(struct
> dri2_egl_surface *dri2_surf)
> }
>  }
>
> +void
> +dri2_egl_surface_destroy_image_front(struct dri2_egl_surface *dri2_surf)
> +{
> +   struct dri2_egl_display *dri2_dpy =
> +  dri2_egl_display(dri2_surf->base.Resource.Display);
> +
> +   if (dri2_surf->dri_image_front) {
> +  dri2_dpy->image->destroyImage(dri2_surf->dri_image_front);
> +  dri2_surf->dri_image_front = NULL;
> +   }
> +}
> +
>  /**
>   * Called via eglTerminate(), drv->API.Terminate().
>   *
> diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_
> dri2.h
> index 165749ebb1..83b9e368b2 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -313,11 +313,11 @@ struct dri2_egl_surface
> } color_buffers[COLOR_BUFFERS_SIZE], *back, *current;
>
> __DRIimage *dri_image_back;
> +   __DRIimage *dri_image_front;
>
>  #ifdef HAVE_ANDROID_PLATFORM
> struct ANativeWindow *window;
> struct ANativeWindowBuffer *buffer;
> -   __DRIimage *dri_image_front;
>  #endif
>
>  #if defined(HAVE_SURFACELESS_PLATFORM)
> @@ -475,6 +475,9 @@ dri2_egl_surface_update_buffer_age(struct
> dri2_egl_surface *dri2_surf);
>  void
>  dri2_egl_surface_destroy_image_back(struct dri2_egl_surface *dri2_surf);
>
> +void
> +dri2_egl_surface_destroy_image_front(struct dri2_egl_surface *dri2_surf);
> +
>  EGLBoolean
>  dri2_init_surface(_EGLSurface *surf, _EGLDisplay *dpy, EGLint type,
>  _EGLConfig *conf, const EGLint *attrib_list, EGLBoolean
> enable_out_fence);
> diff --git a/src/egl/drivers/dri2/platform_android.c
> b/src/egl/drivers/dri2/platform_android.c
> index 421395b5d7..c98802774c 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -354,12 +354,7 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDisplay
> *disp, _EGLSurface *surf)
> }
>
> dri2_egl_surface_destroy_image_back(dri2_surf);
> -
> -   if (dri2_surf->dri_image_front) {
> -  _eglLog(_EGL_DEBUG, "%s : %d : destroy dri_image_front", __func__,
> __LINE__);
> -  dri2_dpy->image->destroyImage(dri2_surf->dri_image_front);
> -  dri2_surf->dri_image_front = NULL;
> -   }
> +   dri2_egl_surface_destroy_image_front(dri2_surf);
>
> dri2_dpy->core->destroyDrawable(dri2_surf->dri_drawable);
>
> --
> 2.14.2
>
> ___
> 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 v2 2/8] egl: refactor color_buffers structure for deduplicating

[Gurchetan Singh]

Can you wrap color_buffers around:

#if defined(HAVE_WAYLAND_PLATFORM) || defined(HAVE_DRM_PLATFORM)
|| defined(HAVE_ANDROID_PLATFORM)

flags?  This is because platform_surfaceless has no native surfaces and
it's good to be explicit in that regard.

On Fri, Oct 6, 2017 at 2:38 PM, Gwan-gyeong Mun  wrote:

> This is added for preventing adding of new color buffers structure and
> back*
> when new platform backend is added.
> This refactoring separates out the common and platform specific bits.
> This makes odd casting in the platform_foo.c but it prevents adding of new
> ifdef magic.
> Because of color_buffers array size is different on android and wayland
> /drm,
> it adds COLOR_BUFFERS_SIZE macro.
>  - android's color buffers array size is 3.
>drm & wayland's color buffers array size is 4.
>
> Fixes from Rob's review:
>  - refactor to separate out the common and platform specific bits.
>
> Fixes from Emil's review:
>  - use suggested color buffers structure shape.
>it makes a buffer pointer of each platform to void pointer type.
>
> Signed-off-by: Mun Gwan-gyeong 
> ---
>  src/egl/drivers/dri2/egl_dri2.h | 30 +-
>  src/egl/drivers/dri2/platform_android.c | 10 +++---
>  src/egl/drivers/dri2/platform_drm.c | 55
> +
>  src/egl/drivers/dri2/platform_wayland.c | 46 +--
>  4 files changed, 71 insertions(+), 70 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.h
> b/src/egl/drivers/dri2/egl_dri2.h
> index 017895f0d9..08ccf24410 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -65,6 +65,15 @@ struct zwp_linux_dmabuf_v1;
>
>  #endif /* HAVE_ANDROID_PLATFORM */
>
> +#if defined(HAVE_WAYLAND_PLATFORM) || defined(HAVE_DRM_PLATFORM)
> +#define COLOR_BUFFERS_SIZE 4
> +#else
> +   /* Usually Android uses at most triple buffers in ANativeWindow
> +* so hardcode the number of color_buffers to 3.
> +*/
> +#define COLOR_BUFFERS_SIZE 3
> +#endif
> +
>  #include "eglconfig.h"
>  #include "eglcontext.h"
>  #include "egldisplay.h"
> @@ -286,39 +295,28 @@ struct dri2_egl_surface
> /* EGL-owned buffers */
> __DRIbuffer   *local_buffers[__DRI_BUFFER_COUNT];
>
> -#if defined(HAVE_WAYLAND_PLATFORM) || defined(HAVE_DRM_PLATFORM)
> +   /* Used to record all the buffers created by each platform's native
> window
> +* and their ages.
> +*/
> struct {
> +  void *native_buffer; // aka wl_buffer/gbm_bo/ANativeWindowBuffer
>  #ifdef HAVE_WAYLAND_PLATFORM
> -  struct wl_buffer   *wl_buffer;
>__DRIimage *dri_image;
>/* for is_different_gpu case. NULL else */
>__DRIimage *linear_copy;
>/* for swrast */
>void *data;
>int data_size;
> -#endif
> -#ifdef HAVE_DRM_PLATFORM
> -  struct gbm_bo   *bo;
>  #endif
>boollocked;
>int age;
> -   } color_buffers[4], *back, *current;
> -#endif
> +   } color_buffers[COLOR_BUFFERS_SIZE], *back, *current;
>
>  #ifdef HAVE_ANDROID_PLATFORM
> struct ANativeWindow *window;
> struct ANativeWindowBuffer *buffer;
> __DRIimage *dri_image_back;
> __DRIimage *dri_image_front;
> -
> -   /* Used to record all the buffers created by ANativeWindow and their
> ages.
> -* Usually Android uses at most triple buffers in ANativeWindow
> -* so hardcode the number of color_buffers to 3.
> -*/
> -   struct {
> -  struct ANativeWindowBuffer *buffer;
> -  int age;
> -   } color_buffers[3], *back;
>  #endif
>
>  #if defined(HAVE_SURFACELESS_PLATFORM)
> diff --git a/src/egl/drivers/dri2/platform_android.c
> b/src/egl/drivers/dri2/platform_android.c
> index 0acbb38bd8..67e739c1fc 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -193,10 +193,10 @@ droid_window_dequeue_buffer(struct dri2_egl_surface
> *dri2_surf)
>  */
> EGLBoolean updated = EGL_FALSE;
> for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
> -  if (!dri2_surf->color_buffers[i].buffer) {
> - dri2_surf->color_buffers[i].buffer = dri2_surf->buffer;
> +  if (!dri2_surf->color_buffers[i].native_buffer) {
> + dri2_surf->color_buffers[i].native_buffer = (void
> *)dri2_surf->buffer;
>}
> -  if (dri2_surf->color_buffers[i].buffer == dri2_surf->buffer) {
> +  if (dri2_surf->color_buffers[i].native_buffer == (void
> *)dri2_surf->buffer) {
>   dri2_surf->back = _surf->color_buffers[i];
>   updated = EGL_TRUE;
>   break;
> @@ -208,10 +208,10 @@ droid_window_dequeue_buffer(struct dri2_egl_surface
> *dri2_surf)
> * the color_buffers
> */
>for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
> - dri2_surf->color_buffers[i].buffer = NULL;
> + dri2_surf->color_buffers[i].native_buffer = NULL;
>