Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API: Extend IImage3dFileLoader interface with IsHighPerfMode method #101

Closed

Conversation

forderud
Copy link
Member

Proposal for enabling run-time query if the loader is operating in high-perf (GPU) vs. lower-perf (CPU) mode. (issue #92).

@SteveKauffman
Copy link
Member

In the case that a particular loader is always CPU-based, what is the expected value of IsHighPerfMode? I'd think that it would be 'true', as the expected usage of this API method is to communicate to the user, "we're operating at a lower performance level, but a higher performance level is possible."

Can the comments be updated accordingly?

Copy link
Member

@SteveKauffman SteveKauffman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IImage3d.idl: see my general comment regarding the expected return value of IsHighPerfMode for loaders that have only a CPU-based impl. Can you update the IsHighPerfMode helpstring to reflect this?

@forderud
Copy link
Member Author

@SteveKauffman Looking better now?

Copy link
Member

@SteveKauffman SteveKauffman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, that comment should clarify things.

Done to enable run-time query if the loader is operating in high-perf (GPU) vs. lower-perf (CPU) mode.
@forderud
Copy link
Member Author

Thanks for your feedback @SteveKauffman. I've now rebased the PR, and modified DummyLoader to always return "true" in accordance to the doc.

This is an API change, so let's await merging until our call next week, so that we're sure that all vendors are ok with it.

@forderud
Copy link
Member Author

Decided to defer this API proposal for the time being. We can always reopen i later if/when needed.

@forderud forderud closed this Sep 19, 2018
@SteveKauffman
Copy link
Member

For decision documentation: deferring this API proposal was was decided by the joint technical team in meeting of 2018-09-19. The reason for deferring was that:

  • the lack of this API method is not blocking our next steps forward toward demo of other-vendor loaders on each vendor's workstation

  • concern about how this would be used - if another company's loader is reporting that we're in low-performance mode, your service organization may not want to deal with support for resolving it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants