Improve error handling for gfxCreateGraphicsPipelines

[zeux]

We are getting VK_ERROR_INCOMPATIBLE_DRIVER when calling CreateGraphicsPipelines for any pipelines in our application; looks like it's coming from here:

portability/libportability-gfx/src/impls.rs

Lines 2103 to 2107 in 7650048

	if pipelines.iter().any(|p| p.is_err()) {
	for op in out_pipelines {
	*op = Handle::null();
	}
	VkResult::VK_ERROR_INCOMPATIBLE_DRIVER

There's no error logs so I'm not sure what the problem is. Would it be possible to communicate the reason for the error via a TTY or something along these lines? These are most likely bugs in portability/gfx/etc. but it's unclear why they happen.

[kvark]

The backend often spews out errors/warning and other messages via rust standard logging mechanisms. They are hooked up to the console output in our debug builds and can be enabled when running with RUST_LOG=gfx_backend_metal=debug. This includes SPIRV-Cross produced shader code/errors.

But in this case, we first need to make sure the errors returned by the backend are not ignored. So minor changes to the portability lib are needed.

[zeux]

I'll check RUST_LOG output tomorrow, thanks. It would be great to mention this in the error message, similarly to how panic says that you can enable backtraces to see more output.

[zeux]

Ok - RUST_LOG didn't work in release builds but it did work in the debug build:

ERROR 2018-08-15T21:03:22Z: gfx_backend_metal::device: PSO creation failed: Vertex attribute TEXCOORD0(4) is missing from the vertex descriptor
1534367001.83030,a824380,6 VULKAN ERROR: vkCreateGraphicsPipelines(device, cache, 1, &createInfo, nullptr, &result) returned -9
1534367001.83034,a824380,6 ERROR: Pipeline state object creation failed with code -9
1534367001.83035,a824380,6 Program: SkyVS,SkyFS,

[zeux]

Ok - I see - this is a bug in gfx (filed here gfx-rs/gfx#2324):

https://github.com/gfx-rs/gfx/blob/a571ae5a15b2fd7bdd457c9d2d6189167ccfbf54/src/backend/metal/src/device.rs#L1011-L1014

This code doesn't handle location in attribute descriptors properly, instead assuming that all attributes have linear locations 0-count-1.

[zeux]

Closing this since the issue is stale and probably doesn't need addressing anymore.