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
__
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 n
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_
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
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
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
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 h
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
> 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 y
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
_
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
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: ~48f
> --- 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
signi
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) +
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.
_
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
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
vulka
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
What is your CPU?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
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
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.freede
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"
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 vulka
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
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
> ...
> 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
> 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/
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
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 wa
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
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.fre
> 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.
(co
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 mailin
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 t
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 wan
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-deve
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).
_
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 do
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
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
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-d
Bisected:
due to many compilation errors, git say any of the following commit could be
the culprit:
663480d4e1460943de83ef14e86b8d2b0776edc6
971dbfb07e6ab4c5113898df25f39815c867a49c
103fcde3210ae17101bc1c64a78d074d61cf5cf7
85d5f3312d67bf8def41110447d19de3a0665754
0bf89d5dd1ee497df340ce932f0726d499
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
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
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/g
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
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
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
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?
__
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 foreseab
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 lo
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
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
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-dev
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 ga
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 d
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
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@li
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
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
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
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 gi
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
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
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.
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
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 supporte
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 c
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 m
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 underst
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
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
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]_
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
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
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_RAT
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_S
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
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 was di
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" power
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
in dpm code.
regards,
--
Sylvain BERTRAND
> 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
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 shedd
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
>> 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
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? O
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 th
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 th
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.
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.
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 islan
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 islan
> 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_NONSU
> 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_NONSU
The code path in that function makes the "blackout thingy" never used:
...
if (running == 0) {
if (running) {
...blackout thingy...
}
...
Is this normal behavior?
--
Sylvain
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.fr
Blackout mc microcode thingy useless?
...
if (running == 0) {
if (running) {
...blackout thingy...
}
...
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
> 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 t
1 - 100 of 108 matches
Mail list logo
