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

Is a GLXFBConfig's type really XID? #202

Open
nwnk opened this issue Aug 15, 2018 · 6 comments
Open

Is a GLXFBConfig's type really XID? #202

nwnk opened this issue Aug 15, 2018 · 6 comments
Assignees

Comments

@nwnk
Copy link
Contributor

nwnk commented Aug 15, 2018

(Incredibly low priority, spec-lawyer-y kind of issue, just writing it down for posterity.)

The GLX spec calls them XIDs, or at least, implies that the storage for a number describing an fbconfig is as big as an XID. But they don't really correspond to an XID inside the server, they're not in the resource database and they don't name an object. I think this is an artifact of the (X server) sample implementation, which allocates visual IDs with the same allocator as server-owned resource IDs, and then the GLX code probably copied that when fbconfigs were added. Certainly that's what X.org did when we finally got around to implementing 1.3 (the SGI SI only went through 1.2).

I'd like Xorg to stop doing the visual ID hack described above, and allocate visuals with their own allocator. I might like the ability to say fbconfigs are in that namespace, as it's unambiguous. I might especially like to say that fbconfig IDs and visual IDs are numerically equal if the visual supports GLX_WINDOW_BIT.

I guess the question here is, is the word "XID" in the GLX spec a comment about just the size of the integer, or about the namespace it came from? Is there any implementation that meaningfully differs, and could a change here possibly break an app?

@cubanismo
Copy link
Contributor

In our implementation we allocate them using FakeClientID(0) but never call AddResource() on them. Our visual IDs and FBConfigs are not currently numerically equal for equivalent visuals. I also don't know what application-visible qualities this imbues in them though. I think we require at least that:

  • FBConfig IDs are unique and persistent across a given X server instance, so logical programs that span multiple processes can look up an FBConfig XID in one process and reliably retrieve the same FBConfig when talking to the same X server in another process.

  • GLVND may also rely on FBConfigs being unique across vendors on a given X display connection, but I'd have to ask Kyle or dig through the source to be sure. You probably know more about any related server-side GLVND requirements (if any) than me.

I believe we map more than one FBConfig to a single X visual in some cases (as the spec seems to encourage), so I don't really like the idea of trying to make vid:fid map 1:1 for "equivalent" visuals/configs, but if it enables/simplifies some other useful feature we could probably find a way to rework things somehow. Our main motivation here I think was just reducing the number of visuals. We expose some horribly large number of visuals as it is, and I think it was starting to cause problems.

@cubanismo
Copy link
Contributor

Note we should be careful to disambiguate GLXFBConfig, the GL client API header type which is a pointer, and the GLXFBConfig protocol type, which is XID. I'm assuming we're talking about the protocol-level object here.

@pdaniell-nv
Copy link
Contributor

@nwnk What's next for this issue?

@nwnk
Copy link
Contributor Author

nwnk commented Feb 20, 2019

[W]e require at least that:

  • FBConfig IDs are unique and persistent across a given X server instance, so logical programs that span multiple processes can look up an FBConfig XID in one process and reliably retrieve the same FBConfig when talking to the same X server in another process.

Agreed.

  • GLVND may also rely on FBConfigs being unique across vendors on a given X display connection, but I'd have to ask Kyle or dig through the source to be sure. You probably know more about any related server-side GLVND requirements (if any) than me.

It does indeed require this.

I believe we map more than one FBConfig to a single X visual in some cases (as the spec seems to encourage), so I don't really like the idea of trying to make vid:fid map 1:1 for "equivalent" visuals/configs, [...]

That's fair.

I think the conclusion is, fbconfig IDs are not resources. Their size on the wire is the same as an XID, but they're allocated from the same namespace as visual IDs, which means they ought not alias a visual ID. The X server might have a convention about which allocator to use, and we may well want to stop using FakeClientID() for that purpose, but that's an implementation detail.

In terms of spec updates I think this just means changing the word "XID" to "int" or "ID" in a few places. I'll write the patch for that.

@pdaniell-nv pdaniell-nv added this to the Needs Action/PR milestone Mar 26, 2019
@nwnk
Copy link
Contributor Author

nwnk commented Sep 19, 2019

In terms of spec updates I think this just means changing the word "XID" to "int" or "ID" in a few places. I'll write the patch for that.

Or, I would, but I don't know where the source to the GLX spec went. I can probably find it in the internal Khronos svn but it doesn't appear to be in any of the public repos.

@oddhack
Copy link
Collaborator

oddhack commented Oct 4, 2019

GLX and GL spec sources aren't public, and GLX has been updated so rarely I haven't even moved it out of SVN into internal gitlab, which will be required since we've made SVN read-only :-) That said if you want to send me a patch against ogl/trunk/specs/glx in SVN, I'll make the right stuff happen.

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

5 participants
@cubanismo @nwnk @oddhack @pdaniell-nv and others