Re: [Dri-devel] Radeon DRM memory layout transition
Ian Romanick wrote: That aside, I think we should be able to remove xf86drmCompat.c now. Unless I'm mistaken, libdrm.a is statically linked into the *_dri.so. If that's the case, and all of the client-side drivers have been updated to not use the functions in xf86drmCompat.c, why do we need it? I looked at the mga driver with nm, and it doesn't reference any of the drmMGA* symbols. If you have access to an XF4.2 system are older, you should check for drmMGA*, drmR128*, drmRadeon*, drmI810* and drmI830* in the 2D drivers...it's these 2D routines we're providing compatability for with the XFree86 server side libdrm.a module that's distributed with our binary packages. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
Michel DÃnzer wrote: On Wed, 2003-10-22 at 23:49, Ian Romanick wrote: I added Keith's proposed struct with int64_t as the value, and I added '#include ' to xf86drmCompat.c. Everything compiled fine. Easy enough. :) I've updated http://penguinppc.org/~daenzer/DRI/radeon-memory-transition.diff, addressing the feedback I've received so far - thanks, more appreciated as always. In particular, Eric will need to double check this for the BSDs; I don't know what to define DRM_PUT_USER_UNCHECKED() to, and the filp_priv handling may still be wrong. I briefly looked at the patch. That looks fine to me. Are we intending to maintain the old client-side drivers forever? I seem to remember there being problems with the really old client-side drivers and the newer kernel modules anyway. FWIW (not much :), I'm not aware of such problems. Do you mean the opposite problems of newer radeon 3D drivers with older DRMs? Right. My memory is a bit fuzzy, but I could have sworn that there were some problems with very old (i.e., 4.0.x) 3D drivers with some of the newer kernel modules. That aside, I think we should be able to remove xf86drmCompat.c now. Unless I'm mistaken, libdrm.a is statically linked into the *_dri.so. If that's the case, and all of the client-side drivers have been updated to not use the functions in xf86drmCompat.c, why do we need it? I looked at the mga driver with nm, and it doesn't reference any of the drmMGA* symbols. --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
Alex Deucher wrote: The question is, can we start ripping it out now, or will there be a xfree86 4.5 and 4.6, etc. As much as I would like to, I don't think we should start ripping yet. I think that will raise to many support questions like, "The new DRI drivers won't load!" :) I think putting #ifdef's around some of the code or otherwise documenting which interfaces and bits of glue are going away is a good idea. --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Wed, 2003-10-22 at 23:49, Ian Romanick wrote: > I added Keith's proposed struct with int64_t as the value, and I added > '#include ' to xf86drmCompat.c. Everything compiled fine. Easy enough. :) I've updated http://penguinppc.org/~daenzer/DRI/radeon-memory-transition.diff, addressing the feedback I've received so far - thanks, more appreciated as always. In particular, Eric will need to double check this for the BSDs; I don't know what to define DRM_PUT_USER_UNCHECKED() to, and the filp_priv handling may still be wrong. > Are we intending to maintain the old client-side drivers forever? I > seem to remember there being problems with the really old client-side > drivers and the newer kernel modules anyway. FWIW (not much :), I'm not aware of such problems. Do you mean the opposite problems of newer radeon 3D drivers with older DRMs? -- Earthling Michel DÃnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Fri, 2003-10-24 at 16:15, Alex Deucher wrote: > The question is, can we start ripping it out now, or will there be a > xfree86 4.5 and 4.6, etc. Until there's an official roadmap for 5.x, I'd assume the next release to be 4.x. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
The question is, can we start ripping it out now, or will there be a
xfree86 4.5 and 4.6, etc.
Alex
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Jens Owen wrote:
>
> > We can definitely remove the xf86drmCompat layer for XFree86 5.0.
> I
> > believe it's well understood that major version changes will break
> > existing binary interfaces.
>
> Oh goodie! There's a whole ton of crap that will get ripped out of
> lib/GL/glx/glx{cmds,ext}.c then! All of the stuff for determining if
>
> the client-side driver supports glcontextmodes and bindContext2 /
> unbindContext2 will go bye-bye. :) This is the best news I've heard
> all
> day...
>
>
>
>
> ---
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community? Make a contribution, and help us add new
> features and functionality. Click here:
> http://sourceforge.net/donate/
> ___
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-develceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
Jens Owen wrote:
We can definitely remove the xf86drmCompat layer for XFree86 5.0. I
believe it's well understood that major version changes will break
existing binary interfaces.
Oh goodie! There's a whole ton of crap that will get ripped out of
lib/GL/glx/glx{cmds,ext}.c then! All of the stuff for determining if
the client-side driver supports glcontextmodes and bindContext2 /
unbindContext2 will go bye-bye. :) This is the best news I've heard all
day...
---
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
Ian Romanick wrote: Michel Dänzer wrote: On Wed, 2003-10-22 at 20:38, Ian Romanick wrote: Eric Anholt wrote: Would we ever be setting pointers through a setparam interface? I think making it an int makes it relatively clear that it's a 32-bit value, though it might be valuable to use [u]intXX_t for the drm (and dri screen private?) sruct definitions everywhere to make things clear. Also, yes, alpha, amd64, ia64, and sparc64 all have 32-bit ints and 64-bit longs and pointers. Isn't the FB_LOCATION a pointer? :) Admittedly it will always be in the first 4GB today, but when PCI Express comes, I don't think that will always be the case. I'd hate to have to invent a new ioctl to support PCI Express when that day comes. That won't be necessary in any case; once there is a chip (which we support...) with a 64 bit address space, just add a parameter to set the high 32 bits. :) I don't mind either way, but I don't feel like figuring out which type to use for a 64 bit value and dealing with the build problems it might cause right now. I added Keith's proposed struct with int64_t as the value, and I added '#include ' to xf86drmCompat.c. Everything compiled fine. As a side note, at what time will we be able to deprecate xf86drmCompat? Are we intending to maintain the old client-side drivers forever? I seem to remember there being problems with the really old client-side drivers and the newer kernel modules anyway. We can definitely remove the xf86drmCompat layer for XFree86 5.0. I believe it's well understood that major version changes will break existing binary interfaces. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
Michel Dänzer wrote: On Wed, 2003-10-22 at 20:38, Ian Romanick wrote: Eric Anholt wrote: Would we ever be setting pointers through a setparam interface? I think making it an int makes it relatively clear that it's a 32-bit value, though it might be valuable to use [u]intXX_t for the drm (and dri screen private?) sruct definitions everywhere to make things clear. Also, yes, alpha, amd64, ia64, and sparc64 all have 32-bit ints and 64-bit longs and pointers. Isn't the FB_LOCATION a pointer? :) Admittedly it will always be in the first 4GB today, but when PCI Express comes, I don't think that will always be the case. I'd hate to have to invent a new ioctl to support PCI Express when that day comes. That won't be necessary in any case; once there is a chip (which we support...) with a 64 bit address space, just add a parameter to set the high 32 bits. :) I don't mind either way, but I don't feel like figuring out which type to use for a 64 bit value and dealing with the build problems it might cause right now. I added Keith's proposed struct with int64_t as the value, and I added '#include ' to xf86drmCompat.c. Everything compiled fine. As a side note, at what time will we be able to deprecate xf86drmCompat? Are we intending to maintain the old client-side drivers forever? I seem to remember there being problems with the really old client-side drivers and the newer kernel modules anyway. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Wed, 2003-10-22 at 20:38, Ian Romanick wrote: > Eric Anholt wrote: > > > Would we ever be setting pointers through a setparam interface? I think > > making it an int makes it relatively clear that it's a 32-bit value, > > though it might be valuable to use [u]intXX_t for the drm (and dri > > screen private?) sruct definitions everywhere to make things clear. > > Also, yes, alpha, amd64, ia64, and sparc64 all have 32-bit ints and > > 64-bit longs and pointers. > > Isn't the FB_LOCATION a pointer? :) Admittedly it will always be in the > first 4GB today, but when PCI Express comes, I don't think that will > always be the case. I'd hate to have to invent a new ioctl to support PCI Express > when that > day comes. That won't be necessary in any case; once there is a chip (which we support...) with a 64 bit address space, just add a parameter to set the high 32 bits. :) I don't mind either way, but I don't feel like figuring out which type to use for a 64 bit value and dealing with the build problems it might cause right now. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
Eric Anholt wrote: Would we ever be setting pointers through a setparam interface? I think making it an int makes it relatively clear that it's a 32-bit value, though it might be valuable to use [u]intXX_t for the drm (and dri screen private?) sruct definitions everywhere to make things clear. Also, yes, alpha, amd64, ia64, and sparc64 all have 32-bit ints and 64-bit longs and pointers. Isn't the FB_LOCATION a pointer? :) Admittedly it will always be in the first 4GB today, but when PCI Express comes, I don't think that will always be the case. I'd hate to have to invent a new ioctl to support PCI Express when that day comes. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Radeon DRM memory layout transition
> systems will break, we don't need to add more. On PPC64 where mixed > mode is supported, sizeof(int) != sizeof(void*). I assume > the same is true on IA-64, x86-64, and SPARC64. x86-64 Linux (gcc) sizeof(int) == 4 sizeonf(long) == 8 sizeof(void*) == 8 x86-64 Windows (VC) sizeof(int) == 4 sizeonf(long) == 4 sizeof(void*) == 8 -- Daniel, Epic Games Inc. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 2003-10-21 at 11:55, Ian Romanick wrote:
> Keith Whitwell wrote:
>
> > Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
> > DRM_RADEON_FB_LOCATION, with an ioctl struct like:
> >
> > #define RADEON_SETPARAM_FB_LOCATION 1
> >
> > typedef struct drm_radeon_setparam {
> > int param;
> > int value;
> > } drm_radeon_setparam_t;
>
> If this is done, I would *strongly* suggest that the type of value by
> int64_t or something similar. We have enough places where mixed 32/64
> systems will break, we don't need to add more. On PPC64 where mixed
> mode is supported, sizeof(int) != sizeof(void*). I assume the same is
> true on IA-64, x86-64, and SPARC64.
>
> Other than that, I am in favor of adding this as a more generic interface.
Would we ever be setting pointers through a setparam interface? I think
making it an int makes it relatively clear that it's a 32-bit value,
though it might be valuable to use [u]intXX_t for the drm (and dri
screen private?) sruct definitions everywhere to make things clear.
Also, yes, alpha, amd64, ia64, and sparc64 all have 32-bit ints and
64-bit longs and pointers.
Hmm, just noticed that the SiS dri/ddx/drm interactions are rather
64-bit unclean. I thought I had fixed that.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 2003-10-21 at 20:55, Ian Romanick wrote:
> Keith Whitwell wrote:
>
> > Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
> > DRM_RADEON_FB_LOCATION, with an ioctl struct like:
> >
> > #define RADEON_SETPARAM_FB_LOCATION 1
> >
> > typedef struct drm_radeon_setparam {
> > int param;
> > int value;
> > } drm_radeon_setparam_t;
>
> If this is done, I would *strongly* suggest that the type of value by
> int64_t or something similar.
I tried u32 for fb_location initially, the problem is that radeon_drm.h
is also included in
programs/Xserver/hw/xfree86/os-support/linux/drm/xf86drmCompat.c, where
this doesn't work.
--
Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
---
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Wed, 2003-10-22 at 01:59, Vladimir Dergachev wrote: > > > > Anyway, I think the most important point is that the DRM should be able > > to deal with whatever you throw at it this way; the details can still be > > changed later. Agreed? > > DRM and DRI drivers. :) What do you mean? Old 3D drivers work with this unchanged. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
> > > > time. > > > > > > Any idea how soon that will be? I was originally hoping to sneak this > > > into XFree86 4.4, but that's getting less likely by the day. > > > > No idea unfortunately. I'll be very busy the next three weeks and to make > > tests I would need to port GATOS code to DRI CVS. There should be a lot of > > changes at least in the mach64 code, but likely elsewhere as well. > > Err, what does Mach64 have to do with this? :) Either I port the whole thing, or it is a one big hack.. ;) > > Anyway, I think the most important point is that the DRM should be able > to deal with whatever you throw at it this way; the details can still be > changed later. Agreed? DRM and DRI drivers. :) best Vladimir Dergachev > > > -- > Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer > Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer > --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 2003-10-21 at 17:13, Vladimir Dergachev wrote: > On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote: > > > On Tue, 2003-10-21 at 03:53, Vladimir Dergachev wrote: > > > On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote: > > > > > > > On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wrote: > > > > > > > > > 2) I would have expected SetFBLocation function to make sure that > > > > > the card is idle. Maybe this is done someplace else ? > > > > > > > > Not explicitly yet, but that's easy enough to add. Is there anything > > > > else to be careful about there? > > > > > > Well, I'll have to take a closer look when I get a solid chunk of spare > > > time. > > > > Any idea how soon that will be? I was originally hoping to sneak this > > into XFree86 4.4, but that's getting less likely by the day. > > No idea unfortunately. I'll be very busy the next three weeks and to make > tests I would need to port GATOS code to DRI CVS. There should be a lot of > changes at least in the mach64 code, but likely elsewhere as well. Err, what does Mach64 have to do with this? :) Anyway, I think the most important point is that the DRM should be able to deal with whatever you throw at it this way; the details can still be changed later. Agreed? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
Keith Whitwell wrote:
Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
DRM_RADEON_FB_LOCATION, with an ioctl struct like:
#define RADEON_SETPARAM_FB_LOCATION 1
typedef struct drm_radeon_setparam {
int param;
int value;
} drm_radeon_setparam_t;
If this is done, I would *strongly* suggest that the type of value by
int64_t or something similar. We have enough places where mixed 32/64
systems will break, we don't need to add more. On PPC64 where mixed
mode is supported, sizeof(int) != sizeof(void*). I assume the same is
true on IA-64, x86-64, and SPARC64.
Other than that, I am in favor of adding this as a more generic interface.
---
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dänzer wrote: > On Tue, 2003-10-21 at 03:53, Vladimir Dergachev wrote: > > On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote: > > > > > On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wrote: > > > > > > > 2) I would have expected SetFBLocation function to make sure that > > > > the card is idle. Maybe this is done someplace else ? > > > > > > Not explicitly yet, but that's easy enough to add. Is there anything > > > else to be careful about there? > > > > Well, I'll have to take a closer look when I get a solid chunk of spare > > time. > > Any idea how soon that will be? I was originally hoping to sneak this > into XFree86 4.4, but that's getting less likely by the day. No idea unfortunately. I'll be very busy the next three weeks and to make tests I would need to port GATOS code to DRI CVS. There should be a lot of changes at least in the mach64 code, but likely elsewhere as well. It is very tempting though ;) best Vladimir Dergachev > > > What code are you working against XFree86 CVS or DRI CVS ? > > DRI CVS for now, but there shouldn't be much difference between the two > yet. > > > -- > Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer > Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer > --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 2003-10-21 at 11:06, Keith Whitwell wrote:
>
> In r200_screen.c, you check for drmMinor >= 10 before issuing the FB_LOCATION
> ioctl, but it's not clear what happens if drmMinor < 10 -- will the driver
> function correctly? [...]
Yes. The driver determines the memory layout from the chip registers,
the ioctl just improves the DRM's ability to check and fix up state.
> Also, it seems this patch does two things, one is the fblocation stuff, but
> there's also some chipset_id changes relating to the R200_CHIPSET_RS300. I'd
> be happier to see these in separate patches.
I can commit these parts separately once everybody is happy, but I'll
keep them together for now due to
http://bugs.xfree86.org/show_bug.cgi?id=314 .
> In radeon_state.c, the tests in radeon_emit_packets() are just ugly. The
> normal usage for this code on a properly installed system is that
> (filp_priv->fboffset == 0), right? So all those tests are going to result in
> a noop? Could the tests be pushed into their own functions and shortcircuited
> witha single test on (fboffset == 0) ?
So I thought first, but then it occurred to me that there's no guarantee
that clients use sensible memory offsets at all, so I think it's a good
idea always to check them (even for the older ioctls, on second though)
to prevent bad things from happening.
> Additionally, in those tests, it looks like you are reading back and fixing up
> the data on the ring -- ie from uncached memory! Especially when (fboffset ==
> 0) this is a very wasteful noop...
Well, I haven't noticed any significant performance impact, but I can
change that I guess.
> Finally, and just being picky -- it'd be nice to keep the number of coding
> styles fairly minimal. It just looks a little odd to start seeing the spaces
> in code like 'tmp[ 0 ]', while the rest of the module is 'tmp[0]'
Point taken. It's just that I've grown to like the spaces a lot (partly
because of you ;), but they're certainly less important for square
brackets.
> Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
> DRM_RADEON_FB_LOCATION, with an ioctl struct like:
>
> #define RADEON_SETPARAM_FB_LOCATION 1
>
> typedef struct drm_radeon_setparam {
> int param;
> int value;
> } drm_radeon_setparam_t;
>
>
> There are other int-valued parameters that I can imagine being set in this way.
Good idea.
Thanks for your suggestions, I'll integrate them and post an updated
patch ASAP.
--
Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
---
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 2003-10-21 at 03:53, Vladimir Dergachev wrote: > On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote: > > > On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wrote: > > > > > 2) I would have expected SetFBLocation function to make sure that > > > the card is idle. Maybe this is done someplace else ? > > > > Not explicitly yet, but that's easy enough to add. Is there anything > > else to be careful about there? > > Well, I'll have to take a closer look when I get a solid chunk of spare > time. Any idea how soon that will be? I was originally hoping to sneak this into XFree86 4.4, but that's getting less likely by the day. > What code are you working against XFree86 CVS or DRI CVS ? DRI CVS for now, but there shouldn't be much difference between the two yet. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 2003-10-21 at 05:14, Eric Anholt wrote: > > One small problem in radeon_fb_location ioctl: For OS-independence, so > far filp has been an opaque void pointer. I'm wondering if maybe we > want to pass the drm_file_t * as part of DRM_IOCTL_ARGS, or just > resurrect DRM_PRIV to get the drm_file_t * based on filp. I have no opinion on which one is better, but either is definitely needed for this to work. :) -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
Michel Dänzer wrote: On Wed, 2003-10-08 at 04:34, Vladimir Dergachev wrote: On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dnzer wrote: Does the aperture ever (have to) move during the X server life though? I would not care. However, I know that at least Window 98 drivers have default position (0) unless capture is enabled. Also, I suspect that when one calls Video BIOS with framebuffer position anywhere other than 0 the BIOS then toggles the hard reset line. Why? (CC'ing Hui Yu, who should be able to comment on this) No idea why it does it. Any news on this? I haven't taken this into account in http://penguinppc.org/~daenzer/DRI/radeon-memory-transition.diff In r200_screen.c, you check for drmMinor >= 10 before issuing the FB_LOCATION ioctl, but it's not clear what happens if drmMinor < 10 -- will the driver function correctly? If not, what should happen? Also, it seems this patch does two things, one is the fblocation stuff, but there's also some chipset_id changes relating to the R200_CHIPSET_RS300. I'd be happier to see these in separate patches. In radeon_state.c, the tests in radeon_emit_packets() are just ugly. The normal usage for this code on a properly installed system is that (filp_priv->fboffset == 0), right? So all those tests are going to result in a noop? Could the tests be pushed into their own functions and shortcircuited witha single test on (fboffset == 0) ? Additionally, in those tests, it looks like you are reading back and fixing up the data on the ring -- ie from uncached memory! Especially when (fboffset == 0) this is a very wasteful noop... Finally, and just being picky -- it'd be nice to keep the number of coding styles fairly minimal. It just looks a little odd to start seeing the spaces in code like 'tmp[ 0 ]', while the rest of the module is 'tmp[0]' Keith --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
Michel Dänzer wrote:
On Wed, 2003-10-08 at 04:34, Vladimir Dergachev wrote:
On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
Does the aperture ever (have to) move during the X server life though?
I would not care. However, I know that at least Window 98 drivers have
default position (0) unless capture is enabled. Also, I suspect that when
one calls Video BIOS with framebuffer position anywhere other than 0 the
BIOS then toggles the hard reset line.
Why? (CC'ing Hui Yu, who should be able to comment on this)
No idea why it does it.
Any news on this? I haven't taken this into account in
http://penguinppc.org/~daenzer/DRI/radeon-memory-transition.diff
Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
DRM_RADEON_FB_LOCATION, with an ioctl struct like:
#define RADEON_SETPARAM_FB_LOCATION 1
typedef struct drm_radeon_setparam {
int param;
int value;
} drm_radeon_setparam_t;
There are other int-valued parameters that I can imagine being set in this way.
Keith
---
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dänzer wrote: > On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wrote: > > I do like the patch. > > Cool. > > > Few questions/comments: > > > > 1) Did you check that it works with non-zero fbLocation ? > > In particular, not all offsets need to have fbLocation added, > > however, the code appears to be correct - I just worry that > > it may add (or not add) fbLocation in the wrong place. > > It's working fine here. I noticed that you handle this quite differently > in the ati.2 driver, but IMHO this way (based on Hui's patches) is > cleaner. Not very much. The differences came from the desire to reduce the work when porting the code to new versions. Thus I avoided adding new fields as much as I can. > > > > 2) I would have expected SetFBLocation function to make sure that > > the card is idle. Maybe this is done someplace else ? > > Not explicitly yet, but that's easy enough to add. Is there anything > else to be careful about there? Well, I'll have to take a closer look when I get a solid chunk of spare time. What code are you working against XFree86 CVS or DRI CVS ? best Vladimir Dergachev > > > -- > Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer > Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer > --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Mon, 2003-10-20 at 18:14, Michel Dänzer wrote: > On Wed, 2003-10-08 at 04:34, Vladimir Dergachev wrote: > > On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dnzer wrote: > > > > > > > Does the aperture ever (have to) move during the X server life though? > > > > > > > > I would not care. However, I know that at least Window 98 drivers have > > > > default position (0) unless capture is enabled. Also, I suspect that when > > > > one calls Video BIOS with framebuffer position anywhere other than 0 the > > > > BIOS then toggles the hard reset line. > > > > > > Why? (CC'ing Hui Yu, who should be able to comment on this) > > > > No idea why it does it. > > Any news on this? I haven't taken this into account in > > http://penguinppc.org/~daenzer/DRI/radeon-memory-transition.diff > > which is my first take on this. As discussed before, this should handle > any combination of new and old components gracefully, in particular it > fixes up the client state in the DRM if necessary (and in the process > always checks them and returns an error if they lie outside the > framebuffer or GART apertures), so old 3D drivers work with the new 2D > driver and DRM. One small problem in radeon_fb_location ioctl: For OS-independence, so far filp has been an opaque void pointer. I'm wondering if maybe we want to pass the drm_file_t * as part of DRM_IOCTL_ARGS, or just resurrect DRM_PRIV to get the drm_file_t * based on filp. (The problem here is that *BSD don't easily have the per-open device private area, so we use a hack in drm_fops.h to simulate it) -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
I do like the patch. Few questions/comments: 1) Did you check that it works with non-zero fbLocation ? In particular, not all offsets need to have fbLocation added, however, the code appears to be correct - I just worry that it may add (or not add) fbLocation in the wrong place. 2) I would have expected SetFBLocation function to make sure that the card is idle. Maybe this is done someplace else ? best Vladimir Dergachev On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dänzer wrote: > On Wed, 2003-10-08 at 04:34, Vladimir Dergachev wrote: > > On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dnzer wrote: > > > > > > > Does the aperture ever (have to) move during the X server life though? > > > > > > > > I would not care. However, I know that at least Window 98 drivers have > > > > default position (0) unless capture is enabled. Also, I suspect that when > > > > one calls Video BIOS with framebuffer position anywhere other than 0 the > > > > BIOS then toggles the hard reset line. > > > > > > Why? (CC'ing Hui Yu, who should be able to comment on this) > > > > No idea why it does it. > > Any news on this? I haven't taken this into account in > > http://penguinppc.org/~daenzer/DRI/radeon-memory-transition.diff > > which is my first take on this. As discussed before, this should handle > any combination of new and old components gracefully, in particular it > fixes up the client state in the DRM if necessary (and in the process > always checks them and returns an error if they lie outside the > framebuffer or GART apertures), so old 3D drivers work with the new 2D > driver and DRM. > > > Feedback appreciated, > > > -- > Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer > Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer > --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wrote: > I do like the patch. Cool. > Few questions/comments: > > 1) Did you check that it works with non-zero fbLocation ? > In particular, not all offsets need to have fbLocation added, > however, the code appears to be correct - I just worry that > it may add (or not add) fbLocation in the wrong place. It's working fine here. I noticed that you handle this quite differently in the ati.2 driver, but IMHO this way (based on Hui's patches) is cleaner. > 2) I would have expected SetFBLocation function to make sure that > the card is idle. Maybe this is done someplace else ? Not explicitly yet, but that's easy enough to add. Is there anything else to be careful about there? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Wed, 2003-10-08 at 04:34, Vladimir Dergachev wrote: > On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dnzer wrote: > > > > > Does the aperture ever (have to) move during the X server life though? > > > > > > I would not care. However, I know that at least Window 98 drivers have > > > default position (0) unless capture is enabled. Also, I suspect that when > > > one calls Video BIOS with framebuffer position anywhere other than 0 the > > > BIOS then toggles the hard reset line. > > > > Why? (CC'ing Hui Yu, who should be able to comment on this) > > No idea why it does it. Any news on this? I haven't taken this into account in http://penguinppc.org/~daenzer/DRI/radeon-memory-transition.diff which is my first take on this. As discussed before, this should handle any combination of new and old components gracefully, in particular it fixes up the client state in the DRM if necessary (and in the process always checks them and returns an error if they lie outside the framebuffer or GART apertures), so old 3D drivers work with the new 2D driver and DRM. Feedback appreciated, -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dänzer wrote: > On Tue, 2003-10-07 at 15:02, Vladimir Dergachev wrote: > > > > > > > > I would suggest adding more ioctls: > > > > > > > > 1. Lock the drm driver against future connections from 3d driver(s). > > > > > > > > 2. Return the number of current connections. > > > > > > > > 3. Move the aperture - should only succeed when nothing else is connected. > > > > > > > > Also, when aperture is moved DRM driver can simply refuse connection to > > > > older 3d drivers. > > > > > > Does the aperture ever (have to) move during the X server life though? > > > > I would not care. However, I know that at least Window 98 drivers have > > default position (0) unless capture is enabled. Also, I suspect that when > > one calls Video BIOS with framebuffer position anywhere other than 0 the > > BIOS then toggles the hard reset line. > > Why? (CC'ing Hui Yu, who should be able to comment on this) No idea why it does it. > > Would resetting the aperture to the default position on server shutdown > deal with this adequately? One would also need to do it each time before video bios is called, or prevent it from being called when we are in the middle of things. best Vladimir Dergachev --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 2003-10-07 at 15:02, Vladimir Dergachev wrote: > > > > > > I would suggest adding more ioctls: > > > > > > 1. Lock the drm driver against future connections from 3d driver(s). > > > > > > 2. Return the number of current connections. > > > > > > 3. Move the aperture - should only succeed when nothing else is connected. > > > > > > Also, when aperture is moved DRM driver can simply refuse connection to > > > older 3d drivers. > > > > Does the aperture ever (have to) move during the X server life though? > > I would not care. However, I know that at least Window 98 drivers have > default position (0) unless capture is enabled. Also, I suspect that when > one calls Video BIOS with framebuffer position anywhere other than 0 the > BIOS then toggles the hard reset line. Why? (CC'ing Hui Yu, who should be able to comment on this) Would resetting the aperture to the default position on server shutdown deal with this adequately? > > Our idea would be an ioctl to set the aperture position on startup and > > (possibly another one) for 3D clients to let the DRM know what they > > think the aperture position is. Then the DRM could fix up client > > commands as necessary. This would work with any 3D driver (except > > probably old incompatible ones from GATOS :). > > Well, fixing up commands might not be so trivial. With 4.3.0 drivers it > turned out it was a lot easier to fix the 3d client. The 3D drivers will be fixed at any rate. The idea is to preserve as much backwards compatibility with old 3D drivers as possible, at least to prevent them from taking down the machine or similar catastrophic failure. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
> > > > I would suggest adding more ioctls: > > > > 1. Lock the drm driver against future connections from 3d driver(s). > > > > 2. Return the number of current connections. > > > > 3. Move the aperture - should only succeed when nothing else is connected. > > > > Also, when aperture is moved DRM driver can simply refuse connection to > > older 3d drivers. > > Does the aperture ever (have to) move during the X server life though? I would not care. However, I know that at least Window 98 drivers have default position (0) unless capture is enabled. Also, I suspect that when one calls Video BIOS with framebuffer position anywhere other than 0 the BIOS then toggles the hard reset line. > Our idea would be an ioctl to set the aperture position on startup and > (possibly another one) for 3D clients to let the DRM know what they > think the aperture position is. Then the DRM could fix up client > commands as necessary. This would work with any 3D driver (except > probably old incompatible ones from GATOS :). Well, fixing up commands might not be so trivial. With 4.3.0 drivers it turned out it was a lot easier to fix the 3d client. Of course, I am not an expert.. best Vladimir Dergachev > > > -- > Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer > Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Mon, 2003-10-06 at 17:38, Vladimir Dergachev wrote: > On Mon, 6 Oct 2003, Michel [ISO-8859-1] Dnzer wrote: > > > A proposal for this has been developed in > > http://bugs.xfree86.org/show_bug.cgi?id=314 (first idea in comment #20, > > refinement inspired by > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg11659.html in comment #27) > > Very interesting, I certainly would be delighted if this was implemented. > > All GATOS drivers need is that framebuffer was moved outside of system > RAM. Nothing more. Good. > As Keith rightly points out, when one uses ioctl it would be hard to make > 3d driver to understand that the aperture moved. > > I would suggest adding more ioctls: > > 1. Lock the drm driver against future connections from 3d driver(s). > > 2. Return the number of current connections. > > 3. Move the aperture - should only succeed when nothing else is connected. > > Also, when aperture is moved DRM driver can simply refuse connection to > older 3d drivers. Does the aperture ever (have to) move during the X server life though? Our idea would be an ioctl to set the aperture position on startup and (possibly another one) for 3D clients to let the DRM know what they think the aperture position is. Then the DRM could fix up client commands as necessary. This would work with any 3D driver (except probably old incompatible ones from GATOS :). -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Mon, 6 Oct 2003, Michel [ISO-8859-1] Dänzer wrote: > > A proposal for this has been developed in > http://bugs.xfree86.org/show_bug.cgi?id=314 (first idea in comment #20, > refinement inspired by > http://www.mail-archive.com/[EMAIL PROTECTED]/msg11659.html in comment #27) Very interesting, I certainly would be delighted if this was implemented. All GATOS drivers need is that framebuffer was moved outside of system RAM. Nothing more. As Keith rightly points out, when one uses ioctl it would be hard to make 3d driver to understand that the aperture moved. I would suggest adding more ioctls: 1. Lock the drm driver against future connections from 3d driver(s). 2. Return the number of current connections. 3. Move the aperture - should only succeed when nothing else is connected. Also, when aperture is moved DRM driver can simply refuse connection to older 3d drivers. best Vladimir Dergachev > > I'd appreciate feedback on this from the GATOS developers, in particular > whether it would be enough to remove the incompatibility of Radeon DRI > components between our projects, or what other issues there are to > consider. > > > PS: I'm not subscribed to the gatos-devel list. > > -- > Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer > Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon DRM memory layout transition
A proposal for this has been developed in http://bugs.xfree86.org/show_bug.cgi?id=314 (first idea in comment #20, refinement inspired by http://www.mail-archive.com/[EMAIL PROTECTED]/msg11659.html in comment #27) I'd appreciate feedback on this from the GATOS developers, in particular whether it would be enough to remove the incompatibility of Radeon DRI components between our projects, or what other issues there are to consider. PS: I'm not subscribed to the gatos-devel list. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
