Re: [BUG][AMD tahiti xt][amdgpu] broken dpm

bisected: commit 4dea25853a6c0c16e373665153bd9eb6edc6319e drm/[radeon|amdgpu]: Replace one-element array and use struct_size() helper ... Also, make use of the new struct_size() helper to properly calculate the size of struct SISLANDS_SMC_SWSTATE. regards, -- Sylvain

[BUG][AMD tahiti xt][amdgpu] broken dpm

Hi, updated my amd-staging-drm-next branch yesterday: the GPU fans do not reduce their rpm anymore. I checked the kernel log (attached) and I noticed: [drm:0xa036d50d] *ERROR* si_set_sw_state failed Is the fix already known or shall I start to bisect? (no rebase on linux master: should

Re: [Bug 206231] R9 280X low performance with all games

On Fri, Jan 24, 2020 at 09:47:44PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > In other words, this presumes the shaders submitted for compilation by dirt > rally engine are different each time the game is run ??? It may be related to the brand new

Re: [Bug 206231] R9 280X low performance with all games

On Fri, Jan 24, 2020 at 09:24:57PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=206231 > > --- Comment #43 from Alex Deucher (alexdeuc...@gmail.com) --- > The first time you run the game the shaders are not cached and you may see > large compile

Re: [Bug 206231] R9 280X low performance with all games

WOW: I did reproduce with dirt rally. I could not see it because the game must not be restarted to "uncripple" the renderer. I used the number or rendered frames and I go from an horrible 3000-5000 frames to a wooping 11000 frames, not to mention the game is now ~playable to max/ultra settings.

Re: [Bug 206231] R9 280X low performance with all games

Yep. this looks like a real critical software and/or hardware bug. Like the one you did show it the tomb raider vid. If you could reproduce with a free game, that would be better for the amd devs. I'll fool around a bit more with dirt rally (don't forget to restart the game each time you change

Re: [Bug 206231] R9 280X low performance with all games

On Thu, Jan 23, 2020 at 10:05:26PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > --- Comment #36 from Jacques Belosoukinski (kentos...@whiteninjastudio.com) > --- > No, I do not have Windows on this computer. There are several benchmark > results > available, moreover I noticed that Mesa

Re: [Bug 206231] R9 280X low performance with all games

On Thu, Jan 23, 2020 at 09:21:05PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=206231 > > --- Comment #34 from Jacques Belosoukinski (kentos...@whiteninjastudio.com) > --- > > > Windows version which should run at an average of 70fps during

Re: [Bug 206231] R9 280X low performance with all games

> Is there a reason to have such poor performance with Dirt Rally compared to > the > Windows version which should run at an average of 70fps during the benchmark? > I > noticed that the GPU load was low on the benchmark unlike other circuits where > the GPU load is 100%. Ok. What settings did

Re: [Bug 206231] R9 280X low performance with all games

This is consistent with what I have. I did a clean benchmark run, but this time everything to low/off, but still 1920x1080: avg fps ~250fps min fps ~200fps max fps ~350fps Still getting gpu vm faults in dmesg. I run everything git and amd-staging-drm-next no older than 1 week. -- Sylvain

Re: [Bug 206231] R9 280X low performance with all games

Actually I should have restarted the game. I did reboot in a clean state and did set "performance" on the gpu as well. Here are the results of "clean" benchmark run: avg fps ~ 20fps min fps ~ 15fps max fps ~ 40fps Still getting gpu vm faults in dmesg. -- Sylvain

Re: [Bug 206231] R9 280X low performance with all games

Dirt Rally is a GL game, not a vulkan game. It happens I have it in my library even though I don't recall to buy it. Anyway I did run the included benchmark: - cpu governor to performance - monitor refresh rate 144Hz - 1920x1080 - 8xmsaa - _no_ vsync - everything to max avg fps:

Re: [Bug 206231] R9 280X low performance with all games

> --- Comment #23 from Alex Deucher (alexdeuc...@gmail.com) --- > Is this roughly the same model every GPU vendor uses. GPUs are complex. No offense intended! It is obvious that the maths being the same for everybody, sensible hardware models will all look alike. It was more to underline the

Re: [Bug 206231] R9 280X low performance with all games

On Tue, Jan 21, 2020 at 08:01:49AM +, bugzilla-dae...@bugzilla.kernel.org wrote: > Yesterday, I compiled and installed the 5.4.13 kernel, but got no > improvements. Only the AMD/mesa devs can reasonably deal with the insane complexity of the GL stack (linux(drm) + libdrm + llvm + mesa(GL) +

Re: [Bug 206231] R9 280X low performance with all games

On Sun, Jan 19, 2020 at 01:11:15PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > Tomb Raider: https://youtu.be/0olpvLBH9DA Indeed, this is obvious here This vid rekt of the mip mapping hardware slow down bug... but I may be totally wrong due to the insane complexity of the GL stack.

Re: [Bug 206231] R9 280X low performance with all games

On Sat, Jan 18, 2020 at 08:59:14PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > I downloaded the Vulkan DLC and active the FPS in Dota 2. I get between ~80 > and > 90 fps : I have ~ the same fps (even though it can go somewhat below in intense team fights) > For CSGO, i get between ~70

Re: [Bug 206231] R9 280X low performance with all games

On Sat, Jan 18, 2020 at 03:00:49PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > https://ibb.co/GCmHFkf > https://ibb.co/ZXsvNZL Still the unreadable screenshots. huh?? > I use Gallium HUD with this options : Gallium HUD does not work with vulkan (as far as I know), hence for dota2

Re: [Bug 206231] R9 280X low performance with all games

BTW, your screenshots are of too low quality to be readable. And what is the tool you user to overlay amd gpu performance? (vulkan?) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Bug 206231] R9 280X low performance with all games

What is your CPU? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Bug 206231] R9 280X low performance with all games

