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 dota2 vulkan on AMD TAHITI XT ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 settings to minimal (native x11). I did investigate the update speed of my mouse, because I was suspicious, and I have above ~1000Hz update speed, using mouse-dpi-tool from libevdev. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 ___ 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
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 want to test it, you > can check the posts below. I am going to test this myself on both Arch and > Ubuntu. > https://steamcommunity.com/games/221410/announcements/detail/1602634609636894200 > https://steamcommunity.com/app/221410/discussions/0/1640915206474070669/ Huho! Cons: - it's c++ - only GFX8 and GFX9 (I have GFX6 :( ) - some nasty python scripts (there are tons in mesa) Pros: - it's several orders of magnitude less brain f*cked than llvm. - it is actual working code which does disjoint mesa from llvm. conclusion: - for GFX8 and GFX9, it's less worse than llvm. - I was asking for a clean GCN ABI definition document from shaders perspective, maybe this code will help to write one (or it is an AMD confidential document??). -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/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 the competitive set. For instance, danger zone open maps, on my system, have disastrous performance... and it is CPU related, not GPU, even though I have 8 core at 4.7Ghz (something is really wrong or litteraly CPU capped somewhere). -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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. (could be linux networking related too). ___ 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
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 dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 a significant amount of fps... actually, I do switch my GPU dpm to high just in case it would be nasty like the cpu governor). -- Sylvain ___ 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 wayland: did they reach the same "cluster f*ck" level that x11 is at? (irony, since wayland reason to exist is to be orders of magnitude less kludgy than x11) -- Sylvain ___ 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
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
> 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 wine/dxvk? ___ 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
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 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 ___ 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
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 vulkan only too (the port was coded by the same company). I did clear "rise of the tomb raider" years ago, I cannot play it anymore because the driver seems to miscompile some shaders and does gpu vm faults (from my save file). I did open a bug. I heard 'southern islands' parts (tahiti...) do suffer from a critical "mip mapping" slowdown bug. That could explain the slugginesh of those hardware parts in 3d intense games (I did almost stop playing "rise of the tomb raider" because the 3d rendering was unpleasantly not smooth enough). If you want, we can try to compare our benchmarks? -- Sylvain ___ 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
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 "own")? ___ 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 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
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
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
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 vulkan. In dota2 you have an option to display the 3d engine(valve source2) fps. In cs:go, there is a way to enable the 3d engine(valve source1) fps display. It is via the "console", see google.com. > My is CPU is an AMD FX 8320 I have a FX9590, then our benchmarks should be mostly the same. ___ 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
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 and +100fps : I have ~ the same for competitive maps. For danger zone maps, namely big open maps, csgo 3d engine has disastrous performance. Valve is aware of the problem. It seems there is a kind of cpu cap somewhere since max or lowest 3d settings does not seem to impact significantly the performance. Don't forget: I heard southern island parts suffer from a critical mip mapping bug/slowdown. The real benchmark is how much time and how often the fps goes below 60 in the worst realistic conditions (average does not matter). I did re-install "rise of the tomb raider", I still get gpu vm faults. If I recall properly "bioshock infinite" is gpu nasty even though it is a GL game. -- Sylvain ___ 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
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. ___ 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
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) + xserver + xf86-video-amdgpu). But they won't be able to do anything if you don't run the latest git version of the code (linux + mesa) and provide an easily reproducible and free (as in free beer) case (or some AMD/mesa devs own your games). I run such a 64bits system. If you can reproduce the issue with a free (as in free beer) game, I'll be pleased to test it to see if it happens on my system. or You would need to compile and run the following linux kernel: "git://people.freedesktop.org/~agd5f/linux branch", "amd-staging-drm-next" branch Unfortunately, Southern Islands hardware shader compiler is llvm, you would need to compile the latest git llvm-project (a massive pain). Idem for libdrm, mesa, the xserver, and the amdgpu xserver driver. -- Sylvain ___ 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
> --- 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 significant "technical cost" difference between GL and vulkan. To come back to this issue, I was willing to help this user "secure" a real issue by reproducing it (since I run everything git) and provide a reasonable context (free as in free beer) for you guys. -- Sylvain ___ 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
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: ~48fps low fps: ~30fps max fps: ~60fps I get several GPU vm faults in dmesg too, but no crash (like in vulkan "rise of the tomb raider"). -- Sylvain ___ 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
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 ___ 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
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 ___ 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
> 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 you use in the benchmark to compare dirt 3d engine on windowsDX and linuxGL(mesa)? all to max(often ultra)/on? with msaa? We must run exactly the same settings. -- Sylvain ___ 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
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 the... > Ultra settings with 8xmsaa, no vsync and 1920x1080 So you say that: everything to max/ultra/on + 8xmsaa an 1920x1080, on windows, you get avg 70fps? yes or no? If yes, what are the max and min fps? -- Sylvain ___ 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
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 has much lower performance compared to > DirectX on Dirt Rally and other games. ok. Then we don't have numbers to compare to and weight how much mesaGL is worse than dx for dirt rally 3D engine (modulo the hardware bugs/gpu vm faults/etc). > New bench with ultra settings, 8 xmsaa and 1920x1080: > min: 14fps > average: 19fps > max: 27fps I guess, one would use the presets to get a min fps close to 60fps and ajust with the advanced settings. -- Sylvain ___ 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
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 the settings...) -- Sylvain ___ 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: 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. I had to run 2 times in a row the benchmark to "uncripple" the renderer, or fool around with the msaa settings (without restarting). And I get ~11000 frames with msaax8 or msaaoff (and I can clearly see when it is on or off). Since you can reproduce with other games-->Yep, it is very probably a set driver/weird hardware critical bugs (modulo the numerous visual glitches and gpu vm faults). @alex: this one is nasty and probably will ruin the gaming experience (and benchmarks!) on many games. (@Jacques: Proton games do not do. Only native GL and/or vulkan, that to remove any proton bugs) ___ 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
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 times. The next time you run the game the shaders are cached > and > you avoid the compiling delays. I did not erazed the disk shader cache since the first time I did run the game. Then the game is loading the shaders straight from the disk cache. In other words, this presumes the shaders submitted for compilation by dirt rally engine are different each time the game is run ??? ___ 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
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 mesa/src/gallium/auxiliary/util/u_live_shader_cache.c I don't know the inner details of this (I stay away from anything GL), but it seems there are some GL shader usages which which will trigger a full compilation of an already compiled shader. @alex, maybe that's what you were talking about? As I said, I may be totally wrong though. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 not be hell) regards, -- Sylvain [0.00] Linux version 5.6.0-1+ (root@) (gcc version 7.3.0 (GCC)) #1 SMP PREEMPT Sun May 31 11:57:46 UTC 2020 [0.00] Command line: cinitramfs_root_uuid=1ef689ac-d88a-4d69-844e-0197359f772f initrd=\5.6.0-1+.cpio.xz [0.00] KERNEL supported cpus: [0.00] AMD AuthenticAMD [0.00] random: get_random_u32 called from 0x81019458 with crng_init=0 [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009] usable [0.00] BIOS-e820: [mem 0x0010-0xcd841fff] usable [0.00] BIOS-e820: [mem 0xcd842000-0xcdb23fff] reserved [0.00] BIOS-e820: [mem 0xcdb24000-0xcde75fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcde76000-0xcea3dfff] reserved [0.00] BIOS-e820: [mem 0xcea3e000-0xcea3efff] usable [0.00] BIOS-e820: [mem 0xcea3f000-0xcec44fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcec45000-0xcf06dfff] usable [0.00] BIOS-e820: [mem 0xcf06e000-0xcf7eefff] reserved [0.00] BIOS-e820: [mem 0xcf7ef000-0xcf7f] usable [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved [0.00] BIOS-e820: [mem 0xfec2-0xfec20fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfed61000-0xfed70fff] reserved [0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved [0.00] BIOS-e820: [mem 0xfef0-0x] reserved [0.00] BIOS-e820: [mem 0x00011000-0x00022fff] usable [0.00] NX (Execute Disable) protection: active [0.00] e820: update [mem 0xbd18f018-0xbd1ad057] usable ==> usable [0.00] e820: update [mem 0xbd18f018-0xbd1ad057] usable ==> usable [0.00] e820: update [mem 0xbd17e018-0xbd18e057] usable ==> usable [0.00] e820: update [mem 0xbd17e018-0xbd18e057] usable ==> usable [0.00] extended physical RAM map: [0.00] reserve setup_data: [mem 0x-0x0009] usable [0.00] reserve setup_data: [mem 0x0010-0xbd17e017] usable [0.00] reserve setup_data: [mem 0xbd17e018-0xbd18e057] usable [0.00] reserve setup_data: [mem 0xbd18e058-0xbd18f017] usable [0.00] reserve setup_data: [mem 0xbd18f018-0xbd1ad057] usable [0.00] reserve setup_data: [mem 0xbd1ad058-0xcd841fff] usable [0.00] reserve setup_data: [mem 0xcd842000-0xcdb23fff] reserved [0.00] reserve setup_data: [mem 0xcdb24000-0xcde75fff] ACPI NVS [0.00] reserve setup_data: [mem 0xcde76000-0xcea3dfff] reserved [0.00] reserve setup_data: [mem 0xcea3e000-0xcea3efff] usable [0.00] reserve setup_data: [mem 0xcea3f000-0xcec44fff] ACPI NVS [0.00] reserve setup_data: [mem 0xcec45000-0xcf06dfff] usable [0.00] reserve setup_data: [mem 0xcf06e000-0xcf7eefff] reserved [0.00] reserve setup_data: [mem 0xcf7ef000-0xcf7f] usable [0.00] reserve setup_data: [mem 0xfec0-0xfec00fff] reserved [0.00] reserve setup_data: [mem 0xfec1-0xfec10fff] reserved [0.00] reserve setup_data: [mem 0xfec2-0xfec20fff] reserved [0.00] reserve setup_data: [mem 0xfed0-0xfed00fff] reserved [0.00] reserve setup_data: [mem 0xfed61000-0xfed70fff] reserved [0.00] reserve setup_data: [mem 0xfed8-0xfed8] reserved [0.00] reserve setup_data: [mem 0xfef0-0x] reserved [0.00] reserve setup_data: [mem 0x00011000-0x00022fff] usable [0.00] efi: EFI v2.31 by American Megatrends [0.00] efi: ACPI=
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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
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 DCCG_DISP[2-6]_SLOW_SELECT? regards, -- Sylvain P.S. It seems that all this was "fixed" in CI with new hardware blocks, but I'm focussing on SI blocks.
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 > actually stand for DISP[3-6]_GAP? > > Still in the same function, what happened to the pipes for > DCCG_DISP[2-6]_SLOW_SELECT? I noticed something else: in si_enable_display_gap, the DISP1_GAP_MCHG and DISP2_GAP_MCHG fields from CG_DISPLAY_GAP_CNTL get inited with DISP1 only to vblank, and never reprogrammed with new displays like DISP[12]_GAP. It seems not consistant, expected? regards, -- Sylvain BERTRAND
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 give it a shot. I must say that the keyboard and mouse are responsive and I can use the computer blindely when the monitor is looping in trying to restore the video mode, thus I am able to get on the spot logs. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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: [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 looking into it. ___ 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
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 foreseable futur, do not make amd-staging-drm-next lag that much. Coming back once I get the faulty _simple_ commit, wish me luck. ___ 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
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? ___ 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
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 classified some commits as good or > bad. > Maybe the problem doesn't occur 100% consistently even with bad commits, so > try > testing longer / more times before declaring a commit as good. Not consistent? Could you be more specific? Some git magic I forgot again? This time I used git bisect to go through "merge" commits properly. I did test countless times those commits: that would mean this TSC code would "side-effect" an ultra-rare bad condition into an nearly-all-the-time bad condition. That amount of bad luck? Whatever, I'll update amd-staging-drm-next, and go through a full bisection again. I'll need probably days (lucky: I don't work). ___ 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
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 parent commits contain commit > e2a9ca29b5edc89da2fddeae30e1070b272395c5 (a TSC commit) as part of their > history. So you previously considered commit > e2a9ca29b5edc89da2fddeae30e1070b272395c5 as both bad and good. That's the > inconsistency. > > This most likely means that you're not yet able to reliably determine that a > given commit is bad, e.g. due to not testing (long) enough. Wow! Then it is even worse of what I thought. Due to the violent leap from 4.18 to 4.19, there are zillions of commits, and even nlog(n) bisect will give me ten_s_ of commits to test. Please, could you refine your "long enough" for a blocker pb which happens at boot, once xorg tries to program my displayport screen. That would be based on your experience, something to give me the order of the "long enough". That said, I have a hinch. I am going to setup a much cleaner test env: it's a custom distro which boots in _really_ a few seconds (not in the range of most mainstream distros boot time)-->I am going to slow it down, on purpose (certainly in more than 1 spot). Then, I have an efi framebuffer and I saw some issues about this->I am going to get rid of it. Then, I am not confident in my monitor (see my other bugs), I may use the previous artificial slow down, to power cycle the monitor, before xorg tries to detect and program it. Well, I'll try to figure a way to put my monitor in a "probably" cleaner state (in respect of displayport hotplug support). Oh, and just in case of, I'll stick to the performance cpu governor. If you have any advice about this based on your experience at knowledge , which I cannot match, I'm all eyes and hears. ___ 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
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 know. In my case, the TSC commits are "good"... and testing time has nothing to do with this: testing a commit in the middle of this series will have a side effect (DP link/aux timings...) on what I am observing to decide if a commit is "bad" or "good". In my case it will break this observable (my DP monitor is _really_ not working) and I'll tag the commit as "bad", which is inconsistent. The bottom of this, which is _obvious_ for an experienced git user on large projects, at the time of big merges on the main branch of a project like linux, if something breaks, bisect is probably more your enemy than your friend: it is ok to ask "Can you bisect?" on a sub-sub-system branch which has been free from big merges from any related other subsystems for a good while, but almost an insult on such massive update. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 1/2 week/s). regards, -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 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 1/2 week/s). > > > > If you have DC enabled, does disabling it (amdgpu.dc=0) help? > > Never mind, I missed that it's about Tahiti, which DC doesn't support. > > > Please share the corresponding Xorg log file. > > What exactly does "not smooth" mean? I meant cursor motion is very blury, enough I can loose its location on the screen. And for instance, while moving the dota2 map with the grab method, at 60Hz it looks like moving the dota2 map at a sub-30Hz with some lag. At 120/144Hz, cursor motion is way less blury, and dota2 map motion is smooth with the grab method. -- Sylvain Xorg.0.log.xz Description: application/xz ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 Xorg modesetting driver and/or the > radeon kernel driver? I don't know, I would need to setup these and test (my custom distro is made for amdgpu). > Sounds like maybe DOTA doesn't use the X11 cursor (which would end up > using the HW cursor), but renders the cursor as part of its scene. Probably, but it happens only at 60Hz. hum... the log was filtered out somewhere... Sending the logs as direct email to your personal email box. -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 reasonable mouse motion speed an update of coords for each column of the screen (full hd). It means that the cursor is supposely displayed for nearly all columns of the screen. For a fast mouse motion, the coord updates jump to a few tens of pixels. (1000Hz mouse) Those numbers does not change from 60Hz to 144Hz, then I can rule out the input code. If it's not my eyes or the screen itself, the pb will be in the cursor update code path from the xserver down to the driver... The bottom of it is if I happened to see a system which has mouse motion which looks smooth for my eyes at 60Hz, I would get back to you on this issue. regards, -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 defined. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 game at 60Hz, it was horrible, I ran it at 144Hz, smooth... the culprit may well be the monitor or my eyes. Don't bother anyway, I'll wait for a more solid element of comparison. If I get one which is obvious to my eyes, I will get back to you on this matter. -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 ___ 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 is > > missing > > the files in amdgpu/ for tahiti gpus. > > I'm pushing out updated firmware this week. In the meantime, you can > just copy or symlink the firmware from the radeon directory. Of course, thanks. regards, -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 0bf89d5dd1ee497df340ce932f0726d499cf9316 Seems the new doorbell support code has a broken SI(TAHITI XT) code path: commit 663480d4e1460943de83ef14e86b8d2b0776edc6 Author: Oak Zeng Date: Mon Nov 19 09:51:20 2018 -0600 drm/amdgpu: Doorbell index initialization for ASICs before vega10 Initialize doorbell index for asics vi and cik v2: Use enum definition instead of hardcoded number Change-Id: Id64eb98f5b1c24b51eb2fd5a083086fc3515813d Signed-off-by: Oak Zeng Suggested-by: Felix Kuehling Suggested-by: Alex Deucher Reviewed-by: Alex Deucher commit 971dbfb07e6ab4c5113898df25f39815c867a49c Author: Oak Zeng Date: Mon Nov 19 15:59:53 2018 -0600 drm/amdgpu: Doorbell layout for vega20 and future asic This introduces new doorbell layout for vega20 and future asics v2: Use enum definition instead of hardcoded value Change-Id: I04d22fb717ac50483c0835f160a2e860e344f358 Signed-off-by: Oak Zeng Suggested-by: Felix Kuehling Suggested-by: Alex Deucher Reviewed-by: Alex Deucher commit 103fcde3210ae17101bc1c64a78d074d61cf5cf7 Author: Oak Zeng Date: Mon Nov 19 09:25:37 2018 -0600 drm/amdgpu: Vega10 doorbell index initialization v2: Use enum definition instead of hardcoded value v3: Remove unused enum definition Change-Id: Ib72058337f0aa53adfc6c6aae5341a7cd665111a Signed-off-by: Oak Zeng Suggested-by: Felix Kuehling Suggested-by: Alex Deucher Reviewed-by: Alex Deucher commit 85d5f3312d67bf8def41110447d19de3a0665754 Author: Oak Zeng Date: Mon Nov 19 14:36:09 2018 -0600 drm/amdgpu: Call doorbell index init on device initialization Also call functioin amdgpu_device_doorbell_init after amdgpu_device_ip_early_init because the former depends on the later to set up asic-specific init_doorbell_index function Change-Id: I2f004bbbe2565035460686f4fc16e86b77a2a9b5 Signed-off-by: Oak Zeng Suggested-by: Felix Kuehling Suggested-by: Alex Deucher Reviewed-by: Alex Deucher commit 0bf89d5dd1ee497df340ce932f0726d499cf9316 Author: Oak Zeng Date: Mon Nov 19 15:20:07 2018 -0600 drm/amdgpu: Use asic specific doorbell index instead of macro definition ASIC specific doorbell layout is used instead of enum definition Change-Id: I84475efcfb482c474fccb133010abb5df5f4 Signed-off-by: Oak Zeng Suggested-by: Felix Kuehling Suggested-by: Alex Deucher Reviewed-by: Alex Deucher ___ 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
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 git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 timer updates from Thomas Gleixner: "Early TSC based time stamping to allow better boot time analysis. This comes with a general cleanup of the TSC calibration code which grew warts and duct taping over the years and removes 250 lines of code. Initiated and mostly implemented by Pavel with help from various folks" * 'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (37 commits) x86/kvmclock: Mark kvm_get_preset_lpj() as __init x86/tsc: Consolidate init code sched/clock: Disable interrupts when calling generic_sched_clock_init() timekeeping: Prevent false warning when persistent clock is not available sched/clock: Close a hole in sched_clock_init() x86/tsc: Make use of tsc_calibrate_cpu_early() x86/tsc: Split native_calibrate_cpu() into early and late parts sched/clock: Use static key for sched_clock_running sched/clock: Enable sched clock early sched/clock: Move sched clock initialization and merge with generic clock x86/tsc: Use TSC as sched clock early x86/tsc: Initialize cyc2ns when tsc frequency is determined x86/tsc: Calibrate tsc only once ARM/time: Remove read_boot_clock64() s390/time: Remove read_boot_clock64() timekeeping: Default boot time offset to local_clock() timekeeping: Replace read_boot_clock64() with read_persistent_wall_and_boot_offset() s390/time: Add read_persistent_wall_and_boot_offset() x86/xen/time: Output xen sched_clock time from 0 x86/xen/time: Initialize pv xen time in init_hypervisor_platform() ... If I revert this merge commit on amd-staging-drm-next branch, my displayport monitor works again. In the 1088c6eef261 branch, the one merged in mainline, displayport programming stopped working on the following commit: commit e2a9ca29b5edc89da2fddeae30e1070b272395c5 Author: Pavel Tatashin Date: Thu Jul 19 16:55:39 2018 -0400 x86/tsc: Initialize cyc2ns when tsc frequency is determined cyc2ns converts tsc to nanoseconds, and it is handled in a per-cpu data structure. Currently, the setup code for c2ns data for every possible CPU goes through the same sequence of calculations as for the boot CPU, but is based on the same tsc frequency as the boot CPU, and thus this is not necessary. Initialize the boot cpu when tsc frequency is determined. Copy the calculated data from the boot CPU to the other CPUs in tsc_init(). In addition do the following: - Remove unnecessary zeroing of c2ns data by removing cyc2ns_data_init() - Split set_cyc2ns_scale() into two functions, so set_cyc2ns_scale() can be called when system is up, and wraps around __set_cyc2ns_scale() that can be called directly when system is booting but avoids saving restoring IRQs and going and waking up from idle. I did not check if this issue was known from upstream yet. ___ 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 Tatashin Date: Thu Jul 19 16:55:38 2018 -0400 x86/tsc: Calibrate tsc only once During boot tsc is calibrated twice: once in tsc_early_delay_calibrate(), and the second time in tsc_init(). Rename tsc_early_delay_calibrate() to tsc_early_init(), and rework it so the calibration is done only early, and make tsc_init() to use the values already determined in tsc_early_init(). Sometimes it is not possible to determine tsc early, as the subsystem that is required is not yet initialized, in such case try again later in tsc_init(). One nasty thing: this commit is broken, it does not compile, hence it's a bisect "skipped" commit. Roughly, if you have a cpu with a frequency above 4.2GHz (max unsigned 32bits), linux time subsystem gets broken leading to the timeouts in displayport programming. Ofc, my cpu runs at 4.7GHz. ___ 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
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
[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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 again. regards, -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 written the code. I don't understand. Isn't the code for DCE programing pretty similar across all generations due to the atombios? I guess I miss something. -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 mean the atombios is gone for DCE programming? -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 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 mean the atombios is gone for > > DCE > > programming? > > It's still there. Even with atombios, there is still a bunch of DCE > specific programming required (page flips, interrupts, hotplug, > watermarks, LUTs, cursors, etc.). DC also adds support for a bunch of > new features that are were not supported by either atombios or the old > modesetting code (regamma/CTM, DP/HDMI audio, dchub programming for > display buffers in system memory for APUs, etc.). 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 GCN1.1/2 which is supported by the new DC code. Is this planned? -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 GCN1.1/2 > > which > > is supported by the new DC code. > > > > Is this planned? > > Right, as I said, you could definitely leverage the support for DCE8 > in DC. The blocks are very similar. At the moment, we have no plans > to implement DC support for DCE6. Ok. Which git repo/branch has the most up-to-date DCE code? Is there a fine granularity selection system for supported DCE features? That to expose the available/implemented DCE features to userland DRM (I can test only discret tahiti XT code paths). I'll try to get something working. -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 > the dce80_ versions. Then add a new dce_version and hook it up all over the > place, add the CHIP IDs for DC support in amdgpu_device_asic_has_dc_support > and you should pretty much be good to go. If you're lucky you'll light up. If > not you'll have to debug. > > As Alex mentioned, implementing DC support SI parts are not a priority for > us, but if you have a working patchset I'll be happy to review. I have massive IRL interference though. I'll give it a try anyway. Thx for the quickstart tips. -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[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. Is this list still valid for amdgpu related work? regards, -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 HDP_NONSURFACE regs should be 64bitified? -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms/atom: bios scratch reg handling updates
If the atombios bits for dpms state are still used from dce4, we would miss explicitly the DFP6 device in radeon_atombios_encoder_dpms_scratch_regs, wouldn't we? -- Sylvain (or sylware on phoronix.com) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
dce crtc mem req and atombios
Hi, On radeon hardware (I have an evergreen based board): Must stopping/resuming the DCE to access the memory controller be done with the EnableCRTCMemReq atombios table? (from DCE3 in dpm code). Because, in evergreen.c, evergreen_mc_stop and evergreen_mc_resume functions do not make use of that table (register direct access). regards, -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/10] drm/radeon: replace pflip and sw_int counters with atomics
> + atomic_tring_int[RADEON_NUM_RINGS]; > boolcrtc_vblank_int[RADEON_MAX_CRTCS]; > - boolpflip[RADEON_MAX_CRTCS]; > - int pflip_refcount[RADEON_MAX_CRTCS]; > + atomic_tpflip[RADEON_MAX_CRTCS]; Hi, Does the linux API mandates atomic_t to be a 32bits word? Regards, -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 think only sparc32 had 24-bit atomics, >> and if you can get sparc32 + a radeon, >> then you can keep both halves. > > And even that is a lie now :-) > > http://lwn.net/Articles/71732/ Ok then: atomic_t means exactly 32 bits! -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
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
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
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 island and we must keep ignoring power_state->v2.nonClockInfoIndex for good and use the state index to reference the right state description in non clock array table? The same does happen for the clock info index which can be out of range. Same treat as above? In radeon_atombios.c, radeon_atombios_parse_pplib_clock_info function, code paths are selected based on DCE generation. The same happens in radeon_atombios_parse_pplib_non_clock_info function. Should it rather be the chip family? Or current powerplay code does deal only with the DCE block?? regards, -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 file, definition of ATOM_PPLIB_STATE_V2 struct. Bug? regards, -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 the golden value in mesa. Is there one golden value for all se/sh blocks? Or are there computed (then overwritting the golden value) values for each se/sh? Why mesa would overwrite its value (I have not checked in lastest mesa)? (drm-next-3.10 branch, head 28ff680d66b9c6b8dbe9436742e39a47a16ea396) In drm-next-3.10 branch, commit c9e065819056dd00ccecbf17a73ade03fa03ca8e, in verde_golden_registers, many registers are set several times in a row, expected? (that does not look like sequential programing registers, maybe some register backbone block routing trickery?) Regards, -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 HDP_NONSURFACE regs should be 64bitified? -- Sylvain
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 island and we must keep ignoring power_state->v2.nonClockInfoIndex for good and use the state index to reference the right state description in non clock array table? The same does happen for the clock info index which can be out of range. Same treat as above? In radeon_atombios.c, radeon_atombios_parse_pplib_clock_info function, code paths are selected based on DCE generation. The same happens in radeon_atombios_parse_pplib_non_clock_info function. Should it rather be the chip family? Or current powerplay code does deal only with the DCE block?? regards, -- Sylvain
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 file, definition of ATOM_PPLIB_STATE_V2 struct. Bug? regards, -- Sylvain
si_mc_load_microcode function and blackout
Blackout mc microcode thingy useless?
...
if (running == 0) {
if (running) {
...blackout thingy...
}
...
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
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? Or the kmap is swapping dwords? 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 host >> endianness? Or the kmap is swapping dwords? > > The rlc buffers should be little endian. They will need to be swapped > on big endian systems. Right, then cpu_to_le32 should be used. Still for endianness, upper dword is written first (line 4045) and lower dword is written second (line 4046): Should the lower dword be written first then second the upper dword if we want little endian? Or maybe in that specific case, the rlc expect the upper dword first? -- Sylvain
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
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 shedding, then I could not check if the 2 masks could work together). regards, -- Sylvain
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
>> BTW, which generations/families/types(mobile...) do support phase shedding? > > Southern Islands and Sea Islands dGPU parts as far as I know. Erf, for tahiti discret gpu, the atombios rom does not have a VOLTAGE_OBJ_PHASE_LUT for VOLTAGE_TYPE_VDDC. I probably miss something in dpm code. regards, -- Sylvain BERTRAND
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
[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 (NISLANDS_DPM2_SQ_RAMP_LTI_RATIO <= (LTI_RATIO_MASK >> LTI_RATIO_SHIFT)) The previous does disable "sq ramping" for good on all SI, expected? 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] 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 (SISLANDS_MCREGISTERTABLE_INITIAL_SLOT) in si_populate_smc_initial_state. That should be removed to avoid confusion. Additionnally, that would mean the acpi state is not using its slot in the mc_reg_table, *BUT* it is used by the ulv state! Indeed ACIndex is set to 1 (SISLANDS_MCREGISTERTABLE_ACPI_SLOT) in si_populate_ulv_state function. We can see in si_populate_mc_reg_table that initial state, acpi state, ulv state and driver state have their respective mc_reg_table slot filled. Then, the previous code seems to make the ulv mc_reg_table slot unused and useless to fill. Moreover, is not following the SISLANDS_MCREGISTERTABLE_*_SLOT mc_reg_table allocation. Bug? regards, -- Sylvain
