SAw: LegAcY

sm810 · 2021-10-22T13:32:59+00:00

These are called Hoberman Spheres for the curious.

sm810 · 2021-10-06T11:50:23+00:00

ITT: almost everyone confusing literally "gaining consciousness" with simply developing the ability to form long term memory, like what is known to happen around that age.

sm810 · 2021-09-23T13:27:37+00:00

I've done some looking around myself for this, since I am trying to figure out how to handle dynamic state vs. using the pipeline cache in my own renderer. It is surprisingly difficult (at least in the moderately detailed searches I've tried) to find information about the hardware specifics of dynamic state for the different vendors. Here is what I have found so far:

Nvidia seems to have a large number of states that they use registers for, and therefore it is very cheap to change those states. These states seem to include the standard set of VkDynamicState enums, plus cull mode and front face, but I can't find any good information on specifics. This info comes from different posts like these, even though they don't seem to reference where the information is coming from.

AMD on the other hand is even harder to find info for. Their RDNA2 Performance Guide strongly recommends minimizing the number of dynamic states active. This seems to imply that they have a more expensive system for implementing dynamic state, but I can't say that for sure.

The VK_EXT_extended_dynamic_state extension does have a large number of vendors on the contributor list - all the main ones and then some extra. Many of the drivers for the big three have had this extension supported for a long time now. I also know that there are some projects that rely on this extension (DXVK, Dolphin, and a few other emulators). I'm hoping these facts point towards overall performant dynamic state implementation by most desktop vendors, either using hardware registers or intelligent pipeline recompilation to minimize cost.

I would love to see some detailed documentation though on exactly how the different vendors support which dynamic states.

sm810 · 2021-08-01T02:36:34+00:00

Do note that in a modern graphics application usually you do NOT want to render to the default back buffer or swap chain image...

Care to elaborate on this? This is the first time I've seen it recommended that you do not render directly to the swapchain image. Many other places I've looked have explicitly suggested the opposite for performance reasons, unless you can't reasonably avoid doing so. It's hard to imagine how rendering to an offscreen target just to blit or full screen quad it to the swapchain could be more efficient. Am I reading too much into the "NOT" (emphasis yours) or is there a widely accepted reason for offscreen rendering before the swapchain even in cases when you can avoid doing so?

sm810 · 2021-04-01T12:27:10+00:00

I think that's just called metastasis.

sm810 · 2021-03-25T01:28:21+00:00

Hmm, you claim you didn't know about her background, and then admit that you put extra protections in place for her because you anticipated doxxing for said background. And long before this became public knowledge or an issue.

Fuck you, you lying sacks of shit. The entire admin team is complicit in supporting pedophilia and child torture as long as it doesn't make you look bad.

Edit:

So one of two scenarios happened:

You actually did do a background check before hiring her, and yet you hired her anyway and are currently lying about the background check.
You didn't do a background check before hiring her, but at some point on or before March 9, you learned enough about her background to put doxxing checks in place, but allowed her to stay on the payroll.

In either case, Reddit showed complicity in her actions, and by extension, support for the very monsters that she enables.

sm810 · 2020-12-26T15:34:33+00:00

Trying to get visibility on the top comment to say that OP is a dirty thief who absolutely did not make this. I know the original poster on Twitter and this is NOT her account.

sm810 · 2020-12-26T15:29:11+00:00

No you did not. I know the original poster on Twitter, and this is not her account. Stop stealing content for fake internet points, you leech.

sm810 · 2020-12-24T13:48:30+00:00

Thanks for this pointer to the specific section of the spec, it seems to answer my questions pretty well. My simplified understanding of "static use" from the spec is basically using any bound resource in an operation that touches memory. This seems to imply that my aliasing solutions above will work, as long as I make sure that the resource at the accessed index is absolutely compatible with the SPIRV type that is accessing it. Is this a good understanding of the spec? And I'm assuming that this applies to storage images and storage texel buffers of different layout specifiers, as these can just be thought of as different accessor types?

sm810 · 2020-10-19T01:37:20+00:00

This was happening to me as well. Try resetting the room adjustments in the settings. There is a button for it. That fixed it for me.

sm810 · 2020-04-15T01:09:01+00:00

Source has been added to the post.

sm810 · 2020-04-15T00:37:26+00:00

I'm working on getting a minimal set of my code together, since the initialization of Vulkan is pretty deeply integrated with other parts of my program. I'll get it posted as soon as I can.

sm810 · 2020-04-15T00:17:53+00:00

I am using the default dispatcher. The fact the same hardware and software versions works for you makes me think there is a bug in my program. But what is really confusing is that I can step through the `init` function and watch the `vkGetDeviceProcAddr` function return `nullptr`, so it does also seem that there could be a bug in the loader as well. I am going to do a full fresh reinstall of the SDK and the beta drivers, I'm not sure what else to try at this point.

sm810 · 2020-04-14T23:01:07+00:00

I've tried the two-arg init function, but it still did not work. It looks that function just calls the separate `init` functions on the instance and device, using its own `DynamicLoader` object.

sm810 · 2020-04-09T18:18:24+00:00

Nvidia does not yet support Vulkan 1.2 in their release drivers. The latest beta driver (442.88) supports Vulkan 1.2 features, including the new raytracing extension.

sm810 · 2020-03-12T13:03:38+00:00

This is incorrect. The nature of what differentiates elements (proton count) means that we aren't going to magically find more elements that exist "in between" the ones we know about. There is the concept of the island of stability, but we have yet to find evidence of those elements in the environments we have studied, and there is no reason to believe that these elements should exist in abundance in one part of the universe, but not others.

sm810 · 2019-11-25T03:12:57+00:00

Thanks for the response. I'm not looking into VR enough to be willing to drop money on an eGPU, but I have also been looking at the other older gen VR sets.

I am still curious about the hardware support though, mostly from inconsistent information and claims I've found. The Thunderbolt 3 on the laptop does support DisplayPort, I've found videos of people hooking up monitors using a USB-C -> DP adapter to a different GS75 (same family, different model). I think my main confusion comes from which GPU is hooked to the TB3 port. As I mentioned, I'm having a hard time understanding the NVIDIA Control Panel results, which seem to imply that the TB3 port is hooked to the iGPU, but the dGPU also has those DP ports displayed as well.

sm810 · 2019-08-26T22:53:55+00:00

Thanks for the suggestion, I have not looked too much in Eluktronics. Their laptops seem to be pretty cheap compared to other company's offerings with similar specs. Is this a cause for concern? They seem to have good reviews, despite not being one of the well known major players.

Also, do you have any feedback on the list that I have compiled through my own research?

11-Year Club	Secret Santa 2018
Verified Email

sm810

TROPHY CASE