Changing color of material of grease pencil crashes blender 2.8 #56185

System Information
Windows 10 64-bit
MSI R7750

Blender Version
2.80.21, Date 2018-07-31, Hash 9b817bc168

Short description of error
When you touch the edge of colore whell - blender crashes.

Exact steps for others to reproduce the error
Add greace pencil - blank
Change mode to draw
Draw a stroke
Go to Material
Select Srtoke-Color
Start selecting a color, go to the edge of color wheel - blender crashes
P.S. You must hold left mouse button and make circular moves to crash

Added subscriber: @andergrin

#56901 was marked as duplicate of this issue

Added subscriber: @s12a

It took several seconds of dragging the cursor on the color wheel, but in the end I could reproduce it with 0f449541d2 and:

Windows 10 Pro x64 (1803)
AMD Radeon RX480 4GB with Radeon Software 18.7.1

It does seem to occur only (or at least, within reasonable time) in Draw mode. Probably the main point of interest is this error:

GPUTexture: texture alloc failed. Not enough Video Memory.Error   : EXCEPTION_ACCESS_VIOLATION

blender.crash.txt
console_output.txt

Tested a newer version of blender 2.8 (2018-07-31 23:00) Hash 0f449541d2
on different PC (Windows 7 64-bit, Asus GT630-2GD3)
and can't recreate crash.

I cannot reproduce in my Windows GTX660 system.

I guess that this may be related to the rendering of the preview, maybe some kind of blocking, so maybe depends of CPU/GPU speed. I will keep testing.

Added subscriber: @Endeg

Just want to report, have same problem on latest 2.8.
Using Windows 7 (7601) and AMD R7 200 Series.

Doing couple of strokes, then change stroke color couple of times and eventually blender just closes with this error:

GPUTexture: texture alloc failed. Not enough Video Memory.Error   : EXCEPTION_ACCESS_VIOLATION

System info attached, hope this might help.
system-info.txt

Closed as duplicate of #56491

Changed status from 'Duplicate' to: 'Open'

Ok, so the problem still persist on current (9d00b0f796) version.
I decided to investigate and found that eventually during one of the redraws GP fails to allocate multisample texture which causes crash later. And this happens when we do a lot of redraws just by changing GP material color (circular motions mentioned in ticket).

I tried to skip drawing when texture was not allocated to see what happens, and crash disappeared. Blender still showed video memory error, but kept working and GP too. And error was shown only once.
So I deduced fix to just calling gpu_texture_try_alloc twice in gpu_texture.c before giving up. And looks like it fixed problem on my system: texture was successfully created on second try.

But before sending patch, I'm not very experienced with OpenGL and not sure if this should be considered a proper fix. Could there be any suggestions on how this problem should be tackled?

Added subscriber: @fclem

Not sure if this is the way to go. @fclem could you take a look?

Added subscriber: @AnrtaHayrwe

Changed status from 'Open' to: 'Resolved'

I think this was solved and it was related to preview jobs. We can close and if the problem still exist, we can reopen it.

This is absolutely not solved. Otherwise I wouldn't be making a complete crash report about it (albeit it turned out to be a duplicate even though I searched beforehand) here: https://developer.blender.org/T56901

Changed status from 'Resolved' to: 'Open'

This is t one I wanted reopen..not #56901

Man, what are you doing...

Well, I can definitely confirm that it's still a problem and it's making it extremely hard to learn to use the grease pencil. I understand that what little development time Blender has can't really be spared towards unsupported hardware, but it's kind of a shame. My 7970 is still working quite well and to replace it with something current but of similar power is too costly for me (around 200 euros for something that isn't that much better to replace something that's still working perfectly fine is insanity). Worst of all I can't even sell this card since it's too old to have much value now even though it's still good.

Whew, okay, vented a little. Now back to not learning grease pencil.

@AnrtaHayrwe Could you try setting in the user prefs the multisample of grease pencil to 0?

I canot reproduce in my system, but maybe the error is related to that.

Turn multisample of grease pencil to 0, still crasing.system-info.txt

Added subscriber: @nokipaike