Dota2? (vulkan and GL) CS:GO? (GL) Those games are free. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Bug 206231] R9 280X low performance with all games

Wow, this from the first tomb raider, the one from 2013!! (7 years ago). Sorry I read the emails in the wrong order. I don't know own this game, sorry. Another game perhaps? ___ dri-devel mailing list dri-devel@lists.freedesktop.org

Re: [Bug 206231] R9 280X low performance with all games

On Fri, Jan 17, 2020 at 06:45:28PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > screenshot : https://i.ibb.co/PrHj3hV/tombraider.jpg This seems to be from "shadow of the tomb raider" which I don't "own". Do you "own" "rise of the tomb raider", the previous tomb raider game (which I

Re: [Bug 206231] R9 280X low performance with all games

Owner and user of tahiti parts on amdgpu with a state of the art gfx stack poping in. I own "rise of the tomb raider" which gnu/linux port is vulkan only, and vulkan is only available with the "amdgpu" kernel module (as far as I know). I have not bought "shadow of the tomb raider", which is

Re: [Bug 110575] [R9 380X] Artifacts in CSGO

On Tue, Jul 30, 2019 at 08:54:44PM +, bugzilla-dae...@freedesktop.org wrote: > I plan to disable SDMA image copies by default on dGPUs. Is there a plan to "standardize" tiling format of frame buffer? (to dma the right format properly from one brand of gpus to another) -- Sylvain

Re: [Bug 109955] amdgpu [RX Vega 64] system freeze while gaming

Don't forget to provide the software stack used: which sofware (game, cad...)? wine/dxvk? native? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Bug 109955] amdgpu [RX Vega 64] system freeze while gaming

> ... > Vulkan/DXVK The bugs may be in wine/DXVK then. You should report to a bug to them and link this bug to theirs. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Bug 109955] amdgpu [RX Vega 64] system freeze while gaming

> I cannot speak for others. In my case,U would say no. I installed windows10 in > a separate ssd, just to check there was no hardware issue of any kind. > On windows10 with latest amd drivers, I have no freezes or any other issue > running same games. Native gnu/linux game or going through

