Hi,
what is the status of DRM_MGA on x86_64? It has been marked broken about
10 months ago with no detailed explanation.
Tom
--
T h o m a s Z e h e t b a u e r ( TZ251 )
PGP encrypted mail preferred - KeyID 96FFCB89
finger [email protected] for key
Experience is what you get when you expected something else.
Hi again,
I have now changed Kconfig and successfully compiled, loaded and used
DRI with a Matrox Millenium G550 on a dual Opteron system. I guess this
is a pretty good test and I wonder if the problem has already been fixed
or if it was limited to specific hard- or software.
Tom
--
T h o m a s Z e h e t b a u e r ( TZ251 )
PGP encrypted mail preferred - KeyID 96FFCB89
finger [email protected] for key
Those, who are willing to give up essential liberty
for the sake of short-term security
deserve neither liberty nor security.
- Benjamin Franklin
Thomas Zehetbauer wrote:
> Hi again,
>
> I have now changed Kconfig and successfully compiled, loaded and used
> DRI with a Matrox Millenium G550 on a dual Opteron system. I guess this
> is a pretty good test and I wonder if the problem has already been fixed
> or if it was limited to specific hard- or software.
The problem, which exists with most (all?) DRM drivers, is that data
types are used in the kernel/user interface that have different sizes on
LP32 and LP64. If your kernel is 64-bit, you will have problems with
32-bit applications.
On Fre, 2004-10-29 at 12:47 -0700, Ian Romanick wrote:
> The problem, which exists with most (all?) DRM drivers, is that data
> types are used in the kernel/user interface that have different sizes on
> LP32 and LP64. If your kernel is 64-bit, you will have problems with
> 32-bit applications.
Then either all or no DRM drivers should be enabled on x86_64, the
DRM_TDFX, DRM_R128, DRM_RADEON and DRM_SIS are not currently disabled. I
vote for enabling all drivers that work with 64-bit applications.
I wonder if this should be the first and only place where different
kernel/userland bitness causes problems. How has this been solved
elsewhere?
Tom
--
T h o m a s Z e h e t b a u e r ( TZ251 )
PGP encrypted mail preferred - KeyID 96FFCB89
finger [email protected] for key
Chemists don't die, they just stop to react.
Thomas Zehetbauer <[email protected]> writes:
> On Fre, 2004-10-29 at 12:47 -0700, Ian Romanick wrote:
> > The problem, which exists with most (all?) DRM drivers, is that data
> > types are used in the kernel/user interface that have different sizes on
> > LP32 and LP64. If your kernel is 64-bit, you will have problems with
> > 32-bit applications.
That was not the reason I disabled it. I reenabled it now in my tree.
> Then either all or no DRM drivers should be enabled on x86_64, the
> DRM_TDFX, DRM_R128, DRM_RADEON and DRM_SIS are not currently disabled. I
> vote for enabling all drivers that work with 64-bit applications.
> I wonder if this should be the first and only place where different
> kernel/userland bitness causes problems. How has this been solved
> elsewhere?
It was solved long ago for the Radeon driver by Egbert Eich.
But for some unknown reason the DRI people never merged his patches.
-Andi
sorry missed the list....
---------- Forwarded message ----------
From: Dave Airlie <[email protected]>
Date: Sat, 30 Oct 2004 21:15:45 +1000
Subject: Re: status of DRM_MGA on x86_64
To: Andi Kleen <[email protected]>
>
> It was solved long ago for the Radeon driver by Egbert Eich.
> But for some unknown reason the DRI people never merged his patches.
Because no-one agreed that his solution was clean enough for use,
no-one contributed well described patches of the separate pieces to
drm or dri,
At the moment any solution to the 32/64-bit DRI will either break pure
64-bit systems or break 32/64-bit mixed systems, nobody has stepped
forward and said that either of these are acceptable, and no drm
developer has the hardware to work on it,
This 64-bit vs 32/64-bit stuff has been on my drm todo list for ages
but I've neither received clean patches or someone who has the test
environment to convince me that breaking one or other of the currently
working systems is acceptable... so we are currently in a state of
breaking backwards compat for 64-bit vs breaking backways compat for
32/64-bit.... I've no idea which one is acceptable, and I'm not going
to spend time developing a patch for one to have it refused because it
breaks compat with the other....
Someone needs to make the big decision, (IMHO only Linus or Andrew can
really make it as it's their kernels that will have the issues...)
Dave.
Dave Airlie <[email protected]> writes:
> sorry missed the list....
>
Ok my answers again.
> > It was solved long ago for the Radeon driver by Egbert Eich.
> > But for some unknown reason the DRI people never merged his patches.
>
> Because no-one agreed that his solution was clean enough for use,
> no-one contributed well described patches of the separate pieces to
> drm or dri,
>
> At the moment any solution to the 32/64-bit DRI will either break pure
> 64-bit systems or break 32/64-bit mixed systems, nobody has stepped
> forward and said that either of these are acceptable,
In short I think it doesn't make sense. There is enough existence
proof that you can write working 32bit emulation layers without
breaking any backwards compatibility. From my experiences with Egberts
patches there are also no compatibility problems.
You pay some cost for the conversion, but it tends to be not significant
(iirc from Egbert's results the non native case was not significantly
slower in ViewPerf)
Some people have attempted to design biarch ABIs in the past
for new interfaces, but more often than not they got it wrong in some
subtle detail and in the end you had to convert anyways.
> and no drm
> developer has the hardware to work on it,
Well, Egbert has and he wrote the code.
There is a working patch that you just need to apply, isn't there?
> This 64-bit vs 32/64-bit stuff has been on my drm todo list for ages
> but I've neither received clean patches or someone who has the test
> environment to convince me that breaking one or other of the currently
> working systems is acceptable...
Again you don't need to break anything. You just convert the ABI.
As a short layman's introduction on how Linux 32bit compatibility
works see http://www.firstfloor.org/~andi/writing-ioctl32
(some details are unfortunately outdated for 2.6, but you'll get
the high level view)
-Andi
Could you or someone else please explain the problem?
From rom what I have read it seems that userland acesses some bitness
dependent kernel structures. Fixing this would mean to use architecture
independent structures in both kernel- and userland and break existing
applications.
As a user I would be satisfied if DRI is available for 64-bit
applications on x86_64 and 32-bit applications do not cause the kernel
to crash.
Tom
PS: I have Fedora running on a dual Opteron system with a Matrox
Millenium G550, tell me if you want to test something.
--
T h o m a s Z e h e t b a u e r ( TZ251 )
PGP encrypted mail preferred - KeyID 96FFCB89
finger [email protected] for key
Attempting to apply the OSI layers model to a real network is just like
attempting to represent seven dimensions in four dimensional reality.
Andi Kleen writes:
> Thomas Zehetbauer <[email protected]> writes:
>
> > On Fre, 2004-10-29 at 12:47 -0700, Ian Romanick wrote:
> > > The problem, which exists with most (all?) DRM drivers, is that data
> > > types are used in the kernel/user interface that have different sizes on
> > > LP32 and LP64. If your kernel is 64-bit, you will have problems with
> > > 32-bit applications.
>
> That was not the reason I disabled it. I reenabled it now in my tree.
>
> > Then either all or no DRM drivers should be enabled on x86_64, the
> > DRM_TDFX, DRM_R128, DRM_RADEON and DRM_SIS are not currently disabled. I
> > vote for enabling all drivers that work with 64-bit applications.
>
> > I wonder if this should be the first and only place where different
> > kernel/userland bitness causes problems. How has this been solved
> > elsewhere?
>
> It was solved long ago for the Radeon driver by Egbert Eich.
> But for some unknown reason the DRI people never merged his patches.
>
I solved it for RADEON, MGA and R128.
It would be interesting to solve this for the i915 driver, too,
and possibly some others.
That it hasn't been merged into DRI yet is a shame. Appearantly
nobody has ever realized why this stuff is useful. Unfortunately
I don't have the time for lobbying it.
It's a very boring undertaking to have to port this from one DRI
version to the next.
Egbert.
>
> I solved it for RADEON, MGA and R128.
> It would be interesting to solve this for the i915 driver, too,
> and possibly some others.
>
> That it hasn't been merged into DRI yet is a shame. Appearantly
> nobody has ever realized why this stuff is useful. Unfortunately
> I don't have the time for lobbying it.
> It's a very boring undertaking to have to port this from one DRI
> version to the next.
Ian, can you look at this I think you are the best person (maybe
Keithw) to tell whether this stuff breaks compat in any direction,.
Egbert you may not want to lobby for it but all I personally want to
know is what it might potentially break in terms of backwards
compatiblity.... from SuSEs point of view as long as a distro is
consistent then you are okay, for us the whole keeping DRIs built
against older kernels working with newer kernels is the only real
issue...
Hopefully Ian can look at the patch and decide on it....
Dave.
Dave.
Dave Airlie writes:
>
> Ian, can you look at this I think you are the best person (maybe
> Keithw) to tell whether this stuff breaks compat in any direction,.
> Egbert you may not want to lobby for it but all I personally want to
> know is what it might potentially break in terms of backwards
> compatiblity.... from SuSEs point of view as long as a distro is
> consistent then you are okay, for us the whole keeping DRIs built
> against older kernels working with newer kernels is the only real
> issue...
Right. I know. I've looked into this.
I thought I had fixed the last remaining backward compatibility
between kernel and DRI (libraries and Xserver) by adding compatibility
ioctls.
I still plan to revisit this issue and see if I can modify the code
such that I don't need those compatibility ioctls.
>
> Hopefully Ian can look at the patch and decide on it....
>
OK. An earlier version is in the freedesktop CVS (#943). If you want
I make a port to the DRI head. Unfortunately I probably won't be able
to get at it for the next 2 - 3 weeks.
Egbert.