v20 with eGPU?

Discussions, questions, comments and suggestions regarding Capture One PRO, Capture One PRO For Sony / Fujifilm, Capture One for Phase One and Capture One Express For Sony / For Fujifilm 20.x for Mac

Re: v20 with eGPU?

Postby SFA » Sun Dec 29, 2019 11:12 pm

PSS wrote:Staying relevant in photographic terms may mean changing everything to top end mobile phone standards and doing stuff with software to simulate "traditional" photographic images until things get to the point where people no longer care whether what they are looking at is a "real image" or cgi.

Once printed media is a distant memory and all marketing is undertaken via social media why would anything else be necessary - or relevant?

That seems like a philosophical question...
I could not care less how the image is taken or created, it’s all tools...and the more they get out of the way, the better...
personally I would love to use the smallest, lightest capture device possible and the most portable, inconspicuous machine to organize and manipulate the images...all with the highest possible quality of course...
If that happens to be a pair of glasses and some foldable slab with voice commands (that actually work and seem natural to me)....ok with me....
Until then I will try to make my life as easy as possible and deliver the best IQ in the least amount of time


That's all fine.

But for what end purpose?
Last edited by SFA on Sat Jan 25, 2020 12:04 pm, edited 1 time in total.
SFA
 
Posts: 7725
Joined: Tue Dec 20, 2011 9:32 pm

Re: v20 with eGPU?

Postby fatihayoglu » Mon Dec 30, 2019 12:42 am

SFA wrote:
fatihayoglu wrote:I don’t know, maybe updated optimized code for recent hardware rather than 5 yrs old one. Otherwise what’s the need for an updated version, right?


Well one reason for for a new version of anything is to make some new features available so that more types of process can use the 'standard'.

IF the hardware and all levels of software manufacturers adopt the new standard for new products then people buying new products may find some benefit. How much benefit may be unknown. If one has a lot of coding to create in addition to what you already have, only useful to your client base if they upgrade hardware and all sorts of software, the commercial rationale AND the benefit to customers may be something of a mirage.

IF the performance benefits are always going to be huge - say 200% and saving people hours of their time - then you may be able to convince people it is worth the cost of upgrading.

If it's closer to 10% benefit and mostly of interest to hardware geeks for testing results ... maybe not so exciting.

I doubt the lowly GPU on my Notebook would be able to gain much - probably nothing - from a later version of OpenCL and the code that the developers would need to add to make use of it in some way.

As windows user I think I can be fairly sure that it will never make use of Metal - whatever that is.

For most things on my machine whether or not I am using OpenCL does not make much difference at all - yet it is still perfectly usable.

These new standards can often seem to be little more than a marketing tool to shift more product by persuading people to keep "at the cutting edge."

A similar example might be a proposal to change out SSD drives for NVMe drives for the speed advantage.

The number are huge - NVMe drives I/O is, typically , a lot fast than traditional SSD SATA3 drives.

In practical terms where will that speed advantage make a difference?

Should we all rush out and change to NVMe drives because they are faster?

Can I justify converting my NAS (2x8Terrabyte drives) to NVMe because the existing drives are slow IF I use them as a primary storage source working with C1?


Grant


That’s lots of IF’s and blind defending CO for not utilizing current technologies. Since I bought my late 2015 top spec iMac 5K, CO is extremely slow on basic adjustments, that’s about 4 years now. Many people have and still are complaining about the performance of their top spec Macs. Every single time, CO blames Apple because of not putting strong GPU in these machines but we all know that when we bought these machines, they were capable of top class video editing. So, sorry but, if a machine can edit video, for basic photo editing it should fly. Period. No excuse or whatsoever. I’m not talking about DAM or anything. And also, I have realized CO does not utilities GPU for adjustments. Then it is poor or lazy coding, sorry, no excuse there as well. Also Apple has stopped or going to stop with the next release to support OpenCL, that means their code won’t be optimized for OpenCL, one can expect poor performance from applications that demands GPU use. Metal is a framework, written by Apple for Apple HW. We, MAC users, expect all the softwares should support Metal so we work on a optimized system. So it’s not about a company brings something to sell more, it’s a framework. When Java went from version 5 to 6, it wasn’t to sell more products. The code was optimized and cleaned. If you are using a donkey years old code, it contains full of bugs etc. then you can expect bad performance.
fatihayoglu
 
