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

Rebuild high level on top of LL #1466

Closed
Bastacyclop opened this issue Sep 2, 2017 · 4 comments

Comments

@Bastacyclop
Copy link
Member

commented Sep 2, 2017

1 - Rebuild gfx_render

First, we need to rebuild gfx_render on top of the new low level core.
It will incorporate the old features from gfx_core and gfx_render:

  • Resource handles
  • Mapping tracking
  • Factory and Device, with the new terminology Device and Queue
  • Encoder will not be Send anymore and rely on pools
  • Slice, see #1392
  • Pipeline mecanisms, see #1429

2 - Split gfx_app

Then, we want our crates to have clearer identities as discussed in gitter. That's why the old gfx_app will be split into three components:

  • Utility code for the examples will live in the examples directory
  • Utility code for the user will be moved into gfx_render (backend-agnostic)
  • Backend selection will be the responsibility of a new gfx_frontend crate

3 - Improve

After these two steps, we will probably have a lot of polishing to do!

@msiglreith

This comment has been minimized.

Copy link
Member

commented Sep 2, 2017

Thanks for taking a stab at this topic!
The mentioned points sound good so far.

Relevant discussion (but also partially outdated): #1281

bors bot added a commit that referenced this issue Sep 10, 2017

Merge #1476
1476: [ll] Frames and encoders for render r=kvark a=Bastacyclop

Working on #1466.
This is an untested draft, I hope there are not too many mistakes.
The interesting stuff is in [core/pool](https://github.com/gfx-rs/gfx/compare/ll...Bastacyclop:ll?expand=1#diff-a8c8cf11be50bbdb6bab730b503bfe00), [render/device](https://github.com/gfx-rs/gfx/compare/ll...Bastacyclop:ll?expand=1#diff-a505eeca0919c44fc9d868f9a1cbdfe3) and more importantly [render/encoder](https://github.com/gfx-rs/gfx/compare/ll...Bastacyclop:ll?expand=1#diff-e76accb5ddad96024c8ebca0ad05ee68) and [render/lib](https://github.com/gfx-rs/gfx/compare/ll...Bastacyclop:ll?expand=1#diff-be2c920c08146924af4d1983d6894d63).
My next step will be to test it in a copy of the quad example.

You can acquire `encoder::Scope`s from which you can get actual `Encoder`s. An `encoder::Scope` is basically a more convenient command buffer pool. So there are two reasons to use multiple scopes: to use multiple encoders at the same time (multithreading mostly) and to release all the acquired encoders independently (different encoding scopes). Maybe scope is not a good name and I should name it simply pool instead.
@Bastacyclop

This comment has been minimized.

Copy link
Member Author

commented Sep 12, 2017

Things to do after the first render implementation:

@kvark kvark added this to the Low Level release milestone Sep 15, 2017

@msiglreith msiglreith added the api: ll label Oct 28, 2017

@kvark kvark removed this from the HAL 0.1 release milestone Jan 22, 2018

@kvark

This comment has been minimized.

Copy link
Member

commented Dec 28, 2018

This is somewhat addressed by Rendy now
cc @omni-viral

@kvark kvark closed this Dec 28, 2018

@omni-viral

This comment has been minimized.

Copy link
Contributor

commented Dec 29, 2018

Rendy doesn't have all necessary tools. Yet it already can do many things that good ol' gfx does for you.
As rendy is going to replace gfx in amethyst it ultimately will get all tools one needs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.