If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Is working being done to get UMS to support interrupts?
No. Because of the way interrupts work on r6xx+ (another ring buffer in gart), it's not really easy to do with UMS without a lot of work in both the drm and ddx. With UMS the ddx initially allocates memory, so it would have to be updated to reserve a portion of the gart for the interrupt ring buffer then you'd need to add a mechanism to tell the drm about the new allocation, then you'd have to update the drm to set up and use the interrupt ring buffer. It's a lot of work for little gain.
Well I'd disagree. At least it would work for r6xx/r7xx across the board, in places where KMS is still not usable. But, then again, I'm not the one would be be doing the work :-)
Here's the thing -- without KMS (or at least without GEM/TTM) the 3D stack is going to be mired at GL 1.4 forever. That was OK a couple of years ago but my impression is that something more is needed today (at least GL 1.5 + GLSL) in order to be broadly useful, and even getting to GL 1.5 *does* need a memory manager.
It's possible in principle to implement GEM/TTM without KMS, of course, but the KMS part should be much easier to port to another OS than the GEM/TTM part so it seems that fixing KMS/GEM/TTM bugs and getting GEM/TTM running on other OSes is a better use of time than backporting to UMS.
That would obviously need to be revisited if progress on stabilizing KMS/GEM/TTM stalled for some reason.
Here's the thing -- without KMS (or at least without GEM/TTM) the 3D stack is going to be mired at GL 1.4 forever. That was OK a couple of years ago but my impression is that something more is needed today (at least GL 1.5 + GLSL) in order to be broadly useful, and even getting to GL 1.5 *does* need a memory manager.
Are you sure about that? On FreeBSD, which does not have GEM/TTM/KMS I'm getting "OpenGL version string: 1.5 Mesa 7.8-devel" :-)
Besides, we're not talking about GLSL here, anyway. We're talking about sync-to-vblank, which apparently now has a dependency on a memory manager.
Yeah, I see that on my UMS system as well. It's on my list of "things to check with Alex" but my first impression is the driver reports the same GL level on UMS and KMS even though more features are available with KMS (and those features are required for GL 1.5).
I suspect if we look closely at extensions vs GL level on UMS we'll find some extensions missing.
Comment