Clarity on GPU sync timing - Or why SDL_Delay?

SDL Development
1

I come from a background on the Mac with Metal without SDL.

Apple manages the display link timing, and calls my function, at the correct time, where I do my rendering.

I have gotten very accurate frame timing, and on the mac there is extremely accurate gpu measurements to record that the frames are rendering precisely and exactly with pin point accuracy, as I intend them, and as I control them.

When I come to assess SDL for porting to linux, I see this bizarre approach of SDL_Delay… which to me looks like a bad approach.

When I search for examples and forum posts, I have read a number of things, which give me the impression that there is some lack of something going on… there is some strange different situation with SDL or with linux and windows or with the people in the community and the way of thinking.

After searching, I did not find clarity on this fundamental topic, which in my opinion should be something that would go on the main website in a first lesson of learning to use SDL, where it would ideally be plainly explained with crystal clarity.

I may be the one confused…

But, I have trouble imagining that a user process should ever use a delay/sleep type approach.

In my mind, the user process, where the game is, should finish it’s work, and instantly return flow to the OS, and then the OS should come back at the appropriate time, calling a function in the user process, to start work again… which is how I understand the mac is working.

With SDL, linux, and windows, I am ignorant and can only make a number of wild guesses and assumptions about the reasons that a delay/sleep is being promoted and commonly accepted by the people as rational.

If someone here understands what I mean, and is using something other than SDL_Delay, I would appreciate your clarity of explanation. Since I have read another forum post of someone clinging to SDL_Delay, when this situation was brought up before, I would kindly ask that anyone who uses SDL_Delay, to kindly have the maturity to not reply to this thread at all, so that a clear straight line of dialog with others can arise and carry on, without muddying the conversation with multiple trajectories of thought trains. I greatly appreciate if such maturity can be exercised, as it will vastly help me get clear on the nature of the situation, and give space for others to read the thread cleanly in a straight line as well. Since I am sure, this is a fundamental question, which everyone new is going to learn, and I’m not sure where else they might learn it but here.

Again, I greatly appreciate any help and maturity in clarifying this situation.

2

So, first off, do not use SDL_Delay() for frame timing.

With Metal, the functionality you’re referring to is actually provided by MetalKit, which is an optional framework that Apple developed after Metal was introduced, to make certain aspects of using Metal easier. On macOS, MetalKit provides functionality similar to iOS’s DisplaySync, where you give it a function that gets called every display refresh.

With games, typically this isn’t the way things are done. The game loop timing is kept 100% under the game’s control. This can be for a few reasons, including that some players actually turn vsync off, so the game no longer waits for the display to refresh before showing the next one if it’s ready, but also because in PC-land there are monitors with adaptive sync that don’t have to refresh at a constant rate. And with new GPU APIs, games have more control over CPU and GPU synchronization (including scheduling work for upcoming frames), which is kind of the opposite of having the OS call your game main loop every frame.

What you can do

If you’re using SDL_Renderer, create it with vsync (or call SDL_RenderSetVSync()). When you call SDL_RenderPresent() your new frame will be shown in sync with the display refresh.

// create a renderer that is HW accelerated, can render to texture, and syncs with the display refresh
uint32_t renderFlags =
    SDL_RENDERER_ACCELERATED |
    SDL_RENDERER_TARGETTEXTURE |
    SDL_RENDERER_PRESENTVSYNC;
SDL_Renderer *renderer = SDL_CreateRenderer(myWindow, -1, renderFlags);
if(renderer == nullptr) {
    // uh oh, handle error
}

bool run = true;
while(run) {
    SDL_Event event;
    while(SDL_PollEvent(&event)) {
        // handle events
    }

    // Clear screen

    // Make draw calls

    // Complete all rendering and then wait until the display refreshes to do the page flip and show our frame
    SDL_RenderPresent(renderer);
}

If you aren’t using SDL_Renderer, but are instead using SDL to create your window etc and then calling Metal yourself, set the Metal layer’s displaySyncEnabled property to YES/true (behind the scenes, this is what SDL_Renderer does). From then on, your frames will be shown when the dispay refreshes. (the default is YES/true)

3

I think the advantage of using SDL_Delay is that it’s easy to use. You can essentially decide the frame rate yourself and don’t need to deal with things like variable sized time steps, frame skipping and frame extrapolation/interpolation.

And perhaps more importantly, it works even with VSYNC turned off. As far as I know, SDL 1.2 on Linux only supported “software rendering” (unless you used OpenGL) so there was no VSYNC. I can’t think of any good alternatives to using SDL_Delay unless you were fine with running a busy loop at 100% CPU usage.

