Re: r300 on Thinkpad r50p (RV350)
On Wed, 29 Jun 2005 22:07:35 -0400
Alex Deucher <[EMAIL PROTECTED]> wrote:
> On 6/29/05, Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> > Hamish Marson wrote:
> > > Fixed it.
> > >
> > > Sorry. It isn't an r300 problem... Or at least doesn't LOOK like an
> > > r300 problem. I changed the xorg.conf & set
> > >
> > > Option "EnablePageFlip" "on" # []
> > >
> > > to
> > >
> > > Option "EnablePageFlip" "off" # []
> > >
> > >
> > > and the flickering went away...
> >
> > PageFlip should work usually on radeons (there can be issues when you
> > use it together with tiling, see
> > https://bugs.freedesktop.org/show_bug.cgi?id=2604), but since the r300
> > driver doesn't support tiling yet...
> > Though I don't know if pageflip is actually supposed to work on r300
> > based cards currently, I don't think there should be differences to the
> > other radeons in that area.
> >
>
> I just added tiling support for r3/4xx cards to xorg cvs.
Nice!
Couple fixes to get depth reads/writes working with 16 and 32 bit depth buffers:
diff -uNr ati/radeon_driver.c ati..s/radeon_driver.c
--- ati/radeon_driver.c Thu Jun 30 05:51:54 2005
+++ ati..s/radeon_driver.c Thu Jun 30 06:06:49 2005
@@ -6110,8 +6110,13 @@
depth_pattern = RADEON_SURF_TILE_DEPTH_16BPP;
else
depth_pattern = RADEON_SURF_TILE_DEPTH_32BPP;
-}
-else {
+} else if (IS_R300_VARIANT){
+ color_pattern = R300_SURF_TILE_COLOR_MACRO;
+ if (cpp == 2)
+ depth_pattern = R300_SURF_TILE_COLOR_MACRO;
+ else
+ depth_pattern = R300_SURF_TILE_COLOR_MACRO |
R300_SURF_TILE_DEPTH_32BPP;
+} else {
/* no idea about R300, just set it up the same as r200
if someone is crazy enough to try... */
color_pattern = R200_SURF_TILE_COLOR_MACRO;
@@ -6175,7 +6180,12 @@
drmRadeonSurfaceAlloc drmsurfalloc;
drmsurfalloc.size = bufferSize;
drmsurfalloc.address = info->depthOffset;
- drmsurfalloc.flags = swap_pattern | (width_bytes / 16) |
depth_pattern;
+
+ if (IS_R300_VARIANT)
+ drmsurfalloc.flags = swap_pattern | (width_bytes / 8) |
depth_pattern;
+ else
+ drmsurfalloc.flags = swap_pattern | (width_bytes / 16) |
depth_pattern;
+
retvalue = drmCommandWrite(info->drmFD, DRM_RADEON_SURF_ALLOC,
&drmsurfalloc, sizeof(drmsurfalloc));
if (retvalue < 0)
diff -uNr ati/radeon_reg.h ati..s/radeon_reg.h
--- ati/radeon_reg.hThu Jun 30 05:51:53 2005
+++ ati..s/radeon_reg.h Thu Jun 30 06:06:53 2005
@@ -1314,6 +1314,9 @@
# define R200_SURF_TILE_COLOR_BOTH(3 << 16)
# define R200_SURF_TILE_DEPTH_32BPP (4 << 16)
# define R200_SURF_TILE_DEPTH_16BPP (5 << 16)
+# define R300_SURF_TILE_NONE (0 << 16)
+# define R300_SURF_TILE_COLOR_MACRO (1 << 16)
+# define R300_SURF_TILE_DEPTH_32BPP (2 << 16)
# define RADEON_SURF_AP0_SWP_16BPP(1 << 20)
# define RADEON_SURF_AP0_SWP_32BPP(1 << 21)
# define RADEON_SURF_AP1_SWP_16BPP(1 << 22)
Please note that I havent tested this with current xorg cvs because of various
inconveniences.
What about the 2560 limit?
I noticed that with the new RADEONDoAdjustFrame I can have 1280x1024-1280x1024
setup if I remove the limits.
> Pageflipping won't work for r300 until the sarea and drm are updated
> to handle the additional xytiling regs.
I fixed couple of things with it and it should now work.
Its not very stable at least with tiling enabled(havent tested without) though
im afraid.
--
Aapo Tahkola
---
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
Egbert Eich writes: > ... and reinvented the weel repeating the same errors that I have > already been thru. What errors do you refer to? 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: ioctl32 on amd64
Egbert Eich writes: > That's fine. If somone tells me what needs to be done > I'm happy to change this. > I've been carrying this code along for too long now. > When I started this this kind of conversion functions > didn't exist. Is there anything wrong with the code that is currently in the kernel, other than the fact that you didn't write it? > > 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? > > Haven't I mentined that it does? Handles that fit into 32bit > should be handed to userspace unchanged, therefore if there is any > code left that does arithmetic with these handles should continue > to work. Handles that are used as real bases should be 32bit as > these usually are pointer to base addresses. There is still a potential problem with your approach - if we are going to create hashed 32-bit handles for 32-bit processes to use, we have to create the hashed handles even if the addmap is being done by a 64-bit process. The reason is that the X server passes handles to DRI clients. If you have a 64-bit X server which does an addmap and gets a 64-bit handle (which doesn't fit into 32 bits) and that handle is then passed to a 32-bit client, the client won't be able to use it because the 32-bit hashed version of the handle hasn't been created. 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: ioctl32 on amd64
Egbert Eich writes: > Maybe you should have gotten in touch with me and we could have > worked out something. I posted to dri-devel on 21 February 2005 mentioning my concerns with your patch. Surely you're on dri-devel if you're working on this stuff? 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: ioctl32 on amd64
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. --- 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 on Thinkpad r50p (RV350)
On 6/29/05, Roland Scheidegger <[EMAIL PROTECTED]> wrote: > Hamish Marson wrote: > > Fixed it. > > > > Sorry. It isn't an r300 problem... Or at least doesn't LOOK like an > > r300 problem. I changed the xorg.conf & set > > > > Option "EnablePageFlip" "on" # [] > > > > to > > > > Option "EnablePageFlip" "off" # [] > > > > > > and the flickering went away... > > PageFlip should work usually on radeons (there can be issues when you > use it together with tiling, see > https://bugs.freedesktop.org/show_bug.cgi?id=2604), but since the r300 > driver doesn't support tiling yet... > Though I don't know if pageflip is actually supposed to work on r300 > based cards currently, I don't think there should be differences to the > other radeons in that area. > I just added tiling support for r3/4xx cards to xorg cvs. Pageflipping won't work for r300 until the sarea and drm are updated to handle the additional xytiling regs. Alex > 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_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 on Thinkpad r50p (RV350)
Hamish Marson wrote: Fixed it. Sorry. It isn't an r300 problem... Or at least doesn't LOOK like an r300 problem. I changed the xorg.conf & set Option "EnablePageFlip" "on" # [] to Option "EnablePageFlip" "off" # [] and the flickering went away... PageFlip should work usually on radeons (there can be issues when you use it together with tiling, see https://bugs.freedesktop.org/show_bug.cgi?id=2604), but since the r300 driver doesn't support tiling yet... Though I don't know if pageflip is actually supposed to work on r300 based cards currently, I don't think there should be differences to the other radeons in that area. 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
Re: ioctl32 on amd64
> > Yes a bit of interest from idr, alanh and keithw might help us out here... > > (and anyone else who knows this area) > > Yes, sorry about this. As it stands I don't have a particularly good > understanding of the issues and will have to spend a bit of time getting up to > speed before I can provide any sort of useful input. Well the main issue is the handle size things, this is the biggest difference between the two approaches... one of Paul's previous mails in this threaed describes the exact issue.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- 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
> > 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 --- 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 on Thinkpad r50p (RV350)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex Deucher wrote: > On 6/29/05, Hamish Marson <[EMAIL PROTECTED]> wrote: > > Alex Deucher wrote: > >> On 6/29/03, Rune Petersen <[EMAIL PROTECTED]> wrote: > >>> Hamish Marson wrote: > -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hamish Marson wrote: > Just as a status report... > > On my thinkpad r50p which has an rv350 (FireGL-T2) when > using the current CVS xorg, CVS Mesa and the tagged r300 > driver 'the_perfect_frag') it all works, 1600fps on > glxgears, but the flickering is awful on OpenGL apps... > Fixed it. Sorry. It isn't an r300 problem... Or at least doesn't LOOK like an r300 problem. I changed the xorg.conf & set Option "EnablePageFlip" "on" # [] to Option "EnablePageFlip" "off" # [] and the flickering went away... H -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCwySb/3QXwQQkZYwRAqNBAJ0UoONE4YOSmuSS2nCSYI+c97FnjwCcC1wy QpIvUXHbOLF/e0UAZ2PNn94= =wpOw -END PGP SIGNATURE- --- 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 on Thinkpad r50p (RV350)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Deucher wrote:
> On 6/29/05, Hamish Marson <[EMAIL PROTECTED]> wrote:
>
> Alex Deucher wrote:
>
>> On 6/29/03, Rune Petersen <[EMAIL PROTECTED]> wrote:
>
>>> Hamish Marson wrote:
>
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
Hamish Marson wrote:
> Just as a status report...
>
> On my thinkpad r50p which has an rv350 (FireGL-T2) when
> using the current CVS xorg, CVS Mesa and the tagged r300
> driver 'the_perfect_frag') it all works, 1600fps on
> glxgears, but the flickering is awful on OpenGL apps...
>
> (Current CVS is yesterday for xorg, today for Mesa).
>
> glxgears - works OK. But flickers. tuxracer - works OK.
> Reasonable frame rates. But flickers at about 10Hz. gl-117
> - Same. Reasonable frame rates. But flickers.
>
> glxgears was in a window. tuxracer and gl-117 were
> full-screen. I had to stop before I threw up...
>
> Suspend & Resume worked OK so far (Only suspended to RAM
> once though).
>
> Hamish.
FWIW the same things also happens on the current CVS copy.
This is with a 1600x1200 resolution LCD as well, just in case
it matters. gl-117 seems to geta round 60fps in the init
screens... But I can't see the screen well enough to navigate
through (Or access even) any setup screens to try & change
anything in it.
H
>>> Flickering should be resolved by adding this to radeon_driver.c
>>> in the Xorg: @@ -5631,6 +5627,11 @@ if (!info->IsSecondary)
>>> RADEONChangeSurfaces(pScrn);
>
>>> + if (info->ChipFamily >= CHIP_FAMILY_R300) { + unsigned char
>>> *RADEONMMIO = info->MMIO; + OUTREG(0x180, INREG(0x180) |
>>> 0x1100); + } + if(info->MergedFB) { /* need this here to fix up
>>> sarea values */ RADEONAdjustFrameMerged(scrnIndex,
>>> pScrn->frameX0, pScrn->frameY0, 0);
>
>
>>> Rune Petersen
>
>> According to the databooks, this is the correct behavior for high
>> res modes. What it does is bump the display0/1 priorities in the
>> memory controller. I'll be committing a slighly updated version
>> of this patch to cvs in the next few days.
>
> If anything, this patch made my display flicker even worse than
> without it. Frame rates seem slightly lower, but glxgears gets
> around 1450-1500fps at only about 50% CPU (vs 1500-1600fps and 100%
> CPU utilisation without the patch).
>
>
>> the flickering may be GL related. if you are using one head, try
>> this line instead: OUTREG(0x180, INREG(0x180) | 0x0100);
Nope.
Maybe it's not that..
With glxgears I get horizontal black bands across the window (Only the
glxgears window. The rest of the display is fine). These jitter around
up & down. (Actually looking very closely at the window, they MIGHT be
horizontal bands of a darker share of the gear colours. A bit hard to
tell if it's that or black bands at high speed... It's 1500fps after all).
With tuxracer, I get a pretty good background in the practice, with
the mountains in the background. Nice & steady. The mid ground (ice
patches & trees) also look good, but over this, all the foreground
stuff, like tux himself, the speedo etc are constantly overlaid by
horizontal blue areas of what looks like no drawing... I'm not sure of
the background gets the same treatment... it's hard to see, but it
looks like they just get horizontal bands of lightblue transparency or
opacity...
In the menus the background is light blue, the foreground is overlaid
with the flickering blue horizontal bands.
I was thinking sync issue maybe... (i.e. screen update not in sync
with the screen refresh rate of 60Hz).
>> that will only up the priority on display0.
>
> This is at 24bpp. Because @ 32bpp in xorg.conf, X doesn't start
> (Unsupported bit depth is the error).
>
>
>> depth 24 is 32bpp internally to the driver. there is no depth
>> 32.
>
That's what I thought.
> I also tried 1024x768 resolution. Same thing. (In fact tuxracer
> runs at a lower res I think. Hard to tell, I have the default
> screen expansion turned on for the LCD. Must turn it off).
>
> Alex. Are the databooks still a dire secret? Or can you share (If
> softcopy). Or can ordinary mortals get hold of them?
>
>
>> Sorry NDAs.
>
Ah well... I guess the world would fail if ATI let us all know how to
program their hardware. Good thing AMD & Intel don't think the same
about their CPU's...
(Sorry. Can't resist that).
H
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCwyJm/3QXwQQkZYwRAjg1AJ4uNxZpbxfDNFR1cqyiVDDFu2QOvwCfdnLi
zwX6is6Uc+pU9B+IvhJeDu8=
=li2R
-END PGP SIGNATURE-
---
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:/
Re: ioctl32 on amd64
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 [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=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Bug in i810 agp support?
On Wed, 2005-06-29 at 13:36 -0400, Jon Smirl wrote: > On 6/29/05, Keith Whitwell <[EMAIL PROTECTED]> wrote: > > Jon Smirl wrote: > > > In i810/server/i810_dri.c there is a call to agp alloc without the > > > type set to zero: > > > drmAgpAlloc(ctx->drmFD, 4096 * 1024, 1, NULL, &dcacheHandle); > > > > > > A type of one translates into U16_APER_SIZE which doesn't match the > > > request size of 4MB. > > > > > > Is this a bug or do I not understand the type parameter on agp alloc? > > > This is the only place where a type other than zero is used. > > > > > > > The i810 had an optional bank of dedicated video ram, the "dcache", > > which was useful for certain tasks despite having lower bandwidth than > > regular shared/system ram. This memory required special handling - I > > would say the type parameter would have been added for this case in > > particular. > > > > Note that this is not the same as the i810's "stolen" ram which is > > allocated off the top of regular memory at boot time by the bios. > > If I am reading the code right the type ends up straight in the > kernel's agp_allocate_memory(pages, type); Then looking at the kernel > code the type goes into the chip agp driver and then comes back out > later. I can't find any documentation on what 'type' does. > > I don't have any reason to think it's not working, it was just odd > that it was the only non-zero use in the system. Type 0 is normal. Type of 1 specifies that it's dcache. Type of 2 specifies cursor memory. The AGP driver respects the type and allocates from the appropriate place. -- 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=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 on Thinkpad r50p (RV350)
On 6/29/05, Hamish Marson <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Alex Deucher wrote:
>
> > On 6/29/03, Rune Petersen <[EMAIL PROTECTED]> wrote:
> >
> >> Hamish Marson wrote:
> >>
> >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> >>>
> >>> Hamish Marson wrote:
> >>>
> >>>
> Just as a status report...
>
> On my thinkpad r50p which has an rv350 (FireGL-T2) when using
> the current CVS xorg, CVS Mesa and the tagged r300 driver
> 'the_perfect_frag') it all works, 1600fps on glxgears, but
> the flickering is awful on OpenGL apps...
>
> (Current CVS is yesterday for xorg, today for Mesa).
>
> glxgears - works OK. But flickers. tuxracer - works OK.
> Reasonable frame rates. But flickers at about 10Hz. gl-117 -
> Same. Reasonable frame rates. But flickers.
>
> glxgears was in a window. tuxracer and gl-117 were
> full-screen. I had to stop before I threw up...
>
> Suspend & Resume worked OK so far (Only suspended to RAM once
> though).
>
> Hamish.
> >>>
> >>>
> >>> FWIW the same things also happens on the current CVS copy.
> >>>
> >>> This is with a 1600x1200 resolution LCD as well, just in case
> >>> it matters. gl-117 seems to geta round 60fps in the init
> >>> screens... But I can't see the screen well enough to navigate
> >>> through (Or access even) any setup screens to try & change
> >>> anything in it.
> >>>
> >>> H
> >>>
> >> Flickering should be resolved by adding this to radeon_driver.c
> >> in the Xorg: @@ -5631,6 +5627,11 @@ if (!info->IsSecondary)
> >> RADEONChangeSurfaces(pScrn);
> >>
> >> + if (info->ChipFamily >= CHIP_FAMILY_R300) { + unsigned
> >> char *RADEONMMIO = info->MMIO; + OUTREG(0x180, INREG(0x180)
> >> | 0x1100); + } + if(info->MergedFB) { /* need this here to fix
> >> up sarea values */ RADEONAdjustFrameMerged(scrnIndex,
> >> pScrn->frameX0, pScrn->frameY0, 0);
> >>
> >>
> >> Rune Petersen
> >>
> >
> > According to the databooks, this is the correct behavior for high
> > res modes. What it does is bump the display0/1 priorities in the
> > memory controller. I'll be committing a slighly updated version of
> > this patch to cvs in the next few days.
> >
>
> If anything, this patch made my display flicker even worse than
> without it. Frame rates seem slightly lower, but glxgears gets around
> 1450-1500fps at only about 50% CPU (vs 1500-1600fps and 100% CPU
> utilisation without the patch).
the flickering may be GL related. if you are using one head, try this
line instead:
OUTREG(0x180, INREG(0x180) | 0x0100);
that will only up the priority on display0.
>
> This is at 24bpp. Because @ 32bpp in xorg.conf, X doesn't start
> (Unsupported bit depth is the error).
depth 24 is 32bpp internally to the driver. there is no depth 32.
>
> I also tried 1024x768 resolution. Same thing. (In fact tuxracer runs
> at a lower res I think. Hard to tell, I have the default screen
> expansion turned on for the LCD. Must turn it off).
>
> Alex. Are the databooks still a dire secret? Or can you share (If
> softcopy). Or can ordinary mortals get hold of them?
>
Sorry NDAs.
Alex
> regards
> Hamish.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.0 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFCwrIC/3QXwQQkZYwRAqa4AKDVEjopQ1xhMcP/mBtBz4Ya7hAjmwCfbEeD
> CrVJq23sNyMApn2J65JDx/c=
> =ajyG
> -END PGP SIGNATURE-
>
>
---
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 on Thinkpad r50p (RV350)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Deucher wrote:
> On 6/29/03, Rune Petersen <[EMAIL PROTECTED]> wrote:
>
>> Hamish Marson wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>>
>>> Hamish Marson wrote:
>>>
>>>
Just as a status report...
On my thinkpad r50p which has an rv350 (FireGL-T2) when using
the current CVS xorg, CVS Mesa and the tagged r300 driver
'the_perfect_frag') it all works, 1600fps on glxgears, but
the flickering is awful on OpenGL apps...
(Current CVS is yesterday for xorg, today for Mesa).
glxgears - works OK. But flickers. tuxracer - works OK.
Reasonable frame rates. But flickers at about 10Hz. gl-117 -
Same. Reasonable frame rates. But flickers.
glxgears was in a window. tuxracer and gl-117 were
full-screen. I had to stop before I threw up...
Suspend & Resume worked OK so far (Only suspended to RAM once
though).
Hamish.
>>>
>>>
>>> FWIW the same things also happens on the current CVS copy.
>>>
>>> This is with a 1600x1200 resolution LCD as well, just in case
>>> it matters. gl-117 seems to geta round 60fps in the init
>>> screens... But I can't see the screen well enough to navigate
>>> through (Or access even) any setup screens to try & change
>>> anything in it.
>>>
>>> H
>>>
>> Flickering should be resolved by adding this to radeon_driver.c
>> in the Xorg: @@ -5631,6 +5627,11 @@ if (!info->IsSecondary)
>> RADEONChangeSurfaces(pScrn);
>>
>> + if (info->ChipFamily >= CHIP_FAMILY_R300) { + unsigned
>> char *RADEONMMIO = info->MMIO; + OUTREG(0x180, INREG(0x180)
>> | 0x1100); + } + if(info->MergedFB) { /* need this here to fix
>> up sarea values */ RADEONAdjustFrameMerged(scrnIndex,
>> pScrn->frameX0, pScrn->frameY0, 0);
>>
>>
>> Rune Petersen
>>
>
> According to the databooks, this is the correct behavior for high
> res modes. What it does is bump the display0/1 priorities in the
> memory controller. I'll be committing a slighly updated version of
> this patch to cvs in the next few days.
>
If anything, this patch made my display flicker even worse than
without it. Frame rates seem slightly lower, but glxgears gets around
1450-1500fps at only about 50% CPU (vs 1500-1600fps and 100% CPU
utilisation without the patch).
This is at 24bpp. Because @ 32bpp in xorg.conf, X doesn't start
(Unsupported bit depth is the error).
I also tried 1024x768 resolution. Same thing. (In fact tuxracer runs
at a lower res I think. Hard to tell, I have the default screen
expansion turned on for the LCD. Must turn it off).
Alex. Are the databooks still a dire secret? Or can you share (If
softcopy). Or can ordinary mortals get hold of them?
regards
Hamish.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCwrIC/3QXwQQkZYwRAqa4AKDVEjopQ1xhMcP/mBtBz4Ya7hAjmwCfbEeD
CrVJq23sNyMApn2J65JDx/c=
=ajyG
-END PGP SIGNATURE-
---
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 on Thinkpad r50p (RV350)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vladimir Dergachev wrote: > > > On Wed, 29 Jun 2005, Hamish Marson wrote: > > Hamish Marson wrote: > Just as a status report... On my thinkpad r50p which has an rv350 (FireGL-T2) when using the current CVS xorg, CVS Mesa and the tagged r300 driver 'the_perfect_frag') it all works, 1600fps on glxgears, but the flickering is awful on OpenGL apps... > > >> What is your screen depth - 32bpp or 16bpp ? > Hi. Sorry. default depth is set to 24 (WHich from memory is the smae setting as fglrx when I had it). If I set it to 32 then X won't start, saying 32 is an unsupported depth. I haven't tried 16. regards Hamish. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCwlm2/3QXwQQkZYwRAgHjAJ9mWgmuYHalI0jUXINI9e7feXJ6LgCcD1tG B4KbfpvuZ8GFKBCBKeX5/5Y= =Juy8 -END PGP SIGNATURE- --- 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: Bug in i810 agp support?
On 6/29/05, Keith Whitwell <[EMAIL PROTECTED]> wrote: > Jon Smirl wrote: > > In i810/server/i810_dri.c there is a call to agp alloc without the > > type set to zero: > > drmAgpAlloc(ctx->drmFD, 4096 * 1024, 1, NULL, &dcacheHandle); > > > > A type of one translates into U16_APER_SIZE which doesn't match the > > request size of 4MB. > > > > Is this a bug or do I not understand the type parameter on agp alloc? > > This is the only place where a type other than zero is used. > > > > The i810 had an optional bank of dedicated video ram, the "dcache", > which was useful for certain tasks despite having lower bandwidth than > regular shared/system ram. This memory required special handling - I > would say the type parameter would have been added for this case in > particular. > > Note that this is not the same as the i810's "stolen" ram which is > allocated off the top of regular memory at boot time by the bios. If I am reading the code right the type ends up straight in the kernel's agp_allocate_memory(pages, type); Then looking at the kernel code the type goes into the chip agp driver and then comes back out later. I can't find any documentation on what 'type' does. I don't have any reason to think it's not working, it was just odd that it was the only non-zero use in the system. -- 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: Bug in i810 agp support?
Jon Smirl wrote: In i810/server/i810_dri.c there is a call to agp alloc without the type set to zero: drmAgpAlloc(ctx->drmFD, 4096 * 1024, 1, NULL, &dcacheHandle); A type of one translates into U16_APER_SIZE which doesn't match the request size of 4MB. Is this a bug or do I not understand the type parameter on agp alloc? This is the only place where a type other than zero is used. The i810 had an optional bank of dedicated video ram, the "dcache", which was useful for certain tasks despite having lower bandwidth than regular shared/system ram. This memory required special handling - I would say the type parameter would have been added for this case in particular. Note that this is not the same as the i810's "stolen" ram which is allocated off the top of regular memory at boot time by the bios. 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
Bug in i810 agp support?
In i810/server/i810_dri.c there is a call to agp alloc without the type set to zero: drmAgpAlloc(ctx->drmFD, 4096 * 1024, 1, NULL, &dcacheHandle); A type of one translates into U16_APER_SIZE which doesn't match the request size of 4MB. Is this a bug or do I not understand the type parameter on agp alloc? This is the only place where a type other than zero is used. -- 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: DRM map design
On 6/29/05, Jon Smirl <[EMAIL PROTECTED]> wrote: > drmAgpAlloc() allocs drm_agp_mem structures which track the agp > allocs. I could change the map system to allow a single map to be > paired with each struct drm_agp_mem. > > The 2MB restricted you are using was allocated with a call to > drmAgpAlloc(), right? You would then add a _RESTRICTED map which would > bind to the struct drm_agp_mem and stop further maps. We need to a > check to make sure a normal user can't free and reallocate a piece of > AGP memory marked restricted. > > The drivers would then be changed to alloc the various parts of AGP > space instead of allocing one big chunk and carving it up. By allocing > multiple pieces the master can set different privs on each piece. > > Backwards compatibility is maintained since root can make any maps > that it wants ignoring the one map per struct drm_agp_mem restriction. A better scheme to do this might be to leave drmAddMap alone and create a new DRM entry point drmAgpAllocMap(). drmAddMap() would continue to be root only. drmAgpAllocMap() is derived from drmAgpAlloc() but also builds a map entry spanning the agp space allocated. It takes an additional parameter for the appropriate DRM_MAP flags. drmAgpAllocMap() would be marked master-only, not root-only. I believe this would be a better approach than changing drmAddMap to allow some maps to be added without root priv and others still needing it. drmAgpAllocMap() already has all of the info it needs, it is easy for it to make the map too. -- 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: New to DRI and how to set up a debugging environment..
On 6/29/05, Prashanth Hegde <[EMAIL PROTECTED]> wrote: > Hi all, > I am new to linux. I am intesrested in developing > drivers for graphics cards. Hopefully I've not misread your email. As far as I know, the 'radeon' driver should support 2D well enough, but you'll need the (still-beta?) driver from r300.sf.net if you want some opensource DRI support on the Radeon 9600 PRO. HTH. -Andy --- 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: DRM map design
On 6/29/05, Paul Mackerras <[EMAIL PROTECTED]> wrote: > Do either of you (or does anyone) have a good mental grasp of how > map handles and offsets are used and manipulated in the X server and > in DRI clients? In particular, I'm interested to know under what > circumstances map handles are generated by arithmetic on other map > handles, or obtained from a source other than a DRM_IOCTL_ADD_MAP > ioctl. Similarly for the offset in a mmap on /dev/dri/cardN; do we do > arithmetic to get those values? > > The underlying question is to what extent the handle returned by > DRM_IOCTL_ADD_MAP needs to be predictable (or have a predictable > relationship to other handles) rather than just being an arbitrary > token invented by the kernel DRM code. I don't think that map handles are being computed in any uniform way. Sometimes they are zero, sometimes the physical address, sometime the kernel virtual address. I'm not clear on what user space is supposed to do with handles. I'm doing drmGet(), getting the offset and then passing the offset back into drmMap(). I just ran into a problem where the handle for the framebuffer was zero and that won't work with drmMap(). After changing to the offset field I am just ignoring the handles. -- 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: ioctl32 on amd64
Paul Mackerras writes: > Dave Airlie writes: > > > The changes to types need to clarify what exactly breaks where, I'm not as > > worried about the interactions between X and Mesa as I am about old > > Xs and new kernels... > > And in context, this comes down to the expectations of existing 64-bit > X servers and DRI clients on 64-bit kernels with respect to how map > handles and mmap offsets can be generated and used. I know people are > currently using 64-bit X servers and DRI clients on x86_64 machines at > least. I'm pretty sure that userspace currently expects to be able to > use framebuffer and register physical addresses as the offset in an > mmap on /dev/dri/card0, and to be able to add an offset to a map > handle for an AGP mapping and use that as an offset for mmap. At > least the radeon driver does this IIRC. If there was such a case I must have missed it. The only driver where I came across something like this was in the MGA driver. So I made sure that values that fit into 32bit remained unchanged if possible. At the same time I fixed the driver code to obtain the address from some different source - which was entirely possible. Also 64bit offsets that don't fit into 32bit won't do you any good in 32bit as you cannot mmap() them. > > And you are right, if we make an incompatible change to the > user/kernel ABI in the middle of a stable kernel series, people will > scream, and rightly so. > That's not my plan. 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
Paul Mackerras writes: > Egbert Eich writes: > > > Non of the patches that I've posted had problems with backward > > compatibility. > > At least not across the kernel/user space interface. > > Originally I had one that wasn't however that had been fixed before > > I put patches into the fd.o bugzilla. > > No, your patches originally changed the size of the drm_map_t, and > added a drm32_map_t which was a different size from the old 32-bit So you didn't notice that I've added backward compatibility functions so that the old call would still have worked. Since the size of the structure was different that was easy to do. > drm_map_t. That and the fact that I found your patch impossible to > follow was why I did my version. ... and reinvented the weel repeating the same errors that I have already been thru. Maybe you should have gotten in touch with me and we could have worked out something. > > Now you have a kernel drm_map_t which is different from the user > drm_map_t. I think this has the potential to be immensely confusing > to people. If the kernel needs an internal data structure to keep > information about maps, that's fine, but it should have a different > name. > Fine. I had a different version where I changed the name. Then kernel people told me it was too intrusive since I had to change the name at every occurance. This is why I came up with the drm_pub_map hack. It's really difficult to make it right for everyone in the kernel. 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
New to DRI and how to set up a debugging environment..
Hi all, I am new to linux. I am intesrested in developing drivers for graphics cards. I want to setup a debugging environment for DRM/DRI. I have a RADEON 9600 PRO card. And, I have the card on a m/c which has linux kernel 2.6.7( compiled with KGDB enabled). I also have X11( 6.8.2) installed on that machine. ( compiled with debugging enabled) But, the issue is X server does not recognize the card as a RADEON card. It just says - VESA genric device. If I change it forcefully to RADEON 9600 PRO the server locks up. When I start the KGDB, the DRM does not get loaded up. Can some one tell me when does it get loaded?. How to debug the DRI code?. I tried debugging it with the GDB. But, GDB says no symbols available for debugging. I have compiled X11 with debugging option enabled.( However I have noticed that while building X11 with the World command, it cleans up the .o files. How do I retain these?). I am trying to use a latest kernel version - 2.6.12.1 and the latest X11. But, KGDB patch fails on this kernel. Has any one applied this patch on a 1.6.12.1 version. If so, please let me know how to proceed?. Since, I am new to this please some one guide mehow to set up a debugging environment for the DRM/DRI development. Appreciate your help. Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com --- 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
On 6/29/05, Thomas Hellström <[EMAIL PROTECTED]> wrote: > > Currently the drivers are AddMap'ing multiple little maps over the AGP > > area, but the area is basically split into two area: private for the > > master and public for the DRI clients to write to. > > > > So to get around the root priv requirement of AddMap I could have DRM > > initially create a map which only allows master access to AGP space. > > Then the non-root master could safely AddMap sub-maps which must exist > > inside of the predefined AGP map. These sub-maps would lower the priv > > requirements for parts of AGP space and allow the clients to run. > > > > The via drm module needs a kernel 2MB _RESTRICTED AGP map for the command > stream. The master must not have access to that part, since it will allow > a non-root master to modify the command stream once it has been > security-checked. > > How will drmAgpAlloc be handled? I mean, how will DRM know how big the > initial map will be? drmAgpAlloc() allocs drm_agp_mem structures which track the agp allocs. I could change the map system to allow a single map to be paired with each struct drm_agp_mem. The 2MB restricted you are using was allocated with a call to drmAgpAlloc(), right? You would then add a _RESTRICTED map which would bind to the struct drm_agp_mem and stop further maps. We need to a check to make sure a normal user can't free and reallocate a piece of AGP memory marked restricted. The drivers would then be changed to alloc the various parts of AGP space instead of allocing one big chunk and carving it up. By allocing multiple pieces the master can set different privs on each piece. Backwards compatibility is maintained since root can make any maps that it wants ignoring the one map per struct drm_agp_mem restriction. -- 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: ioctl32 on amd64
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. --- 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
Paul Mackerras writes: > 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. Right. This depends on the macros though. The ioctl32 code does the same kind of operation numerous times. The macros make the code less complex and allow the reader to focus on what conversions are done and not on how they are done. It is very unlikely that the macros do the wrong thing once they are set up right. However it's more likely that someone forgets to do a conversion. There are numerous other examples of macros in the DRM code which don't have this nice property. > > > 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. That's fine. If somone tells me what needs to be done I'm happy to change this. I've been carrying this code along for too long now. When I started this this kind of conversion functions didn't exist. > > 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 found one instance of this left in the code. This was in the mga driver and would be easy to fix. In my opinion this is more a bug in the code. Still I've changed the hash function so that it will (most likely) pass values that fit into 32bit unmodified. The problem is that one has to find some number to 'tag' an SHM area. If this number is identical to a physical base address that is added later this physical area needs to receive a different tag. It may be possible to go back to and modify the hash function again a little bit more along the line of what Dave submitted to the kernel if there is consensus that this would make the case where a real physical base has been assigend to an SHM area already and this is not available any more even less likely. > > 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? Haven't I mentined that it does? Handles that fit into 32bit should be handed to userspace unchanged, therefore if there is any code left that does arithmetic with these handles should continue to work. Handles that are used as real bases should be 32bit as these usually are pointer to base addresses. 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: r300 on Thinkpad r50p (RV350)
On 6/29/03, Rune Petersen <[EMAIL PROTECTED]> wrote:
> Hamish Marson wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Hamish Marson wrote:
> >
> >
> >>Just as a status report...
> >>
> >>On my thinkpad r50p which has an rv350 (FireGL-T2) when using the
> >>current CVS xorg, CVS Mesa and the tagged r300 driver
> >>'the_perfect_frag') it all works, 1600fps on glxgears, but the
> >>flickering is awful on OpenGL apps...
> >>
> >>(Current CVS is yesterday for xorg, today for Mesa).
> >>
> >>glxgears - works OK. But flickers. tuxracer - works OK. Reasonable
> >>frame rates. But flickers at about 10Hz. gl-117 - Same. Reasonable
> >>frame rates. But flickers.
> >>
> >>glxgears was in a window. tuxracer and gl-117 were full-screen. I
> >>had to stop before I threw up...
> >>
> >>Suspend & Resume worked OK so far (Only suspended to RAM once
> >>though).
> >>
> >>Hamish.
> >
> >
> > FWIW the same things also happens on the current CVS copy.
> >
> > This is with a 1600x1200 resolution LCD as well, just in case it
> > matters. gl-117 seems to geta round 60fps in the init screens... But I
> > can't see the screen well enough to navigate through (Or access even)
> > any setup screens to try & change anything in it.
> >
> > H
> >
>
> Flickering should be resolved by adding this to radeon_driver.c in the Xorg:
> @@ -5631,6 +5627,11 @@
> if (!info->IsSecondary)
> RADEONChangeSurfaces(pScrn);
>
> +if (info->ChipFamily >= CHIP_FAMILY_R300) {
> + unsigned char *RADEONMMIO = info->MMIO;
> + OUTREG(0x180, INREG(0x180) | 0x1100);
> +}
> +
> if(info->MergedFB) {
> /* need this here to fix up sarea values */
> RADEONAdjustFrameMerged(scrnIndex, pScrn->frameX0, pScrn->frameY0, 0);
>
>
> Rune Petersen
>
According to the databooks, this is the correct behavior for high res
modes. What it does is bump the display0/1 priorities in the memory
controller. I'll be committing a slighly updated version of this
patch to cvs in the next few days.
Alex
---
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: ioctl32 on amd64
Dave Airlie wrote: 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) Yes, sorry about this. As it stands I don't have a particularly good understanding of the issues and will have to spend a bit of time getting up to speed before I can provide any sort of useful input. 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: ioctl32 on amd64
Egbert Eich writes: > My patches to drm/X are mainly required to make shared structures > identical in size. To me the main question is whether we should leave space for 64-bit handles, or whether 32-bit handles will be sufficient under all circumstances. 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: ioctl32 on amd64
Dave Airlie writes: > The changes to types need to clarify what exactly breaks where, I'm not as > worried about the interactions between X and Mesa as I am about old > Xs and new kernels... And in context, this comes down to the expectations of existing 64-bit X servers and DRI clients on 64-bit kernels with respect to how map handles and mmap offsets can be generated and used. I know people are currently using 64-bit X servers and DRI clients on x86_64 machines at least. I'm pretty sure that userspace currently expects to be able to use framebuffer and register physical addresses as the offset in an mmap on /dev/dri/card0, and to be able to add an offset to a map handle for an AGP mapping and use that as an offset for mmap. At least the radeon driver does this IIRC. And you are right, if we make an incompatible change to the user/kernel ABI in the middle of a stable kernel series, people will scream, and rightly so. 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: ioctl32 on amd64
Egbert Eich writes: > And yes, I know the macros seem to be ugly. However they make writing > ioctl32 support for new drivers really easy as one doesn't have to > understand the macros. Well, it's really the obfuscation rather than the ugliness which is the problem. I disagree that "one doesn't have to understand", that is a recipe for subtle bugs. > They also allow support of older kernels which don't use > compat_alloc_userspace(). Which would be only 2.4 kernels, even the 2.6.5-based SLES9 kernel has it. If you are using a 2.4 kernel you use an old DRM. 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: ioctl32 on amd64
Egbert Eich writes: > Non of the patches that I've posted had problems with backward compatibility. > At least not across the kernel/user space interface. > Originally I had one that wasn't however that had been fixed before > I put patches into the fd.o bugzilla. No, your patches originally changed the size of the drm_map_t, and added a drm32_map_t which was a different size from the old 32-bit drm_map_t. That and the fact that I found your patch impossible to follow was why I did my version. Now you have a kernel drm_map_t which is different from the user drm_map_t. I think this has the potential to be immensely confusing to people. If the kernel needs an internal data structure to keep information about maps, that's fine, but it should have a different name. 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: ioctl32 on amd64
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. --- 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
Do either of you (or does anyone) have a good mental grasp of how map handles and offsets are used and manipulated in the X server and in DRI clients? In particular, I'm interested to know under what circumstances map handles are generated by arithmetic on other map handles, or obtained from a source other than a DRM_IOCTL_ADD_MAP ioctl. Similarly for the offset in a mmap on /dev/dri/cardN; do we do arithmetic to get those values? The underlying question is to what extent the handle returned by DRM_IOCTL_ADD_MAP needs to be predictable (or have a predictable relationship to other handles) rather than just being an arbitrary token invented by the kernel DRM code. Thanks, 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: ioctl32 on amd64
> > 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 --- 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 on Thinkpad r50p (RV350)
Hamish Marson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hamish Marson wrote:
Just as a status report...
On my thinkpad r50p which has an rv350 (FireGL-T2) when using the
current CVS xorg, CVS Mesa and the tagged r300 driver
'the_perfect_frag') it all works, 1600fps on glxgears, but the
flickering is awful on OpenGL apps...
(Current CVS is yesterday for xorg, today for Mesa).
glxgears - works OK. But flickers. tuxracer - works OK. Reasonable
frame rates. But flickers at about 10Hz. gl-117 - Same. Reasonable
frame rates. But flickers.
glxgears was in a window. tuxracer and gl-117 were full-screen. I
had to stop before I threw up...
Suspend & Resume worked OK so far (Only suspended to RAM once
though).
Hamish.
FWIW the same things also happens on the current CVS copy.
This is with a 1600x1200 resolution LCD as well, just in case it
matters. gl-117 seems to geta round 60fps in the init screens... But I
can't see the screen well enough to navigate through (Or access even)
any setup screens to try & change anything in it.
H
Flickering should be resolved by adding this to radeon_driver.c in the Xorg:
@@ -5631,6 +5627,11 @@
if (!info->IsSecondary)
RADEONChangeSurfaces(pScrn);
+if (info->ChipFamily >= CHIP_FAMILY_R300) {
+ unsigned char *RADEONMMIO = info->MMIO;
+ OUTREG(0x180, INREG(0x180) | 0x1100);
+}
+
if(info->MergedFB) {
/* need this here to fix up sarea values */
RADEONAdjustFrameMerged(scrnIndex, pScrn->frameX0, pScrn->frameY0, 0);
Rune Petersen
---
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: > 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. --- 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
> > Dave, if you cannot test this why do you want to port my code > to Paul's sceme - which seems to be much more error prone than > using my sceme? As Pauls scheme was written from what I could see from a kernel developers point of view, it is maintainable for other kernel developers.. reviewing it didn't take much work... I'm going to look over all the patchses again from scratch... > Furthermore if you don't want to do it I would be willing to do that. > But I'm not going to remove all the macros as they are there for a > reason. Furthermore the DRM code contains a lot of other macros already > which have been accepted by the kernel folks. > Ripping out the old non-'compat_alloc_userspace()' sceme would > tremendously simplify the macros so I'd assume they will look much > more acceptable to kernel people. > > Again, the macros are there to make adding ioctl32 support to other > drivers easy. I don't expect people will bother if it's a lot of > work, error prone if they don't even have a chance to test it. I've been spending most of my time ripping out macros from the kernel, you have to realise they get in the way of maintainability more often than not, especially for non-DRM people to audit and check over the code, and patch code themselves... writing code is a one-time effort, reading it happens much more often, so you should optimise for the read case which is a kernel developer fixing a bug.. so no more hiding things in the kernel to make life easier for the author > I've investigated this and I did not encounter a situation where anything > breaks. > I would certainly be able to push the X stuff. However since this is > dependent on the DRI bits it should be pushed toegther. I assume there > there is a scenario on how to do this, that's been used in the past. > Therefore I'm looking for someone who knows how this was done. > > Maybe Alan can help me on this? I think to look at the comment you make about changing the handle size and what if any effect this can have... I can only see the mga passing them across the kernel/user space boundary ... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- 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
Dave Airlie writes: > > > > 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. > > And this is probably all fine for DRM CVS or Xorg, but for the kernel it > just isn't acceptable, I'd be flamed down if I pushed this patch kernel > side, its just a fact of life... I would have to remove all the macros and > old style ioctl32 stuff to get this into the kernel, without any way of > testing it ... I'm not willing to do that, I'm going to port over the mga > and r128 work you've done to Paul's scheme and push them kernel side ... Dave, if you cannot test this why do you want to port my code to Paul's sceme - which seems to be much more error prone than using my sceme? Ripping out the macros is easy to do. There are ifdefs that select between them so the code can easily be identified. All that's left to do will show up immediately when you do a compile. Furthermore if you don't want to do it I would be willing to do that. But I'm not going to remove all the macros as they are there for a reason. Furthermore the DRM code contains a lot of other macros already which have been accepted by the kernel folks. Ripping out the old non-'compat_alloc_userspace()' sceme would tremendously simplify the macros so I'd assume they will look much more acceptable to kernel people. Again, the macros are there to make adding ioctl32 support to other drivers easy. I don't expect people will bother if it's a lot of work, error prone if they don't even have a chance to test it. > > The changes to types need to clarify what exactly breaks where, I'm not as > worried about the interactions between X and Mesa as I am about old > Xs and new kernels... if we change the sarea size in X will it run on an > old kernel, if I upgrade to a new kernel without changing X will it still > work? I'm only taking care of the DRM, really the userspace stuff is going > to have to be up to someone with more authority than me... (I've asked for > people to review your patch when you first published it, no-one did..) I've investigated this and I did not encounter a situation where anything breaks. I would certainly be able to push the X stuff. However since this is dependent on the DRI bits it should be pushed toegther. I assume there there is a scenario on how to do this, that's been used in the past. Therefore I'm looking for someone who knows how this was done. Maybe Alan can help me on this? > > Breakage in X-> DRI isn't so bad as a release will be consistent.. it'll > just break ATI binary drivers... > No, it won't - as ATi needs to ship the DRI modules and the X driver together anyhow. 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
Hi! > On 6/28/05, Ian Romanick <[EMAIL PROTECTED]> wrote: >> > 3) Can the driver pre-build the AGP/PCI gart maps? If these maps are >> > marked differently it is way for my driver to tell AGP from PCI cards. >> >> I would advise against that. There are (rare) cases where user-mode >> wants to select AGP parameters, AGP mode vs. PCI mode, etc. If AGP is >> acquired and those maps added at module load, the only way to make those >> selections will be via module paramters. Yuck. > > Currently the drivers are AddMap'ing multiple little maps over the AGP > area, but the area is basically split into two area: private for the > master and public for the DRI clients to write to. > > So to get around the root priv requirement of AddMap I could have DRM > initially create a map which only allows master access to AGP space. > Then the non-root master could safely AddMap sub-maps which must exist > inside of the predefined AGP map. These sub-maps would lower the priv > requirements for parts of AGP space and allow the clients to run. > The via drm module needs a kernel 2MB _RESTRICTED AGP map for the command stream. The master must not have access to that part, since it will allow a non-root master to modify the command stream once it has been security-checked. How will drmAgpAlloc be handled? I mean, how will DRM know how big the initial map will be? /Thomas > -- > 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 > --- 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
