[PULL] topic/core-stuff for 3.18

Hi Dave, So small drm stuff all over for 3.18. Biggest one is the cmdline parsing from Chris with a few fixes from me to make it work for stupid kernel configs. Plus the atomic prep series. Tested for more than a week in -nightly and Ville/Imre indeed discovered some fun which is now fixed (and

[PULL] first drm-intel-next for 3.18

Hi Dave, So you made noises that you wanted to open drm-next right after -rc1, so I've figured I'll test this ;-) drm-intel-next-2014-08-08: - Setting dp M2/N2 values plus state checker support (Vandana Kannan) - chv power well support (Ville) - DP training pattern 3 support for chv (Ville) -

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

> I'd rather not have a sysfs entry. I'd prefer a mesa env var or drirc > option to force the CS flag. Yeah, that actually sounds like a good idea. I think we could add a new dword to the flags chunk for this, or use the priority field which is unused for UVD on those older chipsets anyway. If

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

Am 15.08.2014 um 17:32 schrieb Grigori Goronzy: > On 15.08.2014 17:26, Alex Deucher wrote: >> On Fri, Aug 15, 2014 at 11:20 AM, Grigori Goronzy >> wrote: >>> On 15.08.2014 16:11, Christian K?nig wrote: Hi Marco, the problem with an CS ioctl flag is that we sometimes don't know how

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

gt; >>>> > (atomic_read(>rdev->uvd.handles[i]) > >>>> == handle) > >>>> { > >>>>

Fwd: Re: [PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

>> radeon_uvd_cs_msg(struct >>>>>> radeon_cs_parser >>>>>> *p, struct radeon_bo *bo, >>>>>> >>>>>>

[Bug 82671] New: [r600g-evergreen][compute]Empty kernel execution causes crash

... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/15c01a9c/attachment.html>

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

*/ >>>> @@ -428,6 +475,7 @@ static int >>>> radeon_uvd_cs_msg(struct >>>> radeon_cs_parser >>>> *p, struct radeon_bo *bo, >>>> if >>>> >>>> (!atomic_cmpxchg(>rdev->uvd.handles[i], >>>> 0, >>>> handle)) { >>>> >>>> p->rdev->uvd.filp[i] = p->filp; >>>> >>>> p->rdev->uvd.img_size[i] = img_size; >>>> + >>>> radeon_uvd_fps_clear_events(p->rdev, >>>> i); >>>> return 0; >>>> } >>>> } >>>> @@ -763,7 +811,7 @@ int >>>> radeon_uvd_get_destroy_msg(struct >>>> radeon_device >>>> *rdev, int ring, >>>> static void >>>> radeon_uvd_count_handles(struct >>>> radeon_device *rdev, >>>> >>>>unsigned *sd, unsigned *hd) >>>> { >>>> - unsigned i; >>>> + unsigned i, fps_rate = 0; >>>> >>>> *sd = 0; >>>> *hd = 0; >>>> @@ -772,10 +820,13 @@ static void >>>> radeon_uvd_count_handles(struct >>>> radeon_device *rdev, >>>> if >>>> (!atomic_read(>uvd.handles[i])) >>>> continue; >>>> >>>> - if >>>> (rdev->uvd.img_size[i] >= 720*576) >>>> - ++(*hd); >>>> - else >>>> - ++(*sd); >>>> + fps_rate = >>>> radeon_uvd_estimate_fps(rdev, i); >>>> + >>>> + if >>>> (rdev->uvd.img_size[i] >= 720*576) { >>>> + (*hd) += >>>> fps_rate > 30 ? 1 : 2; >>>> + } else { >>>> + (*sd) += >>>> fps_rate > 30 ? 1 : 2; >>>> + } >>>> } >>>> } >>>> >>>> @@ -805,6 +856,7 @@ void >>>> radeon_uvd_note_usage(struct >>>> radeon_device >>>> *rdev) >>>> set_clocks &= >>>> >>>> schedule_delayed_work(>uvd.idle_work, >>>> >>>> msecs_to_jiffies(UVD_IDLE_TIMEOUT_MS)); >>>> >>>> + >>>> if >>>> ((rdev->pm.pm_method == >>>> PM_METHOD_DPM) && >>>> rdev->pm.dpm_enabled) { >>>> unsigned hd = >>>> 0, sd = 0; >>>> >>>> radeon_uvd_count_handles(rdev, >>>> , ); >>>> -- >>>> 1.9.1 >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Marco Antonio Benatto >>>> Linux user ID:#506236 >>> >> >> -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/3d1aee40/attachment-0001.sig>

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

if >> (!atomic_read(>uvd.handles[i])) >> continue; >> >> - if >> (rdev->uvd.img_size[i] >= 720*576) >> - ++(*hd); >> - else >> - ++(*sd); >> + fps_rate = >> radeon_uvd_estimate_fps(rdev, i); >> + >> + if >> (rdev->uvd.img_size[i] >= 720*576) { >> + (*hd) += >> fps_rate > 30 ? 1 : 2; >> + } else { >> + (*sd) += >> fps_rate > 30 ? 1 : 2; >> + } >> } >> } >> >> @@ -805,6 +856,7 @@ void >> radeon_uvd_note_usage(struct >> radeon_device >> *rdev) >> set_clocks &= >> >> schedule_delayed_work(>uvd.idle_work, >> >> msecs_to_jiffies(UVD_IDLE_TIMEOUT_MS)); >> >> + >> if >> ((rdev->pm.pm_method == >> PM_METHOD_DPM) && >> rdev->pm.dpm_enabled) { >> unsigned hd = >> 0, sd = 0; >> >> radeon_uvd_count_handles(rdev, >> , ); >> -- >> 1.9.1 >> >> >> >> >> >> -- >> Marco Antonio Benatto >> Linux user ID:#506236 > -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/e12cfa06/attachment.sig>

[PATCH] drm/radeon: Always flush VM again on < CIK

Hey guys, I think I've figured out what the cause of the remaining issues is while working on the implicit sync stuff. The issue happens when the flush is done because of a CS to the DMA ring and a CS to the GFX ring directly after that which depends on the DMA submission to be finished. In

[Intel-gfx] [PATCH] drm: fix plane rotation when restoring fbdev configuration

On 15 August 2014 11:22, Daniel Vetter wrote: > On Fri, Aug 15, 2014 at 10:48:05AM +0100, Thomas Wood wrote: >> On 15 August 2014 10:42, Thomas Wood wrote: >> > On 14 August 2014 17:02, Daniel Vetter wrote: >> >> On Thu, Aug 14, 2014 at 04:33:18PM +0100, Thomas Wood wrote: >> >>> Make sure

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

+ (*hd) += > fps_rate > 30 ? 1 : 2; > + } else { > + (*sd) += > fps_rate > 30 ? 1 : 2; >

[Bug 82586] UBO matrix in std140 struct does not work

are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/014c7f9f/attachment.html>

[Bug 82586] UBO matrix in std140 struct does not work

d mesa yourself. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/f122bb9a/attachment-0001.html>

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

+ >>>>>>>>> + fps->timestamp = >>>>>>>>> jiffies_64; >>>>>>>>> + fps->event_index = 0; >>>>>>>>> + for (i = 0; i < >>>>>>>>> RADEON_UVD_FPS_EVENTS_MAX; >>>>>>>>> i++) >>>>>>>>> + >>>>>>>>> fps->events[i] = >>>>>>>>> 0; >>>>>>>>> +} >>>>>>>>> + >>>>>>>>> +static void >>>>>>>>> radeon_uvd_fps_note_event( >>>>>>>>> struct >>>>>>>>> radeon_device *rdev, >>>>>>>>> int >>>>>>>>> idx) >>>>>>>>> +{ >>>>>>>>> + struct radeon_uvd_fps >>>>>>>>> *fps >>>>>>>>> = >uvd.fps_info[idx]; >>>>>>>>> + uint64_t timestamp = >>>>>>>>> jiffies_64; >>>>>>>>> + unsigned rate = 0; >>>>>>>>> + >>>>>>>>> + uint8_t index = >>>>>>>>> fps->event_index++; >>>>>>>>> + fps->event_index %= >>>>>>>>> RADEON_UVD_FPS_EVENTS_MAX; >>>>>>>>> + >>>>>>>>> + rate = div64_u64(HZ, >>>>>>>>> max(timestamp - >>>>>>>>> fps->timestamp, >>>>>>>>> 1ULL)); >>>>>>>>> + >>>>>>>>> + fps->timestamp = >>>>>>>>> timestamp; >>>>>>>>> + fps->events[index] = >>>>>>>>> min(rate, 120u); >>>>>>>>> +} >>>>>>>>> + >>>>>>>>> +static unsigned >>>>>>>>> >>>>>>>>> radeon_uvd_estimate_fps(struct >>>>>>>>> radeon_device *rdev, >>>>>>>>> int >>>>>>>>> idx) >>>>>>>>> +{ >>>>>>>>> + struct radeon_uvd_fps >>>>>>>>> *fps >>>>>>>>> = >uvd.fps_info[idx]; >>>>>>>>> + unsigned i, valid = >>>>>>>>> 0, >>>>>>>>> count = 0; >>>>>>>>> + >>>>>>>>> + for (i = 0; i < >>>>>>>>> RADEON_UVD_FPS_EVENTS_MAX; >>>>>>>>> i++) >>>>>>>>> { >>>>>>>>> + /* We should >>>>>>>>> ignore zero values */ >>>>>>>>> + if >>>>>>>>> (fps->events[i] >>>>>>>>> != 0) { >>>>>>>>> + >>>>>>>>> count += >>>>>>>>> fps->events[i]; >>>>>>>>> + >>>>>>>>> valid++; >>>>>>>>> + } >>>>>>>>> + } >>>>>>>>> + >>>>>>>>> + if (valid > 0) >>>>>>>>> + return count >>>>>>>>> / >>>>>>>>> valid; >>>>>>>>> + else >>>>>>>>> + return >>>>>>>>> RADEON_UVD_DEFAULT_FPS; >>>>>>>>> +} >>>>>>>>> + >>>>>>>>>void >>>>>>>>> >>>>>>>>> radeon_uvd_free_handles(struct >>>>>>>>> radeon_device *rdev, struct >>>>>>>>> drm_file *filp) >>>>>>>>>{ >>>>>>>>> int i, r; >>>>>>>>> @@ -419,8 +464,10 @@ static >>>>>>>>> int >>>>>>>>> radeon_uvd_cs_msg(struct >>>>>>>>> radeon_cs_parser >>>>>>>>> *p, struct radeon_bo *bo, >>>>>>>>> >>>>>>>>> /* create or >>>>>>>>> decode, >>>>>>>>> validate the handle */ >>>>>>>>> for (i = 0; i < >>>>>>>>> RADEON_MAX_UVD_HANDLES; ++i) >>>>>>>>> { >>>>>>>>> - if >>>>>>>>> >>>>>>>>> (atomic_read(>rdev->uvd.handles[i]) >>>>>>>>> == handle) >>>>>>>>> + if >>>>>>>>> >>>>>>>>> (atomic_read(>rdev->uvd.handles[i]) >>>>>>>>> == handle) >>>>>>>>> { >>>>>>>>> + >>>>>>>>> >>>>>>>>> radeon_uvd_fps_note_event(p->rdev, i); >>>>>>>>> >>>>>>>>> return 0; >>>>>>>>> + } >>>>>>>>> } >>>>>>>>> >>>>>>>>> /* handle not >>>>>>>>> found >>>>>>>>> try to alloc a new one */ >>>>>>>>> @@ -428,6 +475,7 @@ static >>>>>>>>> int >>>>>>>>> radeon_uvd_cs_msg(struct >>>>>>>>> radeon_cs_parser >>>>>>>>> *p, struct radeon_bo *bo, >>>>>>>>> if >>>>>>>>> >>>>>>>>> (!atomic_cmpxchg(>rdev->uvd.handles[i], >>>>>>>>> 0, >>>>>>>>> handle)) { >>>>>>>>> >>>>>>>>> p->rdev->uvd.filp[i] = >>>>>>>>> p->filp; >>>>>>>>> >>>>>>>>> p->rdev->uvd.img_size[i] = >>>>>>>>> img_size; >>>>>>>>> + >>>>>>>>> >>>>>>>>> radeon_uvd_fps_clear_events(p->rdev, >>>>>>>>> i); >>>>>>>>> >>>>>>>>> return 0; >>>>>>>>> } >>>>>>>>> } >>>>>>>>> @@ -763,7 +811,7 @@ int >>>>>>>>> >>>>>>>>> radeon_uvd_get_destroy_msg(struct >>>>>>>>> radeon_device >>>>>>>>> *rdev, int ring, >>>>>>>>>static void >>>>>>>>> radeon_uvd_count_handles( >>>>>>>>> struct >>>>>>>>> radeon_device *rdev, >>>>>>>>> >>>>>>>>> unsigned *sd, unsigned >>>>>>>>> *hd) >>>>>>>>>{ >>>>>>>>> - unsigned i; >>>>>>>>> + unsigned i, fps_rate >>>>>>>>> = >>>>>>>>> 0; >>>>>>>>> >>>>>>>>> *sd = 0; >>>>>>>>> *hd = 0; >>>>>>>>> @@ -772,10 +820,13 @@ static >>>>>>>>> void >>>>>>>>> radeon_uvd_count_handles( >>>>>>>>> struct >>>>>>>>> radeon_device *rdev, >>>>>>>>> if >>>>>>>>> >>>>>>>>> (!atomic_read(>uvd.handles[i])) >>>>>>>>> >>>>>>>>> continue; >>>>>>>>> >>>>>>>>> - if >>>>>>>>> (rdev->uvd.img_size[i] >= >>>>>>>>> 720*576) >>>>>>>>> - >>>>>>>>> ++(*hd); >>>>>>>>> - else >>>>>>>>> - >>>>>>>>> ++(*sd); >>>>>>>>> + fps_rate = >>>>>>>>> radeon_uvd_estimate_fps(rdev, >>>>>>>>> i); >>>>>>>>> + >>>>>>>>> + if >>>>>>>>> (rdev->uvd.img_size[i] >= >>>>>>>>> 720*576) { >>>>>>>>> + >>>>>>>>> (*hd) += >>>>>>>>> fps_rate > 30 ? 1 : 2; >>>>>>>>> + } else { >>>>>>>>> + >>>>>>>>> (*sd) += >>>>>>>>> fps_rate > 30 ? 1 : 2; >>>>>>>>> + } >>>>>>>>> } >>>>>>>>>} >>>>>>>>> >>>>>>>>> @@ -805,6 +856,7 @@ void >>>>>>>>> radeon_uvd_note_usage(struct >>>>>>>>> radeon_device >>>>>>>>> *rdev) >>>>>>>>> set_clocks &= >>>>>>>>> >>>>>>>>> schedule_delayed_work(>uvd.idle_work, >>>>>>>>> >>>>>>>>> >>>>>>>>> msecs_to_jiffies(UVD_IDLE_TIMEOUT_MS)); >>>>>>>>> >>>>>>>>> + >>>>>>>>> if >>>>>>>>> ((rdev->pm.pm_method == >>>>>>>>> PM_METHOD_DPM) && >>>>>>>>> rdev->pm.dpm_enabled) { >>>>>>>>> unsigned >>>>>>>>> hd >>>>>>>>> = >>>>>>>>> 0, sd = 0; >>>>>>>>> >>>>>>>>> >>>>>>>>> radeon_uvd_count_handles(rdev, >>>>>>>>> , ); >>>>>>>>> -- >>>>>>>>> 1.9.1 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Marco Antonio Benatto >>>>>>>>> Linux user ID:#506236 >>>>>>>>> >>>>>>>> >>>>>>> >>> >>> -- >>> Marco Antonio Benatto >>> Linux user ID: #506236 >>> >> > -- Marco Antonio Benatto Linux user ID: #506236 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/6017d030/attachment-0001.html>

[Bug 71891] 3.13 fails to boot with the radeon module

https://bugzilla.kernel.org/show_bug.cgi?id=71891 --- Comment #44 from Dino --- Solved. Last line before this happened was fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver It works after passing radeon.dpm=0 to boot options. -- You are receiving this mail

[Bug 82667] New: "Distance" game closed alpha: Changing shadow settings segfaults

DRI3_DISABLE=1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/1d1fc228/attachment.html>

drm/radeon: giving userspace control over hardware engine sync

Am 14.08.2014 um 20:35 schrieb Jerome Glisse: > On Thu, Aug 14, 2014 at 06:12:01PM +0200, Christian K?nig wrote: >> Hello everyone, >> >> this set of patch adds the ability for userspace to better control when >> synchronization between the different hardware engines on radeon happens. >>

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

>>>>>> + return count / >>>>>> valid; >>>>>> + else >>>>>> + return >>>>>> RADEON_UVD_DEFAULT_FPS; >>>>>> +} >>>>>> + >>>>>> void >>>>>> radeon_uvd_free_handles(struct >>>>>> radeon_device *rdev, struct >>>>>> drm_file *filp) >>>>>> { >>>>>> int i, r; >>>>>> @@ -419,8 +464,10 @@ static int >>>>>> radeon_uvd_cs_msg(struct >>>>>> radeon_cs_parser >>>>>> *p, struct radeon_bo *bo, >>>>>> >>>>>> /* create or decode, >>>>>> validate the handle */ >>>>>> for (i = 0; i < >>>>>> RADEON_MAX_UVD_HANDLES; ++i) { >>>>>> - if >>>>>> (atomic_read(>rdev->uvd. >>>>>> handles[i]) >>>>>> == handle) >>>>>> + if >>>>>> (atomic_read(>rdev->uvd. >>>>>> handles[i]) >>>>>> == handle) >>>>>> { >>>>>> + >>>>>> radeon_uvd_fps_note_event(p->rdev, >>>>>> i); >>>>>> >>>>>> return 0; >>>>>> + } >>>>>> } >>>>>> >>>>>> /* handle not found >>>>>> try to alloc a new one */ >>>>>> @@ -428,6 +475,7 @@ static int >>>>>> radeon_uvd_cs_msg(struct >>>>>> radeon_cs_parser >>>>>> *p, struct radeon_bo *bo, >>>>>> if >>>>>> (!atomic_cmpxchg(>rdev-> >>>>>> uvd.handles[i], >>>>>> 0, >>>>>> handle)) { >>>>>> >>>>>> p->rdev->uvd.filp[i] = p->filp; >>>>>> >>>>>> p->rdev->uvd.img_size[i] = >>>>>> img_size; >>>>>> + >>>>>> radeon_uvd_fps_clear_events(p- >>>>>> >rdev, >>>>>> i); >>>>>> >>>>>> return 0; >>>>>> } >>>>>> } >>>>>> @@ -763,7 +811,7 @@ int >>>>>> radeon_uvd_get_destroy_msg( >>>>>> struct >>>>>> radeon_device >>>>>> *rdev, int ring, >>>>>> static void >>>>>> radeon_uvd_count_handles(struct >>>>>> radeon_device *rdev, >>>>>> >>>>>> unsigned *sd, unsigned >>>>>> *hd) >>>>>> { >>>>>> - unsigned i; >>>>>> + unsigned i, fps_rate = 0; >>>>>> >>>>>> *sd = 0; >>>>>> *hd = 0; >>>>>> @@ -772,10 +820,13 @@ static void >>>>>> radeon_uvd_count_handles(struct >>>>>> radeon_device *rdev, >>>>>> if >>>>>> (!atomic_read(>uvd. >>>>>> handles[i])) >>>>>> >>>>>> continue; >>>>>> >>>>>> - if >>>>>> (rdev->uvd.img_size[i] >= >>>>>> 720*576) >>>>>> - ++(*hd); >>>>>> - else >>>>>> - ++(*sd); >>>>>> + fps_rate = >>>>>> radeon_uvd_estimate_fps(rdev, i); >>>>>> + >>>>>> + if >>>>>> (rdev->uvd.img_size[i] >= >>>>>> 720*576) { >>>>>> + (*hd) += >>>>>> fps_rate > 30 ? 1 : 2; >>>>>> + } else { >>>>>> + (*sd) += >>>>>> fps_rate > 30 ? 1 : 2; >>>>>> + } >>>>>> } >>>>>> } >>>>>> >>>>>> @@ -805,6 +856,7 @@ void >>>>>> radeon_uvd_note_usage(struct >>>>>> radeon_device >>>>>> *rdev) >>>>>> set_clocks &= >>>>>> schedule_delayed_work(> >>>>>> uvd.idle_work, >>>>>> >>>>>> msecs_to_jiffies(UVD_IDLE_ >>>>>> TIMEOUT_MS)); >>>>>> >>>>>> + >>>>>> if >>>>>> ((rdev->pm.pm_method == >>>>>> PM_METHOD_DPM) && >>>>>> rdev->pm.dpm_enabled) { >>>>>> unsigned hd = >>>>>> 0, sd = 0; >>>>>> >>>>>> radeon_uvd_count_handles(rdev, >>>>>> , ); >>>>>> -- >>>>>> 1.9.1 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Marco Antonio Benatto >>>>>> Linux user ID:#506236 >>>>>> >>>>> >>>> >> > -- Marco Antonio Benatto Linux user ID: #506236 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/7048c4db/attachment-0001.html>

[PATCH] drm/radeon: Revert try to enable VM flushing once more

From: Christian K?nig This reverts commit f77c4f0223a1f0e259007c7431f64df5c29a0bf7. Just had the afflatus why that doesn't work like it should and we need to revert it, cause it can happen on every hardware generation. Signed-off-by: Christian K?nig ---

[Patch] DRM support for addressing >32 bits on 32 bit cores (Radeon DRM driver+TTM)

: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/6f80ce40/attachment-0002.bin> -- next part -- A non-text attachment was scrubbed... Name: ttm.patch Type: text/x-patch Size: 424 bytes Desc: not available URL: <http://lists.freede

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

validate the handle */ > >>>> for (i = 0; i < > >>>> RADEON_MAX_UVD_HANDLES; ++i) { > >>>> - if > >>>> > (atomic_read(>rdev->uvd.handles[i]) > >>>> == handle) > >>>> + if > >>>> > (atomic_read(>rdev->uvd.handles[i]) > >>>> == handle) > >>>> { > >>>> + > >>>> > radeon_uvd_fps_note_event(p->rdev, i); > >>>> > return 0; > >>>> + } > >>>> } > >>>> > >>>> /* handle not found > >>>> try to alloc a new one */ > >>>> @@ -428,6 +475,7 @@ static int > >>>> radeon_uvd_cs_msg(struct > >>>> radeon_cs_parser > >>>> *p, struct radeon_bo *bo, > >>>> if > >>>> > (!atomic_cmpxchg(>rdev->uvd.handles[i], > >>>> 0, > >>>> handle)) { > >>>> > >>>> p->rdev->uvd.filp[i] = p->filp; > >>>> > >>>> p->rdev->uvd.img_size[i] = > img_size; > >>>> + > >>>> > radeon_uvd_fps_clear_events(p->rdev, > >>>> i); > >>>> > return 0; > >>>> } > >>>> } > >>>> @@ -763,7 +811,7 @@ int > >>>> radeon_uvd_get_destroy_msg(struct > >>>> radeon_device > >>>> *rdev, int ring, > >>>> static void > >>>> radeon_uvd_count_handles(struct > >>>> radeon_device *rdev, > >>>> > >>>>unsigned *sd, unsigned *hd) > >>>> { > >>>> - unsigned i; > >>>> + unsigned i, fps_rate = 0; > >>>> > >>>> *sd = 0; > >>>> *hd = 0; > >>>> @@ -772,10 +820,13 @@ static void > >>>> radeon_uvd_count_handles(struct > >>>> radeon_device *rdev, > >>>> if > >>>> > (!atomic_read(>uvd.handles[i])) > >>>> > continue; > >>>> > >>>> - if > >>>> (rdev->uvd.img_size[i] >= 720*576) > >>>> - ++(*hd); > >>>> - else > >>>> - ++(*sd); > >>>> + fps_rate = > >>>> radeon_uvd_estimate_fps(rdev, i); > >>>> + > >>>> + if > >>>> (rdev->uvd.img_size[i] >= > 720*576) { > >>>> + (*hd) += > >>>> fps_rate > 30 ? 1 : 2; > >>>> + } else { > >>>> + (*sd) += > >>>> fps_rate > 30 ? 1 : 2; > >>>> + } > >>>> } > >>>> } > >>>> > >>>> @@ -805,6 +856,7 @@ void > >>>> radeon_uvd_note_usage(struct > >>>> radeon_device > >>>> *rdev) > >>>> set_clocks &= > >>>> > schedule_delayed_work(>uvd.idle_work, > >>>> > >>>> > msecs_to_jiffies(UVD_IDLE_TIMEOUT_MS)); > >>>> > >>>> + > >>>> if > >>>> ((rdev->pm.pm_method == > >>>> PM_METHOD_DPM) && > >>>> rdev->pm.dpm_enabled) { > >>>> unsigned hd = > >>>> 0, sd = 0; > >>>> > >>>> radeon_uvd_count_handles(rdev, > >>>> , ); > >>>> -- > >>>> 1.9.1 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Marco Antonio Benatto > >>>> Linux user ID:#506236 > >>> > >> > >> > > > -- Marco Antonio Benatto Linux user ID: #506236 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/b637b443/attachment-0001.html>

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

On Fri, Aug 15, 2014 at 1:03 PM, Marco Benatto wrote: > Grigori, Alex and Christian > > are you ok if I merge ioctl flag idea with sysfs idea? > > We let the system decide the state using the hint provided by CS ioctl flag > but if performance is not good as expected > or DPM table is not sane we

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

On Fri, Aug 15, 2014 at 12:46 PM, Grigori Goronzy wrote: > For reference, I forgot to send to you all. > > Forwarded Message > Subject: Re: [PATCH] drm/radeon: Adding UVD handle basis fps estimation v2 > Date: Fri, 15 Aug 2014 18:40:02 +0200 > From: Grigori Goronzy > To: Alex

[Bug 71891] 3.13 fails to boot with the radeon module

https://bugzilla.kernel.org/show_bug.cgi?id=71891 Dino changed: What|Removed |Added CC||dino.omanovic.15 at gmail.com --- Comment #43

[Intel-gfx] [PATCH] drm: fix plane rotation when restoring fbdev configuration

On Fri, Aug 15, 2014 at 10:48:05AM +0100, Thomas Wood wrote: > On 15 August 2014 10:42, Thomas Wood wrote: > > On 14 August 2014 17:02, Daniel Vetter wrote: > >> On Thu, Aug 14, 2014 at 04:33:18PM +0100, Thomas Wood wrote: > >>> Make sure plane rotation is reset correctly when restoring the

[PATCH] drm/radeon: properly document reloc priority mask

From: Christian K?nig Instead of hard coding the value properly document that this is an userspace interface. No intended functional change. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_cs.c | 3 ++- include/uapi/drm/radeon_drm.h | 1 + 2

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

+; >>>>>>>>>> + fps->event_index %= RADEON_UVD_FPS_EVENTS_MAX; >>>>>>>>>> + >>>>>>>>>> + rate = div64_u64(HZ, max(timestamp - fps->timestamp, >>>>>>>>>> 1ULL)); >>>>&

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

On Fri, Aug 15, 2014 at 10:11 AM, Christian K?nig wrote: > Hi Marco, > > the problem with an CS ioctl flag is that we sometimes don't know how much > SCLK/MCLK boost is needed, for example when we do post processing in the > player using OpenGL and UVD decoding with VDPAU. In this case VDPAU

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

On Fri, Aug 15, 2014 at 11:20 AM, Grigori Goronzy wrote: > On 15.08.2014 16:11, Christian K?nig wrote: >> Hi Marco, >> >> the problem with an CS ioctl flag is that we sometimes don't know how >> much SCLK/MCLK boost is needed, for example when we do post processing >> in the player using OpenGL

Fence, timeline and android sync points

On Fri, Aug 15, 2014 at 10:07:39AM +0200, Daniel Vetter wrote: > On Thu, Aug 14, 2014 at 07:03:44PM -0400, Jerome Glisse wrote: > > On Thu, Aug 14, 2014 at 11:23:01PM +0200, Daniel Vetter wrote: > > > On Thu, Aug 14, 2014 at 9:15 PM, Jerome Glisse > > > wrote: > > > > Cost 1 uint32 per buffer

Fence, timeline and android sync points

On Fri, Aug 15, 2014 at 08:54:38AM +0200, Thomas Hellstrom wrote: > On 08/14/2014 09:15 PM, Jerome Glisse wrote: > > On Thu, Aug 14, 2014 at 08:47:16PM +0200, Daniel Vetter wrote: > >> On Thu, Aug 14, 2014 at 8:18 PM, Jerome Glisse > >> wrote: > >>> Sucks because you can not do weird

[Intel-gfx] [PATCH] drm: fix plane rotation when restoring fbdev configuration

On 15 August 2014 10:42, Thomas Wood wrote: > On 14 August 2014 17:02, Daniel Vetter wrote: >> On Thu, Aug 14, 2014 at 04:33:18PM +0100, Thomas Wood wrote: >>> Make sure plane rotation is reset correctly when restoring the fbdev >>> configuration by using drm_mode_plane_set_obj_prop. This calls

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

Hi guys, to make a long story short every time I watch a movie my laptop start to heat up because we always select the standard UVD power profile without actually measuring if that is necessary. Marco came up with a patch that seems to reliable measure the fps send down to the kernel and so

[Intel-gfx] [PATCH] drm: fix plane rotation when restoring fbdev configuration

On 14 August 2014 17:02, Daniel Vetter wrote: > On Thu, Aug 14, 2014 at 04:33:18PM +0100, Thomas Wood wrote: >> Make sure plane rotation is reset correctly when restoring the fbdev >> configuration by using drm_mode_plane_set_obj_prop. This calls the >> driver's set_property callback and ensures

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/cfff2eb6/attachment.html>

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

t;> + >>>>>>>>> +static unsigned radeon_uvd_estimate_fps(struct radeon_device >>>>>>>>> *rdev, >>>>>>>>> int >>>>>>>>> idx) >>>>>>>>> +{ >>>>>>>>> + struct radeon_uvd_fps *fp

Fence, timeline and android sync points

On Thu, Aug 14, 2014 at 07:03:44PM -0400, Jerome Glisse wrote: > On Thu, Aug 14, 2014 at 11:23:01PM +0200, Daniel Vetter wrote: > > On Thu, Aug 14, 2014 at 9:15 PM, Jerome Glisse > > wrote: > > > Cost 1 uint32 per buffer and simple if without locking to check status of > > > a buffer. > > > >

[PATCH 3/4] drm/radeon: add DONT_SYNC flag to CS relocs

Am 14.08.2014 um 23:06 schrieb Jerome Glisse: > On Thu, Aug 14, 2014 at 04:34:29PM -0400, Alex Deucher wrote: >> On Thu, Aug 14, 2014 at 2:43 PM, Jerome Glisse wrote: >>> On Thu, Aug 14, 2014 at 06:12:04PM +0200, Christian K?nig wrote: From: Christian K?nig This allows userspace

[Bug 82517] [RADEONSI,VDPAU] SIGSEGV in map_msg_fb_buf called from ruvd_destroy, when closing a Tab with accelerated video player

K?nig --- Thanks for testing, sounds like we can close this now. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140

[Bug 82517] [RADEONSI,VDPAU] SIGSEGV in map_msg_fb_buf called from ruvd_destroy, when closing a Tab with accelerated video player

bed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/ad19f105/attachment.html>

Fence, timeline and android sync points

On 08/14/2014 09:15 PM, Jerome Glisse wrote: > On Thu, Aug 14, 2014 at 08:47:16PM +0200, Daniel Vetter wrote: >> On Thu, Aug 14, 2014 at 8:18 PM, Jerome Glisse wrote: >>> Sucks because you can not do weird synchronization like one i depicted in >>> another >>> mail in this thread and for as long

[Bug 74335] [UVD] vdpau has terrible performance on radeonsi (HD 7950)

: 3.1791% = 100.% -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/305ff64d/attachment.html>

[Bug 82455] Failed to allocate virtual address for buffer

r the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/0b85af36/attachment.html>

[Bug 82586] UBO matrix in std140 struct does not work

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/f578566a/attachment-0001.html>

[Bug 82431] Garbled screen on boot

https://bugzilla.kernel.org/show_bug.cgi?id=82431 --- Comment #6 from Alex Deucher --- dpm is enabled by default in 3.17 so you don't need to append radeon.dpm=1 anymore to enable it. -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 82431] Garbled screen on boot

https://bugzilla.kernel.org/show_bug.cgi?id=82431 --- Comment #5 from Fede --- So the issue is fixed in 3.17? Using that kernel I should not need to use radeon.dpm=1 anymore? -- You are receiving this mail because: You are watching the assignee of the bug.

[git pull] drm fixes (mostly nouveau)

Hi Linus, one doc buidling fixes for a file that moved, along with a bunch of nouveau fixes, one a build problem on ARM. Dave. The following changes since commit 899552d6e84babd24611fd36ac7051068cb1eb2d: Merge branch 'misc' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild

[Bug 82431] Garbled screen on boot

https://bugzilla.kernel.org/show_bug.cgi?id=82431 --- Comment #4 from Alex Deucher --- (In reply to Fede from comment #3) > Hi Alex, > > In deed, adding radeon.dpm=1 works. > Can this be permanently fixed for everyone affected? The issues with dpm on btc asics were fixed in 3.16 and it's

[Bug 82431] Garbled screen on boot

https://bugzilla.kernel.org/show_bug.cgi?id=82431 --- Comment #3 from Fede --- Hi Alex, In deed, adding radeon.dpm=1 works. I tested it after submitting the bug report since I went thru what the actual patch changed. Currently running kernel 3.16.0-5 and it works as long as radeon.dpm=1 is

[Bug 82431] Garbled screen on boot

https://bugzilla.kernel.org/show_bug.cgi?id=82431 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2

[Bug 82431] Garbled screen on boot

https://bugzilla.kernel.org/show_bug.cgi?id=82431 --- Comment #1 from Fede --- Created attachment 146691 --> https://bugzilla.kernel.org/attachment.cgi?id=146691=edit Image of issue At times only a thin dotted line can be seen on the top, other times the content is displayed flickering,

[Bug 82431] New: Garbled screen on boot

https://bugzilla.kernel.org/show_bug.cgi?id=82431 Bug ID: 82431 Summary: Garbled screen on boot Product: Drivers Version: 2.5 Kernel Version: All after 3.13.6-20 Hardware: All OS: Linux Tree: Mainline

[Bug 82455] Failed to allocate virtual address for buffer

r the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/7dbd4e60/attachment.html>

[pull] radeon drm-fixes-3.17

Hi Dave, radeon fixes for 3.17, kind of all over the place (dpm, GPUVM, etc.) The following changes since commit 251964845fbf539781dd2c6406cb2ba1bf9eddd0: drm/doc: Refer to proper source file (2014-08-15 09:50:41 +1000) are available in the git repository at:

Fence, timeline and android sync points

On Thu, Aug 14, 2014 at 9:15 PM, Jerome Glisse wrote: > Yes preemption and gpu scheduling would break such scheme, but my point is > that when you have such gpu you want to implement a proper solution. Which > of course require quite some work accross the stack. So the past can live > on but the

Fence, timeline and android sync points

On Thu, Aug 14, 2014 at 9:15 PM, Jerome Glisse wrote: > Cost 1 uint32 per buffer and simple if without locking to check status of > a buffer. Yeah well except it doesn't and that's why we switch to full blown fence objects internally instead of smacking seqno values all over the place. At least

Fence, timeline and android sync points

On Thu, Aug 14, 2014 at 9:56 PM, Jerome Glisse wrote: > Android fence are not in my mind a nice thing :) Well I'll have a very close look at the proposed ioctl interface on top of these fence fds to make sure it's sane. But it will come that's pretty much for sure. And similar fence integration