On Thu, Nov 21, 2019 at 03:17:12PM -0500, Alex Deucher wrote:
> Not sure I understand the question. What are you asking about?
On GFX[6-9], maybe it could be a could idea to freeze the number of allocated
sgprs and number of allocated vgprs, a bit like what we have on GFX10. Then we
could remove
Hi,
Is this a good idea? (see the email subject).
regards,
--
Sylvain
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On Mon, Feb 04, 2019 at 03:43:36PM +, Wentland, Harry wrote:
> DRM actually bumped this to 32 due to an issue with a Dell 4k display.
As I feared there is a retry counter higher in the code. My bad.
> It depends. I wouldn't call one or the other more correct. I seem to remember
> that the DP
> > List of tested application:
> > - Rise of the Tomb Raider
Sorry to pop in the bug report.
I run git linux(amd-staging-drm-next), drm, llvm (erk!), mesa-gl, mesa-vulkan,
xserver, xf86-video-amdgpu from yesterday, that on AMD tahiti xt.
I have run dota 2 vulkan, artifact (vulkan), cs:go (still
On Fri, Feb 01, 2019 at 09:20:56PM +, Wentland, Harry wrote:
> DRM's AUX code uses usleep_range in drm_dp_dpcd_access.
My bad, forgot about the usleep_range switch. That said AUX_RETRY_INTERVAL is
500 us, with a usleep_range top bound of 600 us.
Then, it would mean DC DP timeout retries would
On Fri, Feb 01, 2019 at 08:08:30PM +, sylvain.bertr...@gmail.com wrote:
> Do you mean non-DC displayport related code is already using udelay instead
> of msleep on linux?
I grep-ed amdgpu displayport atombios code, got udelay(400) only.
Did the same on drm *_dp_* files, got similar udelays wi
On Fri, Feb 01, 2019 at 07:16:17PM +, Wentland, Harry wrote:
> On 2019-02-01 12:31 p.m., sylvain.bertr...@gmail.com wrote:
> > On Fri, Feb 01, 2019 at 10:28:13AM -0500, Bhawanpreet Lakha wrote:
> >> From: John Barberiz
> >> [How]
> >> msleep is inaccurate for small values. Used udelay
> >> ins
On Fri, Feb 01, 2019 at 10:28:13AM -0500, Bhawanpreet Lakha wrote:
> From: John Barberiz
> [How]
> msleep is inaccurate for small values. Used udelay
> instead for accuracy.
Hi,
Should it be the case for non-DC displayport code too?
regards,
--
Sylvain
On Tue, Dec 04, 2018 at 02:00:54PM -0500, Alex Deucher wrote:
> Ping?
Does fix the SI issue (done in bugzilla).
--
Sylvain
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Hi,
(discret GPU, no vce and no uvd memory access)
Is there some hardware counters which allow us to count how much the
GFX/compute block
has its memory stalled because of the DC block ?
I presume the new on-die cache in vega is to mitigate the demanding DC block
over the GFX/compute block.
I
On Mon, Oct 15, 2018 at 07:28:57AM +0200, Mauro Rossi wrote:
> dpm for SI is available, while powerplay for SI is not, but
> display/amdgpu_dm uses some powerplay calls, where get_static_clock
> functions not available and the *ERROR* DM_PPLIB is due to missing handling
> in powerplay
I though pow
On Sun, Oct 14, 2018 at 11:47:18PM +0200, Mauro Rossi wrote:
> DOUBT: I think that it would make sense to set "power level 0" i.e.
> the "lower state" as safe default,
> considering that powerplay smu6/hwmgr are not implemented for SI and
> smu7 CIK functions do not work,
> the AS-IS dpm is the onl
On Mon, Oct 08, 2018 at 08:17:06PM +, sylvain.bertr...@gmail.com wrote:
> Sorry, I was wrong: I thought your patch set was enabling by default DC for
> dce6 (it requires the DC kernel param).
> I did force it, and it fails to init the dce6.
I did hack a bit your patch set on amd-staging-drm-ne
On Mon, Oct 08, 2018 at 07:02:54PM +0200, Mauro Rossi wrote:
> Thanks for info, do you have some github or patch to share for
> comparison/mutual knowledge?
Sorry, I was wrong: I thought your patch set was enabling by default DC for
dce6 (it requires the DC kernel param).
I did force it, and it fa
On Mon, Oct 08, 2018 at 12:04:23PM +, sylvain.bertr...@gmail.com wrote:
> I am currently testing your patch set, on amd-staging-drm-next
> (380d480842d584278dba9aa74341017d8c7d8c23) with an AMD tahiti xt part and a
> displayport monitor.
Forgot a very important thing: I run it with the linux t
I am currently testing your patch set, on amd-staging-drm-next
(380d480842d584278dba9aa74341017d8c7d8c23) with an AMD tahiti xt part and a
displayport monitor.
patch02 drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c did not apply but
seems kind of benign.
It's working out of the box on my AM
On Tue, Jun 12, 2018 at 01:41:55PM +0100, Daniel Stone wrote:
> Hi Sylvain,
>
> On 12 June 2018 at 13:38, wrote:
> > On Tue, Jun 12, 2018 at 12:34:31PM +0100, Daniel Stone wrote:
> >> GitLab has a pretty comprehensive and well-documented API which might
> >> help if you don't want to use a web b
On Tue, Jun 12, 2018 at 12:34:31PM +0100, Daniel Stone wrote:
> Hi Sylvain,
> It looks like Mutt is mangling email addresses - I've fixed Michel's.
>
> On 11 June 2018 at 14:30, wrote:
> > On Mon, Jun 11, 2018 at 12:33:52PM +0200, Michel Dänzer wrote:
> >> Adding the amd-gfx list, in cases someb
On Mon, Jun 11, 2018 at 12:33:52PM +0200, Michel Dänzer wrote:
> Adding the amd-gfx list, in cases somebody there has concerns or other
> feedback.
For feedback:
I attempted a migration on gitlab of my repos but I was blocked because it's
not noscript/xhtml basic browser friendly.
I was successfu
On Thu, May 10, 2018 at 09:34:02PM +, sylvain.bertr...@gmail.com wrote:
> On Thu, May 10, 2018 at 10:27:12PM +0530, Dawson Dias wrote:
> > Wow they're just going to defer it untill GCC 9. So the kernel will be
> > unbuildable using GCC 8.x.
> > Pity.
>
> And recent llvm do not compile with gcc
On Thu, May 10, 2018 at 10:27:12PM +0530, Dawson Dias wrote:
> Wow they're just going to defer it untill GCC 9. So the kernel will be
> unbuildable using GCC 8.x.
> Pity.
And recent llvm do not compile with gcc 7.3.0 because of the extreme complexity
of the c++ syntax used in the latter... I was w
Hi,
In my attempt to add the code for dce6 in dc (I base myself on dce80 code), it
seems I miss the mmDPREFCLK_CNTL (dc/dce/dce_clocks.h) register description for
dce60. I have mmDENTIST_DISPCLK_CNTL though.
I miss too the "max_clks_by_state" per power state limits (dc/dce/dce_clocks.c)
for dce60
22 matches
Mail list logo
