Looking at the preview window with different zoom settings changes the way it is corrupted, notice the gaps between bars is zoomed

In T80912#1018997, @Daniel Pocock (pocock) wrote:

I provided a test file, please see the earlier comment "Here is a sample blend file that reproduces the problem", it is a link to the files on Gitlab.

I tried using an updated ffmpeg 4.3.1 backport, that didn't make any difference

I ran ffplay from the command line with each of the video files used in the Blend file.

I provided a test file, please see the earlier comment "Here is a sample blend file that reproduces the problem", it is a link to the files on Gitlab.

Note that this report is still missing:

Can you check if other software using ffmpeg plays this properly? (video editors, players)

none of those are used in the VSE, for all i know ffmpeg is delivering the frame to us like this, a developer will have to look at this, throwing random things at the wall going "could it be this?" doesn't seem like a good use of anyone's time.

Using find, I found three places in the source tree where the logic is not right for ppc64el

In T80912#1018643, @Richard Antalik (ISS) wrote:

Regarding endianness it seems we rely on __BIG_ENDIAN__ and __LITTLE_ENDIAN__ symbols to be defined correctly, but they are not defined in GCC. I don't build on Linux so I don't know if this has to be defined explicitly somewhere in make files. @Ray molenkamp (LazyDodo) Are you familiar with this?

Another problem I sometimes see when porting code is that the size of data types is not correct for every architecture, for example, the gcc on that architecture uses 64 bits for a type but the developer has guessed it is 32 bits and hardcoded that somewhere. I feel that in this case, that is less likely than an endianess issue but can't be completely sure.

Here is a sample blend file that reproduces the problem

I can see that little endian is detected at the configure step and the gcc compiler is called with -DLITTLE_ENDIAN on the command line.

Regarding endianness it seems we rely on __BIG_ENDIAN__ and __LITTLE_ENDIAN__ symbols to be defined correctly, but they are not defined in GCC. I don't build on Linux so I don't know if this has to be defined explicitly somewhere in make files. @Ray molenkamp (LazyDodo) Are you familiar with this?

As an endianness issue, I was concerned that some part of the code may see that it is running on ppc and wrongly assume all ppc == big endian. I've seen similar problems in other code.

This doesn't look like GPU issue, since whole preview region is pushed to GPU as one texture.
Also I am not sure if this would be endianness issue, since x86 is also little endian.

I tried building 2.90.0 as a Debian package, it also has the same bug.

Yes, I'm happy to test it and create a sample blend file demonstrating the problem

Hi, apparently it still happens... I'm trying to use blender on my laptop with Intel graphics and the exact same thing happens. Too bad because I need it for school :/

My bad, apologies for the noise! It's working fine. For posterity, I was missing this library: libnvoptix1. Again, thanks for the help.
Please close this ticket.

I'm going to have to rescind my previous post actually. Today, it's gone back to crashing again. Happens within 30-60 seconds of starting blender. GPU just hangs. Also seeing a report(https://gitlab.freedesktop.org/drm/intel/-/issues/2380#note_611990) on the Intel gitlab that 2.83.5-2 is still crashing for another user, only that it's taking up to an hour to occur instead of minutes for them.

In T77466#1004981, @Andrew Dionne (CepheidVariable) wrote:

It's worth noting, that somewhere between my post on August 17th, and August 21st, when the most recent Arch Linux build of Blender was packaged(At the time of this post,) a pull request was done that fixed the GPU hang on Blender's side, rather than the driver side. Version 2.83.5 still hangs the GPU, but 2.83.5-2 in Arch Linux does not.

So, it looks like our three possible choices are to use 2.82, the latest git version, or switch from the Iris driver, as Timothy suggested.

I'd still like to find the cause, though... So I'll get off my lazy posterior and get to work on poking the Linux kernel.

It's worth noting, that somewhere between my post on August 17th, and August 21st, when the most recent Arch Linux build of Blender was packaged(At the time of this post,) a pull request was done that fixed the GPU hang on Blender's side, rather than the driver side. Version 2.83.5 still hangs the GPU, but 2.83.5-2 in Arch Linux does not.

I've been looking all over for a way to fix this and I think I finally found one!

The problem persists with the 23 August 2020 Beta version: blender-2.90.0-ebf10b72b05f-linux64.tar.xz

Further testing shows that it works correctly with the X.Org X server driver, but not various versions of the NVIDIA drivers, see below.

That is definitely happening to me with Blender version 2.83.5.

If Blender isn't receiving the event, we cannot realistically resolve this on our end.

Right, so as a bit of practice in learning new software development techniques, I took the time to use my PC to bisect the commit in which this particular problem shows up.

Same here. Out of nowhere, I get:

When I use Blender 2.9 and I want to use the keys [Ctrl]+[A], for instance, the key [Ctrl] does then not work properly any more in Blender, I can then no more activate it! I discovered that it was not because of a bug in Blender, but that it happened, but when I activated in the same time another program in de Ubuntu O.S., namely the software named "Tweaks", which has a function in it under the menu "Keyboard & Mouse" called "Pointer Location (Press the Ctrl key to highlight the pointer)'. Funnily , when the key [Ctrl] is activated in the software "Tweaks", then the key [Ctrl] is desactivated in "Blender".

It highlights the cursor. Rather than a ctrl press event, we get a window deactivated event, and only a release event afterwards. xev shows the same thing, so it's not Blender specific.

I'm not familier with this feature.

Does sampling work in 2.9 or is this in 2.91? Also are we able to sample outside of the blender window/env, like another program/window running in Windows, or ONLY in blender?

I tried it with two laptops. One is a Macbook with Boot Camp, which doesn't allow me to use the Intel GPU.
It didn't work in any configuration.

I can't reproduce the problem:

I can't get this feature to work at all unfortunately. Neither on Linux, nor macOS or Windows. Latest master that is.

Can confirm.

Even if the current behavior is preferred under some conditions, it feels like a bug - especially when painting for example.

Is there a way for a non-coder to diagnose this under Linux? I would like to help in any way I can.