AmberScript updates to buffers #66

dj2 · 2018-11-19T18:36:39Z

No description provided.

docs/amber_script.md

dj2 · 2018-11-19T18:37:55Z

docs/amber_script.md

  ENTRY_POINT kFragmentShader red
 END  # pipeline

 PIPELINE graphics kGreenPipeline
  ATTACH kVertexShader
  ATTACH kFragmentShader

-  FRAMEBUFFER kFrameBuffer
+  FRAMEBUFFER 256 256


How do we encode the case where we want the framebuffer from the two pipelines to be the same, or to be different? My previous assumption was they'd have unique framebuffers, except in cases like this were I was passing the same FRAMEBUFFER into both of them.

Example:

BIND myim AS fb DESCRIPTOR_SET 1 BINDING 0

Then the underlying resource (myim) is a declared buffer (image) that already exists. And you can act on it twice, and it's orthogonal.

dj2 · 2018-11-19T18:39:31Z

docs/amber_script.md

@@ -405,6 +403,6 @@ CLEAR_COLOR kGraphicsPipeline 255 0 0 255
 CLEAR kGraphicsPipeline

 RUN kGraphicsPipeline \
-  DRAW_ARRAY kIndices IN kBuffer AS triangle_list \
+  DRAW_ARRAY kIndices IN kData AS triangle_list \


Currently RUN is where we use vertex and indices buffers, do they need to be attached into a PIPELINE with the VERTEX_BUFFER and INDEX_BUFFER calls we mentioned, or is just referencing them here enough?

If they're attached into a PIPELINE, does that mean that RUN pipeline DRAW_ARRAY will just use them implicitly? So this would just be:

RUN kGraphicsPipeline DRAW_ARRAY AS triangle_list START_IDX 0 COUNT 24

In Vulkan both index buffer and vertex buffers are bound in the command buffer before doing the draw call. So it's ok to do it implicitly here. The backend will translate this RUN call into the right bind-index-buffer and bind-vertex-buffer commands.

I believe the vertex and index buffer bindings are totally different numbering spaces than descriptor set/binding pairs. Beware.(?!)

docs/amber_script.md

dneto0 · 2018-11-19T20:02:27Z

docs/amber_script.md

  ENTRY_POINT kFragmentShader red
 END  # pipeline

 PIPELINE graphics kGreenPipeline
  ATTACH kVertexShader
  ATTACH kFragmentShader

-  FRAMEBUFFER kFrameBuffer
+  FRAMEBUFFER 256 256


Example:

BIND myim AS fb DESCRIPTOR_SET 1 BINDING 0

Then the underlying resource (myim) is a declared buffer (image) that already exists. And you can act on it twice, and it's orthogonal.

dneto0 · 2018-11-19T20:19:31Z

docs/amber_script.md

@@ -405,6 +403,6 @@ CLEAR_COLOR kGraphicsPipeline 255 0 0 255
 CLEAR kGraphicsPipeline

 RUN kGraphicsPipeline \
-  DRAW_ARRAY kIndices IN kBuffer AS triangle_list \
+  DRAW_ARRAY kIndices IN kData AS triangle_list \


In Vulkan both index buffer and vertex buffers are bound in the command buffer before doing the draw call. So it's ok to do it implicitly here. The backend will translate this RUN call into the right bind-index-buffer and bind-vertex-buffer commands.

I believe the vertex and index buffer bindings are totally different numbering spaces than descriptor set/binding pairs. Beware.(?!)

dj2 · 2018-11-19T21:14:02Z

PTAL.

I decided to run with VERTEX_DATA and INDEX_DATA to see what it looked it, and seems to make the DRAW_ARRAY call nicer. This then does raise the question, can you attach multiple vertex data buffers to a pipeline? If you want to have multiple data types in there you'd need to, or we need struct support for the data types.

Changed up the FRAMEBUFFER settings a bit to match what was discussed.

dneto0 · 2018-11-20T04:30:29Z

docs/amber_script.md

+  BIND BUFFER <buffer_name> AS <buffer_type> DESCRIPTOR_SET <id> \
+       BINDING <id> IDX <val>
+
+  BIND SAMPLER <sampler_name>


