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
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.c
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
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 falsely
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.
:
> 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
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(.
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 f
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 fi
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(.
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/vir
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
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 ccbb
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://git
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/virg
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
b/src/gallium/drivers/virgl/virgl_resou
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
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, &device)".On
Sat, Oct 20, 2018 at 11:46 PM Mathias Fröhlich
wrote:
>
> Hi Emil,
>
> On Wednesday, 3 October 2018 16:02:4
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-
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-
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-
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-
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_
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 b
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 -->
VIRGL_MAX_
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(-)
ers,
>
> -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 mo
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
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 usefu
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 usef
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
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.
> - [Gurcheta
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
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/
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/me
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 1
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
dEQP-GLES31.functional.image_l
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
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_i
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
https://lists.freedesktop
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 tg
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
Reviewed-by: Gurchetan Singh
On Wed, May 23, 2018 at 1:36 AM Tomeu Vizoso
wrote:
> Virgl could save a lot of work converting buffers in the host side
> between formats if Mesa supported a bunch of other formats when reading
> pixels.
>
> This commit adds cases to handle spec
Reviewed-by: Gurchetan Singh
On Mon, May 21, 2018 at 12:37 AM Gert Wollny
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
Reviewed-by: Gurchetan Singh
On Fri, May 18, 2018 at 6:01 AM Elie Tournier
wrote:
> Wrong ML. I add
>
> On Fri, May 18, 2018 at 10:46:29AM +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > The host side hasn't got support for this feature yet, so don&#
Yes, it seems needed for the GLES on GLES work. Still needs to land:
Reviewed-by: Gurchetan Singh
On Wed, May 9, 2018 at 7:15 PM Dave Airlie wrote:
> On 4 April 2018 at 02:06, Jakob Bornecrantz wrote:
> > Signed-off-by: Jakob Bornecrantz
> not sure if still needed or not, but
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 everyth
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
F_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
(don't have commit access so hopefully someone merges this)
O
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 i
On Fri, Apr 27, 2018 at 2:00 AM, Nicolai Hähnle wrote:
> On 26.04.2018 04:30, Marek Olšák wrote:
>>
>> On Wed, Apr 25, 2018 at 6:56 PM, Gurchetan Singh
>> mailto:gurchetansi...@chromium.org>> wrote:
>>
>> On Wed, Apr 25, 2018 at 2:16 PM, Marek Olšák
On Thu, Apr 26, 2018 at 3:08 PM, Marek Olšák wrote:
> On Thu, Apr 26, 2018 at 2:40 PM, Gurchetan Singh
> wrote:
>>
>> On Thu, Apr 26, 2018 at 10:23 AM, Marek Olšák wrote:
>> > Gurchetan, can you confirm that the stride returned at alloc() is only
>> >
e:
>>
>> 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
>> 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 wrote:
> On Wed, Apr 25, 2018 at 6:56 PM, Gurchetan Singh
> wrote:
>>
>> On Wed, Apr 25, 2018 at 2:16 PM, Marek Olšák wrote:
>> > From: Nico
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. Unfortun
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
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
including
PIPE_QUERY_OCCLUSION_PREDICATE_CONSERVATIVE there makes sense for now.
Reviewed-by: Gurchetan Singh
Tested-by: Gurchetan Singh
On Tue, Feb 13, 2018 at 6:58 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> The gallium query types changed, so we need to remap from the
> gallium
On Wed, Feb 14, 2018 at 3:57 PM, Marek Olšák wrote:
> Do you have commit access?
No, would appreciate a merge ;-)
> Marek
>
> On Thu, Feb 15, 2018 at 12:40 AM, gurchetansi...@chromium.org
> wrote:
>> From: Gurchetan Singh
>>
>> The ARB_viewport_arr
On Thu, Feb 8, 2018 at 6:01 PM, Ilia Mirkin wrote:
> On Thu, Feb 8, 2018 at 8:58 PM, Ilia Mirkin wrote:
>> On Thu, Feb 8, 2018 at 8:36 PM, Gurchetan Singh
>> wrote:
>>> On Thu, Feb 8, 2018 at 5:15 PM, Marek Olšák wrote:
>>>>
>>>> On Fri, Feb
On Thu, Feb 8, 2018 at 5:15 PM, Marek Olšák wrote:
>
> On Fri, Feb 9, 2018 at 2:12 AM, Gurchetan Singh
> wrote:
> > On Thu, Feb 8, 2018 at 4:46 PM, Marek Olšák wrote:
> >>
> >> This is not the correct fix.
> >>
> >> clear_with_quad c
n Fri, Feb 9, 2018 at 1:28 AM, gurchetansi...@chromium.org
> wrote:
> > From: Gurchetan Singh
> >
> > 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_C
Any plans to merge this? This fixes Chrome not starting with Virgl.
Reviewed-by: Gurchetan Singh
Tested-by: Gurchetan Singh
On Mon, Nov 13, 2017 at 12:53 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This fixes some dEQP tests that generated bad shaders.
>
> Fixes: b6f6ead
gt; On Fri, Jan 12, 2018 at 2:29 AM, Tomasz Figa wrote:
> > Hi Rob,
> >
> > On Fri, Jan 12, 2018 at 5:26 AM, Robert Foss
> wrote:
> >> Heya,
> >>
> >>
> >> On 12/22/17 1:09 PM, Tomasz Figa wrote:
> >>>
> >>> On Fri, Dec
12, 2018 at 5:26 AM, Robert Foss
>> wrote:
>>
>>> Heya,
>>>
>>>
>>> On 12/22/17 1:09 PM, Tomasz Figa wrote:
>>>
>>>>
>>>> On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
>>>> wrote:
>>>>
&g
gt; Heya,
>
>
> On 12/22/17 1:09 PM, Tomasz Figa wrote:
>
>> On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
>> wrote:
>>
>>> So the plan is for alloc_handle_t to not be sub-classed by the
>>> implementations, but have all necessary information that
handle would
add complexity to our (*registerBuffer) path.
On Thu, Dec 21, 2017 at 10:14 AM, Rob Herring wrote:
> On Wed, Dec 13, 2017 at 5:02 PM, Gurchetan Singh
> wrote:
> > Hi Robert,
> >
> > Thanks for looking into this! We need to decide if we want:
> >
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 drmAndro
Reviewed-by: Gurchetan Singh
On Wed, Nov 15, 2017 at 7:27 AM, Gwan-gyeong Mun 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
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_and
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
On Tue, Oct 24, 2017 at 2:45 PM, Gwan-gyeong Mun wrote:
> To share common dest
GMT+09:00 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
you for reviewing the patches.
>
> 2017-10-20 6:18 GMT+09:00 Gurchetan Singh :
> > De-duplicating and then trimming down works for me.
> >
> > On Thu, Oct 19, 2017 at 3:31 AM, Emil Velikov
> > wrote:
> >>
> >> On 18 October 2017 at 23:36, Gurchetan
De-duplicating and then trimming down works for me.
On Thu, Oct 19, 2017 at 3:31 AM, Emil Velikov
wrote:
> On 18 October 2017 at 23:36, Gurchetan Singh
> wrote:
> >> Then again, I'd suggest keeping that as separate series. These patches
> >> started as a way to min
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 20
Reviewed-by: Gurchetan Singh
On Wed, Oct 18, 2017 at 9:09 AM, Eric Engestrom
wrote:
> Suggested-by: Emil Velikov
> Signed-off-by: Eric Engestrom
> ---
> src/egl/drivers/dri2/platform_surfaceless.c | 3 +--
> src/egl/drivers/dri2/platform_wayland.c | 3 +--
> sr
OUNT];
#endif
#endif
WDYT?
On Wed, Oct 18, 2017 at 2:55 AM, Emil Velikov
wrote:
> On 17 October 2017 at 21:38, Gurchetan Singh
> wrote:
> > The naming is verbose and somewhat inconsistent. We have:
> >
> > dri2_init_surface
> > dri2_fini_surface
> >
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 h
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
