This issue was automatically generated. Feel free to close without ceremony if you do not agree with re-licensing or if it is not possible for other reasons. Respond to @cmr with any questions or concerns, or pop over to #rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer) published a crates.io package with the license as "MIT" xor "Apache-2.0" and the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that license is good for interoperation. The MIT license as an add-on can be nice for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright header with different names in the copyright field, for every MIT library in use. The Apache license does not have this drawback. However, this is not the primary motivation for me creating these issues. The Apache license also has protections from patent trolls and an explicit contribution licensing clause. However, the Apache license is incompatible with GPLv2. This is why Rust is dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for GPLv2 compat), and doing so would be wise for this project. This also makes this crate suitable for inclusion and unrestricted sharing in the Rust standard distribution and other projects using dual MIT/Apache, such as my personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really require reproducing the whole thing?" I'm not a lawyer, and I can't give legal advice, but some Google Android apps include open source attributions using this interpretation. Others also agree with it. But, again, the copyright notice redistribution is not the primary motivation for the dual-licensing. It's stronger protections to licensees and better interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work (as not all contributions qualify for copyright, due to not being a "creative work", e.g. a typo fix) and then add the following to your README:

## License

Licensed under either of

 * Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, if you have them, use the following boilerplate (based on that used in Rust):

// Copyright 2016 gfx Developers
//
// Licensed under the Apache License, Version 2.0, <LICENSE-APACHE or
// http://apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or
// http://opensource.org/licenses/MIT>, at your option. This file may not be
// copied, modified, or distributed except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable making an official recommendation either way, but the Apache license recommends it in their appendix on how to use the license.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these from the Rust repo for a plain-text version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT OR Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval by the necessary contributors and doing this changes, so feel free to leave the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your name. My scripts will pick this exact phrase up and check your checkbox, but I'll come through and manually review this issue later as well.

• [x] @kvark
• [x] @bjz
• [x] @cmr
• [x] @csherratt
• [x] @bvssvni
• [x] @sectopod
• [x] @homu
• [x] @Kimundi
• [x] @hannobraun
• [x] @fkaa
• [x] @lucidd
• [x] @serpis
• [x] @vickenty
• [x] @tomaka
• [ ] @mitchmindtree
• [x] @jeremija
• [x] @nicholasbishop
• [x] @mttr
• [x] @aepsil0n
• [x] @KokaKiwi
• [ ] @Potpourri
• [x] @photex
• [x] @red75prime
• [x] @Bastacyclop
• [x] @olsonjeffery
• [x] @mtsr
• [x] @MaikKlein
• [x] @thehydroimpulse
• [ ] @burtonageo
• [ ] @lynks--
• [x] @mike-marcacci
• [x] @stjahns
• [x] @amaranth
• [x] @petevine
• [x] @nulldatamap
• [x] @asheb
• [x] @andrew-d
• [x] @cybergeek94
• [ ] @axelmagn
• [x] @bfops
• [x] @toqueteos
• [x] @cl91
• [ ] @Chase-C
• [x] @munshkr
• [x] @fungos
• [x] @freebroccolo
• [ ] @escalant3
• [x] @dylanede
• [x] @farism
• [x] @flodiebold
• [x] @jahfer
• [x] @leonkunert
• [x] @mzmonsour
• [x] @ReadmeCritic
• [ ] @AnthIste
• [ ] @sbward
• [x] @alexcrichton
• [ ] @tomjakubowski
• [x] @yuriks
• [x] @gaudecker
• [x] @ahtn
• [x] @qres
• [x] @tioover

Fixes/Discussion: https://github.com/gfx-rs/wgpu/issues/450

PR checklist:

