Re: Intel clc dependency

[Timo Aaltonen]

Tapani Pälli kirjoitti 11.4.2024 klo 6.05:


On 11.4.2024 1.15, Brian Paul wrote:

On 4/10/24 13:53, Timo Aaltonen wrote:

Brian Paul kirjoitti 6.4.2024 klo 1.05:
I'm trying to build the Intel Vulkan driver.  First time in a few 
months.  I'm having build problems related to clc.  I'm on Ubuntu 22.04



[...]
[1347/3181] Generating src/intel/vulkan/...om command (wrapped by 
meson to set env)
FAILED: 
src/intel/vulkan/grl/gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable.h
env MESA_SHADER_CACHE_DISABLE=true MESA_SPIRV_LOG_LEVEL=error 
/home/brianp/build3/mesa/build/src/intel/compiler/intel_clc -p dg2 
--prefix gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable -e 
BFS_pass1_indexed_batchable --in 
../src/intel/vulkan/grl/gpu/bvh_build_BFS.cl --in 
/home/brianp/build3/mesa/src/intel/vulkan/grl/gpu/libs/lsc_intrinsics_fallback.cl -o src/intel/vulkan/grl/gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable.h -- -cl-std=cl2.0 -D__OPENCL_VERSION__=200 -DMAX_HW_SIMD_WIDTH=16 -DMAX_WORKGROUP_SIZE=16 -I/home/brianp/build3/mesa/src/intel/vulkan/grl/gpu -I/home/brianp/build3/mesa/src/intel/vulkan/grl/include

ERROR: libclc shader missing. Consider installing the libclc package
Aborted (core dumped)

I've installed every clc-related package I could find.  I've tried 
several options for the 'intel-clc' option without luck.


BTW, the description of intel-clc in meson_options.txt looks suspect:

option(
   'intel-clc',
   type : 'combo',
   deprecated: {'true': 'enabled', 'false': 'disabled'},
   value : 'disabled',
   choices : [
 'enabled', 'disabled', 'system',
   ],
   description : 'Build the intel-clc compiler (enables Vulkan Intel 
' +

 'Ray Tracing on supported hardware).'
)

The default is 'disabled' but that's deprecated?  Choices include 
'enabled' but that's deprecated too?


Any tips for building the ToT Intel Vulkan driver?

-Brian



You need to have libclc-NN-dev installed matching with the llvm 
version, which on stock 22.04 would be libclc-13-dev.


I'm using llvm 15 and have libclc-15-dev installed.  I get the "ERROR: 
libclc shader missing. Consider installing the libclc package" issue I 
quoted above.




You'll need to install libclc-15 too. I think libclc-15-dev package is 
missing dependency to libclc-15 .. did not verify this but I've been 
able to install libclc-15-dev without the library package getting 
installed.


huh.. I'll poke the maintainer to fix that


--
t

Re: Intel clc dependency

[Timo Aaltonen]

Brian Paul kirjoitti 6.4.2024 klo 1.05:
I'm trying to build the Intel Vulkan driver.  First time in a few 
months.  I'm having build problems related to clc.  I'm on Ubuntu 22.04



[...]
[1347/3181] Generating src/intel/vulkan/...om command (wrapped by meson 
to set env)
FAILED: 
src/intel/vulkan/grl/gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable.h
env MESA_SHADER_CACHE_DISABLE=true MESA_SPIRV_LOG_LEVEL=error 
/home/brianp/build3/mesa/build/src/intel/compiler/intel_clc -p dg2 
--prefix gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable -e 
BFS_pass1_indexed_batchable --in 
../src/intel/vulkan/grl/gpu/bvh_build_BFS.cl --in 
/home/brianp/build3/mesa/src/intel/vulkan/grl/gpu/libs/lsc_intrinsics_fallback.cl -o src/intel/vulkan/grl/gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable.h -- -cl-std=cl2.0 -D__OPENCL_VERSION__=200 -DMAX_HW_SIMD_WIDTH=16 -DMAX_WORKGROUP_SIZE=16 -I/home/brianp/build3/mesa/src/intel/vulkan/grl/gpu -I/home/brianp/build3/mesa/src/intel/vulkan/grl/include

ERROR: libclc shader missing. Consider installing the libclc package
Aborted (core dumped)

I've installed every clc-related package I could find.  I've tried 
several options for the 'intel-clc' option without luck.


BTW, the description of intel-clc in meson_options.txt looks suspect:

option(
   'intel-clc',
   type : 'combo',
   deprecated: {'true': 'enabled', 'false': 'disabled'},
   value : 'disabled',
   choices : [
     'enabled', 'disabled', 'system',
   ],
   description : 'Build the intel-clc compiler (enables Vulkan Intel ' +
     'Ray Tracing on supported hardware).'
)

The default is 'disabled' but that's deprecated?  Choices include 
'enabled' but that's deprecated too?


Any tips for building the ToT Intel Vulkan driver?

-Brian



You need to have libclc-NN-dev installed matching with the llvm version, 
which on stock 22.04 would be libclc-13-dev.


--
t

Re: [ANNOUNCE] mesa 22.2.0-rc3

[Timo Aaltonen]

Hi, it's been a month without a new rc, when do we get one?


Dylan Baker kirjoitti 18.8.2022 klo 21.47:

Hi list,

I didn't get this out yesterday, but here's mesa 22.2.0-rc3. We've got a
huge number of fixes for turnip, a good number of fixes for
gallium/nine, as well as a bit of this and that.

Cheers,
Dylan

shortlog


Axel Davy (6):
   frontend/nine: Skip invalid swvp calls
   frontend/nine: Fix buffer tracking out of bounds
   frontend/nine: Fix ATOC handling
   frontend/nine: Fix cso restore bug
   frontend/nine: Fix shader multi-use crash
   frontend/nine: Fix ff position_t fallback when w = 0

Charmaine Lee (1):
   mesa/st: fix reference to nir->info after nir_to_tgsi

