It took several seconds of dragging the cursor on the color wheel, but in the end I could reproduce it with 0f449541d2e 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

Tested a newer version of blender 2.8 (2018-07-31 23:00) Hash 0f449541d2e
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.

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.

Not sure if this is the way to go. @Clément Foucault (fclem) could you take a look?

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

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.

@Alexander Chaplinskikh (AlexChaplinskikh) 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.

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.

@Clément Foucault (fclem) Do you have any idea here?

@Alexander Chaplinskikh (AlexChaplinskikh) 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.

@Antonio Vazquez (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.

@Alexander Chaplinskikh (AlexChaplinskikh) 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.

@Alexander Chaplinskikh (AlexChaplinskikh) 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

@Alexander Chaplinskikh (AlexChaplinskikh) 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.

@Clément Foucault (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

@Clément Foucault (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.

@Antonio Vazquez (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 T56185#537228, @Alexander Chaplinskikh (AlexChaplinskikh) 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

@noki paike (amonpaike) @Alexander Chaplinskikh (AlexChaplinskikh) 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)

@Clément Foucault (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.

@noki paike (amonpaike) 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.

@Alexander Chaplinskikh (AlexChaplinskikh)
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

@noki paike (amonpaike) 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.

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

@noki paike (amonpaike) ... 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 c4806bbcb9c 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 @Andrii (andergrin) and @Andrey Gladyshev (Endeg) to try to do the same thing as me to confirm this since you had similar results.

In T56185#537478, @Alexander Chaplinskikh (AlexChaplinskikh) 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 T56185#537478, @Alexander Chaplinskikh (AlexChaplinskikh) wrote:

I'd also like to ask @Andrii (andergrin) and @Andrey Gladyshev (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...

@Alexander Chaplinskikh (AlexChaplinskikh)
Ok, for me (still version c4806bbcb9c):

• 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 (4c31bed6b46) 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 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: rB47ba487e05da

Created new report T62838