Re: DRM map design
I've attached my current diffs to DRM. I am coverting DRM so that the
server does not have to run as root. The attached code allows this.
Most of the changes are in AddMap.
1) sarea is prebuilt
2) agp maps are allowed from non-root master but checked to make sure
they are within allocated agp space.
3) I haven't done PCI maps yet they will look like the AGP ones.
I will probaby get rid of the changes where I added an extra parameter
to the IOCTL macros before check in.
>From user space I use loops like this:
for (i = 0;; i++) {
if (drmGetMap(disp->drmFD, i, &offset, &size, &type, &flags,
&handle, &mtrr) != 0)
break;
if (type == DRM_SHM) {
if (drmMap( disp->drmFD, offset, size,
(drmAddressPtr)(&disp->pSAREA)) < 0) {
fprintf(stderr, "[drm] drmMap failed\n");
return 0;
}
break;
}
}
if (!disp->pSAREA)
return 0;
drmMap never cares about the handle since drmMap turns into mmap and
mmap doesn't know about DRM maps.
--
Jon Smirl
[EMAIL PROTECTED]
patch
Description: Binary data
Re: DRM map design
Jon Smirl writes: > Don't the maps always contain the physical address of the object? That > would provide a unique handle. No, for _DRM_SHM and _DRM_SCATTER_GATHER maps the offset is a kernel virtual address (at least at present). It's only by luck that we don't see collisions. Also, using a physical address is not suitable in the long term if we want 32-bit handles, since physical addresses may well be above 4GB in future, though for now most systems that we care about seem to put their AGP and PCI devices at physical addresses below 4GB. > Where does the handle get used in user space? After I GetMap() to find > the map I need, I pass the offset back into drmMap() not the handle. > Offset is the physical address in most cases. There is a confusing inconsistency between drm_addmap and drm_getmap here. drm_addmap has code at the end to return the kernel's map->offset value in the userspace map->handle field, but drm_getmap doesn't do that. So yes, using the map->offset returned by drmGetMap is correct, at least at present. That's unfortunate, though, because if we go to 32-bit handles, we'd really want drm_getmap to return the handle in *handle rather than *offset, which would mean that it would be the handle value that you would have to pass to mmap, rather than the offset value. It seems that nothing in X or DRI currently uses drmGetMap except for test/dristat.c, which only prints the offset and handle, so presumably your stuff would be the only thing that broke if we changed this. :) Paul. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] r300 driver locks up with Xglx
Nicolai Haehnle wrote: According to lspci, it's an "ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]" That chip is actually known to work fine. Have you tried to run ordinary OpenGL applications within the normal X.Org server (e.g. Glean, TuxRacer, Cube, ...)? Are you seeing lockups there, too? Yes, in fact, mostly it does work fine, and has done so for a while now: - glxgears works, though it only gives me 500 fps (on a Pentium M 1400 - I should get at least 1000 or 1500, right?) - The xscreensaver GL hacks work fine, apart from some display problems on some of them (e.g. mirrorblob) and slowness in uploading textures - Quake3 is a little bit slow but works fine. If the lockups happen only with Xglx, this could well be an Xglx-specific software issue. In this case, you should try enabling the DRM debugging options (modprobe drm debug=1) and have a look into the dmesg/syslog/wherever kernel messages end up on your system to see what happens around the the time of lockup. Also, you should obviously make sure that all your components are recent (X.Org CVS, r300 CVS, Mesa CVS). Ok. I'll see if I can get the messages then. I don't think the machine locks up completely. If it's a bug on our (i.e. the driver's) side, we should fix it, whether or not Xglx itself is in a usable state. It's likely that Xglx hits code paths that aren't used by most programs. That's what I thought as well. Cheers, Lorenzo --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] r300 driver locks up with Xglx
On 7/1/05, Nicolai Haehnle <[EMAIL PROTECTED]> wrote: > If it's a bug on our (i.e. the driver's) side, we should fix it, whether or > not Xglx itself is in a usable state. It's likely that Xglx hits code paths > that aren't used by most programs. Xglx is working pretty well. I'd suggest using it as a test case for your r300 work. It exercises a large number of OpenGL features some of which are not comonly used. It is also a good thing to compare to since it works without problems on the ATI drivers. http://www.freedesktop.org/wiki/Software_2fXgl -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
On Fri, 2005-07-01 at 03:24 +0300, Aapo Tahkola wrote: > On Sun, 26 Jun 2005 23:48:11 -0400 > Michel Dänzer <[EMAIL PROTECTED]> wrote: > > > On Sun, 2005-06-26 at 18:05 -0700, Eric Anholt wrote: > > > On Mon, 2005-06-27 at 01:19 +0100, Alan Cox wrote: > > > > > > > Disagree also about axing the comment - its useful to know why something > > > > is being done. > > > > > > Wait, the comment says "TODO: Remove this; we can't afford to let > > > userspace control something that locks up the graphics card so easily." > > > We're not removing the code being referred to, as far as I've heard, and > > > "we can't afford" is contradictory to what we have agreed on for DRI > > > policy (drivers can't escalate privelege, but can hang the machine). > > > > When did this 'agreement' occur? I can't remember agreeing to that. That > > we may not be able to prevent all such cases doesn't mean we shouldn't > > prevent the ones we can. > > Without VPU recovery, it is very likely that the prices would be too high > to stand. I really mean 'the ones we can'. All I'm saying is that we should try to prevent it whenever reasonably possible and that the fact that it may not always be is IMHO a bad excuse for never trying. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] r300 driver locks up with Xglx
On Friday 01 July 2005 16:31, Lorenzo Colitti wrote: > Peter Zubaj wrote: > > Some of r300 driver lockups are card dependant (and for now I have > > only these card dependand lockups). Cards which will lock (soon or > > later) are 9500 Pro (maybe 9500 too), 9700, 9800. What card do you have ? > > According to lspci, it's an "ATI Technologies Inc RV350 [Mobility Radeon > 9600 M10]" That chip is actually known to work fine. Have you tried to run ordinary OpenGL applications within the normal X.Org server (e.g. Glean, TuxRacer, Cube, ...)? Are you seeing lockups there, too? If the lockups happen only with Xglx, this could well be an Xglx-specific software issue. In this case, you should try enabling the DRM debugging options (modprobe drm debug=1) and have a look into the dmesg/syslog/wherever kernel messages end up on your system to see what happens around the the time of lockup. Also, you should obviously make sure that all your components are recent (X.Org CVS, r300 CVS, Mesa CVS). > > Try to load fglrx 2d driver first, then uload it and then use r300 driver. > > I don't use fglrx, both because it's closed source and because I don't > want to litter my system with a lot of files I don't know about. Would > installing it help to debug the problem or is it just a workaround? If It's a workaround only. fglrx seems to perform some initializations that we're missing, but so far this workaround seems to be relevant to plain R300 hardware anyway (i.e. *not* RV350). > it's only a workaround, I can simply not try to use Xglx: it doesn't > work anyway... If it's a bug on our (i.e. the driver's) side, we should fix it, whether or not Xglx itself is in a usable state. It's likely that Xglx hits code paths that aren't used by most programs. cu, Nicolai pgp9Gq5dz7KJK.pgp Description: PGP signature
Re: DRM map design
Don't the maps always contain the physical address of the object? That would provide a unique handle. Where does the handle get used in user space? After I GetMap() to find the map I need, I pass the offset back into drmMap() not the handle. Offset is the physical address in most cases. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] r300 driver locks up with Xglx
Peter Zubaj wrote: Some of r300 driver lockups are card dependant (and for now I have only these card dependand lockups). Cards which will lock (soon or later) are 9500 Pro (maybe 9500 too), 9700, 9800. What card do you have ? According to lspci, it's an "ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]" Try to load fglrx 2d driver first, then uload it and then use r300 driver. I don't use fglrx, both because it's closed source and because I don't want to litter my system with a lot of files I don't know about. Would installing it help to debug the problem or is it just a workaround? If it's only a workaround, I can simply not try to use Xglx: it doesn't work anyway... Cheers, Lorenzo --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 on amd64
Ian Romanick writes: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Egbert Eich wrote: > > > @@ -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. > > It is, and in more ways that this. That is why, for MGA DRM >= 3.2, > this code is no longer used. The only use of the primary handle was to > determine when the DMA engine had processed certain command buffers. > This case has been replaced by an in-kernel interrupt-based wait > mechanism. In the current code, primary_offset is always set to zero if > DRM >= 3.2. OK, that sounds reasonable. Would the change I've made would still be useful for DRM < 3.2? Cheers, Egbert. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM map design
Paul Mackerras writes: > Keith Whitwell writes: > > > In general I'd prefer that the values passed to clients (and back again) > > to be abstract tokens rather than actual addresses or offsets into some > > unspecified address space. > > > > Which should mean that 32 bits is more than ample to contain them... > > The problem that we have is that currently the kernel DRM uses the > map->offset field for two different things: (a) as a token for > userspace to use to identify a particular map and (b) to store > map-type-specific information such as the physical address for > _DRM_REGISTERS and _DRM_FRAME_BUFFER maps, or the address within the > GART aperture for _DRM_AGP maps, or the kernel virtual address within > a scatter/gather mapping for _DRM_SCATTER_GATHER maps. For _DRM_SHM > maps, map->offset is set to the kernel virtual address of the memory > allocated for the map, but that is only used as a token, not for > internal use inside the DRM. > > In fact it is only by luck that we don't get collisions between the > physical addresses used for _DRM_REGISTERS and _DRM_FRAME_BUFFER maps > and the kernel virtual addresses used for _DRM_SHM maps at the moment. > > My patch took the approach of only creating abstract tokens for > _DRM_SHM maps, which meant that I didn't need to disentangle (a) and > (b). If we are going to create abstract tokens for all maps, we need > to do something different. > > One alternative is to add another field to the kernel's (i.e. the > DRM's) version of the drm_map_t, in which to store the userspace > token. This is the approach taken by Egbert's patch. The current > version of Egbert's patch has the kernel version of the drm_map_t > called the same but different from the userspace drm_map_t. I would > prefer that the kernel structure be called something different if its > contents are different, but that will admittedly make the patch pretty > intrusive. That's fine. This can be done, it will just make the patch bigger, which should be less of a concern than future confusion. > > Another alternative is to have a separate data structure to translate > userspace tokens to drm_map_t pointers. The "idr" structure in the > kernel (include/linux/idr.h) is commonly used for this sort of thing. > With this approach, we would allocate map handles as small multiples > of PAGE_SIZE, and use idr_find(&dev->map_idr, handle >> PAGE_SHIFT) to > map from userspace tokens to drm_map_t *'s. I believe we don't ever > need to go from drm_map_t * to the userspace token. I'll try to code > this up over the weekend so that we can see how intrusive it is likely > to be. The advantage is of course that it means we don't have to have > different drm_map_t's in the kernel and userspace. > Well, both approaches are fine. The disadvantage of the second apporach however is that we have no control over the token value. Therefore we cannot take the gentle approach to make the attempt to leave values that fit into 32bit unchanged. This would definitely change the kernel ABI and may have side effects for some exisiting drivers - especially binary only drivers. Egbert. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 on amd64
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. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM map design
Paul Mackerras wrote: Keith Whitwell writes: In general I'd prefer that the values passed to clients (and back again) to be abstract tokens rather than actual addresses or offsets into some unspecified address space. Which should mean that 32 bits is more than ample to contain them... The problem that we have is that currently the kernel DRM uses the map->offset field for two different things: (a) as a token for userspace to use to identify a particular map and (b) to store map-type-specific information such as the physical address for _DRM_REGISTERS and _DRM_FRAME_BUFFER maps, or the address within the GART aperture for _DRM_AGP maps, or the kernel virtual address within a scatter/gather mapping for _DRM_SCATTER_GATHER maps. For _DRM_SHM maps, map->offset is set to the kernel virtual address of the memory allocated for the map, but that is only used as a token, not for internal use inside the DRM. In fact it is only by luck that we don't get collisions between the physical addresses used for _DRM_REGISTERS and _DRM_FRAME_BUFFER maps and the kernel virtual addresses used for _DRM_SHM maps at the moment. My patch took the approach of only creating abstract tokens for _DRM_SHM maps, which meant that I didn't need to disentangle (a) and (b). If we are going to create abstract tokens for all maps, we need to do something different. One alternative is to add another field to the kernel's (i.e. the DRM's) version of the drm_map_t, in which to store the userspace token. This is the approach taken by Egbert's patch. The current version of Egbert's patch has the kernel version of the drm_map_t called the same but different from the userspace drm_map_t. I would prefer that the kernel structure be called something different if its contents are different, but that will admittedly make the patch pretty intrusive. Another alternative is to have a separate data structure to translate userspace tokens to drm_map_t pointers. The "idr" structure in the kernel (include/linux/idr.h) is commonly used for this sort of thing. With this approach, we would allocate map handles as small multiples of PAGE_SIZE, and use idr_find(&dev->map_idr, handle >> PAGE_SHIFT) to map from userspace tokens to drm_map_t *'s. I believe we don't ever need to go from drm_map_t * to the userspace token. I'll try to code this up over the weekend so that we can see how intrusive it is likely to be. The advantage is of course that it means we don't have to have different drm_map_t's in the kernel and userspace. Sounds good Paul. I think it's worthwhile to at least investigate this as it'd be a cleaner result all round at the end. Keith --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM map design
Keith Whitwell writes: > In general I'd prefer that the values passed to clients (and back again) > to be abstract tokens rather than actual addresses or offsets into some > unspecified address space. > > Which should mean that 32 bits is more than ample to contain them... The problem that we have is that currently the kernel DRM uses the map->offset field for two different things: (a) as a token for userspace to use to identify a particular map and (b) to store map-type-specific information such as the physical address for _DRM_REGISTERS and _DRM_FRAME_BUFFER maps, or the address within the GART aperture for _DRM_AGP maps, or the kernel virtual address within a scatter/gather mapping for _DRM_SCATTER_GATHER maps. For _DRM_SHM maps, map->offset is set to the kernel virtual address of the memory allocated for the map, but that is only used as a token, not for internal use inside the DRM. In fact it is only by luck that we don't get collisions between the physical addresses used for _DRM_REGISTERS and _DRM_FRAME_BUFFER maps and the kernel virtual addresses used for _DRM_SHM maps at the moment. My patch took the approach of only creating abstract tokens for _DRM_SHM maps, which meant that I didn't need to disentangle (a) and (b). If we are going to create abstract tokens for all maps, we need to do something different. One alternative is to add another field to the kernel's (i.e. the DRM's) version of the drm_map_t, in which to store the userspace token. This is the approach taken by Egbert's patch. The current version of Egbert's patch has the kernel version of the drm_map_t called the same but different from the userspace drm_map_t. I would prefer that the kernel structure be called something different if its contents are different, but that will admittedly make the patch pretty intrusive. Another alternative is to have a separate data structure to translate userspace tokens to drm_map_t pointers. The "idr" structure in the kernel (include/linux/idr.h) is commonly used for this sort of thing. With this approach, we would allocate map handles as small multiples of PAGE_SIZE, and use idr_find(&dev->map_idr, handle >> PAGE_SHIFT) to map from userspace tokens to drm_map_t *'s. I believe we don't ever need to go from drm_map_t * to the userspace token. I'll try to code this up over the weekend so that we can see how intrusive it is likely to be. The advantage is of course that it means we don't have to have different drm_map_t's in the kernel and userspace. Paul. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GLX 1.3 support?
Aric Cyr wrote: I had originally posted this on the xorg-devel mailing list, but didn't get much response, so thought I'd try my luck here... I was just wondering if there was any progress or planned work to update the server's GLX implementation to 1.3.? It looks like about half of the work is already done, since the GLX_SGIX_fbconfig extension is already implemented, as is glX*Pixmap. The only things I can see missing (based on current Xorg CVS) is glX*Drawable() functions and PBuffer related stuff. The only thing I can think of is that the PBuffer stuff might be difficult to implement with the current memory manager. If there is some technical (or legal?) reason for not having this implemented yet, I'd be interested in learning it. I'd be willing to start working on implementing this myself. If anyone has any recommendations on how to proceed, I am open for suggestions, including any necessary pre-requisite work. I'm no expert on this, but IIRC there are no legal reasons for not implementing it. You are correct that the difficulties are in implementing pbuffers, as there is no current memory manager... There could be more issues I can't remember right now, there was some discussion on the list some time ago. Roland --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
