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
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
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
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 -08
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
>
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
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.
&
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:
>
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)
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.
&
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
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
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)
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
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
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
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
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.
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
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 +-
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
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
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 EGLDevic
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
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
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"
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"
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"
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"
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 -->
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
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(-)
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
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 -->
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(-)
-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 compu
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
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
&
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
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
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
> whi
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
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.
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] Fi
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
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
> ---
>
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)
---
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
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(+)
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.
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
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 ++--
>
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++
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)
>
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.
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 s
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
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 inse
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
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 inse
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
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_in
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
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 whe
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
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
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>
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
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
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 hop
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
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 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:
>> > Gurche
: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
&
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, 201
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
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
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
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 Airli
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:
>> F
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
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:
>
> 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(G
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:
> Fr
@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
gt;
>> 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, Gurch
om>
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
>>> implementa
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
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
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 fro
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
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
>
> 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_eg
>
> 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&g
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 sep
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
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>
f
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:
&g
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
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
1 - 100 of 164 matches
Mail list logo