Re: [Mesa-dev] [RFC][PATCH 4/5] Android.mk: Add option to use vendor version of mesa
On 07/26/2018 08:06 PM, Rob Herring wrote: On Wed, Jul 25, 2018 at 1:52 PM John Stultz wrote: On Wed, Jul 25, 2018 at 5:42 AM, Emil Velikov wrote: On 25 July 2018 at 00:21, John Stultz wrote: From: Yong Yao This is a forward port of a patch from the AOSP/master branch: https://android.googlesource.com/platform/external/mesa3d/+/b1e5fad1db4c1d51c7ae3a033b100a8429ae5415%5E%21/ Which allows boards to provide their own custom copy of mesa. Thanks for sorting these out John. My understanding was that when a custom project repo is used one handles that in the device manifest. Roughly as: - foo.xml -> contains vast majority of the git repos with associated tags/etc - local.xml -> removes any repo/project from ^^, adds new one Is that no longer the case, or I simply misremember how Android does things? So, I'm not aware of the specific history behind this patch. I think it is quite simple. Intel needed mesa and put it into their device repo(s) rather than updating external/mesa3d/. I would point to the repo, but it seems android-ia is gone... FYI Android-IA was renamed as 'Celadon': https://01.org/projectceladon/ but Mesa branch is still available in the old location: https://github.com/intel/external-mesa And I can't speak for Google, there has been a general push via the Treble efforts to standardize the Android system image, and to push vendors to keep any device specific bits into their own device directory. So there is a strong disincentive to modify projects in AOSP and in order to include things like devboards into AOSP, the push has been to limit any device specific changes to only the device directory git tree. I can't imagine that mesa would ever be part of the system image so why would there be any common repository. Maybe a s/w rendering build, but that may still be in the vendor partition and SwiftShader seems to be preferred anyways. There seems to be little incentive to not have a fork per device. So while one can technically still replace projects with local repos (and this is very useful for development!), I think they do not want folks doing this for shipping devices. We are trying to make sure device support is pushed upstream to fdo, A fork in every device is not encouraging that. I think anyone working on h/w support in mesa is targeting upstream anyways regardless of what happens in AOSP. and then align AOSP's mesa to that, but one could imagine a board that doesn't have support upstream in mesa, and provides its own copy of mesa in the device directory. This patch allows the build to override the default mesa project with the vendor provided mesa. One concrete example here, which unfortunately I've not had time to work on, might be if we try to integrate the revived lima work to support HiKey's mali utgard gpu. That would require a local mesa tree along with the developmental kernel driver. I'm pretty sure lima will be merged to mesa master well before either it works with Android or anyone cares about supporting it in AOSP. Rob ___ 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 1/2] mesa: add glRenderbufferStorage support for EXT_texture_norm16 formats
Hi; On 07/25/2018 08:36 AM, Tapani Pälli wrote: On 07/24/2018 10:31 PM, Eric Anholt wrote: Tapani Pälli writes: These bits were missing, found when extending the Piglit test. Fixes: 7f467d4f73 "mesa: GL_EXT_texture_norm16 extension plumbing" Signed-off-by: Tapani Pälli Aren't you missing the RGB16 and R/RG/RGB/RGBA16_SNORM cases here? They aren't required for rendering, but if the implementation supports them we should answer correctly. If I've understood correctly, SNORM ones are supported only with EXT_render_snorm so those ones I was planning to add separately. For RGB16 I guess we would need to query the driver. Not sure what would be the best way to achieve this, it seems that at least i965 relies on _mesa_query_internal_format_default which just says to support anything (is broken). Eric, would it be OK to land this patch? I'll add SNORM ones with EXT_render_snorm. // Tapani ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 1/8] nir: evaluate if condition uses inside the if branches
For the series Tested-by: Dieter Nützel with glmark2, glxgears, UH, UV, Blender 2.79 and FreeCAD 0.17 on RX 580. With UH I saw some small light blue triangles spreading around. Have to bisect which patch set was the culprit. (If I have some time.) Tried your's above configure-bump-libdrm-for-AMDGPU-to-2.4.92.mbox (Samuel) ASTC-texture-compression-for-all-Gallium-drivers.mbox (Marek) Dieter Am 28.07.2018 03:07, schrieb Timothy Arceri: On 28/07/18 11:06, Timothy Arceri wrote: Since we know what side of the branch we ended up on we can just replace the use with a constant. All the spill changes in shader-db are from Dolphin uber shaders, despite some small regressions the change is clearly positive. V2: insert new constant after any phis in the use->parent_instr->type == nir_instr_type_phi path. Meh this was meant to be V3 ___ 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 04/11] nir/types: Add array_or_matrix helpers
1-4: Reviewed-by: Timothy Arceri ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107351] Android 8.1: radv segfault with 3Dmark vulkan benchmarks
https://bugs.freedesktop.org/show_bug.cgi?id=107351 --- Comment #14 from Mauro Rossi --- Created attachment 140879 --> https://bugs.freedesktop.org/attachment.cgi?id=140879=edit Hack test case that avoids the segfault Hi Bas, I (truly) don't know how this was possible, because it is all based on trial and error, but the changes in the attachment allow to avoid the segfault and to proceed in both 3DMARK Slingshot Extreme and 3DMARK API Overhead, the benchmark now proceed without segfaults. The changes are inspired from anv code with some changes as explained in the commit message. Probably the problem is elsewhere, I'd like to understand why these changes work. Mauro -- You are receiving this mail because: You are the QA Contact for the bug. 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] [Bug 106411] Invalid gl_InstanceID value with combination of gl_DrawIDARB under OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=106411 --- Comment #4 from Lionel Landwerlin --- Could this be related to https://bugs.freedesktop.org/show_bug.cgi?id=102678 ? -- 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
Re: [Mesa-dev] [PATCH] xf86drm: Fix error path in drmGetDevice2
I think chasing all the invocations of drmGetDevice2 is wrong - since
it's drmGetDevice2 that's broken, not the code that uses it. Code that
uses drmGetDevice2 expects it to return error when device has not been
found.
If setting *device in error path is not good, the patch can be
modified to not set *device to NULL and return error when it was never
assigned in the drmGetDevice2 function - it should also work, though I
have not tried it.
On 29 July 2018 at 19:20, Christoph Haag wrote:
> I've reported this here:
> https://bugs.freedesktop.org/show_bug.cgi?id=107384
>
> The patch in the comments initializing drmDevicePtr device to NULL makes
> it work properly for me.
>
> I don't think the patch is on the mailing list yet. It's probably a good
> idea to check if there are more places where this initialization needs
> to be done...
>
>
> On 29.07.2018 10:20, Mariusz Ceier wrote:
>> In drmGetDevice2 when no local device is found or when
>> drm_device_has_rdev filters out all devices, *device might be left
>> uninitialized causing drmGetDevice2 to not return error - since
>> it's only returned when *device == NULL.
>>
>> Above leads to crash in the firefox in system with amdgpu.
>>
>> With this change firefox displays:
>>
>> libGL error: MESA-LOADER: failed to retrieve device information
>> libGL error: unable to load driver: amdgpu_dri.so
>> libGL error: driver pointer missing
>> libGL error: failed to load driver: amdgpu
>> libGL error: MESA-LOADER: failed to retrieve device information
>> libGL error: unable to load driver: amdgpu_dri.so
>> libGL error: driver pointer missing
>> libGL error: failed to load driver: amdgpu
>>
>> and doesn't crash.
>>
>> Signed-off-by: Mariusz Ceier
>> ---
>> xf86drm.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/xf86drm.c b/xf86drm.c
>> index 1e621e99..336d64de 100644
>> --- a/xf86drm.c
>> +++ b/xf86drm.c
>> @@ -3935,6 +3935,8 @@ int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr
>> *device)
>>
>> drmFoldDuplicatedDevices(local_devices, node_count);
>>
>> +*device = NULL;
>> +
>> for (i = 0; i < node_count; i++) {
>> if (!local_devices[i])
>> continue;
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106411] Invalid gl_InstanceID value with combination of gl_DrawIDARB under OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=106411 --- Comment #3 from Alexander --- I have no reproduction on Mesa 18.1.3. So the bug is related to Mesa 18.0.* only. -- 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 v5 1/2] intel/fs: New methods dst_write_pattern and src_read_pattern at fs_inst
These new methods return for a instruction register source/destination
the read/write byte pattern of the 32-byte GRF as an unsigned int.
The returned pattern takes into account the exec_size of the instruction,
the type bitsize, the register stride and a relative offset inside the
register.
The motivation of this functions if to know the read/written bytes
of the instructions to improve the liveness analysis for partial
read/writes.
We manage special cases for SHADER_OPCODE_BYTE_SCATTERED_WRITE_LOGICAL
and SHADER_OPCODE_BYTE_SCATTERED_WRITE because depending of the bitsize
parameter they have a different read pattern.
v2: (Francisco Jerez)
- Split original register_byte_use_pattern into one read and other
write.
- Check for send like instructions using this->mlen != 0
- Pass functions src number and offset.
- Use periodic_mask function with code written by Francisco Jerez
to simplify pattern generation.
- Avoid breaking silently if source straddles multiple GRFs.
v3: (Francisco Jerez)
- A SEND could be this->mlen != 0 or this->is_send_from_grf
- We only assume that a periodic mask with offset could be applied
to reg_offset == 0.
- We can assure that for MOVs operations for any offset (Chema)
v4: (Francisco Jerez)
- We return 0 mask for reg_offset out of the region definition.
- We return periodic masks when access is in bounds for ALU opcodes.
v5: (Francisco Jerez)
- Mask can only be periodic when byte_offset < type_size * stride
when reg_offset > 0.
Cc: Francisco Jerez
---
src/intel/compiler/brw_fs.cpp | 121 +
src/intel/compiler/brw_ir_fs.h | 2 +
2 files changed, 123 insertions(+)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 7ddbd285fe2..d790b080e53 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -39,6 +39,7 @@
#include "compiler/glsl_types.h"
#include "compiler/nir/nir_builder.h"
#include "program/prog_parameter.h"
+#include
using namespace brw;
@@ -687,6 +688,126 @@ fs_inst::is_partial_write() const
this->dst.offset % REG_SIZE != 0);
}
+/**
+ * Returns a periodic mask that is repeated "count" times with a "step"
+ * size and consecutive "bits" finally shifted "offset" bits to the left.
+ *
+ * This helper is used to calculate the representations of byte read/write
+ * register patterns
+ *
+ * Example: periodic_mask(8, 4, 2, 0) would return 0x
+ * periodic_mask(8, 4, 2, 2) would return 0x
+ * periodic_masc(8, 2, 2, 16) would return 0x
+ */
+static inline uint32_t
+periodic_mask(unsigned count, unsigned step, unsigned bits, unsigned offset)
+{
+ uint32_t m = (count ? (1 << bits) - 1 : 0);
+ const unsigned max = MIN2(count * step, sizeof(m) * CHAR_BIT);
+
+ for (unsigned shift = step; shift < max; shift *= 2)
+ m |= m << shift;
+
+ return m << offset;
+}
+
+/**
+ * Returns a 32-bit uint whose bits represent if the associated register byte
+ * has been written by the instruction. The returned pattern takes into
+ * account the exec_size of the instruction, the type bitsize, the stride
+ * of the destination register and the internal register byte offset.
+ *
+ * The objective of this function is to identify which parts of the register
+ * are written for operations that don't write a full register. So we
+ * we can identify in live range variable analysis if a partial write has
+ * completelly defined the data used by a partial read.
+ *
+ * reg_offset identifies full registers starting at dst.reg with
+ * reg_offset == 0.
+ */
+unsigned
+fs_inst::dst_write_pattern(unsigned reg_offset) const
+{
+ assert(this->dst.file == VGRF);
+
+ /* Instruction doesn't write out of bounds */
+ if (reg_offset >= regs_written(this))
+ return 0;
+
+ /* We don't know what is written so we return the worst case */
+ if (this->predicate && this->opcode != BRW_OPCODE_SEL)
+ return 0;
+
+ /* We assume that send destinations are completelly defined */
+ if (this->is_send_from_grf() || this->mlen != 0)
+ return ~0u;
+
+ /* The byte pattern is calculated using a periodic mask for ALU
+* operations and reg_offset in bounds.
+*/
+ unsigned step = this->dst.stride * type_sz(this->dst.type);
+ unsigned byte_offset = this->dst.offset % REG_SIZE;
+ if (reg_offset == 0 || byte_offset < step) {
+ return periodic_mask(this->exec_size, step, type_sz(this->dst.type),
+ byte_offset);
+ }
+
+ /* We don't know what was written so return 0 as safest choice */
+ return 0;
+}
+
+/**
+ * Returns a 32-bit uint whose bits represent if the associated register byte
+ * has been read by the instruction. The returned pattern takes into
+ * account the exec_size of the instruction, the type bitsize and stride of
+ * a source register and the internal register byte offset.
+ *
+ * The objective of this function
Re: [Mesa-dev] [PATCH 1/2] intel/fs: New method for register_byte_use_pattern for fs_inst
El 28/07/18 a las 01:45, Francisco Jerez escribió:
> Chema Casanova writes:
>
>> El 27/07/18 a las 02:44, Francisco Jerez escribió:
>>> Chema Casanova writes:
>>>
El 26/07/18 a las 20:02, Francisco Jerez escribió:
> Chema Casanova writes:
>
>> El 20/07/18 a las 22:10, Francisco Jerez escribió:
>>> Chema Casanova writes:
>>>
El 20/07/18 a las 00:34, Francisco Jerez escribió:
> Chema Casanova writes:
>
>> El 14/07/18 a las 00:14, Francisco Jerez escribió:
>>> Jose Maria Casanova Crespo writes:
>>>
For a register source/destination of an instruction the function
returns
the read/write byte pattern of a 32-byte registers as a unsigned
int.
The returned pattern takes into account the exec_size of the
instruction,
the type bitsize, the stride and if the register is source or
destination.
The objective of the functions if to help to know the read/written
bytes
of the instructions to improve the liveness analysis for partial
read/writes.
We manage special cases for
SHADER_OPCODE_BYTE_SCATTERED_WRITE_LOGICAL
and SHADER_OPCODE_BYTE_SCATTERED_WRITE because depending of the
bitsize
parameter they have a different read pattern.
---
src/intel/compiler/brw_fs.cpp | 183
+
src/intel/compiler/brw_ir_fs.h | 1 +
2 files changed, 184 insertions(+)
diff --git a/src/intel/compiler/brw_fs.cpp
b/src/intel/compiler/brw_fs.cpp
index 2b8363ca362..f3045c4ff6c 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -687,6 +687,189 @@ fs_inst::is_partial_write() const
this->dst.offset % REG_SIZE != 0);
}
+/**
+ * Returns a 32-bit uint whose bits represent if the associated
register byte
+ * has been read/written by the instruction. The returned pattern
takes into
+ * account the exec_size of the instruction, the type bitsize and
the register
+ * stride and the register is source or destination for the
instruction.
+ *
+ * The objective of this function is to identify which parts of
the register
+ * are read or written for operations that don't read/write a
full register.
+ * So we can identify in live range variable analysis if a
partial write has
+ * completelly defined the part of the register used by a partial
read. So we
+ * avoid extending the liveness range because all data read was
already
+ * defined although the wasn't completely written.
+ */
+unsigned
+fs_inst::register_byte_use_pattern(const fs_reg , boolean
is_dst) const
+{
+ if (is_dst) {
>>
>>> Please split into two functions (like fs_inst::src_read and
>>> ::src_written) since that would make the call-sites of this method
>>> more
>>> self-documenting than a boolean parameter. You should be able to
>>> share
>>> code by refactoring the common logic into a separate function (see
>>> below
>>> for some suggestions on how that could be achieved).
>>
>> Sure, it would improve readability and simplifies the logic, I've
>> chosen
>> dst_write_pattern and src_read_pattern.
>>
>>>
+ /* We don't know what is written so we return the worts
case */
>>>
>>> "worst"
>>
>> Fixed.
>>
+ if (this->predicate && this->opcode != BRW_OPCODE_SEL)
+ return 0;
+ /* We assume that send destinations are completely written
*/
+ if (this->is_send_from_grf())
+ return ~0u;
>>>
>>> Some send-like instructions won't be caught by this condition, you
>>> should check for this->mlen != 0 in addition.
>>
>> Would it be enough to check for (this->mlen > 0) and forget about
>> is_send_from_grf? I am using this approach in v2 I am sending.
>>
>
> I don't think the mlen > 0 condition would catch all cases either...
> E.g. FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD IIRC. You probably need
> both
> conditions. Sucks...
That is
Re: [Mesa-dev] [PATCH] xf86drm: Fix error path in drmGetDevice2
I've reported this here:
https://bugs.freedesktop.org/show_bug.cgi?id=107384
The patch in the comments initializing drmDevicePtr device to NULL makes
it work properly for me.
I don't think the patch is on the mailing list yet. It's probably a good
idea to check if there are more places where this initialization needs
to be done...
On 29.07.2018 10:20, Mariusz Ceier wrote:
> In drmGetDevice2 when no local device is found or when
> drm_device_has_rdev filters out all devices, *device might be left
> uninitialized causing drmGetDevice2 to not return error - since
> it's only returned when *device == NULL.
>
> Above leads to crash in the firefox in system with amdgpu.
>
> With this change firefox displays:
>
> libGL error: MESA-LOADER: failed to retrieve device information
> libGL error: unable to load driver: amdgpu_dri.so
> libGL error: driver pointer missing
> libGL error: failed to load driver: amdgpu
> libGL error: MESA-LOADER: failed to retrieve device information
> libGL error: unable to load driver: amdgpu_dri.so
> libGL error: driver pointer missing
> libGL error: failed to load driver: amdgpu
>
> and doesn't crash.
>
> Signed-off-by: Mariusz Ceier
> ---
> xf86drm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 1e621e99..336d64de 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -3935,6 +3935,8 @@ int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr
> *device)
>
> drmFoldDuplicatedDevices(local_devices, node_count);
>
> +*device = NULL;
> +
> for (i = 0; i < node_count; i++) {
> if (!local_devices[i])
> continue;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/7] ASTC texture compression for all Gallium drivers
Am Donnerstag, den 26.07.2018, 14:30 -0400 schrieb Marek Olšák: > FYI, I'd like to include this in Mesa 18.2, which means I'll push > this on Monday July 30 if there is no review. I can't comment on the details of the decompression algoritm in patch 1, the rest looks good to me, so patches 2-7: Reviewed-By: Gert Wollny > > Marek > > On Mon, Jul 23, 2018 at 7:52 PM, Marek Olšák > wrote: > > Hi, > > > > This series enables ASTC texture compression for all Gallium > > drivers > > that don't support it in hardware. The works the same as the ETC2 > > fallback, i.e. it decompresses ASTC inside glCompressedTexImage to > > a supported uncompressed format. > > > > RadeonSI now finally supports the following: > > - GL_KHR_texture_compression_astc_ldr > > - GL_ANDROID_extension_pack_es31a > > - OpenGL ES 3.2 !!! > > > > All ASTC dEQP tests pass. > > > > Please review. > > > > Thanks, > > Marek > > ___ > 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] xf86drm: Fix error path in drmGetDevice2
In drmGetDevice2 when no local device is found or when
drm_device_has_rdev filters out all devices, *device might be left
uninitialized causing drmGetDevice2 to not return error - since
it's only returned when *device == NULL.
Above leads to crash in the firefox in system with amdgpu.
With this change firefox displays:
libGL error: MESA-LOADER: failed to retrieve device information
libGL error: unable to load driver: amdgpu_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: amdgpu
libGL error: MESA-LOADER: failed to retrieve device information
libGL error: unable to load driver: amdgpu_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: amdgpu
and doesn't crash.
Signed-off-by: Mariusz Ceier
---
xf86drm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index 1e621e99..336d64de 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3935,6 +3935,8 @@ int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr
*device)
drmFoldDuplicatedDevices(local_devices, node_count);
+*device = NULL;
+
for (i = 0; i < node_count; i++) {
if (!local_devices[i])
continue;
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 01/11] util/list: Make some helpers take const lists
Reviewed-by: Christian Gmeiner
Jason Ekstrand schrieb am So., 29. Juli 2018, 07:46:
> They're all just querying things about the list and not mutating
> anything.
>
> Reviewed-by: Thomas Helland
> ---
> src/util/list.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/util/list.h b/src/util/list.h
> index 6edb7501109..09d1b4cae64 100644
> --- a/src/util/list.h
> +++ b/src/util/list.h
> @@ -72,7 +72,7 @@ static inline void list_addtail(struct list_head *item,
> struct list_head *list)
> list->prev = item;
> }
>
> -static inline bool list_empty(struct list_head *list);
> +static inline bool list_empty(const struct list_head *list);
>
> static inline void list_replace(struct list_head *from, struct list_head
> *to)
> {
> @@ -101,7 +101,7 @@ static inline void list_delinit(struct list_head *item)
> item->prev = item;
> }
>
> -static inline bool list_empty(struct list_head *list)
> +static inline bool list_empty(const struct list_head *list)
> {
> return list->next == list;
> }
> @@ -114,7 +114,7 @@ static inline bool list_is_singular(const struct
> list_head *list)
> return list->next != NULL && list->next != list && list->next->next ==
> list;
> }
>
> -static inline unsigned list_length(struct list_head *list)
> +static inline unsigned list_length(const struct list_head *list)
> {
> struct list_head *node;
> unsigned length = 0;
> @@ -145,7 +145,7 @@ static inline void list_splicetail(struct list_head
> *src, struct list_head *dst)
> dst->prev = src->prev;
> }
>
> -static inline void list_validate(struct list_head *list)
> +static inline void list_validate(const struct list_head *list)
> {
> struct list_head *node;
> assert(list->next->prev == list && list->prev->next == list);
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
