Search the Community
Showing results for tags 'macos'.
Found 4 results
Can Vectorworks add a "compute on GPU" option to Renderworks modes? OR, if the programming obstacles are too high, can Vectorworks create a new class of rendering modes that are run on GPU compute so they massively faster than raytracing on a CPU, but with more fidelity options than OpenGL? I'm happy to say; I just got a screaming fast video card for my primary workstation. This is primarily to have enough VRAM for Vectorworks' VRAM-hungry OpenGL render mode. On my main machine I've gone from the AMD "Pro" 460 discrete internal GPU with 4 GB, to an RX580 with 8GB for about a year in an eGPU, to now a Radeon VII with 16 GB of the fastest VRAM on the market. Around my office, we also have a Titan X(p) in our windows machine and a few Vega FEs with 12GB and 16GB respectively. To be clear, we don't run out of VRAM on the 12GB+ cards, I just got the VII because of the 1TB/s HMB2 is as fast as it gets without spending all the dollars; and Vectorworks is a connoisseur of VRAM. The difference in framerate stability and model pop-in is quite noticeable with each step up that ladder when working in big files. However, the amount of processing power that Vectorworks utilizes on those ever more expensive cards is largely flat for a given resolution. Anecdotally meaning: a model that would utilize 90% of the GPU clock on my 460, will utilize maybe 65% on my 580, and less than 40% on my VII. While dropping many thousands of dollars on video cards and enclosures has absolutely made the user experience a more pleasant and stable one, when it comes time to do a high quality render, most of our users are back down to 4 CPU cores. The performance difference is so stark, that we have a dedicated workstation just for rendering-out big packets with a 14 core Xeon. I'm contemplating a 64-core Ryzen down the road, but good golly it would be nice to dump off something like a ray-traced render to a piece of hardware that is purpose built for something so easily made massively multithreaded. like a GPU. Maybe this means tearing Renderworks down to the ground.... but Apple is always going on about how easy it is to move code written in C over to Metal. So, while I waited 28 minutes for my render to export, I figured I should suggest it. I was frankly surprised by how quickly the developers of DaVinci Resolve put out a Metal API enabled export module, and really impressed by the 20-30% speed increase over OpenCL. I know that some users will try to use a GPU-compute mode on integrated-GPUs that are like to see worse performance. However; unlocking horsepower for the typical user that has a capable discreet GPU would save me, for one, dozens of man-hours per week I imagine. The dialog could even offer some low grade benchmark to let the use know what the time difference would be for a given set of hardware. Food for thought.
With macOS 10.15 Catalina due to be released next month (and the long-known fact that 32-bit apps will no longer work after 10.15), I used Go64 to check and see if all parts of Vw2020 report as being 64-bit, and there are still two applications inside the Vw package which report as being 32-bit: python 3.5-32 libxerces-c-3.0.dylib Are either of these 32-bit applications going to prevent Vw2020 from running properly under macOS 10.15 Catalina? Thanks. [Tech Support Ref. No. VSS-92289]
I've finally had it, I've given up on thinking Apple will ever fix Preview.app. It's only gets worse with each release. Now there's a bug that makes our mark ups unreadable on other computers. So what are the best alternatives from an AEC point of view?