Setting gl_FragDepth in fragment shader causes Err in Factory::create_pipeline_simple

[norru]

I'll post more details in the days to come. For the time being, any suggestions welcome.

If the pixel shader contains a line like

 gl_FragDepth = 0.0; // or any other value

leads let pso = factory.create_pipeline_simple(VERTEX_SRC, FRAGMENT_SRC, shaded::new()).unwrap(); to this:

thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: DescriptorInit(PixelExport(255, None))', ../src/libcore/result.rs:746
stack backtrace:
   1:     0x558d2ca14460 - std::sys::backtrace::tracing::imp::write::h4c73fcd3363076f5
   2:     0x558d2ca1705b - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::h0422dbb3077e6747
   3:     0x558d2ca16ce3 - std::panicking::default_hook::haac48fa641db8fa2
   4:     0x558d2ca0d5bf - std::sys_common::unwind::begin_unwind_inner::h39d40f52add53ef7
   5:     0x558d2ca0e268 - std::sys_common::unwind::begin_unwind_fmt::h64c0ff793199cc1b
   6:     0x558d2ca13941 - rust_begin_unwind
   7:     0x558d2ca4cf8f - core::panicking::panic_fmt::h73bf9d7e8e891a73
   8:     0x558d2c83f0d8 - core::result::unwrap_failed::h76c5eb24dc69b566
                        at ../src/libcore/macros.rs:29
   9:     0x558d2c83ee59 - _<std..result..Result<T, E>>::unwrap::hdd8f20652a43eb00
                        at ../src/libcore/result.rs:687
  10:     0x558d2c83d0bd - _<render..DrawShaded<R>>::new::h162d384cb319a439
                        at src/render.rs:225
  11:     0x558d2c832ca9 - rust_evaluation::main::h11b730a907f7f040
                        at src/main.rs:327
  12:     0x558d2ca16924 - std::sys_common::unwind::try::try_fn::h09ba69fd13531e58
  13:     0x558d2ca138cb - __rust_try
  14:     0x558d2ca1636b - std::rt::lang_start::h5b0863080165c75e
  15:     0x558d2c86c0e9 - main
  16:     0x7f3a29e0b82f - __libc_start_main
  17:     0x558d2c82d6b8 - _start
  18:                0x0 - <unknown>

where

    pipeline shaded {
        vbuf: gfx::VertexBuffer<VertexPosNormal> = (),
        camera_args: gfx::ConstantBuffer<CameraArgs> = "cb_CameraArgs",
        model_args: gfx::ConstantBuffer<ModelArgs> = "cb_ModelArgs",
        fragment_args: gfx::ConstantBuffer<FragmentArgs> = "cb_FragmentArgs",
        lights: gfx::ConstantBuffer<PointLight> = "u_Lights",
        out_ka: gfx::RenderTarget<gfx::format::Rgba8> = "o_Color",
        out_depth: gfx::DepthTarget<gfx::format::DepthStencil> = gfx::preset::depth::LESS_EQUAL_WRITE,
    }

[kvark]

Thanks for the report! We'll fix it ASAP. It's just a check missing from #980 , it seems.

[kvark]

In the meantime, may I wonder why you want to set the depth manually?

[norru]

Experimenting with impostors. I'm basically drawing balls using quads.

On 1 June 2016 at 13:49, Dzmitry Malyshau notifications@github.com wrote:

In the meantime, may I wonder why you want to set the depth manually?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#984 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AA2Ry8XZWS4JexQSphmiZVfF7zc4S1d5ks5qHX-9gaJpZM4IrEix
.

Cheers,
Nico

[kvark]

Ok, cool. I just want to make sure you realize the performance implications of writing to the depth from the shader.

[norru]

Yup, I'm nowhere near the optimization stage - just prototyping at the
moment. I expect it to have quite a hit but not worried for now. It might turn out that drawing balls as balls is faster after all.

On 1 June 2016 at 14:27, Dzmitry Malyshau notifications@github.com wrote:

Ok, cool. I just want to make sure you realize the performance
implications of writing to the depth from the shader.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#984 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AA2Ry5SB0JmHTjaSNCBKmSE7vB0xLMw0ks5qHYi_gaJpZM4IrEix
.

Cheers,
Nico

[norru]

Ace, thanks!

Is there an ETA on when this fix will be released on crates.io?

[kvark]

I suppose we could slightly bend the semver rules here. The gfx_core crate definitely needs a minor version bump, but the graphics backends can just go with a patch version increased.

On Jun 4, 2016, at 9:42, Nico Orrù notifications@github.com wrote:

Ace, thanks!

Is there an ETA on when this fix will be released on crates.io?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[norru]

No rush, I'll grab it when it's ready!

[kvark]

@norru Would you mind using cargo override for now? It should work seamlessly until you publish your crate. It's not clear how to properly upload this change on crates.io (yet).

[norru]

It's not urgent but I can give it a shot :)

On 5 June 2016 at 01:27, Dzmitry Malyshau notifications@github.com wrote:

@norru https://github.com/norru Would you mind using cargo override
http://doc.crates.io/specifying-dependencies.html#overriding-dependencies
for now? It should work seamlessly until you publish your crate. It's not
clear how to properly upload this change on crates.io (yet).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#984 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AA2Ry4ZuZaH1dQaHdnpDJ0qFPJ-BakwUks5qIhfWgaJpZM4IrEix
.

Cheers,
Nico