Chia-I Wu (26):
   turnip: add tu_common.h as the common header
   turnip: remove includes that are already in tu_common.h
   turnip: add tu_drm.h
   turnip: add tu_suballoc.h
   turnip: update tu_cs.h
   turnip: add tu_query.h
   turnip: add tu_image.h
   turnip: add tu_formats.h
   turnip: update tu_descriptor_set.h
   turnip: add tu_shader.h
   turnip: add tu_pipeline.h
   turnip: add tu_clear_blit.h
   turnip: add tu_dynamic_rendering.h
   turnip: add tu_lrz.h
   turnip: add tu_pass.h
   turnip: add tu_wsi.h
   turnip: update tu_autotune.h
   turnip: add tu_device.h
   turnip: add tu_cmd_buffer.h
   turnip: add tu_android.h
   turnip: update tu_util.h
   turnip: move away from tu_private.h
   turnip: remove tu_private.h
   turnip: remove headers from libtu_files
   turnip: use SPDX-License-Identifier
   turnip: fix a use-after-free in autotune

Dylan Baker (5):
   .pick_status.json: Update to a3bf0da1cbd4b10043c80bf44609a3024b5fcc36
   .pick_status.json: Update to 24b9ad7cd5ebc7cfa5d03cf0f243ea4841c971b9
   .pick_status.json: Update to 74fc367127ccf945f4c649dd6ddff955c802e36e
   .pick_status.json: Mark 11ab6087797f805cf158048915c67945613c9a72 as 
denominated
   VERSION: bump to 22.2.0-rc3

Eric Engestrom (1):
   vk/device-select-layer: fix .sType of VkPhysicalDeviceGroupProperties

Jesse Natalie (2):
   egl/wgl: Delete unused variables/code
   egl/wgl: Fix some awkward sizeof formatting

Konstantin Seurer (1):
   radv: Fix stack size calculation with stage ids

Lionel Landwerlin (1):
   anv: don't return incorrect error code for vkCreateDescriptorPool

Liviu Prodea (1):
   meson: Microsoft / maybe Intel CLC need the all-targets workaround just 
like clover

Marek Olšák (2):
   glthread: unbind framebuffers in glDeleteFramebuffers
   glthread: call _mesa_glthread_DeleteBuffers unconditionally

Mike Blumenkrantz (4):
   radv: fix return type for meta resolve shaders
   nir/validate: clamp unsized tex dests to 32bit
   mesa: fix blending when using luminance/intensity emulation
   mesa: require render target bind for A/L/I in format selection

Pavel Ondračka (1):
   r300: fix variables detection for paired ALU and TEX instructions in 
different branches

Qiang Yu (1):
   nir/lower_gs_intrinsics: fix primitive count for points

Samuel Pitoiset (1):
   radv: fix cleaning the meta query state if an error occured

Yonggang Luo (2):
   microsoft/clc: Fixes compiling errors with clang/mingw64 in 
clc/clc_compiler_test.cpp
   util: Fixes invalid assumption that return non null by function 
util_format_fetch_rgba_func

sjfricke (1):
   isl: fix bug where sb.MOCS is not being set



git tag: mesa-22.2.0-rc3

https://archive.mesa3d.org/mesa-22.2.0-rc3.tar.xz
SHA256: db392307a02f97b7a8237809e28b627306356a2b27bb911bf9f4344b66313e39  
mesa-22.2.0-rc3.tar.xz
SHA512: 
e026904fbc046575d58c5458e2d94d201cbb015eaf5e900eefbc237f45ebd0e6afb46b4d74b0c9b864911e174a1729707e9f85fea54996ba87499b33c4c96836
  mesa-22.2.0-rc3.tar.xz
PGP: https://archive.mesa3d.org/mesa-22.2.0-rc3.tar.xz.sig


--
t

Re: Amber branch plan

[Timo Aaltonen]

Dylan Baker kirjoitti 7.12.2021 klo 1.51:

Since classic is gone,  I thought I'd lay out my thinking for Amber.

I'm assuming that we'll branch Amber from the 21.3 branch, after that
reaches normal EOL. That gives us the benefit of developing on top of a
known good state for classic drivers, and should minimize friction for
distros dealing with classic. If anyone wants to backport changes from
main to amber they can obviously do so.

Are there any objections to that plan?

Dylan


Is there going to be a separate tarball release of Amber?


--
t

Re: [Mesa-dev] [ANNOUNCE] mesa 21.2.1

[Timo Aaltonen]

On 19.8.2021 20.06, Dylan Baker wrote:

Hi list,

I'd like to announce the availability of Mesa 21.2.1. This is the first
bug fix release in the mesa 21.2 series. This is a day late, as I was
tracking down some CI failures, which turned out to be fixed tests that
just needed aditional backports for CI.

There's a bunch of stuff here, with fossilize_db being the majority of
it. The rest of the fixes are all over the tree, with nice changes for
almost everyone.

This has been another nice, tidy release, and I'll see you again in two
weeks with 21.2.2


Hi,

It's been nearly four weeks now, when can we expect a new release?


--
t

Re: [Mesa-dev] [ANNOUNCE] mesa 21.0.3

[Timo Aaltonen]

On 21.4.2021 21.25, Dylan Baker wrote:

Hi list,

Mesa 21.0.3 is now available. This features quite a few backports done
by helpful mesa devlopers, so a big thank you to all of them. We've got
a bunch of stuff here, from haiku, to core mesa, radeonsi, lavapipe,
nir, radv, anv, freedreno and turnip, etniviv, iris, egl, lima, core
gallium stuff, spriv, v3d, lots of microsoft stuff, and even meson
fixes.

Cheers,
Dylan


Hi, it's been almost seven weeks since this release, is 21.0.x already 
dead or will we see a .4 to finish it?




--
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [ANNOUNCE] Mesa 18.3.3 release candidate

[Timo Aaltonen]

