Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 02 Oct 2010
Offline Last Active Sep 22 2015 03:56 PM

Posts I've Made

In Topic: Reducing CPU usage in Enet thread

21 August 2015 - 12:33 PM

Finally: On windows, when the user is dragging a window around, the main loop is blocked, but messages will be sent to the window message handler, so adding a WM_TIMER timer that ticks every X milliseconds is a good way of taking care of that part of always keeping the application responsive.


I get that messages are queued up for the window, but does not the thread that is blocked during dragging prevent it from calling PeekMessage() which will trickle down to WinProc, how will one then tick Enet?



On the server, if it is blocked until it recieves a message then it can't send anything before it recieves a packed right? So if an important event needs to be sent but the server is waiting to recieve a packet, that event will have a latency attached to it?

In Topic: Reducing CPU usage in Enet thread

21 August 2015 - 10:36 AM

Any reason why blocking reads won't work?

You could have one read-thread and one write-thread for the network..


Does two threads sharing the same socket/connection work in Enet? Even though one is recieving and the other is sending, is that thread-safe?

In Topic: Reducing CPU usage in Enet thread

21 August 2015 - 05:47 AM

No, if I don't call enet_host_service() for 5 sec it breaks.

In Topic: Reducing CPU usage in Enet thread

21 August 2015 - 05:08 AM

Well, polling on the main thread might work if you manage to guarantee that it is done every 5seconds or less, or else the connection breaks. I don't really want a hiccup on the main thread to cause network issues.


Also, as AgentC said, the server side loop spinning makes the server core be at 100% usage unless I put in delays, which I don't want. So either accept 100% core usage or put in Sleep()?

In Topic: UpdateSubresource on StructuredBuffer

15 August 2015 - 01:31 PM

I just recently installed Win10 and VS Community. I did notice a graph in the Diagnostics window during debugging. But I have not studied up on how to use these tools properly. Do you know of any good places or videos on youtube?


Would be nice to know where the bottlenecks are.


Typically the GPU won't be executing commands until quite some time after the CPU issues D3D commands. The D3D user-mode drivers will typically buffer things so that they can be executed on a separate thread, and the driver will send off packets of work to the GPU at some later point. In practice you can end up having the GPU be up to 3 frames behind the CPU, although in practice it's usually closer to 1 frame.


Great to know, I hope this translates in my case that I don't have to worry about keeping the GPU busy while mapping with D3D11_MAP_WRITE_DISCARD. That it all buffers up and only when everything is ready the GPU goes bananas and produces a frame. The interface kinda lets you believe that a DrawCall is executed when called.