Devices discussion

[joeblew99]

Is this ready for testing on android and ios.

Is the roadmap plan to support webgl via emscripten ?

[joeblew99]

Btw. The architecture being designed to support vulcan / spir is very smart move I think. I am already playing around with this and can help on this aspect.

[kvark]

Emscripten kinda works with some hacks. @AerialX got hematite running on it. See #641 for missing features and hacks.

Android/iOS are really in the same boat, since it's also GL ES 2.0. They are not quite ready for testing, but you can get around to run stuff, maybe even submit some PRs back ;)

[kvark]

@joeblew99 You are playing around Vulkan? How did you get the specs? We'd appreciate any help on this front.

[joeblew99]

I work with people at arm doing testing sometimes. I sometimes get invited to dogfood early drivers on mobile.

[joeblew99]

Its an informal thing. I get the impression they and silicon manufacturers are very keen to get it moving

[kvark]

There is a thousand things yet to do in gfx land, but getting more devices (which should really be named backends, btw) is our strategic goal. I believe D3D bindings are mature enough to experiment with gfx_device_d3d, and we are ready to start playing with Vulkan when it's out. If you can start any kind of work, I just created https://github.com/gfx-rs/gfx_device_vulkan for you.

[joeblew99]

Definitely will help if I can. This project is really great. But the drivers I get are open very very raw still so allot of false positives. I am hoping I get more drops and that their drivers get more substatial. I was mostly testing things on android btw

[kvark]

@joeblew99 sounds great! If you are serious about that, I can just add you to the members so that you can work on gfx_device_vulkan directly without stalls or interruptions. We'll keep on eye on the code anyway, of course ;)

[joeblew99]

On windows Microsoft have not dropped D3D ? I read that they might be dropping D3D and going opengl.

On browsers your going via emscripten of generating webgl calls as js internally. This is what the golang developers are doing - generating directly.

[joeblew99]

I am very serious about vulcan. It is really the way it should be done.

[kvark]

Microsoft is by far not abandoning D3D. They are pushing DX12 left and right, and it's a big improvement! Even though, still unportable.

You've been invited to the group. Good luck!

[fkaa]

Been reading through Apple's Metal API recently and thought I might write down my understanding of how they've designed it and how gfx can adapt. As far as I know Metal is pretty similar to Mantle, which in turn is similar to Vulkan, so this should be pretty relevant, despite being designed for the PowerVR GPUs.

Textures

In Metal, mutability is sparse. Textures (MTLTexture) are immutable in the sense that you can change its data (TexSubImage), but not its descriptor (width, height, format etc.). This feature exists in OpenGL via TexStorage.

Resources

All resources are created with an accompanying type descriptor (MTLTextureDescriptor for MTLTexture). The same exists in gfx with its TextureInfo, but from my limited knowledge of gfx, this pattern is much more prevalent in Metal (there's MTLRenderPipelineColorAttachmentDescriptor for creating color attachments!)

Device

There is a notion of a Device in Metal (MTLDevice), but it seems to also serve as a factory for creating all the resources and can be used to check for features. From the documentation:

The MTLDevice protocol defines the interface to a single graphics processor (GPU). [...]

Most objects in Metal that perform graphics rendering and computational work are associated directly with a specific device. For example, texture objects are created by a device object and can be used only with that device. Most methods on a MTLDevice object create non-transient objects, including command queues, resources (such as buffers and textures), and pipeline states. [...]

Shaders

Shaders in Metal seems very streamlined. MTLLibrary is the Metal equivalence of a compiled shader program. Individual MTLFunction can then be queried from the program and passed as arguments to other Metal API functions (see the part about compute encoders below).

Command Buffers

Pushing commands to the GPU is done by creating a command queue (MTLCommandQueue). The queues can in turn create command buffers (MTLCommandBuffer) which encode commands into the buffer. Finally the buffers are committed to the queue to perform the encoded commands.

Command buffers is where all the magic happens. They can create different types of encoders which correspond to different parts of the pipeline. Only a single encoder can be active for a command buffer. You can also encode several commands from different encoders in a single command buffer. To execute all the commands the buffer is commited to the queue.

• MTLRenderCommandEncoder is the most common encoder which is used for "normal" rendering. It can hold a MTLRenderPipelineState object which describes the render pass (color attachments, shader program, multisampling etc.)
• MTLComputeCommandEncoder handles interfacing with compute programs and specifies in/out data in the program. It It also holds a MTLComputePipelineState which describes what MTLFunction to run and what arguments to pass.
• MTLBlitCommandEncoder takes care of resource-copying commands (Buffer <-> Buffer, Buffer -> Texture, Texture <-> Texture etc.)
• MTLParallelRenderCommandEncoder is similar to MTLRenderCommandEncoder but has the added benefit that it can be encoded from multiple threads simultaneously. Individual MTLRenderCommandEncoder are created from the parallel encoder. These objects encode to the same commandbuffer as the parallel encoder. Synchronization is entirely up to the user and all render commands are executed in the order that the individual MTLRenderCommandEncoder were created in.

The documentation says the following on multithreading:

In a multithreaded app, break your overall task into subtasks that can be encoded separately. Create a command buffer for each chunk of work, then call the enqueue method on these command buffer objects to establish the order of execution. Fill each buffer object (using multiple threads) and commit them. The command queue automatically schedules and executes these command buffers as they become available.

Quite a long comment but I hope it was somewhat insightful. If anyone actually knows Metal, please point out anything that's incorrect!

[kvark]

@fkaa thanks fa ton for writing this up!

Textures - we have the same policy. Buffers and Textures in gfx-rs are immutable when it comes to the descriptors, so no changes are needed.

Color attachment descriptors - not sure how it's going to map just yet. Sounds like it's the same concept as the texture views in GL/D3D, which we need to provide (TODO!).

Device - seems to be what our Factory is. Not a big deal, outside of the terms confusion.

Shaders - the MTLFunction is related to compute queues, as you said, and we don't have computing just yet (another TODO!)

*Command Buffers - MTLRenderCommandEncoder is what our Renderer is, and MTLCommandQueue is our Device. Looks very compatible with us so far, but we'll need a compute queue eventually, followed by the blit/copy queue at some point.

[kvark]

Reading up more on Metal makes me think it's a better candidate for us to match. If we go lower, we wouldn't be able to emulate Metal then. Also, it's interface is much simpler, while still providing as much power as Mantle and co.

[emberian]

@kvark Agree, now that Metal is announced for OS X I think it makes a lot of sense to target it as an "advanced" API on all Mac platforms.

[kvark]

Closing as outdated. We got ES2 and Metal, in a way now. Our API most closely resembles DX12.