I read this bug report and I wanted to do some tests and I confirm on my radeon 7670 color change and after a few seconds crash

blender-2.80-c3d46694e21-win64.zip Sep 24 2018 00:05:02

Indeed, crashing anyway. You probably haven't read my crash report, but I've actually built it myself to see more details. Here's the screenshot:
https://dev-files.blender.org/file/data/j6pkh4qr35eh54bnxp3d/PHID-FILE-a4angccvhfiexbjbcwfy/BlenderGPcrash2.jpg

Some kind of read access violation. Seems to only happen to GPUs around the 1st GCN generation of AMD cards. Now if I knew C/C++ I'd love to fix it myself but I have no clue what this could mean.

@fclem Do you have any idea here?

@AnrtaHayrwe Can you review in debug mode what is the value of stl->storage->multisamples in GPENCIL_draw_scene() when you set the multisamples to 0?

Try to verify if the macro MULTISAMPLE_GP_SYNC_ENABLE is executed or not.... it's strange you have this if the multisample is set to 0.

@antoniov To me it looks like a GPU mem leak. The texture maybe not freed in the right context or something like that (but there are assert for ensuring that it is the case). Then the driver cannot create the texture for the preview because of insufficient memory.

It is related to the preview drawing. But the leak maybe elsewhere.

@AnrtaHayrwe Try updating the stoke color without any 3D view opened. If it does not crash it might be because there is less textures allocated on the GPU so it's not a very good indicator.

@AnrtaHayrwe Be sure to get the last source code. I have disabled AA for material previews because it's not required.

I disabled my discrete gpu radeon 7670, to see what happens with the intel hd 4000 : blender does not crash, but the color change is terribly slow (rotating the selection of color in the color wheel)

intel not crash and slow

radeon crash

@AnrtaHayrwe Try updating the stoke color without any 3D view opened. If it does not crash it might be because there is less textures allocated on the GPU so it's not a very good indicator.

@fclem
I tried to do this test, without an open 3d view, it takes 3-4 times more time but then crashes the same

I tried also to do the same test with a normal geometry and not crash

@fclem Tried changing the colour on a material without the object showing anywhere and while it did take me about a minute of twerking my mouse around it ended up crashing anyway.

@antoniov I tried debugging with breakpoints on places that had stl->storage->multisamples and MULTISAMPLE_GP_SYNC_ENABLE but I didn't really understand it. Only thing I know is that the value of multisamples was 0 and MULTISAMPLE_GP_SYNC_ENABLE didn't seem to be hit from what VS was telling me. Though once I had those breakpoints and it crashed after changing colour I got stopped at a different place.

I also tried rebuilding again (since I read that message only after finishing the other "testing") with the up to date source but it was exactly the same result.

on linux with the latest mesa 18.3-git.devel drivers
on radeon gpu it seems not to crash
and on the intel gpu is also fast

tested blender-2.80-2abbe1d125f-linux-glibc224-x86_64.tar.bz2 Sep 23 2018 23:04:43

Oh, speaking about Linux, I tried running an Ubuntu VM with Mesa drivers in VirtualBox before and it didn't seem to crash. Though it ran so slowly I didn't have the patience to keep twirling the colour wheel for longer than three minutes. So it seems to be specific to Windows and/or AMD drivers. Which is why I have no real hope of having this fixed by the devs due to support for 1st gen GCN GPUs having been dropped since 2.79.

In #56185#537228, @AnrtaHayrwe wrote:
Oh, speaking about Linux, I tried running an Ubuntu VM with Mesa drivers in VirtualBox before and it didn't seem to crash. Though it ran so slowly I didn't have the patience to keep twirling the colour wheel for longer than three minutes. So it seems to be specific to Windows and/or AMD drivers. Which is why I have no real hope of having this fixed by the devs due to support for 1st gen GCN GPUs having been dropped since 2.79.

if you want to use blender 2.8 on linux with these cards you have to use:
(on the real machine)
https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa

I fought a couple of weeks with the boys of mesa to get rid of the drivers on these radeon :P
unfortunately they are not yet perfect, the esm shadow do not work if you do not disable sbcl and in general the performance is slower than windows
R600_DEBUG=nosb ./blender