On 1.2.2019 13.08, Emil Velikov wrote:
> Hi Carsten,
> 
> On 2019/01/31, Carsten Haitzler wrote:
>> On Wed, 30 Jan 2019 18:33:35 + Emil Velikov  
>> said:
>>
>> You might want to hold off on this. My bugfix was actually patched out by 
>> partly
>> removing some of it. The void ptr math should never have been there and 
>> wasn't
>> in the final patch.
>>
>> I'm talking about:
>>
>> +void *cpu2 = cpu + 8;
>>
>> In 300d3ae8b1445b5060f92c77c0f577f4b7b2c7d6
>>
>> At least with gcc8 mesa is a dud on Raspberry Pi (can't upload/downlaod
>> textures without crashing) without the fixes. I moved the secondary ptr math
>> into the ASM chunk because the C compiler seemed to just mess up cpu2 ptr
>> content/value for me on gcc8 (it also kept the parameter inputs/outputs 
>> cleaner
>> and consistent with other ASM chunks). Keeping this as void ptr math alone is
>> just wrong and asking for trouble and as it unfixed a fix I already had in
>> submitted patches.
>>
>> Being at FOSDEM I now no longer have access to my OS image with all of this 
>> set
>> up to test and won't until next week. I can't dig in and verify. Without my
>> fixes at all it's a dead man walking with gcc8, and thus Arch Linux is broken
>> entirely on Rpi without it (and has been for a while now).
>>
> If I understand this correctly, during the rework (by Eric I assume) some of
> your fixes got invalidated. Yet the current code and binaries produced are
> not worse off then before the patches.
> 
> Thus from stable POV, we're safe, since nothing has regressed per se. We will
> apply the extra patches for the next release.

The new vc4 patches broke build on armhf:

In file included from ../src/gallium/drivers/vc4/vc4_tiling_lt_neon.c:30:
../src/gallium/drivers/vc4/vc4_tiling_lt.c: In function ‘vc4_store_utile’:
../src/gallium/drivers/vc4/vc4_tiling_lt.c:200:25: error: output operand 
constraint lacks ‘=’
 : "q0", "q1", "q2", "q3");
 ^
../src/gallium/drivers/vc4/vc4_tiling_lt.c:181:17: error: output operand 
constraint lacks ‘=’
 __asm__ volatile (
 ^~~
../src/gallium/drivers/vc4/vc4_tiling_lt.c:181:17: error: invalid lvalue in asm 
output 0


the full log is at
https://buildd.debian.org/status/fetch.php?pkg=mesa=armhf=18.3.3-1=1549529258=0


-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/5] Fixueps for ppc64 and gnu hurd

[Timo Aaltonen]

On 18.12.2018 7.52, Stuart Young wrote:
> Hi Dylan,
> 
> Can't speak on Timo's behalf, but looking at the build logs for 18.3.0
> (which is patched with these patches), it built fine on ppc64el (Little
> Endian PPC64), but hurd is having issues, tho it looks like it's not
> directly related to the patch you provided.

Yes, sorry about the delay.. the patches work, Hurd failure is not
related to meson anymore..

> Seems like the issue is that hurd is falling through the tests in
> src/util/os_misc.c: In function ‘os_get_total_physical_memory’
> 
> ...and ends up bailing out with:
> 
> src/util/os_misc.c:173:2: error: #error unexpected platform in os_sysinfo.c

..but that this was not built on Hurd before 18.3, so needs support for
it there.


-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/5] Fixueps for ppc64 and gnu hurd

[Timo Aaltonen]

On 4.12.2018 23.52, Dylan Baker wrote:
> This little series is aimed at fixing problems reported by fedora and debian
> when using meson, there's a couple of patches in here for fixing ppc64 
> detection
> (tested without llvm), and a couple for gnu hurd (not tested).
> 
> Dylan Baker (5):
>   meson: remove duplicate definition
>   meson: Fix ppc64 little endian detection
>   meson: Override C++ standard to gnu++11 when building with altivec on
> ppc64le
>   meson: Add support for gnu hurd
>   meson: Add toggle for glx-direct
> 
>  meson.build   | 33 ---
>  meson_options.txt |  6 
>  src/gallium/state_trackers/clover/meson.build |  3 ++
>  3 files changed, 31 insertions(+), 11 deletions(-)
> 

Thanks, I'll give these a try soon.

-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Timo Aaltonen]