Re: [Bug 109955] amdgpu [RX Vega 64] system freeze while gaming

unstable power supply lines to the gpu if overheating is excluded? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Bug 109955] amdgpu [RX Vega 64] system freeze while gaming

Playing dota2 vulkan or GL? I guess it's vulkan: and there I don't know how vulkan deal with multiple WSIs, and how dota2 selects the one it will use. The idea is to clearly identify the code paths which would be "buggy". (my custom distro is x11 native) That said, I don't know the status of

Re: [Bug 109955] amdgpu [RX Vega 64] system freeze while gaming

power management related code is in amdgpu, then the right place is here, the "dri" and "amdgfx" mailing lists (aka linux gpu driver mailing lists). As far as I am concerned, when I play dota2, I always switch the GPU dpm to high and the CPU freq governor to perf (because, all those things steal

Re: [Bug 109955] amdgpu [RX Vega 64] system freeze while gaming

Guys, I am getting freezes on tahiti xt/fx9590 recently... But I am not logging a bug yet because I think the reason is summer heat. Try to game with an opened computer case with a big fan blowing into it. ___ dri-devel mailing list

Re: [Bug 111082] Severe stutter in CS:GO surf servers, despite ~300fps

> My CPU load is also super low and never above 50 % on a single > core. This is the issue: looks like cpu capping in the 3d engine. But, since csgo 3d engine is direct3d designed, this is why vulkan. linux csgo devs are the ones who can profile properly their game and figure out the culprit.

Re: [Bug 111082] Severe stutter in CS:GO surf servers, despite ~300fps

I did report my CSGO performance pb to valve devs: https://github.com/ValveSoftware/csgo-osx-linux/issues/ I have no idea if my CPU bound performance pb is in the driver (which is very likely since it's opengl), or the 3D engine. ___ dri-devel

Re: [Bug 111082] Severe stutter in CS:GO surf servers, despite ~300fps

On Mon, Jul 08, 2019 at 03:20:44AM +, bugzilla-dae...@freedesktop.org wrote: > How is this not a graphics driver bug? He meant it could be a game engine bug (network or 3D, very probably). You are both right. CSGO 3D engine on based linux OSes is really bad if you use maps which are not in

Re: [Bug 109955] amdgpu [RX Vega 64] system freeze while gaming

On Sun, Jul 07, 2019 at 05:31:34AM +, bugzilla-dae...@freedesktop.org wrote: > 2. Valve sponsored an interesting project that removes dependency of AMD Mesa > from LLVM. And instead uses ACO. Valve made this available for Arch based > systems via AUR, and Ubuntu based system via PPA. If you

AMDGPU mesa3d ABI specs

Hi, Is there a document which describes, with implementat-able accuracy, the mesa3d ABI for amdgpu? Namely, proper document to generate a mesa3d loadable ELF object, and what GPU state shader code can expect to run. regards, -- Sylvain ___

Re: [Bug 110822] booting with kernel version 5.1.0 or higher on RX 580 hangs

bisect is quite common in the git world. You'll find tons of tutorials on the web, namely you're good for a little bit of reading. Just don't forget to "git reset --hard" before calling "git bisect good|bad". (just performed a bisection on linux yesterday).

Re: [Bug 109955] amdgpu [RX Vega 64] system freeze while gaming

It seems I get the same freezes than you. It takes hours of gaming to get some random hard hang (no log). I thought I was overheating, but realized that my system is on "vacation" while playing. linux amd-staging-drm-new/x11 native/mesa/llvm(erk...), all git no older than a week. playing mostly

Re: [Bug 109124] [AMD][TAHITI XT] csgo new battle royal mode bad performance

You can increase significantly the performance issue while taking some height: climb to the top of the "water station", turn to look anywhere, the fps drops below 30fps. Seems to be significantly linked to the 3d engine performance. ___ dri-devel mailing

Re: [Bug 109124] [AMD][TAHITI XT] csgo new battle royal mode bad performance

The actual main issue is while turning: since fps drops badly, it makes turning all blury, then makes it quite harder to spot anything. And in "open space" we turn all the time to check out if nobody is around (if you cannot know you are alone in your tile). I run the 3d engine at 1920x1080, video

Re: [Bug 109182] [AMD][TAHITI XT] CSGO rendering artifact on dashboard human body

I added xcb capture to my ffmpeg build: I made a video of the glitches available for download there: http://dl.free.fr/r1ENiiJ3C (it's a french hosting service for big files, let me know if you are unable to download it) ___ dri-devel mailing list

Re: [Bug 108920] [AMDGPU][TAHITI XT] linux unable to boot since rc3 rebase

Bisected: due to many compilation errors, git say any of the following commit could be the culprit: 663480d4e1460943de83ef14e86b8d2b0776edc6 971dbfb07e6ab4c5113898df25f39815c867a49c 103fcde3210ae17101bc1c64a78d074d61cf5cf7 85d5f3312d67bf8def41110447d19de3a0665754

Re: [Bug 107784] [AMD tahiti XT] displayport broken

Yep, it manifest also on 32 bits x86. I posted also a bug report. Since it's critical we'll probably get a new rc very soon. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Bug 107784] [AMD tahiti XT] displayport broken

