• Login
  • Register
  • Dolphin Forums
  • Home
  • FAQ
  • Download
  • Wiki
  • Code


Dolphin, the GameCube and Wii emulator - Forums › Dolphin Emulator Discussion and Support › Development Discussion v
« Previous 1 ... 7 8 9 10 11 ... 111 Next »

Why was GCC Adapter polling implemented the way it is ?
View New Posts | View Today's Posts

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Thread Modes
Why was GCC Adapter polling implemented the way it is ?
01-23-2019, 07:05 AM
#1
Arte
Unregistered
 
Hello,

I have recently begun looking thoroughly into the Dolphin implementation, and while looking into how it handles GCC Adapter polling, I was very surprised to find the following code (Source/Core/InputCommon/GCAdapter.cpp) :

Code:
static void Read()
{
 int payload_size = 0;
 while (s_adapter_thread_running.IsSet())
 {
   libusb_interrupt_transfer(s_handle, s_endpoint_in, s_controller_payload_swap,
                             sizeof(s_controller_payload_swap), &payload_size, 16);

   {
     std::lock_guard<std::mutex> lk(s_mutex);
     std::swap(s_controller_payload_swap, s_controller_payload);
     s_controller_payload_size.store(payload_size);
   }

   Common::YieldCPU();
 }
}

This is an odd way of implementing polling, with the first implementation one would think of being periodic polling (especially since, I believe, the USB standard expects interrupt transfers to be periodic - not that it matters in the adapter's case).
Yet, as I interpret it, here we yield the CPU after each USB transfer request, and do another one when the CPU is kind enough to let this thread resume execution. (Looking at USB request block trace, with little CPU load, on my computer, this actually behaved close to periodic behavior - ~every 0.8ms)
I was unable to find an explanation of why this is done the way it is. Since this is quite critical code, I suppose there is a good and technically advanced reason for it, and was hoping whoever knows could explain me.

Thanks !
Reply
01-23-2019, 09:20 AM (This post was last modified: 01-23-2019, 09:41 AM by Billiard26.)
#2
Billiard26 Offline
Developer
**********
Developers (Some Administrators and Super Moderators)
Posts: 2,653
Threads: 8
Joined: Feb 2010
The YieldCPU is probably unnecessary as libusb_interrupt_transfer is blocking, but other than that the code seems fine. There have been a lot of hands in this file. It's been changed around quite a bit, a few times, in attempts to get better behavior.

It's possible that the yield is alleviating CPU usage in situations where libusb is in an error state and returns immediately.

And I wouldn't really agree. The code isn't that critical. 0.8ms is a long time in perspective. Even when yielding your OS is going to allow this thread to read input long before you'd notice any delay.
Find
Reply
« Next Oldest | Next Newest »


  • View a Printable Version
  • Subscribe to this thread
Forum Jump:


Users browsing this thread: 1 Guest(s)



Powered By MyBB | Theme by Fragma

Linear Mode
Threaded Mode