I know that there are minimum uniform buffer and shader storage minimum alignments, but I was wondering if there were minimum alignment for vertices(anything that is read from the input assembler) and indices. Also do the staging buffers need to have an alignment for indices and vertices? How about the copy operations from staging buffer to a device-local buffer and vice versa?
vkCmdBindIndexBuffer's documentation states that offset "must be a multiple of the type indicated by indexType".
The vertex buffer binding functions have similar alignment requirements based on the formats used for them, but they are specified in a more unusual way (and not in the documentation for the function).
There is a section in the specification on how the address for a specific attribute is computed. The wording here puts for a set of de-facto requirements on the pOffsets parameter to vkCmdBindVertexBuffers and similar functions.
The rules boil down to this: you have to specify offsets (and other fields) such that the eventual address computed for each attribute is not misaligned, relative to the format for that attribute. Packed formats have to be multiples of their pack size, while non-packed formats have to be multiples of their component sizes. So while VK_FORMAT_A8B8G8R8_UNORM_PACK32 must be aligned to 4 bytes, VK_FORMAT_R8G8B8A8_UNORM can handle byte-alignment.
Though personally, I wouldn't test the latter.
Related
It is explained on https://www.r-spatial.org/r/2017/06/22/spatial-index.html that "The R tree is constructed on the first argument (x), and used to match all geometries on the second argument (y) of binary functions". However, it is finally not explained what are the criteria that could guide the user in the choice of the sf object to put in the first argument. Are there some rules of thumb for this choice?
Generally, with creating spatial indexes you want to start with a larger envelopes that decompose to smaller envelopes. So, if you are extending from that then starting with a geometry with a larger extent then building smaller envelopes from that would match the general schema of how these selections are optimized.
Structs may only contain scalars or other structs. But as I konw , only offset is writed to buffer when writing vector/table/string field into table data (the data of vector/table/string is wirited before table data). So struct contains vector/table/string field still can has fix size. Why flatbuffer do the limit that struct can only contain scalars or other structs?
The idea behind a struct is that it is a self-contained piece of memory that always has the same layout and size and as such can easily be copied around by itself, especially in languages that support such types natively, like C/C++/Rust etc.
If it could contain strings, then it would be at least two pieces of memory, whose distance and size would be variable, and thus not efficient to copy and easy to manage. We have table for such cases.
If you must have a vector or string inside a struct, some languages already support an "array" type, which is of fixed length. You could put that, plus a length field in a struct to emulate vectors and strings, of course with the downside that the space allocated for them is always the same.
I have a uniform buffer which should be updated every frame. In order to avoid big stalls I want to create 3 buffers (by the number of my frame buffers) which should be interleaved every frame (0-1-2-0-1-2-...). But I can't understand how to create descriptors and bind them. This is how I'm doing it now:
I created a VkDescriptorSetLayout where I specified that I want to use a uniform buffer at binding position 0 in some shader stage.
I created a VkDescriptorPool with a size for 3 descriptors for uniform buffers.
Next I need to allocate descriptor sets but how many descriptor sets do I need here? I have only one VkDescriptorSetLayout and I'm expecting to get one VkDescriptorSet.
Next I need to update created descriptor sets. Since I have only one binding (0) in my shader I can use only one one buffer in VkDescriptorBufferInfo which will be passed to VkWriteDescriptorSet which will be passed to vkUpdateDescriptorSets. But what about other two buffers? Where to specify them?
When I need to record a command I need to bind my descriptor set. But till now I have a descriptor set which is updated only for one buffer. What about the others?
Do I need to create 3 VkDescriptorSetLayout - one for every frame? Next do I need to allocate and update corresponding descriptor set with a corresponding buffer? And after this do I need to create 3 different command buffers where I should specify corresponding descriptor set.
It seems it's a lot of work - the data is almost the same - all bindings, states stays the same, only the buffer changes.
All it sounds very confusing so please don't hesitate to clarify.
Descriptor Set Layouts defines the contents of a descriptor set - what types of resources (descriptors) given set contains. When You need several descriptor sets with a single uniform buffer, You can create all of these descriptor sets using the same layout (layout is only a description, a specification). This way You just tell the driver: "Hey, driver! Give me 3 descriptor sets. But all of them should be exactly the same".
But because they are created from the same layout it doesn't mean they must contain the same resource handles. All them (in Your case) must contain a uniform buffer. But what resource will be used for this uniform buffer depends on You. So each descriptor set can be updated with separate buffer.
Now when You want to use 3 buffers one after another in three consecutive frames, You can do it in several different ways:
You can have a single descriptor set. Then in every frame, before You start preparing command buffers, You update the descriptor set with the next buffer. But when You update a descriptor set, it cannot be used by any submitted (and not yet finished) command buffers. So this would require additional synchronization and wouldn't be that much different than using a single buffer. This way You also cannot "pre-record" command buffers.
You can have a single descriptor set. To change its contents (use a different buffer in it) You can update it through functions added in the VK_KHR_descriptor_update_template extension. It allows descriptor updates to be recorded in command buffers so synchronization should be a bit easier. It should allow You to pre-record command buffers. But it needs an extension to be supported so it's not an option on platforms that do not support it.
Method You probably thought of - You can have 3 separate descriptor sets. All of them allocated using the same layout with a uniform buffer. Then You update each descriptor set with a different buffer (You can use 1st buffer with 1st descriptor set, 2nd buffer with 2nd descriptor set and 3rd buffer with 3rd descriptor set). Now during recording a command buffer, when You want to use a first buffer then You just bind the first descriptor set. In the next frame, You just bind a second descriptor set and so on.
The method 3 is probably the easiest to implement as it requires no synchronization for descriptors (only per frame-level synchronization is required if You have such). It also allows You to pre-record command buffers and it doesn't require any additional extensions to be enabled. But as You noted, it requires more resources to be created and managed.
Don't forget that You need to create a descriptor pool that is big enough to contain 3 uniform buffers but at the same You must also specify that You want to allocate 3 descriptor sets from it (one uniform buffer per descriptor set).
You can read more about descriptor sets in Intel's API without Secrets: Introduction to Vulkan - Part 6 tutorial.
As for Your questions:
Do I need to create 3 VkDescriptorSetLayout - one for every frame?
No - a single layout is enough (as soon as all descriptor sets contain the same types of resources in the same bindings.
Next do I need to allocate and update corresponding descriptor set
with a corresponding buffer?
As per option 3 - yes.
And after this do I need to create 3 different command buffers where I
should specify corresponding descriptor set.
It depends whether You re-record command buffers every frame or if You pre-record them up front. Usually command buffers are re-recorded each frame. But as having a single command buffer requires waiting until its submission is finished, You probably may need a set(s) of command buffers for each frame, that correspond to Your framebuffer images (and descriptor sets). So in frame 0 You use command buffer #0 (or multiple command buffers reserved for frame 0). In frame 1 You use command buffer #1 etc.
Now You can record a command buffer for a given frame and during recording You provide a descriptor set that is associated with a given frame.
I'm starting to study the FITS format and I'm in the proccess of reading the Definition of FITS document.
I know that a FITS file can have one or more HDUs, the primary being the first one and the extensions being the following ones (if there is more than one HDU), I also know that for the extensions there is a mandatory keyword in the header (XTENSION) that let us know if the Data Unit is an Image, Binary Table or ASCII Table, but how can I know what is the Data Type (Image, Binary Table or ASCII Table) of the first HDU?
I don't understand why XTENSION isn't a mandatory keyword in the primary header.
The "type" of the PRIMARY HDU is essentially IMAGE in most cases. From v3.0 of the standard:
3.3.2. Primary data array
The primary data array, if present, shall consist of a single data
array with from 1 to 999 dimensions (as specified by the NAXIS
keyword defined in Sect. 4.4.1). The random groups convention
in the primary data array is a more complicated structure and
is discussed separately in Sect. 6. The entire array of data values
are represented by a continuous stream of bits starting with
the first bit of the first data block. Each data value shall consist
of a fixed number of bits that is determined by the value of
the BITPIX keyword (Sect. 4.4.1). Arrays of more than one dimension
shall consist of a sequence such that the index along
axis 1 varies most rapidly, that along axis 2 next most rapidly,
and those along subsequent axes progressively less rapidly, with that along axis m, where m is the value of NAXIS, varying least
rapidly. There is no space or any other special character between
the last value on a row or plane and the first value on the next
row or plane of a multi-dimensional array. Except for the location
of the first element, the array structure is independent of the
FITS block structure. This storage order is shown schematically
in Fig. 1 and is the same order as in multi-dimensional arrays in
the Fortran programming language (ISO 2004). The index count
along each axis shall begin with 1 and increment by 1 up to the
value of the NAXISn keyword (Sect. 4.4.1).
If the data array does not fill the final data block, the remainder
of the data block shall be filled by setting all bits to zero.
The individual data values shall be stored in big-endian byte order
such that the byte containing the most significant bits of the
value appears first in the FITS file, followed by the remaining
bytes, if any, in decreasing order of significance.
Though it isn't until later on (in section 7.1) that it makes this connection:
7.1. Image extension
The FITS image extension is nearly identical in structure to the
the primary HDU and is used to store an array of data. Multiple
image extensions can be used to store any number of arrays in a
single FITS file. The first keyword in an image extension shall
be XTENSION= ’IMAGE ’.
It isn't immediately apparent what it means by "nearly identical" here. I guess the only difference is that the PRIMARY HDU may also have the aformentioned "random groups" structure, whereas with IMAGE extension HDU's PCOUNT is always 0 and GCOUNT is always 1.
You'll only rarely see the "random groups" convention. This is sort of a precursor to the BINTABLE format. It was used traditionally in radio interferometry data, but hardly at all outside that.
The reason for all this is for backwards compatibility with older versions of FITS that predate even the existence of extension HDUs. Many FITS-based formats don't put any data in the PRIMARY HDU and use the primary header only for metadata keywords that pertain to the entire file (e.g. most HST data).
How can I read the .las header file to determine what spatial reference system (i.e projection system, datum, etc) that a LiDAR point cloud is using?
The best answer can be found in the ASPRS specifications for what should be included in an LAS header. Look for the LASF_Projection portion of the file.
The projection information for the point data is required for all
data. The projection information will be placed in the Variable Length
Records. Placing the projection information within the Variable Length
Records allows for any projection to be defined including custom
projections. The GeoTIFF specification is the model for
representing the projection information, and the format is explicitly
defined by this specification.
GeoKeyDirectoryTag Record: (mandatory)
User ID: LASF_Projection
Record ID: 34735
This record contains the key values that define the coordinate system.
The answer for Erica is correct but partially (is based on the 1.2 las version), as in the new version of the .las format (1.4) there are quite important changes on the OORDINATE REFERENCE SYSTEM (CRS) REPRESENTATION:
Take a look at this:
http://www.asprs.org/a/society/committees/standards/LAS_1_4_r13.pdf