Found the bug, very probably. It seems to be an upstream bug: a 32bits multiplication overflow on TSC frequency introduced in recent TSC cleanup: commit cf7a63ef4e0203f6f33284c69e8188d91422de83 Author: Pavel

Re: [Bug 107784] [AMD tahiti XT] displayport broken

Breaking commit is a merge commit from upstream mainline: commit 13e091b6dd0e78a518a7d8756607d3acb8215768 Merge: eac341194426 1088c6eef261 Author: Linus Torvalds Date: Mon Aug 13 18:28:19 2018 -0700 Merge branch 'x86-timers-for-linus' of

Re: [Bug 107784] [AMD tahiti XT] displayport broken

Got something, sort of obvious for a human, impossible for bisect to know, which explains why this bisection was a failure: testing a commit in the middle of a series of commits which are to be taken as a whole to be consistent for normal operations of the kernel, is wrong. That, bisect cannot

Re: [Bug 107784] [AMD tahiti XT] displayport broken

On Thu, Sep 06, 2018 at 02:22:18PM +, bugzilla-dae...@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=107784 > > --- Comment #16 from Michel Dänzer --- > "this commit" being 019cddc88f9e4ae0de2c76802f7137210c2101aa (the I2C merge), > which has two parents. Both of those

Re: [Bug 107784] [AMD tahiti XT] displayport broken

On Thu, Sep 06, 2018 at 10:04:53AM +, bugzilla-dae...@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=107784 > > --- Comment #14 from Michel Dänzer --- > That's not consistent with the merge commit you identified earlier. So I'm > afraid it's likely that you incorrectly

Re: [Bug 107784] [AMD tahiti XT] displayport broken

bisected: e2a9ca29b5edc89da2fddeae30e1070b272395c5 This commit is one in a series related to new TSC code. I tried to switch the clocksource to hpet early in the boot process, did not change anything. Any ideas before I post an issue on kernel bugzilla?

Re: [Bug 107784] [AMD tahiti XT] displayport broken

Ok, I got it. Since my git knowledge is quite limited, this "merge" commit is opening a vast sea of new commits to test. I'll dive into bisection using bisect (which actually deals with those merge commits). I am a bit scared of the amount of commits, may take hours/days. Please, in the

Re: [Bug 107213] [amdgpu/DisplayPort] KDE Wayland session is segfaulting right after login

May be different then, because my bug https://bugs.freedesktop.org/show_bug.cgi?id=107784 is with git userspace no older than a few days, and displayport is broken whatever the screen resolution. I did manually bisect the kernel and found the faulty commit though, I guess the guys in amd are now

Re: [Bug 107213] [amdgpu/DisplayPort] KDE Wayland session is segfaulting right after login

