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

added constructors to MTLRegion #165

Closed
wants to merge 4 commits into from
Closed

added constructors to MTLRegion #165

wants to merge 4 commits into from

Conversation

adamnemecek
Copy link
Contributor

No description provided.

@@ -31,6 +31,37 @@ pub struct MTLRegion {
pub size: MTLSize,
}

impl MTLRegion {
#[inline]
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm curious to hear more about where you feel the line should be for abstractions around the raw metal APIs?

Mainly looking to better understand the motivation / thought process here.

More specifically, why should this land?

Cheers!!

Copy link
Collaborator

@chinedufn chinedufn Jul 30, 2020

Choose a reason for hiding this comment

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

Ah I see https://developer.apple.com/documentation/metal/1516011-mtlregionmake1d

Mind making names consistent with Metal and linking to the Metal docs as a doc comment for each function?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As far as naming, you need to strike a balance between the metal idioms and rust idioms. What do you suggest these be called? We already diverge from the make prefix e.g. new_render_command_encoder is called makeRenderCommandEncoder in metal.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think one of the most important flows to support is

  1. Person looks up Apple’s Metal Docs for how to do something

  2. Person looks for the equivalent in metal-rs

  3. Person finds what they need quickly

Given that goal (I’m just speaking for myself, you might think that’s a silly goal!) I’d say that the only changes we should make to function names or parameters is

  1. snake casing because it’s more rusty and you’ll still be able to find what you’re looking for

  2. More appropriate types such as accepting a &Path instead of an NSString when we need a file path.

As such, I’d personally lean towards calling these make_1d, make_2d and make_3d.

I’d say that the divergence in the render command encoder creator fits under the umbrella of #144

These are just my thoughts, will wait on @kvark

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So these should be functions or constructors?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah sorry, I meant MTLRegion::make_1d etc constructors

Copy link
Contributor Author

@adamnemecek adamnemecek Jul 31, 2020

Choose a reason for hiding this comment

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

I would still lean towards the "new" nomenclature since there isn't a single instance in metal-rs of a function starting with "make".

Copy link
Contributor Author

@adamnemecek adamnemecek Jul 31, 2020

Choose a reason for hiding this comment

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

@kvark suggests renaming all functions (not just these but like in the whole framework) to "make" (pun intended) to be in line with metal. How about we merge this in and rename it with the rest if we decide to do that?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I just appreciate this PR in the first place so - I won’t stand in the way! That plan sounds fine to me.

Maybe just still add the doc comment linking to the corresponding Metal docs?

I think we should do that for all constructors/functions/methods/types/etc going forwards.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Oh and I still think these should at the very least be 1d 2d instead of d1 d2 ... but again ... I won’t stand in the way and bike shed this !

Copy link
Contributor

@monocodus monocodus bot left a comment

Choose a reason for hiding this comment

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

This is an autogenerated code review.New suggestions: 3

The .monocodus config not found in your repo. Default config is used.
Check config documentation here

@@ -112,6 +168,7 @@ fn main() {
WindowEvent::CloseRequested => *control_flow = ControlFlow::Exit,
WindowEvent::Resized(size) => {
layer.set_drawable_size(CGSize::new(size.width as f64, size.height as f64));

Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change

generated by rustfmt

@@ -162,7 +219,15 @@ fn main() {

let command_buffer = command_queue.new_command_buffer();
let encoder = command_buffer.new_render_command_encoder(&render_pass_descriptor);
encoder.set_render_pipeline_state(&pipeline_state);

encoder.set_scissor_rect(MTLScissorRect { x: 0, y: 0, width: 100, height: 100});
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
encoder.set_scissor_rect(MTLScissorRect { x: 0, y: 0, width: 100, height: 100});
encoder.set_scissor_rect(MTLScissorRect {
x: 0,
y: 0,
width: 100,
height: 100,
});

generated by rustfmt

encoder.set_vertex_buffer(0, Some(&clear_rect_buffer), 0);
encoder.draw_primitives_instanced(metal::MTLPrimitiveType::TriangleStrip, 0, 4, 1);

encoder.set_scissor_rect(MTLScissorRect { x: 0, y: 0, width: size.width as _, height: size.height as _});
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
encoder.set_scissor_rect(MTLScissorRect { x: 0, y: 0, width: size.width as _, height: size.height as _});
encoder.set_scissor_rect(MTLScissorRect {
x: 0,
y: 0,
width: size.width as _,
height: size.height as _,
});

generated by rustfmt

@adamnemecek
Copy link
Contributor Author

adamnemecek commented Jul 31, 2020 via email

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