On 3.12.2018 20.54, Dylan Baker wrote:
> Quoting Timo Aaltonen (2018-12-03 10:36:12)
>> On 3.12.2018 20.25, Emil Velikov wrote:
>>> On Mon, 3 Dec 2018 at 17:49, Dylan Baker  wrote:
>>>>
>>>> Quoting Emil Velikov (2018-12-03 07:54:38)
>>>>> Hi all,
>>>>>
>>>>> On Thu, 29 Nov 2018 at 17:44, Emil Velikov  
>>>>> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I can see why people may opt to not use or maintain the autotools build.
>>>>>> Although I would kindly ask that we do not remove it just yet.
>>>>>>
>>>>>> In Mesa, we have different parts not used by different teams. As such
>>>>>> we tend to remove stuff when nobody is around to maintain it anymore.
>>>>>>
>>>>>> That said, I'm planning to continue maintaining it and would appreciate
>>>>>> if we keep it in-tree.
>>>>>>
>>>>>> As people may be concerned about bugreports and alike we can trivially
>>>>>> add a warning (as configure is invoked) to forwards any issues to my
>>>>>> email. Additionally (or alternatively) we can have an autotools bugzilla
>>>>>> category with me as the default assignee.
>>>>>>
>>>>>
>>>>> Seems like I failed to make things clear enough with earlier message.
>>>>>
>>>>> There is _no_ expectation for anyone to touch or even look at autotools.
>>>>> Hence, my suggestion to have configure.ac point people to me in case of 
>>>>> issues.
>>>>>
>>>>> If people have CI that uses it - feel free to drop it.
>>>>>
>>>>
>>>> I've tried to stay out of this discussion, because everyone knows my 
>>>> opinion,
>>>> and I feel I don't have much to add, however...
>>>>
>>>>>
>>>>> That said, many have asked why I'd go through the pain of maintaining it:
>>>>>  - Most Linux distributions have switched, but there'still a few 
>>>>> outstanding
>>>>>  - Non Linux distributions have not switched
>>>>
>>>> Haiku has at least :)
>>>>
>>> \o/
>>
>> And Debian too (in experimental). Ubuntu will follow once the final is
>> out and it build everywhere. There's a build failure on ppc64el, btw:
>>
>> https://buildd.debian.org/status/fetch.php?pkg=mesa=ppc64el=18.3.0%7Erc5-1=1543575640=0
>>
>>>>>  - The meson build is missing features, relative the autotools one
>>>>
>>>> The only feature that I know that meson does not have relative to 
>>>> autotools is
>>>> the gl mangling stuff (which is intentional, we'll add it if someone shows 
>>>> up
>>>> with a need for it). Everything else is either intentionally not 
>>>> implemented
>>>> (GLX TLS toggling for example, which meson hardcodes on for OSes that 
>>>> support
>>>> it, and off for those that don't).
>>>>
>>> On top of the TLS and symbol mangling (for which I agree) there is:
>>>  - disable direct glx - non linux people use this
>>
>> This seems to work, at least on Hurd:
>>
>> diff --git a/meson.build b/meson.build
>> index 33f4e5ad3cf..90cc0bb3af2 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -53,6 +53,7 @@ with_tests = get_option('build-tests')
>>  with_valgrind = get_option('valgrind')
>>  with_libunwind = get_option('libunwind')
>>  with_asm = get_option('asm')
>> +with_glx_direct= get_option('glx-direct')
>>  with_glx_read_only_text = get_option('glx-read-only-text')
>>  with_osmesa = get_option('osmesa')
>>  with_swr_arches = get_option('swr-arches')
>> @@ -370,9 +371,6 @@ if with_glvnd
>>endif
>>  endif
>>
>> -# TODO: toggle for this
>> -with_glx_direct = true
>> -
>>  if with_vulkan_icd_dir == ''
>>with_vulkan_icd_dir = join_paths(get_option('datadir'), 'vulkan/icd.d')
>>  endif
>> diff --git a/meson_options.txt b/meson_options.txt
>> index a1d5ab0e185..4d5f36bf33d 100644
>> --- a/meson_options.txt
>> +++ b/meson_options.txt
>> @@ -205,6 +205,12 @@ option(
>>choices : ['auto', 'disabled', 'dri', 'xlib', 'gallium-xlib'],
>>description : 'Build support for GLX platform'
>>  )
>> +option(
>> +  'glx-direct',
>> +  type : 'boolean',
>> +  value : 'true',
>> +  description : 'Enable direct rendering in GLX and EGL for DRI'
>> +)
>>  option(
>>'egl',
>>type : 'combo',
>>
>>
> 
> I'm glad that this actually worked :) I tried to wire up direct glx so adding 
> a
> toggle would be easy if we needed it. Do you need this for Hurd Timo?

Yep, it also needs -D_GNU_SOURCE which hopefully is fixed by this:

--- a/meson.build
+++ b/meson.build
@@ -779,7 +779,7 @@ if cc.compiles('int foo(void) __attribut
 endif
 
 # TODO: this is very incomplete
-if ['linux', 'cygwin'].contains(host_machine.system())
+if ['linux', 'linux-gnu', 'cygwin', 'gnu'].contains(host_machine.system())
   pre_args += '-D_GNU_SOURCE'
 endif

(to match configure.ac) 

And that ppc64el build fail might be because it for some reason doesn't seem to 
get -DUSE_PPC64LE_ASM..



-- 
t



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Timo Aaltonen]

On 3.12.2018 20.25, Emil Velikov wrote:
> On Mon, 3 Dec 2018 at 17:49, Dylan Baker  wrote:
>>
>> Quoting Emil Velikov (2018-12-03 07:54:38)
>>> Hi all,
>>>
>>> On Thu, 29 Nov 2018 at 17:44, Emil Velikov  wrote:

 Hi all,

 I can see why people may opt to not use or maintain the autotools build.
 Although I would kindly ask that we do not remove it just yet.

 In Mesa, we have different parts not used by different teams. As such
 we tend to remove stuff when nobody is around to maintain it anymore.

 That said, I'm planning to continue maintaining it and would appreciate
 if we keep it in-tree.

 As people may be concerned about bugreports and alike we can trivially
 add a warning (as configure is invoked) to forwards any issues to my
 email. Additionally (or alternatively) we can have an autotools bugzilla
 category with me as the default assignee.

>>>
>>> Seems like I failed to make things clear enough with earlier message.
>>>
>>> There is _no_ expectation for anyone to touch or even look at autotools.
>>> Hence, my suggestion to have configure.ac point people to me in case of 
>>> issues.
>>>
>>> If people have CI that uses it - feel free to drop it.
>>>
>>
>> I've tried to stay out of this discussion, because everyone knows my opinion,
>> and I feel I don't have much to add, however...
>>
>>>
>>> That said, many have asked why I'd go through the pain of maintaining it:
>>>  - Most Linux distributions have switched, but there'still a few outstanding
>>>  - Non Linux distributions have not switched
>>
>> Haiku has at least :)
>>
> \o/

And Debian too (in experimental). Ubuntu will follow once the final is
out and it build everywhere. There's a build failure on ppc64el, btw:

https://buildd.debian.org/status/fetch.php?pkg=mesa=ppc64el=18.3.0%7Erc5-1=1543575640=0

>>>  - The meson build is missing features, relative the autotools one
>>
>> The only feature that I know that meson does not have relative to autotools 
>> is
>> the gl mangling stuff (which is intentional, we'll add it if someone shows up
>> with a need for it). Everything else is either intentionally not implemented
>> (GLX TLS toggling for example, which meson hardcodes on for OSes that support
>> it, and off for those that don't).
>>
> On top of the TLS and symbol mangling (for which I agree) there is:
>  - disable direct glx - non linux people use this

This seems to work, at least on Hurd:

diff --git a/meson.build b/meson.build
index 33f4e5ad3cf..90cc0bb3af2 100644
--- a/meson.build
+++ b/meson.build
@@ -53,6 +53,7 @@ with_tests = get_option('build-tests')
 with_valgrind = get_option('valgrind')
 with_libunwind = get_option('libunwind')
 with_asm = get_option('asm')
+with_glx_direct= get_option('glx-direct')
 with_glx_read_only_text = get_option('glx-read-only-text')
 with_osmesa = get_option('osmesa')
 with_swr_arches = get_option('swr-arches')
@@ -370,9 +371,6 @@ if with_glvnd
   endif
 endif

-# TODO: toggle for this
-with_glx_direct = true
-
 if with_vulkan_icd_dir == ''
   with_vulkan_icd_dir = join_paths(get_option('datadir'), 'vulkan/icd.d')
 endif
diff --git a/meson_options.txt b/meson_options.txt
index a1d5ab0e185..4d5f36bf33d 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -205,6 +205,12 @@ option(
   choices : ['auto', 'disabled', 'dri', 'xlib', 'gallium-xlib'],
   description : 'Build support for GLX platform'
 )
+option(
+  'glx-direct',
+  type : 'boolean',
+  value : 'true',
+  description : 'Enable direct rendering in GLX and EGL for DRI'
+)
 option(
   'egl',
   type : 'combo',


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Timo Aaltonen]

On 29.11.2018 20.22, Matt Turner wrote:
> On Thu, Nov 29, 2018 at 9:47 AM Emil Velikov  wrote:
>> In Mesa, we have different parts not used by different teams. As such
>> we tend to remove stuff when nobody is around to maintain it anymore.
> 
> We drop things for that reason, but also when something is no longer
> needed. I don't think autotools is needed. As far as I know all
> distributions have switched to Meson quite some time ago. I just
> removed the last version of Mesa from Gentoo that we were still
> building with autotools.

FTR, I converted the Debian Mesa packaging to Meson today, and realized
that the feature in the upcoming Meson is not needed at all by the
packaging (it can find llvm-config-N.N just fine..). So I'm fine with
removing autotools support :)


-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Timo Aaltonen]

On 27.11.2018 19.42, Eero Tamminen wrote:
> Hi,
> 
> On 27.11.2018 19.05, Matt Turner wrote:
>> On Tue, Nov 27, 2018 at 1:13 AM Timo Aaltonen 
>> wrote:
>>> On 17.11.2018 6.04, Dylan Baker wrote:
>>>> Quoting Dylan Baker (2018-09-17 09:44:07)
>>>>> I feel like for !windows meson is in good enough shape at this
>>>>> point that we
>>>>> can start having the discussion about deleting the autotools build.
>>>>> So, is there
>>>>> anything left that autotools can do that meson cannot (that we
>>>>> actually want to
>>>>> implement)? And, what is a reasonable time-table to remove the
>>>>> autotools build?
>>>>> I think we could reasonably remove it as soon as 18.3 if others
>>>>> felt confident
>>>>> that it would work for them.
>>>>
>>>> Okay, time for an update on things and a chance to talk about what
>>>> else we need.
>>>>
>>>> Support for llvm-config (and any binary, actually) overriding has
>>>> landed in
>>>> meson, and will be present in the 0.49.0 release, which is due out
>>>> December 9th.
>>>
>>> Hi, just a note that Ubuntu 18.04 LTS ships with meson 0.45.1 and will
>>> get Mesa backports up until and including 20.0.x, so I wonder how
>>> complex these required new features in meson are to be backported, or
>>> perhaps easily worked around? Backporting a whole new version of meson
>>> might not happen..
>>
>> I understand the LTS concept, but what's the value in never upgrading
>> something like a build tool like Meson? Yeah, new versions give a
>> possibility of regressions, but with something evolving as quickly as
>> Meson the version available in April 2018 becomes less useful for its
>> intended purpose with each passing month...
> 
> Ubuntu has so called hardware enabling (HWE) packages, which provide
> newer versions of kernel, mesa and few other components for LTS, and
> a meta package(s) that pull those in. They're based on package versions
> tested in development versions of Ubuntu.
> 
> For example, relevant Ubuntu 18.10 packages would be available as
> HWE packages for 18.04 somewhere around February, according to
> preliminary Ubuntu kernel schedule.
> 
> Of the packages relevant to Mesa, 18.10 has for example:
> - kernel v4.18   (18.04 has v4.15)
> - LLVM v7.0  (18.04 has LLVM v6)
> - Meson v0.47.2  (18.04 has v0.45)
> 
> I don't know how much that 4 month gap (before new development
> distro release package versions become available in preceding LTS
> release as HW packages) fluctuates.

The backports are being prepared now, bionic-proposed has everything
needed by mesa 18.2.2 (last of the 18.2.x series will be provided
later), xserver and drivers will follow soon. 18.04.2 image will be out
in February '19, but having these in -proposed means the daily image
will use them and gives plenty of time for testing (over the holidays, heh).

Meson is not on the list of HWE backports, but as I said, it could be
backported as a separate source package for mesa to build-depend on if
necessary.


-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Timo Aaltonen]

On 27.11.2018 19.05, Matt Turner wrote:
> On Tue, Nov 27, 2018 at 1:13 AM Timo Aaltonen  wrote:
>>
>> On 17.11.2018 6.04, Dylan Baker wrote:
>>> Quoting Dylan Baker (2018-09-17 09:44:07)
>>>> I feel like for !windows meson is in good enough shape at this point that 
>>>> we
>>>> can start having the discussion about deleting the autotools build. So, is 
>>>> there
>>>> anything left that autotools can do that meson cannot (that we actually 
>>>> want to
>>>> implement)? And, what is a reasonable time-table to remove the autotools 
>>>> build?
>>>> I think we could reasonably remove it as soon as 18.3 if others felt 
>>>> confident
>>>> that it would work for them.
>>>>
>>>> Dylan
>>>
>>> Okay, time for an update on things and a chance to talk about what else we 
>>> need.
>>>
>>> Support for llvm-config (and any binary, actually) overriding has landed in
>>> meson, and will be present in the 0.49.0 release, which is due out December 
>>> 9th.
>>
>> Hi, just a note that Ubuntu 18.04 LTS ships with meson 0.45.1 and will
>> get Mesa backports up until and including 20.0.x, so I wonder how
>> complex these required new features in meson are to be backported, or
>> perhaps easily worked around? Backporting a whole new version of meson
>> might not happen..
> 
> I understand the LTS concept, but what's the value in never upgrading
> something like a build tool like Meson? Yeah, new versions give a
> possibility of regressions, but with something evolving as quickly as
> Meson the version available in April 2018 becomes less useful for its
> intended purpose with each passing month...

Fair enough, I'll just package a newer, renamed meson for mesa if necessary.


