Re: [Mesa-dev] very strange intermittent frame-dropping

well it had to happen eventually (i forgot to keep the battery charged up) so the opportunity to restart arrived - changed to DRI=3 and, ta-daaa, problem's gone. ... or, at least, carrying out the previously 100%-repeatable test (resize of a window under fvwm2) is no longer 100% repeatable. i'll

[Mesa-dev] very strange intermittent frame-dropping

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848895 there's a really strange and comprehensively cross-application intermittent bug that's only occurring on opengl-based applications, that's been introduced some time in the past year. to be absolutely honest nobody's even sure it's actually

Re: [Mesa-dev] very strange intermittent frame-dropping

On Tue, Apr 4, 2017 at 11:04 AM, Eero Tamminen wrote: >> anyway, apologies: nobody whose applications are affected by this >> really has a clue where the *actual* bug is so i am escalating it down >> the chain of library dependencies, making people aware. it could be

Re: [Mesa-dev] very strange intermittent frame-dropping

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Apr 4, 2017 at 12:10 PM, Luke Kenneth Casson Leighton <l...@lkcl.net> wrote: >> Does DRI2 vs. DRI3 have any effect on it? > > hmm, good question. i'm running with "DRI" "true

Re: [Mesa-dev] very strange intermittent frame-dropping

On Thu, Apr 6, 2017 at 11:36 AM, Eero Tamminen wrote: >> LIBGL_DEBUG=verbose glxgears >> libGL: Using DRI2 for screen 0 >> >> huh. so i _thought_ it was going to be DRI3. that's supposed to be >> the default, isn't it? > > > You need it enabled in Intel DDX build,

Re: [Mesa-dev] very strange intermittent frame-dropping

On Wed, Apr 5, 2017 at 10:43 PM, Chris Wilson wrote: >> 303 frames in 5.0 seconds = 60.424 FPS >> 212 frames in 11.7 seconds = 18.079 FPS > > Overshoots by 6s. that's because, after the first 5 seconds, i did the fvwm2-based "window resize" operation which triggered

Re: [Mesa-dev] very strange intermittent frame-dropping

ok installed libxcb1-dbg from debian, that gives more info, sorry i can't install all the dbg symbols because of conflicting dependencies, it seems that the packages are not fully sync'd at debian/testing. starting to look like an x11 (xcb-related) bug, not mesa, what do you think? l.

Re: [Mesa-dev] very strange intermittent frame-dropping

: > Hi, > > On 04.04.2017 14:10, Luke Kenneth Casson Leighton wrote: >> >> On Tue, Apr 4, 2017 at 11:04 AM, Eero Tamminen >> <eero.t.tammi...@intel.com> wrote: >>>> >>>> anyway, apologies: nobody whose applications are affected by this >

Re: [Mesa-dev] very strange intermittent frame-dropping

eero, chris: michel informs me that this is a known bug in xserver-xorg-core 1.19.0 and that upgrading to at least 1.19.1 or above fixes the problem. i'll need to wait until another unscheduled reboot but will keep you informed, and will try out DRI2 as well as DRI3. l.

[Mesa-dev] NLNet Funding Application, EUR 50, 000, for help porting AMDVLK or MESA RADV to the Libre RISC-V Hybrid CPU/GPU.

(to preserve thread, please do cc me on any questions, i am subscribed digest, thanks) https://libre-riscv.org/nlnet_2019_amdvlk_port/ i've submitted a funding request to the Charitable Foundation, NLNet, for people to be the recipient of donations to work on a port of MESA RADV (or AMDVLK, as

Re: [Mesa-dev] NLNet Funding Application, EUR 50, 000, for help porting AMDVLK or MESA RADV to the Libre RISC-V Hybrid CPU/GPU.

hi all, the funding application was successful, i will follow up in a separate subject line. On Thursday, September 26, 2019, Luke Kenneth Casson Leighton wrote: > (to preserve thread, please do cc me on any questions, i am subscribed > digest, thanks) > > https://lib

Re: [Mesa-dev] NLNet Funded development of a software/hardware MESA driver for the Libre GPGPU

On Thursday, January 9, 2020, Jason Ekstrand wrote: > Drive-by comment: > really appreciate the feedback. > I don't think you actually want to base any decisions an a vec4 > architecture. Nearly every company in the graphics industry thought that > was a good idea and designed vec4

