AMD R600/700 DRM Interrupts Support Pushed

[Adarion]

Cheers for the new specs and stuff.
I only wish 2.6.33 was already here.

[adamk]

Only kms support interrupts for r6xx+.

Is working being done to get UMS to support interrupts?

Adam

[agd5f]

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.

[adamk]

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 :-)

[rohcQaH]

in places where KMS is still not usable.

not sure what you mean, but wouldn't it be wiser to make KMS usable in those places instead of wasting time on outdated technologies?

[adamk]

Well there are certainly KMS specific bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=24124

https://bugs.freedesktop.org/show_bug.cgi?id=24263

Though, admittedly, only the former one impacts r6xx KMS for me. And, yes, it would be nice if those bugs were fixed :-)

There's also the various BSDs, which support direct rendering but do not yet support KMS and may not for a while.

Adam

[bridgman]

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.

[Louise]

Does anyone know how far KMS is from being considered done?

[adamk]

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.

[bridgman]

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.