May be related to (if your kernel have the same faulty commit): https://bugs.freedesktop.org/show_bug.cgi?id=107784 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [amdgpu][tahiti xt] missing firmware

On Mon, Jul 09, 2018 at 10:24:19AM -0400, Alex Deucher wrote: > On Sun, Jul 8, 2018 at 10:31 AM, wrote: > > Hi, > > > > The firmware paths were changed from 'radeon/' to 'amdgpu/' in > > amd-staging-drm-next, but master of > > git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

[amdgpu][tahiti xt] missing firmware

Hi, The firmware paths were changed from 'radeon/' to 'amdgpu/' in amd-staging-drm-next, but master of git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git is missing the files in amdgpu/ for tahiti gpus. regards, -- Sylvain ___

Re: [amdgpu][tahiti xt] cursor motion smoothness

On Tue, Jul 03, 2018 at 11:01:46AM +0200, Michel Dänzer wrote: > Also make sure you do not pass -dumbSched on the Xorg command line, and > do not disable Option "SilkenMouse" in xorg.conf. No pb on this side. I tried to enable -dumbSched, I could not see any difference. I did run a fast moving

Re: [amdgpu][tahiti xt] cursor motion smoothness

On Tue, Jul 03, 2018 at 10:54:15AM +0200, Michel Dänzer wrote: > Unless your xserver build ends up with INPUTTHREAD undefined for some > reason, input events are processed in a separate thread, and the HW > cursor position is updated accordingly ASAP. I did check on that: INPUTTHREAD is properly

Re: [amdgpu][tahiti xt] cursor motion smoothness

On Mon, Jul 02, 2018 at 06:43:48PM +0200, Michel Dänzer wrote: > > Sending the logs as direct email to your personal email box. > > Does using xf86-input-libinput instead of xf86-input-evdev help? I did plan to switch to libinput in the futur, but: I did test the xinput events and I get for a

Re: [amdgpu][tahiti xt] cursor motion smoothness

On Mon, Jul 02, 2018 at 04:22:47PM +0200, Michel Dänzer wrote: > Is the behaviour different with the Xorg modesetting driver and/or the > radeon kernel driver? Tested both. Same thing than with amdgpu. -- Sylvain ___ dri-devel mailing list

Re: [amdgpu][tahiti xt] cursor motion smoothness

On Mon, Jul 02, 2018 at 04:22:47PM +0200, Michel Dänzer wrote: > I'm afraid I'm still not sure what "blurry motion" means exactly. Like the mouse cursor location is updated very slowly, and that, only at 60Hz. (in dota2, it looks like sub-30Hz with lag). > Is the behaviour different with the

Re: [amdgpu][tahiti xt] cursor motion smoothness

On Mon, Jul 02, 2018 at 11:29:19AM +0200, Michel Dänzer wrote: > On 2018-07-02 11:24 AM, Michel Dänzer wrote: > > On 2018-07-01 02:52 PM, sylvain.bertr...@gmail.com wrote: > >> Hi, > >> > >> I noticed that when my monitor runs at 60Hz, the cursor motion is really > >> not > >> smooth, even at low

[amdgpu][tahiti xt] cursor motion smoothness