-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Timo Aaltonen]

On 27.11.2018 12.20, Erik Faye-Lund wrote:
> On Tue, 2018-11-27 at 11:13 +0200, Timo Aaltonen wrote:
>> On 17.11.2018 6.04, Dylan Baker wrote:
>>> Quoting Dylan Baker (2018-09-17 09:44:07)
>>>> I feel like for !windows meson is in good enough shape at this
>>>> point that we
>>>> can start having the discussion about deleting the autotools
>>>> build. So, is there
>>>> anything left that autotools can do that meson cannot (that we
>>>> actually want to
>>>> implement)? And, what is a reasonable time-table to remove the
>>>> autotools build?
>>>> I think we could reasonably remove it as soon as 18.3 if others
>>>> felt confident
>>>> that it would work for them.
>>>>
>>>> Dylan
>>>
>>> Okay, time for an update on things and a chance to talk about what
>>> else we need.
>>>
>>> Support for llvm-config (and any binary, actually) overriding has
>>> landed in
>>> meson, and will be present in the 0.49.0 release, which is due out
>>> December 9th.
>>
>> Hi, just a note that Ubuntu 18.04 LTS ships with meson 0.45.1 and
>> will
>> get Mesa backports up until and including 20.0.x, so I wonder how
>> complex these required new features in meson are to be backported, or
>> perhaps easily worked around? Backporting a whole new version of
>> meson
>> might not happen..
>>
> 
> I don't know if this is acceptable or not for packaging, but one could
> always install meson from pip, I would assume...

Nope, network resources aren't available (nor allowed) when building for
the distro.


-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Timo Aaltonen]

On 17.11.2018 6.04, Dylan Baker wrote:
> Quoting Dylan Baker (2018-09-17 09:44:07)
>> I feel like for !windows meson is in good enough shape at this point that we
>> can start having the discussion about deleting the autotools build. So, is 
>> there
>> anything left that autotools can do that meson cannot (that we actually want 
>> to
>> implement)? And, what is a reasonable time-table to remove the autotools 
>> build?
>> I think we could reasonably remove it as soon as 18.3 if others felt 
>> confident
>> that it would work for them.
>>
>> Dylan
> 
> Okay, time for an update on things and a chance to talk about what else we 
> need.
> 
> Support for llvm-config (and any binary, actually) overriding has landed in
> meson, and will be present in the 0.49.0 release, which is due out December 
> 9th.

Hi, just a note that Ubuntu 18.04 LTS ships with meson 0.45.1 and will
get Mesa backports up until and including 20.0.x, so I wonder how
complex these required new features in meson are to be backported, or
perhaps easily worked around? Backporting a whole new version of meson
might not happen..



-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] loader_dri3/glx/egl: Reinstate the loader_dri3_vtable get_dri_screen callback

[Timo Aaltonen]

Thomas Hellstrom kirjoitti 09.02.2018 klo 10:37:
> Removing this callback caused rendering corruption in some multi-screen cases,
> so it is reinstated but without the drawable argument which was never used
> by implementations and was confusing since the drawable could have been
> created with another screen.
> 
> Cc: "17.3" mesa-sta...@lists.freedesktop.org
> Fixes: 5198e48a0d (loader_dri3/glx/egl: Remove the loader_dri3_vtable 
> get_dri_screen callback)
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105013
> Reported-by: Daniel van Vugt <daniel.van.v...@canonical.com>
> Signed-off-by: Thomas Hellstrom <thellst...@vmware.com>

Tested-by: Timo Aaltonen <tjaal...@ubuntu.com>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Disable L3 cache allocation for external buffers

[Timo Aaltonen]

On 24.10.2017 19:06, Chris Wilson wrote:
> Through the use of mocs, we can define the cache usage for any surface
> used by the GPU. In particular, we can request that L3 cache be
> allocated for either a read/write miss so that subsequent reads can be
> fetched from cache rather than memory. A consequence of this is that if
> we allocate a L3/LLC cacheline for a read and the object is changed in
> main memory (e.g. a PCIe write bypassing the CPU) then the next read
> will be serviced from the stale cache and not from the new data in
> memory. This is an issue for external PRIME buffers where we may miss
> the updates entirely if the image is small enough to fit within our
> cache.
> 
> Currently, we have a single bit to mark all external buffers so use that
> to tell us when it is unsafe to use a cache override in mocs and
> fallback to the PTE value instead (which should be set to the correct
> cache level to be coherent amongst all active parties: PRIME, scanout and
> render). This may be refined in future to limit the override to buffers
> outside the control of mesa; as buffers being shared between mesa
> clients should be able to coordinate themselves without resolves.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101691
> Cc: Kenneth Graunke 
> Cc: Jason Ekstrand 
> Cc: Lyude Paul 
> Cc: Timo Aalton 
> Cc: Ben Widawsky 
> Cc: Daniel Vetter 

This did not pass our testing, though I backported it to 17.2. Should
that matter?


-- 
t

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] fixup! EGL: Implement the libglvnd interface for EGL (v2)

[Timo Aaltonen]

On 17.01.2017 18:31, Kyle Brenneman wrote:
> On 01/16/2017 02:32 PM, Adam Jackson wrote:
>> On Thu, 2017-01-05 at 14:29 -0700, Kyle Brenneman wrote:
>>> ---
>>>   src/egl/generate/eglFunctionList.py | 6 --
>>>   1 file changed, 4 insertions(+), 2 deletions(-)
>> Reviewed-by: Adam Jackson <a...@redhat.com>
>>
>> Is this too invasive for 13.1?
>>
>> - ajax
>>
> If it helps, almost all of the libglvnd code just sits on top of the
> existing EGL library, and a non-libglvnd build doesn't even compile it.
> Other than the makefile, the only change that would affect a
> non-libglvnd build is for the client extension string in eglQueryString.

Ping? Surely these can land in master by now? Fedora ships them, and
they work fine on Debian too, so:

Tested-by: Timo Aaltonen <tjaal...@ubuntu.com>


-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [ANNOUNCE] mesa 12.0.5

[Timo Aaltonen]