Now I think hardware rendering/VSYNC is more consistently available so there is probably less reason to use SDL_Delay nowadays but some old habits die slow…

This is essentially what you’re doing when you’re using SDL_Delay except that you explicitly tell the OS when you want to start work again.

I’m sorry, I missed this request before making my reply. I do actually still use SDL_Delay but it’s not for ideological reasons. I still use SDL 1.2 on Linux because that’s what existed when I started the game I’m current working on. I will probably upgrade to SDL 2 or 3 when it’s finished. Not sure I will use hardware rendering/VSYNC for this game but if I ever start working on a new independent game I would no doubt try to make use of this because I can see the advantages (it’s more accurate and avoids tearing), though I’m not sure if it might still be a good idea to fall back on SDL_Delay if VSYNC has been turned off or is unavailable.

4

Of course SDL_Delay (or native funtions like Windows’ Sleep or Unix’s nanosleep) is needed, and yes, it should be used. This is the only option to limit the number of generated frames with VSync turned off. If we are programming a game for modern platforms and devices, saving energy is very important — especially due to the gigantic number of laptops and mobile devices used for gaming.

The game and any other software should use the minimum amount of CPU power to do its job, and release the rest. In this way other processes will have a chance to hit the CPU, and the processor itself will go into power saving mode much more often (e.g. keep the frequency low, avoid Turbo Boosting), which will increase system performance and responsiveness, and will extend battery life and lower users’ electricity bills.

The game should give the user the option to set VSync, and if the user turns off VSync (because for some reason he doesn’t want it), the game should give the option to choose the framerate — recommended (e.g. 60fps), lowered (e.g. 30fps), unlimited (maximum fps) and optionally custom framerate (any fixed number).

If VSync is disabled, any framerate other than “unlimited” should use SDL_Delay (or other forms of power saving) for limiting CPU power consumption.

1 Like
5

Yes, of course you have to do some kind of frame rate limiting if the user turns off vsync so you don’t hit 3000 fps or whatever, but that’s clearly not what @morelightning was asking about.

Also, the thing about SDL_Delay() is that it is only guaranteed to sleep for at least the specified amount of time; the OS may put your app to sleep for longer (though typically not more than a few milliseconds longer).

6

Sounds like, everyone who has responded so far, is not yet experienced enough with Apple’s setup to understand the question. And that is fair enough to understand, but it does not really allow us to get to the real topic yet and talk about it sincerely as group, where everyone sees the situation, takes it as something amiss that does matter, and then together addresses it by perhaps changing SDL or linux itself or the linux gpu driver itself… I would like to get crystal clear on which level the problem is starting… is at the SDL layer or the linux kernel/driver layer…

Perhaps if there is someone here with expert vulkan experience on linux, they may be able to address the question and bring more clarity.

Does the group that writes SDL itself, come to this forum, or is there another place where they usually hang out?

From the level of responses, unfortunately, it sounds like at the present moment, I have to make one of several assumptions or guesses or negative conclusions, such as:
A) That SDL is designed by a group of game developers, who do not care about the level of precision in frame stability that I’m referring to.
B) That linux is not setup, even with using vulkan directly, to lead to the same level of precision as the mac setup can achieve.
C) That windows is most popular, but because it’s timing ability is terrible, there is a tendency to avoid deep discussion all together. It would merely be pointing out that it is not possible on windows, and would be a point-less topic for people who are most concerned with windows, which is again understandable, but it is not a position that addresses solving the problem or seeing the problem to be important. To say it is not possible on windows, for most would simply be a dead end, and so there is a culture of accepting lower work arounds, and not seeing the real matter with it.
D) Some variable combination of the above.

However, I would like vivid clarity, and it is still ambiguous, as to what level the problem of poor frame timing architecture originates. If linux at the rawest level of access with vulkan, could give at least as equal frame control as the mac, I would simply go to do that rather than use SDL, that is… if SDL does not provide it… or if the community making/using SDL is understandably not up to going to the depth of solving it, since it would only improve linux games and not windows games.

But, my impression… and I can only make guesses and assumptions here, is that SDL is designed the way it is, because both windows and linux are not setup for it at the raw level, and there is very little perception and deep comprehension of the wider situation of why it would matter to do what I have done on the mac.

I would rather not make guesses and assumptions like the above about why things are not done in various communities, and would prefer if someone with vulkan experience or linux kernel/driver level experience could answer it… But I’m not sure where to go find those people.

At the moment, it sounds very clear at the least, that in SDL at present day time, by this community’s word, it is not possible at all, to achieve the precision anywhere close to what the mac can attain, and which I have extensively attained and measured thoroughly and followed for years.