Switching to Linux isn't really an option to me, so I only use VMs to test stuff and that's it.

this is my opinion profane ... as it seems that the crash does not happen immediately but only after that this movement saturates somehow a portion of memory assigned to the "cache-buffer of the color" and after it happens to crash, it would not be possible to empty the memory every thousandth of a movement?
in the selection of color there is no need for a history data of color to be stored in memory

@nokipaike @AnrtaHayrwe Can you try running with the command line option -t 1 to put aside any multithreading issue?

Also can you try to reproduce with an eevee material instead of a GP mat? (to make sure it's local to GP)

@fclem Well, dunno if I managed to run it as you wanted (I just started Blender from the command line like this: blender.exe -t 1) but it crashed anyway.

And when it comes to reproducing the crash with normal materials, I wasn't able to crash it no matter how I tried. Works smoothly in EEVEE, OpenGL and Cycles.

One thing I discovered, though, is that it doesn't crash if I change the colour of the GP materials in Cycles or OpenGL. It also changes as smoothly as the normal materials. But once I changed to EEVEE it became sluggish and crashed like usual. I tried again, switching from EEVEE to Cycles/OpenGL right before it crashes and it went back to being smooth again and not crashing, but after I switched back it crashed after a few colour changes. Seems like whatever causes the crash doesn't get reset when changing render engines, but at least it doesn't affect the other engines.

I swear, moving the mouse around in circles so much will worsen my RSI...

I downloaded the latest build and I am no longer able to crash blender
but now he appears on the console:
GPUtexture:Texture alloc failed, not enough Video Memory.

blender-2.80-c4806bbcb9c-win64.zip Sep 25 2018 00:42:57

note: I'm not using official amd drivers, but a hacked version that contains more recent dlls (with yesterday's blender build and these drivers crashing the same)

Also downloaded the latest build but still crashing the same way. I have the official drivers. Version 18.9.2.

@nokipaike While it's not crashing, does it still feel sluggish? Try to compare it with different render engines like I did.

I'm actually pretty happy I discovered that other render engines don't crash. I can at least practice somewhat now.

@AnrtaHayrwe
my gpu is supported up to the legacy drivers that are stopped in 2016 and to remedy put more recent dll of drectx and opengl from the new drivers, so your drivers are newer

I've done other tests and I can not get it to crash anymore

with cycles it does not come out: GPUtexture:Texture alloc failed, not enough Video Memory and the color change is very fluid

with eevee comes out GPUtexture:Texture alloc failed, not enough Video Memory and the color change is sometimes fluid and sometimes gets stuck

with opengl comes out: the color change is very fluid and "GPUTexture: texture alloc failed. Not enough Video Memory" it takes a lot longer to appear

my gpu has 2 GB of memory

as I make movements in the color wheel, sometimes it hangs at the edge of the wheel circumference and moves only around this circumference. in order to start selecting all the colors of the wheel, I have to release the mouse and press again

this strangeness always does it yesterday and even on linux

@nokipaike I see. So we got somewhat similar results.

When it comes to the color wheel, I can confirm the same behaviour. I think this is due to the wheel not locking the cursor in its circumference and letting you go way out of bounds. You can actually come back to the center if you try. Though this behaviour is part of 2.79 as well and probably earlier. While I don't think it should be considered a bug, improving the cursor to be locked inside the colour wheel would make for a better experience. Maybe I'll post this in Right-Click Select or something.

Removed subscriber: @s12a

maybe the problem is right between the color wheel and the cursor ... that somehow the jumps and inconsistencies make badly manage something in the memory of these radeons and cause crashes

look carefully at the color wheel in the upper left corner before the crash appears a thick black shape

@nokipaike ... No, don't think it's that...

Anyway, I've just posted my thoughts on the colour wheel here if anyone cares:
https://blender.community/c/rightclickselect/vdcbbc/

I hope some of the devs actually give their opinion on that since it's one of those small annoyances that seem to be part of every program from what I can tell. Wanna know the reason it hasn't been improved yet.

