Re: Roadmap wiki

Corentin,

> I think we all agree on this one, but it is hard to explain: the pipeline
state will contain aspects that 1) are required at pipeline compilation in
some APIs 2) is supported in all APIs.

Yes, that sounds better.

> I don't think the "3-layered" hierarchy mentioned the heap / pool / set
of #19 <https://github.com/gpuweb/gpuweb/issues/19> but a description of
the Vulkan binding model.

I'm not referring to the heap/pool/set of #19, I'm talking about Vulkan
model. Since Google doesn't want to expose the descriptor pools, you have a
2-layer hierarchy.

> We have found that you can avoid the offset alignment requirement by
splitting copies, so I suggest we don't expose it. Agreed with the
row-pitch alignment and fixing it to 256: the Vulkan DB
<http://vulkan.gpuinfo.org/listreports.php?limit=optimalBufferCopyRowPitchAlignment>
shows it is at most 128.

Can you remind me about the splitting details? I don't think that removing
the offset alignment restriction will do much good, even if you have a
workaround for D3D12, given that we'd still like to hit the "optimal"
driver path on Vulkan, which involves following the optimal offset
alignment (which is also 1/64/128 typically).

> I don't think this is resolved: in #22
<https://github.com/gpuweb/gpuweb/issues/22> I explain how integer fences
can be emulated efficiently on all APIs, and I feel they would be more
useful to developers.

I don't feel easy about this workaround. IIRC, we decided to reach out to
ISVs polling if their actual usage fits D3D12 better.

> how about we keep the roadmap at a fairly high-level and start writing
documents about different aspects of the API in gpuweb/gpuweb so we can use
pull requests and comment things on the PR directly?

That sounds good. I suppose we can figure out the exact form of this once
we start filling out the details.

Regards,
Dzmitry

On Fri, Aug 11, 2017 at 6:16 PM, Corentin Wallez <cwallez@google.com> wrote:

> On Thu, Aug 10, 2017 at 11:47 AM, Dzmitry Malyshau <dmalyshau@mozilla.com>
> wrote:
>
>> Hello GPUWeb,
>>
>> I'd like to discuss the first draft of the Roadmap document:
>> https://github.com/gpuweb/gpuweb/wiki/Roadmap
>>
>> First of all, big thanks to Myles for starting the effort!!!
>>
>> +1 this helps framing the work a lot!
>
>
>> Several consensus items raised at least one of my eyebrows:
>>
>> > Consensus: MVP will only allow one instance of a queue object
>> > Consensus: Consecutive render passes don’t inherit state
>> > Consensus: In general, include the union of all 3 platform API’s
>> pipeline state
>>
> I think we all agree on this one, but it is hard to explain: the pipeline
> state will contain aspects that 1) are required at pipeline compilation in
> some APIs 2) is supported in all APIs.
>
>
>> > Consensus: Renderpass information is not included (Vulkan backends will
>> create dummy renderpasses)
>>
>
>>
> And this one can raise a Google's eyebrow, given that they proposed to
>> hide the concept of descriptor pools/maps:
>> > Consensus: Generally, use Vulkan’s binding model: A 3-layered
>> hierarchy: Descriptors, a set of descriptors, and a (single) collection of
>> sets.
>>
>> I don't think the "3-layered" hierarchy mentioned the heap / pool / set
> of #19 <https://github.com/gpuweb/gpuweb/issues/19> but a description of
> the Vulkan binding model.
>
>
>> Not necessarily saying these are incorrect (I might have just missed the
>> consensus), but it would be great to link to a particular spot in the notes
>> where the points are agreed upon.
>>
>> Clarifications I think we can add safely:
>>
>> > Open Question: D3D has to keep samplers separately from all other
>> resources
>>
>> Another open question: D3D allows only one of each descriptor heap type
>> to be bound at any particular point in the command list.
>>
>> > Open Question: Aligned to what?
>>
>> I think we have an answer.
>> For buffer copy operations, buffer offsets need to be aligned to 512
>> bytes in D3D12 and to the optimal alignment (as specified by the device
>> capabilities) in Vulkan. Buffer row pitches should be correspondingly
>> aligned to 256 bytes in D3D12 and the optimal pitch alignment in Vulkan.
>> Also see https://github.com/gpuweb/gpuweb/issues/28
>>
>> We have found that you can avoid the offset alignment requirement by
> splitting copies, so I suggest we don't expose it. Agreed with the
> row-pitch alignment and fixing it to 256: the Vulkan DB
> <http://vulkan.gpuinfo.org/listreports.php?limit=optimalBufferCopyRowPitchAlignment>
> shows it is at most 128.
>
>
>> Regards,
>> Dzmitry
>>
>
> > Consensus: Fences will have 1 bit of information in them
>
> I don't think this is resolved: in #22
> <https://github.com/gpuweb/gpuweb/issues/22> I explain how integer fences
> can be emulated efficiently on all APIs, and I feel they would be more
> useful to developers.
>
> With respect to process, how about we keep the roadmap at a fairly
> high-level and start writing documents about different aspects of the API
> in gpuweb/gpuweb so we can use pull requests and comment things on the PR
> directly? There are several subjects that could already start to get a bit
> more detailed, like pipeline state and command buffer. The documents would
> contain pseudo-code and explanation of how the concept maps to the
> different underlying APIs.
>
> Cheers,
>
> Corentin
>