On 13.01.2017 07:40, Emil Velikov wrote:
> On 12 January 2017 at 10:29, Timo Aaltonen <tjaal...@ubuntu.com> wrote:
>> On 11.01.2017 15:01, Emil Velikov wrote:
>>> On 6 December 2016 at 14:55, Marek Olšák <mar...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I'd like to announce that this release doesn't fix the worst GPU
>>>> hangs/freezes it has. I'm talking about all Gallium drivers here.
>>>> There was a bug recently discovered in shared code that leads to
>>>> random GPU hangs with radeonsi, but all other Gallium drivers are also
>>>> affected in "some negative way", which may include freezes. The fix
>>>> was available prior to 12.0.5, but wasn't applied due to a process
>>>> issue.
>>>>
>>>> It is still the best 12.0.x release, but users and distributions
>>>> wanting better stability for non-Intel drivers should wait for 12.0.6.
>>>>
>>> As some of you may know, I've mentioned that 12.0.6 will be available
>>> if we get at least a few developers/teams behind it.
>>>
>>> Since then people have contacted me, on and off list, speaking
>>> positively about having 12.0.6. As such there I'll be rolling the
>>> release.
>>> Not to mention that Michel went the extra mile with improved/extra
>>> patches on the topic/issue mentioned by Marek.
>>>
>>> Thank for the feedback everyone !
>>> Emil
>>
>> Is there a public branch with the proposed commits? mesa/12.0 hasn't
>> been touched since previous release. I'd need the release or a
>> preliminary branch ASAP for ubuntu..
>>
> A preliminary one, tested only locally:
> https://github.com/evelikov/Mesa/commits/mesa_12/jenkins
> 
> A proper one, alongside a summary email will follow shortly - as the
> test results arrive.

Great, thanks! Any reason mesa/12.0 can't be kept in sync with this?


-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [ANNOUNCE] mesa 12.0.5

[Timo Aaltonen]

On 11.01.2017 15:01, Emil Velikov wrote:
> On 6 December 2016 at 14:55, Marek Olšák  wrote:
>> Hi,
>>
>> I'd like to announce that this release doesn't fix the worst GPU
>> hangs/freezes it has. I'm talking about all Gallium drivers here.
>> There was a bug recently discovered in shared code that leads to
>> random GPU hangs with radeonsi, but all other Gallium drivers are also
>> affected in "some negative way", which may include freezes. The fix
>> was available prior to 12.0.5, but wasn't applied due to a process
>> issue.
>>
>> It is still the best 12.0.x release, but users and distributions
>> wanting better stability for non-Intel drivers should wait for 12.0.6.
>>
> As some of you may know, I've mentioned that 12.0.6 will be available
> if we get at least a few developers/teams behind it.
> 
> Since then people have contacted me, on and off list, speaking
> positively about having 12.0.6. As such there I'll be rolling the
> release.
> Not to mention that Michel went the extra mile with improved/extra
> patches on the topic/issue mentioned by Marek.
> 
> Thank for the feedback everyone !
> Emil

Is there a public branch with the proposed commits? mesa/12.0 hasn't
been touched since previous release. I'd need the release or a
preliminary branch ASAP for ubuntu..


-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] fixup! EGL: Implement the libglvnd interface for EGL (v2)

[Timo Aaltonen]

