Re: [SPAM] [PATCH 1/3] drm/radeon/kms: fence cleanup + more reliable GPU lockup detection V2
2010/3/1 :
> From: Jerome Glisse
>
> This patch cleanup the fence code, it drops the timeout field of
> fence as the time to complete each IB is unpredictable and shouldn't
> be bound.
>
> The fence cleanup lead to GPU lockup detection improvement, this
> patch introduce a callback, allowing to do asic specific test for
> lockup detection. In this patch the CP is use as a first indicator
> of GPU lockup. If CP doesn't make progress during 1second we assume
> we are facing a GPU lockup.
>
> To avoid overhead of testing GPU lockup frequently due to fence
> taking time to be signaled we query the lockup callback every
> 500msec. There is plenty code comment explaining the design & choise
> inside the code.
>
> This have been tested mostly on R3XX/R5XX hw, in normal running
> destkop (compiz firefox, quake3 running) the lockup callback wasn't
> call once (1 hour session). Also tested with forcing GPU lockup and
> lockup was reported after the 1s CP activity timeout.
>
> V2 switch to 500ms timeout so GPU lockup get call at least 2 times
> in less than 2sec.
>
> Signed-off-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/evergreen.c | 6 ++
> drivers/gpu/drm/radeon/r100.c | 84 +++
> drivers/gpu/drm/radeon/r300.c | 27 -
> drivers/gpu/drm/radeon/r600.c | 33 +-
> drivers/gpu/drm/radeon/radeon.h | 102 ++--
> drivers/gpu/drm/radeon/radeon_asic.h | 20 ++-
> drivers/gpu/drm/radeon/radeon_fence.c | 75 +---
> drivers/gpu/drm/radeon/rv770.c | 6 --
> 8 files changed, 248 insertions(+), 105 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index bd2e7aa..8988df7 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -490,6 +490,12 @@ int evergreen_mc_init(struct radeon_device *rdev)
> return 0;
> }
>
> +bool evergreen_gpu_is_lockup(struct radeon_device *rdev)
> +{
> + /* FIXME: implement for evergreen */
> + return false;
> +}
> +
> int evergreen_gpu_reset(struct radeon_device *rdev)
> {
> /* FIXME: implement for evergreen */
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index 91eb762..96a6370 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -1772,6 +1772,90 @@ int r100_rb2d_reset(struct radeon_device *rdev)
> return -1;
> }
>
> +void r100_gpu_lockup_update(struct r100_gpu_lockup *lockup, struct radeon_cp
> *cp)
> +{
> + lockup->last_cp_rptr = cp->rptr;
> + lockup->last_jiffies = jiffies;
> +}
> +
> +/**
> + * r100_gpu_cp_is_lockup() - check if CP is lockup by recording information
> + * @rdev: radeon device structure
> + * @lockup: r100_gpu_lockup structure holding CP lockup tracking
> informations
> + * @cp: radeon_cp structure holding CP information
> + *
> + * We don't need to initialize the lockup tracking information as we will
> either
> + * have CP rptr to a different value of jiffies wrap around which will force
> + * initialization of the lockup tracking informations.
> + *
> + * A possible false positivie is if we get call after while and last_cp_rptr
> ==
> + * the current CP rptr, even if it's unlikely it might happen. To avoid this
> + * if the elapsed time since last call is bigger than 2 second than we return
> + * false and update the tracking information. Due to this the caller must
> call
> + * r100_gpu_cp_is_lockup several time in less than 2sec for lockup to be
> reported
> + * the fencing code should be cautious about that.
> + *
> + * Caller should write to the ring to force CP to do something so we don't
> get
> + * false positive when CP is just gived nothing to do.
> + *
> + **/
> +bool r100_gpu_cp_is_lockup(struct radeon_device *rdev, struct
> r100_gpu_lockup *lockup, struct radeon_cp *cp)
> +{
> + unsigned long cjiffies, elapsed;
> +
> + cjiffies = jiffies;
> + if (!time_after(cjiffies, lockup->last_jiffies)) {
> + /* likely a wrap around */
> + lockup->last_jiffies = jiffies;
> + return false;
> + }
> + if (cp->rptr != lockup->last_cp_rptr) {
> + /* CP is still working no lockup */
> + lockup->last_cp_rptr = cp->rptr;
> + lockup->last_jiffies = jiffies;
> + return false;
> + }
> + elapsed = jiffies_to_msecs(cjiffies - lockup->last_jiffies);
> + if (elapsed >= 3000) {
> + /* very likely the improbable case where current
> + * rptr is equal to last recorded, a while ago, rptr
> + * this is more likely a false positive update tracking
> + * information which should force us to be recall at
> + * latter point
> + */
> + lockup->last_cp_rptr = cp->r
Re: [PATCH 3/6] libkms: Add nouveau support.
Hi Marcin,
I have some minor comments inlined below.
Best regards,
Erik
> +static int
> +nouveau_bo_create(struct kms_driver *kms,
> + const unsigned width, const unsigned height,
> + const enum kms_bo_type type, const unsigned *attr,
> + struct kms_bo **out)
> +{
> + struct drm_nouveau_gem_new arg;
> + unsigned size, pitch;
> + struct nouveau_bo *bo;
> + int i, ret;
> +
> + for (i = 0; attr[i]; i += 2) {
> + switch (attr[i]) {
> + case KMS_WIDTH:
> + case KMS_HEIGHT:
> + case KMS_BO_TYPE:
> + break;
> + default:
> + return -EINVAL;
> + }
> + }
> +
> + bo = calloc(1, sizeof(*bo));
> + if (!bo)
> + return -ENOMEM;
> +
> + if (type == KMS_BO_TYPE_CURSOR_64X64_ARGB) {
> + pitch = 64 * 4;
> + size = 64 * 64 * 4;
> + } else if (type == KMS_BO_TYPE_SCANOUT) {
> + pitch = width * 4;
> + pitch = (pitch + 512 - 1) & ~(512 - 1);
What is 512 derived from?
Would a #define explain this better?
> + size = pitch * height;
> + } else {
> + return -EINVAL;
> + }
> +
> + memset(&arg, 0, sizeof(arg));
> + arg.info.size = size;
> + arg.info.domain = NOUVEAU_GEM_DOMAIN_MAPPABLE |
> NOUVEAU_GEM_DOMAIN_VRAM;
> + arg.info.tile_mode = 0;
> + arg.info.tile_flags = 0;
> + arg.align = 512;
> + arg.channel_hint = 0;
> +
> + ret = drmCommandWriteRead(kms->fd, DRM_NOUVEAU_GEM_NEW, &arg,
> sizeof(arg));
> + if (ret)
> + goto err_free;
> +
> + bo->base.kms = kms;
> + bo->base.handle = arg.info.handle;
> + bo->base.size = size;
> + bo->base.pitch = pitch;
> + bo->map_handle = arg.info.map_handle;
> +
> + *out = &bo->base;
> +
> + return 0;
> +
> +err_free:
> + free(bo);
> + return ret;
> +}
> +
> +static int
> +nouveau_bo_get_prop(struct kms_bo *bo, unsigned key, unsigned *out)
> +{
> + switch (key) {
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int
> +nouveau_bo_map(struct kms_bo *_bo, void **out)
> +{
> + struct nouveau_bo *bo = (struct nouveau_bo *)_bo;
> + void *map = NULL;
> + int ret;
> +
ret is unused.
> + if (bo->base.ptr) {
> + bo->map_count++;
> + *out = bo->base.ptr;
> + return 0;
> + }
> +
> + map = mmap(0, bo->base.size, PROT_READ | PROT_WRITE, MAP_SHARED,
> bo->base.kms->fd, bo->map_handle);
> + if (map == MAP_FAILED)
> + return -errno;
> +
> + bo->base.ptr = map;
> + bo->map_count++;
> + *out = bo->base.ptr;
> +
> + return 0;
> +}
> +
> +static int
> +nouveau_bo_unmap(struct kms_bo *_bo)
> +{
> + struct nouveau_bo *bo = (struct nouveau_bo *)_bo;
> + bo->map_count--;
> + return 0;
> +}
> +
> +static int
> +nouveau_bo_destroy(struct kms_bo *_bo)
> +{
> + struct nouveau_bo *bo = (struct nouveau_bo *)_bo;
> + struct drm_gem_close arg;
> + int ret;
> +
> + if (bo->base.ptr) {
> + /* XXX Sanity check map_count */
> + munmap(bo->base.ptr, bo->base.size);
> + bo->base.ptr = NULL;
> + }
> +
> + memset(&arg, 0, sizeof(arg));
> + arg.handle = bo->base.handle;
> +
> + ret = drmIoctl(bo->base.kms->fd, DRM_IOCTL_GEM_CLOSE, &arg);
> + if (ret)
> + return -errno;
> +
> + free(bo);
> + return 0;
> +}
> +
> +int
> +nouveau_create(int fd, struct kms_driver **out)
> +{
> + struct kms_driver *kms;
> +
> + kms = calloc(1, sizeof(*kms));
> + if (!kms)
> + return -ENOMEM;
> +
> + kms->fd = fd;
> +
> + kms->bo_create = nouveau_bo_create;
> + kms->bo_map = nouveau_bo_map;
> + kms->bo_unmap = nouveau_bo_unmap;
> + kms->bo_get_prop = nouveau_bo_get_prop;
> + kms->bo_destroy = nouveau_bo_destroy;
> +// kms->get_prop = nouveau_get_prop;
> + kms->destroy = nouveau_destroy;
> + *out = kms;
> +
> + return 0;
> +}
> --
> 1.6.4.4
>
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourse
MTRR allocation failed on a 965GM system
Hi, When running drm-next tip on my 965GM system I get a message from the kernel log during bootup complaining that the MTRR allocation failed and that Graphics performance may suffer. Is this warning a real bug and if so what component and what bugtracker (kernel.org or freedesktop) should I file it against? Best regards, Erik -- 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: [Intel-gfx] Patch for testing irq spinning
2008/12/5 Tomas Carnecky <[EMAIL PROTECTED]>: [snip] > The irq storms seem to be gone. But I'm not sure if MSI is really > usable. When I let glxgears run, it freezes after a ~10-30 seconds, and > resumes normally after I move a window (doesn't have to be the glxgears > window, just one window on the desktop). Is that maybe a symptom of the > lost interrupts that the errata refers to (GM965 + MSI)? > This sounds like the same error I get when running my GM965 with framebuffer compression enabled. Regards, Erik -- 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: ATI Xpress 200M Northbridge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-François Bucas skrev: > Anybody knows where to look to find and help these "others" ? > What needs to be done ? I've read about some registers that would be > incorrects... > You should drop Phillip Ezolt a line, as he has been trying to debug the issue. You can reach him thru this list or [EMAIL PROTECTED] Regards Erik Andrén > Thanks > > [EMAIL PROTECTED] wrote: >> On 11/29/06, *simone.vianello86-at-tin.it >> <http://simone.vianello86-at-tin.it> simone.vianello86-at-tin.it >> <http://simone.vianello86-at-tin.it> |rivatv-devel|* < ... > >> wrote: >> >> Hello, somebody know when the support for this hardware is available? >> >> - >> 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 >> >> <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV> >> -- >> ___ >> Dri-devel mailing list >> Dri-devel@lists.sourceforge.net <mailto:Dri-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/dri-devel >> <https://lists.sourceforge.net/lists/listinfo/dri-devel> >> >> 2D support is already present. 3D support is just getting underway by >> some others, but it is not in a usable state so far as I know. >> >> >> >> >> - >> 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 > > - > 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 > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFbfkZN7qBt+4UG0ERAs2aAJ0Xq8iN4Ddqx7E0gOJhUHg3H7DbXgCeOINU dlVw/12V+giJXwUONkSx6qM= =TBrK -END PGP SIGNATURE- - 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
