- User Since
- Feb 14 2012, 12:24 AM (438 w, 6 d)
May 21 2019
For posterity - The Logitech MX Anywhere 2s mouse middle mouse button also doesn't work with Blender 2.80.
The Logitech "Options" software does not appear to help in any way. I am returning the $80 product.
Dec 14 2018
Sep 29 2016
I'm pleased to report that the test file is now rendering correctly on the latest BuildBot Blender builds. Please close this bug report.
Sep 10 2016
Thanks for the troubleshooting tips. I've retested with blender-2.78.0-git.1558f5b-windows64 (2016-09-09)
Sep 8 2016
The latest BuildBot builds will utilize over 11GB of VRAM when rendering using the new Cycles displacement feature. So, Blender appears capable of accessing most of them VRAM on the card with a different scene.
Sep 7 2016
Just re-ran the 256 x 215 tile test with Simplified enabled and received the following errors (duplicate/info lines removed):
Sep 5 2016
After a reboot, I ran another render test at 256 x 215 tile size and Blender produces the following error (duplicate lines removed):
Testing has always been done after a fresh reboot. I'm not sure how that impacts VRAM fragmentation. Let me know if that would rule it out as the culprit.
Aug 27 2016
Aug 26 2016
I can attempt a driver roll back and test again. T49113 describes a Linux driver that causes crash on F12. The behavior here is on Windows 10 and crashes part way through the render.
Let me know if there are instructions for generating more detailed Blender crash details.
Driver Version 372.54 - WHQL
Driver Release Date Mon Aug 15, 2016
Aug 25 2016
I tested again with today's BuildBot build and Blender is now crashing during render instead of throwing CUDA errors.
Aug 24 2016
I'm seeing similar errors on a Titan X Pascal. It's reproducible on the latest BuildBot builds with the "Victor" benchmark file located here: https://code.blender.org/2016/02/new-cycles-benchmark/
The error varies depending on tile size, I've included both below. GPU-Z indicates the card has VRAM to spare during the error. Windows TDRDelay timeout value set to a generous 120 secs.
Please advise if I should create a separate bug report.
Dec 20 2014
Hooray! The commits you have made here have fixed the issue - http://www.miikahweb.com/en/blender/git-logs/commit/7a04c7f6d02a90388e722bf3a600327b52c744ac
Thank you the effort Sergey. This is a win for Blender UV unwrap scalability.
Dec 19 2014
Sorry if I wasn't clear. From your comments earlier:
Hi Sergey - Others have confirmed that this is not an OS or hardware issue but indeed appears to be a Blender software crash behavior introduced in 2.72. Confirmation here:
Are there troubleshooting steps that could help us find the root cause?
Blender 2.73 Test Build also exhibits this behavior.
Nov 16 2014
Hi Sergey. Can you explain how your LU solver comment applies when there are GB of free RAM? Any information is appreciated.
Nov 5 2014
LU solver double precision sounds like a good design call.
Oct 30 2014
I've run another couple of tests with 2.72b and RAM utilization never reaches above 18% (12/64 GB) during unwrap and when the crash occurs.
Oct 21 2014
Jun 20 2014
Hi Gang - This bug appears to have been fixed via duplicate bug https://developer.blender.org/T40228
Mar 29 2014
@jucyfruit - A test using BuildBot blender-2.70-b64bdb2-win64-vc12.zip (2014-03-29 VS2013) still exhibits the issue. Thanks for the tip though.
Mar 27 2014
Additional Info (thanks to cegaton): Render completes when lowering MIS Map Resolution to 180 or below
Additional information on this issue including repro steps can be found here:
The issue appears with multiple GPUs enabled and Multiple Importance Sampling enabled in World settings.