Posts: 259
Joined: Sat Jul 25, 2015 5:57 pm

Re: v20 with eGPU?

Postby verstaerker » Tue Dec 31, 2019 12:50 pm

PSS wrote:I think we were all hoping for switch to metal with v20....oh well, maybe next year...
The mini probably needs the egpu anyway, I am not too concerned with export times, my concern is faster redraw and snappier adjustments....I would expect things to be instant with the egpu vs ok(with a slight lag) with my mbp...
I also do some basic video work which would definitely e easier with the egpu...
having to manually go into system settings sound like a pain...
are you running the egpu into the mini and the monitor from the egpu?


The redraw speed when doing adjustments are totally fine when the correct GPU is actually used.
On my MBP this is only the case if i did the mentioned switch in the system settings or using gfxCardStatus tool.
It's almost instant for typical adjustments. (lets ignore pairing masks .. that's always slow).

on the mini i run the Monitor on the eGPU. Thats better in almost any usecase. Especially when doing video editing i noticed quite lower fps when having the monitor on the mini.
verstaerker
 
Posts: 20
Joined: Thu Jul 14, 2011 11:35 am

Re: v20 with eGPU?

Postby SFA » Tue Dec 31, 2019 2:28 pm

fatihayoglu wrote:That’s lots of IF’s and blind defending CO for not utilizing current technologies. Since I bought my late 2015 top spec iMac 5K, CO is extremely slow on basic adjustments, that’s about 4 years now. Many people have and still are complaining about the performance of their top spec Macs. Every single time, CO blames Apple because of not putting strong GPU in these machines but we all know that when we bought these machines, they were capable of top class video editing. So, sorry but, if a machine can edit video, for basic photo editing it should fly. Period. No excuse or whatsoever. I’m not talking about DAM or anything. And also, I have realized CO does not utilities GPU for adjustments. Then it is poor or lazy coding, sorry, no excuse there as well. Also Apple has stopped or going to stop with the next release to support OpenCL, that means their code won’t be optimized for OpenCL, one can expect poor performance from applications that demands GPU use. Metal is a framework, written by Apple for Apple HW. We, MAC users, expect all the softwares should support Metal so we work on a optimized system. So it’s not about a company brings something to sell more, it’s a framework. When Java went from version 5 to 6, it wasn’t to sell more products. The code was optimized and cleaned. If you are using a donkey years old code, it contains full of bugs etc. then you can expect bad performance.


You make a lot of assumptions. Notably that new code (really additional code options when talking OpenCL as far as I can tell) has less bugs than old code. I seriously doubt that but if you have evidence from a broad base of developments I will happily change my mind.

Java was actually a great example of where developer would freeze their code to a "known good" (for them) version in order to avoid having to constantly battle with conflicting updates. They would ensure that their installation always included a version of Java they were OK with.

Certainly at some point they would need to move on - but there is no point in a smaller developer battling the latest (and allegedly greatest) of everything unless some specific benefit accrues to their product and they hope that makes it worth battling with the early adopter issues. Adobe may have the resources and influence to take things on, not least because they can spread any benefits across a very wide product range, some of which is in the development tools sphere of influence anyway. So they have to make the effort to stay in that market and once done it's logical to roll out the results through the rest of their products.

For many other developers that is not so obviously the case.

Nothing I have read about OpenCL suggest that any version, widely adopted or not, is a panacea for for high speed processing in any situation.

Indeed Apple, which initially created OpenCL, seems to be intent on moving on to other things that suit its purpose and that potentially means that dual platform vendors may see less point in chasing OpenCL for its portability - one of the main marketing points for the technology.

That and the apparent effect that increasing the technology base and complexity of any product tens to mean that optimum results only come with very exact tuning of parameters to available features and functions. Without that disappointment may follow.

That's a big overhead and carrying it will be of potential (but not certain) benefit to a small number of existing users and a some others who end up upgrading their hardware to new equipment that itself is keeping up with the technology in ways that go beyond just including the ability to support a recent iteration of the code if anyone has used it.

And a basic internal communication system configuration that can deal with the data volumes at the speeds that allows the technology to appear to be effective to a human user.

I keep looking for something that suggests that the great wow factor and excellent "bang for buck" result from OpenCL2.x.

