Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PresentMon service and client PresentMonAPI2.dll backward/forward compatibility #383

Open
AlexUnwinder opened this issue Dec 22, 2024 · 1 comment
Assignees

Comments

@AlexUnwinder
Copy link

I started attaching recently released PresentMon 2.3.0 service to my project and noticed that it seems to return completely broken data in pmConsumeFrames() for client application using PresentMonAPI2.dll v2.2.0. Is doesn't look like intended service's behavior for me. The service should either provide backward compatibility for older versions of client's API libraries or return error inside pmOpenSession() to prevent such clients from reading invalid data.

@AlexUnwinder AlexUnwinder changed the title PresentMon service and client PresentMonAPI2.dll backward/forwar compatibility PresentMon service and client PresentMonAPI2.dll backward/forward compatibility Dec 22, 2024
@planetchili
Copy link
Collaborator

Hi Alex, sorry for the delay in getting back to you. You are absolutely correct about the protocol binary compatibility between the middleware and the service.

The intention is and has always been to guarantee backward compatibility between the service and older middleware versions. We began this work by implementing the V2 dynamic query API and the introspection system, building those new systems on top of the existing shared memory module (named the Streamer).

The second part of this transition is to replace the Streamer with a more flexible shared memory buffer built on boost.interprocess, using named objects instead of fixed byte offsets to reduce brittleness by giving us added flexibility to position objects within the shared memory segment, using dynamic strides for elements within buffer objects to allow element data structures to grow without breaking compatibility, and much more.

Unfortunately, this second part was deferred in order to address more pressing issues, and so we do not as of yet have the strong backward compatibility guarantee that we intended. My apologies for not communicating this state more clearly in the documentation. I will bring up your issue in our next meeting and discuss finally prioritizing completion of this transition.

Incidentally, if you have any ideas or feedback about the IPC subsystem for transferring data, including versioning of the binary protocol, the introspection, the dynamic query API, etc., please don't hesitate to share them. Once we finalize the IPC system, this will be our final opportunity to introduce large breaking changes into the API and the binary interface.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants