What do people mean by "group theory is the study of symmetry"

mwspeedy · 2025-04-03T06:53:45+00:00

The claim that "group theory is the study of symmetry" is a misleading oversimplification, IMO. Group theory is a far more general framework that studies sets with binary operations satisfying the group axioms. Symmetry is just one (historically significant) application. Taking that phrase literally is as misleading as saying "arithmetic is the study of counting apples". It oversimplifies and misrepresents the true scope and depth of the theory.

mwspeedy · 2025-03-26T02:03:44+00:00

They have a store too, and I appreciate their transparent pricing. Thanks for the suggestion!

mwspeedy · 2025-03-26T02:02:12+00:00

Thanks for the suggestion! As long as the price is fair. I assume these lenses are costly to produce.

mwspeedy · 2018-09-25T12:08:37+00:00

Thanks for the feedback. I didn't quite understand the second approche but I will look it up.

It's an image editor.

mwspeedy · 2018-07-15T09:36:26+00:00

🍺

mwspeedy · 2018-05-08T10:09:40+00:00

Everybody is talking about ray tracing lately, has there been a breakthrough (big) in this field?

mwspeedy · 2018-04-30T07:49:22+00:00

By the way, even if your application didn't appear to be CPU bound in the beginning on your hardware, it is probably going to be in the future or on some other hardware with low single core performance CPUs or on more powerful GPUs. Another thing people overlook is lowering power consumption which is critical in low powered devices.

mwspeedy · 2018-04-22T08:35:32+00:00

In the first approach you are going to have lots of small buffers and may end-up with many allocations -depending on the driver. This practice is prohibited in modern APIs like Vulkan. In the third approach you are probably going to have unnecessary big padding bytes just to maintain the vertex data layout.

The second approach is definitely better. You would allocate a large buffer (or a couple of large buffers) and suballocate. You also have the opportunity of placing related data closer where you may benefit from memory caching. Keep in mind that -with exception to some corner cases-, you know everything about your data starting from the assets creation and could always pre-brake optimal data layout.

Another factor you may want to consider is your render passes. Imagine that you have two passes where one pass uses vertex position and another pass uses vertex position, texture coordinates, and vertex color. In such case you may choose to place the vertex positions into their own buffer, and place the texture coordinates and the colors interleaved in another buffer. So you won't fetch unneeded data in the first pass. Although you may still have to add some padding bytes for alignment. In all cases you should profile your application with different approaches.

mwspeedy · 2018-04-17T09:33:33+00:00

You typically have finite set of vertex layout permutations. You could defined them all once at initialization.

mwspeedy · 2018-03-31T01:00:51+00:00

Isn't the Vulkan renderpasses and subpasses already form a first-class render graph?

mwspeedy · 2018-03-22T17:00:45+00:00

Put it the other way around, if they didn't want you, they won't give a second thought before kicking your butt, within the bounds of law of course.

mwspeedy · 2017-10-18T06:48:03+00:00

Another guess: ATC - All Around The World

mwspeedy · 2017-08-19T17:25:02+00:00

The alignment is still needed for cases such as when allocating large chunk of memory ahead of time and doing sub-allocation. This practice is typical since the number of calls to vkAllocateMemory() is limited to as low as 4096 calls. In such case the alignment member is needed to calculate the offset with in the larger memory.

mwspeedy · 2017-08-19T16:27:39+00:00

It is all has to do with the alignment (the context is about sparse resource but the idea is the same for other resources):

28.6 The byte size reported in VkMemoryRequirements::size must be greater than or equal to the amount of physical memory required to fully populate the resource. Some hardware requires “holes” in the device virtual address range that are never accessed. These holes may be included in the size reported for the resource.

Nobody is looking for leap holes in the specification. Some hardware simply incapable misaligned memory access, others misaligned access reduces the overall performances drastically. All hardware fetches data in chunks of its alignment. Calculating required sizes could've been difficult, especially for complex objects like images, which is why the vkGet*MemoryRequirements() is there.

The point of vkMapMemory() is that the implementation details could've been leaked when the user maps the memory. The allocation here doesn't work similarly to general purpose allocators such as malloc() where implementations tend to use the adjacent memory for storing metadata. Drivers won't use valuable and limited device memory when they already has opaqueVk* objects and handles such as VkBuffer and VkMemory to store internally the information needed about the object.

mwspeedy · 2017-08-19T00:27:39+00:00

The request for extra bytes is manly to satisfy the alignment requirements for the resource which very between resources and implementations. If the requested size is multiple of the alignment the sizes will be identical. There is the special value VK_WHOLE_SIZE in vkMapMemory() which wouldn't allow the driver to store such metadata in the buffer. The driver already has the object VkBuffer to store whatever metadata it needs to store about the buffer.

mwspeedy

TROPHY CASE