Re: glxsync - explicit frame synchronization sample implementation

Hi, Different window managers do resizes differently. See for example: https://gitlab.gnome.org/GNOME/mutter/-/issues/60 On which window managers did you test this? - Eero On 30.12.2021 7.20, Michael Clark wrote: Dear Mesa Developers, I have been using GLFW for tiny

Re: revenge of CALLOC_STRUCT

Hi, Valgrind should be able to report mismatching alloc & free calls, and I think one can also annotate which functions are alloc & free ones. AFAIK Valgrind does not work on Windows, but you could Valgrind Windows Mesa version on Linux using Wine. - Eero On 26.12.2021 12.37,

Re: [Mesa-dev] Workflow Proposal

Hi, On 7.10.2021 16.00, Alyssa Rosenzweig wrote: I would love to see this be the process across Mesa. We already don't rewrite commit messages for freedreno and i915g, and I only have to do the rebase (busy-)work for my projects in other areas of the tree. Likewise for Panfrost. At least, I

Re: [Mesa-dev] Workflow Proposal

Hi, On 7.10.2021 19.51, Daniel Stone wrote: On Thu, 7 Oct 2021 at 09:38, Eero Tamminen wrote: This sounds horrible from the point of view of trying to track down somebody who knows about what's & why's of some old commit that is later on found to cause issues... But why would your f

Re: [Mesa-dev] Workflow Proposal

Hi, On 6.10.2021 23.00, Jordan Justen wrote: Bas Nieuwenhuizen writes: On Wed, Oct 6, 2021 at 8:49 PM Jordan Justen wrote: I guess I missed where it was suggested that Marge should remove Reviewed-by tags. I don't think Marge should ever remove something from the commit message. AFAIU

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

Hi, On 28.2.2020 10.48, Dave Airlie wrote: Yes, we could federate everything back out so everyone runs their own builds and executes those. Tinderbox did something really similar to that IIRC; not sure if Buildbot does as well. Probably rules out pre-merge testing, mind. Why? does gitlab not

Re: [Mesa-dev] Profile-guides optimizations

Hi, On 13.2.2020 20.44, Dylan Baker wrote: I actually spent a bunch of time toying with PGO a couple of years ago. I got the guidance all working and was able to train it, but what we found was that it made the specific workloads we threw at it much faster, but it made every real world use case

Re: [Mesa-dev] Merging experimental r600/nir code

Hi, On 13.2.2020 10.38, Timur Kristóf wrote: I think the question about PGO is this: are the profiles of the users' applications gonna be the same as the profile that is collected from the benchmarks? Eg. if the test benchmark uses different draw calls or triggers different shader compiler

Re: [Mesa-dev] Mesa CI with trace regression testing

Hi, On 27.9.2019 4.32, Eric Anholt wrote: Alexandros Frantzis writes: The last couple of months we (at Collabora) have been working on a prototype for a Mesa testing system based on trace replays that supports correctness regression testing and, in the future, performance regression testing.

Re: [Mesa-dev] 19.2 release train going off the rails

Hi, On 3.9.2019 20.27, Matt Turner wrote: What is going on with the 19.2 RCs? I know that we said we would push the releases back a week to let some feature work land, but the last blocker of the feature tracker [0] landed on the 14th and RC1 wasn't until the 20th. Now another two weeks have

Re: [Mesa-dev] renderdoc-traces: like shader-db for runtime

Hi, On 24.6.2019 19.36, Elie Tournier wrote: Great topic. For the past few days, I was looking at a CI for Mesa: https://gitlab.freedesktop.org/hopetech/tracie OK, it's in a very very alpha stage. ;) My idea was to use apitrace to dump and replay traces then compare images with reference

Re: [Mesa-dev] renderdoc-traces: like shader-db for runtime

Hi, On 20.6.2019 22.26, Eric Anholt wrote: Hey folks, I wanted to show you this follow-on to shader-db I've been working on: https://gitlab.freedesktop.org/anholt/renderdoc-traces For x86 development I've got a collection of ad-hoc scripts to capture FPS numbers from various moderately

Re: [Mesa-dev] GLU and GLUT issues migrated to gitlab

Hi, On 14.5.2019 20.06, Adam Jackson wrote: On Mon, 2019-05-13 at 12:14 -0400, Adam Jackson wrote: Not, I hope, that anyone is likely to notice, but I've moved the open GLU and GLUT bugs from bugzilla to gitlab and closed the components in bugzilla. I say "moved" but really glut only had one

Re: [Mesa-dev] Mesa/DRI applications freezing randomly

Hi, (Please add answers to the bug you create about this) On 17.4.2019 16.22, Augusto Mecking Caringi wrote: Recently applications using Mesa/DRI libraries started fo freeze randomly in my system... I'm running Fedora 29 x86_64: - Kernel: x86_64 Linux 5.0.7-200.fc29.x86_64 - X.Org X Server

Re: [Mesa-dev] Mesa 19.1.0 release plan

Hi, On 16.4.2019 11.38, Juan A. Suarez Romero wrote: On Mon, 2019-04-15 at 18:57 +0300, Eero Tamminen wrote: On 15.4.2019 17.15, Juan A. Suarez Romero wrote: Here is the tentative release plan for 19.1.0. As many of you are well aware, it's time to the next branch point. The calendar

Re: [Mesa-dev] Mesa 19.1.0 release plan

Hi, On 15.4.2019 17.15, Juan A. Suarez Romero wrote: Here is the tentative release plan for 19.1.0. As many of you are well aware, it's time to the next branch point. The calendar is already updated, so these are the tentative dates: Apr 30 2019 - Feature freeze/Release candidate 1 May 07

Re: [Mesa-dev] [PATCH 2/2] meson: upgrade minimum meson version

eson to the distro, and what's available in it. Dylan? - Eero Regards //Ernst Den tis 9 apr. 2019 kl 13:00 skrev Eero Tamminen : Hi, On 9.4.2019 0.22, Dylan Baker wrote: It would be nice if people wouldn't try to build bleeding edge mesa on a 12 year old distro :D. Unfortunately as

Re: [Mesa-dev] [PATCH 2/2] meson: upgrade minimum meson version

moving these deprecation warnings in cases where the minimum version doesn't have the recommended replacement, but that's hard. Dylan Quoting Eero Tamminen (2019-04-08 04:16:49) Hi, On 6.4.2019 11.44, Khaled Emara wrote: Sorry, I though LTS distros used old versions of mesa. Got it. Those *provi

Re: [Mesa-dev] [PATCH 2/2] meson: upgrade minimum meson version

Hi, On 6.4.2019 11.44, Khaled Emara wrote: Sorry, I though LTS distros used old versions of mesa. Got it. Those *provide* older Mesa version, so naturally people want to build latest Mesa on them (especially if they've just bought HW that isn't supported by distro version of Mesa). Building

Re: [Mesa-dev] [PATCH] RFC: Workaround for pthread_setaffinity_np() seccomp filtering

Hi, On 12.3.2019 10.59, Marc-André Lureau wrote: On Fri, Mar 1, 2019 at 12:13 PM Mathias Fröhlich wrote: On Friday, 1 March 2019 12:15:08 CET Eero Tamminen wrote: On 1.3.2019 11.12, Michel Dänzer wrote: On 2019-02-28 8:41 p.m., Marek Olšák wrote: On Thu, Feb 28, 2019 at 1:37 PM Eero

Re: [Mesa-dev] [PATCH] RFC: Workaround for pthread_setaffinity_np() seccomp filtering

Hi, On 1.3.2019 11.12, Michel Dänzer wrote: On 2019-02-28 8:41 p.m., Marek Olšák wrote: On Thu, Feb 28, 2019 at 1:37 PM Eero Tamminen Why distro versions of Qemu filter sched_setaffinity() syscall? (https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1815889) Daniel Berrange (berrange

Re: [Mesa-dev] [PATCH] RFC: Workaround for pthread_setaffinity_np() seccomp filtering

Hi, On 28.2.2019 11.57, Marc-André Lureau wrote: On Thu, Feb 28, 2019 at 1:17 AM Marek Olšák wrote: I'd rather have something more robust than an env var, like catching SIGSYS. SIGSYS is info for the invoking parent, not the (Mesa) process doing the syscall. From "man 2 seccomp": The

Re: [Mesa-dev] A few NIR compile time optimisations

Hi, On 20.2.2019 17.32, Marek Olšák wrote: On Wed, Feb 20, 2019 at 2:31 AM Connor Abbott On Wed, Feb 20, 2019 at 4:29 AM Marek Olšák ... That's a harsh reaction to a relatively good benchmarking setup. I use debugoptimized with -DDEBUG. My performance is probably

Re: [Mesa-dev] [ANNOUNCE] mesa 19.0.0-rc1

Hi, On 6.2.2019 20.03, Dylan Baker wrote: Quoting Eero Tamminen (2019-02-04 04:41:12) [...] * going through bugzilla bugs that have been created after previous release branch point was tagged and, adding the relevant ones to the release tracker bug This has always been the job

Re: [Mesa-dev] [ANNOUNCE] mesa 19.0.0-rc

Hi, On 4.2.2019 14.41, Eero Tamminen wrote: On 2.2.2019 3.20, Mark Janes wrote: [...] These regressions all need to be added to the release tracker.  Thank you for reporting them. If that should track all the things regressed since previous 18.3 version was branched: --- tag

Re: [Mesa-dev] [ANNOUNCE] mesa 19.0.0-rc1

Hi, On 2.2.2019 3.20, Mark Janes wrote: Eero Tamminen writes: On 31.1.2019 1.37, Dylan Baker wrote: This email announces the mesa 19.0 release candidate 1. I'll keep this email fairly brief since I'm already running a little late on getting this done :) I've just had to resolve quite a few