Samplers are also bound to descriptor set and binding.

dneto0 · 2018-11-20T04:41:28Z

docs/amber_script.md

 ### Run a pipeline.

+When running a `DRAW_ARRAY` command you must attach the vertex data and index
+data to the `PIPELINE` with the `VERTEX_DATA` and `INDEX_DATA` commands.


The index buffer is only needed if doing an indexed draw. (It's if and only if.)

I'd write it like this:

When running a DRAW_ARRAY command, you must attache the vertex data to the PIPELINE with the VERTEX_DATA command.
To run an indexed draw, attach the index data to the PIPELINE with an INDEX_DATA command.

Done. Also updated DRAW_ARRAY to provide a DRAW_ARRAY INDEXED option.

docs/amber_script.md

dneto0 · 2018-11-20T05:01:18Z

docs/amber_script.md

@@ -319,15 +338,15 @@ PIPELINE graphics kRedPipeline

  ATTACH kFragmentShader

-  FRAMEBUFFER kFrameBuffer
+  FRAMEBUFFER kFramebuffer 256 256


Need DIMS keyword

docs/amber_script.md

dneto0 · 2018-11-20T05:19:26Z

docs/amber_script.md

+  VERTEX_DATA kData
+  INDEX_DATA kIndices
+END  # pipeline
+
 CLEAR_COLOR kGraphicsPipeline 255 0 0 255


Now that FRAMEBUFFER is not declared in a pipeline, the CLEAR and CLEAR_COLOR have to name an buffer rather than a pipeline, I think.

Well, you're still clearing the drawing buffer for the pipeline aren't you as opposed to some other buffer?

Let's resolve Framebuffer semantics in a future CL.

docs/amber_script.md

dneto0 · 2018-11-20T20:45:52Z

docs/amber_script.md

+  VERTEX_DATA kData
+  INDEX_DATA kIndices
+END  # pipeline
+
 CLEAR_COLOR kGraphicsPipeline 255 0 0 255


Let's resolve Framebuffer semantics in a future CL.

AmberScript updates to buffers

1269540

dj2 added the documentation Issues with documentation label Nov 19, 2018

dj2 added this to the AmberScript Parsing milestone Nov 19, 2018

dj2 self-assigned this Nov 19, 2018

dj2 added this to In progress in General via automation Nov 19, 2018

dj2 requested review from jaebaek and dneto0 November 19, 2018 18:36

dj2 commented Nov 19, 2018

View reviewed changes

dneto0 reviewed Nov 19, 2018

View reviewed changes

Refine

756ef01

dneto0 reviewed Nov 20, 2018

View reviewed changes

dj2 added 2 commits November 20, 2018 10:59

Merge branch 'master' into buffer_updates

804cceb

Updates

bf9cde2

dneto0 approved these changes Nov 20, 2018

View reviewed changes

dneto0 merged commit 3d0472b into google:master Nov 20, 2018

General automation moved this from In progress to Done Nov 20, 2018

dj2 mentioned this pull request Nov 21, 2018

Redefined buffer types #48

Closed

dj2 deleted the buffer_updates branch December 5, 2018 04:09

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

AmberScript updates to buffers #66

AmberScript updates to buffers #66

dj2 commented Nov 19, 2018

dj2 Nov 19, 2018

dneto0 Nov 19, 2018

dj2 Nov 19, 2018

dj2 Nov 19, 2018

dneto0 Nov 19, 2018

dneto0 Nov 19, 2018

dneto0 Nov 19, 2018

dj2 commented Nov 19, 2018

dneto0 Nov 20, 2018

dj2 Nov 20, 2018

dneto0 Nov 20, 2018

dj2 Nov 20, 2018

dneto0 Nov 20, 2018

dj2 Nov 20, 2018

dneto0 Nov 20, 2018

dj2 Nov 20, 2018

dneto0 Nov 20, 2018

dneto0 Nov 20, 2018

AmberScript updates to buffers #66

AmberScript updates to buffers #66

Conversation

dj2 commented Nov 19, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dj2 commented Nov 19, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment