Re: drm: Branch 'master' - 5 commits
On Thu, Apr 5, 2012 at 4:21 PM, Ville Syrjälä wrote:
> On Tue, Apr 03, 2012 at 02:50:01PM -0700, Rob Clark wrote:
>> + /* just testing a limited # of formats to test single
>> + * and multi-planar path.. would be nice to add more..
>> + */
>> + if (!strcmp(p->format_str, "YUYV")) {
>> + pitches[0] = p->w * 2;
>> + offsets[0] = 0;
>> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]);
>> +
>> + fill422(virtual, 0, p->w, p->h, pitches[0]);
>> +
>> + format = DRM_FORMAT_YUYV;
>> + } else if (!strcmp(p->format_str, "NV12")) {
>> + pitches[0] = p->w;
>> + offsets[0] = 0;
>> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]);
>> + pitches[1] = p->w;
>> + offsets[1] = p->w * p->h;
>> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[1]);
>> +
>> + fill420(virtual, virtual+offsets[1],
>> virtual+offsets[1]+1,
>> + 2, 0, p->w, p->h, pitches[0]);
>> +
>> + format = DRM_FORMAT_NV12;
>> + } else if (!strcmp(p->format_str, "YV12")) {
>> + pitches[0] = p->w;
>> + offsets[0] = 0;
>> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]);
>> + pitches[1] = p->w / 2;
>> + offsets[1] = p->w * p->h;
>> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[1]);
>> + pitches[2] = p->w / 2;
>> + offsets[2] = offsets[1] + (p->w * p->h) / 4;
>> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[1]);
> ^
> Should be '2'. The kernel patch I just posted might have caught this.
> OTOH it might not have in case handles[2] contains uninitialized data.
>
Good catch, I can push a fix. If you already have a patch, please
send, otherwise I'll just go ahead and fix it myself.
fwiw, on omap4xxx we only support 1 and 2 plane formats, so 3 plane
was untested.. but I wanted to push the test at least so we could have
some common test code between the different platforms and catch any
potential mismatches in understanding (for ex. the src coords in 16.16
format vs integer)
> We should add a test that would make sure that passing an invalid bo
> handle for any plane would return with an error. The problem is knowing
> what exactly is an invalid handle since it's all driver specific.
> Perhaps 0x would be a reasonably safe choice. Hmm, now I wonder
> if 0 might actually be a valid handle for some of the current drivers...
I guess *nearly* everyone uses GEM? I suppose we could have a
validate_handle fxn ptr w/ a default drm_gem_validate_handle() helper
that any of the drivers using GEM could use. I'm not sure if that is
just overkill (since the drm_gem_object_lookup() would anyways fail in
the driver part).
On the other hand moving something like the objects_lookup() helper in
omapdrm into core gem code might not be a bad idea. This way each
driver isn't having to handle the cleanup when it gets only part way
thru object lookup when it encounters an invalid handle.
> There should obviously also be a test that does use separate bos
> for reach plane. That should either succeed and produce the correct
> result, or the driver should respond with an error at least to the
> setplane ioctl. Whether it would allow addfb2 to succeed is a slightly
> more complicated matter. I suppose it could be possible that on some
> odd hardware some planes would support multiple bos and some would
> not. In which case the driver would need to allow the addfb2.
Yeah, there certainly is room for more tests, especially because there
are so many possible permutations. Possibly we should split out into
'planetest' before modetest gets too big? Anyways, I figured at least
one basic test was better than zero ;-)
BR,
-R
> --
> Ville Syrjälä
> syrj...@sci.fi
> http://www.sci.fi/~syrjala/
>
> --
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know
Re: drm: Branch 'master' - 5 commits
On Tue, Apr 03, 2012 at 02:50:01PM -0700, Rob Clark wrote:
> + /* just testing a limited # of formats to test single
> + * and multi-planar path.. would be nice to add more..
> + */
> + if (!strcmp(p->format_str, "YUYV")) {
> + pitches[0] = p->w * 2;
> + offsets[0] = 0;
> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]);
> +
> + fill422(virtual, 0, p->w, p->h, pitches[0]);
> +
> + format = DRM_FORMAT_YUYV;
> + } else if (!strcmp(p->format_str, "NV12")) {
> + pitches[0] = p->w;
> + offsets[0] = 0;
> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]);
> + pitches[1] = p->w;
> + offsets[1] = p->w * p->h;
> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[1]);
> +
> + fill420(virtual, virtual+offsets[1],
> virtual+offsets[1]+1,
> + 2, 0, p->w, p->h, pitches[0]);
> +
> + format = DRM_FORMAT_NV12;
> + } else if (!strcmp(p->format_str, "YV12")) {
> + pitches[0] = p->w;
> + offsets[0] = 0;
> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]);
> + pitches[1] = p->w / 2;
> + offsets[1] = p->w * p->h;
> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[1]);
> + pitches[2] = p->w / 2;
> + offsets[2] = offsets[1] + (p->w * p->h) / 4;
> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[1]);
^
Should be '2'. The kernel patch I just posted might have caught this.
OTOH it might not have in case handles[2] contains uninitialized data.
We should add a test that would make sure that passing an invalid bo
handle for any plane would return with an error. The problem is knowing
what exactly is an invalid handle since it's all driver specific.
Perhaps 0x would be a reasonably safe choice. Hmm, now I wonder
if 0 might actually be a valid handle for some of the current drivers...
There should obviously also be a test that does use separate bos
for reach plane. That should either succeed and produce the correct
result, or the driver should respond with an error at least to the
setplane ioctl. Whether it would allow addfb2 to succeed is a slightly
more complicated matter. I suppose it could be possible that on some
odd hardware some planes would support multiple bos and some would
not. In which case the driver would need to allow the addfb2.
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master' - 2 commits
On Mon, 05 Dec 2011 14:23:55 -0800, Eric Anholt wrote: > On Mon, 5 Dec 2011 02:31:58 -0800 (PST), ic...@kemper.freedesktop.org (Chris > Wilson) wrote: > > configure.ac |2 +- > > intel/intel_bufmgr_gem.c | 27 +-- > > 2 files changed, 22 insertions(+), 7 deletions(-) > > > > New commits: > > commit e73161a02b604742e3da3bca8f13cff81276de43 > > Author: Chris Wilson > > Date: Mon Dec 5 10:30:52 2011 + > > > > configure: Bump version to 2.4.28 > > > > So that we can pull a couple of Intel bug fixes into xf86-video-intel. > > > > Signed-off-by: Chris Wilson > > Performance before: > [ 0] glfirefox-talos-gfx 17.866 17.915 0.14%4/4 > after: > [ 0] glfirefox-talos-gfx 22.173 22.251 0.20%4/4 > > There's a pretty obvious opportunity to keep the performance win of the > userspace caching that you've broken here, but you gave none of us a > chance to review it before you pushed the patch *and shipped a release > with it*. This is not acceptable. Please revert and bump the release, > and fix it correctly. No, what was unacceptable was a vma leak impacting a critical system application, and for the library API to be broken by design. The onus is to improve performance without regressing system stability, not the other way around. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master' - 2 commits
On Mon, 5 Dec 2011 02:31:58 -0800 (PST), ic...@kemper.freedesktop.org (Chris Wilson) wrote: > configure.ac |2 +- > intel/intel_bufmgr_gem.c | 27 +-- > 2 files changed, 22 insertions(+), 7 deletions(-) > > New commits: > commit e73161a02b604742e3da3bca8f13cff81276de43 > Author: Chris Wilson > Date: Mon Dec 5 10:30:52 2011 + > > configure: Bump version to 2.4.28 > > So that we can pull a couple of Intel bug fixes into xf86-video-intel. > > Signed-off-by: Chris Wilson Performance before: [ 0] glfirefox-talos-gfx 17.866 17.915 0.14%4/4 after: [ 0] glfirefox-talos-gfx 22.173 22.251 0.20%4/4 There's a pretty obvious opportunity to keep the performance win of the userspace caching that you've broken here, but you gave none of us a chance to review it before you pushed the patch *and shipped a release with it*. This is not acceptable. Please revert and bump the release, and fix it correctly. pgpAEuNpy2UG9.pgp Description: PGP signature -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
Dne 1.9.2010 02:53, Eric Anholt napsal(a): > On Tue, 31 Aug 2010 12:17:43 +0200, Zdenek Kabelac > wrote: >> Dne 28.8.2010 05:55, Eric Anholt napsal(a): >>> On Fri, 27 Aug 2010 13:16:04 +0200, Zdenek Kabelac >>> wrote: On 27.8.2010 12:02, Julien Cristau wrote: > On Fri, Aug 27, 2010 at 11:26:59 +0200, Zdenek Kabelac wrote: > >> Why keeping different name for C++ and C ? >> > Because changing the name for C means breaking API for existing users, > which is not a nice thing to do. > Well if DRM would have very stable API - it would make sence - but from a view of occasional user who needs to compile drm for intel driver - it seems the API is changed so frequently and in such an incompatible way that this change doesn't look all that bad. How many libdrm project users are there - and how often is this variable used outside of libdrm ? Now C++ will use different names for same variables - that IMHO bigger issue... Also - if headers are supposed to be C++ friendly - maybe usage of extern "C" might be handy for such case ? >>> >>> Uh, you claim the API has changed, but I'm not aware of any circumstance >>> since TTM removal where upgrading libdrm on Intel should have broken >>> either API or ABI for its users. Can you back that up? >> >> Ok - I'm remembering this issue: >> >> Essentially I've had idea to try to bisect for this problem: >> https://bugs.freedesktop.org/show_bug.cgi?id=26937 >> >> As I'm quite sure, that there were times were I could use fullscreen for >> flash >> without fear of having to restart my desktop. >> >> So I've tried just some random older git versions of libdrm & intel driver - > > there were some minor compilations issue (I guess some list defines > conflicts >> and few other minor things for compilation). >> >> However compiled driver & library actually never worked and all I got was >> usually black screen. It's probably hard to judge if the problem is kernel >> driver (using usually quite fresh vanilla git tree) or Xorg from Fedora >> Rawhide can't work with some slightly older libdrm/intel. It probably not >> reasonable to spend time to detect where exactly is problem - all I want to >> point out is, that some internal API must changed significantly so while I >> could usually boot with 2 year old kernel, I cannot use few months old >> drm&intel driver. >> >> And back to this issue - if this variable is used a lot by other projects, >> than this commit is probably ok - though looks ugly. But if there is just >> one >> project which uses it, than it's probably better to break API and keep it >> clean and use same variable for C & C++ programs. > > For bisecting, just hold libdrm at the new version and bisect in 2d, > unless your initial test of old+old vs old+new of each component points > at libdrm (in which case, hold the 2d driver old and bisect across > libdrm). > > New drivers do require new symbols, but libdrm is API and ABI stable, > exactly so that people can bisect successfully. Ok - I made a closer look at the problem - and bisected for a reason my current Xorg server shows black screen for older version of Intel driver. It looks like the key issue is some API change in Xorg related to this Intel driver commit: 8700673157fdd3a87ad5150f2f30823261fec519 (Adapt glyphs for changes in devPrivates API, Jun 7 2010, Chris Wilson) This is effectively the oldest version of Intel driver which currently seems to work with my (recently upgraded) xorg-x11-server-Xorg-1.9.0-7.fc15.x86_64. It seems like cherry-picking to make this usable for older version of Intel git tree seems to be very complicated so doing bisect looks like very hard task in this case. I'm open to some ideas how could I eventually try to resolve/help with my fullscreen bug (id=26937). Anyway this seems to show that keeping API stable at one small library and breaking it in Xorg server itself doesn't make things better after all Is there any other way (except essentially completely reinstalling my whole system and trying to figure out which combination of Xorg and driver still works ok for full screen??) Would it help to post some /sys prints which would show why the screen is locked in 'fullscreen' picture and there is no way to restore it back ? Zdenek -- Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Tue, 31 Aug 2010 12:17:43 +0200, Zdenek Kabelac wrote: > Dne 28.8.2010 05:55, Eric Anholt napsal(a): > > On Fri, 27 Aug 2010 13:16:04 +0200, Zdenek Kabelac > > wrote: > >> On 27.8.2010 12:02, Julien Cristau wrote: > >>> On Fri, Aug 27, 2010 at 11:26:59 +0200, Zdenek Kabelac wrote: > >>> > Why keeping different name for C++ and C ? > > >>> Because changing the name for C means breaking API for existing users, > >>> which is not a nice thing to do. > >>> > >> > >> > >> Well if DRM would have very stable API - it would make sence - but from a > >> view > >> of occasional user who needs to compile drm for intel driver - it seems > >> the > >> API is changed so frequently and in such an incompatible way that this > >> change > >> doesn't look all that bad. > >> > >> How many libdrm project users are there - and how often is this variable > >> used > >> outside of libdrm ? > >> > >> Now C++ will use different names for same variables - that IMHO bigger > >> issue... > >> > >> Also - if headers are supposed to be C++ friendly - maybe usage of > >> extern "C" might be handy for such case ? > > > > Uh, you claim the API has changed, but I'm not aware of any circumstance > > since TTM removal where upgrading libdrm on Intel should have broken > > either API or ABI for its users. Can you back that up? > > Ok - I'm remembering this issue: > > Essentially I've had idea to try to bisect for this problem: > https://bugs.freedesktop.org/show_bug.cgi?id=26937 > > As I'm quite sure, that there were times were I could use fullscreen for flash > without fear of having to restart my desktop. > > So I've tried just some random older git versions of libdrm & intel driver - > there were some minor compilations issue (I guess some list defines conflicts > and few other minor things for compilation). > > However compiled driver & library actually never worked and all I got was > usually black screen. It's probably hard to judge if the problem is kernel > driver (using usually quite fresh vanilla git tree) or Xorg from Fedora > Rawhide can't work with some slightly older libdrm/intel. It probably not > reasonable to spend time to detect where exactly is problem - all I want to > point out is, that some internal API must changed significantly so while I > could usually boot with 2 year old kernel, I cannot use few months old > drm&intel driver. > > And back to this issue - if this variable is used a lot by other projects, > than this commit is probably ok - though looks ugly. But if there is just one > project which uses it, than it's probably better to break API and keep it > clean and use same variable for C & C++ programs. For bisecting, just hold libdrm at the new version and bisect in 2d, unless your initial test of old+old vs old+new of each component points at libdrm (in which case, hold the 2d driver old and bisect across libdrm). New drivers do require new symbols, but libdrm is API and ABI stable, exactly so that people can bisect successfully. pgpcqoVUWDGRH.pgp Description: PGP signature -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
Dne 28.8.2010 05:55, Eric Anholt napsal(a): > On Fri, 27 Aug 2010 13:16:04 +0200, Zdenek Kabelac > wrote: >> On 27.8.2010 12:02, Julien Cristau wrote: >>> On Fri, Aug 27, 2010 at 11:26:59 +0200, Zdenek Kabelac wrote: >>> Why keeping different name for C++ and C ? >>> Because changing the name for C means breaking API for existing users, >>> which is not a nice thing to do. >>> >> >> >> Well if DRM would have very stable API - it would make sence - but from a >> view >> of occasional user who needs to compile drm for intel driver - it seems the >> API is changed so frequently and in such an incompatible way that this >> change >> doesn't look all that bad. >> >> How many libdrm project users are there - and how often is this variable >> used >> outside of libdrm ? >> >> Now C++ will use different names for same variables - that IMHO bigger >> issue... >> >> Also - if headers are supposed to be C++ friendly - maybe usage of >> extern "C" might be handy for such case ? > > Uh, you claim the API has changed, but I'm not aware of any circumstance > since TTM removal where upgrading libdrm on Intel should have broken > either API or ABI for its users. Can you back that up? Ok - I'm remembering this issue: Essentially I've had idea to try to bisect for this problem: https://bugs.freedesktop.org/show_bug.cgi?id=26937 As I'm quite sure, that there were times were I could use fullscreen for flash without fear of having to restart my desktop. So I've tried just some random older git versions of libdrm & intel driver - there were some minor compilations issue (I guess some list defines conflicts and few other minor things for compilation). However compiled driver & library actually never worked and all I got was usually black screen. It's probably hard to judge if the problem is kernel driver (using usually quite fresh vanilla git tree) or Xorg from Fedora Rawhide can't work with some slightly older libdrm/intel. It probably not reasonable to spend time to detect where exactly is problem - all I want to point out is, that some internal API must changed significantly so while I could usually boot with 2 year old kernel, I cannot use few months old drm&intel driver. And back to this issue - if this variable is used a lot by other projects, than this commit is probably ok - though looks ugly. But if there is just one project which uses it, than it's probably better to break API and keep it clean and use same variable for C & C++ programs. Zdenek -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Fri, 27 Aug 2010 13:16:04 +0200, Zdenek Kabelac wrote: > On 27.8.2010 12:02, Julien Cristau wrote: > > On Fri, Aug 27, 2010 at 11:26:59 +0200, Zdenek Kabelac wrote: > > > >> Why keeping different name for C++ and C ? > >> > > Because changing the name for C means breaking API for existing users, > > which is not a nice thing to do. > > > > > Well if DRM would have very stable API - it would make sence - but from a > view > of occasional user who needs to compile drm for intel driver - it seems the > API is changed so frequently and in such an incompatible way that this change > doesn't look all that bad. > > How many libdrm project users are there - and how often is this variable used > outside of libdrm ? > > Now C++ will use different names for same variables - that IMHO bigger > issue... > > Also - if headers are supposed to be C++ friendly - maybe usage of > extern "C" might be handy for such case ? Uh, you claim the API has changed, but I'm not aware of any circumstance since TTM removal where upgrading libdrm on Intel should have broken either API or ABI for its users. Can you back that up? pgpKm9ejTeVnU.pgp Description: PGP signature -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On 27.8.2010 12:02, Julien Cristau wrote: > On Fri, Aug 27, 2010 at 11:26:59 +0200, Zdenek Kabelac wrote: > >> Why keeping different name for C++ and C ? >> > Because changing the name for C means breaking API for existing users, > which is not a nice thing to do. > Well if DRM would have very stable API - it would make sence - but from a view of occasional user who needs to compile drm for intel driver - it seems the API is changed so frequently and in such an incompatible way that this change doesn't look all that bad. How many libdrm project users are there - and how often is this variable used outside of libdrm ? Now C++ will use different names for same variables - that IMHO bigger issue... Also - if headers are supposed to be C++ friendly - maybe usage of extern "C" might be handy for such case ? Zdenek -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Fri, Aug 27, 2010 at 11:26:59 +0200, Zdenek Kabelac wrote: > Why keeping different name for C++ and C ? > Because changing the name for C means breaking API for existing users, which is not a nice thing to do. Cheers, Julien -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
Dne 27.8.2010 00:50, Eric Anholt napsal(a):
> include/drm/drm.h|4
> intel/intel_bufmgr.h |6 +-
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> New commits:
> commit 23287f05cf2443ddf9e028e29beb5bd30979c6cf
> Author: Eric Anholt
> Date: Thu Aug 26 15:39:28 2010 -0700
>
> Avoid use of c++ reserved keyword "virtual" when using a C++ compiler.
>
> Avoids requiring nasty hacks around libdrm headers in the new C++
> parts of Mesa drivers.
>
> diff --git a/include/drm/drm.h b/include/drm/drm.h
> index a0559eb..2ba7136 100644
> --- a/include/drm/drm.h
> +++ b/include/drm/drm.h
> @@ -373,7 +373,11 @@ struct drm_buf_pub {
> */
> struct drm_buf_map {
> int count; /**< Length of the buffer list */
> +#ifdef __cplusplus
> + void *virt;
> +#else
> void *virtual; /**< Mmap'd area in user-virtual */
> +#endif
> struct drm_buf_pub *list; /**< Buffer information */
> };
Quit weird patch
Why keeping different name for C++ and C ?
Why not simply use i.e.:
void* user_virtual;
Or something similar - and avoid using these rather useless ifdefs ?
Zdenek
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Tue, 9 Feb 2010 00:38:05 -0800 (PST), ic...@kemper.freedesktop.org (Chris Wilson) wrote: > intel/intel_bufmgr_gem.c | 13 + > 1 file changed, 13 insertions(+) > > New commits: > commit fdcde592c2c48e143251672cf2e82debb07606bd > Author: Chris Wilson > Date: Tue Feb 9 08:32:54 2010 + > > intel: Account for potential pinned buffers hogging fences > > As the kernel reports the total number of fences, we must guess how many > fences are likely to be pinned. In the typical system these will be only > used by the scanout buffers, of which there may be one per pipe, and any > number of manually pinned fenced buffers. So take a conservative guess > and reserve two fences for use by the system. > > Note this reduces the number of fences to 3 for i915 and prior. (on a non-2.6.33 KMS kernel) pgphRCRvGshO0.pgp Description: PGP signature -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Thu, 2008-12-11 at 22:50 -0800, vehemens wrote: > On Thursday 11 December 2008 04:28:48 pm Jesse Barnes wrote: > > On Thursday, December 11, 2008 4:16 pm vehemens wrote: > > > On Wednesday 10 December 2008 03:52:08 pm Jesse Barnes wrote: > > > >... > > > >New commits: > > > >commit 9583c099b4a08b49e03f7b461c344b6d277fd262 > > > >Author: Jesse Barnes > > > >Date: Wed Dec 10 15:47:28 2008 -0800 > > > > > > > >Revert "Merge branch 'modesetting-gem'" > > > > > > > >This reverts commit 6656db10551bbb8770dd945b6d81d5138521f208. > > > > > > > >We really just want the libdrm and ioctl bits, not all the driver > > > >stuff. > > > >... > > > > > > Could you help me out and explain why we don't want the merge? > > > > Because it pulled in a bunch of driver code that probably isn't ready (at > > least I didn't want to merge it w/o acks from Dave, Jerome and Stephane). > > I just posted a more minimal patch earlier today. > > I can understand not merging code when it's not ready, but that begs the > question on who would be affected at this point given the way most > distributions are handled :? > Radeon code in modesetting-gem branch is not ready especialy libdrm-radeon and in it the cs part, i am mostly happy with the bo part. So i believe Jesse took the right decision. Otherwise i don't understand your question on who's affected ? affected by what ? Cheers, Jerome Glisse -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Thursday 11 December 2008 04:28:48 pm Jesse Barnes wrote: > On Thursday, December 11, 2008 4:16 pm vehemens wrote: > > On Wednesday 10 December 2008 03:52:08 pm Jesse Barnes wrote: > > >... > > >New commits: > > >commit 9583c099b4a08b49e03f7b461c344b6d277fd262 > > >Author: Jesse Barnes > > >Date: Wed Dec 10 15:47:28 2008 -0800 > > > > > >Revert "Merge branch 'modesetting-gem'" > > > > > >This reverts commit 6656db10551bbb8770dd945b6d81d5138521f208. > > > > > >We really just want the libdrm and ioctl bits, not all the driver > > >stuff. > > >... > > > > Could you help me out and explain why we don't want the merge? > > Because it pulled in a bunch of driver code that probably isn't ready (at > least I didn't want to merge it w/o acks from Dave, Jerome and Stephane). > I just posted a more minimal patch earlier today. I can understand not merging code when it's not ready, but that begs the question on who would be affected at this point given the way most distributions are handled :? -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Thursday, December 11, 2008 4:16 pm vehemens wrote: > On Wednesday 10 December 2008 03:52:08 pm Jesse Barnes wrote: > >... > >New commits: > >commit 9583c099b4a08b49e03f7b461c344b6d277fd262 > >Author: Jesse Barnes > >Date: Wed Dec 10 15:47:28 2008 -0800 > > > >Revert "Merge branch 'modesetting-gem'" > > > >This reverts commit 6656db10551bbb8770dd945b6d81d5138521f208. > > > >We really just want the libdrm and ioctl bits, not all the driver > >stuff. > >... > > Could you help me out and explain why we don't want the merge? Because it pulled in a bunch of driver code that probably isn't ready (at least I didn't want to merge it w/o acks from Dave, Jerome and Stephane). I just posted a more minimal patch earlier today. -- Jesse Barnes, Intel Open Source Technology Center -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Wednesday 10 December 2008 03:52:08 pm Jesse Barnes wrote: >... >New commits: >commit 9583c099b4a08b49e03f7b461c344b6d277fd262 >Author: Jesse Barnes >Date: Wed Dec 10 15:47:28 2008 -0800 > >Revert "Merge branch 'modesetting-gem'" > >This reverts commit 6656db10551bbb8770dd945b6d81d5138521f208. > >We really just want the libdrm and ioctl bits, not all the driver >stuff. >... Could you help me out and explain why we don't want the merge? -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master' - 5 commits
On Tuesday, June 03, 2008 2:54 am Michel Dänzer wrote:
> Nan hai (I hope I got that right), Jesse,
>
>
> I think your drm commits 63fd6f284ddd1096d34b39941683ae244c1e01fc
> ("[i915] 2D driver may reset Frame count value, this may lead driver")
> and c7ee6cc269c26d8e7ed98a16a272eca63daab201 ("Remove broken 'in vblank'
> accounting") should be revisited in the light of these fixes (and the
> corresponding xf86-video-ati changes to call the DRM_IOCTL_MODESET_CTL
> ioctl). The former should no longer be necessary, and the problem that
> prompted the latter is now worked around in the core, as it turned out
> to affect the radeon driver as well.
Yeah, if the 2D drivers support the ioctl, I think we can get rid of Nanhai's
workaround. What do you think Nanhai?
Thanks,
Jesse
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master' - 5 commits
Nan hai (I hope I got that right), Jesse,
I think your drm commits 63fd6f284ddd1096d34b39941683ae244c1e01fc
("[i915] 2D driver may reset Frame count value, this may lead driver")
and c7ee6cc269c26d8e7ed98a16a272eca63daab201 ("Remove broken 'in vblank'
accounting") should be revisited in the light of these fixes (and the
corresponding xf86-video-ati changes to call the DRM_IOCTL_MODESET_CTL
ioctl). The former should no longer be necessary, and the problem that
prompted the latter is now worked around in the core, as it turned out
to affect the radeon driver as well.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Sunday, April 27, 2008 3:25 am Michel Dänzer wrote:
> On Sat, 2008-04-26 at 17:14 -0700, Jesse Barnes wrote:
> > New commits:
> > commit b45fe49bcd989be4e1327c13dd734410b395761c
> > Author: Jesse Barnes <[EMAIL PROTECTED](none)>
> > Date: Sat Apr 26 17:11:18 2008 -0700
> >
> > Enum-ectomy of vblank modesetting ioctl
> >
> > Enum can be of pretty much any size since C leaves the choice of size
> > up to the implementation. So avoid using it in new interfaces like the
> > vblank pre- & post-modeset ioctl. Thanks to hch for spotting this.
>
> [...]
>
> > @@ -567,7 +566,7 @@ enum drm_modeset_ctl_cmd {
> > */
> > struct drm_modeset_ctl {
> > unsigned long arg;
> > - enum drm_modeset_ctl_cmd cmd;
> > + int cmd;
> > };
>
> Meanwhile, unsigned long definitely requires special handling with 32
> bit userspace on a 64 bit kernel... it should probably be replaced with
> a fixed size type, but I'm not sure if it needs 64 bits or if 32 are
> sufficient.
Yeah I was just talking with Dave about that... The original code was just
trying to stay consistent with the rest of the DRM interfaces. This seems
like a really bad idea in hindsight.
Also, 'arg' should really be called 'crtc' and can safely be u32 or something
much smaller. 'cmd' could just be u8...
Jesse
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Sat, 2008-04-26 at 17:14 -0700, Jesse Barnes wrote:
>
> New commits:
> commit b45fe49bcd989be4e1327c13dd734410b395761c
> Author: Jesse Barnes <[EMAIL PROTECTED](none)>
> Date: Sat Apr 26 17:11:18 2008 -0700
>
> Enum-ectomy of vblank modesetting ioctl
>
> Enum can be of pretty much any size since C leaves the choice of size up
> to the implementation. So avoid using it in new interfaces like the vblank
> pre- & post-modeset ioctl. Thanks to hch for spotting this.
[...]
> @@ -567,7 +566,7 @@ enum drm_modeset_ctl_cmd {
> */
> struct drm_modeset_ctl {
> unsigned long arg;
> - enum drm_modeset_ctl_cmd cmd;
> + int cmd;
> };
Meanwhile, unsigned long definitely requires special handling with 32
bit userspace on a 64 bit kernel... it should probably be replaced with
a fixed size type, but I'm not sure if it needs 64 bits or if 32 are
sufficient.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
Eric Anholt wrote:
> On Sun, 2008-04-06 at 02:21 -0700, Thomas Hellstrom wrote:
>
>> linux-core/drm_objects.h |2 ++
>> linux-core/drm_ttm.c | 12 +---
>> 2 files changed, 11 insertions(+), 3 deletions(-)
>>
>> New commits:
>> commit e89710bef7691e4e9d0bc7d427542bfae6ce4258
>> Author: Thomas Hellstrom
>> Date: Sun Apr 6 11:21:22 2008 +0200
>>
>> Place highmem pages last in the ttm page array.
>>
>
> Could you add a comment explaining what this is about?
>
This is to prepare for Dave's linux 2.6.26 set_memory_uc_array()
interface which accepts an array of virtual addresses, and hence no
highmem pages.
We have two ways to handle this
a) Allocate a new temporary array that holds the virtual addresses. This
will in many cases fall back to using slow vmalloc() and not desirable.
b) Temporarily (during the set_memory_uc_array() call only) typecast the
page array entries and replace the (struct page) pointers with unsigned
long virtual addresses for the lomem pages. This avoids the vmalloc()
but OTOH is a bit ugly.
The above commit is to pave the way for b) if we want to go that way.
/Thomas
>> diff --git a/linux-core/drm_objects.h b/linux-core/drm_objects.h
>> index 9bd04ff..c32edac 100644
>> --- a/linux-core/drm_objects.h
>> +++ b/linux-core/drm_objects.h
>> @@ -311,6 +311,8 @@ struct drm_ttm_backend {
>> struct drm_ttm {
>> struct page *dummy_read_page;
>> struct page **pages;
>> +long first_himem_page;
>> +long last_lomem_page;
>> uint32_t page_flags;
>> unsigned long num_pages;
>> atomic_t vma_count;
>> diff --git a/linux-core/drm_ttm.c b/linux-core/drm_ttm.c
>> index da202a5..c306a2c 100644
>> --- a/linux-core/drm_ttm.c
>> +++ b/linux-core/drm_ttm.c
>> @@ -263,12 +263,16 @@ struct page *drm_ttm_get_page(struct drm_ttm *ttm, int
>> index)
>> struct page *p;
>> struct drm_buffer_manager *bm = &ttm->dev->bm;
>>
>> -p = ttm->pages[index];
>> -if (!p) {
>> +while(NULL == (p = ttm->pages[index])) {
>> p = drm_ttm_alloc_page();
>> if (!p)
>> return NULL;
>> -ttm->pages[index] = p;
>> +
>> +if (PageHighMem(p))
>> +ttm->pages[--ttm->first_himem_page] = p;
>> +else
>> +ttm->pages[++ttm->last_lomem_page] = p;
>> +
>> ++bm->cur_pages;
>> }
>> return p;
>> @@ -376,6 +380,8 @@ struct drm_ttm *drm_ttm_create(struct drm_device *dev,
>> unsigned long size,
>>
>> ttm->destroy = 0;
>> ttm->num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
>> +ttm->first_himem_page = ttm->num_pages;
>> +ttm->last_lomem_page = -1;
>>
>> ttm->page_flags = page_flags;
>>
>>
>> -
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> Register now and save $200. Hurry, offer ends at 11:59 p.m.,
>> Monday, April 7! Use priority code J8TLD2.
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> --
>> ___
>> Dri-patches mailing list
>> [EMAIL PROTECTED]
>> https://lists.sourceforge.net/lists/listinfo/dri-patches
>>
>>
>>
>> -
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> Register now and save $200. Hurry, offer ends at 11:59 p.m.,
>> Monday, April 7! Use priority code J8TLD2.
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>>
>>
>> --
>> ___
>> Dri-devel mailing list
>> Dri-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/dri-devel
>>
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Sun, 2008-04-06 at 02:21 -0700, Thomas Hellstrom wrote:
> linux-core/drm_objects.h |2 ++
> linux-core/drm_ttm.c | 12 +---
> 2 files changed, 11 insertions(+), 3 deletions(-)
>
> New commits:
> commit e89710bef7691e4e9d0bc7d427542bfae6ce4258
> Author: Thomas Hellstrom
> Date: Sun Apr 6 11:21:22 2008 +0200
>
> Place highmem pages last in the ttm page array.
Could you add a comment explaining what this is about?
> diff --git a/linux-core/drm_objects.h b/linux-core/drm_objects.h
> index 9bd04ff..c32edac 100644
> --- a/linux-core/drm_objects.h
> +++ b/linux-core/drm_objects.h
> @@ -311,6 +311,8 @@ struct drm_ttm_backend {
> struct drm_ttm {
> struct page *dummy_read_page;
> struct page **pages;
> + long first_himem_page;
> + long last_lomem_page;
> uint32_t page_flags;
> unsigned long num_pages;
> atomic_t vma_count;
> diff --git a/linux-core/drm_ttm.c b/linux-core/drm_ttm.c
> index da202a5..c306a2c 100644
> --- a/linux-core/drm_ttm.c
> +++ b/linux-core/drm_ttm.c
> @@ -263,12 +263,16 @@ struct page *drm_ttm_get_page(struct drm_ttm *ttm, int
> index)
> struct page *p;
> struct drm_buffer_manager *bm = &ttm->dev->bm;
>
> - p = ttm->pages[index];
> - if (!p) {
> + while(NULL == (p = ttm->pages[index])) {
> p = drm_ttm_alloc_page();
> if (!p)
> return NULL;
> - ttm->pages[index] = p;
> +
> + if (PageHighMem(p))
> + ttm->pages[--ttm->first_himem_page] = p;
> + else
> + ttm->pages[++ttm->last_lomem_page] = p;
> +
> ++bm->cur_pages;
> }
> return p;
> @@ -376,6 +380,8 @@ struct drm_ttm *drm_ttm_create(struct drm_device *dev,
> unsigned long size,
>
> ttm->destroy = 0;
> ttm->num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> + ttm->first_himem_page = ttm->num_pages;
> + ttm->last_lomem_page = -1;
>
> ttm->page_flags = page_flags;
>
>
> -
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Register now and save $200. Hurry, offer ends at 11:59 p.m.,
> Monday, April 7! Use priority code J8TLD2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> --
> ___
> Dri-patches mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-patches
--
Eric Anholt [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master' - 2 commits
Dave Airlie wrote: >>> >>> >> Yes, I think so. One reason to lock is to make sure the GTT page table >> is really repopulated after a resume, but that can be handled in the DRM >> driver resume function, and we could perhaps >> change the user-space lock_mm() to ignore kernel_bos. >> > > It defintely should all be handled in-kernel, putting functionality like > that under user space control is a throw back, the lock-mm should maybe > only apply to the bos allocated to that user who locks.. or really I'm not > sure we really need a lock function if we have a proper kernel driver.. > > I'm not sure that we need that either. Currently it has two purposes: 1) Make sure the X server doesn't use any VRAM or TT resources when it's VT switched. With TTM I don't think we really need this, since if an fb app or whatever needs space, it will evict the X server and DRI buffers. 2) Make dri clients sleep while VT is switched away. If we decide that 1) is not important with kernel-created mms, the problem more or less goes away, and I haven't really read up enough on the new drm design to know how 2 is supposed to be handled. /Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master' - 2 commits
> > > Yes, I think so. One reason to lock is to make sure the GTT page table > is really repopulated after a resume, but that can be handled in the DRM > driver resume function, and we could perhaps > change the user-space lock_mm() to ignore kernel_bos. It defintely should all be handled in-kernel, putting functionality like that under user space control is a throw back, the lock-mm should maybe only apply to the bos allocated to that user who locks.. or really I'm not sure we really need a lock function if we have a proper kernel driver.. > > We also have a another possibility where an ioctl makes the drm fb evict > its scanout buffers and one that brings them back. This preserves > aperture space when X is doing its allocation, but it's abit > error-prone since it requires that fb can live with updated offsets and > kernel virtual addresses. It apparently can, but there's no mutex > generally protecting these variables so it seems quite fragile. Again we can't do this with an ioctl as it leaves us open to userspace whims, however with modesetting branch I'm hoping to come up with something to allow this, myself and Jakob have discussed a driver specific ioctl, which can swap fbs out of the aperture on the fly, so the driver can swap in X's fb and when X exits swap in the fb fb.. Yes fb is a bit messy, it doesn't have a prepare/commit type functionality, and we may have to come up with a map/unmap interface with a mutex for it to use to update the screen... Dave. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master' - 2 commits
Dave Airlie wrote: >> So, over to the somewhat different problem I was referring to, namely >> potential buffer eviction on vt switch where the X server run >> drm_bo_lock_mm(), and will evict any fb scanout BOs. Only the fb layer >> doesn't really notice as long as the BOs sit in VRAM... >> > > Yes I get around this currently by not having the X server call it on > modesetting systems. Clearly I need a better answer which may be that we > ignore it in the kernel, unless it comes from a control node process.. > > when does locking the mm make actual sense? just VT switching? > > Yes, I think so. One reason to lock is to make sure the GTT page table is really repopulated after a resume, but that can be handled in the DRM driver resume function, and we could perhaps change the user-space lock_mm() to ignore kernel_bos. We also have a another possibility where an ioctl makes the drm fb evict its scanout buffers and one that brings them back. This preserves aperture space when X is doing its allocation, but it's abit error-prone since it requires that fb can live with updated offsets and kernel virtual addresses. It apparently can, but there's no mutex generally protecting these variables so it seems quite fragile. /Thomas > Dave. > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master' - 2 commits
> So, over to the somewhat different problem I was referring to, namely > potential buffer eviction on vt switch where the X server run > drm_bo_lock_mm(), and will evict any fb scanout BOs. Only the fb layer > doesn't really notice as long as the BOs sit in VRAM... Yes I get around this currently by not having the X server call it on modesetting systems. Clearly I need a better answer which may be that we ignore it in the kernel, unless it comes from a control node process.. when does locking the mm make actual sense? just VT switching? Dave. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master' - 2 commits
Dave Airlie wrote: >>> >>> this adds something to say the kernel initialised the memory region not >>> the userspace. and blocks userspace from deallocating kernel areas >>> >>> >> Dave, >> I guess this commit is a fix for the fact that the X server will try to >> evict fb scanout buffers when leaving VT. We've solved this issue so far >> by having the fb layer evict its scanouts when the X server starts >> before it goes on allocating its own buffers. This was done using >> device-private IOCTLS. >> > > Nope its to do with the fact that if the kernel sets up a memory managed > area, userspace shuoldn't be allowed to just tear it down... so in > modesetting the kernel sets up the areas, running an old X driver then > nukes my memory manager that I'm still using... > > What I'd like to do actually is make the memory managed areas configured > from userspace attach to the master fd as well, so when you nuke > userspace, it self destructs any memory managed areas it setup, while this > has little long term value (as really you need to create the memory areas > in-kernel already) I can see it being useful for a lot of short-term > stuff. > > OK. Hmm, I was confusing drm_bo_clean_mm with drm_bo_lock_mm. > > >> While this is probably desirable to save GTT / VRAM space, I agree it's >> not desirable that the X server or master has the power to evict kernel >> buffers. >> >> What are your thoughts about this? It'd be good to have a common >> practice for upcoming drivers. >> Do we need a mechanism for the X server to clean out it's own buffers >> and the DRI client buffers, or should we just leave them where they are? >> If we want to implement something like that we might have >> drm_bo_clean_mm leave bo_kernel buffers alone instead of the whole >> memory area. >> >> > > So really when the X server exits, all buffers allocated by it need to go > away, or at least get dereferenced, however if it has create memory > managed areas these also need to go away... it should not be destroying > memory manager areas. > I agree. So, over to the somewhat different problem I was referring to, namely potential buffer eviction on vt switch where the X server run drm_bo_lock_mm(), and will evict any fb scanout BOs. Only the fb layer doesn't really notice as long as the BOs sit in VRAM... This needs to be addressed in one way or another. /Thomas > Dave. > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master' - 2 commits
> > > > this adds something to say the kernel initialised the memory region not > > the userspace. and blocks userspace from deallocating kernel areas > > > Dave, > I guess this commit is a fix for the fact that the X server will try to > evict fb scanout buffers when leaving VT. We've solved this issue so far > by having the fb layer evict its scanouts when the X server starts > before it goes on allocating its own buffers. This was done using > device-private IOCTLS. Nope its to do with the fact that if the kernel sets up a memory managed area, userspace shuoldn't be allowed to just tear it down... so in modesetting the kernel sets up the areas, running an old X driver then nukes my memory manager that I'm still using... What I'd like to do actually is make the memory managed areas configured from userspace attach to the master fd as well, so when you nuke userspace, it self destructs any memory managed areas it setup, while this has little long term value (as really you need to create the memory areas in-kernel already) I can see it being useful for a lot of short-term stuff. > While this is probably desirable to save GTT / VRAM space, I agree it's > not desirable that the X server or master has the power to evict kernel > buffers. > > What are your thoughts about this? It'd be good to have a common > practice for upcoming drivers. > Do we need a mechanism for the X server to clean out it's own buffers > and the DRI client buffers, or should we just leave them where they are? > If we want to implement something like that we might have > drm_bo_clean_mm leave bo_kernel buffers alone instead of the whole > memory area. > So really when the X server exits, all buffers allocated by it need to go away, or at least get dereferenced, however if it has create memory managed areas these also need to go away... it should not be destroying memory manager areas. Dave. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master' - 2 commits
Dave Airlie wrote: > libdrm/xf86drm.c | 15 ++ > libdrm/xf86mm.h |1 > linux-core/drm_bo.c | 67 > +++--- > linux-core/drm_drv.c |2 + > linux-core/drm_objects.h |8 - > shared-core/drm.h |6 > shared-core/nouveau_mem.c |6 ++-- > 7 files changed, 90 insertions(+), 15 deletions(-) > > New commits: > commit d5c0101252e9f48ef1b59f48c05fea7007df97f0 > Author: Dave Airlie <[EMAIL PROTECTED]> > Date: Mon Feb 18 10:39:21 2008 +1000 > > ttm: make sure userspace can't destroy kernel create memory managers > > this adds something to say the kernel initialised the memory region not > the userspace. and blocks userspace from deallocating kernel areas > Dave, I guess this commit is a fix for the fact that the X server will try to evict fb scanout buffers when leaving VT. We've solved this issue so far by having the fb layer evict its scanouts when the X server starts before it goes on allocating its own buffers. This was done using device-private IOCTLS. While this is probably desirable to save GTT / VRAM space, I agree it's not desirable that the X server or master has the power to evict kernel buffers. What are your thoughts about this? It'd be good to have a common practice for upcoming drivers. Do we need a mechanism for the X server to clean out it's own buffers and the DRI client buffers, or should we just leave them where they are? If we want to implement something like that we might have drm_bo_clean_mm leave bo_kernel buffers alone instead of the whole memory area. /Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: drm: Branch 'master'
>-Original Message- >From: Jesse Barnes [mailto:[EMAIL PROTECTED] >Sent: 2008年3月4日 3:20 >To: dri-devel@lists.sourceforge.net >Cc: Nan hai Zou >Subject: Re: drm: Branch 'master' > >On Sunday, March 02, 2008 10:17 pm Nan hai Zou wrote: >> shared-core/i915_irq.c |7 +++ >> 1 file changed, 7 insertions(+) >> >> New commits: >> commit 63fd6f284ddd1096d34b39941683ae244c1e01fc >> Author: Zou Nan hai <[EMAIL PROTECTED]> >> Date: Mon Mar 3 14:49:49 2008 +0800 >> >> [i915] 2D driver may reset Frame count value, this may lead driver >> to leap it's vblank count a huge value. >> This will stall some applications that switch video mode if >> vblank_mode is set to a non zero value in drirc. > >Nanhai, have you seen this bug in practice? The new code has an ioctl >intended to be used in this case (see the pre- and post- mode set functions), >but the 2d driver isn't using it yet... > >Jesse Yes, actually you may set vblank_mode to 1 or 2 in drirc. Then play games like quake4 demo. You will see the application stop at the first few frames. Thanks Zou Nan hai - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Sunday, March 02, 2008 10:17 pm Nan hai Zou wrote: > shared-core/i915_irq.c |7 +++ > 1 file changed, 7 insertions(+) > > New commits: > commit 63fd6f284ddd1096d34b39941683ae244c1e01fc > Author: Zou Nan hai <[EMAIL PROTECTED]> > Date: Mon Mar 3 14:49:49 2008 +0800 > > [i915] 2D driver may reset Frame count value, this may lead driver > to leap it's vblank count a huge value. > This will stall some applications that switch video mode if > vblank_mode is set to a non zero value in drirc. Nanhai, have you seen this bug in practice? The new code has an ioctl intended to be used in this case (see the pre- and post- mode set functions), but the 2d driver isn't using it yet... Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Wed, 2008-02-27 at 21:55 +0100, Thomas Hellström wrote: > Eric Anholt wrote: > > On Wed, 2008-02-27 at 20:41 +0100, Thomas Hellström wrote: > > > >> Eric Anholt wrote: > >> > >>> On Wed, 2008-02-27 at 10:49 -0800, Thomas Hellstrom wrote: > >>> > >>> > shared-core/i915_dma.c | 13 + > 1 file changed, 9 insertions(+), 4 deletions(-) > > New commits: > commit 72983ff30183745cd96760aa07b857c44daebde7 > Author: Thomas Hellstrom > Date: Wed Feb 27 19:46:28 2008 +0100 > > Don't wait for buffer idle before applying relocations. > > diff --git a/shared-core/i915_dma.c b/shared-core/i915_dma.c > index b916441..2d26fcc 100644 > --- a/shared-core/i915_dma.c > +++ b/shared-core/i915_dma.c > @@ -860,6 +860,15 @@ int i915_apply_reloc(struct drm_file *file_priv, > int num_buffers, > drm_bo_kunmap(&relocatee->kmap); > relocatee->data_page = NULL; > relocatee->offset = new_cmd_offset; > + > +/* > + * Note on buffer idle: > + * Since we're applying relocations, this part of the > + * buffer is obviously not used by the GPU and we don't > + * need to wait for buffer idle. This is an important > + * consideration for user-space buffer pools. > + */ > + > > > >>> I don't understand this comment. What would have ensured that this part > >>> of the buffer is not used by the GPU if you've removed the syncing that > >>> the DRM does when applying relocations? > >>> > >>> > >> Hmm, > >> I'd say user-space would've idled the buffers when they were written to > >> and the relocations were created. > >> But I guess you can use relocations to just patch state buffers up > >> without mapping them from user-space. Are you doing that for i965? In > >> that case I'll immediately revert to the original code. > >> > > > > User space *can't* idle the buffers, because it doesn't know if the > > kernel will need to write an updated relocation for buffer location > > moving or not. Only the kernel has that knowledge, unless you want to > > just fail out to userland when any buffer has moved. That sounds like > > minimal fun. > > > OK, I was assuming that anyone submitting a relocation would actually > have mapped the buffer when doing that, causing an implicit idle. I > guess this breaks i965. Nope. The usage model for state buffers is that we create a state buffer for a unique set of state (hardware state plus buffer objects to be referenced by that hardware state), then we reuse that over and over without ever mapping it again from userland[1]. The trick is that the referenced buffers may get moved by the kernel, so we associate these relocations with them when handing them to the kernel, and the kernel does the fixups as necessary (which is rather rare, once we did the presumed offset change). Note that the state hash key data is pointers to referenced buffer objects, not offsets of referenced buffer objects (wouldn't work as you can imagine some new buffer of the same class but different contents getting migrated in at the same offset as a different old one). We thought about trying to achieve truly static state buffers, but it sounded bad. If we did use buffer pointers plus buffer offsets in the keys so we never had to rewrite relocations again, it would mean that when the kernel did have to move something, we'd have to exit all the way out from the kernel, create a new buffer referencing the new offset, and recalculate our state into it. That sounded worse than the current plan. In particular, the case of creating a new set of state several levels deep results in: exec with relocation A -> B, B -> C kernel migrates C in exit from kernel userland creates new B' pointing at C exec with relocation A -> B' -> C kernel migrates B' in exit from kernel userland creates A' pointing at B' exec with relocation A' -> B' -> C kernel migrates A' in and you finally win. Winning somehow feels like losing. It would mean that for any chance at performance you'd have to pre-validate C when creating B, and B when creating A. And when a buffer like C gets migrated, presumably you would want to throw out B, and the A that points at B, since you're going to have to redo them anyway and otherwise they'll pollute your state cache and waste memory. Also, experiments with trying to do prevalidation with drmBOSetStatus to avoid kernel relocations on new buffers were generally unpleasant. So I'm pretty sure we've made the right design decision with having our buffers be static except in the case of migration of relocation targets, with that relocation update handled by the kernel. [1] OK, there's an exception to this that we do to avoid kernel relocations in one ca
Re: drm: Branch 'master'
Eric Anholt wrote: > On Wed, 2008-02-27 at 20:41 +0100, Thomas Hellström wrote: > >> Eric Anholt wrote: >> >>> On Wed, 2008-02-27 at 10:49 -0800, Thomas Hellstrom wrote: >>> >>> shared-core/i915_dma.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) New commits: commit 72983ff30183745cd96760aa07b857c44daebde7 Author: Thomas Hellstrom Date: Wed Feb 27 19:46:28 2008 +0100 Don't wait for buffer idle before applying relocations. diff --git a/shared-core/i915_dma.c b/shared-core/i915_dma.c index b916441..2d26fcc 100644 --- a/shared-core/i915_dma.c +++ b/shared-core/i915_dma.c @@ -860,6 +860,15 @@ int i915_apply_reloc(struct drm_file *file_priv, int num_buffers, drm_bo_kunmap(&relocatee->kmap); relocatee->data_page = NULL; relocatee->offset = new_cmd_offset; + + /* + * Note on buffer idle: + * Since we're applying relocations, this part of the + * buffer is obviously not used by the GPU and we don't + * need to wait for buffer idle. This is an important + * consideration for user-space buffer pools. + */ + >>> I don't understand this comment. What would have ensured that this part >>> of the buffer is not used by the GPU if you've removed the syncing that >>> the DRM does when applying relocations? >>> >>> >> Hmm, >> I'd say user-space would've idled the buffers when they were written to >> and the relocations were created. >> But I guess you can use relocations to just patch state buffers up >> without mapping them from user-space. Are you doing that for i965? In >> that case I'll immediately revert to the original code. >> > > User space *can't* idle the buffers, because it doesn't know if the > kernel will need to write an updated relocation for buffer location > moving or not. Only the kernel has that knowledge, unless you want to > just fail out to userland when any buffer has moved. That sounds like > minimal fun. > OK, I was assuming that anyone submitting a relocation would actually have mapped the buffer when doing that, causing an implicit idle. I guess this breaks i965. I've pushed a fix. /Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Wed, 2008-02-27 at 20:41 +0100, Thomas Hellström wrote: > Eric Anholt wrote: > > On Wed, 2008-02-27 at 10:49 -0800, Thomas Hellstrom wrote: > > > >> shared-core/i915_dma.c | 13 + > >> 1 file changed, 9 insertions(+), 4 deletions(-) > >> > >> New commits: > >> commit 72983ff30183745cd96760aa07b857c44daebde7 > >> Author: Thomas Hellstrom > >> Date: Wed Feb 27 19:46:28 2008 +0100 > >> > >> Don't wait for buffer idle before applying relocations. > >> > >> diff --git a/shared-core/i915_dma.c b/shared-core/i915_dma.c > >> index b916441..2d26fcc 100644 > >> --- a/shared-core/i915_dma.c > >> +++ b/shared-core/i915_dma.c > >> @@ -860,6 +860,15 @@ int i915_apply_reloc(struct drm_file *file_priv, int > >> num_buffers, > >>drm_bo_kunmap(&relocatee->kmap); > >>relocatee->data_page = NULL; > >>relocatee->offset = new_cmd_offset; > >> + > >> + /* > >> + * Note on buffer idle: > >> + * Since we're applying relocations, this part of the > >> + * buffer is obviously not used by the GPU and we don't > >> + * need to wait for buffer idle. This is an important > >> + * consideration for user-space buffer pools. > >> + */ > >> + > >> > > > > I don't understand this comment. What would have ensured that this part > > of the buffer is not used by the GPU if you've removed the syncing that > > the DRM does when applying relocations? > > > Hmm, > I'd say user-space would've idled the buffers when they were written to > and the relocations were created. > But I guess you can use relocations to just patch state buffers up > without mapping them from user-space. Are you doing that for i965? In > that case I'll immediately revert to the original code. User space *can't* idle the buffers, because it doesn't know if the kernel will need to write an updated relocation for buffer location moving or not. Only the kernel has that knowledge, unless you want to just fail out to userland when any buffer has moved. That sounds like minimal fun. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
Eric Anholt wrote: > On Wed, 2008-02-27 at 10:49 -0800, Thomas Hellstrom wrote: > >> shared-core/i915_dma.c | 13 + >> 1 file changed, 9 insertions(+), 4 deletions(-) >> >> New commits: >> commit 72983ff30183745cd96760aa07b857c44daebde7 >> Author: Thomas Hellstrom >> Date: Wed Feb 27 19:46:28 2008 +0100 >> >> Don't wait for buffer idle before applying relocations. >> >> diff --git a/shared-core/i915_dma.c b/shared-core/i915_dma.c >> index b916441..2d26fcc 100644 >> --- a/shared-core/i915_dma.c >> +++ b/shared-core/i915_dma.c >> @@ -860,6 +860,15 @@ int i915_apply_reloc(struct drm_file *file_priv, int >> num_buffers, >> drm_bo_kunmap(&relocatee->kmap); >> relocatee->data_page = NULL; >> relocatee->offset = new_cmd_offset; >> + >> +/* >> + * Note on buffer idle: >> + * Since we're applying relocations, this part of the >> + * buffer is obviously not used by the GPU and we don't >> + * need to wait for buffer idle. This is an important >> + * consideration for user-space buffer pools. >> + */ >> + >> > > I don't understand this comment. What would have ensured that this part > of the buffer is not used by the GPU if you've removed the syncing that > the DRM does when applying relocations? > Hmm, I'd say user-space would've idled the buffers when they were written to and the relocations were created. But I guess you can use relocations to just patch state buffers up without mapping them from user-space. Are you doing that for i965? In that case I'll immediately revert to the original code. /Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Wed, 2008-02-27 at 10:49 -0800, Thomas Hellstrom wrote:
> shared-core/i915_dma.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> New commits:
> commit 72983ff30183745cd96760aa07b857c44daebde7
> Author: Thomas Hellstrom
> Date: Wed Feb 27 19:46:28 2008 +0100
>
> Don't wait for buffer idle before applying relocations.
>
> diff --git a/shared-core/i915_dma.c b/shared-core/i915_dma.c
> index b916441..2d26fcc 100644
> --- a/shared-core/i915_dma.c
> +++ b/shared-core/i915_dma.c
> @@ -860,6 +860,15 @@ int i915_apply_reloc(struct drm_file *file_priv, int
> num_buffers,
> drm_bo_kunmap(&relocatee->kmap);
> relocatee->data_page = NULL;
> relocatee->offset = new_cmd_offset;
> +
> + /*
> + * Note on buffer idle:
> + * Since we're applying relocations, this part of the
> + * buffer is obviously not used by the GPU and we don't
> + * need to wait for buffer idle. This is an important
> + * consideration for user-space buffer pools.
> + */
> +
I don't understand this comment. What would have ensured that this part
of the buffer is not used by the GPU if you've removed the syncing that
the DRM does when applying relocations?
> ret = drm_bo_kmap(relocatee->buf, new_cmd_offset >> PAGE_SHIFT,
> 1, &relocatee->kmap);
> if (ret) {
> @@ -1003,10 +1012,6 @@ static int i915_exec_reloc(struct drm_file *file_priv,
> drm_handle_t buf_handle,
> }
>
> mutex_lock (&relocatee.buf->mutex);
> - ret = drm_bo_wait (relocatee.buf, 0, 0, FALSE);
> - if (ret)
> - goto out_err1;
> -
> while (reloc_user_ptr) {
> ret = i915_process_relocs(file_priv, buf_handle,
> &reloc_user_ptr, &relocatee, buffers, buf_count);
> if (ret) {
--
Eric Anholt [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Tuesday, October 23, 2007 12:54 am Dave Airlie wrote:
> shared-core/i915_dma.c |3 +++
> 1 file changed, 3 insertions(+)
>
> New commits:
> commit a294aa724a1e932fb6017383e08532bfcc914df0
> Author: Dave Airlie <[EMAIL PROTECTED]>
> Date: Tue Oct 23 17:54:07 2007 +1000
>
> i915: require mfence before submitting batchbuffer
>
> diff --git a/shared-core/i915_dma.c b/shared-core/i915_dma.c
> index d0d65f8..f0fd603 100644
> --- a/shared-core/i915_dma.c
> +++ b/shared-core/i915_dma.c
> @@ -1044,6 +1044,9 @@ static int i915_execbuffer(struct drm_device
> *dev, void *data, if (ret)
> goto out_free;
>
> + /* make sure all previous memory operations have passed */
> + asm volatile("mfence":::"memory");
> +
Mabye use mb() here instead?
Also, is this ordering UC or WC writes against the DMA read from the
device? Maybe the comment should read "make sure prior stores are
visible to the device before we submit the buffer", assuming that's
what's going on...
Jesse
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM_READ/WRITE* vs. byte swapping (Re: drm: Branch 'master')
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michel Dänzer wrote:
> On Wed, 2007-10-03 at 14:08 -0700, Ian Romanick wrote:
>> diff --git a/linux-core/xgi_cmdlist.c b/linux-core/xgi_cmdlist.c
>> index 261f4e1..35f7e1b 100644
>> --- a/linux-core/xgi_cmdlist.c
>> +++ b/linux-core/xgi_cmdlist.c
>> @@ -45,7 +45,7 @@ static inline void dwWriteReg(struct drm
>> DRM_INFO("mmio_map->handle = 0x%p, addr = 0x%x, data = 0x%x\n",
>> map->handle, addr, data);
>> #endif
>> -DRM_WRITE32(map, addr, data);
>> +DRM_WRITE32(map, addr, cpu_to_le32(data));
>
> These look odd - DRM_READ/WRITE* already swap bytes. Does the device's
> MMIO aperture swap bytes on its own? If so, and you can't or don't want
> to disable that, maybe we need new macros using __raw_read/write* on
> Linux.
Hmm...I didn't realize that those functions had a built-in byte-swap.
I'm having some issues getting XP10 working properly on PPC, and a
liberal sprinkling of cpu_to_le32 and le32_to_cpu made things "better."
I'll continue investigating.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHCmMPX1gOwKyEAw8RApB/AKCa0BacjZSD7eynwgOVAfI4Gz/YGwCeJqc/
aUEPIxI064kjOqjHyTw+3eM=
=zxPL
-END PGP SIGNATURE-
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM_READ/WRITE* vs. byte swapping (Re: drm: Branch 'master')
On Wed, 2007-10-03 at 14:08 -0700, Ian Romanick wrote:
>
> diff --git a/linux-core/xgi_cmdlist.c b/linux-core/xgi_cmdlist.c
> index 261f4e1..35f7e1b 100644
> --- a/linux-core/xgi_cmdlist.c
> +++ b/linux-core/xgi_cmdlist.c
> @@ -45,7 +45,7 @@ static inline void dwWriteReg(struct drm
> DRM_INFO("mmio_map->handle = 0x%p, addr = 0x%x, data = 0x%x\n",
>map->handle, addr, data);
> #endif
> - DRM_WRITE32(map, addr, data);
> + DRM_WRITE32(map, addr, cpu_to_le32(data));
These look odd - DRM_READ/WRITE* already swap bytes. Does the device's
MMIO aperture swap bytes on its own? If so, and you can't or don't want
to disable that, maybe we need new macros using __raw_read/write* on
Linux.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master' - 11 commits
Eric Anholt wrote: >On Sat, 2007-09-29 at 00:24 +0200, Thomas Hellström wrote: > > >>Eric Anholt wrote: >> >> >> >>>On Fri, 2007-09-28 at 12:10 +0200, Thomas Hellström wrote: >>> >>> >>> >>> Eric Anholt wrote: >libdrm/xf86drm.c | 26 >libdrm/xf86mm.h |1 >linux-core/Makefile |1 >linux-core/drm_bo.c | 249 >--- >linux-core/drm_drv.c |3 >linux-core/drm_ioctl.c | 25 ++-- >linux-core/drm_objects.h |3 >shared-core/drm.h| 29 +++-- >8 files changed, 254 insertions(+), 83 deletions(-) > >New commits: >diff-tree 24e33627c5dfb92324a9faf1c7d366e7f33e622a (from parents) >Merge: 7587e9682c1b70930c015915d588b42ccd00c7c4 >e7bfeb3031374653f7e55d67cc1b5c823849359f >Author: Eric Anholt <[EMAIL PROTECTED]> >Date: Fri Sep 21 17:05:21 2007 -0700 > > Merge branch 'bo-set-pin' > > This branch replaces the NO_MOVE/NO_EVICT flags to buffer validation > with a > separate privileged ioctl to pin buffers like NO_EVICT meant before. > The > functionality that was supposed to be covered by NO_MOVE may be > reintroduced > later, possibly in a different way, after the superioctl branch is > merged. > > > > > Eric, I'm a bit curious about this commit. At XDS there were some wishes to a) Get rid of the memory specification flag at buffer object creation. b) Get rid of the validate call altogether, forcing non-root clients to use the superioctl. Then with the current set pin interface we have no way to specify where we want to pin the buffers, So either we need to specify this in the set pin interface or perhaps keep a validate interface with a mandatory "Don't fence", just to set the buffer flags, but then there's no real need for the set_pin interface. Another functionality we need to keep is to move out the scanout buffers before releasing them on VT switch, so that we don't fragment memory. That's currently done by >>>On VT switch everything gets kicked out. The X Server unpins the buffer >>>itself. I'm not seeing the issue there. >>> >>> >>> >>> >>Hmm, you're right. VT was a bad example. >>Releasing and reallocating a buffer on an xrandr event is a better one, >>where we need to issue the sequence below. >> >> > >RandR FB resize is just: >disable crtcs scanning from buffer >allocate new buffer >unpin old buffer >copy operation from old to new >pin new >turn on crtcs pointing to new. > > > But the point is you want to avoid fragmentation of the aperture / VRAM by unpin and move out the old buffer before allocating the new one. Something that's possible with the validate interface, but unless we add the buffer flags to the setpin interface, that possibility is gone. /Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master' - 11 commits
On Sat, 2007-09-29 at 00:24 +0200, Thomas Hellström wrote: > Eric Anholt wrote: > > >On Fri, 2007-09-28 at 12:10 +0200, Thomas Hellström wrote: > > > > > >>Eric Anholt wrote: > >> > >> > >>> libdrm/xf86drm.c | 26 > >>> libdrm/xf86mm.h |1 > >>> linux-core/Makefile |1 > >>> linux-core/drm_bo.c | 249 > >>> --- > >>> linux-core/drm_drv.c |3 > >>> linux-core/drm_ioctl.c | 25 ++-- > >>> linux-core/drm_objects.h |3 > >>> shared-core/drm.h| 29 +++-- > >>> 8 files changed, 254 insertions(+), 83 deletions(-) > >>> > >>>New commits: > >>>diff-tree 24e33627c5dfb92324a9faf1c7d366e7f33e622a (from parents) > >>>Merge: 7587e9682c1b70930c015915d588b42ccd00c7c4 > >>>e7bfeb3031374653f7e55d67cc1b5c823849359f > >>>Author: Eric Anholt <[EMAIL PROTECTED]> > >>>Date: Fri Sep 21 17:05:21 2007 -0700 > >>> > >>>Merge branch 'bo-set-pin' > >>> > >>>This branch replaces the NO_MOVE/NO_EVICT flags to buffer validation > >>> with a > >>>separate privileged ioctl to pin buffers like NO_EVICT meant before. > >>> The > >>>functionality that was supposed to be covered by NO_MOVE may be > >>> reintroduced > >>>later, possibly in a different way, after the superioctl branch is > >>> merged. > >>> > >>> > >>> > >>Eric, > >> > >>I'm a bit curious about this commit. > >>At XDS there were some wishes to > >> > >>a) Get rid of the memory specification flag at buffer object creation. > >>b) Get rid of the validate call altogether, forcing non-root clients to > >>use the superioctl. > >> > >>Then with the current set pin interface we have no way to specify where > >>we want to pin the buffers, > >> > >>So either we need to specify this in the set pin interface or perhaps > >>keep a validate interface with a mandatory > >>"Don't fence", just to set the buffer flags, but then there's no real > >>need for the set_pin interface. > >> > >>Another functionality we need to keep is to move out the scanout buffers > >>before releasing them on VT switch, > >>so that we don't fragment memory. That's currently done by > >> > >> > > > >On VT switch everything gets kicked out. The X Server unpins the buffer > >itself. I'm not seeing the issue there. > > > > > Hmm, you're right. VT was a bad example. > Releasing and reallocating a buffer on an xrandr event is a better one, > where we need to issue the sequence below. RandR FB resize is just: disable crtcs scanning from buffer allocate new buffer unpin old buffer copy operation from old to new pin new turn on crtcs pointing to new. You've got to blank the screen anyway if you're changing mode, so disabling it around the copy is just fine. The only case not covered is extending the FB to put a new crtc to the side/above/below and not flickering the currently-enabled CRTC. If you wanted to attempt that you just try setting up two pinned buffers at the same time, doing the copy, pageflipping between them, and then doing another series of the same if you want to optimize memory layout afterwards, and falling back to the above if you can't manage it. But this doesn't seem like a very useful effort currently, since it doesn't deal with the fact that you've got ugly intermediate states being shown anyway as your desktop environment tries to re-fit itself to the bigger FB. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master' - 11 commits
Eric Anholt wrote: >On Fri, 2007-09-28 at 12:10 +0200, Thomas Hellström wrote: > > >>Eric Anholt wrote: >> >> >>> libdrm/xf86drm.c | 26 >>> libdrm/xf86mm.h |1 >>> linux-core/Makefile |1 >>> linux-core/drm_bo.c | 249 >>> --- >>> linux-core/drm_drv.c |3 >>> linux-core/drm_ioctl.c | 25 ++-- >>> linux-core/drm_objects.h |3 >>> shared-core/drm.h| 29 +++-- >>> 8 files changed, 254 insertions(+), 83 deletions(-) >>> >>>New commits: >>>diff-tree 24e33627c5dfb92324a9faf1c7d366e7f33e622a (from parents) >>>Merge: 7587e9682c1b70930c015915d588b42ccd00c7c4 >>>e7bfeb3031374653f7e55d67cc1b5c823849359f >>>Author: Eric Anholt <[EMAIL PROTECTED]> >>>Date: Fri Sep 21 17:05:21 2007 -0700 >>> >>>Merge branch 'bo-set-pin' >>> >>>This branch replaces the NO_MOVE/NO_EVICT flags to buffer validation >>> with a >>>separate privileged ioctl to pin buffers like NO_EVICT meant before. The >>>functionality that was supposed to be covered by NO_MOVE may be >>> reintroduced >>>later, possibly in a different way, after the superioctl branch is >>> merged. >>> >>> >>> >>Eric, >> >>I'm a bit curious about this commit. >>At XDS there were some wishes to >> >>a) Get rid of the memory specification flag at buffer object creation. >>b) Get rid of the validate call altogether, forcing non-root clients to >>use the superioctl. >> >>Then with the current set pin interface we have no way to specify where >>we want to pin the buffers, >> >>So either we need to specify this in the set pin interface or perhaps >>keep a validate interface with a mandatory >>"Don't fence", just to set the buffer flags, but then there's no real >>need for the set_pin interface. >> >>Another functionality we need to keep is to move out the scanout buffers >>before releasing them on VT switch, >>so that we don't fragment memory. That's currently done by >> >> > >On VT switch everything gets kicked out. The X Server unpins the buffer >itself. I'm not seeing the issue there. > > Hmm, you're right. VT was a bad example. Releasing and reallocating a buffer on an xrandr event is a better one, where we need to issue the sequence below. >>drmBOValidate(xxx, DRM_BO_MEM_LOCAL , DRM_BO_HINT_DONT_FENCE); // Unpin >>and move out. >>drmBOUnreference(xxx) // Unreference. DRI clients need to unreference >>next time they take the lock. >> >>but basically we want to set some kind of zombie buffer state here, to >>be able to release the pinned pages. >>This functionality also basically need a validate / whatever we name it >>functionality left in there. >> >>So, what are your plans for this? >> >> > >Chatting with airlied, he suggested that I commit the code as is to get >i915-unification landed so that his superioctl and my 965 work could go >forward based on that. The plan is to remove the create memory type >flag, and possibly dd one to bo_set_pin, at a later date. > > > OK. I guess I'd like to see the setPin functionality being more or less like validate is today with the additional restrictions that it is root-only and doesn't put anything on the unfenced list. I'd like to be able to specify memory types and also pinned and possibly "zombie" state. will that work OK with your current work? /Thomas > > >- >This SF.net email is sponsored by: Microsoft >Defy all challenges. Microsoft(R) Visual Studio 2005. >http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > > > >-- >___ >Dri-devel mailing list >Dri-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/dri-devel > > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master' - 11 commits
On Fri, 2007-09-28 at 12:10 +0200, Thomas Hellström wrote: > Eric Anholt wrote: > > libdrm/xf86drm.c | 26 > > libdrm/xf86mm.h |1 > > linux-core/Makefile |1 > > linux-core/drm_bo.c | 249 > > --- > > linux-core/drm_drv.c |3 > > linux-core/drm_ioctl.c | 25 ++-- > > linux-core/drm_objects.h |3 > > shared-core/drm.h| 29 +++-- > > 8 files changed, 254 insertions(+), 83 deletions(-) > > > > New commits: > > diff-tree 24e33627c5dfb92324a9faf1c7d366e7f33e622a (from parents) > > Merge: 7587e9682c1b70930c015915d588b42ccd00c7c4 > > e7bfeb3031374653f7e55d67cc1b5c823849359f > > Author: Eric Anholt <[EMAIL PROTECTED]> > > Date: Fri Sep 21 17:05:21 2007 -0700 > > > > Merge branch 'bo-set-pin' > > > > This branch replaces the NO_MOVE/NO_EVICT flags to buffer validation > > with a > > separate privileged ioctl to pin buffers like NO_EVICT meant before. > > The > > functionality that was supposed to be covered by NO_MOVE may be > > reintroduced > > later, possibly in a different way, after the superioctl branch is > > merged. > > > Eric, > > I'm a bit curious about this commit. > At XDS there were some wishes to > > a) Get rid of the memory specification flag at buffer object creation. > b) Get rid of the validate call altogether, forcing non-root clients to > use the superioctl. > > Then with the current set pin interface we have no way to specify where > we want to pin the buffers, > > So either we need to specify this in the set pin interface or perhaps > keep a validate interface with a mandatory > "Don't fence", just to set the buffer flags, but then there's no real > need for the set_pin interface. > > Another functionality we need to keep is to move out the scanout buffers > before releasing them on VT switch, > so that we don't fragment memory. That's currently done by On VT switch everything gets kicked out. The X Server unpins the buffer itself. I'm not seeing the issue there. > drmBOValidate(xxx, DRM_BO_MEM_LOCAL , DRM_BO_HINT_DONT_FENCE); // Unpin > and move out. > drmBOUnreference(xxx) // Unreference. DRI clients need to unreference > next time they take the lock. > > but basically we want to set some kind of zombie buffer state here, to > be able to release the pinned pages. > This functionality also basically need a validate / whatever we name it > functionality left in there. > > So, what are your plans for this? Chatting with airlied, he suggested that I commit the code as is to get i915-unification landed so that his superioctl and my 965 work could go forward based on that. The plan is to remove the create memory type flag, and possibly dd one to bo_set_pin, at a later date. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master' - 11 commits
Eric Anholt wrote: > libdrm/xf86drm.c | 26 > libdrm/xf86mm.h |1 > linux-core/Makefile |1 > linux-core/drm_bo.c | 249 > --- > linux-core/drm_drv.c |3 > linux-core/drm_ioctl.c | 25 ++-- > linux-core/drm_objects.h |3 > shared-core/drm.h| 29 +++-- > 8 files changed, 254 insertions(+), 83 deletions(-) > > New commits: > diff-tree 24e33627c5dfb92324a9faf1c7d366e7f33e622a (from parents) > Merge: 7587e9682c1b70930c015915d588b42ccd00c7c4 > e7bfeb3031374653f7e55d67cc1b5c823849359f > Author: Eric Anholt <[EMAIL PROTECTED]> > Date: Fri Sep 21 17:05:21 2007 -0700 > > Merge branch 'bo-set-pin' > > This branch replaces the NO_MOVE/NO_EVICT flags to buffer validation with > a > separate privileged ioctl to pin buffers like NO_EVICT meant before. The > functionality that was supposed to be covered by NO_MOVE may be > reintroduced > later, possibly in a different way, after the superioctl branch is merged. > Eric, I'm a bit curious about this commit. At XDS there were some wishes to a) Get rid of the memory specification flag at buffer object creation. b) Get rid of the validate call altogether, forcing non-root clients to use the superioctl. Then with the current set pin interface we have no way to specify where we want to pin the buffers, So either we need to specify this in the set pin interface or perhaps keep a validate interface with a mandatory "Don't fence", just to set the buffer flags, but then there's no real need for the set_pin interface. Another functionality we need to keep is to move out the scanout buffers before releasing them on VT switch, so that we don't fragment memory. That's currently done by drmBOValidate(xxx, DRM_BO_MEM_LOCAL , DRM_BO_HINT_DONT_FENCE); // Unpin and move out. drmBOUnreference(xxx) // Unreference. DRI clients need to unreference next time they take the lock. but basically we want to set some kind of zombie buffer state here, to be able to release the pinned pages. This functionality also basically need a validate / whatever we name it functionality left in there. So, what are your plans for this? /Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
Alan Hourihane írta:
> On Wed, 2007-09-26 at 15:43 +0100, Keith Whitwell wrote:
>
>> Alan Hourihane wrote:
>>
>>> linux-core/drm_drv.c |2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> New commits:
>>> diff-tree 6671ad1917698b6174a1af314b63b3800d75248c (from
>>> 03c47f1420bf17a1e0f2b86be500656ae5a4c95b)
>>> Author: Alan Hourihane <[EMAIL PROTECTED]>
>>> Date: Wed Sep 26 15:38:54 2007 +0100
>>>
>>> don't copy back if an error was returned.
>>>
>>> diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
>>> index cedb6d5..8513a28 100644
>>> --- a/linux-core/drm_drv.c
>>> +++ b/linux-core/drm_drv.c
>>> @@ -645,7 +645,7 @@ long drm_unlocked_ioctl(struct file *fil
>>> retcode = func(dev, kdata, file_priv);
>>> }
>>>
>>> - if (cmd & IOC_OUT) {
>>> + if ((retcode == 0) && cmd & IOC_OUT) {
>>>
>> Hmm, brackets around the == but not around the & ??
>>
>> Could you humour me and change that to something like:
>>
>> if (retcode == 0 && (cmd & IOC_OUT)) {
>>
>
> Sure. should of caught that.
>
It's "should've". You should have caught that as well. :-)
> Alan.
>
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Wed, 2007-09-26 at 15:43 +0100, Keith Whitwell wrote:
> Alan Hourihane wrote:
> > linux-core/drm_drv.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > New commits:
> > diff-tree 6671ad1917698b6174a1af314b63b3800d75248c (from
> > 03c47f1420bf17a1e0f2b86be500656ae5a4c95b)
> > Author: Alan Hourihane <[EMAIL PROTECTED]>
> > Date: Wed Sep 26 15:38:54 2007 +0100
> >
> > don't copy back if an error was returned.
> >
> > diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
> > index cedb6d5..8513a28 100644
> > --- a/linux-core/drm_drv.c
> > +++ b/linux-core/drm_drv.c
> > @@ -645,7 +645,7 @@ long drm_unlocked_ioctl(struct file *fil
> > retcode = func(dev, kdata, file_priv);
> > }
> >
> > - if (cmd & IOC_OUT) {
> > + if ((retcode == 0) && cmd & IOC_OUT) {
>
> Hmm, brackets around the == but not around the & ??
>
> Could you humour me and change that to something like:
>
> if (retcode == 0 && (cmd & IOC_OUT)) {
Sure. should of caught that.
Alan.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
Alan Hourihane wrote:
> linux-core/drm_drv.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> New commits:
> diff-tree 6671ad1917698b6174a1af314b63b3800d75248c (from
> 03c47f1420bf17a1e0f2b86be500656ae5a4c95b)
> Author: Alan Hourihane <[EMAIL PROTECTED]>
> Date: Wed Sep 26 15:38:54 2007 +0100
>
> don't copy back if an error was returned.
>
> diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
> index cedb6d5..8513a28 100644
> --- a/linux-core/drm_drv.c
> +++ b/linux-core/drm_drv.c
> @@ -645,7 +645,7 @@ long drm_unlocked_ioctl(struct file *fil
> retcode = func(dev, kdata, file_priv);
> }
>
> - if (cmd & IOC_OUT) {
> + if ((retcode == 0) && cmd & IOC_OUT) {
Hmm, brackets around the == but not around the & ??
Could you humour me and change that to something like:
if (retcode == 0 && (cmd & IOC_OUT)) {
Keith
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Mon, 2007-08-13 at 16:32 -0700, Eric Anholt wrote:
>*/
> - map->offset += dev->agp->base;
> + if (map->offset < dev->agp->base ||
> + map->offset > dev->agp->base +
> + dev->agp->agp_info.aper_size * 1024 * 1024) {
> + map->offset += dev->agp->base;
> + }
Looks like this will always add dev->agp->base if the aperture is at the
very end of the address space (dev->agp->base +
dev->agp->agp_info.aper_size * 1024 * 1024 wraps to 0). (Been there,
done that in the radeon driver...)
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Thu, 2007-01-25 at 14:06 -0800, Patrice Mandin wrote: > shared-core/nouveau_fifo.c | 48 > +++-- > 1 files changed, 21 insertions(+), 27 deletions(-) > > New commits: > diff-tree 6d9ef1a960a76410e816425d8a53fb96cf2b871d (from > 582637641abbadc75795ac7e0671e1a5e3b41880) > Author: Patrice Mandin <[EMAIL PROTECTED]> > Date: Thu Jan 25 23:06:48 2007 +0100 > > nouveau: simplify and fix BIG_ENDIAN flags > > diff --git a/shared-core/nouveau_fifo.c b/shared-core/nouveau_fifo.c > index e80ba76..b035ed0 100644 > --- a/shared-core/nouveau_fifo.c > +++ b/shared-core/nouveau_fifo.c > @@ -182,16 +182,15 @@ int nouveau_fifo_init(drm_device_t *dev) > NV_WRITE(NV_PFIFO_CACH1_DMAC, 0x); > NV_WRITE(NV_PFIFO_CACH1_DMAS, 0x); > NV_WRITE(NV_PFIFO_CACH1_ENG, 0x); > -#ifdef __BIG_ENDIAN > + > NV_WRITE(NV_PFIFO_CACH1_DMAF, NV_PFIFO_CACH1_DMAF_TRIG_112_BYTES | > NV_PFIFO_CACH1_DMAF_SIZE_128_BYTES | > NV_PFIFO_CACH1_DMAF_MAX_REQS_4 | > - NV_PFIFO_CACH1_BIG_ENDIAN); > -#else > - NV_WRITE(NV_PFIFO_CACH1_DMAF, NV_PFIFO_CACH1_DMAF_TRIG_112_BYTES | > - NV_PFIFO_CACH1_DMAF_SIZE_128_BYTES | > - NV_PFIFO_CACH1_DMAF_MAX_REQS_4); > -#endif > +#ifdef __BIG_ENDIAN Note that __BIG/LITTLE_ENDIAN on their own don't indicate the native byte order; e.g. on ppc they're both defined. You should probably use MESA_BIG_ENDIAN or _mesa_little_endian(). -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
>> 0x1002 0x4c42 0 "3D Rage LT Pro AGP-133" >> 0x1002 0x4c44 0 "3D Rage LT Pro AGP-66" >> +0x1002 0x4759 0 "Rage 3D IICATI 3D RAGE IIC AGP(A12/A13) > > The formatting looks really strange. > > Also Rage IIC doesn't have a setup engine so AFAIK it should not be > listed in the drm. The bug has been open for a while with no comments, and this in a Dell Poweredge and it claims AGP, so I thought maybe it does hve enogh juice.. the string idoesn't matter so much on linux, and is from the web.. Dave -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Thu, Sep 21, 2006 at 08:44:47PM -0700, Dave Airlie wrote: > shared-core/drm_pciids.txt |1 + > 1 files changed, 1 insertion(+) > > New commits: > diff-tree 255f3e6f76dfd267a14765dd1293229184298d89 (from > 1f71b8d7a456fe3ec4bfc2fed70b7420cdd0d55a) > Author: Anish Mistry <[EMAIL PROTECTED]> > Date: Fri Sep 22 03:43:34 2006 +1000 > > bug 7092 : add pci ids for mach64 in Dell poweredge 4200 > > diff --git a/shared-core/drm_pciids.txt b/shared-core/drm_pciids.txt > index 9e0c099..c597708 100644 > --- a/shared-core/drm_pciids.txt > +++ b/shared-core/drm_pciids.txt > @@ -186,6 +186,7 @@ > 0x1002 0x4c51 0 "3D Rage LT Pro" > 0x1002 0x4c42 0 "3D Rage LT Pro AGP-133" > 0x1002 0x4c44 0 "3D Rage LT Pro AGP-66" > +0x1002 0x4759 0 "Rage 3D IICATI 3D RAGE IIC AGP(A12/A13) The formatting looks really strange. Also Rage IIC doesn't have a setup engine so AFAIK it should not be listed in the drm. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Wed, 2006-07-19 at 13:37 -0700, Adam Jackson wrote: > > diff-tree af7b89d7246efbed7d05c38fcaa6a13c4b89db90 (from > d5e0f8bdaf8769642950b8219f0e80f6b523817d) > Author: Adam Jackson <[EMAIL PROTECTED]> > Date: Wed Jul 19 15:35:31 2006 -0400 > > Make sure busmastering gets disabled on module unload. > > diff --git a/shared-core/radeon_cp.c b/shared-core/radeon_cp.c > index 695b5ec..299ec6a 100644 > --- a/shared-core/radeon_cp.c > +++ b/shared-core/radeon_cp.c > @@ -1719,6 +1719,11 @@ static int radeon_do_cleanup_cp(drm_devi > dev_priv->gart_info.addr = 0; > } > } > + > + /* Disable busmastering */ > + RADEON_WRITE(RADEON_BUS_CNTL, RADEON_READ(RADEON_BUS_CNTL) | > + RADEON_BUS_MASTER_DIS); This oopses for me on X server shutdown. Does it really work on module unload? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
