From: Markus T. <ma...@tr...> - 2005-01-17 20:52:28
|
Is it possible to run 32bit OpenGL applications on an AMD64 with DRI support? 64bit applications are working fine, but 32bit apps always use software rendering on my machine (Radeon 7500). It looks like an kernel issue. So my question is, if there are any kernel patches available to solve this problem? Thanks, Markus |
From: Alex D. <ale...@gm...> - 2005-01-18 00:32:14
|
On Mon, 17 Jan 2005 21:44:47 +0100, Markus T. <ma...@tr...> wrote: > Is it possible to run 32bit OpenGL applications on an AMD64 with DRI > support? 64bit applications are working fine, but 32bit apps always > use software rendering on my machine (Radeon 7500). > It looks like an kernel issue. So my question is, if there are any kernel > patches available to solve this problem? > > Thanks, > Markus > Egbert Eich wrote a thunking layer a while back. I think it may be included in the suse xorg builds, but it's still being discussed for inclusion in the upstream sources. Alex |
From: Dave A. <ai...@li...> - 2005-01-18 00:45:34
|
> Is it possible to run 32bit OpenGL applications on an AMD64 with DRI > support? 64bit applications are working fine, but 32bit apps always > use software rendering on my machine (Radeon 7500). > It looks like an kernel issue. So my question is, if there are any kernel > patches available to solve this problem? There is a patch but it doesn't provide full backwards compat .. it's bugzilla 943 on bugs.freedesktopp.org Egbert is hoping to look at it again, I keep getting hopelessly lost in types when I start looking at it.. I don't have the hardware to test it on... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person |
From: Alan H. <al...@fa...> - 2005-06-28 08:55:13
|
On Tue, Jan 18, 2005 at 12:45:23AM +0000, Dave Airlie wrote: > > > Is it possible to run 32bit OpenGL applications on an AMD64 with DRI > > support? 64bit applications are working fine, but 32bit apps always > > use software rendering on my machine (Radeon 7500). > > It looks like an kernel issue. So my question is, if there are any kernel > > patches available to solve this problem? > > There is a patch but it doesn't provide full backwards compat .. it's > bugzilla 943 on bugs.freedesktopp.org > > Egbert is hoping to look at it again, I keep getting hopelessly lost in > types when I start looking at it.. I don't have the hardware to test it > on... Egbert's patch has been updated and it's looking good. I'd suggest committing it to CVS now for more widespread testing. I'll commit it by the end of the week unless there are any arguments against it. Alan. |
From: Dave A. <ai...@li...> - 2005-06-28 12:16:17
|
> > bugzilla 943 on bugs.freedesktopp.org > > > > Egbert is hoping to look at it again, I keep getting hopelessly lost in > > types when I start looking at it.. I don't have the hardware to test it > > on... > > Egbert's patch has been updated and it's looking good. > > I'd suggest committing it to CVS now for more widespread testing. > > I'll commit it by the end of the week unless there are any arguments against > it. I've started pushing the kernel bits to the kernel from Paulus, Linus has accepted the drm ioc32 and radeon ioc32 stuff, I need to take the MGA and r128 and whatever other bits are in Egberts patch... The fixes to Mesa and Xorg should be taken, the main issue with Egberts patch is it is against Xorg CVS not against the individual components at last look... I'd rather this stuff was fixed in each component separately so finding backwards compatiblity issues will be easier... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG |
From: Alan H. <al...@fa...> - 2005-06-28 12:18:36
|
On Tue, Jun 28, 2005 at 01:16:14PM +0100, Dave Airlie wrote: > > > > bugzilla 943 on bugs.freedesktopp.org > > > > > > Egbert is hoping to look at it again, I keep getting hopelessly lost in > > > types when I start looking at it.. I don't have the hardware to test it > > > on... > > > > Egbert's patch has been updated and it's looking good. > > > > I'd suggest committing it to CVS now for more widespread testing. > > > > I'll commit it by the end of the week unless there are any arguments against > > it. > > > I've started pushing the kernel bits to the kernel from Paulus, Linus has > accepted the drm ioc32 and radeon ioc32 stuff, I need to take the MGA and > r128 and whatever other bits are in Egberts patch... If this stuff is in the kernel, hasn't it been committed to the DRM CVS ?? Alan. |
From: Dave A. <ai...@li...> - 2005-06-28 13:02:53
|
> > > > I've started pushing the kernel bits to the kernel from Paulus, Linus has > > accepted the drm ioc32 and radeon ioc32 stuff, I need to take the MGA and > > r128 and whatever other bits are in Egberts patch... > > If this stuff is in the kernel, hasn't it been committed to the DRM CVS ?? Mainly as I've only got two hands, and Paulus submitted it to the kernel first and it was easier to get into -mm and test it... it was a trivial push to get it into Linus's kernel.. also the kernel interfaces for this stuff has changed recently so I'm not sure about how to support older kernels via DRM CVS, so I'd rather punt on that and not support them... I've just committed untested the compat code to DRM CVS but I've no 64-bit system to even test it on... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG |
From: Alan H. <al...@fa...> - 2005-06-28 13:09:17
|
On Tue, Jun 28, 2005 at 02:02:39PM +0100, Dave Airlie wrote: > > > > > > > I've started pushing the kernel bits to the kernel from Paulus, Linus has > > > accepted the drm ioc32 and radeon ioc32 stuff, I need to take the MGA and > > > r128 and whatever other bits are in Egberts patch... > > > > If this stuff is in the kernel, hasn't it been committed to the DRM CVS ?? > > Mainly as I've only got two hands, and Paulus submitted it to the kernel > first and it was easier to get into -mm and test it... it was a trivial > push to get it into Linus's kernel.. also the kernel interfaces for this > stuff has changed recently so I'm not sure about how to support older > kernels via DRM CVS, so I'd rather punt on that and not support them... > > I've just committed untested the compat code to DRM CVS but I've no 64-bit > system to even test it on... Thanks for updating the CVS, and no problem on the 'two hands' thing either. I was just a little perplexed (as I'm sure Egbert was too) that the bug #943 hadn't been updated by Paul and all of a sudden it appears in the kernel first without being in the DRM CVS for at least a little while to get tested here. I guess we need to pull Paul's Mesa fixes into the Mesa CVS too now ?? Alan. |
From: Dave A. <ai...@li...> - 2005-06-28 13:20:53
|
> > I was just a little perplexed (as I'm sure Egbert was too) that the bug #943 > hadn't been updated by Paul and all of a sudden it appears in the kernel > first without being in the DRM CVS for at least a little while to get > tested here. Paul and Egbert discussed it on the bug at the time Paul was working on it .. I was happier with Pauls initial approach for the kernel, and Egberts first patch I also felt to be overly intrusive from the start, and uncaring of backwards compat, i.e. fine for SuSE distros but not for the kernel as we would break old Xs.... > > I guess we need to pull Paul's Mesa fixes into the Mesa CVS too now ?? Yes they probably do need to be applied alright, really Egberts patch need to take more care of what Paul was aiming for with compatibility... I didn't get enough time to full review his last patch, but I would prefer to see it split up into the drm/Mesa/Xorg pieces so each can be assessed by each team, the days of the drm being a part of Xorg are coming to an end... I was hoping the two of them would sort it out and supply me with a "final solution" as I've no access to any equipment using this stuff, and couldn't ever get anyone to review Egberts patch until Paul turned up with his own.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG |
From: Alan H. <al...@fa...> - 2005-06-28 13:41:20
|
On Tue, Jun 28, 2005 at 02:20:44PM +0100, Dave Airlie wrote: > > > > > I was just a little perplexed (as I'm sure Egbert was too) that the bug #943 > > hadn't been updated by Paul and all of a sudden it appears in the kernel > > first without being in the DRM CVS for at least a little while to get > > tested here. > > Paul and Egbert discussed it on the bug at the time Paul was working on it > .. I was happier with Pauls initial approach for the kernel, and Egberts > first patch I also felt to be overly intrusive from the start, and > uncaring of backwards compat, i.e. fine for SuSE distros but not for the > kernel as we would break old Xs.... I understand the backwards compatibility issues and that's good to have, but even Paul noted that when the chance arrives that the scheme should be changed to match more of what Egbert was trying to achieve. The libdri.a library has just been bumped to 5.0.0 in X.Org's snapshot 6.8.99.8, so now maybe a good time to adjust things a little more and bump libdrm.a to 2.0.0 as well. > > I guess we need to pull Paul's Mesa fixes into the Mesa CVS too now ?? > > Yes they probably do need to be applied alright, really Egberts patch need > to take more care of what Paul was aiming for with compatibility... I > didn't get enough time to full review his last patch, but I would prefer > to see it split up into the drm/Mesa/Xorg pieces so each can be assessed > by each team, the days of the drm being a part of Xorg are coming to an > end... To be honest, looking at the bug report, I'm not sure which patch should be applied to Mesa and/or X.Org in association with Paul's patch or Egberts. > I was hoping the two of them would sort it out and supply me with a "final > solution" as I've no access to any equipment using this stuff, and > couldn't ever get anyone to review Egberts patch until Paul turned up with > his own.. Indeed. Things seem to have slid a little here. I hope that Egbert and Paul can hash things out a little more. I've directly CC'ed them here for an update. Alan. |
From: Paul M. <pa...@sa...> - 2005-06-29 11:07:47
|
Alan Hourihane writes: > I understand the backwards compatibility issues and that's good to have, > but even Paul noted that when the chance arrives that the scheme should > be changed to match more of what Egbert was trying to achieve. I had been hoping for some more comments from the "senior" DRI hackers. Egbert's patch takes somewhat the opposite approach from mine; where I extended the RADEONDRIRec structure to have space for 64-bit handles, Egbert's patch unconditionally makes the drm_handle_t be 32-bit. Which is fine if the DRI developers generally agree that limiting handles to 32 bits is OK, but I don't think that discussion has been had yet. > To be honest, looking at the bug report, I'm not sure which patch should > be applied to Mesa and/or X.Org in association with Paul's patch or Egberts. The issue of what structures are used for communication between the X server and the DRI client is largely separate from the issue of communication between them and the kernel. The one thing that links them is the question of whether handles are always limited to 32 bits or not. > Indeed. Things seem to have slid a little here. I hope that Egbert and Paul > can hash things out a little more. I hope so too... Paul. |
From: Dave A. <ai...@li...> - 2005-06-29 11:31:20
|
> > I had been hoping for some more comments from the "senior" DRI hackers. > Egbert's patch takes somewhat the opposite approach from mine; where I > extended the RADEONDRIRec structure to have space for 64-bit handles, > Egbert's patch unconditionally makes the drm_handle_t be 32-bit. > Which is fine if the DRI developers generally agree that limiting > handles to 32 bits is OK, but I don't think that discussion has been > had yet. Yes a bit of interest from idr, alanh and keithw might help us out here... (and anyone else who knows this area).... > > server and the DRI client is largely separate from the issue of > communication between them and the kernel. The one thing that links > them is the question of whether handles are always limited to 32 bits > or not. Since my area is the DRM and to show why macros were to me not useful I've just checked mga and r128 ports of Egberts code to your framework into DRM CVS, I'd really appreciate someone compile testing them at least (my cross compiler setup is hosed, I'll fix it in the next day or two..), I'd also appreciate if someone could tell me if idr's new mga ioctls need compat code or not ... Now I've hacked that code together in little over two hours (while watching Raiders of the lost Ark) I don't see the advantage adding all the macros will bring, once you've identified which structs/ioctls need work, a quick editor macro can generate the code nearly... (granted I'm sure there are bugs in what I've just done...) I'm tempted to go finish all the drivers as soon as I figure out the exact reasons why a function needs a compat ioctl (I'm assuming any sign of an unsigned long is good enough), Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG |
From: Egbert E. <ei...@su...> - 2005-06-29 14:04:59
|
Dave Airlie writes: > > > > I had been hoping for some more comments from the "senior" DRI hackers. > > Egbert's patch takes somewhat the opposite approach from mine; where I > > extended the RADEONDRIRec structure to have space for 64-bit handles, > > Egbert's patch unconditionally makes the drm_handle_t be 32-bit. > > Which is fine if the DRI developers generally agree that limiting > > handles to 32 bits is OK, but I don't think that discussion has been > > had yet. > > Yes a bit of interest from idr, alanh and keithw might help us out here... > (and anyone else who knows this area).... > > > > > server and the DRI client is largely separate from the issue of > > communication between them and the kernel. The one thing that links > > them is the question of whether handles are always limited to 32 bits > > or not. > > Since my area is the DRM and to show why macros were to me not useful I've > just checked mga and r128 ports of Egberts code to your framework into DRM > CVS, I'd really appreciate someone compile testing them at least (my cross > compiler setup is hosed, I'll fix it in the next day or two..), I'd also > appreciate if someone could tell me if idr's new mga ioctls need compat > code or not ... The key should be to fix them so they don't as long as they are not yet released. Often times it is more a lack of knowledge than necessity that these conversions are needed. > > Now I've hacked that code together in little over two hours (while > watching Raiders of the lost Ark) I don't see the advantage adding all the > macros will bring, once you've identified which structs/ioctls need work, > a quick editor macro can generate the code nearly... (granted I'm sure > there are bugs in what I've just done...) Right. Those bugs have been removed from my code already. Egbert. |
From: Dave A. <ai...@li...> - 2005-06-29 23:04:23
|
> > Now I've hacked that code together in little over two hours (while > > watching Raiders of the lost Ark) I don't see the advantage adding all the > > macros will bring, once you've identified which structs/ioctls need work, > > a quick editor macro can generate the code nearly... (granted I'm sure > > there are bugs in what I've just done...) > > Right. Those bugs have been removed from my code already. I've no idea if you are deliberatly missing the point (we have a manager here who says if someone doesn't understand something then you aren't explaining it clearly enough, so maybe its my fault for not being clear) The macros are never going into the Linux kernel, I have the authority to say that, Paul has backed my opinion up (both of us have submitted code to the kernel for a while), I've reimplemented your code using Pauls template and using a cross-compiler made it build on my system, I believe it works exactly like your code just using the latest kernel methods for compatible ioctls, the macros will not help in the slightest the "maintenance" of the code, and this is the job that happens most often (and mostly by me...) not the writing which has been pointed out only happens once.... this was 3 hours work for me... I've asked AlanH to throw together an i915 implementation and with that we'll be set for most of the the hardware people will initially throw at it (mach64 and savage probably being the other two).... I appreciate the work you've put into the patch and we now have code in place that builds on both yours and Pauls work, and its going to be merged to the kernel so we should all be happy about this.. The issues remaining are: a) should we provide backwards compat stuff for users of old kernels in DRM CVS, without cluttering up the nice code.. b) what size to we make handles... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG |
From: Alan H. <al...@fa...> - 2005-06-30 23:06:56
|
On Thu, Jun 30, 2005 at 12:04:13AM +0100, Dave Airlie wrote: > The issues remaining are: > a) should we provide backwards compat stuff for users of old kernels in > DRM CVS, without cluttering up the nice code.. It'd be nice to do something. Using RedHat EL4 the DRM CVS fails to build because the .compat_ioctl doesn't exist in 2.6.9. Or, at the very least, we'll need to check if compat_ioctl exists before allowing compilation. Alan. |
From: Paul M. <pa...@sa...> - 2005-06-30 03:21:03
|
Egbert Eich writes: > > Now I've hacked that code together in little over two hours (while > > watching Raiders of the lost Ark) I don't see the advantage adding all the > > macros will bring, once you've identified which structs/ioctls need work, > > a quick editor macro can generate the code nearly... (granted I'm sure > > there are bugs in what I've just done...) > > Right. Those bugs have been removed from my code already. How do you know that, without having even seen Dave's code? Paul. |
From: Egbert E. <ei...@su...> - 2005-07-01 13:04:24
|
Alan Hourihane writes: > It'd be nice to do something. Using RedHat EL4 the DRM CVS fails to > build because the .compat_ioctl doesn't exist in 2.6.9. > > Or, at the very least, we'll need to check if compat_ioctl exists before > allowing compilation. Well, that may be the way to go. The code looks quite different and we need to clutter it with ifdefs since macros don't seem acceptable. Adding a set of separate functions for 2.4 can be left as an exercise to someone who needs it. Egbert. |
From: Egbert E. <ei...@su...> - 2005-06-28 13:53:42
|
Alan Hourihane writes: > On Tue, Jan 18, 2005 at 12:45:23AM +0000, Dave Airlie wrote: > > > > > Is it possible to run 32bit OpenGL applications on an AMD64 with DRI > > > support? 64bit applications are working fine, but 32bit apps always > > > use software rendering on my machine (Radeon 7500). > > > It looks like an kernel issue. So my question is, if there are any kernel > > > patches available to solve this problem? > > > > There is a patch but it doesn't provide full backwards compat .. it's > > bugzilla 943 on bugs.freedesktopp.org > > > > Egbert is hoping to look at it again, I keep getting hopelessly lost in > > types when I start looking at it.. I don't have the hardware to test it > > on... > > Egbert's patch has been updated and it's looking good. > > I'd suggest committing it to CVS now for more widespread testing. > > I'll commit it by the end of the week unless there are any arguments against > it. > Looks like that Dave Airlie has pushed another set of patches made by Paul Mackerras into the DRM code. My patches support a wider range of chipsets (Matrox, R128 and Radeon) and provide a framework which makes it easy to add ioctl32 support to more chipsets. Furthermore they have support for both the old style ioctl32 support and the one that uses compat_alloc_user_space() so they should work on a wider range of kernels. Egbert. |
From: Paul M. <pa...@sa...> - 2005-06-29 11:36:52
|
Egbert Eich writes: > My patches support a wider range of chipsets (Matrox, R128 and Radeon) > and provide a framework which makes it easy to add ioctl32 support > to more chipsets. Unfortunately your macros have the effect of increasing the effort required by a kernel developer to read and understand the code. In the kernel we care much more about code being easy to read than about it being easy to write. A kernel developer reading my code sees the function names that they know (access_ok, copy_to_user, etc.) and can see at a glance what the code is doing. > Furthermore they have support for both the old style ioctl32 support > and the one that uses compat_alloc_user_space() so they should work > on a wider range of kernels. The biggest problem, though, is that you are still using register_ioctl32_conversion, even for your "new" style support. That function is about to be removed. We need to supply a compat_ioctl function in the file_operations vector, which is what the code which is now upstream does. I would also like to discuss the treatment of handles a bit more. You have taken the approach of always hashing handles. I had concluded some time ago that that approach had problems because of the tendency of the DRI userspace to use physical addresses (of the framebuffer and card registers) as the offset in mmap calls (if I remember correctly, it was a while ago that I last looked at this stuff). I'm interested to know how your patch solves that problem. Also, does a kernel with your patch work with existing unmodified X servers and DRI clients? On x86_64 that would mean a 64-bit X server with 64-bit clients. Or do you require userspace to be updated if the kernel DRM is updated with your patch? Paul. |
From: Eric A. <et...@lc...> - 2005-06-29 21:27:28
|
On Wed, 2005-06-29 at 21:29 +1000, Paul Mackerras wrote: > Egbert Eich writes: > > > My patches support a wider range of chipsets (Matrox, R128 and Radeon) > > and provide a framework which makes it easy to add ioctl32 support > > to more chipsets. > > Unfortunately your macros have the effect of increasing the effort > required by a kernel developer to read and understand the code. In > the kernel we care much more about code being easy to read than about > it being easy to write. A kernel developer reading my code sees the > function names that they know (access_ok, copy_to_user, etc.) and can > see at a glance what the code is doing. > > > Furthermore they have support for both the old style ioctl32 support > > and the one that uses compat_alloc_user_space() so they should work > > on a wider range of kernels. > > The biggest problem, though, is that you are still using > register_ioctl32_conversion, even for your "new" style support. That > function is about to be removed. We need to supply a compat_ioctl > function in the file_operations vector, which is what the code which > is now upstream does. > > I would also like to discuss the treatment of handles a bit more. You > have taken the approach of always hashing handles. I had concluded > some time ago that that approach had problems because of the tendency > of the DRI userspace to use physical addresses (of the framebuffer and > card registers) as the offset in mmap calls (if I remember correctly, > it was a while ago that I last looked at this stuff). I'm interested > to know how your patch solves that problem. I've taken a look, and started writing down my understanding of handles and offsets here: http://dri.freedesktop.org/wiki/DrmMapHandling As far as I could tell, math was not being done on handles. This makes sense, since the DRM mmap handler is comparing whether the passed in offset is exactly equal to (not just in the range of) a map's offset/length. But I'm really concerned about the mixing of handles and offsets that I'm seeing, which I really can't reconcile with the code actually working. But if we could confirm that all DRI drivers were using handles to map from, then I think we've got a lot of freedom in deciding what type a handle is. If someone who's looked at this as well could read that page and correct anything I've misunderstood, that would be great. -- Eric Anholt et...@lc... http://people.freebsd.org/~anholt/ anholt@FreeBSD.org |
From: Egbert E. <ei...@su...> - 2005-06-30 08:23:59
|
Eric Anholt writes: > > I've taken a look, and started writing down my understanding of handles > and offsets here: > http://dri.freedesktop.org/wiki/DrmMapHandling Thanks for putting together this page! > > As far as I could tell, math was not being done on handles. This makes > sense, since the DRM mmap handler is comparing whether the passed in > offset is exactly equal to (not just in the range of) a map's > offset/length. But I'm really concerned about the mixing of handles and Right. However I came across one place where map handles were used as base address of a physical range. Then an offset was added. This had nothing to do with using handles in mmap(). The 'handles' seemed to be some multi purpose thing. Please take a look at https://bugs.freedesktop.org/attachment.cgi?id=2363 and the following change: diff -rNu ../unpatched/Mesa/src/mesa/drivers/dri/mga/mga_xmesa.c Mesa/src/mesa/drivers/dri/mga/mga_xmesa.c --- ../unpatched/Mesa/src/mesa/drivers/dri/mga/mga_xmesa.c 2004-12-16 01:23:47.000000000 +0100 +++ Mesa/src/mesa/drivers/dri/mga/mga_xmesa.c 2005-04-05 21:26:38.000000000 +0200 @@ -612,8 +612,7 @@ _tnl_allow_pixel_fog( ctx, GL_FALSE ); _tnl_allow_vertex_fog( ctx, GL_TRUE ); - mmesa->primary_offset = mmesa->mgaScreen->primary.handle; - + mmesa->primary_offset = drmAgpBase(sPriv->fd); ctx->DriverCtx = (void *) mmesa; mmesa->glCtx = ctx; If you look at mgaioctl.c you will find code that does arithmetic with mmesa->primary_offset. In my opinion the assignment: mmesa->primary_offset = mmesa->mgaScreen->primary.handle; is a bug. I've made sure that the kernel code still works even without my changes however there is the small but >0 possibility that it doesn't as this address might have been taken when when squeezing a 64bit address into 32 bit, in which case the HandleID() macro creates a different handle. One could argue that the physical address spaces are usually added before SHMs are so this chance never exists. > offsets that I'm seeing, which I really can't reconcile with the code > actually working. But if we could confirm that all DRI drivers were > using handles to map from, then I think we've got a lot of freedom in > deciding what type a handle is. Right. > > If someone who's looked at this as well could read that page and correct > anything I've misunderstood, that would be great. > Will do. Egbert. |
From: Alan H. <al...@fa...> - 2005-06-30 08:46:51
|
There's another issue here. And that's drmAddress in the 2D DDX drivers. On 32bit arches it's 32bits, on 64bit arches it's 64bit. And because drmAddress is passed in the *DRIRec things break. The client-side 3D driver gets the *DRIRec and as it's a different size things are a mess when using a 32bit client on a 64bit arch. It looks like the radeon and r128 don't suffer from this but most of the other drivers do. Alan. |
From: Alan H. <al...@fa...> - 2005-06-30 08:53:02
|
On Thu, Jun 30, 2005 at 09:46:41AM +0100, Alan Hourihane wrote: > There's another issue here. > > And that's drmAddress in the 2D DDX drivers. > > On 32bit arches it's 32bits, on 64bit arches it's 64bit. And because > drmAddress is passed in the *DRIRec things break. > > The client-side 3D driver gets the *DRIRec and as it's a different size > things are a mess when using a 32bit client on a 64bit arch. > > It looks like the radeon and r128 don't suffer from this but most of > the other drivers do. For i810 and i830 it can just be removed as it isn't even used. The other drivers just need a little tweaking to remove it's use. Alan. |
From: Egbert E. <ei...@su...> - 2005-06-30 13:24:00
|
Alan Hourihane writes: > On Thu, Jun 30, 2005 at 09:46:41AM +0100, Alan Hourihane wrote: > > For i810 and i830 it can just be removed as it isn't even used. The other > drivers just need a little tweaking to remove it's use. > How about casting it to drm_handle_t? Cheers, Egbert. |
From: Alan H. <al...@fa...> - 2005-06-30 13:42:13
|
On Thu, Jun 30, 2005 at 03:23:52 +0200, Egbert Eich wrote: > Alan Hourihane writes: > > On Thu, Jun 30, 2005 at 09:46:41AM +0100, Alan Hourihane wrote: > > > > For i810 and i830 it can just be removed as it isn't even used. The other > > drivers just need a little tweaking to remove it's use. > > > > How about casting it to drm_handle_t? I think we can just remove it in the other cases. I've just looked at the via and sis drivers and it doesn't make any real use of it. I'm sure the other drivers don't make any real use of it too. I think it's best to just remove it's use completely. Alan. |