Hi, I noticed that when my monitor runs at 60Hz, the cursor motion is really not smooth, even at low speed (it starts to be smooth at low speed when my monitor runs at 120/144Hz). Is there a way to improve this at the hardware level or is this a xserver issue? (I run everything git no older than

Re: [Bug 106617] monitor often unable to get out from dpms off

I cannot reasonably tell you if it is a regression, because my usage rarely gets my monitor in dpms off mode. That on top of the fact I did a new custom gnu/linux distro recently. If you have some compilation or not flags to enable tracing of video mode related code (in any/all components), I'll

Re: [AMD TAHITI XT][bisected] 83e3c46158720af39eef49e7066ee091e60e773a broke linux

On Sun, Mar 18, 2018 at 04:40:59PM +, sylvain.bertr...@gmail.com wrote: > I bisected a commit which broke my amd tahiti xt support. > bad commit:83e3c46158720af39eef49e7066ee091e60e773a > last good commit:f97eb9dba72fadc7c3ee1ed585246450fa927127 Tested today commit: my linux kernel is booting

[AMD TAHITI XT][bisected] 83e3c46158720af39eef49e7066ee091e60e773a broke linux

Hi, I bisected a commit which broke my amd tahiti xt support. repo: git://people.freedesktop.org/~agd5f/linux branch: amd-staging-drm-next bad commit:83e3c46158720af39eef49e7066ee091e60e773a last good commit:f97eb9dba72fadc7c3ee1ed585246450fa927127 regards, -- Sylvain

[AMDGPU] module does not link without DEBUG_FS configuration option

Hi, I did not look into details, but on amd-staging-drm-next (495e9e174feaec6e5aeb6f8224f0d3bda4c96114), linking the amdgpu module fails if DEBUG_FS is not enabled (probably some weird things happen in the code with the CONFIG_DEBUG_FS macro). Saw passing something about an amd-gfx mailing list.

Re: [AMDGPU][TAHITI XT] new display code

On Tue, Jan 30, 2018 at 10:17:06AM -0500, Harry Wentland wrote: > A good start would be to try re-using the DCE8 code for DCE6. You can > probably create a new dce60_resource.c and dce60_hw_sequencer.c, copying the > register structs, caps, function pointers, constructors and destructors from >

Re: [AMDGPU][TAHITI XT] new display code

On Mon, Jan 29, 2018 at 03:40:34PM -0500, Alex Deucher wrote: > On Mon, Jan 29, 2018 at 3:34 PM, wrote: > > As far as I can remember, not for the new features ofc, DCE programming for > > GCN1 > > is very similar if not mostly the same than DCE programming for

Re: [AMDGPU][TAHITI XT] new display code

On Mon, Jan 29, 2018 at 02:39:53PM -0500, Alex Deucher wrote: > On Mon, Jan 29, 2018 at 2:31 PM, wrote: > > On Mon, Jan 29, 2018 at 01:58:46PM -0500, Alex Deucher wrote: > >> It's similar, but there is still a bunch of DCE specific code. No one > >> has written that

Re: [AMDGPU][TAHITI XT] new display code

On Mon, Jan 29, 2018 at 01:58:46PM -0500, Alex Deucher wrote: > It's similar, but there is still a bunch of DCE specific code. No one > has written that DC code for DCE 6 yet. One could use the DC DCE8 > code as a guide, but it still has to be done. I have not checked the new code, but does it

Re: [AMDGPU][TAHITI XT] new display code

On Mon, Jan 29, 2018 at 01:04:08PM -0500, Alex Deucher wrote: > On Mon, Jan 29, 2018 at 12:56 PM, wrote: > > Hi, > > > > I'm an owner of tahiti xt gpu, and I wonder what are the reasons the new > > display code is not available for gcn1 hardware? > > No one has

[AMDGPU][TAHITI XT] new display code

Hi, I'm an owner of tahiti xt gpu, and I wonder what are the reasons the new display code is not available for gcn1 hardware? regards, -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org

SI display gap for more than 2 displays

On Thu, Sep 04, 2014 at 03:52:20PM +0200, Sylvain BERTRAND wrote: > Hi, > > In si_program_display_gap we have DISP1_GAP and DISP2_GAP. > > Where are DISP3_GAP to DISP6_GAP? What does expect this hardware > block when more than 2 displays are connected? Is DISP2_GAP > actual

SI display gap for more than 2 displays

Hi, In si_program_display_gap we have DISP1_GAP and DISP2_GAP. Where are DISP3_GAP to DISP6_GAP? What does expect this hardware block when more than 2 displays are connected? Is DISP2_GAP actually stand for DISP[3-6]_GAP? Still in the same function, what happened to the pipes for

i915 power management documentation

On Mon, Jun 02, 2014 at 06:45:59PM +0200, Daniel Vetter wrote: > The hw guys don't yet allow us to publish docs for this. We're working on > it. For now your best guess is to look at the code or ask around on the > #intel-gfx irc channel. Fear of US patent trolls? regards, -- Sylvain

[radeonsi] ss percentage divider in dpm

Hi, The commit 18f8f52b9a8c293111c058f9d25bcd5e718b80b2 does introduce the ss percentage divider. This divider is not used in si_populate_mclk_value and si_calculate_sclk_params. Expected? -- Sylvain

[radeonsi] si_populate_sq_ramping_values

Hi, In si_dpm.c, si_populate_sq_ramping_values function, It should be SISLANDS_DPM2_SQ_RAMP_LTI_RATIO instead of NISLANDS_DPM2_SQ_RAMP_LTI_RATIO. Moreover should it be: if (SISLANDS_DPM2_SQ_RAMP_LTI_RATIO > (LTI_RATIO_MASK >> LTI_RATIO_SHIFT)) instead of: if

[radeonsi] dpm: mc_reg_table slots

Hi, In si_populate_smc_acpi_state function, the acpi (emergency) state is a patched version of the initial state. Then 'ACIndex = 0' for the acpi state (i.e. setting it to SISLANDS_MCREGISTERTABLE_INITIAL_SLOT) seems misleading, since ACIndex is already set to 0

radeon atombios, vco_mode forced to 1

Hi, In radeon_atom_get_memory_pll_dividers, the vco_mode is forced to 0 or 1 instead of retaining the atombios value range of 0,1 and 2. Expected? regards, -- Sylvain

atombios powerplay cac table

On Thu, Nov 07, 2013 at 04:57:21AM +0100, Sylvain BERTRAND wrote: > Which GPU generations/families do use the "new" powerplay CAC > table, defined when the atombios platform capabilities have the > ATOM_PP_PLATFORM_CAP_NEW_CAC_VOLTAGE flag? I reply myself, since that w

atombios powerplay cac table

Hi, Which GPU generations/families do use the "new" powerplay CAC table, defined when the atombios platform capabilities have the ATOM_PP_PLATFORM_CAP_NEW_CAC_VOLTAGE flag? On drm-next-3.13 branch, commit 70471860ff9f335c60c004d42ebd48945bfa5403, I noticed the following: For the "new"

smc table extra flag used in system flags

Hi, git branch drm-fixes-3.12, git commit cdf6e8058415ba4d808537e30a0a6be9fb29e95a In si_dpm.c line 4557, the PPSMC_EXTRAFLAGS_AC2DC_GPIO5_POLARITY_HIGH is ignored because it is written in smc table systemFlags instead of the extraFlags. regards, -- Sylvain

vddc phase shedding in smc tables

in dpm code. regards, -- Sylvain BERTRAND

vddc phase shedding in smc tables

> unless I'm not understanding your question. Nope, my bad, I miss-read and did not double-check. :) BTW, which generations/families/types(mobile...) do support phase shedding? regards, -- Sylvain

vddc phase shedding in smc tables

Hi, git branch drm-fixes-3.12, git commit cdf6e8058415ba4d808537e30a0a6be9fb29e95a In si_dpm.c, the vddc phase shedding mask does overwrite the vddc voltage mask (lines 3889 and 3920 in si_populate_smc_voltage_tables function). Expected? (my tahiti based board seems not to have vddc phase

SI MC_ARB_BURST_TIME and MC_SEQ_TRAIN_WAKEUP_CNTL

Hi, MC_SEQ_TRAIN_WAKEUP_CNTL and MC_ARB_BURST_TIME have the same register address, 0x2808, in sid.h. (Register addresses are different in cikd.h) Expected? regards, -- Sylvain

endianness of rlc buffers (SI)

>> commit 555b1b651acf44bf27ebbb04235d38a8fd2d58dc (drm-fixes-3.12) >> >> evergreen.c, SI code path, line 4045 and 4046 shouldn't be swapped? >> Should cpu_to_le32 be used? >> >> Basically, is the endianness enforcement right for the rlc BOs? >> Or is there a bit somewhere to switch the RLC to

endianness of rlc buffers (SI)

Hi, commit 555b1b651acf44bf27ebbb04235d38a8fd2d58dc (drm-fixes-3.12) evergreen.c, SI code path, line 4045 and 4046 shouldn't be swapped? Should cpu_to_le32 be used? Basically, is the endianness enforcement right for the rlc BOs? Or is there a bit somewhere to switch the RLC to host endianness?

PA_SC_RASTER_CONFIG

Hi, In si.c, the PA_SC_RASTER_CONFIG register is set with a golden value in 'si_init_golden_registers' function but get set nearly immediately after in 'si_setup_rb' function at a finer level (for each sh block of each se block). If I remember well, that golden value would be again set to

PA_SC_RASTER_CONFIG

Hi, In si.c, the PA_SC_RASTER_CONFIG register is set with a golden value in 'si_init_golden_registers' function but get set nearly immediately after in 'si_setup_rb' function at a finer level (for each sh block of each se block). If I remember well, that golden value would be again set to

radeon pm bug?

Hi, In radeon_atombios.c file, radeon_atombios_parse_power_table_6 function, the power state is selected using the state array index: power_state = (union pplib_power_state *)_array->states[i]; The state array has variable sized states which size should be computed as said in the atombios.h

radeon pm bug?

Hi, In radeon_atombios.c file, radeon_atombios_parse_power_table_6 function, the power state is selected using the state array index: power_state = (union pplib_power_state *)state_array-states[i]; The state array has variable sized states which size should be computed as said in the atombios.h

radeon pm questions

Hi, I have a few questions about radeon pm code: In radeon_atombios.c, radeon_atombios_parse_power_table_6 function, power_state->v2.nonClockInfoIndex for non_clock_info of one state is ignored and replaced by the state index, referencing an iguana bug. Is it still buggy from southern

radeon pm questions

Hi, I have a few questions about radeon pm code: In radeon_atombios.c, radeon_atombios_parse_power_table_6 function, power_state-v2.nonClockInfoIndex for non_clock_info of one state is ignored and replaced by the state index, referencing an iguana bug. Is it still buggy from southern

[RFC] make VM handling async

> It's not 100% complete cause page table updates should be made with the DMA > ring, but we haven't released documentation for that yet, so I currently > use CP memory writes instead. Sad. Any release time hint? (the DMA ring will cleanup a lot of code). BTW, maybe at the same time the

radeon si: si_mc_load_microcode, blackout code path never used

The code path in that function makes the "blackout thingy" never used: ... if (running == 0) { if (running) { ...blackout thingy... } ... Is this normal behavior? -- Sylvain

radeon si: si_mc_load_microcode, blackout code path never used

The code path in that function makes the blackout thingy never used: ... if (running == 0) { if (running) { ...blackout thingy... } ... Is this normal behavior? -- Sylvain ___ dri-devel mailing list

si_mc_load_microcode function and blackout

Blackout mc microcode thingy useless? ... if (running == 0) { if (running) { ...blackout thingy... } ...

si_mc_load_microcode function and blackout

Blackout mc microcode thingy useless? ... if (running == 0) { if (running) { ...blackout thingy... } ... ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 08/10] drm/radeon: replace pflip and sw_int counters with atomics

> Does the linux API mandates atomic_t to be a 32bits word? AFAIK it is, at least for the platforms we care about. ... >>> >>> Then, the proper course of action would be to add to the linux API, sized >>> atomic operation first, wouldn't it? >> >> No, atomic is fine for this, I

[PATCH 08/10] drm/radeon: replace pflip and sw_int counters with atomics

>> Does the linux API mandates atomic_t to be a 32bits word? > > AFAIK it is, at least for the platforms we care about. > ... Then, the proper course of action would be to add to the linux API, sized atomic operation first, wouldn't it? -- Sylvain

  1   2   >