[Mesa-dev] NLNet Funded development of a software/hardware MESA driver for the Libre GPGPU

(if responding on mesa-dev please do cc me to help preserve the thread, i am subscribed in digest mode, thanks) the NLNet funding application documented here was successful: https://libre-riscv.org/nlnet_2019_amdvlk_port/ we therefore have money (direct payment of tax free, tax deductible

Re: [Mesa-dev] NLNet Funded development of a software/hardware MESA driver for the Libre GPGPU

On 1/9/20, Jason Ekstrand wrote: > Hopefully that makes the trade-off make more sense. One other important > factor is that, even if vec4 could, in theory, be more efficient, it's way > easier to write a compiler if you scalarize everything. hi jason, really appreciated the additional insight.

Re: [Mesa-dev] NLNet Funded development of a software/hardware MESA driver for the Libre GPGPU

On Monday, January 13, 2020, Jacob Lifshay wrote: > On Thu, Jan 9, 2020 at 3:56 AM Luke Kenneth Casson Leighton > wrote: > > > > > jacob perhaps you could clarify, here? > > So the major issue with the approach AMDGPU took where the SIMT to > predicated vector t

Re: [Mesa-dev] NLNet Funded development of a software/hardware MESA driver for the Libre GPGPU

On Tuesday, January 14, 2020, Jacob Lifshay wrote: > On Mon, Jan 13, 2020 at 9:39 AM Jason Ekstrand > wrote: > > > > On Mon, Jan 13, 2020 at 11:27 AM Luke Kenneth Casson Leighton < > l...@lkcl.net> wrote: > >> jason i'd be interested to hear you

Re: [Mesa-dev] Rust drivers in Mesa

fransisco, alyssa et al: you may be interested to know that the Libre-SOC Kazan Vulkan driver, funded by NLnet, is written in rust. https://salsa.debian.org/Kazan-team/kazan the insights and analysis that you are going through is - was - pretty much exactly why we chose it (or, more accurately:

Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sun, Aug 23, 2020 at 10:36 AM vivek pandya wrote: > > Hello all, > > I just cleanup a bit and commited code at : > https://gitlab.freedesktop.org/vivekvpandya/mesa/-/commit/d1f29adf926eb44453db1255834575a6f7169d5f > >

Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver

On Sun, Aug 23, 2020 at 10:19 AM apinheiro wrote: > On 23/8/20 8:11, Luke Kenneth Casson Leighton wrote: > > next step is to add 3D opcodes *directly* to the POWER9 core that we > > are developing. > > Then, in addition to the drivers you already looking as reference, it >

Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver

On Sat, Aug 22, 2020 at 10:34 PM apinheiro wrote: > As Jason mentioned, to get a Vulkan driver started, you would need more > than just one method. If you want a reference: > > https://gitlab.freedesktop.org/apinheiro/mesa/-/commit/07d01ebf6aae2f9ae71a8bea13a5d8acccb6280e > > This commit added

Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver

On Sun, Aug 23, 2020 at 1:56 AM apinheiro wrote: > On 22/8/20 23:59, Luke Kenneth Casson Leighton wrote: > > constructive feedback on this approach greatly appreciated: > > https://bugs.libre-soc.org/show_bug.cgi?id=251#c36 > In any case, those steps look good enough, a

Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver

On Monday, August 24, 2020, Jacob Lifshay wrote: Kazan isn't built on Mesa or NIR (though it was originally intended to > integrate with Mesa). Luke decided that Libre-SOC should also have a > similar Mesa-based driver and applied to NLNet for funding for it, i'm amazed they said yes :) it

Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver

On Sun, Aug 23, 2020 at 8:50 PM Dave Airlie wrote: > I don't want to get involved in half-thought out schemes here, [this has been in the planning stage for... almost 2 years now?] > but I'm > going to indulge myself in one post. appreciated. > The programming model is what designs the

Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver

On Monday, August 24, 2020, Dave Airlie wrote: > > amdgpu is completely scalar, it is?? waah! that's new information to me. does it even squash vec2/3/4, predication and swizzle? what about the upstream amdgpu LLVM-IR? that still preserves vector intrinsics, right? i'm assuming that AMDVLK