- User Since
- Oct 2 2014, 3:13 PM (202 w, 4 d)
Sun, Aug 19
Fri, Aug 17
Thu, Aug 16
@nBurn (nBurn) transferred the page, link has been updated.
Wed, Aug 15
Tue, Aug 14
there's some discussion about this in D3581 as well.
Mon, Aug 13
Sat, Aug 11
Fri, Aug 10
commited in rBe2f006949fbd
the main difference is the old hinter did both horizontal and vertical hinting, the new one only does vertical, hence a little more horizontal blur. selecting the old interpreter is literally a one liner but i'm gonna leave it up to the UI guys to decide what they want here, regardless this shouldn't hold up any lib upgrade.
Thu, Aug 9
I have brought up cleaning up /extern i the past, and from what I get it's mostly there as a convenience for the linux platform, i'm kinda digging the WITH_SYSTEM_* thing and wouldn't mind transferring some of the libs in /extern that have no local changes (like ceres) over to svn once we finish the current batch of lib updates. That way linux users can still have the code easily available in the version we like, but the mac/windows users don't have to build the same thing that never changes over and over again (last time i checked ceres alone was about 12% of the complete blender build time)
Wed, Aug 8
- make the diff apply cleanly.
Tue, Aug 7
also we could bump the following libs a little further if we wanted to
This can't be split up, due to openjpeg living both in the binary deps and lives in /extern they have to match and be of the same version or the linker will have a bad time linking oiio (atleast on windows, but i can't imagine mac would be any different)
Mon, Aug 6
Uploading symbols to the processing server is part of the build process.
the reporting server takes care of most of it (tosses out the personal information, runs the stack trace and groups it by common crash locations)
The patch is cherry picked from freetype git (and should be in 2.9.2 or whatever the next version may be) i didn't expect it to cause issues on other platforms?
Sun, Aug 5
It's some kind of deg threading issue by the looks of it, can't repro in debug, can repro in release, can't repro when starting release with '-t 1'
Sat, Aug 4
@Bastien Montagne (mont29) these things are terribly difficult to troubleshoot, it's generally environmental (gpu drivers, os updates, overclocking, software being installed along side blender,etc etc etc) and not a bug in blender. given these cases are generally isolated incidents, we could probably locate the issue with a lot of back and forth but i don't feel it's a great use of time.
Fri, Aug 3
Wed, Aug 1
probably easier if they look directly at D3573 which appear to be the same patch.
Tue, Jul 31
Sun, Jul 29
please attach a failing .svg file
Fri, Jul 27
The default paste for a feature requests has some links
Also the whole 'gpu likes larger tiles' no longer holds true.
tested a few times, seem all-right now
Thu, Jul 26
Wed, Jul 25
oh yikes, you should have probably zipped that before uploading, that 159 MB file got compressed down to under 7 MB here when using 7zip.
I'd probably look into running procmon and see what binaries are being loaded , if you attach a trace i'll take a quick peek if anything iffy stands out.
looked some more into this, looks like chrome ran into a similar issue coming from math.h, all i can say is 'yikes'
Tue, Jul 24
look into why it's linking gflagsd.lib and where it is coming from,
it's highly suspicious that it is picking up a library for gflags.dll we link everything static,it kinda sounds like it's picking up some other library off your system.
i'm gonna have to close this as per tracker rules
Mon, Jul 23
Jul 20 2018
this is as expected, this card is no longer supported
Jul 19 2018
please do not assign priority your self.
@Clément Foucault (fclem) looked some more into it tonight looks like there's no texture-handles leaking (every texture created has a matching delete), however the reason the memory usage in gpu-z get so high is because once you call glDeleteTextures the texture handle gets freed, but the actual buffer in gpu memory the opengl implementation is free to do whatever it wants, including hanging on to it just in case some new texture needs it and save it self an allocation. I don't think there's an actual leak here (or at-least anymore)
we dropped support for fermi from the code, 2 won't work.
Jul 18 2018
Thank you for the report. Currently we are aware of many issues in 2.8 and actively working to fix them. But since replying to reports takes time, we have decided to limit bug reports to crashing bugs only at this point in time.