If anyone has a link I'd love to read what it says.


Grant
Last edited by SFA on Fri Jan 03, 2020 9:58 pm, edited 1 time in total.
SFA
 
Posts: 7725
Joined: Tue Dec 20, 2011 9:32 pm

Re: v20 with eGPU?

Postby KrishnaKotti » Fri Jan 03, 2020 3:57 pm

verstaerker wrote:i'm using CO 20 on a mac Mini with Blackmagic eGPU Pro. It's definitely using it. It's important to have the "prefer external GPU" option on. When adjusting image the usage is around 30-50%. When exporting it's near 100%.

On my Macbook Pro it's only using the AMD GPU if i switch off the system-setting "automatic change of graphic-mode“ (wich enforces the AMD GPU to be used at all times) .

I was in contact with the support about it. I demonstrated in a video the behavior. Since then i haven't heard back from then.

It would be good if they could use Metal2 instead of openCL .. i'm sure the performance would increase a lot.


What is this option prefer external GPU ? How do we have this option on ?
KrishnaKotti
 
Posts: 6
Joined: Fri Jun 01, 2018 3:36 pm

Re: v20 with eGPU?

Postby verstaerker » Sun Jan 12, 2020 5:15 pm

KrishnaKotti wrote:
What is this option prefer external GPU ? How do we have this option on ?


in finder on the app-icon, rightclick Information ... there is a checkbox "prefer external GPU"
verstaerker
 
Posts: 20
Joined: Thu Jul 14, 2011 11:35 am

Re: v20 with eGPU?

Postby verstaerker » Sun Jan 12, 2020 5:28 pm

btw i'm using CO now on a MacPro 2019 with a VegaII .. this runs like a dream. Absolutely great.
Except the masking tool with AutoAdjustment on
verstaerker
 
Posts: 20
Joined: Thu Jul 14, 2011 11:35 am

Re: v20 with eGPU?

Postby Whitesnake » Sat Jan 25, 2020 7:42 am

Since my Mac Mini my eGPU isn't fully used during exporting pictures. I opened a thread: https://forum.phaseone.com/En/viewtopic.php?f=71&t=37458&p=177162#p177162

Does anyone experience something similar? Funny fact is, that the Mac Mini is a little bit faster than the Macbook Pro. But I would like to know why the eGPU isn't used. Only difference between the systems is OS and the size of internal the SSD.
Whitesnake
 
Posts: 38
Joined: Tue Apr 13, 2010 8:39 pm

Re: v20 with eGPU?

Postby SFA » Sat Jan 25, 2020 12:10 pm

Whitesnake wrote:Since my Mac Mini my eGPU isn't fully used during exporting pictures. I opened a thread: https://forum.phaseone.com/En/viewtopic.php?f=71&t=37458&p=177162#p177162

Does anyone experience something similar? Funny fact is, that the Mac Mini is a little bit faster than the Macbook Pro. But I would like to know why the eGPU isn't used. Only difference between the systems is OS and the size of internal the SSD.


Isn't used or isn't FULLY used?

Usage of a GPU does not imply bypassing all other computer processes not that the the available data transfers rates in the computer and to and from the GPU can force 100% utilisation.

Furthermore there may be power demands that have to be managed and heat controls to apply.

Given the nature of the operation you may also need to consider the reporting resolution of whatever you are using to monitor performance.


Grant
SFA
 
Posts: 7725
Joined: Tue Dec 20, 2011 9:32 pm

Re: v20 with eGPU?

Postby Whitesnake » Sun Jan 26, 2020 9:35 am

Isn't fully used (it's used approx. 60 %). The Macbook Pro used 100% of the eGPU.
Whitesnake
 
Posts: 38
Joined: Tue Apr 13, 2010 8:39 pm

Re: v20 with eGPU?

Postby SFA » Sun Jan 26, 2020 10:11 am

Whitesnake wrote:The Macbook Pro used 100% of the eGPU.


For what does the Macbook use the eGPU 100%?

By that I mean "What is the Macbook doing (by itself) that requires 100% use of the eGPU?"
SFA
 
Posts: 7725
Joined: Tue Dec 20, 2011 9:32 pm

Previous

Return to Capture One 20.x Software for Mac



Who is online

Users browsing this forum: No registered users and 2 guests