Re: [Mesa-dev] [ANNOUNCE] mesa 19.0.0-rc1

Hi, On 31.1.2019 1.37, Dylan Baker wrote: This email announces the mesa 19.0 release candidate 1. I'll keep this email fairly brief since I'm already running a little late on getting this done :) I've just had to resolve quite a few autotools issues to get the dist built. Notable in the

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

Hi, On 13.1.2019 9.44, Jonathan Gray wrote: ...> As we can not depend on python to build Mesa in OpenBSD I will have to go back to maintaining a local Mesa build system if autotools is removed. Mesa already needs python-mako (for code generation) with Autotools. Why Meson also needing Python

Re: [Mesa-dev] Chromium - Application-level nouveau blacklist

Hi, On 8.1.2019 8.56, Stéphane Marchesin wrote: Yes I think the Chrome-side is very simple here: because there isn't time or means for in-depth investigation, if a driver crashes too much, it gets blacklisted. The situation is not unique, the GPU blacklist file is 1700 lines:

Re: [Mesa-dev] NIR documentation (was: NIR constant problem for GPU which doesn't have native integer support)

Hi, On 7.1.2019 12.42, Erik Faye-Lund wrote: On Fri, 2019-01-04 at 09:40 -0600, Jason Ekstrand wrote: [...] Yeah... Patches welcome? There have been many attempts by Connor and myself to better document NIR. They all end up in /dev/null due to EBIGGERFIRES. :-( That said, if you ever want

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

Hi, On 20.12.2018 4.40, Stuart Young wrote: Could this be reduced this from an error to a warning, with the command-line option suppressing the warning? Perhaps as well as producing the warning, the build could sleep for say 30 seconds after producing the warning message. This would be

Re: [Mesa-dev] last call for autotools

Hi, On 17.12.2018 8.08, Marek Olšák wrote: [...] I think one of the serious usability issues is that environment variables such as CFLAGS, CXXFLAGS, LDFLAGS, and PKG_CONFIG_PATH are not saved by meson for future reconfigures. I don't know what Meson is supposed to do, but to me that would be

Re: [Mesa-dev] Suggestions for improving meson-based builds

Hi, On 17.12.2018 2.33, Jason Ekstrand wrote: On Sun, Dec 16, 2018 at 1:49 PM Ilia Mirkin > wrote: [...]> 2. Summary at the end. This is not strictly an autotools-specific issue, but rather how mesa has used it. That summary at the end is very useful to

Re: [Mesa-dev] Let's talk about -DDEBUG

Hi, On 13.12.2018 12.19, Eric Engestrom wrote: On Wednesday, 2018-12-12 19:45:06 -0500, Marek Olšák wrote: On Wed, Dec 12, 2018 at 7:35 PM Rob Clark wrote: On Wed, Dec 12, 2018 at 7:14 PM Dylan Baker wrote: Quoting Rob Clark (2018-12-12 15:52:47) ... I guess I should have covered that:

Re: [Mesa-dev] [PATCH 4/4] nir: detect more induction variables

Hi, On 28.11.2018 5.25, Timothy Arceri wrote: This adds allows loop analysis to detect inductions varibales that are incremented in both branches of an if rather than in a main loop block. For example: [...]> Unfortunatly GCM could move the addition out of the if for us (making this patch

Re: [Mesa-dev] [PATCH 5/6] nir: Fix holes in nir_instr

Hi, On 28.11.2018 2.38, Ian Romanick wrote: From: Ian Romanick Found using pahole. While Pahole does static analysis for binaries, Valgrind has tool that can do also _run-time_ analysis of structures and other heap allocations utilization:

Re: [Mesa-dev] Lets talk about autotools

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

Re: [Mesa-dev] [PATCH] meson: Bump version to 0.46 for python module

Hi, On 21.11.2018 20.13, Dylan Baker wrote: From: Arfrever Frehtes Taifersar Arahesis Meson has two modules for finding python, the python3 module and the python module. Python3 is older, and has some corner cases, python is newer, has no known corner cases and can detect python2. Things have

Re: [Mesa-dev] [PATCH 1/5] i965/icl: Fix L3 configurations

Hi, On 16.11.2018 10.33, Francisco Jerez wrote: Kenneth Graunke writes: [...] Perhaps we'll get both configs working, and then will want to be able to select between them. I question whether the additional URB is truly that valuable - how large are the actual gains? - considering that we

Re: [Mesa-dev] [PATCH 00/11] intel/fs: Add a generic SEND opcode and use it on

Hi, On 3.11.2018 2.06, Jason Ekstrand wrote: This patch series is something we've talked about doing for a while and haven't gotten around to yet. It implements a generic SEND opcode and then reworks a bunch of the current SEND instructions such as texturing to use that instead of piles of

Re: [Mesa-dev] [PATCH] intel/compiler: Print message descriptor as immediate source

Hi, Toni had a working assembler in early 2017, but he had to stop working on it because nobody reviewed the patches needed for the disassembler. Maybe his patch series for the disassembly output still has something useful for your assembler: * i965 shader disassembly label support:

Re: [Mesa-dev] [PATCH 0/5] anv: Add a NIR cache

Hi, On 10/13/18 3:08 AM, Jason Ekstrand wrote: This patch series adds a simple NIR shader cache that sits right after spirv_to_nir and brw_preprocess_nir and before linking. This should help alleviate some of the added overhead of link-time optimization since most of the NIR-level optimization

Re: [Mesa-dev] [PATCH] anv: Use separate MOCS settings for external BOs

or display and those which are entirely internal. That, together with an anv_mocs_for_bo helper lets us choose the right MOCS settings for each BO use. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99507 Cc: mesa-sta...@lists.freedesktop.org Tested-By: Eero Tamminen This fixes the horrible

Re: [Mesa-dev] [PATCH] util/u_queue: don't inherit thread affinity from parent thread

Hi, On 10/3/18 2:00 AM, Marek Olšák wrote: On Tue, Oct 2, 2018 at 6:36 PM Rob Clark wrote: On Tue, Oct 2, 2018 at 6:30 PM Marek Olšák wrote: From: Marek Olšák [...] Just curious (and maybe I missed some previous discussion), would this override taskset? Asking because when benchmarking

Re: [Mesa-dev] [PATCH 3/4] drirc: Initial blacklist for adaptive sync

Hi, On 11.09.2018 19:24, Nicholas Kazlauskas wrote: Applications that don't present at a predictable rate (ie. not games) shouldn't have adapative sync enabled. This list covers some of the common desktop compositors and some web browsers. Why videos (in video players like vlc & mpv) wouldn't

Re: [Mesa-dev] [PATCH] glsl: fixer lexer for unreachable defines

Hi, Seems a lot of replicated code to deal with regression from few line line patch, but at least it fixed the failing GfxBench ALU2 test. :-) Tested-By: Eero Tamminen - Eero On 01.09.2018 16:57, Timothy Arceri wrote: If we have something like: #ifdef NOT_DEFINED #define

Re: [Mesa-dev] [PATCH] Bounding box avx2 intrinsic algorithm for openGL/GLES

Hi, On 31.08.2018 08:25, kedar.j.kara...@intel.com wrote: From: "J Karanje, Kedar" The feature is enabled by default during make however we need to add the following to drirc to enable the feature at runtime. vbo: Main algorithm & code to check for MVP & vertex position location Build

Re: [Mesa-dev] [PATCH 3/3] i965/screen: Allow modifiers on sRGB formats

r comment) fixes both SynMark & GfxBench regressions. Tested-By: Eero Tamminen - Eero Rejecting such formats caused us to not allow CCS in some cases where we should have been allowing it. There's some question of whether or not we really should be using SRGB "fourcc&q

Re: [Mesa-dev] [PATCH 0/2] Implement INTEL_fragment_shader_ordering

Hi, On 28.08.2018 19:15, Rogovin, Kevin wrote: On the questions of tests: If people want, I can adapt the test in piglit for ARB_fragment_shader_interlock to this INTEL one. In general, I have an app/library that uses the extension and testing of that does definitely work on i965 (which

Re: [Mesa-dev] [PATCH v2 2/2] i965, anv: Use INTEL_DEBUG for disk_cache driver flags

Hi, Should this fix also: https://bugs.freedesktop.org/show_bug.cgi?id=106382 ? - Eero On 23.07.2018 07:27, Jordan Justen wrote: Since various options within INTEL_DEBUG could impact code generation, we need to set the disk cache driver_flags parameter based on the INTEL_DEBUG

Re: [Mesa-dev] [PATCH v2 2/3] nir: Add a discard optimization pass

Hi, On 06.07.2018 00:28, Jason Ekstrand wrote: On Thu, Jul 5, 2018 at 2:18 PM, Jason Ekstrand > wrote: [...] >> Optimizing for the latter case is an essentially >> heuristic assumption that needs to be verified experimentally.  Have you >>

Re: [Mesa-dev] Loop unrolling and if statement opts

Hi, On 11.07.2018 12:00, Timothy Arceri wrote: On 11/07/18 18:20, Eero Tamminen wrote: Have you considered partial loop unrolling support? I.e. when loop counter is known, but too high for full unroll, doing partial loop unrolling (e.g. unroll 4x times) and dividing loop counter by same

Re: [Mesa-dev] Loop unrolling and if statement opts

Hi, Have you considered partial loop unrolling support? I.e. when loop counter is known, but too high for full unroll, doing partial loop unrolling (e.g. unroll 4x times) and dividing loop counter by same amount (if it didn't divide evenly, need to unroll remainder outside of loop). This

Re: [Mesa-dev] [PATCH 6/7] mesa/util: add allow_glsl_relaxed_es driconfig override

Hi, On 08.06.2018 15:19, Timothy Arceri wrote: This relaxes a number of ES shader restrictions allowing shaders to follow more desktop GLSL like rules. This initial implementation relaxes the following: - allows linking ES shaders with desktop shaders - allows mismatching precision

Re: [Mesa-dev] Mesa logo animation (was: Move the Mesa Website to Sphinx)

Hi, On 08.06.2018 15:06, robdcl...@gmail.com wrote: On Fri, Jun 8, 2018 at 3:02 AM, Jordan Justen wrote: On Thu, Jun 7, 2018 at 2:56 AM Eero Tamminen wrote: ... For Mesa, WebGL could be more fitting implementation than SVG though... https://github.com/gears3d/gears3d.github.io/blob

Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx

Hi, On 07.06.2018 12:01, Erik Faye-Lund wrote: Just as a fun toy, I decided to give an animated SVG "variation" of this a go myself: https://codepen.io/kusma/pen/vrXppL The actual SVG can be found here: https://gitlab.freedesktop.org/snippets/492 The gears were generated by this python

Re: [Mesa-dev] [PATCH 00/53] intel/fs: SIMD32 support for fragment shaders

Hi, On 30.05.2018 17:30, Jason Ekstrand wrote: On May 30, 2018 06:45:29 Eero Tamminen wrote: On 29.05.2018 18:58, Eero Tamminen wrote: On 25.05.2018 00:55, Jason Ekstrand wrote: This patch series adds back-end compiler support for SIMD32 fragment shaders.  Support is added and everything

Re: [Mesa-dev] [PATCH 00/53] intel/fs: SIMD32 support for fragment shaders

Hi, On 29.05.2018 18:58, Eero Tamminen wrote: On 25.05.2018 00:55, Jason Ekstrand wrote: This patch series adds back-end compiler support for SIMD32 fragment shaders.  Support is added and everything works but it's currently hidden behind INTEL_DEBUG=do32.  We know that it improves performance

Re: [Mesa-dev] [PATCH 00/53] intel/fs: SIMD32 support for fragment shaders

Hi, On 29.05.2018 18:58, Eero Tamminen wrote: On 25.05.2018 00:55, Jason Ekstrand wrote: This patch series adds back-end compiler support for SIMD32 fragment shaders.  Support is added and everything works but it's currently hidden behind INTEL_DEBUG=do32.  We know that it improves performance

Re: [Mesa-dev] [PATCH 00/53] intel/fs: SIMD32 support for fragment shaders

a good enough heuristic to start turning it on by default. The objective of this series is to just to get the compiler infrastructure landed so that it stops bit-rotting in Curro's branch. Tested v3 on BXT & SKL. Everything seems to work otherwise fine. Tested-by Eero Tamminen Figuring

Re: [Mesa-dev] Mesa documentation (was: Gitlab migration)

Hi, On 23.05.2018 22:34, Jason Ekstrand wrote: [...]> One of the motivations for doing this now is that there has been some desire to move the mesa website away from raw HTML and over to a platform such as sphinx.  If we're going to do that, we need a system for building the website whenever

Re: [Mesa-dev] [PATCH 09/22] intel/compiler: implement 16-bit multiply-add

Hi, On 21.05.2018 10:42, Iago Toral wrote: On Fri, 2018-05-18 at 12:08 +0300, Eero Tamminen wrote: On 17.05.2018 14:25, Eero Tamminen wrote: On 17.05.2018 11:46, Iago Toral Quiroga wrote: The PRM for MAD states that F, DF and HF are supported, however, then it requires that the instruction

Re: [Mesa-dev] [PATCH 09/22] intel/compiler: implement 16-bit multiply-add

Hi, On 17.05.2018 11:46, Iago Toral Quiroga wrote: The PRM for MAD states that F, DF and HF are supported, however, then it requires that the instruction includes a 2-bit mask specifying the types of each operand like this: > 00: 32-bit float 01: 32-bit signed integer 10: 32-bit unsigned

Re: [Mesa-dev] gcc bug / crash in ast_type_qualifier::validate_in_qualifier()?

Hi, On 08.05.2018 20:33, Francisco Jerez wrote: Kenneth Graunke <kenn...@whitecape.org> writes: On Tuesday, May 8, 2018 1:23:32 AM PDT Eero Tamminen wrote: On 08.05.2018 06:45, Matt Turner wrote: On Mon, May 7, 2018 at 8:02 PM, Brian Paul <bri...@vmware.com> wrote: This proba

Re: [Mesa-dev] gcc bug / crash in ast_type_qualifier::validate_in_qualifier()?

Hi, On 08.05.2018 06:45, Matt Turner wrote: On Mon, May 7, 2018 at 8:02 PM, Brian Paul wrote: I don't know when this started happening (I'll try bisecting tomorrow) but we're seeing a crash in ast_type_qualifier::validate_in_qualifier() in -O3 builds with gcc 5.4.0 on

Re: [Mesa-dev] [PATCH 0/4] improve buffer cache and reuse

Hi, On 05.05.2018 03:56, James Xiong wrote: From: "Xiong, James" With the current implementation, brw_bufmgr may round up a request size to the next bucket size, result in 25% more memory allocated in the worst senario. For example: Request sizeActual size

Re: [Mesa-dev] [PATCH v3] i965: Fix ETC2/EAC GetCompressed* functions on Gen7 GPUs

Hi, On 04.05.2018 22:06, Eleni Maria Stea wrote: On Fri, 4 May 2018 18:29:55 +0300 Eero Tamminen <eero.t.tammi...@intel.com> wrote: You mean returning CAVEAT_SUPPORT in params for compressed formats which are transparently converted to uncompressed data? Well, that would be th

Re: [Mesa-dev] [PATCH v3] i965: Fix ETC2/EAC GetCompressed* functions on Gen7 GPUs

Hi, On 04.05.2018 14:11, Eleni Maria Stea wrote: Thanks for your feedback, On Thu, 3 May 2018 13:30:38 +0300 Eero Tamminen <eero.t.tammi...@intel.com> wrote: On 02.05.2018 20:19, Matt Turner wrote: On Wed, May 2, 2018 at 9:13 AM, Eleni Maria Stea <es...@igalia.com> wrote: Gen

Re: [Mesa-dev] [PATCH 0/4] improve buffer cache and reuse

Hi, On 02.05.2018 21:19, James Xiong wrote: On Wed, 2 May 2018 14:18:21 +0300 Eero Tamminen <eero.t.tammi...@intel.com> wrote: [...] You're missing information on: * On which plaform you did the testing (affects variance) * how many test rounds you ran, and * what is your variance &g

Re: [Mesa-dev] [PATCH v3] i965: Fix ETC2/EAC GetCompressed* functions on Gen7 GPUs

Hi, On 02.05.2018 20:19, Matt Turner wrote: On Wed, May 2, 2018 at 9:13 AM, Eleni Maria Stea wrote: Gen 7 GPUs store the compressed EAC/ETC2 images in other non-compressed formats that can render. When GetCompressed* functions are called, the pixels are returned in the

Re: [Mesa-dev] [PATCH 0/4] improve buffer cache and reuse

Hi, On 02.05.2018 02:25, James Xiong wrote: From: "Xiong, James" With the current implementation, brw_bufmgr may round up a request size to the next bucket size, result in 25% more memory allocated in the worst senario. For example: Request sizeActual size

Re: [Mesa-dev] [PATCH] dri3: Only update number of back buffers in loader_dri3_get_buffers

;30 compiz crashes within ~3h test run. With the patch, same compiz process works fine for the whole run. -> looks good to me. Tested-by: Eero Tamminen <eero.t.tammi...@intel.com> - Eero src/loader/loader_dri3_helper.c | 19 +++ 1 file changed, 11 inserti

Re: [Mesa-dev] [PATCH] mesa/main: Rework the shader capture naming convention

Hi, On 28.04.2018 17:39, Benedikt Schemmer wrote: Change from a purely number.shader_test naming scheme to sha_number.shader_test because especially games often use the same number for entirely different shaders based on graphics settings etc. and then already captured shaders get

Re: [Mesa-dev] [PATCH] anv/allocator: Don't srink either end of the block pool

in either direction. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105374 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106147 Verified that "texture3d" demo works with this patch, crashes without it. Tested-by: Eero Tamminen <eero.t.tammi...@intel.com> - Eer

Re: [Mesa-dev] [PATCH v2] dri3: Prevent multiple freeing of buffers.

Hi, Tested on KBL GT2. Before the patch, there are few dozen compiz segfaults during ~3 hours of testing. With the patched version there are no segfaults. Tested-by: Eero Tamminen <eero.t.tammi...@intel.com> - Eero On 10.04.2018 10:44, Sergii Romantsov wrote: Commit 3160cb

Re: [Mesa-dev] [PATCH] dri3: Prevent multiple freeing of buffers.

Hi, I tested this on KBL GT2. Compiz crashes during 3h test run dropped from 30 to none. There were couple of percent changes in few synthetic tests, but I think that's just because Compiz is now running properly. -> looks good! - Eero Tested-by: Eero Tamminen <eero.t

Re: [Mesa-dev] [PATCH] i965: annotate brw_oa.py's --header and --code as required

Hi, On 20.03.2018 19:06, Dylan Baker wrote: Quoting Emil Velikov (2018-03-20 09:29:00) [snip] gens = [] for xml_file in args.xml_files: @@ -617,7 +610,7 @@ def main(): """)) -c("#include \"" + os.path.basename(args.header) + "\"") +c("#include \"" +

Re: [Mesa-dev] GfxBench & CSDof failures

Hi, On 28.03.2018 13:27, Eero Tamminen wrote: Mesa built from following (last evening) commit: commit 76dfed8ae2d5c6c509eb2661389be3c6a25077df Author: Rob Clark <robdcl...@gmail.com> AuthorDate: Thu Mar 15 18:42:44 2018 -0400 Commit: Rob

[Mesa-dev] GfxBench & CSDof failures

Hi, Mesa built from following (last evening) commit: commit 76dfed8ae2d5c6c509eb2661389be3c6a25077df Author: Rob Clark AuthorDate: Thu Mar 15 18:42:44 2018 -0400 Commit: Rob Clark CommitDate: Tue Mar 27

Re: [Mesa-dev] [PATCH 1/5] i965: Hard code scratch_ids_per_subslice for Cherryview

Hi, Tested SynMark CSDof and GfxBench Aztec Ruins GL & GLES / normal & high versions, which were earlier GPU hanging. With this patch hangs are gone. Tested-by: Eero Tamminen <eero.t.tammi...@intel.com> On 07.03.2018 10:16, Jordan Justen wrote: Ken suggested

Re: [Mesa-dev] [PATCH 1/5] i965: Hard code scratch_ids_per_subslice for Cherryview

Hi, Tested SynMark CSDof and GfxBench Aztec Ruins GL & GLES / normal & high versions, which were earlier GPU hanging. With this patch hangs are gone. Tested-by: Eero Tamminen <eero.t.tammi...@intel.com> On 07.03.2018 10:16, Jordan Justen wrote: Ken suggested

Re: [Mesa-dev] [PATCH 3/3] i965/tex_image: Avoid the ASTC LDR workaround on gen9lp

Flush certain subnormal ASTC channel values" Cc: Eero Tamminen <eero.t.tammi...@intel.com> Cc: Scott D Phillips <scott.d.phill...@intel.com> --- src/mesa/drivers/dri/i965/intel_tex_image.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/in

Re: [Mesa-dev] [PATCH 5/6] intel/fs: Handle surface opcode sample masks via predication.

GT2. CSDof improved by: * 9% on BYT * 7-8% on BXT J4205, and on SKL GT2 desktop (Variance on HSW was too large in this test, to conclude anything.) Changes in all the other tests were within daily variance. Tested-By: Eero Tamminen <eero.t.tammi...@intel.com> - Eero ---

Re: [Mesa-dev] [PATCH 08/15] glsl: Switch ast_type_qualifier to a 128-bit bitset.

d integer types, but it should be harmless since the two candidates have the same semantics, and should go away with a C++11-capable compiler. I think the attached patch should shut the warnings on older compilers. Yes, it fixed the compilation with gcc 5.4, and INTEL_DEBUG=shader_time segfaults with g

Re: [Mesa-dev] [PATCH 4/4] i965: Implement dual-patch tessellation evaluation shaders.

Hi, Could you also give dual & single shaders different names when dumping them, e.g. something like the attached patch? - Eero On 23.02.2018 10:36, Kenneth Graunke wrote: Normally, SIMD8 tessellation evaluation shaders operate on a single patch, with each channel operating on a

Re: [Mesa-dev] [PATCH shaderdb 3/3] run: shader program file created via GetProgramBinary

Hi, On 13.02.2018 03:26, Dongwon Kim wrote: extraction of linked binary program to a file using glGetProgramBinary. This file is intended to be loaded by glProgramBinary in the graphic application running on the target system. A new option, '--out=' is available to be used for specifying the

Re: [Mesa-dev] [PATCH 0/6] i965: Misc sRGB and CCS fixes

CarChase & SynMark Deferred KBL GT3e improvements: ~2% in GfxBench Manhattan 3.1 & CarChase and SynMark Deferred By accident I had left Aztec Ruins out, but I assume ~1% drop in that is also fixed. Tested-by: Eero Tamminen <eero.t.tammi...@intel.com> - Eero [1] SynM

Re: [Mesa-dev] [PATCH] spirv: Loosten the validation for load/store type matching

, with them, it works fine. Tested-by: Eero Tamminen <eero.t.tammi...@intel.com> On Mon, Jan 1, 2018 at 8:09 PM, Jason Ekstrand <ja...@jlekstrand.net <mailto:ja...@jlekstrand.net>> wrote: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104424 <https:/

Re: [Mesa-dev] [PATCH] spirv: avoid infinite loop / freeze in vtn_cfg_walk_blocks()

Hi, On 22.12.2017 11:42, Eero Tamminen wrote: On 21.12.2017 22:19, Mark Janes wrote: This patch doesn't apply to master as formatted. It was against master.  Could you try the attached patch instead? Argh, I meant the patch attached to this mail. Sorry again. - Eero I assume I

Re: [Mesa-dev] [PATCH] spirv: avoid infinite loop / freeze in vtn_cfg_walk_blocks()

testing on master. My fix is rather obvious, just moving few lines, to make sure loop is incremented every round, like it was before the bad commit. - Eero Eero Tamminen <eero.t.tammi...@intel.com> writes: Fixes: 9702fac68e (spirv: consider bitsize when handling OpSwitch

Re: [Mesa-dev] [PATCHv2] intel/fs: Optimize and simplify the copy propagation dataflow logic.

Hi, I tested this on HSW GT2, BXT & SKL GT3e, and didn't see any significant regressions this time. I'll try it also on a machine with smaller variance than those (now that it became free), and send a note if that does show something. - Eero On 20.12.2017 21:27, Francisco Jerez

[Mesa-dev] [PATCH] spirv: avoid infinite loop / freeze in vtn_cfg_walk_blocks()

Fixes: 9702fac68e (spirv: consider bitsize when handling OpSwitch cases) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104359 --- src/compiler/spirv/vtn_cfg.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/compiler/spirv/vtn_cfg.c

Re: [Mesa-dev] [PATCH] intel/fs: Optimize and simplify the copy propagation dataflow logic.

Hi, I got unexpected results with this, when testing it on BXT & SKL GT2. While performance in GpuTest Volplosion and GfxBench v4 Tessellation test improved slightly, performance in SynMark v7 CSDof and GpuTest v0.7 Piano dropped clearly. Piano dropped only on SKL, but there the drop was

Re: [Mesa-dev] [PATCH] intel/fs: Optimize and simplify the copy propagation dataflow logic.

Hi, On 20.12.2017 16:29, Eero Tamminen wrote: I got unexpected results with this, when testing it on BXT & SKL GT2. While performance in GpuTest Volplosion and GfxBench v4 Tessellation test improved slightly, performance in SynMark v7 CSDof and GpuTest v0.7 Piano dropped clearly. P

Re: [Mesa-dev] [PATCH 3/3] Revert "i965: Disable regular fast-clears (CCS_D) on gen9+"

e render cache, it should     be safe to re-enable CCS_D for sRGB. * s/How taht/Now that/ * Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=104163 * Tested-by: Eero Tamminen <eero.t.tammi...@intel.com> - Eero On Wed, Dec 13, 2017 at 5:52 PM, Jason Ekstrand <ja...@jle

Re: [Mesa-dev] [PATCH 0/2] i965: scratch space fixes (v2)

Hi, Tested-by: Eero Tamminen <eero.t.tammi...@intel.com> Fixes GPU hangs I'm seeing also with the *GL* version of CarChase on KBL GT3e (when using Ubuntu 16.04 kernel). - Eero On 12.12.2017 14:17, kevin.rogo...@intel.com wrote: From: Kevin Rogovin <kevin.rogo...@

Re: [Mesa-dev] [PATCH 1/2] intel/fs: Implement GRF bank conflict mitigation pass.

Hi, On 11.12.2017 12:28, Eero Tamminen wrote: Thanks for finally having this handled in Mesa! This patch series, live intervals and "Don't let undefined values prevent copy propagation" commits help performance in following tests: * GfxBench CarChase (2% by live intervals) That

Re: [Mesa-dev] [PATCH 0/2] i965: scratch space fixes

Hi, Tested-by: Eero Tamminen <eero.t.tammi...@intel.com> On 12.12.2017 12:04, kevin.rogo...@intel.com wrote: From: Kevin Rogovin <kevin.rogo...@intel.com> This patch series fixes 2 issues for scratch space on compute shaders for GEN. Together with the ASTC5x5 fixes posted befo

Re: [Mesa-dev] [PATCH 1/2] intel/fs: Implement GRF bank conflict mitigation pass.

Hi, Thanks for finally having this handled in Mesa! This patch series, live intervals and "Don't let undefined values prevent copy propagation" commits help performance in following tests: * GfxBench CarChase (2% by live intervals) * GfxBench AztecRuins & Manhattan 3.0 (very marginally) *

Re: [Mesa-dev] GPU (and system) monitoring

Hi, On 21.11.2017 02:39, Gordon Haverland wrote: On Mon, 20 Nov 2017 13:25:26 +0100 Nicolai Hähnle wrote: ... umr does that for the amdgpu kernel module I downloaded the source tree, compiled umr, mounted the debugfs to use umr, and ran umr --top switching to sensor

  1   2   3   >