• [x] make succeeds (on *nix)
• [ ] make reftests succeeds
• [x] tested examples with the following backends:
  • GL ( excluding compute because it isn't supported )
• [x] rustfmt run on changed code

I noticed this issue about gfx_app has pretty much stopped, when I was just looking, and realized the exact same thing had been confusing me trying to learn gfx. In the thread, it was brought up maybe it was a good idea to move gfx_app to it's own module, to help users with learning the API (whom are reading the example code).

Since progress has slowed down in the PR for cargo workspaces I thought I would submit this as some progress. I thought it was good timing since the last commit to the gfx repository just accepted a pull-request doing a similar rename, it seems smart to do another rename pull-request like this (since others maintaining branches will already need to rebase). I could be wrong about this, but the alternative would for me to sit back and wait until another point in the future to do this.

I think renaming gfx_app to gfx_support, and more importantly moving the code out of gfx's root (and under examples/) will help users understand what is "gfx library code" vs "gfx support library code". The distinction is subtle but important, I believe. It certainty wasn't clear to me until quite a while of digging by myself.

I have a few things I'd like to discuss moving forward, this pull request certainly isn't ready as is.

1. I'd like to gather consensus that this is the right direction to move gfx. Are there any objections to the direction of this pull-request?
2. Is gfx_project a good name for the "root project"?
3. I'm not sure that duplicating the Cargo.toml file is the right way to express what I'm intending. Right now I'm duplicating the dependencies section in both Cargo.toml files. Apart from going through each dependency one-by-one, and seeing whether examples/ or gfx/ requires the dependency, is there a way to not duplicate the dependencies your aware of? Is duplicating them a problem?
4. In the other thread glium was brought up as an example, in glium's example code, the helper code lives in the examples/support/ directory, causing all examples to have to add explicitly mod support it. I tried emulating the same setup, but I wasn't able to get it to compile. I would need to spend more time comparing with the glium project to emulate that setup.
5. I need to try using the support code from another package, to make sure it's visible the way I think it should be. This is a TODO.

Anyways, I stole this list from the other thread. Here is what is working:

cargo build cargo run --example (they all seem to work)

What is not working:

cargo test -- this isn't working for me on master/, not completely sure abouit this one. cargo build --all (error: native frameworks are only available on macOS targets) cargo test --all (error: Could not compile core-foundation-sys)

Pretty tired now when writing this up, so posting this looking to get some direction/guidance to move forward with this change.

edit: Resolves:

• #1248
• #1424

Fixes #89, Fixes #849, Fixes #878, Fixes #882, Fixes #897, Fixes #902, Fixes #906

Breaking changes

• TriangleFan is removed
• R8_G8_B8 and R3_G3_B2 surface types are removed, and with them the old Srgb8 shortcut
• scaled channel formats (integers that are seen as floats) are removed
• explicit mipmap generation is removed. You can tell gfx to generate mipmaps on texture data initialization instead.
• Factory::update_*() methods are removed in favor of CommandBuffer-based updates and providing the initial data for resource creation, which now supports multiple slices and mips.
• device capabilities are reduced by cutting out GL-specific stuff.
• there is a new Bind flag set that you'll need to pass for some of the object construction methods
• Usage enum has undergone a rewrite
• there is a new ShaderSet type that may need for the PSO (or shader program) construction
• new structures for SRV/RTV/DSV creation: ResourceDesc, RenderDesc, and DepthStencilDesc
• CommandBuffer interface has minor changes in the scissor and indexed draw semantics, and a major change in the clearing semantics.
• SubmitInfo is gone. Encoder has a single flush method instead of as_buffer and reset.
• Phantom is renamed to Typed
• gfx_constant_struct requires the shader-visible names now, the same as gfx_vertex_struct
• shader version selection has been moved to gfx_app crate. Both core and render crates are now completely API-unaware.

Notable non-breaking changes

• there are new gfx_device_dx11 and gfx_window_dxgi crates. We also set up windows CI, which has GLFW stuff excluded.
• most, if not all, examples are rewritten to use the new gfx_app crate. It is now the only place that knows about all the windowing and API backends in this repository.
• Border mode for samplers
• new convenience type your_pso::Bundle and the constructor your_pso::bundle() are generated for you to contain the slice, PSO itself, and PSO run-time data objects.

Examples update

• most examples simply call launch_default, which selects the default backends for the current platform
• no longer using cast_slice - instead calling create_texture_const_u8
• passing in an array of input slices for texture creation - this saves "skybox" example half a page of code
• parameters are converted to be using the constant buffers for DX11 compatibility. Some are still being mirrored in globals to be compatible with GL2.
• shader versions for different models/backends are now properly specified and selected
• "Target0" name for the final PSO outputs at the moment. DX11 doesn't provide us the name, but it has the type to match on, and GL doesn't care. "Target0" is what we translate built-in DX11 semantic into.

Why DX11?

It's the most established API for high-performance games and graphics application to date. It has the best all-around driver support, variety of powerful tools, and is not cluttered by the legacy (looking at you, OpenGL).

Implementation details

The backend supports both native deferred contexts and emulated (in the same way we do with OpenGL). Once you obtained a device instance with gfx_window_dxgi::init, you can transform it into gfx_device_dx11::Deferred with a simple into() call. The application launcher uses native DX11 contexts by default.

Future work

• Integrate winit when it's ready (#907)
• Implement state caching for the DX11 command buffers

Requires https://github.com/gfx-rs/draw_state/pull/34 Fixes #815, fixes #842, fixes #823, fixes #761, ~~fixes #722~~, fixes #703, fixes #694, fixes #463 Closes #817, closes #640, closes #630, closes #575, closes #571, closes #322, closes #121 Touches #698, #331, #311, #284, #161

Breaking changes:

• Batch, Mesh, Stream concepts are gone, as well as the old shader parameters interface. PSO is the new paradigm, with it's own macro and interfaces.
• VAO, FBO, Surface, Plane, Output are gone, they are now hidden GL implementation details. Command enum and state caching have also been moved into GL backend.
• Texture semantic has changed - now it is just an allocation of some pixel data. For actual rendering, users are required to operate on the strongly-typed target/resource views. The new format specification supports textures, views, and vertex buffers in the uniform way.

See a better overview of the change in this comment. The best source of knowledge to this moment is the example code. We realize such this needs to be well documented and are working on it.

TODO (note: this is a vastly incomplete list of what's actually done):

• [x] PSO resource - low level
  • [x] resource
  • [x] binding
  • [x] creation
• [x] High level
  • [x] RenderTargetView and DepthStencilView
    • [x] low-level bindings
    • [x] raw creation
    • [x] typed creation
    • [x] hook up to PSO
  • [x] ShaderResourceView and UnorderedAccessView
    • [x] low-level bindings
    • [x] raw creation
    • [x] typed creation
    • [x] hook up to PSO
  • [x] move core into a separate lib (#703)
  • [x] remove the Copy constraint from the resources
  • [x] layout matching
    • [x] vertex attributes
    • [x] shader data
    • [x] pixel targets
  • [x] strongly-typed initialization
  • [x] hook to the Renderer for drawing
• [x] helper macros
  • [x] structure definition
  • [x] PSO
  • [x] PSO with static init
  • [x] texture format
  • [x] macros tests
• [x] Universal data format spec
  • [x] serialized form
  • [x] strongly-typed form
  • [x] replace tex::Format
  • [x] replace attrib::Format
• [x] GL backend
  • [x] rewrite init() function for windowing backends
  • [x] rewrite CommandBuffer implementation to do the heavy lifting
  • [ ] ~~support for structured buffers~~ (can be postponed)
  • [x] Glutin window
  • [x] GLFW window
• [x] Switch the examples to use PSO
  • [x] blend
  • [x] cube
  • [x] deferred
  • [x] flowmap
  • [x] instancing
  • [x] mipmap
  • [x] performance
  • [x] shadow
  • [x] terrain
  • [x] triangle
  • [x] ubo_tilemap
• [x] Clean up
  • [x] remove old Resources subtypes
  • [ ] ~~remove shader programs~~
  • [x] remove old meshes and attribute formats
  • [x] remove old shader parameters
  • [x] remove old texture format
  • [x] remove batches
  • [x] remove VAO and FBO
  • [x] remove Plane, Output, and Frame
• [x] Post-clean
  • [x] rename NewTexture to Texture
  • [x] remove primitive from mesh::Slice
• [x] Documentation
  • [x] typed PSO
  • [x] universal format

Or, basically, rewrite the whole damn thing ;)

I'm getting an error when running the following code:

extern crate piston_window;
use piston_window::*;
fn main() {
    let mut window: PistonWindow = PistonWindow::new(OpenGL::V2_1, 0,
    WindowSettings::new("Hello", (800,600))
      .opengl(OpenGL::V2_1)
      .exit_on_esc(true)
      .srgb(false)
      .build() // hack around default srgb(true) (builds GlutinWindow instead of PistonWindow)
      .unwrap());
    while let Some(e) = window.next() {
        window.draw_2d(&e, |_c, g| {
            clear([0.5, 1.0, 0.5, 1.0], g);
        });
    }
}

here is the stack backtrace:

`thread '<main>' panicked at 'Error after executing command BindProgram(0): InvalidOperation', /home/harrison/.multirust/toolchains/beta/cargo/registry/src/github.com-88ac128001ac3a9a/gfx_device_gl-0.10.0/src/lib.rs:283
stack backtrace:

   1:     0x562aec0d2c90 - std::sys::backtrace::tracing::imp::write::h25f26530b3b48a54
   2:     0x562aec0d57bb - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::hb497e646e4148afc
   3:     0x562aec0d5443 - std::panicking::default_hook::hd57825f8b5247927
   4:     0x562aec0cbf1f - std::sys_common::unwind::begin_unwind_inner::hf40013815c474ad4
   5:     0x562aec0ccbc8 - std::sys_common::unwind::begin_unwind_fmt::h42a3b0f6333a2a21
   6:     0x562aebf76c8f - gfx_device_gl::Device::check::h4290e3674196ac1e
                        at /home/harrison/Projects/rust/testing_piston/src/<std macros>:8
   7:     0x562aebf7e69d - gfx_device_gl::Device::process::ha9e4c244f4e4d126
                        at /home/harrison/.multirust/toolchains/beta/cargo/registry/src/github.com-88ac128001ac3a9a/gfx_device_gl-0.10.0/src/lib.rs:665
   8:     0x562aebf7a04e - gfx_device_gl::Device::reset_state::hd0590a45498c77d8
                        at /home/harrison/.multirust/toolchains/beta/cargo/registry/src/github.com-88ac128001ac3a9a/gfx_device_gl-0.10.0/src/lib.rs:378
   9:     0x562aebf88b02 - _<Device as gfx_core..Device>::submit::hd22aed74b4a07f91
                        at /home/harrison/.multirust/toolchains/beta/cargo/registry/src/github.com-88ac128001ac3a9a/gfx_device_gl-0.10.0/src/lib.rs:689
  10:     0x562aebef9db0 - _<gfx..encoder..Encoder<R, C>>::flush::hbf7cc6ecb9eefa5b
                        at /home/harrison/.multirust/toolchains/beta/cargo/registry/src/github.com-88ac128001ac3a9a/gfx-0.11.0/src/encoder.rs:85
  11:     0x562aebef2bff - _<piston_window..PistonWindow<W>>::draw_2d::hf03a024ce1bc4da9
                        at /home/harrison/.multirust/toolchains/beta/cargo/registry/src/github.com-88ac128001ac3a9a/piston_window-0.47.0/src/lib.rs:221
  12:     0x562aebebff80 - testing_piston::main::h55362581195f04b1
                        at /home/harrison/Projects/rust/testing_piston/src/main.rs:12
  13:     0x562aec0d5084 - std::sys_common::unwind::try::try_fn::hf5d123c03b60f222
  14:     0x562aec0d20fb - __rust_try
  15:     0x562aec0d4acb - std::rt::lang_start::hb87e98f24ba5d300
  16:     0x562aebefaab9 - main
  17:     0x7fe7c4171ec4 - __libc_start_main
  18:     0x562aebebfd18 - <unknown>
  19:                0x0 - <unknown>
error: Process didn't exit successfully: `/home/harrison/Projects/rust/testing_piston/target/debug/testing_piston` (exit code: 101)`

How do I go about fixing this? I was thinking maybe I'm missing a dependency or something, but I really have no idea!

$ cargo run --bin quad --features=metal

Produces a grey window and nothing else

Short info header:

• OS: OS X Sierra 10.12.6 (16G29)
• GPU: Intel Iris Graphics 6100 1536 MB

$git log commit 6c3c1d335778fba3333d395f486a8a032805cec6 Merge: f8b74e2 86c5d35 Author: bors[bot] <bors[bot]@users.noreply.github.com> Date: Wed Jan 9 17:45:47 2019 +0000

examples$ cargo run --bin quad --features=metal Finished dev [unoptimized + debuginfo] target(s) in 0.20s
Running /Users/andrewl/rust/gfx/target/debug/quad AdapterInfo { name: "Intel(R) Iris(TM) Graphics 6100", vendor: 0, device: 0, device_type: DiscreteGpu } Memory types: [MemoryType { properties: DEVICE_LOCAL, heap_index: 0 }, MemoryType { properties: COHERENT | CPU_VISIBLE, heap_index: 1 }, MemoryType { properties: DEVICE_LOCAL | CPU_VISIBLE, heap_index: 1 }, MemoryType { properties: DEVICE_LOCAL | CPU_VISIBLE | CPU_CACHED, heap_index: 1 }] formats: Some([Bgra8Unorm, Bgra8Srgb, Rgba16Float]) SwapchainConfig { present_mode: Fifo, composite_alpha: Inherit, format: Bgra8Srgb, extent: Extent2D { width: 1024, height: 768 }, image_count: 2, image_layers: 1, image_usage: COLOR_ATTACHMENT } SwapchainConfig { present_mode: Fifo, composite_alpha: Inherit, format: Bgra8Srgb, extent: Extent2D { width: 1024, height: 768 }, image_count: 2, image_layers: 1, image_usage: COLOR_ATTACHMENT } SwapchainConfig { present_mode: Fifo, composite_alpha: Inherit, format: Bgra8Srgb, extent: Extent2D { width: 1024, height: 768 }, image_count: 2, image_layers: 1, image_usage: COLOR_ATTACHMENT } SwapchainConfig { present_mode: Fifo, composite_alpha: Inherit, format: Bgra8Srgb, extent: Extent2D { width: 1024, height: 768 }, image_count: 2, image_layers: 1, image_usage: COLOR_ATTACHMENT } SwapchainConfig { present_mode: Fifo, composite_alpha: Inherit, format: Bgra8Srgb, extent: Extent2D { width: 1024, height: 768 }, image_count: 2, image_layers: 1, image_usage: COLOR_ATTACHMENT }

[lines keep repeating infinitely]

Fixes Dota2 after #2116 PR checklist:

• [ ] make succeeds (on *nix)
• [ ] make reftests succeeds
• [ ] tested examples with the following backends:
• [ ] rustfmt run on changed code

( Will, hopefully ) fix issue #3353

PR checklist:

• [ ] make succeeds (on *nix)
• [ ] make reftests succeeds
• [ ] tested examples with the following backends:

Because we follow Vulkan closely for the HAL API, we don't have many safety guarantees for most of the API usage. A few users have asked to have the explicit unsafe annotation to make it more obvious that no guarantees are provided here.

I'm trying to figure out if I'm supposed to use gfx_app::Application since that's what all the examples use, but don't see a way to take user input. Looking at the implementation it hard codes the keys it will accept. Is there a way to handle user input with this struct or is this boilerplate I'm supposed to copy and modify?

let mut harness = Harness::new();
main: loop {
    // quit when Esc is pressed.
    for event in window.poll_events() {
        match event {
            glutin::Event::KeyboardInput(_, _, Some(glutin::VirtualKeyCode::Escape)) |
            glutin::Event::Closed => break 'main,
            _ => {},
        }
    }
    // draw a frame
    app.render(&mut device);
    window.swap_buffers().unwrap();
    device.cleanup();
    harness.bump()
}