r300 testing..
FYI I've had a chance today to test the r300 driver (using a Radeon 9550) with every 3d game and application I have installed. This includes UnrealTournament, ut2004, q3a, RTCW, Rune, Tribes2, Orbz, MarbleBlast (both from GarageGames), neverball, neverputt, NWN, doom3, blender, ppracer, and gltron. There were no lockups and very few rendering errors that I could see. Doom3 refused to launch, just stopping with: - R_InitOpenGL - Setup X display connection dlopen(libGL.so.1) Initializing OpenGL display Using XFree86-VidModeExtension Version 2.2 DGA DirectVideo Mouse (Version 2.0) initialized Free86-VidModeExtension Activated at 800x600 Performance wise, the driver seems to be on par with the r200 driver. Orbz and NWN are noticably slower. UT2004 is painfully slow, but I'm chalking that up to the S3TC fallback in the games renderer. Blender, which used to crash when opening up a couple files, seems to work flawlessly. This is on an SMP xeon system, with 1 gig of RAM, running 2.6.12.1 and Debian -unstable. Adam --- 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=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
OT: r300 - display corruption frglrx - radeon
Hi, For display corruption when switching from fglrx to radeon driver are responsible RADEON_SURFACEx_ register. One question: for what are these surfaces good ? Peter Zubaj --- 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=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3460] dri-20050601 [r200] americas army crash after start
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3460 --- Additional Comments From [EMAIL PROTECTED] 2005-06-26 14:29 --- Could you include a backtrace from running the app under gdb? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2516] some rasterization fallbacks cause segfaults
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2516 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-06-26 14:59 --- Patch committed to CVS. Thanks! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 testing..
Adam K Kirchhoff wrote: FYI I've had a chance today to test the r300 driver (using a Radeon 9550) with every 3d game and application I have installed. This includes UnrealTournament, ut2004, q3a, RTCW, Rune, Tribes2, Orbz, MarbleBlast (both from GarageGames), neverball, neverputt, NWN, doom3, blender, ppracer, and gltron. There were no lockups and very few rendering errors that I could see. Great to hear! Doom3 refused to launch, just stopping with: - R_InitOpenGL - Setup X display connection dlopen(libGL.so.1) Initializing OpenGL display Using XFree86-VidModeExtension Version 2.2 DGA DirectVideo Mouse (Version 2.0) initialized Free86-VidModeExtension Activated at 800x600 Is that the whole message? Doom3 stops for me with a message saying the required features weren't found. Re-enabling cube maps should allow Doom3 to start. Using the arb renderer, it almost looks correct with the exception of a few things. But it's very slow. The arb2 renderer will most likely look horribly wrong, and will eventually die in r300_fragprog.c due to unimplemented instructions. Mesa also doesn't seem to set fp_instruction-Opcode for the KIL instruction, so what you see with the arb2 renderer may vary from run to run. Performance wise, the driver seems to be on par with the r200 driver. Orbz and NWN are noticably slower. UT2004 is painfully slow, but I'm chalking that up to the S3TC fallback in the games renderer. Blender, which used to crash when opening up a couple files, seems to work flawlessly. I notice that the Blender tool panel doesn't randomly disappear now, which is good. S3TC does seem to be the killer for UT2004. I started porting over the S3TC stuff from the r200 driver a while back, but haven't had a lot of time recently to fix a couple of issues with it. Overall fps doesn't seem to take a huge gain, but the sudden drops to 1-2fps in certain levels (CTF-Faceclassic) disappear when S3TC's enabled. I have most of the remaining ARB_f_p support implemented locally, and some fixes for existing instructions. I needed to overhaul quite a bit of my original code because of some very bad assumptions, so it'll be a week or so before I have time to properly test the changes and commit to cvs. Cheers, Ben. This is on an SMP xeon system, with 1 gig of RAM, running 2.6.12.1 and Debian -unstable. Adam --- 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=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- 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=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] drm driver: merge upstream, security, etc
Hi all, I have fixed known issues with r300 DRM driver: * r300_emit_unchecked_state properly fallbacks to r300_emit_carefully_checked_state() when asked to set touchy registers (i.e. those with offsets). * r300_emit_raw properly checks LOAD_VBPNTR packet that all offsets are ok. * all of these copy user data exactly once. The next step is to discuss what else is needed for successful merge into the main DRM CVS. * What are the requirements for a patch to be accepted ? * Can R300 developers get CVS access ? * What else do we need in R300 DRM module ? (Besides working PCIE - Dave what are wishes in this regard ?) * any issues that I missed ? thank you ! Vladimir Dergachev --- 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=7477alloc_id=16492op=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 Sun, 2005-06-26 at 18:54 -0400, Vladimir Dergachev wrote: Hi all, I have fixed known issues with r300 DRM driver: * r300_emit_unchecked_state properly fallbacks to r300_emit_carefully_checked_state() when asked to set touchy registers (i.e. those with offsets). * r300_emit_raw properly checks LOAD_VBPNTR packet that all offsets are ok. * all of these copy user data exactly once. The next step is to discuss what else is needed for successful merge into the main DRM CVS. * What are the requirements for a patch to be accepted ? * Can R300 developers get CVS access ? * What else do we need in R300 DRM module ? (Besides working PCIE - Dave what are wishes in this regard ?) I was just looking at r300 code today for my own system. A few things that I think ought to happen for the merge: - Clean up style. Unindented blocks of code, weird whitespace (closing brackets on the same column as the block containing it, rather than the surrounding block), lack of wrapping at 80 columns, etc. - r300_emit_unchecked_state should get renamed (r300_check_and_emit_state?) and its all-caps warnings removed. Things I noticed that aren't top priority: - DRM_COPY_FROM_USER_UNCHECKED in r300_emit_cliprects should be a DRM_COPY_FROM_USER, I think. - Axe the comment about can't afford to let userspace control something that locks up the graphics card so easily in R300_CMD_END3D handling. There are too many ways to hang a graphics card with DRI for us to try to stop the user from doing so. - r300_reg_flags should probably be in the dev_priv rather than a global. And something I've wondered about for a while: - Is the __user annotation supposed to mean this is a value from userland that should be checked for use or this is a pointer to somewhere in userland that needs to be copy_from_usered before use? For CVS access, please get the r300 developers to submit their ssh v2 public key, preferred username, email address, and full name to fd.o bugzilla under sitewranglers, noting that they should get access to mesa and dri. When that starts happening, I'll be sure to poke daniels about getting the accounts made. For the client driver code, I'm thinking it would be a good idea to repocopy it over (thus maintaining CVS history). If you agree with this, whenever its time to do that merge we should have a 1-day rest so that sf.net will make a clean tarball of the current cvsroot, which the sf.net project admin (you) could grab and hand off to me to put the bits in the right place in Mesa CVS. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [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_id=7477alloc_id=16492op=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 6/26/05, Eric Anholt [EMAIL PROTECTED] wrote: I was just looking at r300 code today for my own system. A few things that I think ought to happen for the merge: - Clean up style. Unindented blocks of code, weird whitespace (closing brackets on the same column as the block containing it, rather than the surrounding block), lack of wrapping at 80 columns, etc. - r300_emit_unchecked_state should get renamed (r300_check_and_emit_state?) and its all-caps warnings removed. The code in DRM CVS has been run through the kernel 'scripts/Lindent' program. There has been recent discussion on lkml about changing the script from 80 char lines to something more modern like 120. I'd definitely vote for 120. You will need to do some manual touch up after Lindent. It will mess up formatting of C99 initializers and some constant blocks. The r300 client code is added into the r200 driver, right? Not a third library like radeon/r200/r300. -- 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_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: OT: r300 - display corruption frglrx - radeon
Peter Zubaj wrote: Hi, For display corruption when switching from fglrx to radeon driver are responsible RADEON_SURFACEx_ register. One question: for what are these surfaces good ? For tiling, if you read/write directly to the graphic card memory. Should be no issue with xorg cvs however, as these registers get cleaned up on all radeon cards at xorg startup since tiling support was added. 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=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 testing..
Ben Skeggs wrote: S3TC does seem to be the killer for UT2004. I started porting over the S3TC stuff from the r200 driver a while back, but haven't had a lot of time recently to fix a couple of issues with it. Overall fps doesn't seem to take a huge gain, but the sudden drops to 1-2fps in certain levels (CTF-Faceclassic) disappear when S3TC's enabled. That's true, but to avoid the huge drops you could also just decrease texture detail. Or implement the second texture heap in main memory and use gart texturing (though you'd also need to manually increase the gart size). There are some problems with that for r200, and the strategy for what textures to put where may not be optimal currently, but the drops should be gone. That said, the performance in ut2k4 is probably really slow (apart from that problem) due to deficiencies in drawArrays handling, at least that was the case for r200 last time I checked... 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=7477alloc_id=16492op=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 Sun, 2005-06-26 at 19:53 -0400, Jon Smirl wrote: On 6/26/05, Eric Anholt [EMAIL PROTECTED] wrote: I was just looking at r300 code today for my own system. A few things that I think ought to happen for the merge: - Clean up style. Unindented blocks of code, weird whitespace (closing brackets on the same column as the block containing it, rather than the surrounding block), lack of wrapping at 80 columns, etc. - r300_emit_unchecked_state should get renamed (r300_check_and_emit_state?) and its all-caps warnings removed. The code in DRM CVS has been run through the kernel 'scripts/Lindent' program. There has been recent discussion on lkml about changing the script from 80 char lines to something more modern like 120. I'd definitely vote for 120. You will need to do some manual touch up after Lindent. It will mess up formatting of C99 initializers and some constant blocks. Please, 80 is standard. The r300 client code is added into the r200 driver, right? Not a third library like radeon/r200/r300. It started from a copy of the r200 driver, but as far as I know the r200 support is totally broken in it, so it would go into an r300 directory. From the last time a merge was attempted between two radeon drivers, the actual amount of shared code was small. I suspect there would be even less shared between the new one and previous drivers. It shouldn't stop merging in the future if we can show that it's a win, but I wouldn't want to wait on getting the r200 bits working again to bring the new driver in. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [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_id=7477alloc_id=16492op=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 6/26/05, Eric Anholt [EMAIL PROTECTED] wrote: The code in DRM CVS has been run through the kernel 'scripts/Lindent' program. There has been recent discussion on lkml about changing the script from 80 char lines to something more modern like 120. I'd definitely vote for 120. You will need to do some manual touch up after Lindent. It will mess up formatting of C99 initializers and some constant blocks. Please, 80 is standard. I'm sorry, I forgot that you do your development on an EGA adapter. -- 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_idt77alloc_id492op=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 Llu, 2005-06-27 at 01:02, Eric Anholt wrote: definitely vote for 120. You will need to do some manual touch up after Lindent. It will mess up formatting of C99 initializers and some constant blocks. Please, 80 is standard. Not for most code I've looked at. 80 generates horrible formatting like printf( hello, x, y+5); all the time. Disagree also about axing the comment - its useful to know why something is being done. --- 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=7477alloc_id=16492op=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 Mon, 2005-06-27 at 01:19 +0100, Alan Cox wrote: On Llu, 2005-06-27 at 01:02, Eric Anholt wrote: definitely vote for 120. You will need to do some manual touch up after Lindent. It will mess up formatting of C99 initializers and some constant blocks. Please, 80 is standard. Not for most code I've looked at. 80 generates horrible formatting like printf( hello, x, y+5); all the time. Are you saying this: if ((offset=dev_priv-fb_location) (offsetdev_priv-gart_vm_start)) return 0; is more readable than: if ((offset = dev_priv-fb_location) (offset dev_priv-gart_vm_start)) return 0; I also like being able to stick two windows side by side for comparing code, where diff isn't really appropriate. At 120 columns, that doesn't fit, even on my 1600x1200 screen. I'm not going to put my foot down on this one, though it would leave us with code quite contradictory to the style of kernel code in two of the projects that the DRM runs on. But I see a lot in here that would be improved by 80-column wrapping (comments starting at the 40th column, for example) and little that would be harmed (a few things that hang just beyond 80 columns, breaking up some strings into multiple lines). I typically use my editor at about 95 columns, to handle code that doesn't wrap (and it's often understandable), but this code seems egregious. 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). I don't see how this comment would stay as-is. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [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_id=7477alloc_id=16492op=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 6/26/05, Eric Anholt [EMAIL PROTECTED] wrote:
Are you saying this:
if ((offset=dev_priv-fb_location)
(offsetdev_priv-gart_vm_start)) return 0;
is more readable than:
if ((offset = dev_priv-fb_location)
(offset dev_priv-gart_vm_start))
return 0;
Lindent would do this even with the wrap set at 80 columns.
if ((offset=dev_priv-fb_location) (offsetdev_priv-gart_vm_start))
return 0;
This is from the DRM code formatted with an 80 column limit. Lindent
will let strings exceed 80 columns. To me it look like 13 lines of
code turned into 28.
/* If permanent maps are implemented, maps must match */
if (dev-driver-permanent_maps) {
DRM_DEBUG
(Looking for: offset = 0x%08lx, size =
0x%08lx, type = %d\n,
map-offset, map-size, map-type);
list_for_each(_list, dev-maplist-head) {
drm_map_list_t *_entry =
list_entry(_list, drm_map_list_t,
head);
DRM_DEBUG
(Checking: offset = 0x%08lx, size
= 0x%08lx, type = %d\n,
_entry-map-offset,
_entry-map-size,
_entry-map-type);
if (_entry-map
map-type == _entry-map-type
map-offset ==
_entry-map-offset) {
_entry-map-size = map-size;
drm_free(map, sizeof(*map),
DRM_MEM_MAPS);
map = _entry-map;
DRM_DEBUG
(Found existing: offset =
0x%08lx, size = 0x%08lx, type = %d\n,
map-offset, map-size,
map-type);
goto found_it;
}
}
--
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_idt77alloc_id492op=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 Sun, 2005-06-26 at 21:25 -0400, Jon Smirl wrote: On 6/26/05, Eric Anholt [EMAIL PROTECTED] wrote: Are you saying this: if ((offset=dev_priv-fb_location) (offsetdev_priv-gart_vm_start)) return 0; is more readable than: if ((offset = dev_priv-fb_location) (offset dev_priv-gart_vm_start)) return 0; Lindent would do this even with the wrap set at 80 columns. if ((offset=dev_priv-fb_location) (offsetdev_priv-gart_vm_start)) return 0; This is from the DRM code formatted with an 80 column limit. Lindent will let strings exceed 80 columns. To me it look like 13 lines of code turned into 28. Heh. One of the suggestions of BSD style is that when 80 columns becomes too little, you probably need another function. In the diff I'm currently testing for cleaning up map handling (which net removes 200 lines), I've removed that if statement that didn't need to exist (afaict), and split the find-the-map bits into another function. I think it's quite improved. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [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_id=7477alloc_id=16492op=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 Sunday 26 June 2005 21:51, Eric Anholt wrote: Heh. One of the suggestions of BSD style is that when 80 columns becomes too little, you probably need another function. In the diff I'm currently testing for cleaning up map handling (which net removes 200 lines), I've removed that if statement that didn't need to exist (afaict), and split the find-the-map bits into another function. I think it's quite improved. Likewise, from linux/Documentation/CodingStyle: # Now, some people will claim that having 8-character indentations makes # the code move too far to the right, and makes it hard to read on a # 80-character terminal screen. The answer to that is that if you need # more than 3 levels of indentation, you're screwed anyway, and should fix # your program. # # In short, 8-char indents make things easier to read, and have the added # benefit of warning you when you're nesting your functions too deep. # Heed that warning. I've got more horizontal screen space than jesus, and I still can't fit two 120-column terminals side by side on the same monitor. I'm casting my vote for staying with 80 columns. - ajax pgpb8CniCqXbl.pgp Description: PGP signature
Re: [R300] drm driver: merge upstream, security, etc
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. -- 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_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM mappings cleanup
Attached is a patch to clean up setup and teardown of maps in Linux. I
did it because in the process of making BSD compile again, I kept
finding things that needed to be cleaned up and were making it harder to
get BSD working again, and it was too much doing both OSes at once. I'd
like to get it committed very soon so I can get BSD DRM CVS compiling
again. The changes in this patch:
- Remove drm_initmap and replace its usage with drm_addmap. This is
nicer in savage because we don't have to go back and find the map again
-- I suspect this would be the case in most drivers that used it.
- Remove the permanent maps flag. Instead, for register and framebuffer
maps, we always check whether there's already a map of that type and
offset around.
- Remove the split cleanup of maps between driver takedown (last close)
and cleanup (module unload). Instead, always tear down maps on
takedown, and drivers can recreate them on first open.
- Make MGA always use addmap, instead of allocating consistent memory in
the PCI case and then faking up a map for it, which accomplished nearly
the same thing, in a different order. Note that the maps are exposed to
the user again: we may want to expose a flag to avoid this, but it's not
a security concern, and saves us a lot of code.
- Remove rmmaps in the MGA driver. Since the function is only called
during takedown anyway, we can let them die a natural death.
- Make removal of maps happen in one function, which is called by both
drm_takedown and drm_rmmap_ioctl.
Places to go from here:
- Remove the hack of setting up dmahs on the stack in order to
drm_pci_free, by storing the real dmah in the drm_local_map_t.
- Remove the rmmap ioctl calls from the X Server (I think this would be
safe: a number of the rmmaps are for framebuffer/registers, which never
get rmmapped anyways, and takedown should clean up the rest. I don't
think you would be able to successfully start DRI again anyway if
someone's still holding the device open).
This was tested by starting/glxgears/stopping on mga, savage, and
radeon. In the MGA case it was with and without old-dma, and also with
ForcePCIDMA.
The diff is about +190, -390 lines. Anyone want to review it first,
since I have a tendency to under-test on linux?
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
Index: linux-core/drmP.h
===
RCS file: /cvs/dri/drm/linux-core/drmP.h,v
retrieving revision 1.149
diff -u -r1.149 drmP.h
--- linux-core/drmP.h 17 Jun 2005 09:09:17 - 1.149
+++ linux-core/drmP.h 27 Jun 2005 02:55:54 -
@@ -571,7 +571,6 @@
/* variables */
u32 driver_features;
int dev_priv_size;
- int permanent_maps;
drm_ioctl_desc_t *ioctls;
int num_ioctls;
struct file_operations fops;
@@ -863,15 +862,13 @@
extern int drm_addbufs_fb (drm_device_t * dev, drm_buf_desc_t * request);
extern int drm_addmap(drm_device_t * dev, unsigned int offset,
unsigned int size, drm_map_type_t type,
- drm_map_flags_t flags, drm_map_t ** map_ptr);
+ drm_map_flags_t flags, drm_local_map_t ** map_ptr);
extern int drm_addmap_ioctl(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
-extern int drm_rmmap(drm_device_t *dev, void *handle);
+extern int drm_rmmap(drm_device_t *dev, drm_local_map_t *map);
+extern int drm_rmmap_locked(drm_device_t *dev, drm_local_map_t *map);
extern int drm_rmmap_ioctl(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
-extern int drm_initmap(drm_device_t * dev, unsigned int offset,
- unsigned int size, unsigned int resource, int type,
- int flags);
extern int drm_addbufs(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
extern int drm_infobufs(struct inode *inode, struct file *filp,
Index: linux-core/drm_bufs.c
===
RCS file: /cvs/dri/drm/linux-core/drm_bufs.c,v
retrieving revision 1.59
diff -u -r1.59 drm_bufs.c
--- linux-core/drm_bufs.c 14 Jun 2005 22:34:10 - 1.59
+++ linux-core/drm_bufs.c 27 Jun 2005 03:03:55 -
@@ -48,66 +48,21 @@
}
EXPORT_SYMBOL(drm_get_resource_len);
- /**
- * Adjusts the memory offset to its absolute value according to the mapping
- * type. Adds the map to the map list drm_device::maplist. Adds MTRR's where
- * applicable and if supported by the kernel.
- */
-int drm_initmap(drm_device_t * dev, unsigned int offset, unsigned int size,
- unsigned int resource, int type, int flags)
+static drm_local_map_t *drm_find_matching_map(drm_device_t *dev,
+ drm_local_map_t *map)
{
- drm_map_t *map;
- drm_map_list_t *list;
-
- DRM_DEBUG(\n);
-
- if ((offset (~PAGE_MASK)) || (size (~PAGE_MASK)))
- return -EINVAL;
-#if !defined(__sparc__) !defined(__alpha__)
- if (offset + size offset || offset virt_to_phys(high_memory))
Re: [R300] drm driver: merge upstream, security, etc
I was just looking at r300 code today for my own system. A few things that I think ought to happen for the merge: - Clean up style. Unindented blocks of code, weird whitespace (closing brackets on the same column as the block containing it, rather than the surrounding block), lack of wrapping at 80 columns, etc. - r300_emit_unchecked_state should get renamed (r300_check_and_emit_state?) and its all-caps warnings removed. What about r300_emit_packet0 instead of r300_emit_unchecked_state and r300_emit_packet3 instead of r300_emit_raw ? Cause that's what they do. Things I noticed that aren't top priority: - DRM_COPY_FROM_USER_UNCHECKED in r300_emit_cliprects should be a DRM_COPY_FROM_USER, I think. Hmm.. I have no idea either - could anyone else comment ? - Axe the comment about can't afford to let userspace control something that locks up the graphics card so easily in R300_CMD_END3D handling. There are too many ways to hang a graphics card with DRI for us to try to stop the user from doing so. Well, nothing wrong for setting goals too high, at least there is something to look up to ;) - r300_reg_flags should probably be in the dev_priv rather than a global. It is for all practical purposes a static array - identical for each r300 device. No reason to waste memory if someone has two cards. And something I've wondered about for a while: - Is the __user annotation supposed to mean this is a value from userland that should be checked for use or this is a pointer to somewhere in userland that needs to be copy_from_usered before use? No idea, someone else should comment on this.. For the client driver code, I'm thinking it would be a good idea to repocopy it over (thus maintaining CVS history). If you agree with this, whenever its time to do that merge we should have a 1-day rest so that sf.net will make a clean tarball of the current cvsroot, which the sf.net project admin (you) could grab and hand off to me to put the bits in the right place in Mesa CVS. Great, thank you ! Vladimir Dergachev -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [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_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- 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=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