I know how this sounds, and would very much rather I would be the person who is wrong in this scenario. So if anyone else can chime in with deeper experience than what has been posted thus far, I would greatly appreciate it. (I could break apart, piece by piece the problems with the previous responses, but I would prefer if we could instead open a clear space, for a clear line of communication for someone else to come in and talk about the vulkan layer and whether that can do what the mac is able to do.)

I do greatly appreciate everyone’s time and effort in trying to bring this matter to crystal clarity, and for the benefit of everyone, perhaps, after getting the answer I’m asking, we can go back and clarify for each person who wrote in, what the gaps in comprehension were, so that in the end, everyone can atleast be aware of the big gap, if that is something everyone would like to know. (I have seen some other communities, that don’t actually want to know, and are not interested in knowing what they can not fix, and I can understand that position too, and simply drop the conversation)

7

I wrote my post because @morelightning is surprised that SDL_Delay is widely used on Windows/Linux. This is how it looks, because these are the possibilities on these platforms. If in macOS/Metal rendering can work by callbacks-manner, that’s great, but AFAIK on Windows there is no such thing, so the loop must be written in such a way that it (i.e. the CPU) is responsible for the timing, and the use of various sleeping mechanisms are mandatory.

The second thing is the description:

What does “precisely and exactly with pin point accuracy” actualy mean? Down to milliseconds? microseconds? nanoseconds?

With VSync enabled, you get the highest accuracy, consistent with screen refresh rate, and then SDL_Delay is not needed at all. And if it is disabled, you can still get very high accuracy — just skillfully combine SDL_Delay with a short spinlock, based on SDL_GetPerformanceCounter and the assembler pause instruction. You can get even sub-microsecond precision, depending on the counter frequency (on my fairly old PC, the couter frequency is 10MHz, so one counter tick is equal to 100ns).

8

I understood your question. I have done Metal programming, both on iOS and on macOS.

I responded with information about why things are the way they are.