It seems, the crash is gone. With latest AMD Radeon driver (18.9.2) and todays (25.09.18) Blender build i can't reproduse crash anymore, even with eevee engine. The cursor movment is still a little bit clunky.
P.S. Nope, with EEVEE crash again

Yeah, installed c4806bbcb9 version and with 18.5.1 driver it works properly. Looks like fixed by 2b628ba.
There was still crash on first run but I can't reproduce it so I'm not sure if it's relevant to this issue.

Also, I'm still seeing "GPUTexture: texture alloc failed. Not enough Video Memory." message in console but it happens only once and as I keep circling on color wheel it's not printed anymore.

OK, I've spent some more time testing and I've found some weird fecking results that were the oposite of what I was expecting.

So basically, when the Grease Pencil MultiSample is set to 0 or 2 it shows "GPUTexture: texture alloc failed. Not enough Video Memory." in the console and crashes right away.

But when you set the Grease Pencil MultiSample to 4, 8 or 16 it shows "GPUTexture: texture alloc failed. Not enough Video Memory." in the console but doesn't crash. It just keeps running. And that error only popped up once no matter the settings I changed and how much I tried.

I don't understand why but maybe it could help the devs in some way.

I'd also like to ask @andergrin and @Endeg to try to do the same thing as me to confirm this since you had similar results.

In #56185#537478, @AnrtaHayrwe wrote:

But when you set the Grease Pencil MultiSample to 4, 8 or 16 it shows "GPUTexture: texture alloc failed. Not enough Video Memory." in the console but doesn't crash. It just keeps running. And that error only popped up once no matter the settings I changed and how much I tried.

in fact I have never touched this option and is set to multisample to 4, perhaps because I had saved the custom preferences previously ...

but for the sake of it I did some tests with multisample at 2 and 0 and I did not crash any more

It would be interesting to be able to understand what this depends on:

"GPUTexture: texture alloc failed. Not enough Video Memory."

In #56185#537478, @AnrtaHayrwe wrote:
I'd also like to ask @andergrin and @Endeg to try to do the same thing as me to confirm this since you had similar results.

For me blender crashes with "no multisample", and with multisample: 2 i not able to crash it.

The results seem to be all over the place... But it looks like at least some levels of MultiSample don't crash. So weird...

@AnrtaHayrwe
Ok, for me (still version c4806bbcb9):

No multisample: message in console and crash
Multisample 2, 4, 8, 16: message in console and no crash

Later will try to run it with fix mentioned earlier (https:*developer.blender.org/T56185#531680) to see if problem persist. The diff is here .

It looks like the problem is not about memory but about driver refusing to allocate textures at certain rate. So by adding this double check we give driver some pause to pass texture allocation. Not sure about correctnes of fix but maybe it can give some hint where to dig.

Checked with the fix and and all multisample settings worked without crash. Still getting error message in console. It's strange that this texture allocation fails once and after that seems to work properly.

Tried beta (4c31bed6b4) version. And looks like it's working for me, almost scratched the hole in my tablet.

Still got this in console:
"GPUTexture: texture alloc failed. Not enough Video Memory.GPUTexture: texture alloc failed. Not enough Video Memory."

But no crashes so far. Maybe someone else who got this crash can confirm too?

This issue was referenced by ba1f178c1c

Changed status from 'Open' to: 'Resolved'

Added subscriber: @McLP

This crash/freeze happens instantly on my system. No message in the console. Independent of Draw/Object mode. I believe the is related to my old graphics card (no driver update available). Even freezes without any strokes drawn. Creating a new material does the same.

Operating system: Windows-10-10.0.17134 64 Bits
Graphics card: Intel(R) HD Graphics 4000 Intel 4.0.0 - Build 10.18.10.4425
Blender version: 2.80 (sub 50), branch: blender2.7, commit date: 2019-03-20 01:34, hash: 47ba487e05

Changed status from 'Resolved' to: 'Open'

Added subscriber: @brecht

Changed status from 'Open' to: 'Resolved'

@McLP, please create a new bug report for your case.

Created new report #62838

Removed subscriber: @andergrin

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Changing color of material of grease pencil crashes blender 2.8 #56185