In rB1aed77cacac4c4f560b8c87e73c109b7021dd1b3#194493, @Brecht Van Lommel (brecht) wrote:

Pugixml is still bundled with OpenImageIO as before, do we really need it as a separate library?

@nBurn (nBurn) transferred the page, link has been updated.

there's some discussion about this in D3581 as well.

fixed the wiki links, @Sergey Sharybin (sergey) can you transfer dependency graph design to the new wiki? (had to place a en.blender.org link for now)

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.

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)

• make the diff apply cleanly.

known issue see T54152 and D3079 which frustratingly have been held up

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)

In D3576#82344, @Sergey Sharybin (sergey) wrote:

Have mixed feeling here. On the one hand, having for official this might help. But then what do we do with nightly builds?

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?

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'

@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.

probably easier if they look directly at D3573 which appear to be the same patch.

please attach a failing .svg file

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

looks like i have no commit rights to rBM yet, @Aaron Carlisle (Blendify) can you set me up?

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'

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

this is as expected, this card is no longer supported

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.

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.