The original dri2_format_to_pipe_format function just misses case branch
for __DRI_IMAGE_FORMAT_XBGR. I discovered this when debugging one google
map crash inside emulator.
Signed-off-by: Lepton Wu <lep...@chromium.org>
---
src/gallium/state_trackers/dri/dri2.c | 3 +++
1 file chan
On 19 June 2017 at 18:51, Lepton Wu <lep...@google.com> wrote:
> > The original dri2_format_to_pipe_format function just misses case branch
> > for __DRI_IMAGE_FORMAT_XBGR. I discovered this when debugging one
> google
> > map crash inside emulator.
> >
&
Gentle ping. Thanks.
On Wed, Dec 27, 2017 at 11:35 PM, Lepton Wu <lep...@chromium.org> wrote:
> v2: address comments from Tomasz Figa
>a) Add more check for plane size.
>b) Avoid duplicated mapping and leaked mapping.
>c) Other minor changes.
>
> Signe
v2: address comments from Tomasz Figa
a) Add more check for plane size.
b) Avoid duplicated mapping and leaked mapping.
c) Other minor changes.
Signed-off-by: Lepton Wu <lep...@chromium.org>
Change-Id: I0863f522976cc8863d6e95492d9346df35c066ec
---
src/gallium/winsys/sw/k
On Thu, Aug 16, 2018 at 1:37 PM Ray Strode wrote:
>
> From: Ray Strode
>
> At the moment, depending on pipe transfer flags, the dumb
> buffer map address can end up at either kms_sw_dt->ro_mapped
> or kms_sw_dt->mapped.
>
> When it's time to unmap the dumb buffer, both locations get unmapped,
>
s memory.
> Thanks for fixing this issue. For the future, feel free to use a fixes
> tag (+cc) as below.
> It provides a nice reference when picking the fix for stable branches,
> plus the author is your first line reviewer ;-)
>
> Fixes: d891f28df9a ("gallium/winsys/kms: Fix possi
The current code is buggy: if there are only 12 dwords left in cbuf,
we emit a zero data length command which will be rejected by virglrenderer.
Fix it by calling flush in this case.
---
src/gallium/drivers/virgl/virgl_encode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
with this CL, if user call dt_map for single
plane buffer multiple times, they will get same pointer, and if they
call dt_unmap
, with this CL, it still get unmapped.
On Wed, Mar 7, 2018 at 7:14 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 6 March 2018 at 22:43, Lepto
I misunderstanding your point, now I got it and will do more test to
see if removing this hunk will cause some issue
in some cases of multi plane code path. Thanks.
On Wed, Mar 7, 2018 at 10:14 AM, Lepton Wu <lep...@chromium.org> wrote:
> Actually the reason why I need this CL:
>
>
OK, I will send out a new version which omit unmap in dt_destory.
Any way, even we need this code, it could be a separate patch.
On Wed, Mar 7, 2018 at 7:14 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 6 March 2018 at 22:43, Lepton Wu <lep...@chromium.org> wrote:
>&
For this patch, actually it's as same as V3. But since it depends on
the 1st patch, I also update the title to V4.
On Wed, Mar 7, 2018 at 2:39 PM, Lepton Wu <lep...@chromium.org> wrote:
> Add a new struct kms_sw_plane which delegate a plane and use it
> in place of sw_displaytarg
mapping.
Change-Id: I65308f0ff2640bd57b2577c6a3469540c9722859
Signed-off-by: Lepton Wu <lep...@chromium.org>
---
.../winsys/sw/kms-dri/kms_dri_sw_winsys.c | 21 ---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsy
Add a new struct kms_sw_plane which delegate a plane and use it
in place of sw_displaytarget. Multiple planes share same underlying
kms_sw_displaytarget.
Change-Id: I0e9ca1d0ba0aa78c27dfdb50c30dc0c424fec172
Signed-off-by: Lepton Wu <lep...@chromium.org>
---
.../winsys/sw/k
Add a new struct kms_sw_plane which delegate a plane and use it
in place of sw_displaytarget. Multiple planes share same underlying
kms_sw_displaytarget.
Change-Id: I0e9ca1d0ba0aa78c27dfdb50c30dc0c424fec172
Signed-off-by: Lepton Wu <lep...@chromium.org>
---
.../winsys/sw/k
ough the cracks.
>
> There's one important functionality change which should be split out
> and documented.
> The rest is just style nitpicks.
>
> On 28 December 2017 at 07:35, Lepton Wu <lep...@chromium.org> wrote:
>> v2: address comments from Tomasz Figa
>>
mapping.
Change-Id: I65308f0ff2640bd57b2577c6a3469540c9722859
Signed-off-by: Lepton Wu <lep...@chromium.org>
---
.../winsys/sw/kms-dri/kms_dri_sw_winsys.c | 26 ++-
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsy
Ping. Any more comments or missing stuff to get this commited into master?
Thanks.
On Wed, Mar 7, 2018 at 2:39 PM, Lepton Wu <lep...@chromium.org> wrote:
> If user calls map twice for kms_sw_displaytarget, the first mapped
> buffer could get leaked. Instead of calling mmap ever
com> wrote:
> On 13 March 2018 at 11:46, Tomasz Figa <tf...@chromium.org> wrote:
>> On Thu, Mar 8, 2018 at 7:39 AM, Lepton Wu <lep...@chromium.org> wrote:
>>> If user calls map twice for kms_sw_displaytarget, the first mapped
>>> buffer could get leaked. Inste
If users are running mesa under old version of qemu or have turned off
GL at runtime, virtio gpu driver actually doesn't work. Adds a detection
here so mesa can fall back to software rendering.
v2:
- move detection from loader to virgl (Ilia, Emil)
Signed-off-by: Lepton Wu <lep...@chromium.
I know this looks like a hack. But just want to send this out for comments
to see how can I address this issue in mesa:
virgl driver enabled image can't work on legacy qemu or GL disabled qemu.
It seems another choice could be playing with MESA_LOADER_DRIVER_OVERRIDE to
override driver name, but
If user are running mesa under old version of qemu or have turned off
GL at runtime, virtio gpu driver actually doesn't work. Adding a detection
here can make sure same disk image work with both cases.
Signed-off-by: Lepton Wu <lep...@chromium.org>
---
src/loader/loader.
On Thu, Apr 5, 2018 at 12:38 PM, Lepton Wu <lep...@chromium.org> wrote:
> If users are running mesa under old version of qemu or have turned off
> GL at runtime, virtio gpu driver actually doesn't work. Adds a detection
> here so mesa can fall back to software rendering.
&g
Add a new struct kms_sw_plane which delegate a plane and use it
in place of sw_displaytarget. Multiple planes share same underlying
kms_sw_displaytarget.
Change-Id: I0e9ca1d0ba0aa78c27dfdb50c30dc0c424fec172
Signed-off-by: Lepton Wu <lep...@chromium.org>
---
.../winsys/sw/k
mapping. Also introduce reference count for
mapped buffer so we can unmap them at right time.
Change-Id: I65308f0ff2640bd57b2577c6a3469540c9722859
Signed-off-by: Lepton Wu <lep...@chromium.org>
---
.../winsys/sw/kms-dri/kms_dri_sw_winsys.c | 44 +++
1 file changed, 36 inse
at 10:44 PM, Emil Velikov <emil.l.veli...@gmail.com>
>>> wrote:
>>>> On 20 March 2018 at 04:40, Tomasz Figa <tf...@chromium.org> wrote:
>>>>> On Tue, Mar 20, 2018 at 2:55 AM, Emil Velikov <emil.l.veli...@gmail.com>
>>>>> wrote:
>&
On Mon, Mar 19, 2018 at 10:55 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> Hi Lepton,
>
> On 19 March 2018 at 17:33, Lepton Wu <lep...@chromium.org> wrote:
>> If user calls map twice for kms_sw_displaytarget, the first mapped
>> buffer could get leaked. I
Add a new struct kms_sw_plane which delegate a plane and use it
in place of sw_displaytarget. Multiple planes share same underlying
kms_sw_displaytarget.
Reviewed-by: Tomasz Figa <tf...@chromium.org>
Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
Signed-off-by: Le
mapping. Also introduce reference count for
mapped buffer so we can unmap them at right time.
Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
Reviewed-by: Tomasz Figa <tf...@chromium.org>
Signed-off-by: Lepton Wu <lep...@chromium.org>
---
.../winsys/sw/kms-dri/kms_dri_sw
)
v6:
- remove change-id in commit message (Tomasz)
v7:
- add revision history in commit message (Emil)
Reviewed-by: Tomasz Figa <tf...@chromium.org>
Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
Signed-off-by: Lepton Wu <lep...@chromium.org>
---
...
munmap in dt_destory
v6:
- remove change-id in commit message (Tomasz)
v7:
- remove munmap from dt_destory again (Emil)
- add revision history in commit message (Emil)
Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
Reviewed-by: Tomasz Figa <tf...@chromium.org>
Signed-off-by: Le
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.
>
> On Mon, Mar 18, 2019 at 4:40 PM Lepton Wu wrote:
>
>> This fd was create in virgl_drm_screen_create
On Wed, Mar 20, 2019 at 3:03 PM Chia-I Wu wrote:
> On Mon, Mar 18, 2019 at 2:22 PM Lepton Wu wrote:
>
>> The old code could use gem name as key when inserting it to bo_handles
>> hash table while trying to remove it from hash table with bo_handle as
>> key in virgl_hw_re
On Tue, Mar 19, 2019 at 4:29 AM Erik Faye-Lund
wrote:
> On Mon, 2019-03-18 at 14:44 -0700, Lepton Wu wrote:
> > virgl render complains about "Illegal resource" when running
> > dEQP-EGL.functional.color_clears.single_context.gles2.rgb888_window,
> > the reason is t
to bo_names hash table when handle type is SHARED.
Signed-off-by: Lepton Wu
---
.../winsys/virgl/drm/virgl_drm_winsys.c | 24 +--
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
b/src/gallium/winsys/virgl/drm
virgl render complains about "Illegal resource" when running
dEQP-EGL.functional.color_clears.single_context.gles2.rgb888_window,
the reason is that a zero bind value was given for temp resource.
Signed-off-by: Lepton Wu
---
src/gallium/drivers/virgl/virgl_texture.c | 10
-by: Lepton Wu
---
src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
index 120e8eda2cd..01811a0e997 100644
--- a/src
virgl render complains about "Illegal resource" when running
dEQP-EGL.functional.color_clears.single_context.gles2.rgb888_window,
the reason is that a zero bind value was given for temp resource.
Signed-off-by: Lepton Wu
---
src/gallium/drivers/virgl/virgl_texture.c | 1 +
1 file
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
On Mon, Apr 8, 2019 at 11:10 AM Chia-I Wu wrote:
>
>
>
> On Mon, Apr 8, 2019 at 9:34 AM Lepton Wu wrote:
>>
>> The old code could use gem name as key when inserting it to bo_handles
>> hash table while trying to remove it from hash table with bo_handle as
res_is_ref, which assumes each kernel GEM object has a
>> > unique virgl_hw_res.
>> >
>> > On Mon, Apr 1, 2019 at 12:37 PM Lepton Wu wrote:
>> >>
>> >>
>> >>
>> >>
>> >> On Wed, Mar 20, 2019 at 3:03 PM Chia-I W
/heads/master/opengl/libs/EGL/eglApi.cpp#608
On Wed, Jul 31, 2019 at 3:50 PM Lepton Wu wrote:
>
> From: Emil Velikov
>
> As said in the EGL_KHR_platform_android extensions
>
> For each EGLConfig that belongs to the Android platform, the
> EGL_NATIVE_VISUAL_ID attribute
That's interesting. The android frame work will hard coded to use
RGBA_ and set it as window format here:
https://android.googlesource.com/platform/frameworks/native/+/refs/heads/master/opengl/libs/EGL/eglApi.cpp#738
Do you have a custom version of android which do different code here?
For
a1be5d3;hb=519828c5b649e5e83f18444666f0672ab7852518;hpb=792c8dc009bd3a0c44eb39e757a95e099c03b54c
Not sure how difficult it is to push this to aosp android.
On Thu, Aug 15, 2019 at 3:31 PM Mauro Rossi wrote:
>
> Hi Lepton,
>
> On Thu, Aug 15, 2019 at 9:58 PM Lepton Wu wrote:
>>
>> That's i
On Thu, Aug 15, 2019 at 3:31 PM Mauro Rossi wrote:
>
> Hi Lepton,
>
> On Thu, Aug 15, 2019 at 9:58 PM Lepton Wu wrote:
>>
>> That's interesting. The android frame work will hard coded to use
>> RGBA_ and set it as window format here:
>>
>> https://an
On Tue, Aug 27, 2019 at 7:14 PM Lepton Wu wrote:
>
> On Thu, Aug 15, 2019 at 3:31 PM Mauro Rossi wrote:
> >
> > Hi Lepton,
> >
> > On Thu, Aug 15, 2019 at 9:58 PM Lepton Wu wrote:
> >>
> >> That's interesting. The android frame work will hard
On Tue, Aug 27, 2019 at 7:35 PM Lepton Wu wrote:
>
> On Tue, Aug 27, 2019 at 7:14 PM Lepton Wu wrote:
> >
> > On Thu, Aug 15, 2019 at 3:31 PM Mauro Rossi wrote:
> > >
> > > Hi Lepton,
> > >
> > > On Thu, Aug 15, 2019 at 9:58 PM Lepton Wu
the [expected] failure.
Signed-off-by: Emil Velikov
Acked-by: Tomasz Figa
(tfiga: Remove only respective EGL config, leave EGL image as is.)
Signed-off-by: Tomasz Figa
Signed-off-by: Lepton Wu
---
src/egl/drivers/dri2/platform_android.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src
The set of meta data was removed by commit 8083464. It broke lots of
dEQP tests when running with pbuffer surface type.
Fixes: 80834640137 ("virgl: remove dead code")
Signed-off-by: Lepton Wu
---
src/gallium/drivers/virgl/virgl_resource.c | 1 +
1 file changed, 1 insertion(+)
diff -
On Wed, Jul 17, 2019 at 11:26 AM Chia-I Wu wrote:
>
> On Wed, Jul 17, 2019 at 10:14 AM Erik Faye-Lund
> wrote:
> >
> > On Wed, 2019-07-17 at 10:02 -0700, Lepton Wu wrote:
> > > The set of meta data was removed by commit 8083464. It broke lots of
> > > dEQP
M Chia-I Wu wrote:
>
> On Wed, Jul 17, 2019 at 11:44 AM Lepton Wu wrote:
> >
> > On Wed, Jul 17, 2019 at 11:26 AM Chia-I Wu wrote:
> > >
> > > On Wed, Jul 17, 2019 at 10:14 AM Erik Faye-Lund
> > > wrote:
> > > >
> > > > On Wed, 2019-07-1
OK, actually struct winsys_handle is an obscure structure for virgl
driver so we can't access whandle->stride here...
So maybe just leave this CL as it is?
On Wed, Jul 17, 2019 at 1:12 PM Chia-I Wu wrote:
>
> On Wed, Jul 17, 2019 at 12:45 PM Lepton Wu wrote:
> > met
In src/mesa/state_tracker/st_atom_list.h,
Now it's this order:
ST_STATE(ST_NEW_FS_STATE, st_update_fp)
ST_STATE(ST_NEW_GS_STATE, st_update_gp)
ST_STATE(ST_NEW_TES_STATE, st_update_tep)
ST_STATE(ST_NEW_TCS_STATE, st_update_tcp)
ST_STATE(ST_NEW_VS_STATE, st_update_vp)
While code in
Marek Olšák wrote:
>
>
>
> On Fri., Jul. 26, 2019, 15:58 Lepton Wu, wrote:
>>
>> If shader A depends on shader B, should we put st_update_shaderB in
>> front of st_update_shaderA?
>
>
> That's the current order. The order of GPU execution doesn't matter.
r depends on the update of the following shader.
>
> Marek
>
> On Wed, Jul 24, 2019 at 7:19 PM Lepton Wu wrote:
>>
>> In src/mesa/state_tracker/st_atom_list.h,
>>
>> Now it's this order:
>>
>> ST_STATE(ST_NEW_FS_STATE, st_update_fp)
>> ST_STATE(ST_NEW_GS_S
n Fri., Jul. 26, 2019, 16:11 Lepton Wu, wrote:
>>
>> I am confused, for example, according to:
>>
>> https://www.khronos.org/opengl/wiki/Geometry_Shader, it come after
>> Vertex shader, that mean, it depends on vertex shader, right?
>> So st_update_gp should be a
OK, I didn't know there is a patch in mail list. BTW, it seems there is no
meaningful difference
with the generated code: when it's trying to align to 32 bytes border,
since the actual code size
is between 32 and 64, actually the entry size is 64. So in this case,
balign to 32 or 64 has same
56 matches
Mail list logo
