Re: [Mesa-dev] [PATCH] virgl: Use right key to insert resource to hash.
On Thu, 4 Apr 2019 at 06:54, Chia-I Wu wrote:
>
> You could end up having two virgl_hw_res with two different GEM handles
> pointing to the same kernel GEM object. That might break some assumptions
> about dependency tracking.
>
> For example, when the cmdbuf being built uses a buffer and you want to
> transfer some more data into the buffer, you normally need to submit the
> cmdbuf first before starting the transfer. The current code detects that
> with virgl_drm_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 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_res_destroy. This triggers use after free. Also, we
should only reuse resource from bo_handle hash when the handle type is
FD.
>>>
>>> Reuse is not very accurate. Opening a shared handle (flink name) twice
>>> gives two GEM handles. Importing an fd handle (prime fd) twice gives the
>>> same GEM handle. In all cases, within a virgl_winsys, we want only one GEM
>>> handle and only one virgl_resource for each kernel GEM object.
>>>
>>> I think the logic should go like:
>>>
>>> if (HANDLE_TYPE_SHARED) {
>>> if (bo_names.has(flink_name))
>>> return bo_names[flink_name];
>>> gem_handle = gem_open(flink_name);
>>> } else {
>>> gem_handle = drmPrimeFDToHandle(prime_fd);
>>> }
>>>
>>>
>>> if (bo_handles.has(gem_handle))
>>> return bo_handles[gem_handle];
>>> bo_handles[gem_handle] = create_new_resource();
>>>
>> Hi, the current patch did most of what you said with only one difference:
>> it didn't insert to bo_handles[] hash when the type is HANDLE_TYPE_SHARED.
>> I think this is reasonable since opening a shared handle always get a new
>> gem handle very time and I think it doesn't worth to insert it to
>> bo_handles[] hash.
>> What do you think?
Just to reinforce this, we can only have one GEM handle for a kernel
object, validation will go wrong and deadlock if we submit two handles
pointing at the same bo.
Opening a shared handle should not get a new gem handle, if should
return any gem handle that already exists.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] iris: Do not fast clear depth on gen > 9 yet.
Depth fast clears were unrestricted, meaning they were enabled on every
hardware generation. However, gen11+ requires some extra code to make it
work properly.
---
src/gallium/drivers/iris/iris_clear.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/drivers/iris/iris_clear.c
b/src/gallium/drivers/iris/iris_clear.c
index 6e0a569e7b0..2fd82c1881e 100644
--- a/src/gallium/drivers/iris/iris_clear.c
+++ b/src/gallium/drivers/iris/iris_clear.c
@@ -353,6 +353,12 @@ can_fast_clear_depth(struct iris_context *ice,
{
struct pipe_resource *p_res = (void *) res;
+ struct iris_batch *batch = >batches[IRIS_BATCH_RENDER];
+ const struct gen_device_info *devinfo = >screen->devinfo;
+
+ if (devinfo->gen > 9)
+ return false;
+
/* Check for partial clears */
if (box->x > 0 || box->y > 0 ||
box->width < u_minify(p_res->width0, level) ||
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] amd/addrlib: fix uninitialized values for Addr2ComputeDccAddrFromCoord
Reviewed-by: Bas Nieuwenhuizen
On Wed, Apr 3, 2019 at 11:17 PM Marek Olšák wrote:
>
> From: Marek Olšák
>
> ---
> src/amd/addrlib/src/gfx9/gfx9addrlib.cpp | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp
> b/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp
> index b3cbccf..9be775f 100644
> --- a/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp
> +++ b/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp
> @@ -129,20 +129,22 @@ const Dim3d Gfx9Lib::Block256_3dZ[] = {{8, 4, 8},
> {4, 4, 8}, {4, 4, 4}, {4, 2
>
>
> */
> Gfx9Lib::Gfx9Lib(const Client* pClient)
> :
> Lib(pClient),
> m_numEquations(0)
> {
> m_class = AI_ADDRLIB;
> memset(_settings, 0, sizeof(m_settings));
> memcpy(m_swizzleModeTable, SwizzleModeTable, sizeof(SwizzleModeTable));
> +m_metaEqOverrideIndex = 0;
> +memset(m_cachedMetaEqKey, 0, sizeof(m_cachedMetaEqKey));
> }
>
> /**
>
>
> * Gfx9Lib::~Gfx9Lib
> *
> * @brief
> * Destructor
>
>
> */
> --
> 2.7.4
>
> ___
> 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] nir: do not pack varying with different types
Seems ok for now.
Reviewed-by: Timothy Arceri
On 3/4/19 10:37 pm, Samuel Pitoiset wrote:
The current algorithm only supports packing 32-bit types.
If a shader uses both 16-bit and 32-bit varyings, we shouldn't
compact them together.
Cc: Timothy Arceri
Signed-off-by: Samuel Pitoiset
---
src/compiler/nir/nir_linking_helpers.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/compiler/nir/nir_linking_helpers.c
b/src/compiler/nir/nir_linking_helpers.c
index 146d4e4e591..482ac2881bc 100644
--- a/src/compiler/nir/nir_linking_helpers.c
+++ b/src/compiler/nir/nir_linking_helpers.c
@@ -243,6 +243,7 @@ struct assigned_comps
uint8_t comps;
uint8_t interp_type;
uint8_t interp_loc;
+ uint8_t is_32bit;
};
/* Packing arrays and dual slot varyings is difficult so to avoid complex
@@ -308,6 +309,7 @@ get_unmoveable_components_masks(struct exec_list *var_list,
comps[location + i].interp_type =
get_interp_type(var, type, default_to_smooth_interp);
comps[location + i].interp_loc = get_interp_loc(var);
+comps[location + i].is_32bit =
glsl_type_is_32bit(glsl_without_array(type));
}
}
}
@@ -572,6 +574,14 @@ assign_remap_locations(struct varying_loc (*remap)[4],
continue;
}
+ /* We can only pack varyings with matching types, and the current
+ * algorithm only supports packing 32-bit.
+ */
+ if (!assigned_comps[tmp_cursor].is_32bit) {
+tmp_comp = 0;
+continue;
+ }
+
while (tmp_comp < 4 &&
(assigned_comps[tmp_cursor].comps & (1 << tmp_comp))) {
tmp_comp++;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] amd/addrlib: fix uninitialized values for Addr2ComputeDccAddrFromCoord
From: Marek Olšák
---
src/amd/addrlib/src/gfx9/gfx9addrlib.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp
b/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp
index b3cbccf..9be775f 100644
--- a/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp
+++ b/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp
@@ -129,20 +129,22 @@ const Dim3d Gfx9Lib::Block256_3dZ[] = {{8, 4, 8}, {4,
4, 8}, {4, 4, 4}, {4, 2
*/
Gfx9Lib::Gfx9Lib(const Client* pClient)
:
Lib(pClient),
m_numEquations(0)
{
m_class = AI_ADDRLIB;
memset(_settings, 0, sizeof(m_settings));
memcpy(m_swizzleModeTable, SwizzleModeTable, sizeof(SwizzleModeTable));
+m_metaEqOverrideIndex = 0;
+memset(m_cachedMetaEqKey, 0, sizeof(m_cachedMetaEqKey));
}
/**
* Gfx9Lib::~Gfx9Lib
*
* @brief
* Destructor
*/
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] virgl: Use right key to insert resource to hash.
You could end up having two virgl_hw_res with two different GEM handles
pointing to the same kernel GEM object. That might break some assumptions
about dependency tracking.
For example, when the cmdbuf being built uses a buffer and you want to
transfer some more data into the buffer, you normally need to submit the
cmdbuf first before starting the transfer. The current code detects that
with virgl_drm_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 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_res_destroy. This triggers use after free. Also, we
>>> should only reuse resource from bo_handle hash when the handle type is
>>> FD.
>>>
>> Reuse is not very accurate. Opening a shared handle (flink name) twice
>> gives two GEM handles. Importing an fd handle (prime fd) twice gives the
>> same GEM handle. In all cases, within a virgl_winsys, we want only one GEM
>> handle and only one virgl_resource for each kernel GEM object.
>>
>> I think the logic should go like:
>>
>> if (HANDLE_TYPE_SHARED) {
>> if (bo_names.has(flink_name))
>> return bo_names[flink_name];
>> gem_handle = gem_open(flink_name);
>> } else {
>> gem_handle = drmPrimeFDToHandle(prime_fd);
>> }
>>
>>
> if (bo_handles.has(gem_handle))
>> return bo_handles[gem_handle];
>> bo_handles[gem_handle] = create_new_resource();
>>
>> Hi, the current patch did most of what you said with only one
> difference: it didn't insert to bo_handles[] hash when the type
> is HANDLE_TYPE_SHARED.
> I think this is reasonable since opening a shared handle always get a new
> gem handle very time and I think it doesn't worth to insert it to
> bo_handles[] hash.
> What do you think?
>
>>
>>> Signed-off-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/gallium/winsys/virgl/drm/virgl_drm_winsys.c
>>> +++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
>>> @@ -424,13 +424,13 @@ virgl_drm_winsys_resource_create_handle(struct
>>> virgl_winsys *qws,
>>> res = NULL;
>>> goto done;
>>>}
>>> - }
>>>
>>> - res = util_hash_table_get(qdws->bo_handles,
>>> (void*)(uintptr_t)handle);
>>> - if (res) {
>>> - struct virgl_hw_res *r = NULL;
>>> - virgl_drm_resource_reference(qdws, , res);
>>> - goto done;
>>> + res = util_hash_table_get(qdws->bo_handles,
>>> (void*)(uintptr_t)handle);
>>> + if (res) {
>>> +struct virgl_hw_res *r = NULL;
>>> +virgl_drm_resource_reference(qdws, , res);
>>> +goto done;
>>> + }
>>> }
>>>
>>> res = CALLOC_STRUCT(virgl_hw_res);
>>> @@ -469,7 +469,8 @@ virgl_drm_winsys_resource_create_handle(struct
>>> virgl_winsys *qws,
>>> res->num_cs_references = 0;
>>> res->fence_fd = -1;
>>>
>>> - util_hash_table_set(qdws->bo_handles, (void *)(uintptr_t)handle,
>>> res);
>>> + util_hash_table_set(qdws->bo_handles, (void
>>> *)(uintptr_t)res->bo_handle,
>>> + res);
>>>
>>> done:
>>> mtx_unlock(>bo_handles_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] Last week of voting for X.Org 2019 Election and By-laws approval
To all X.Org Foundation Members: We're currently halfway through our annual election at 71.4% turnout. If you haven't done so please login to https://members.x.org/, click on the Active ballot "X.Org 2019 Elections v2 and xorg+fdo merger" and leave your vote. In order to pass the proposed bylaw changes we'll need at least a 2/3 majority so we highly encourage each and everyone of you to vote. It only takes a couple of minutes. The election will close at 02:00 UTC on 11 April 2019. Harry, on behalf of the X.Org elections committee ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] nir: Add "viewport vector" system values
Alyssa Rosenzweig writes: > While a partial set of viewport system values exist, these are scalar > values, which is a poor fit for viewport transformations on vector ISAs > like Midgard (where the vec3 values for scale and offset each need to be > coherent in a vec4 uniform slot to take advantage of vectorized > transform math). This patch adds vec3 scale/offset fields corresponding > to the 3D Gallium viewport / glViewport+depth > > Signed-off-by: Alyssa Rosenzweig > Cc: Eric Anholt Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Remove support for legacy kernels
I also have no problems with this from the Bifrost facing side.
On Tue, Apr 2, 2019 at 7:25 PM Tomeu Vizoso
wrote:
> On 4/1/19 2:16 AM, Alyssa Rosenzweig wrote:
> > Previously, there was minimal support for interoperating with legacy
> > kernels (reusing kernel modules originally designed for proprietary
> > legacy userspaces, rather than for upstream-friendly free software
> > stacks). Now that the Panfrost kernel is stabilising, this commit drops
> > the legacy code path.
> >
> > Panfrost users need to use a modern, mainline kernel supporting the
> > Panfrost kernel driver from this commit forward.
>
> Sounds good to me. This will make it easier to refactor code around and I
> don't think I will need any more register dumps from kbase any more (and
> if so, I can always go back in time).
>
> Reviewed-by: Tomeu Vizoso
>
> Thanks!
>
> Tomeu
>
> > Signed-off-by: Alyssa Rosenzweig
> > Cc: Tomeu Vizoso
> > Cc: Rob Herring
> > ---
> > src/gallium/drivers/panfrost/.gitignore| 1 -
> > src/gallium/drivers/panfrost/meson.build | 10 --
> > src/gallium/drivers/panfrost/pan_drm.c | 1 -
> > src/gallium/drivers/panfrost/pan_public.h | 2 +-
> > src/gallium/drivers/panfrost/pan_screen.c | 14 ++
> > src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c| 11 +--
> > .../winsys/panfrost/drm/panfrost_drm_public.h | 2 +-
> > .../winsys/panfrost/drm/panfrost_drm_winsys.c | 6 +++---
> > 8 files changed, 8 insertions(+), 39 deletions(-)
> >
> > diff --git a/src/gallium/drivers/panfrost/.gitignore
> b/src/gallium/drivers/panfrost/.gitignore
> > index 9d2c2c18bef..e69de29bb2d 100644
> > --- a/src/gallium/drivers/panfrost/.gitignore
> > +++ b/src/gallium/drivers/panfrost/.gitignore
> > @@ -1 +0,0 @@
> > -nondrm
> > diff --git a/src/gallium/drivers/panfrost/meson.build
> b/src/gallium/drivers/panfrost/meson.build
> > index e3569e73468..371a11a934b 100644
> > --- a/src/gallium/drivers/panfrost/meson.build
> > +++ b/src/gallium/drivers/panfrost/meson.build
> > @@ -62,16 +62,6 @@ compile_args_panfrost = [
> > '-Wno-pointer-arith'
> > ]
> >
> > -overlay = join_paths(meson.source_root(), meson.current_source_dir(),
> 'nondrm/pan_nondrm.c')
> > -nondrm_overlay_check = run_command('ls', overlay)
> > -has_nondrm_overlay = nondrm_overlay_check.returncode() == 0
> > -
> > -if has_nondrm_overlay
> > - files_panfrost += files('nondrm/pan_nondrm.c')
> > - inc_panfrost += include_directories('nondrm/include')
> > - compile_args_panfrost += '-DPAN_NONDRM_OVERLAY'
> > -endif
> > -
> > midgard_nir_algebraic_c = custom_target(
> > 'midgard_nir_algebraic.c',
> > input : 'midgard/midgard_nir_algebraic.py',
> > diff --git a/src/gallium/drivers/panfrost/pan_drm.c
> b/src/gallium/drivers/panfrost/pan_drm.c
> > index c30beaf2b50..4b8c197be0e 100644
> > --- a/src/gallium/drivers/panfrost/pan_drm.c
> > +++ b/src/gallium/drivers/panfrost/pan_drm.c
> > @@ -298,7 +298,6 @@ panfrost_drm_force_flush_fragment(struct
> panfrost_context *ctx,
> > struct pipe_context *gallium = (struct pipe_context *) ctx;
> > struct panfrost_screen *screen = pan_screen(gallium->screen);
> > struct panfrost_drm *drm = (struct panfrost_drm
> *)screen->driver;
> > -int ret;
> >
> > if (!screen->last_fragment_flushed) {
> > drmSyncobjWait(drm->fd, >out_sync, 1, INT64_MAX, 0,
> NULL);
> > diff --git a/src/gallium/drivers/panfrost/pan_public.h
> b/src/gallium/drivers/panfrost/pan_public.h
> > index f57fd6157f4..c7e72f94246 100644
> > --- a/src/gallium/drivers/panfrost/pan_public.h
> > +++ b/src/gallium/drivers/panfrost/pan_public.h
> > @@ -32,7 +32,7 @@ struct pipe_screen;
> > struct renderonly;
> >
> > struct pipe_screen *
> > -panfrost_create_screen(int fd, struct renderonly *ro, bool is_drm);
> > +panfrost_create_screen(int fd, struct renderonly *ro);
> >
> > #ifdef __cplusplus
> > }
> > diff --git a/src/gallium/drivers/panfrost/pan_screen.c
> b/src/gallium/drivers/panfrost/pan_screen.c
> > index 682eb37f5c7..71c6175d069 100644
> > --- a/src/gallium/drivers/panfrost/pan_screen.c
> > +++ b/src/gallium/drivers/panfrost/pan_screen.c
> > @@ -63,7 +63,6 @@ DEBUG_GET_ONCE_FLAGS_OPTION(pan_debug,
> "PAN_MESA_DEBUG", debug_options, 0)
> > int pan_debug = 0;
> >
> > struct panfrost_driver *panfrost_create_drm_driver(int fd);
> > -struct panfrost_driver *panfrost_create_nondrm_driver(int fd);
> >
> > const char *pan_counters_base = NULL;
> >
> > @@ -549,7 +548,7 @@ panfrost_screen_get_compiler_options(struct
> pipe_screen *pscreen,
> > }
> >
> > struct pipe_screen *
> > -panfrost_create_screen(int fd, struct renderonly *ro, bool is_drm)
> > +panfrost_create_screen(int fd, struct renderonly *ro)
> > {
> > struct panfrost_screen *screen =
> CALLOC_STRUCT(panfrost_screen);
> >
> > @@ -567,16 +566,7 @@ panfrost_create_screen(int fd, struct renderonly
> *ro, bool is_drm)
> >
Re: [Mesa-dev] new dispatch generator broke with Marek's parallel compile commit
On Tue, 2 Apr 2019 at 20:00, Ian Romanick wrote: > > On 4/2/19 4:43 AM, Emil Velikov wrote: > > On Tue, 2 Apr 2019 at 04:55, Dave Airlie wrote: > >> > >> On Tue, 2 Apr 2019 at 11:24, Dave Airlie wrote: > >>> > >>> Marek's commit to add ARB_parallel_shader_compile broke some es1 tests > >>> in the Intel CI. > >>> > >>> It appears the whatever generates the es1api isn't consistent, for > >>> example glTranslatex on my local system is 1405 in es1api but is 1406 > >>> in the gl api. > >>> > >>> I'm no expert on this area, Emil any ideas? > >> > >> This seems to be due the new registry xml parser, I'm not sure how > >> broken it is, but it seems like it's a bit busted, and nobody tested > >> the scenario where a new function gets introduced in the middle. > >> > >> It looks like static_data.py has a limit on the offsets it cares > >> about, I thought adding static offsets for these functions would help > >> here, but it appears currently it all just work by luck, that the > >> static offsets work out to be the same as ones generated by gl_XML.py > >> for values above MAX_OFFSETS. > >> > >> I've got a hacky patch that makes it work here, that increases > >> MAX_OFFSETS to 1420, adds a new entry to the end for the new APIs, but > >> really I think the current code is broken, and is happening to work > >> out, but I'm hoping I'm just missing something obvious and it'll be a > >> one line fix for Emil. > >> > > As you have noticed the old generator would add entries to the glapi > > table in arbitrary order. > > Meaning that the ABI between dri/glapi/libGL* would break every now and > > then. > > > > In more detail - libGL* would expect glFooBar at offset X, while the > > function is at Y according to glapi and the dri module sets the > > dispatch at Y. Latter uses a combination of fixed offset and dynamic > > offset lookup. > > This doesn't make sense to me. Can you explain more? There are only > two parts. There's the loader, and there's the driver. The loader > assigns locations either at compile-time or at run-time. The driver > queries the locations of functions that it will provide. All functions > that the loader knows about should realistically have a dispatch > location set at compile time. The loader should only generate new > locations at run-time if the application or driver asks for a function > that it does not know. > > For things that don't have a static dispatch location set in the XML, > the loader is free to assign any location is pleases, but that location > must be consistent across all APIs because a single application can > create contexts from every possible API in the same address space, but > glXGetProcAddress or eglGetProcAddress are API agnostic. > > If there is any possibility for a single function to have different > dispatch locations in different APIs, then the single most fundamental > invariant of the entire dispatch table system is being violated. That > is a pretty catastrophic failure. > Note: I'm not 100% sure if the following is an issue or design decision. I'm inclined towards the former, although I could be wrong. Loader references known functions entries by glapi_table offset, they're resolved at build-time. At some point a developer: - changes the include order in our XMLs - adds a new XML/entrypoints (say glFooBar) at in "special" order - flips the aliasing order of glFoo and glFooARB Since our old parser validates the entrypoints in the order they're presented** - glFooBar gets an offset of X and shifts (some of) the existing entrypoints by 1. Say glHamSandwich - moves from X to X+1 The driver populates the entrypoints by offset, hence they're resolved at build-time. New driver sets the glHamSandwich entrypoint at X+1 while old loader expect it at X. Unless I've missed something, the above will result in sub-par experience. HTH Emil ** The aliasing rules apply on top. Aside: while porting libGL and libglapi (WIP) I've noticed two type of some aliasing changes wrt upstream. I'm planning to add a quirk table and we can go through each one at time permits. Example: - us AreTexturesResident and AreTexturesResidentEXT are aliased, upstream - they're not - us MultiDrawElementsIndirectAMD alias MultiDrawElementsIndirect, upstream MultiDrawElementsIndirect alias MultiDrawElementsIndirectAMD ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/u_dump: util_dump_sampler_view: Dump u.tex.first_level
Reviewed-by: Marek Olšák
Marek
On Wed, Apr 3, 2019 at 12:13 PM Guido Günther wrote:
> Dump u.tex.first_level instead of dumping u.tex.last_level twice.
>
> Signed-off-by: Guido Günther
> ---
> src/gallium/auxiliary/util/u_dump_state.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/util/u_dump_state.c
> b/src/gallium/auxiliary/util/u_dump_state.c
> index 638dac79db2..6b11f10408a 100644
> --- a/src/gallium/auxiliary/util/u_dump_state.c
> +++ b/src/gallium/auxiliary/util/u_dump_state.c
> @@ -789,7 +789,7 @@ util_dump_sampler_view(FILE *stream, const struct
> pipe_sampler_view *state)
> else {
>util_dump_member(stream, uint, state, u.tex.first_layer);
>util_dump_member(stream, uint, state, u.tex.last_layer);
> - util_dump_member(stream, uint, state, u.tex.last_level);
> + util_dump_member(stream, uint, state, u.tex.first_level);
>util_dump_member(stream, uint, state, u.tex.last_level);
> }
>
> --
> 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
[Mesa-dev] [PATCH] gallium/u_dump: util_dump_sampler_view: Dump u.tex.first_level
Dump u.tex.first_level instead of dumping u.tex.last_level twice.
Signed-off-by: Guido Günther
---
src/gallium/auxiliary/util/u_dump_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_dump_state.c
b/src/gallium/auxiliary/util/u_dump_state.c
index 638dac79db2..6b11f10408a 100644
--- a/src/gallium/auxiliary/util/u_dump_state.c
+++ b/src/gallium/auxiliary/util/u_dump_state.c
@@ -789,7 +789,7 @@ util_dump_sampler_view(FILE *stream, const struct
pipe_sampler_view *state)
else {
util_dump_member(stream, uint, state, u.tex.first_layer);
util_dump_member(stream, uint, state, u.tex.last_layer);
- util_dump_member(stream, uint, state, u.tex.last_level);
+ util_dump_member(stream, uint, state, u.tex.first_level);
util_dump_member(stream, uint, state, u.tex.last_level);
}
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/3] gallium/auxiliary/vl: Add barrier/unbind after compute shader launch.
For the series:
Reviewed-by: Marek Olšák
Marek
On Wed, Apr 3, 2019 at 11:01 AM Zhu, James wrote:
> Add memory barrier sync for multiple launch cases, and unbind completed
> resources after launch.
>
> Signed-off-by: James Zhu
> ---
> src/gallium/auxiliary/vl/vl_compositor_cs.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/src/gallium/auxiliary/vl/vl_compositor_cs.c
> b/src/gallium/auxiliary/vl/vl_compositor_cs.c
> index c3afe61..a659fd2 100644
> --- a/src/gallium/auxiliary/vl/vl_compositor_cs.c
> +++ b/src/gallium/auxiliary/vl/vl_compositor_cs.c
> @@ -292,6 +292,10 @@ cs_launch(struct vl_compositor *c,
> info.grid[2] = 1;
>
> ctx->launch_grid(ctx, );
> +
> + /* Make the result visible to all clients. */
> + ctx->memory_barrier(ctx, PIPE_BARRIER_ALL);
> +
> }
>
> static inline struct u_rect
> @@ -389,6 +393,13 @@ draw_layers(struct vl_compositor *c,
>
> cs_launch(c, layer->cs, &(drawn.area));
>
> + /* Unbind. */
> + ctx->set_shader_images(ctx, PIPE_SHADER_COMPUTE, 0, 1, NULL);
> + ctx->set_constant_buffer(ctx, PIPE_SHADER_COMPUTE, 0, NULL);
> + ctx->set_sampler_views(c->pipe, PIPE_SHADER_FRAGMENT, 0,
> num_sampler_views, NULL);
> + ctx->bind_compute_state(ctx, NULL);
> + ctx->bind_sampler_states(c->pipe, PIPE_SHADER_COMPUTE, 0,
> num_sampler_views, NULL);
> +
> if (dirty) {
> struct u_rect drawn = calc_drawn_area(s, layer);
> dirty->x0 = MIN2(drawn.x0, dirty->x0);
> --
> 2.7.4
>
> ___
> 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 v2 3/3] gallium/auxiliary/vl: Add barrier/unbind after compute shader launch.
Add memory barrier sync for multiple launch cases, and unbind completed
resources after launch.
Signed-off-by: James Zhu
---
src/gallium/auxiliary/vl/vl_compositor_cs.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/gallium/auxiliary/vl/vl_compositor_cs.c
b/src/gallium/auxiliary/vl/vl_compositor_cs.c
index c3afe61..a659fd2 100644
--- a/src/gallium/auxiliary/vl/vl_compositor_cs.c
+++ b/src/gallium/auxiliary/vl/vl_compositor_cs.c
@@ -292,6 +292,10 @@ cs_launch(struct vl_compositor *c,
info.grid[2] = 1;
ctx->launch_grid(ctx, );
+
+ /* Make the result visible to all clients. */
+ ctx->memory_barrier(ctx, PIPE_BARRIER_ALL);
+
}
static inline struct u_rect
@@ -389,6 +393,13 @@ draw_layers(struct vl_compositor *c,
cs_launch(c, layer->cs, &(drawn.area));
+ /* Unbind. */
+ ctx->set_shader_images(ctx, PIPE_SHADER_COMPUTE, 0, 1, NULL);
+ ctx->set_constant_buffer(ctx, PIPE_SHADER_COMPUTE, 0, NULL);
+ ctx->set_sampler_views(c->pipe, PIPE_SHADER_FRAGMENT, 0,
num_sampler_views, NULL);
+ ctx->bind_compute_state(ctx, NULL);
+ ctx->bind_sampler_states(c->pipe, PIPE_SHADER_COMPUTE, 0,
num_sampler_views, NULL);
+
if (dirty) {
struct u_rect drawn = calc_drawn_area(s, layer);
dirty->x0 = MIN2(drawn.x0, dirty->x0);
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 8/8] egl: add EGL_platform_device support
On Wed, Apr 3, 2019 at 10:13 AM Mathias Fröhlich wrote: > > What is missing for merging this? > > I saw the pbuffer swrast crash and proposed to disable them via the > 3rd patch that I pushed into my branch for you. > Emil never responded to that proposal directly. In one mail he mentioned > that he wanted to care for swrast to cope with the pbuffers. So I hoped > that > he continues the work he mentioned... > > For me it would be ok to squash patch #2 and #3 into one and for now > disable pbuffers on swrast from device. > > What I don't want to have is mesa crashing on the egl pbuffer on a swrast > device as crashing is not an option. > Sounds reasonable. So you basically said that the branch is ready to be merged, right? I'm being pressured to get EGL_EXT_platform_device into master ASAP. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v6 32/35] intel/compiler: validate region restrictions for mixed float mode
From: Iago Toral Quiroga
v2:
- Adapted unit tests to make them consistent with the changes done
to the validation of half-float conversions.
v3 (Curro):
- Check all the accummulators
- Constify declarations
- Do not check src1 type in single-source instructions.
- Check for all instructions that read accumulator (either implicitly or
explicitly)
- Check restrictions in src1 too.
- Merge conditional block
- Add invalid test case.
---
src/intel/compiler/brw_eu_validate.c| 290 +++
src/intel/compiler/test_eu_validate.cpp | 631
2 files changed, 921 insertions(+)
diff --git a/src/intel/compiler/brw_eu_validate.c
b/src/intel/compiler/brw_eu_validate.c
index cfaf126e2f5..4a735641c86 100644
--- a/src/intel/compiler/brw_eu_validate.c
+++ b/src/intel/compiler/brw_eu_validate.c
@@ -170,6 +170,20 @@ src1_is_null(const struct gen_device_info *devinfo, const
brw_inst *inst)
brw_inst_src1_da_reg_nr(devinfo, inst) == BRW_ARF_NULL;
}
+static bool
+src0_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
+{
+ return brw_inst_src0_reg_file(devinfo, inst) ==
BRW_ARCHITECTURE_REGISTER_FILE &&
+ (brw_inst_src0_da_reg_nr(devinfo, inst) & 0xF0) ==
BRW_ARF_ACCUMULATOR;
+}
+
+static bool
+src1_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
+{
+ return brw_inst_src1_reg_file(devinfo, inst) ==
BRW_ARCHITECTURE_REGISTER_FILE &&
+ (brw_inst_src1_da_reg_nr(devinfo, inst) & 0xF0) ==
BRW_ARF_ACCUMULATOR;
+}
+
static bool
src0_is_grf(const struct gen_device_info *devinfo, const brw_inst *inst)
{
@@ -275,6 +289,27 @@ sources_not_null(const struct gen_device_info *devinfo,
return error_msg;
}
+static bool
+inst_uses_src_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
+{
+ /* Check instructions that use implicit accumulator sources */
+ switch (brw_inst_opcode(devinfo, inst)) {
+ case BRW_OPCODE_MAC:
+ case BRW_OPCODE_MACH:
+ case BRW_OPCODE_SADA2:
+ return true;
+ }
+
+ /* Instructions with three source operands cannot use explicit accumulator
+* operands.
+*/
+ const unsigned num_sources = num_sources_from_inst(devinfo, inst);
+ if (num_sources > 2)
+ return false;
+
+ return src0_is_acc(devinfo, inst) || (num_sources > 1 &&
src1_is_acc(devinfo, inst));
+}
+
static struct string
send_restrictions(const struct gen_device_info *devinfo,
const brw_inst *inst)
@@ -938,6 +973,260 @@ general_restrictions_on_region_parameters(const struct
gen_device_info *devinfo,
return error_msg;
}
+static struct string
+special_restrictions_for_mixed_float_mode(const struct gen_device_info
*devinfo,
+ const brw_inst *inst)
+{
+ struct string error_msg = { .str = NULL, .len = 0 };
+
+ const unsigned opcode = brw_inst_opcode(devinfo, inst);
+ const unsigned num_sources = num_sources_from_inst(devinfo, inst);
+ if (num_sources >= 3)
+ return error_msg;
+
+ if (!is_mixed_float(devinfo, inst))
+ return error_msg;
+
+ unsigned exec_size = 1 << brw_inst_exec_size(devinfo, inst);
+ bool is_align16 = brw_inst_access_mode(devinfo, inst) == BRW_ALIGN_16;
+
+ enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
+ enum brw_reg_type src1_type = num_sources > 1 ?
+ brw_inst_src1_type(devinfo, inst) : 0;
+ enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
+
+ unsigned dst_stride = STRIDE(brw_inst_dst_hstride(devinfo, inst));
+ bool dst_is_packed = is_packed(exec_size * dst_stride, exec_size,
dst_stride);
+
+ /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+* Float Operations:
+*
+*"Indirect addressing on source is not supported when source and
+* destination data types are mixed float."
+*/
+ ERROR_IF((types_are_mixed_float(dst_type, src0_type) &&
+ brw_inst_src0_address_mode(devinfo, inst) != BRW_ADDRESS_DIRECT)
||
+(num_sources > 1 &&
+ types_are_mixed_float(dst_type, src1_type) &&
+ brw_inst_src1_address_mode(devinfo, inst) != BRW_ADDRESS_DIRECT),
+"Indirect addressing on source is not supported when source and "
+"destination data types are mixed float");
+
+ /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+* Float Operations:
+*
+*"No SIMD16 in mixed mode when destination is f32. Instruction
+* execution size must be no more than 8."
+*/
+ ERROR_IF(exec_size > 8 && dst_type == BRW_REGISTER_TYPE_F,
+"Mixed float mode with 32-bit float destination is limited "
+"to SIMD8");
+
+ if (is_align16) {
+ /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+ * Float Operations:
+ *
+ * "In Align16 mode, when half float and float data types are mixed
+ *between source operands OR between
[Mesa-dev] [PATCH v6 30/35] intel/compiler: validate region restrictions for half-float conversions
From: Iago Toral Quiroga
v2:
- Consider implicit conversions in 2-src instructions too (Curro)
- For restrictions that involve destination stride requirements
only validate them for Align1, since Align16 always requires
packed data.
- Skip general rule for the dst/execution type size ratio for
mixed float instructions on CHV and SKL+, these have their own
set of rules that we'll be validated separately.
v3 (Curro):
- Do not check src1 type in single-source instructions.
- Check restriction on src1.
- Remove invalid test.
---
src/intel/compiler/brw_eu_validate.c| 155 +++-
src/intel/compiler/test_eu_validate.cpp | 116 ++
2 files changed, 270 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_eu_validate.c
b/src/intel/compiler/brw_eu_validate.c
index bd0e48a5e5c..54bffb3af03 100644
--- a/src/intel/compiler/brw_eu_validate.c
+++ b/src/intel/compiler/brw_eu_validate.c
@@ -469,6 +469,66 @@ is_packed(unsigned vstride, unsigned width, unsigned
hstride)
return false;
}
+/**
+ * Returns whether an instruction is an explicit or implicit conversion
+ * to/from half-float.
+ */
+static bool
+is_half_float_conversion(const struct gen_device_info *devinfo,
+ const brw_inst *inst)
+{
+ enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
+
+ unsigned num_sources = num_sources_from_inst(devinfo, inst);
+ enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
+
+ if (dst_type != src0_type &&
+ (dst_type == BRW_REGISTER_TYPE_HF || src0_type ==
BRW_REGISTER_TYPE_HF)) {
+ return true;
+ } else if (num_sources > 1) {
+ enum brw_reg_type src1_type = brw_inst_src1_type(devinfo, inst);
+ return dst_type != src1_type &&
+(dst_type == BRW_REGISTER_TYPE_HF ||
+ src1_type == BRW_REGISTER_TYPE_HF);
+ }
+
+ return false;
+}
+
+/*
+ * Returns whether an instruction is using mixed float operation mode
+ */
+static bool
+is_mixed_float(const struct gen_device_info *devinfo, const brw_inst *inst)
+{
+ if (devinfo->gen < 8)
+ return false;
+
+ if (inst_is_send(devinfo, inst))
+ return false;
+
+ unsigned opcode = brw_inst_opcode(devinfo, inst);
+ const struct opcode_desc *desc = brw_opcode_desc(devinfo, opcode);
+ if (desc->ndst == 0)
+ return false;
+
+ /* FIXME: support 3-src instructions */
+ unsigned num_sources = num_sources_from_inst(devinfo, inst);
+ assert(num_sources < 3);
+
+ enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
+ enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
+
+ if (num_sources == 1)
+ return types_are_mixed_float(src0_type, dst_type);
+
+ enum brw_reg_type src1_type = brw_inst_src1_type(devinfo, inst);
+
+ return types_are_mixed_float(src0_type, src1_type) ||
+ types_are_mixed_float(src0_type, dst_type) ||
+ types_are_mixed_float(src1_type, dst_type);
+}
+
/**
* Checks restrictions listed in "General Restrictions Based on Operand Types"
* in the "Register Region Restrictions" section.
@@ -539,7 +599,100 @@ general_restrictions_based_on_operand_types(const struct
gen_device_info *devinf
exec_type_size == 8 && dst_type_size == 4)
dst_type_size = 8;
- if (exec_type_size > dst_type_size) {
+ if (is_half_float_conversion(devinfo, inst)) {
+ /**
+ * A helper to validate used in the validation of the following
restriction
+ * from the BDW+ PRM, Volume 2a, Command Reference, Instructions - MOV:
+ *
+ *"There is no direct conversion from HF to DF or DF to HF.
+ * There is no direct conversion from HF to Q/UQ or Q/UQ to HF."
+ *
+ * Even if these restrictions are listed for the MOV instruction, we
+ * validate this more generally, since there is the possibility
+ * of implicit conversions from other instructions, such us implicit
+ * conversion from integer to HF with the ADD instruction in SKL+.
+ */
+ enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
+ enum brw_reg_type src1_type = num_sources > 1 ?
+brw_inst_src1_type(devinfo, inst) : 0;
+ ERROR_IF(dst_type == BRW_REGISTER_TYPE_HF &&
+ (type_sz(src0_type) == 8 ||
+(num_sources > 1 && type_sz(src1_type) == 8)),
+ "There are no direct conversions between 64-bit types and HF");
+
+ ERROR_IF(type_sz(dst_type) == 8 &&
+ (src0_type == BRW_REGISTER_TYPE_HF ||
+(num_sources > 1 && src1_type == BRW_REGISTER_TYPE_HF)),
+ "There are no direct conversions between 64-bit types and HF");
+
+ /* From the BDW+ PRM:
+ *
+ * "Conversion between Integer and HF (Half Float) must be
+ *DWord-aligned and strided by a DWord on the destination."
+ *
+ * Also, the above restrictions seems to be expanded on CHV and
[Mesa-dev] [PATCH v7 28/35] intel/compiler: implement SIMD16 restrictions for mixed-float instructions
From: Iago Toral Quiroga
v2: f32to16/f16to32 can use a :W destination (Curro)
---
src/intel/compiler/brw_fs.cpp | 71 +++
1 file changed, 71 insertions(+)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index d4803c63b93..48b5cc6c403 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -5606,6 +5606,48 @@ fs_visitor::lower_logical_sends()
return progress;
}
+static bool
+is_mixed_float_with_fp32_dst(const fs_inst *inst)
+{
+ /* This opcode sometimes uses :W type on the source even if the operand is
+* a :HF, because in gen7 there is no support for :HF, and thus it uses :W.
+*/
+ if (inst->opcode == BRW_OPCODE_F16TO32)
+ return true;
+
+ if (inst->dst.type != BRW_REGISTER_TYPE_F)
+ return false;
+
+ for (int i = 0; i < inst->sources; i++) {
+ if (inst->src[i].type == BRW_REGISTER_TYPE_HF)
+ return true;
+ }
+
+ return false;
+}
+
+static bool
+is_mixed_float_with_packed_fp16_dst(const fs_inst *inst)
+{
+ /* This opcode sometimes uses :W type on the destination even if the
+* destination is a :HF, because in gen7 there is no support for :HF, and
+* thus it uses :W.
+*/
+ if (inst->opcode == BRW_OPCODE_F32TO16)
+ return true;
+
+ if (inst->dst.type != BRW_REGISTER_TYPE_HF ||
+ inst->dst.stride != 1)
+ return false;
+
+ for (int i = 0; i < inst->sources; i++) {
+ if (inst->src[i].type == BRW_REGISTER_TYPE_F)
+ return true;
+ }
+
+ return false;
+}
+
/**
* Get the closest allowed SIMD width for instruction \p inst accounting for
* some common regioning and execution control restrictions that apply to FPU
@@ -5768,6 +5810,35 @@ get_fpu_lowered_simd_width(const struct gen_device_info
*devinfo,
max_width = MIN2(max_width, 4);
}
+ /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+* Float Operations:
+*
+*"No SIMD16 in mixed mode when destination is f32. Instruction
+* execution size must be no more than 8."
+*
+* FIXME: the simulator doesn't seem to complain if we don't do this and
+* empirical testing with existing CTS tests show that they pass just fine
+* without implementing this, however, since our interpretation of the PRM
+* is that conversion MOVs between HF and F are still mixed-float
+* instructions (and therefore subject to this restriction) we decided to
+* split them to be safe. Might be useful to do additional investigation to
+* lift the restriction if we can ensure that it is safe though, since these
+* conversions are common when half-float types are involved since many
+* instructions do not support HF types and conversions from/to F are
+* required.
+*/
+ if (is_mixed_float_with_fp32_dst(inst))
+ max_width = MIN2(max_width, 8);
+
+ /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+* Float Operations:
+*
+*"No SIMD16 in mixed mode when destination is packed f16 for both
+* Align1 and Align16."
+*/
+ if (is_mixed_float_with_packed_fp16_dst(inst))
+ max_width = MIN2(max_width, 8);
+
/* Only power-of-two execution sizes are representable in the instruction
* control fields.
*/
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 8/8] egl: add EGL_platform_device support
> What is missing for merging this? I saw the pbuffer swrast crash and proposed to disable them via the 3rd patch that I pushed into my branch for you. Emil never responded to that proposal directly. In one mail he mentioned that he wanted to care for swrast to cope with the pbuffers. So I hoped that he continues the work he mentioned... For me it would be ok to squash patch #2 and #3 into one and for now disable pbuffers on swrast from device. What I don't want to have is mesa crashing on the egl pbuffer on a swrast device as crashing is not an option. best Mathias > > Thanks, > Marek > > On Wed, Apr 3, 2019 at 12:30 AM Mathias Fröhlich > wrote: > > > Marek, > > > > On Tuesday, 2 April 2019 23:07:50 CEST Marek Olšák wrote: > > > Do you have a branch with patch 7/8 and 8/8? I'm interested in > > > EGL_EXT_platform_device on radeonsi. > > > > You can take a look at the egl-device-4 branch on > > https://gitlab.freedesktop.org/frohlich/mesa.git > > I pushed a rebased and slightly changed wip for you. > > > > I have also some more tests in my local piglit as well as separate > > tests/examples that I initially wrote as an example to make use of the > > extension. > > But I have to dig out these first... > > > > best > > > > Mathias > > > > > > > > Thanks, > > > Marek > > > > > > On Wed, Oct 3, 2018 at 4:36 AM Mathias Fröhlich < > > mathias.froehl...@gmx.net> > > > wrote: > > > > > > > Hi Emil, > > > > > > > > Ok, thanks for picking that up. > > > > > > > > On Tuesday, 2 October 2018 12:23:30 CEST Emil Velikov wrote: > > > > > On Thu, 20 Sep 2018 at 15:13, Mathias Fröhlich > > > > > wrote: > > > > > > > > > > > > > > > > > If I replace the above with > > > > > > > > > > > > EGLint surface_type = 0; > > > > > > /* Only advertise pbuffer configs for non swrast devices > > */ > > > > > > if (dri2_dpy->image_driver) > > > > > > surface_type = EGL_PBUFFER_BIT; > > > > > > > > > > > > dri2_conf = dri2_add_config(dpy, > > dri2_dpy->driver_configs[i], > > > > > >config_count + 1, surface_type, NULL, > > > > > >visuals[j].rgba_masks); > > > > > > > > > > > > then I can easily prohibit the crash that I mentioned when trying > > to > > > > > > create a pbuffer surface on the swrast device. > > > > > > At least I do no longer get a valid pbuffer config from > > eglChooseConfig > > > > > > and without that we cannot reach the crashing > > > > > > dri2_dpy->image_driver->createNewDrawable > > > > > > call somewhere from eglCreatePbufferSurface anymore. > > > > > > > > > > > > Still getting a surface less context on swrast should work... > > > > > > > > > > > Issue is that we do not know how to create a "pbuffer only" swrast. > > > > > > > > > > Hence one resolves to hacks like the ones we have in > > > > platform_surfaceless. > > > > > Effectively pilling hacks upon hacks - see swrast_loader_extensions > > > > > and "software path w/o DRM.". > > > > > > > > > > That said, I'm working on proper solution but since it will take some > > > > > time to finish/merge I'll drop this and 7/8 for now. > > > > > > > > > > > > That's fine too. > > > > > > > > What I wanted to avoid is that people using the extension correctly > > fail > > > > with a > > > > crash in the application when running on mesa. > > > > Think about it. Thats really bad from an application writers point of > > view > > > > as you do all right with checking extensions and that and then the > > opengl > > > > stack suddenly crashes. > > > > > > > > best > > > > > > > > Mathias > > > > > > > > > > > > ___ > > > > 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 3/3] gallium/auxiliary/vl: Add barrier/unbind after compute shader launch.
On Tue, Apr 2, 2019 at 2:22 PM Zhu, James wrote: > > Add memory barrier sync and unbind resource after launch will enhance > the robustness. I can't tell from the comment -- is this working around driver bugs, or is the state tracker using the API incorrectly and this fixes the usage. If the latter, what was incorrect? I don't think "enhance robustness" without a description of how is a sufficient description. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa gallium: use compute shaders for vaapi blit
On Wed, Apr 3, 2019 at 9:57 AM Ilia Mirkin wrote: > On Wed, Apr 3, 2019 at 9:36 AM Marek Olšák wrote: > > > > On Wed, Apr 3, 2019 at 9:06 AM Ilia Mirkin wrote: > >> > >> On Wed, Apr 3, 2019 at 8:38 AM Marek Olšák wrote: > >> > > >> > On Tue, Apr 2, 2019 at 2:14 PM Eric Anholt wrote: > >> >> > >> >> Ilia Mirkin writes: > >> >> > >> >> > Shouldn't this sort of decision be left up to the driver? If the > >> >> > driver would like to use CS for blits, fine, but why not let it > blit > >> >> > in the most optimal way possible and force it to use a compute > shader? > >> >> > >> >> Yeah, commit messages require an explanation of why a change is being > >> >> made. > >> > > >> > > >> > We plan to create vaapi contexts with PIPE_CONTEXT_COMPUTE_ONLY for > better GPU multitasking. > >> > > >> > RadeonSI uses async compute queues if PIPE_CONTEXT_COMPUTE_ONLY is > set, so it can't do any graphics stuff, not even blit. (pipe_context::blit > is NULL) > >> > >> Makes sense. Sounds like one of those would be a better condition than > >> the mere existence of compute support then? > > > > > > Or we can add PIPE_CAP_PREFER_COMPUTE_BLIT as a performance hint. > > When would a driver set that, and when would a state tracker respect it? > > As I see it, if the driver prefers compute blits, it can just do that > in its ->blit impl. If the state tracker created a > PIPE_CONTEXT_COMPUTE_ONLY context, then it can also decide to not use > ->blit(). I don't see what the CAP adds, but perhaps I'm missing > something. > util_compute_blit was only validated for vaapi. Using it in the driver is risky. PIPE_CAP_PREFER_COMPUTE_BLIT would be the hint for vaapi. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa gallium: use compute shaders for vaapi blit
On Wed, Apr 3, 2019 at 9:36 AM Marek Olšák wrote: > > On Wed, Apr 3, 2019 at 9:06 AM Ilia Mirkin wrote: >> >> On Wed, Apr 3, 2019 at 8:38 AM Marek Olšák wrote: >> > >> > On Tue, Apr 2, 2019 at 2:14 PM Eric Anholt wrote: >> >> >> >> Ilia Mirkin writes: >> >> >> >> > Shouldn't this sort of decision be left up to the driver? If the >> >> > driver would like to use CS for blits, fine, but why not let it blit >> >> > in the most optimal way possible and force it to use a compute shader? >> >> >> >> Yeah, commit messages require an explanation of why a change is being >> >> made. >> > >> > >> > We plan to create vaapi contexts with PIPE_CONTEXT_COMPUTE_ONLY for better >> > GPU multitasking. >> > >> > RadeonSI uses async compute queues if PIPE_CONTEXT_COMPUTE_ONLY is set, so >> > it can't do any graphics stuff, not even blit. (pipe_context::blit is NULL) >> >> Makes sense. Sounds like one of those would be a better condition than >> the mere existence of compute support then? > > > Or we can add PIPE_CAP_PREFER_COMPUTE_BLIT as a performance hint. When would a driver set that, and when would a state tracker respect it? As I see it, if the driver prefers compute blits, it can just do that in its ->blit impl. If the state tracker created a PIPE_CONTEXT_COMPUTE_ONLY context, then it can also decide to not use ->blit(). I don't see what the CAP adds, but perhaps I'm missing something. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] gallium/auxiliary/vl: Add barrier/unbind after compute shader launch.
On Tue, Apr 2, 2019 at 2:22 PM Zhu, James wrote: > Add memory barrier sync and unbind resource after launch will enhance > the robustness. > > Signed-off-by: James Zhu > --- > src/gallium/auxiliary/vl/vl_compositor_cs.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/src/gallium/auxiliary/vl/vl_compositor_cs.c > b/src/gallium/auxiliary/vl/vl_compositor_cs.c > index c3afe61..f00cb65 100644 > --- a/src/gallium/auxiliary/vl/vl_compositor_cs.c > +++ b/src/gallium/auxiliary/vl/vl_compositor_cs.c > @@ -292,6 +292,17 @@ cs_launch(struct vl_compositor *c, > info.grid[2] = 1; > > ctx->launch_grid(ctx, ); > + > + /* Make the result visible to all clients. */ > + ctx->memory_barrier(ctx, PIPE_BARRIER_ALL); > + > + /* Unbind. */ > + ctx->set_shader_images(ctx, PIPE_SHADER_COMPUTE, 0, 1, NULL); > + ctx->set_constant_buffer(ctx, PIPE_SHADER_COMPUTE, 0, NULL); > + ctx->set_sampler_views(c->pipe, PIPE_SHADER_FRAGMENT, 0, 0, NULL); > count shouldn't be 0 > + ctx->bind_compute_state(ctx, NULL); > + ctx->bind_sampler_states(c->pipe, PIPE_SHADER_COMPUTE, 0, 0, NULL); > same here + ctx->flush(ctx, NULL, 0); > the flush shouldn't be needed Marek > } > > static inline struct u_rect > -- > 2.7.4 > > ___ > 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] gallium: ddebug: Add missing fence related wrappers
Reviewed-by: Marek Olšák
Marek
On Wed, Apr 3, 2019 at 7:08 AM Guido Günther wrote:
> Without that `GALLIUM_DDEBUG=always kmscube -A` would segfault like
>
> #0 0x in ()
> #1 0xa72a3c54 in dri2_get_fence_fd (_screen=0xed4f2090,
> _fence=0xed9ef880) at
> ../src/gallium/state_trackers/dri/dri_helpers.c:140
> #2 0xa8744824 in dri2_dup_native_fence_fd (drv=0xed5010c0,
> disp=0xed5029a0, sync=0xed9ef7c0) at
> ../src/egl/drivers/dri2/egl_dri2.c:3050
> #3 0xa87339b8 in eglDupNativeFenceFDANDROID
> (dpy=0xed5029a0, sync=0xed9ef7c0) at ../src/egl/main/eglapi.c:2107
> #4 0xbd29ca90 in ()
> #5 0xbd401000 in ()
>
> Signed-off-by: Guido Günther
>
> ---
> Changes from v1:
> - Drop duplicate dd_context_flush() as noticed by Lucas Stach
> ---
> .../auxiliary/driver_ddebug/dd_context.c | 27 +++
> .../auxiliary/driver_ddebug/dd_screen.c | 10 +++
> 2 files changed, 37 insertions(+)
>
> diff --git a/src/gallium/auxiliary/driver_ddebug/dd_context.c
> b/src/gallium/auxiliary/driver_ddebug/dd_context.c
> index 4ea0b16de6f..ab3043a8b87 100644
> --- a/src/gallium/auxiliary/driver_ddebug/dd_context.c
> +++ b/src/gallium/auxiliary/driver_ddebug/dd_context.c
> @@ -575,6 +575,31 @@ dd_context_set_stream_output_targets(struct
> pipe_context *_pipe,
> pipe->set_stream_output_targets(pipe, num_targets, tgs, offsets);
> }
>
> +
> +static void
> +dd_context_fence_server_sync(struct pipe_context *_pipe,
> + struct pipe_fence_handle *fence)
> +{
> + struct dd_context *dctx = dd_context(_pipe);
> + struct pipe_context *pipe = dctx->pipe;
> +
> + pipe->fence_server_sync(pipe, fence);
> +}
> +
> +
> +static void
> +dd_context_create_fence_fd(struct pipe_context *_pipe,
> + struct pipe_fence_handle **fence,
> + int fd,
> + enum pipe_fd_type type)
> +{
> + struct dd_context *dctx = dd_context(_pipe);
> + struct pipe_context *pipe = dctx->pipe;
> +
> + pipe->create_fence_fd(pipe, fence, fd, type);
> +}
> +
> +
> void
> dd_thread_join(struct dd_context *dctx)
> {
> @@ -867,6 +892,8 @@ dd_context_create(struct dd_screen *dscreen, struct
> pipe_context *pipe)
> CTX_INIT(create_stream_output_target);
> CTX_INIT(stream_output_target_destroy);
> CTX_INIT(set_stream_output_targets);
> + CTX_INIT(create_fence_fd);
> + CTX_INIT(fence_server_sync);
> CTX_INIT(create_sampler_view);
> CTX_INIT(sampler_view_destroy);
> CTX_INIT(create_surface);
> diff --git a/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> b/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> index a89af8a8d62..b2108adfa32 100644
> --- a/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> +++ b/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> @@ -348,6 +348,15 @@ dd_screen_fence_finish(struct pipe_screen *_screen,
> return screen->fence_finish(screen, ctx, fence, timeout);
> }
>
> +static int
> +dd_screen_fence_get_fd(struct pipe_screen *_screen,
> + struct pipe_fence_handle *fence)
> +{
> + struct pipe_screen *screen = dd_screen(_screen)->screen;
> +
> + return screen->fence_get_fd(screen, fence);
> +}
> +
> /
> * memobj
> */
> @@ -550,6 +559,7 @@ ddebug_screen_create(struct pipe_screen *screen)
> SCR_INIT(flush_frontbuffer);
> SCR_INIT(fence_reference);
> SCR_INIT(fence_finish);
> + SCR_INIT(fence_get_fd);
> SCR_INIT(memobj_create_from_handle);
> SCR_INIT(memobj_destroy);
> SCR_INIT(get_driver_query_info);
> --
> 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 v2 8/8] egl: add EGL_platform_device support
What is missing for merging this? Thanks, Marek On Wed, Apr 3, 2019 at 12:30 AM Mathias Fröhlich wrote: > Marek, > > On Tuesday, 2 April 2019 23:07:50 CEST Marek Olšák wrote: > > Do you have a branch with patch 7/8 and 8/8? I'm interested in > > EGL_EXT_platform_device on radeonsi. > > You can take a look at the egl-device-4 branch on > https://gitlab.freedesktop.org/frohlich/mesa.git > I pushed a rebased and slightly changed wip for you. > > I have also some more tests in my local piglit as well as separate > tests/examples that I initially wrote as an example to make use of the > extension. > But I have to dig out these first... > > best > > Mathias > > > > > Thanks, > > Marek > > > > On Wed, Oct 3, 2018 at 4:36 AM Mathias Fröhlich < > mathias.froehl...@gmx.net> > > wrote: > > > > > Hi Emil, > > > > > > Ok, thanks for picking that up. > > > > > > On Tuesday, 2 October 2018 12:23:30 CEST Emil Velikov wrote: > > > > On Thu, 20 Sep 2018 at 15:13, Mathias Fröhlich > > > > wrote: > > > > > > > > > > > > > > If I replace the above with > > > > > > > > > > EGLint surface_type = 0; > > > > > /* Only advertise pbuffer configs for non swrast devices > */ > > > > > if (dri2_dpy->image_driver) > > > > > surface_type = EGL_PBUFFER_BIT; > > > > > > > > > > dri2_conf = dri2_add_config(dpy, > dri2_dpy->driver_configs[i], > > > > >config_count + 1, surface_type, NULL, > > > > >visuals[j].rgba_masks); > > > > > > > > > > then I can easily prohibit the crash that I mentioned when trying > to > > > > > create a pbuffer surface on the swrast device. > > > > > At least I do no longer get a valid pbuffer config from > eglChooseConfig > > > > > and without that we cannot reach the crashing > > > > > dri2_dpy->image_driver->createNewDrawable > > > > > call somewhere from eglCreatePbufferSurface anymore. > > > > > > > > > > Still getting a surface less context on swrast should work... > > > > > > > > > Issue is that we do not know how to create a "pbuffer only" swrast. > > > > > > > > Hence one resolves to hacks like the ones we have in > > > platform_surfaceless. > > > > Effectively pilling hacks upon hacks - see swrast_loader_extensions > > > > and "software path w/o DRM.". > > > > > > > > That said, I'm working on proper solution but since it will take some > > > > time to finish/merge I'll drop this and 7/8 for now. > > > > > > > > > That's fine too. > > > > > > What I wanted to avoid is that people using the extension correctly > fail > > > with a > > > crash in the application when running on mesa. > > > Think about it. Thats really bad from an application writers point of > view > > > as you do all right with checking extensions and that and then the > opengl > > > stack suddenly crashes. > > > > > > best > > > > > > Mathias > > > > > > > > > ___ > > > 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 gallium: use compute shaders for vaapi blit
On Wed, Apr 3, 2019 at 9:06 AM Ilia Mirkin wrote: > On Wed, Apr 3, 2019 at 8:38 AM Marek Olšák wrote: > > > > On Tue, Apr 2, 2019 at 2:14 PM Eric Anholt wrote: > >> > >> Ilia Mirkin writes: > >> > >> > Shouldn't this sort of decision be left up to the driver? If the > >> > driver would like to use CS for blits, fine, but why not let it blit > >> > in the most optimal way possible and force it to use a compute shader? > >> > >> Yeah, commit messages require an explanation of why a change is being > >> made. > > > > > > We plan to create vaapi contexts with PIPE_CONTEXT_COMPUTE_ONLY for > better GPU multitasking. > > > > RadeonSI uses async compute queues if PIPE_CONTEXT_COMPUTE_ONLY is set, > so it can't do any graphics stuff, not even blit. (pipe_context::blit is > NULL) > > Makes sense. Sounds like one of those would be a better condition than > the mere existence of compute support then? > Or we can add PIPE_CAP_PREFER_COMPUTE_BLIT as a performance hint. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa gallium: use compute shaders for vaapi blit
On Wed, Apr 3, 2019 at 8:38 AM Marek Olšák wrote: > > On Tue, Apr 2, 2019 at 2:14 PM Eric Anholt wrote: >> >> Ilia Mirkin writes: >> >> > Shouldn't this sort of decision be left up to the driver? If the >> > driver would like to use CS for blits, fine, but why not let it blit >> > in the most optimal way possible and force it to use a compute shader? >> >> Yeah, commit messages require an explanation of why a change is being >> made. > > > We plan to create vaapi contexts with PIPE_CONTEXT_COMPUTE_ONLY for better > GPU multitasking. > > RadeonSI uses async compute queues if PIPE_CONTEXT_COMPUTE_ONLY is set, so it > can't do any graphics stuff, not even blit. (pipe_context::blit is NULL) Makes sense. Sounds like one of those would be a better condition than the mere existence of compute support then? -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa gallium: use compute shaders for vaapi blit
On Tue, Apr 2, 2019 at 2:14 PM Eric Anholt wrote: > Ilia Mirkin writes: > > > Shouldn't this sort of decision be left up to the driver? If the > > driver would like to use CS for blits, fine, but why not let it blit > > in the most optimal way possible and force it to use a compute shader? > > Yeah, commit messages require an explanation of why a change is being > made. > We plan to create vaapi contexts with PIPE_CONTEXT_COMPUTE_ONLY for better GPU multitasking. RadeonSI uses async compute queues if PIPE_CONTEXT_COMPUTE_ONLY is set, so it can't do any graphics stuff, not even blit. (pipe_context::blit is NULL) Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] gallium: ddebug: Add missing fence related wrappers
Am Mittwoch, den 03.04.2019, 13:08 +0200 schrieb Guido Günther:
> Without that `GALLIUM_DDEBUG=always kmscube -A` would segfault like
>
> #0 0x in ()
> #1 0xa72a3c54 in dri2_get_fence_fd (_screen=0xed4f2090,
> _fence=0xed9ef880) at ../src/gallium/state_trackers/dri/dri_helpers.c:140
> #2 0xa8744824 in dri2_dup_native_fence_fd (drv=0xed5010c0,
> disp=0xed5029a0, sync=0xed9ef7c0) at
> ../src/egl/drivers/dri2/egl_dri2.c:3050
> #3 0xa87339b8 in eglDupNativeFenceFDANDROID (dpy=0xed5029a0,
> sync=0xed9ef7c0) at ../src/egl/main/eglapi.c:2107
> #4 0xbd29ca90 in ()
> #5 0xbd401000 in ()
>
> Signed-off-by: Guido Günther
Reviewed-by: Lucas Stach
>
> ---
> Changes from v1:
> - Drop duplicate dd_context_flush() as noticed by Lucas Stach
> ---
> .../auxiliary/driver_ddebug/dd_context.c | 27 +++
> .../auxiliary/driver_ddebug/dd_screen.c | 10 +++
> 2 files changed, 37 insertions(+)
>
> diff --git a/src/gallium/auxiliary/driver_ddebug/dd_context.c
> b/src/gallium/auxiliary/driver_ddebug/dd_context.c
> index 4ea0b16de6f..ab3043a8b87 100644
> --- a/src/gallium/auxiliary/driver_ddebug/dd_context.c
> +++ b/src/gallium/auxiliary/driver_ddebug/dd_context.c
> @@ -575,6 +575,31 @@ dd_context_set_stream_output_targets(struct pipe_context
> *_pipe,
> pipe->set_stream_output_targets(pipe, num_targets, tgs, offsets);
> }
>
> +
> +static void
> +dd_context_fence_server_sync(struct pipe_context *_pipe,
> + struct pipe_fence_handle *fence)
> +{
> + struct dd_context *dctx = dd_context(_pipe);
> + struct pipe_context *pipe = dctx->pipe;
> +
> + pipe->fence_server_sync(pipe, fence);
> +}
> +
> +
> +static void
> +dd_context_create_fence_fd(struct pipe_context *_pipe,
> + struct pipe_fence_handle **fence,
> + int fd,
> + enum pipe_fd_type type)
> +{
> + struct dd_context *dctx = dd_context(_pipe);
> + struct pipe_context *pipe = dctx->pipe;
> +
> + pipe->create_fence_fd(pipe, fence, fd, type);
> +}
> +
> +
> void
> dd_thread_join(struct dd_context *dctx)
> {
> @@ -867,6 +892,8 @@ dd_context_create(struct dd_screen *dscreen, struct
> pipe_context *pipe)
> CTX_INIT(create_stream_output_target);
> CTX_INIT(stream_output_target_destroy);
> CTX_INIT(set_stream_output_targets);
> + CTX_INIT(create_fence_fd);
> + CTX_INIT(fence_server_sync);
> CTX_INIT(create_sampler_view);
> CTX_INIT(sampler_view_destroy);
> CTX_INIT(create_surface);
> diff --git a/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> b/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> index a89af8a8d62..b2108adfa32 100644
> --- a/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> +++ b/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> @@ -348,6 +348,15 @@ dd_screen_fence_finish(struct pipe_screen *_screen,
> return screen->fence_finish(screen, ctx, fence, timeout);
> }
>
> +static int
> +dd_screen_fence_get_fd(struct pipe_screen *_screen,
> + struct pipe_fence_handle *fence)
> +{
> + struct pipe_screen *screen = dd_screen(_screen)->screen;
> +
> + return screen->fence_get_fd(screen, fence);
> +}
> +
> /
> * memobj
> */
> @@ -550,6 +559,7 @@ ddebug_screen_create(struct pipe_screen *screen)
> SCR_INIT(flush_frontbuffer);
> SCR_INIT(fence_reference);
> SCR_INIT(fence_finish);
> + SCR_INIT(fence_get_fd);
> SCR_INIT(memobj_create_from_handle);
> SCR_INIT(memobj_destroy);
> SCR_INIT(get_driver_query_info);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nir: do not pack varying with different types
The current algorithm only supports packing 32-bit types.
If a shader uses both 16-bit and 32-bit varyings, we shouldn't
compact them together.
Cc: Timothy Arceri
Signed-off-by: Samuel Pitoiset
---
src/compiler/nir/nir_linking_helpers.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/compiler/nir/nir_linking_helpers.c
b/src/compiler/nir/nir_linking_helpers.c
index 146d4e4e591..482ac2881bc 100644
--- a/src/compiler/nir/nir_linking_helpers.c
+++ b/src/compiler/nir/nir_linking_helpers.c
@@ -243,6 +243,7 @@ struct assigned_comps
uint8_t comps;
uint8_t interp_type;
uint8_t interp_loc;
+ uint8_t is_32bit;
};
/* Packing arrays and dual slot varyings is difficult so to avoid complex
@@ -308,6 +309,7 @@ get_unmoveable_components_masks(struct exec_list *var_list,
comps[location + i].interp_type =
get_interp_type(var, type, default_to_smooth_interp);
comps[location + i].interp_loc = get_interp_loc(var);
+comps[location + i].is_32bit =
glsl_type_is_32bit(glsl_without_array(type));
}
}
}
@@ -572,6 +574,14 @@ assign_remap_locations(struct varying_loc (*remap)[4],
continue;
}
+ /* We can only pack varyings with matching types, and the current
+ * algorithm only supports packing 32-bit.
+ */
+ if (!assigned_comps[tmp_cursor].is_32bit) {
+tmp_comp = 0;
+continue;
+ }
+
while (tmp_comp < 4 &&
(assigned_comps[tmp_cursor].comps & (1 << tmp_comp))) {
tmp_comp++;
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: ddebug: Add missing fence related wrappers
Hi,
On Wed, Apr 03, 2019 at 12:43:05PM +0200, Lucas Stach wrote:
> Hi Guido,
>
> Am Montag, den 01.04.2019, 14:19 +0200 schrieb Guido Günther:
> > Without that `GALLIUM_DDEBUG=always kmscube -A` would segfault like
> >
> > #0 0x in ()
> > #1 0xa72a3c54 in dri2_get_fence_fd (_screen=0xed4f2090,
> > _fence=0xed9ef880) at
> > ../src/gallium/state_trackers/dri/dri_helpers.c:140
> > #2 0xa8744824 in dri2_dup_native_fence_fd (drv=0xed5010c0,
> > disp=0xed5029a0, sync=0xed9ef7c0) at
> > ../src/egl/drivers/dri2/egl_dri2.c:3050
> > #3 0xa87339b8 in eglDupNativeFenceFDANDROID (dpy=0xed5029a0,
> > sync=0xed9ef7c0) at ../src/egl/main/eglapi.c:2107
> > #4 0xbd29ca90 in ()
> > #5 0xbd401000 in ()
> >
> > > Signed-off-by: Guido Günther
> > ---
> > This is similar in spirit to the patches for GALLIUM_TRACE send out earlier.
> >
> >
> > .../auxiliary/driver_ddebug/dd_context.c | 40 +++
> > .../auxiliary/driver_ddebug/dd_screen.c | 10 +
> > 2 files changed, 50 insertions(+)
> >
> > diff --git a/src/gallium/auxiliary/driver_ddebug/dd_context.c
> > b/src/gallium/auxiliary/driver_ddebug/dd_context.c
> > index 4ea0b16de6f..3152c664630 100644
> > --- a/src/gallium/auxiliary/driver_ddebug/dd_context.c
> > +++ b/src/gallium/auxiliary/driver_ddebug/dd_context.c
> > @@ -575,6 +575,43 @@ dd_context_set_stream_output_targets(struct
> > pipe_context *_pipe,
> > pipe->set_stream_output_targets(pipe, num_targets, tgs, offsets);
> > }
> >
> > +
> > +static void
> > +dd_context_flush(struct pipe_context *_pipe,
> > + struct pipe_fence_handle **fence,
> > + unsigned flags)
> > +{
> > + struct dd_context *dctx = dd_context(_pipe);
> > + struct pipe_context *pipe = dctx->pipe;
> > +
> > + pipe->flush(pipe, fence, flags);
> > +}
>
> dd_context_flush() is already implemented in dd_draw.c
You're right - only looked in dd_context. I've removed that part in v2.
Cheers,
-- Guido
>
> Regards,
> Lucas
>
> > +
> > +
> > +static void
> > +dd_context_fence_server_sync(struct pipe_context *_pipe,
> > + struct pipe_fence_handle *fence)
> > +{
> > + struct dd_context *dctx = dd_context(_pipe);
> > + struct pipe_context *pipe = dctx->pipe;
> > +
> > + pipe->fence_server_sync(pipe, fence);
> > +}
> > +
> > +
> > +static void
> > +dd_context_create_fence_fd(struct pipe_context *_pipe,
> > + struct pipe_fence_handle **fence,
> > + int fd,
> > + enum pipe_fd_type type)
> > +{
> > + struct dd_context *dctx = dd_context(_pipe);
> > + struct pipe_context *pipe = dctx->pipe;
> > +
> > + pipe->create_fence_fd(pipe, fence, fd, type);
> > +}
> > +
> > +
> > void
> > dd_thread_join(struct dd_context *dctx)
> > {
> > @@ -867,6 +904,9 @@ dd_context_create(struct dd_screen *dscreen, struct
> > pipe_context *pipe)
> > CTX_INIT(create_stream_output_target);
> > CTX_INIT(stream_output_target_destroy);
> > CTX_INIT(set_stream_output_targets);
> > + CTX_INIT(flush);
> > + CTX_INIT(create_fence_fd);
> > + CTX_INIT(fence_server_sync);
> > CTX_INIT(create_sampler_view);
> > CTX_INIT(sampler_view_destroy);
> > CTX_INIT(create_surface);
> > diff --git a/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> > b/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> > index a89af8a8d62..b2108adfa32 100644
> > --- a/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> > +++ b/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> > @@ -348,6 +348,15 @@ dd_screen_fence_finish(struct pipe_screen *_screen,
> > return screen->fence_finish(screen, ctx, fence, timeout);
> > }
> >
> > +static int
> > +dd_screen_fence_get_fd(struct pipe_screen *_screen,
> > + struct pipe_fence_handle *fence)
> > +{
> > + struct pipe_screen *screen = dd_screen(_screen)->screen;
> > +
> > + return screen->fence_get_fd(screen, fence);
> > +}
> > +
> > /
> > * memobj
> > */
> > @@ -550,6 +559,7 @@ ddebug_screen_create(struct pipe_screen *screen)
> > SCR_INIT(flush_frontbuffer);
> > SCR_INIT(fence_reference);
> > SCR_INIT(fence_finish);
> > + SCR_INIT(fence_get_fd);
> > SCR_INIT(memobj_create_from_handle);
> > SCR_INIT(memobj_destroy);
> > SCR_INIT(get_driver_query_info);
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] gallium: ddebug: Add missing fence related wrappers
Without that `GALLIUM_DDEBUG=always kmscube -A` would segfault like
#0 0x in ()
#1 0xa72a3c54 in dri2_get_fence_fd (_screen=0xed4f2090,
_fence=0xed9ef880) at ../src/gallium/state_trackers/dri/dri_helpers.c:140
#2 0xa8744824 in dri2_dup_native_fence_fd (drv=0xed5010c0,
disp=0xed5029a0, sync=0xed9ef7c0) at
../src/egl/drivers/dri2/egl_dri2.c:3050
#3 0xa87339b8 in eglDupNativeFenceFDANDROID (dpy=0xed5029a0,
sync=0xed9ef7c0) at ../src/egl/main/eglapi.c:2107
#4 0xbd29ca90 in ()
#5 0xbd401000 in ()
Signed-off-by: Guido Günther
---
Changes from v1:
- Drop duplicate dd_context_flush() as noticed by Lucas Stach
---
.../auxiliary/driver_ddebug/dd_context.c | 27 +++
.../auxiliary/driver_ddebug/dd_screen.c | 10 +++
2 files changed, 37 insertions(+)
diff --git a/src/gallium/auxiliary/driver_ddebug/dd_context.c
b/src/gallium/auxiliary/driver_ddebug/dd_context.c
index 4ea0b16de6f..ab3043a8b87 100644
--- a/src/gallium/auxiliary/driver_ddebug/dd_context.c
+++ b/src/gallium/auxiliary/driver_ddebug/dd_context.c
@@ -575,6 +575,31 @@ dd_context_set_stream_output_targets(struct pipe_context
*_pipe,
pipe->set_stream_output_targets(pipe, num_targets, tgs, offsets);
}
+
+static void
+dd_context_fence_server_sync(struct pipe_context *_pipe,
+ struct pipe_fence_handle *fence)
+{
+ struct dd_context *dctx = dd_context(_pipe);
+ struct pipe_context *pipe = dctx->pipe;
+
+ pipe->fence_server_sync(pipe, fence);
+}
+
+
+static void
+dd_context_create_fence_fd(struct pipe_context *_pipe,
+ struct pipe_fence_handle **fence,
+ int fd,
+ enum pipe_fd_type type)
+{
+ struct dd_context *dctx = dd_context(_pipe);
+ struct pipe_context *pipe = dctx->pipe;
+
+ pipe->create_fence_fd(pipe, fence, fd, type);
+}
+
+
void
dd_thread_join(struct dd_context *dctx)
{
@@ -867,6 +892,8 @@ dd_context_create(struct dd_screen *dscreen, struct
pipe_context *pipe)
CTX_INIT(create_stream_output_target);
CTX_INIT(stream_output_target_destroy);
CTX_INIT(set_stream_output_targets);
+ CTX_INIT(create_fence_fd);
+ CTX_INIT(fence_server_sync);
CTX_INIT(create_sampler_view);
CTX_INIT(sampler_view_destroy);
CTX_INIT(create_surface);
diff --git a/src/gallium/auxiliary/driver_ddebug/dd_screen.c
b/src/gallium/auxiliary/driver_ddebug/dd_screen.c
index a89af8a8d62..b2108adfa32 100644
--- a/src/gallium/auxiliary/driver_ddebug/dd_screen.c
+++ b/src/gallium/auxiliary/driver_ddebug/dd_screen.c
@@ -348,6 +348,15 @@ dd_screen_fence_finish(struct pipe_screen *_screen,
return screen->fence_finish(screen, ctx, fence, timeout);
}
+static int
+dd_screen_fence_get_fd(struct pipe_screen *_screen,
+ struct pipe_fence_handle *fence)
+{
+ struct pipe_screen *screen = dd_screen(_screen)->screen;
+
+ return screen->fence_get_fd(screen, fence);
+}
+
/
* memobj
*/
@@ -550,6 +559,7 @@ ddebug_screen_create(struct pipe_screen *screen)
SCR_INIT(flush_frontbuffer);
SCR_INIT(fence_reference);
SCR_INIT(fence_finish);
+ SCR_INIT(fence_get_fd);
SCR_INIT(memobj_create_from_handle);
SCR_INIT(memobj_destroy);
SCR_INIT(get_driver_query_info);
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: ddebug: Add missing fence related wrappers
Hi Guido,
Am Montag, den 01.04.2019, 14:19 +0200 schrieb Guido Günther:
> Without that `GALLIUM_DDEBUG=always kmscube -A` would segfault like
>
> #0 0x in ()
> #1 0xa72a3c54 in dri2_get_fence_fd (_screen=0xed4f2090,
> _fence=0xed9ef880) at ../src/gallium/state_trackers/dri/dri_helpers.c:140
> #2 0xa8744824 in dri2_dup_native_fence_fd (drv=0xed5010c0,
> disp=0xed5029a0, sync=0xed9ef7c0) at
> ../src/egl/drivers/dri2/egl_dri2.c:3050
> #3 0xa87339b8 in eglDupNativeFenceFDANDROID (dpy=0xed5029a0,
> sync=0xed9ef7c0) at ../src/egl/main/eglapi.c:2107
> #4 0xbd29ca90 in ()
> #5 0xbd401000 in ()
>
> > Signed-off-by: Guido Günther
> ---
> This is similar in spirit to the patches for GALLIUM_TRACE send out earlier.
>
>
> .../auxiliary/driver_ddebug/dd_context.c | 40 +++
> .../auxiliary/driver_ddebug/dd_screen.c | 10 +
> 2 files changed, 50 insertions(+)
>
> diff --git a/src/gallium/auxiliary/driver_ddebug/dd_context.c
> b/src/gallium/auxiliary/driver_ddebug/dd_context.c
> index 4ea0b16de6f..3152c664630 100644
> --- a/src/gallium/auxiliary/driver_ddebug/dd_context.c
> +++ b/src/gallium/auxiliary/driver_ddebug/dd_context.c
> @@ -575,6 +575,43 @@ dd_context_set_stream_output_targets(struct pipe_context
> *_pipe,
> pipe->set_stream_output_targets(pipe, num_targets, tgs, offsets);
> }
>
> +
> +static void
> +dd_context_flush(struct pipe_context *_pipe,
> + struct pipe_fence_handle **fence,
> + unsigned flags)
> +{
> + struct dd_context *dctx = dd_context(_pipe);
> + struct pipe_context *pipe = dctx->pipe;
> +
> + pipe->flush(pipe, fence, flags);
> +}
dd_context_flush() is already implemented in dd_draw.c
Regards,
Lucas
> +
> +
> +static void
> +dd_context_fence_server_sync(struct pipe_context *_pipe,
> + struct pipe_fence_handle *fence)
> +{
> + struct dd_context *dctx = dd_context(_pipe);
> + struct pipe_context *pipe = dctx->pipe;
> +
> + pipe->fence_server_sync(pipe, fence);
> +}
> +
> +
> +static void
> +dd_context_create_fence_fd(struct pipe_context *_pipe,
> + struct pipe_fence_handle **fence,
> + int fd,
> + enum pipe_fd_type type)
> +{
> + struct dd_context *dctx = dd_context(_pipe);
> + struct pipe_context *pipe = dctx->pipe;
> +
> + pipe->create_fence_fd(pipe, fence, fd, type);
> +}
> +
> +
> void
> dd_thread_join(struct dd_context *dctx)
> {
> @@ -867,6 +904,9 @@ dd_context_create(struct dd_screen *dscreen, struct
> pipe_context *pipe)
> CTX_INIT(create_stream_output_target);
> CTX_INIT(stream_output_target_destroy);
> CTX_INIT(set_stream_output_targets);
> + CTX_INIT(flush);
> + CTX_INIT(create_fence_fd);
> + CTX_INIT(fence_server_sync);
> CTX_INIT(create_sampler_view);
> CTX_INIT(sampler_view_destroy);
> CTX_INIT(create_surface);
> diff --git a/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> b/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> index a89af8a8d62..b2108adfa32 100644
> --- a/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> +++ b/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> @@ -348,6 +348,15 @@ dd_screen_fence_finish(struct pipe_screen *_screen,
> return screen->fence_finish(screen, ctx, fence, timeout);
> }
>
> +static int
> +dd_screen_fence_get_fd(struct pipe_screen *_screen,
> + struct pipe_fence_handle *fence)
> +{
> + struct pipe_screen *screen = dd_screen(_screen)->screen;
> +
> + return screen->fence_get_fd(screen, fence);
> +}
> +
> /
> * memobj
> */
> @@ -550,6 +559,7 @@ ddebug_screen_create(struct pipe_screen *screen)
> SCR_INIT(flush_frontbuffer);
> SCR_INIT(fence_reference);
> SCR_INIT(fence_finish);
> + SCR_INIT(fence_get_fd);
> SCR_INIT(memobj_create_from_handle);
> SCR_INIT(memobj_destroy);
> SCR_INIT(get_driver_query_info);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] virgl: Set bind when creating temp resource.
On Mon, 2019-04-01 at 12:43 -0700, Lepton Wu wrote:
>
>
> On Tue, Mar 19, 2019 at 4:29 AM Erik Faye-Lund <
> erik.faye-l...@collabora.com> 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 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 changed, 1 insertion(+)
> > >
> > > diff --git a/src/gallium/drivers/virgl/virgl_texture.c
> > > b/src/gallium/drivers/virgl/virgl_texture.c
> > > index 231319899e0..563dbacba7e 100644
> > > --- a/src/gallium/drivers/virgl/virgl_texture.c
> > > +++ b/src/gallium/drivers/virgl/virgl_texture.c
> > > @@ -66,6 +66,7 @@ static void
> > > virgl_init_temp_resource_from_box(struct pipe_resource *res,
> > >unsigned level,
> > > unsigned flags)
> > > {
> > > memset(res, 0, sizeof(*res));
> > > + res->bind = orig->bind;
> > > res->format = orig->format;
> > > res->width0 = box->width;
> > > res->height0 = box->height;
> >
> > I have a similar-ish patch for the same issue in a branch I'll be
> > sending out soon:
> >
> > https://gitlab.freedesktop.org/kusma/mesa/commit/6c19b6b98025a1be31eabdb559709b18eecdbafa#note_132855
> >
> > Now, as Dave pointed out, there might be some more cases missing in
> > my
> > patch. I also tried your approach, and it works for me. But I'm not
> > entirely sure it's the right one; for instance I don't think we'd
> > ever
> > want to carry flags like PIPE_BIND_DISPLAY_TARGET and
> > PIPE_BIND_BLENDABLE forward.
> >
> > Perhaps the right thing is to do something like:
> >
> > res->bind = orig->bind & (PIPE_BIND_DEPTH_STENCIL |
> > PIPE_BIND_RENDER_TARGET);
> >
> > But I'm not sure if that's enough; what if we get a surface with
> > PIPE_BIND_SHADER_IMAGE set? We probably still want to use
> > PIPE_BIND_RENDER_TARGET for the blit then...
>
> How about this, let's deal with PIPE_BIND_DEPTH_STENCIL
> and PIPE_BIND_RENDER_TARGET first in this patch, also add a warning
> here
> if we see any other bind so later people can fix things based on
> real cases. Then at least we fix something in this patch.
Sounds good to me.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 87738] [OpenCL] Please add Image support
https://bugs.freedesktop.org/show_bug.cgi?id=87738 --- Comment #6 from Jan Vesely --- (In reply to smt from comment #5) > Is there any progress at all towards this? I feel like it would really > improve Linux use case for some of us using software like Darktable and > whatever other software could possibly use this, I'm still unable to use > opencl in Darktable with the same error: > > 0.021473 [opencl_init] found opencl runtime library 'libOpenCL' > 0.021502 [opencl_init] opencl library 'libOpenCL' found on your system and > loaded > 0.081308 [opencl_init] found 1 platform > 0.081325 [opencl_init] found 1 device > 0.081354 [opencl_init] discarding device 0 `AMD Radeon (TM) RX 460 Graphics > (POLARIS11, DRM 3.27.0, 5.0.0-8-generic, LLVM 8.0.0)' due to missing image > support. > 0.081359 [opencl_init] no suitable devices found. > 0.081360 [opencl_init] FINALLY: opencl is NOT AVAILABLE on this system. There has been little progress on image support. The implementation had tons of other problems with advertised functionality (mostly in libclc builtins). You'd probably get incorrect results if those workloads ran. images are #3 on my todo list (after fixing conversion routines(#1) and support for non-inlined function calls(#2)) unless someone beats me to it. but time is scarce. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/aux: Report error if loading of a pipe driver fails.
Skip over non-existent files.
Signed-off-by: Jan Vesely
---
This should help detect instances of messed up/missing symbols in the driver.
windows build seems OK:
https://ci.appveyor.com/project/jvesely/mesa/builds/23550498#L1292
.../auxiliary/pipe-loader/pipe_loader.c | 5 +-
src/gallium/auxiliary/util/u_file.h | 58 +++
2 files changed, 62 insertions(+), 1 deletion(-)
create mode 100644 src/gallium/auxiliary/util/u_file.h
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
index 6fd15527e53..fc8ee8e8dcd 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
@@ -31,6 +31,7 @@
#include "util/u_memory.h"
#include "util/u_string.h"
#include "util/u_dl.h"
+#include "util/u_file.h"
#include "util/xmlconfig.h"
#include "util/xmlpool.h"
@@ -158,11 +159,13 @@ pipe_loader_find_module(const char *driver_name,
ret = util_snprintf(path, sizeof(path), "%s%s%s",
MODULE_PREFIX, driver_name, UTIL_DL_EXT);
- if (ret > 0 && ret < sizeof(path)) {
+ if (ret > 0 && ret < sizeof(path) && u_file_access(path, 0) != -1) {
lib = util_dl_open(path);
if (lib) {
return lib;
}
+ fprintf(stderr, "ERROR: Failed to load pipe driver at `%s': %s\n",
+ path, util_dl_error());
}
}
diff --git a/src/gallium/auxiliary/util/u_file.h
b/src/gallium/auxiliary/util/u_file.h
new file mode 100644
index 000..f337dc9761e
--- /dev/null
+++ b/src/gallium/auxiliary/util/u_file.h
@@ -0,0 +1,58 @@
+/**
+ *
+ * Copyright 2009 VMware, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ **/
+
+
+#ifndef U_FILE_H_
+#define U_FILE_H_
+
+#if defined(PIPE_OS_UNIX)
+#include
+#endif
+#if defined(PIPE_OS_WINDOWS)
+#include
+#endif
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+static inline int
+u_file_access(const char *path, int mode) {
+#if defined(PIPE_OS_UNIX)
+ return access(path, mode);
+#elif defined(PIPE_OS_WINDOWS)
+ return _access(path, mode);
+#else
+ return 0;
+#endif
+}
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* U_FILE_H_ */
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