In short: you can synchronize to the display refresh in SDL very precisely WITHOUT HAVING TO USE `SDL_DELAY()~. I even provided a short code sample.

I also explained how getting a callback to “draw stuff” every frame from the operating system isn’t actually part of Metal at all, but MetalKit, an optional, kinda-training-wheels way to get Metal set up. Under the hood, SDL uses Metal on macOS and iOS.

Yep, they pop in here from time to time.

You don’t need something like what MetalKit provides (the OS calls an application-provided function every frame) to get extremely high display refresh accuracy. You don’t have to use SDL_Delay() either! Just use the facilities SDL provides (namely, creating the SDL_Renderer with the PRESENTVSYNC flag, or enabling it by calling SDL_RenderSetVSync()).

Also, yes, of course SDL is mostly meant for games.

I’m neither a Linux user nor a Vulkan defender, but this is completely false. You can achieve the same level of “precision” (whatever you mean by that) as on macOS.

My daily driver computer is a Mac, and I’m in no way a Windows defender. But you can easily sync with the display refresh on Windows, the same overall way you would on macOS when not using MetalKit.

As I mentioned in my earlier post (right under your OP!), game developers writing code down at the level of game loops, using SDL directly, etc., do not want to give up control of their game loop and presentation timing, which is what MetalKit or something similar requires.

The reasons are varying:

  1. Adaptive sync displays that don’t update at a constant rate anyway, so games can render frames quickly and get them displayed (without tearing) as soon as they’re done, so long as it’s a timing the monitor can do.
  2. Users sometimes turn vsync (display refresh synchronization) off. Which again means it doesn’t make sense for the OS to be calling an application-provided function every time the display refreshes.
  3. The OS calling an application-provided function in which to do all rendering isn’t making very good use of Metal, Vulkan, or DX12’s fine-grained CPU-GPU syncronization functionality.
  4. Vulkan and DX12 allow the application to have much more control over the swapchain (drawables in Metal) than Metal does. Including the ability to discard a finished frame that hasn’t been shown yet if a more recent frame is completed and ready to go.

I would rather not make guesses and assumptions like the above about why things are not done in various communities, and would prefer if someone with vulkan experience or linux kernel/driver level experience could answer it… But I’m not sure where to go find those people.

So, again, SDL provides the ability to explicitly synchronize your application to the display refresh. This doesn’t require SDL_Delay()!

Even when I write Metal code directly, I don’t use MetalKit, which means I don’t use its display refresh callback but instead use Metal’s own lower level display sync.

It would probably be helpful if you told us exactly what you’re trying to do. While SDL is mostly aimed at cross-platform game development, people have successfully used it for other things, including things like video players.

1 Like
9

Can you share some code of what are you talking about? See if this case of iOS is what you mean.

Game Center integration might require that you break up your main loop in order to yield control back to the system. In other words, instead of running an endless main loop, you run each frame in a callback function, using:

int SDL_iPhoneSetAnimationCallback(SDL_Window * window, int interval, void (*callback)(void*), void *callbackParam);

This will set up the given function to be called back on the animation callback, and then you have to return from main() to let the Cocoa event loop run.

e.g.

extern "C"
void ShowFrame(void*)
{
    ... do event handling, frame logic and rendering ...
}

int main(int argc, char *argv[])
{
    ... initialize game ...

#ifdef __IOS__
    // Initialize the Game Center for scoring and matchmaking
    InitGameCenter();

    // Set up the game to run in the window animation callback on iOS
    // so that Game Center and so forth works correctly.
    SDL_iPhoneSetAnimationCallback(window, 1, ShowFrame, NULL);
#else
    while ( running ) {
        ShowFrame(0);
        DelayFrame();
    }
#endif
    return 0;
}
10

Everyone please listen,

I have attained clarity and enlightenment on the original topic of this thread.

Here are the clear facts as of today:

A) SDL can not do what is correct.
B) Vulkan on linux fails to provide what is correct.
C) A vulkan “extension” has been in slow development since around 2016, but is not complete.
D) All vulkan and SDL projects will stutter because of the above. Extra Stuttering is coming from poorly written software.

These are the straight facts, by thorough assessment of SDL and vulkan on linux.

A master of vulkan and SDL, had they been present, could have plainly read my mind, in my first post, and answered it straightly, that vulkan was not designed to do it correctly, but that they know about it, and at some point will get around to writing it.

As to responding to the many rabbit trails expressed in this thread… I think it is better not to.

It would only serve to bother people, and it does not sound like anyone is originating from a position for sincerity of quality, health, and comprehends the relationships and reasons why, the fundamentals like precision frame timing and stability, is important for human health across millions of people world wide.

Simply, if people did have such clarity on health and quality, they would treat the subjects entirely differently.

I was merely assessing the landscape with acuity, and have discovered something very unfortunate.

I’m going to take a break.

If I am a human being, sincere about the health of the children and millions of people using the software, I must now look at many things like this, and the unhealthy game controller hardware that damages the body and diminishes healthy brain function.

I understand if such moral things are unwelcome in conversation, but I must now go and focus on working on those.

At some point, if each of you would like to gain clarity or work on the real things, I can take more time to explain for the true benefit of everyone.

But for now, reading all your posts and responding to each rabbit trail, is a little bit of a diversion, unless it will motivate you to work on any one of the many real health problems in game dev that diminish everyone’s intelligence capacity. I would like to focus more time with people who wish for the health and intelligence of the whole earth to rise, and who are in enough clarity and enlightenment space already, to start to contribute the work that actually needs to be done.

In any case, thank you for your time.

11

For ‘perfect’ results you must render a frame not according to the time now but according to the time when it will be displayed. Since that is in the future it poses quite a problem!

The best you can do is to assume that the frame rate is constant, in which case the next frame will be displayed exactly one frame period after the previous frame was displayed, which is something that you can - at least in principle - know.

In general a precise timer is neither necessary nor helpful, because that will tell you the time now, not when the last frame was displayed (nor when the next frame will be displayed).

12

Oh, you’re trolling.

2 Likes
13

Please kindly stop adding additional pollution to the thread.

I gently stated that I had reached the bottom of the real circumstances, and I have enough intuition of everyone, and am simply gently skipping over posts that are not aligned to the thread topic.

If you would like to really know, you may find the log of the progress on this issue in vulkan here:

To solve the real problem, which is not understood in the SDL circle, I must go edit vulkan… which is beyond the space, that I sense, the people here are willing to go. I feel I understand everyone here deeply, but you all do not understand me at all, and I was trying to be gentle about it.

The level of miscommunication and misconstrued notions has been immense, and was not intended.

14

You asked how to match your drawing with the display refresh using SDL. I explained how to do this without using SDL_Delay(). I even explained why things are the way they are.

You skipped over it, and posted whatever this is:

Then there was some mention by you about how all Vulkan and SDL apps have stuttering, which is clearly not the case.

2 Likes
15

I understand how you feel.

If I was in your shoes, I might feel the same way.

But, I assure you, Unnecessary Stuttering, exists in all vulkan software today.

That is something known clearly, only to those who work at deeper levels.

It is understandable that the folks here, have not been working at those levels, and are insensitive to the existence of many things like this. I don’t want to make anyone feel very bad about that… but it’s like, I was trying to avoid directly invalidating you, when it wouldn’t have helped me to the answer, and it wouldn’t have helped you either, and just would trigger you… So, I perceived this situation, and a thousand other complexities unsaid in you and each of the others, and I tried to not respond to your post in the beginning, and asked everyone to clear space in the thread, in hopes that a vulkan expert might step in.

But, there was some disconnect in communication, and people kept writing.

During that time, I read the SDL code on github, and saw that SDL was doing this work around.

I went then to vulkan code base directly, and saw that the problem was that vulkan neglected to implement the system in the way which would give magnitudes better stability.

It was crystal clear, that SDL was designed in complete unawareness and worked with what it had… Because the vulkan guys were also unaware and designed it improperly. Try to recognize the chain there.

SDL being mainly a windows user base, would also have no clue about such complex matters that are buried in the graphics drivers. And as you know, that led to an attitude of working with what they have on windows and accepting whatever low quality standards are provided by Microsoft/Nvidia/etc. This is all understandable.

However, a person like me is coming from a very different space, and introduced something which is complex from that space, you all are not familiar with… and it invalidates the ground floor of what was being posted. But, as I said, I did not want to start a fight, it would be fruitless, so I continued to work on my own and find the answer to my own question.

You see, for me to ask the question to you, is unfair, unless you have the experience. Those who have the experience would not have any trouble understanding my question, nor debate the plain reality of the stuttering…

For example, if you are wise, you will recognize that in the link to the vulkan thread, the guy there writing vulkan itself, he expresses clearly, that he was not aware of the situation before it was brought up, but after it was brought up and the complexity was explained, he understood the guy who reported the problem. The vulkan guy clearly says he understands it, and the entire topic is to write it better, and not stutter. They are talking about the same stuttering that I am talking about. Try to clear space and read the entire log and continue reading by following to the vulkan extension page further, if you truly would like to understand why your posts are not valid to the scene where I am and they are. We are not both yet in the same room, or same level of comprehension of the whole system yet. And this is why you write these things and argue with me. There is no point to argue about it. If alternately, you are arguing because deep inside you would rather there not be a real problem and huge space that you are completely unaware of, then I can only gently suggest to you, that such a position will block you from true learning about the many circumstances that others like me are involved in with enormous depth beyond the space you know.

I do not want to make people feel bad, and so as I said, I was trying to not invalidate everyone at the very beginning, because it would only make people get upset and try to defend SDL because you are fond of it.

It’s like I was trying to tip toe around you guys, because I could read everyone’s cognitions and background space very vividly.

But, now that I got to the answer of what level the stuttering needs to be fixed from… In Vulkan, because vulkan is written poorly - now we can move forward in correcting everyone here about everything, if they are truly interested in ‘whatever turns out to be true’…

If individuals are not really interested, and would rather not know, and start from defense and not listening and not reading thoroughly… then I’m not going to continue much further in debate, for people who it bothers, and where there is no fruit from it.

If you read the vulkan issue thread, you will also see, they are aware it should not be a “vulkan extension”, but should actually be in the core of Vulkan. Perhaps you can make some calming tea and read through and see if you can grasp the situation better now.

We can remove the stuttering in vulkan.

But, if people want to debate that there even is a problem, then you put up a huge friction to knowing the reality and getting it solved. What benefit do you gain from fighting me on this?

I am sincerely here trying to improve the physical health and intelligence across the world, and in some gentle way, to educate anyone on a problem, it often means introducing a space which invalidates you and has an enormous amount of background understanding and experience of why something is important, why it truly matters, and what all the consequences are, which are being neglected by those who are not in a space which understands them. Somehow, I have to gently do that on a thousand levels, without making you feel bad. It’s like, I’m coming half way to help here, to make SDL better, but you have to come the other half way, without fighting, if there is any hope for real communication.

I have a huge number of hardware and software changes to address, for vastly raising the health and therefore vastly raising the intelligence of everyone. This is just one thing on my list.

It’s like, if I point out, that I am a former Apple employee, and also I work in hardware R&D of a vast wide range of things, and also I build nuclear reactors… I’m coming from a different comprehension depth… and I say to you, there are complex things we know about matter by direct first hands experience, which show that by using any of the game controllers currently on the market, the human vastly diminishes brain function and health… and that’s going to make you uncomfortable, because you use those controllers a lot and don’t want it to be true that your intelligence has been compromised on a vast scale that you are not cognizant of, not sensitive to detecting. A clouded man, feels clear, and only recognizes the cloudiness, after he is cured. We know this extremely well in the reactor space. We have extensive experience with a million phenomena like that, and very advanced forms of measurement people don’t know about. And I say, a similar thing is happening with the stuttering problem, when it’s brought up, it makes you uncomfortable. And I want you to know, it’s completely understandable, and I don’t want you to feel bad or be defensive or argue and fight. There is no point. I’m trying to do real work here… and to some degree, I have compassion for your stance, but try to understand my position… if I have to fight a million people who don’t want to know… it’s like I’m going to start reading people, and depending on their level and degree of sincere intent, I am willing to pause and take time out to explain a little… but if you want to fight, I’m not here for that, I have work to do. Every day that passes, children use these toxic controllers, and we know the answer, so I have a lot of real work to attend to. We now know the toxic hardware choices of the whole computer, and we know how to solve it. Try to put yourself in my shoes, and see that I can only spend so much time with the SDL group here, if everyone wants to hold their wrong notions and fight. If you want to know anything, I share openly… my rule is… maturity, no debates, no fighting, no memes or laughing things off in satire. I’m working with very severe things, and I take it very seriously.

Right now, on this issue with SDL and Vulkan, the answer is now crystal clear:

To solve the stuttering and vastly improve frame stability in SDL and vulkan, we need to change the core of vulkan, or at least get that extension published. Then SDL itself, would be redesigned for the more correct structure on linux.

I don’t expect anyone who wrote so far, to have a mindset, that they are going to help with that, so I’m just going to the work itself, and I said, I’m going to take a break now that I found clarity with this piece.

The only further communication here in SDL, would be to offer explanation and correction to everyone here, for the benefit of everyone. But if that isn’t welcome, I’m going to get back to work on the other stuff and walk away.

The topic of this thread has been achieved. If there isn’t maturity to handle what I’m sharing, perhaps a moderator can lock the thread, to prevent further unnecessary pollution by people arguing about whether what I have stated is simply true.

16

Probably relevant: The Elusive Frame Timing. Finally, an explanation for why some… | by Alen Ladavac | Medium
or the slides of the corresponding GDC talk: GDC Vault - Advanced Graphics Techniques Tutorial: The Elusive Frame Timing: A Case Study for Smoothness Over Speed

Unfortunately I couldn’t find the video, though I think I’ve seen it at some point in the past?
Update: Here’s the video: GDC Vault - Advanced Graphics Techniques Tutorial: The Elusive Frame Timing: A Case Study for Smoothness Over Speed !

The Vulkan extension that article/talk is about is VK_GOOGLE_display_timing - is this what you want?
In that case, there already is a solution for your problem (on the Vulkan side), but possibly not implemented by all drivers (I didn’t check).

If you want to implement whatever is needed in SDL to make this work, I’m sure that would be appreciated, and if it needs changes to the API, this is a very good time for such changes because SDL3 is still in development and the API isn’t set in stone yet :slight_smile:

17

Daniel,

VK_GOOGLE_display_timing is not good.

There are no existing correct solutions yet.

There is a large zone of confusion as to ‘what is really needed’ and ‘why’.

Because of this confusion, the attempted approaches, end up not correct.

When I design hardware, from the fundamentals of raw matter, everything is very clear.

This clarity of the whole picture of the fundamental ground, gives direct insight as to correct answers, which exist beyond the realm of opinions, and the strange artificial space software developers live inside.

What I witness, is that the root problem with getting this fixed, has been that the software programmers are ungrounded in fundamentals, and from starting to think and work from a space ungrounded in matter fundamentals, they take subtly wrong action, and neglect the fundamental things ‘that are actually needed’. It results in pseudo ‘solutions’ like VK_GOOGLE_display_timing and the other vulkan extension which they have been struggling with the last few years.

What I am witnessing at scale in vulkan, is a disaster zone of poor decisions.

In this current moment, I can see the whole situation clearly… but the conclusions of clear sight of the whole problem space, lead me to write an official assessment report, that recommends action steps to work directly to arrange an entire replacement, instead of vulkan, along with a genuine quality compositor.

It is much faster to write a wholistic system from scratch, in the clearly correct way the hardware works.

So in my assessment report, that I am writing after surveying the landscape, this is what I will be recommending as the highest correct solution, which happens to be both feasible and more easy and straight to do.

My intent was to ‘have the true circumstances be revealed, whatever they may turn out to be’, and then ‘arrange what is truly needed to be correct’.

It is unfortunate that the objective assessment of the space, has been severely negative for the present day, and that most people here will likely still be in deep confusion and diminishing health and intelligence for some time.

All I can do to help the folks here today, is strongly recommend that all game developers take 4+ months of break, from using all the hardware and software completely, in order to regain a little more of the brain capacity and health, and thereafter be able to work together and arrive at more correct solutions for each thing naturally. The severity of this recommendation for the true benefit of everyone, can not be understated. If the people do not need to use the hardware and software for survival, until solutions are in place, they should try their best to muster up the self-less maturity and wisdom to heed this warning seriously.

That is the best I can do to help you at this time.

18

Well, it was April 1. Not sure what his excuse is now, though…

4 Likes
19

The shallow surface appearance of “success”,

Is not the same as ‘What is truly needed to be correct’.

In order to understand what I have said, you need the fundamentals of matter, beneath the software illusion.

As a person goes toward the fundamentals of matter, we get simpler.

For instance, most of you, only know about the API interface of DirectX, Vulkan, and Metal.

On the shallow surface, these appear complex… and convoluted.

However, I know that beneath Apple’s Metal API, is a much simpler thing.

Exponentially simpler by unbelievable magnitudes.

To program with the gpu at that simpler level, is vastly easier and more straight forward, than the convoluted nonsense in those surface APIs.

You would not believe how true this is, from your position of living in convoluted complexities of symbolic abstraction in higher level programming interfaces.

All of the million arguments that software programmers have, can be vaporized, when we simply look at the medium beneath the layer they live inside.

Plainly, we can look at the simplicity of, for example, the gpu calls underneath Apple’s Metal API, and we see this truth very clearly.

If we want a healthier computer system that fires regular intervals into the brain and body, then, the million arguments of confused software programmers, can be bypassed.

We simply are going to work at the simpler root level, and arrange it correctly from that level.

The people who only have experience with the software layer, are trying to solve the problem by patching the surface layer… which is enormous convolution of higher level abstracted symbolic programming libraries like Vulkan, Metal, DirectX, and the further layers above that in your game engine structures… The people who are trying to solve it from that layer, are not completely solving the real problem. They are beginning from the confused space of their layer, and then doing a patch, and then using shallow methods of measurement to grade themselves and call it a day.

No. I do not accept that as a real solution, if I am truly a moral person who has a sincere intent to raise the health and intelligence of the world by fixing the real problem. It would just be disingenuous for someone like me, and it would be ignorant or negligent of the physical medium.

That is why I simply pointed out that VK_GOOGLE_display_timing is not a genuine solution, and alluded to the video being a way of grading, that looks from the high level down, instead of the bottom up. And which is a direction that stereotypically makes a million errors of this kind.

Get to the fundamentals of the matter space outside your medium, and you will understand the things I say more easily.

At the simpler layers, we can in fact easily replace the window compositor and vulkan entirely with much less effort than it takes to write 1 game. This is a fact, that I don’t sense that any of you has grokked yet.

You live in a convoluted complex layer and so you assume it is a big deal. You look at the many open source projects that are convoluted and a mess and huge, and you think that’s just how it is. No. That’s what it looks like when it’s done wrong. That’s what it looks like, when the developers originate from a space of diminished brain function. And collectively, even if you have one clear programmer in an open source project like vulkan, you will have all the others pollute it and destroy it rapidly. That’s not ‘just how it is’. No that is a diminished condition of the physical brain at scale, and lack of coming to terms with it as a group, and curing the disorder.

We saw this with Swift. In the beginning a prototype of a simple language was made, and later in open source, there was “democracy”… meaning a hundred cognitions of convoluted minds made poor decisions collectively on a run away train to low intelligence land.

Then we witnessed users of Swift across the world gradually diminish in intelligence. It was plainly clear in what they made across time. They personally, would not be able to clearly state to you, “Swift has diminished my intelligence and level of brain function”… they could not say that with self awareness, because the mind had already taken the shape of the medium.

Try to realize the wider circumstances and depth that I write from.

I build clean nuclear reactors.

I am not trying to “generate energy”

I am not doing what you think I am, and my reasons are very different, and the standard of matter perfection to get the result, is very different.

We have figured out the fundamentals of matter.

I am going to the root, and finding out what there is.

Then I am coming and saying things to you, which sound far out, and are incomprehensible to you… but which is changing the world at a level that makes all the focus of software very miniscule.

What we need to do now is apply the facts of the fundamentals of matter globally for the health and intelligence of everyone. There are no opinions anymore, when we have what we have.

It will be much easier if everyone could muster up the immense maturity to handle it, and understand why I am saying it is so important that these things are fixed the right ways.

Sunk cost is not intelligent.

Drop the sunk cost, you raise intelligence.

Within a trivial amount of time, the entire system can be replaced, by approaching it from the simpler level.

No one here is above the laws of physics which are diminishing your intelligence by using bad hardware and software.

You are being heavily shaped by the medium. And the medium is very bad right now.

I can’t condone children using the hardware and software. We have immense measurements. It would be immoral to turn a blind eye and encourage children to play on hardware which destroys their physical brain capacity to such degrees.

I don’t want to live in a world where the younger people are going to be thoroughly messed up. I would like to see the children become better than us.

I am talking about correcting the medium, which corrects you, and everything you make.

The space beneath you.

That is going to take enormous self-less maturity of each one of you, to not respond in subtle self-defense and deflection or ignore it.

If you can not go where I have gone in life, you will not be able to hold the proof in your own hands, and your only chance right now today, is to heed what I have said, and throw away the controller. Throw away the touch screens and drawing tablets and capacitive trackpads.

Not reducing the time spent, No.

Reactor experiments in my building has shown this very clearly. You must stop completely for 4+ months to stop the active damage to your body, and then work on regenerating the brain matter and function, using the best available to you.

It’s like absurdly low standards of quality and shallow sense of caring… negligence… not intelligence not listening… and the people are shaped by the medium they are living in, and can only think in terms of the space they are in. You guys could only think about my question from your bubble, and could not see the whole space. That’s how your minds work, when people are not using the full brain, the writer can only think in words, the painter can only think in terms of images. So you can’t even think the unthinkable thoughts, to take the simple action, because you live in a mental landscape where you block yourself from taking actions that would lead to genuine intelligence and comprehension of matter. You laugh off what is said, and choose to remain in a diminished state of brain function, rather than do the smart thing and realize there is a real potential for intelligence waiting for you, that you have never known in life, because of having low standards and thinking it doesn’t matter. You never find out it matters.

You must realize at some point, that in other parts of the world, people do not need to eat solid food anymore, because we overlap super magnetic clean material lasers in the brain. If you use VR, it’s plain as day that you should not stick that on your head, nor use wireless headphones. If you take someone with low standards who thinks electricity is generic energy and not matter of different kinds, based on the junk conditions arranged by negligent engineers… that person is going to build damaging hardware and software, think it’s clean and good, and not become healthy and intelligent. “Everyone else was doing it and saying it didn’t matter” - will not save them. They will destroy their body and brain, because of low standards and attachment to sunk costs of low brow popular cognitions, and progressively have cognitive blindness which causes them to continue to make poor choices, and become dimmer and dimmer, across long periods of time, all while feeling “normal” and thinking they are intelligent. The million “makers” and circuit ‘hackers’ with soldering irons doing dirty things and thinking it’s okay because the software works… that is not intelligence at all. That is not full brain use at all. That is like patting yourself on the back for feeling intelligent in completing a lego, while making something that physically damages your body and brain, and being completely ignorant to what people like me are doing with transformation of matter with nuclear reactors, and how it invalidates the whole tech scene and academic theories. If you can only hear what I say from your limited space of low quality, that you call high quality, then in reality there is a huge space you are blocking yourselves from even beginning to enter, because of your stances. Not a single person here, asked in a sincere way, why it was universally important that the frame timing be done truly right. What someone asked once, was what and why “I” wanted it. Not why it is important for mankind. Not even why it is important for your own life. Someone who genuinely cared in that way, would have typed in a different way, and I would have picked it up. I am extremely disappointed in how this thread went and overall state of the community here, but I understand where everyone in coming from and won’t hold it against you. Anyone can become smart by raising their standards and by stop doing wrong things. Just turn around on a dime and start doing right today. Just like that. It doesn’t matter that everyone has been doing wrong things. In my R&D building, we have real technology to make healthier computers… but it requires maturity and rising to high standards from people like those in this community and across the scene. Else, just like open source projects, the low standards of the people’s cognitions will rapidly pollute it. Just look at how no one was patient enough to listen to what I wrote at the start of the thread, and give space for other experts to talk. If you want people like me to share with the open sources communities, the maturity level has got to be way higher. Otherwise, I feel like I have to black box it, like Apple, to ensure the health of the children is not compromised by developers who don’t think it matters.

If you heed this warning seriously, and drop all the junk you are using… Then you all will actually become geniuses, and we can have real conversations about entire spaces that you don’t even know exist right now, and what we are all trying to do.

20

Ok, who let ChatGPT in here? :wink:

3 Likes