On 05.01.2017 23:29, Kyle Brenneman wrote:
> ---
>  src/egl/generate/eglFunctionList.py | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/src/egl/generate/eglFunctionList.py 
> b/src/egl/generate/eglFunctionList.py
> index b19b5f7..80cb834 100644
> --- a/src/egl/generate/eglFunctionList.py
> +++ b/src/egl/generate/eglFunctionList.py
> @@ -53,12 +53,14 @@ method values:
>  Select the vendor that owns the current context.
>  """
>  
> -def _eglFunc(name, method, static=False, public=False, inheader=None, 
> prefix="", extension=None, retval=None):
> +def _eglFunc(name, method, static=None, public=False, inheader=None, 
> prefix="dispatch_", extension=None, retval=None):
>  """
>  A convenience function to define an entry in the EGL function list.
>  """
> +if static is None:
> +static = (not public and method != "custom")
>  if inheader is None:
> -inheader = (not public)
> +inheader = (not static)
>  values = {
>  "method" : method,
>  "prefix" : prefix,

You probably need to send a v3 with this added?



-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Next Mesa release, anyone?

[Timo Aaltonen]

On 29.09.2016 18:10, Jason Ekstrand wrote:
> On Sep 28, 2016 11:44 PM, "Timo Aaltonen" <tjaal...@ubuntu.com
> <mailto:tjaal...@ubuntu.com>> wrote:
>>
>> On 28.09.2016 21:53, Marek Olšák wrote:
>> > Hi,
>> >
>> > It's been almost 4 months since the 12.0 branch was created, and soon
>> > it will have been 3 months since Mesa 12.0 was released.
>> >
>> > Is there any reason we haven't created the stable branch yet?
>> >
>> > Ideally, we would time the release so that it's 1-2 months before fall
>> > distribution releases.
>>
>> Yep, 12.0 got delayed and 12.1 seems to follow the same path, and it's
>> too late for Ubuntu 16.10 already which will ship with 12.0.3.
> 
> In order to avoid this problem in the future, when is the latest we can
> release such that you can pick it up?

The Ubuntu feature-freeze date tends to be around mid-February/August,
but freeze exceptions are allowed. So having rc1 roughly around FF would
be fine. Then the actual .0 release a few weeks later is not a problem,
and there would still be time to squeeze in a bugfix release or two
before the distro release late April/October.


-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Next Mesa release, anyone?

[Timo Aaltonen]

On 28.09.2016 21:53, Marek Olšák wrote:
> Hi,
> 
> It's been almost 4 months since the 12.0 branch was created, and soon
> it will have been 3 months since Mesa 12.0 was released.
> 
> Is there any reason we haven't created the stable branch yet?
> 
> Ideally, we would time the release so that it's 1-2 months before fall
> distribution releases.

Yep, 12.0 got delayed and 12.1 seems to follow the same path, and it's
too late for Ubuntu 16.10 already which will ship with 12.0.3.

-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] clover: Fix build against clang SVN >= r273191

[Timo Aaltonen]

On 21.06.2016 02:17, Vedran Miletić wrote:
> setLangDefaults() now requires PreprocessorOptions as an argument.
> ---
>  src/gallium/state_trackers/clover/llvm/invocation.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp 
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index e2cadda..57e 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> @@ -207,7 +207,7 @@ namespace {
>c.getDiagnosticOpts().ShowCarets = false;
>c.getInvocation().setLangDefaults(c.getLangOpts(), clang::IK_OpenCL,
>  #if HAVE_LLVM >= 0x0309
> -llvm::Triple(triple),
> +llvm::Triple(triple), 
> c.getPreprocessorOpts(),
>  #endif
>  clang::LangStandard::lang_opencl11);
>c.createDiagnostics(
> 

Emil,

Please add this to 12.0, since it's needed for using llvm-3.9 with 12.0.x.

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=97542


-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 12.0.2 release candidate

[Timo Aaltonen]

On 01.09.2016 19:47, Emil Velikov wrote:
> On 1 September 2016 at 17:34, Timo Aaltonen <tjaal...@ubuntu.com> wrote:
>> On 01.09.2016 17:25, Emil Velikov wrote:
>>> Hello list,
>>>
>>> The candidate for the Mesa 12.0.2 is now available.
>>
>> Forgot to push the tag?
>>
> Branch or tag ? The former was done a few minutes after the email,
> while the latter will be in a few days as 12.0.2 is out.

hmm right, there are no rc tags for point-releases, forgout about that..

what about 12.1.0-rcN then?-)


-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 12.0.2 release candidate

[Timo Aaltonen]

On 01.09.2016 17:25, Emil Velikov wrote:
> Hello list,
> 
> The candidate for the Mesa 12.0.2 is now available. 

Forgot to push the tag?


-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallivm: disable avx512 features

[Timo Aaltonen]

08.05.2016, 17:02, srol...@vmware.com kirjoitti:
> From: Roland Scheidegger <srol...@vmware.com>
> 
> We don't target this yet, and some llvm versions incorrectly enable it based
> on cpu string, causing crashes.
> (Albeit this is a losing battle, it is pretty much guaranteed when the next
> new feature comes along llvm will mistakenly enable it on some future cpu,
> thus we would have to proactively disable all new features as llvm adds them.)
> 
> This should fix https://bugs.freedesktop.org/show_bug.cgi?id=94291 (untested)

and it does prevent the tests from segfaulting when run on a desktop
Skylake, so

Tested-by: Timo Aaltonen <tjaal...@ubuntu.com>


-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Don't enable reset notification support on Gen4-5.

[Timo Aaltonen]

On 08.04.2014 00:31, Timo Aaltonen wrote:
 On 12.03.2014 10:43, Kenneth Graunke wrote:
 arekm reported that using Chrome with GPU acceleration enabled on GM45
 triggered the hw_ctx != NULL assertion in brw_get_graphics_reset_status.

 We definitely do not want to advertise reset notification support on
 Gen4-5 systems, since it needs hardware contexts, and we never even
 request a hardware context on those systems.

 Cc: Ian Romanick i...@freedesktop.org
 Signed-off-by: Kenneth Graunke kenn...@whitecape.org
 
 this has been on bugzilla too for some time now:
 
 https://bugs.freedesktop.org/show_bug.cgi?id=75723

maybe with proper cc: things get moving?

this is stable material too, whatever ends up committed to master


-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Fix missing _NEW_SCISSOR in Broadwell SF_CLIP_VIEWPORT state.

[Timo Aaltonen]

Yep, fixed!

Tested-by: Timo Aaltonen tjaal...@ubuntu.com

On 10.04.2014 08:54, Kenneth Graunke wrote:
 The _Xmin/_Xmax/_Ymin/_Ymax values need to be guarded by _NEW_SCISSOR.
 
 Fixes Piglit's scissor-many, and rendering in GNOME Shell.
 Hopefully fixes similar issues with Unity and ChromeOS.
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75879
 Signed-off-by: Kenneth Graunke kenn...@whitecape.org
 Cc: Timo Aaltonen tjaal...@ubuntu.com
 Cc: James Ausmus james.aus...@intel.com
 ---
  src/mesa/drivers/dri/i965/gen8_viewport_state.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/src/mesa/drivers/dri/i965/gen8_viewport_state.c 
 b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
 index 344310e..b366246 100644
 --- a/src/mesa/drivers/dri/i965/gen8_viewport_state.c
 +++ b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
 @@ -86,7 +86,7 @@ gen8_upload_sf_clip_viewport(struct brw_context *brw)
vp[10] = -gby; /* y-min */
vp[11] =  gby; /* y-max */
  
 -  /* Screen Space Viewport */
 +  /* _NEW_SCISSOR | _NEW_VIEWPORT | _NEW_BUFFERS: Screen Space Viewport 
 */
if (render_to_fbo) {
   vp[12] = ctx-DrawBuffer-_Xmin;
   vp[13] = ctx-DrawBuffer-_Xmax - 1;
 @@ -110,7 +110,7 @@ gen8_upload_sf_clip_viewport(struct brw_context *brw)
  
  const struct brw_tracked_state gen8_sf_clip_viewport = {
 .dirty = {
 -  .mesa = _NEW_VIEWPORT | _NEW_BUFFERS,
 +  .mesa = _NEW_BUFFERS | _NEW_SCISSOR | _NEW_VIEWPORT,
.brw = BRW_NEW_BATCH,
.cache = 0,
 },
 


-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Don't enable reset notification support on Gen4-5.

[Timo Aaltonen]

On 12.03.2014 10:43, Kenneth Graunke wrote:
 arekm reported that using Chrome with GPU acceleration enabled on GM45
 triggered the hw_ctx != NULL assertion in brw_get_graphics_reset_status.
 
 We definitely do not want to advertise reset notification support on
 Gen4-5 systems, since it needs hardware contexts, and we never even
 request a hardware context on those systems.
 
 Cc: Ian Romanick i...@freedesktop.org
 Signed-off-by: Kenneth Graunke kenn...@whitecape.org

this has been on bugzilla too for some time now:

https://bugs.freedesktop.org/show_bug.cgi?id=75723



-- 
t
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev