On 2023-04-18 23:06, Alex Deucher wrote:
Make sure the PCI register BAR is properly mapped in the ddx. Those old ddxes
required direct access to the hardware in the X server.
Alex
Thank you for replying, Alex. My knowledge of hardware on this level is rather
limited and I humbly ask for so
Make sure the PCI register BAR is properly mapped in the ddx. Those old ddxes
required direct access to the hardware in the X server.
Alex
On Monday, April 17, 2023 at 04:18:16 PM EDT, Morgan Wesström
wrote:
Dear list,
This is a small hobby project of mine so it's no big deal if
Processing control commands:
> reassign -1 xserver-xorg-video-radeon
Bug #1002834 [bugs.debian.org] bugs.debian.org: radeon /dri3/composer vsync/ no
browser works/ menu software quits
Bug reassigned from package 'bugs.debian.org' to 'xserver-xorg-video-radeon'.
Ignoring request to alter found ver
On 2021-10-12 02:03, Felix Miata wrote:
> Is there an IRC channel somewhere for amdgpu display driver issues? I couldn't
> find one on libera or oftc, and freenode won't let me join.
It's #radeon on OFTC.
--
Earthling Michel Dänzer| https://redhat.com
Libre software
73.218795] [drm] enabling PCIE gen 2 link speeds, disable with
> radeon.pcie_gen2=0
> [122273.223112] [drm] PCIE GART of 1024M enabled (table at
> 0x00162000).
> [122273.223206] radeon :01:00.0: WB enabled
> [122273.223208] radeon :01:00.0: fence driver on ring 0 use gpu
I have some more info on it:
Sometimes I can go to another terminal screen, sometimes I can still
login through ssh, sometimes the system fully locks up, but I can reboot
with sysreq-alt-b.
The whole thing seems to happen random, but mostly after the system has
been running one or two days.
Processing commands for cont...@bugs.debian.org:
> reassign 992617 libgl1-mesa-dri
Bug #992617 [xserver-xorg-video-radeon] xserver-xorg-video-radeon: Screen
rotate doesn't work
Bug reassigned from package 'xserver-xorg-video-radeon' to 'libgl1-mesa-dri'.
No longer marked as found in versions xser
On Mon, Aug 2, 2021 at 1:21 PM Guus Ellenkamp wrote:
>
> My display freezes randomly on an Ubuntu 20.04 system with a Radeon AMD
> Turks graphics card.
>
> Before the final freeze I often get warnings by the display suddenly
> turning black and then turning on again.
>
> Not sure if it's the drive
I'm sure you're busy, but if you could respond to my email below, I can
cross this off my list.
Thanks,
-Adam
On Sunday, March 28, 2021 at 1:46 PM, Adam Carter
wrote:
> Hey,
>
> After emailing you, I realized this may not be your responsibility and
> you're focused on other stuff.
>
> Who's the
I wanted to check in and see if you got my note about display port
standards?
Thanks,
-Adam
On Monday, March 22, 2021 at 7:22 AM, Adam Carter
wrote:
> I noticed you shared an article from En.Wikipedia.org when you talked
> about display port standards, here:
> lists.x.org/archives/xorg-driver-a
On Mon, Nov 9, 2020 at 4:19 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/radeon_display.c: In function ‘radeon_div’:
> drivers/gpu/drm/radeon/radeon_display.c:1094:11: warning: variable ‘mod’ set
> but not used [-Wunused-but-set-variable]
>
On Mon, Nov 9, 2020 at 4:19 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/radeon_display.c:264: warning: Function parameter or
> member '__work' not described in 'radeon_unpin_work_func'
> drivers/gpu/drm/radeon/radeon_display.c:406: warning
On Mon, 09 Nov 2020, Alex Deucher wrote:
> On Mon, Nov 9, 2020 at 4:19 PM Lee Jones wrote:
> >
> > This set is part of a larger effort attempting to clean-up W=1
> > kernel builds, which are currently overwhelmingly riddled with
> > niggly little warnings.
> >
> > This set takes the running (decr
On Mon, Nov 9, 2020 at 4:19 PM Lee Jones wrote:
>
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
>
> This set takes the running (decreasing) total from 5000 before
> [Set 1] down to 2300.
>
One thing i can see from your logs is that your Caicos gpu is
supported and attached to the radeon-kms driver, not amdgpu-kms, so i
think your xorg.conf's device section should have
Driver "radeon"
, not "amdgpu"? Other than that, dmesg output would give more hints.
On Fri, Nov 1, 20
On Tue, Sep 24, 2019 at 9:23 AM James Cloos wrote:
>
> For the V1605B, does anyone have the list of which firmware files need
> to be in CONFIG_EXTRA_FIRMWARE when amdgpu is compiled in?
>
> I take it that it is either raven or raven2, but not sure which.
>
> And does it need anything else?
It's
On 2019-02-02 6:39 a.m., Bill Messenger wrote:
> I found out that using Linux Mint 18.3 (which is based on Ubuntu 16.04) and
> using the default open-source amdgpu drivers seems to fix the issues with
> Blender, Inkscape, and Godot. I haven't tried seeing if it fixes the issue
> with LinVst yet, th
I found out that using Linux Mint 18.3 (which is based on Ubuntu 16.04) and
using the default open-source amdgpu drivers seems to fix the issues with
Blender, Inkscape, and Godot. I haven't tried seeing if it fixes the issue
with LinVst yet, though. I'm not sure why the latest version of Ubuntu,
Li
On Mon, Oct 22, 2018 at 11:17 PM Kevin Brace wrote:
>
> Hi Matt,
>
> When I released xf86-video-r128 DDX Version 6.11, I do not think I knew how
> to use the r128 DDX compile options correctly, and that is partial reason why
> this bug happened.
> I just uploaded Version 6.12 to the freedesktop.
Hi Matt,
When I released xf86-video-r128 DDX Version 6.11, I do not think I knew how to
use the r128 DDX compile options correctly, and that is partial reason why this
bug happened.
I just uploaded Version 6.12 to the freedesktop.org upstream Git and x.org tar
file repositories.
Version 6.12 sh
Processing control commands:
> severity -1 important
Bug #868179 [xserver-xorg-video-radeon] xserver-xorg-video-radeon: SEGV when
starting X11
Severity set to 'important' from 'grave'
> retitle -1 xserver-xorg-video-radeon: SEGV if xorg.conf contains both
> rotation and Virtual
Bug #868179 [xser
On Mon, Jan 8, 2018 at 7:58 PM, Hans Schneidhofer wrote:
> hi list,
> have installed a new Ubuntu 16.04 lts with kernel 4.10.
> My Hardware :
> Mainboard : M5A78L-M PLUS/USB3
> CPU : AMD Phenom(tm) II X2 511 Processor
> RAM : DDR3 8 GB
> Graphic : RS780L [Radeon 3000]
> Display : LG 32LH301C (32")
un 3.7.17, Michel Dänzer a écrit :
Objet: Re: Multi screen and graphics cards failed with radeon driver on debian
stretch
À: pbasnews-...@yahoo.fr
Cc: xorg-driver-ati@lists.x.org
Date: Lundi 3 juillet 2017, 5h19
On 30/06/17 10:53 PM, pbasnews-...@yahoo.fr
wrote:
> Without xorg.conf, I
On 30/06/17 10:53 PM, pbasnews-...@yahoo.fr wrote:
> Without xorg.conf, I have only one half of screen. I can enable 2 screens of
> same
> graphics card with xrandr of course (and kde system setting too)
>
> But unfortunaly I can not use xrand to enable my 3rd screen connected on my
> second
> g
Without xorg.conf, I have only one half of screen. I can enable 2 screens of
same graphics card with xrandr of course (and kde system setting too)
But unfortunaly I can not use xrand to enable my 3rd screen connected on my
second graphic cars
DISPLAY=:1 /usr/bin/xrandr --output VGA-0 --mode 1280
On 30/06/17 05:08 PM, Michel Dänzer wrote:
> On 23/06/17 11:15 PM, pbasnews-...@yahoo.fr wrote:
>>
>> $ xrandr --listproviders
>> Providers: number : 2
>> Provider 0: id: 0x99 cap: 0xf, Source Output, Sink Output, Source Offload,
>> Sink Offload crtcs: 2 outputs: 3 associated providers: 0 name:ATI
On 23/06/17 11:15 PM, pbasnews-...@yahoo.fr wrote:
> Hello,
>
> On debian previous version (jessie) I managed to use my 3 screen on KDE but
> since [b]stretch[/b] update, my conf doesn't work anymore.
> If anyone could help me?
You shouldn't need any xorg.conf file.
> $ xrandr --listproviders
On 15/06/17 10:27 PM, Adam Jackson wrote:
> On Thu, 2017-06-15 at 12:27 +0900, Michel Dänzer wrote:
>
>> P.S. We're now using the amd-gfx mailing list for reviewing patches for
>> these drivers.
>
> My apologies!
No problem at all.
> I've fixed my git configs to point to there instead.
Thanks.
On Thu, 2017-06-15 at 12:27 +0900, Michel Dänzer wrote:
> P.S. We're now using the amd-gfx mailing list for reviewing patches for
> these drivers.
My apologies! I've fixed my git configs to point to there instead.
- ajax
___
xorg-driver-ati mailing li
On 13/06/17 10:32 PM, Adam Jackson wrote:
> The client could have said anything here, and if what they said doesn't
> actually name an atom NameForAtom() will return NULL, and strcmp() will
> be unhappy about that.
>
> [copied from xserver d4995a3936ae283b9080fdaa0905daa669ebacfc]
>
> Signed-off-
On Fri, Apr 28, 2017 at 9:29 PM, Felix Miata wrote:
> Alex Deucher composed on 2017-04-28 15:15 (UTC-0400):
>
>> Felix Miata wrote:
>
>> All evergreen cards only have 2 PLLs so that means they can only
>> support two independent clocks. If you want to use more than two
>> displays, you'll need to
On Fri, Apr 28, 2017 at 9:55 PM, Michel Dänzer wrote:
> On 29/04/17 04:15 AM, Alex Deucher wrote:
>> On Fri, Apr 28, 2017 at 5:46 AM, Felix Miata wrote:
>>> Felix Miata composed on 2017-04-28 05:22 (UTC-0400):
>>>
Felix Miata composed on 2017-04-27 06:35 (UTC-0400):
>>>
> openSUSE Tumble
On 29/04/17 04:15 AM, Alex Deucher wrote:
> On Fri, Apr 28, 2017 at 5:46 AM, Felix Miata wrote:
>> Felix Miata composed on 2017-04-28 05:22 (UTC-0400):
>>
>>> Felix Miata composed on 2017-04-27 06:35 (UTC-0400):
>>
openSUSE Tumbleweed
kernel 4.10.10
server 1.19.3
ATI HD5450 PCI
Alex Deucher composed on 2017-04-28 15:15 (UTC-0400):
> Felix Miata wrote:
> All evergreen cards only have 2 PLLs so that means they can only
> support two independent clocks. If you want to use more than two
> displays, you'll need to use displayport or for non-displayport, at
> least two of th
On Fri, Apr 28, 2017 at 5:46 AM, Felix Miata wrote:
> Felix Miata composed on 2017-04-28 05:22 (UTC-0400):
>
>> Felix Miata composed on 2017-04-27 06:35 (UTC-0400):
>
>>> openSUSE Tumbleweed
>>> kernel 4.10.10
>>> server 1.19.3
>>> ATI HD5450 PCIe gfxcard (Cedar)
> ...
> When I use this startup sc
Felix Miata composed on 2017-04-28 05:22 (UTC-0400):
> Felix Miata composed on 2017-04-27 06:35 (UTC-0400):
>> openSUSE Tumbleweed
>> kernel 4.10.10
>> server 1.19.3
>> ATI HD5450 PCIe gfxcard (Cedar)
...
When I use this startup script:
xrandr --output DVI-0 --primary --mode 1920x1200 --left-of H
Felix Miata composed on 2017-04-27 06:35 (UTC-0400):
> openSUSE Tumbleweed
> kernel 4.10.10
> server 1.19.3
> ATI HD5450 PCIe gfxcard (Cedar)
> During BIOS display, 1920x1080 Dell is blank, the other two in 80x25. When KMS
> kicks in the framebuffers sometimes only two of the three light up, and
Boris Gjenero composed on 2017-04-05 17:42 (UTC-0400):
My Dell Inspiron 6400 has a ATI x1400 video card and 1680x1050 WSXGA+
display
I suspect it's possible your observations may be characteristic of the whole
X1300-X1950 series of Radeon cards, at least with the FOSS Radeon driver. My
X
On Sun, Mar 26, 2017 at 5:21 AM, Felix Miata wrote:
> AMD Sempron(tm) Processor 3000+
> Fresh installation on resurrected MSI K8MM-V MS-7142 motherboard.
> https://www.msi.com/Motherboard/support/K8MMV.html
> openSUSE Tumbleweed, kernel 4.10.4, server 1.19.3, ati driver 7.9.0
>
> Mouse cursor is a
On Wed, Mar 8, 2017 at 1:42 AM, Weiwen Zhong wrote:
> Hi all,
>
> I have an armv8 machine with radeon 7350 card installed. And this is my only
> display card. I've built radeon drivers and firmwares into the kernel (ver
> 4.9.9).
> When system booting and loading radeon driver, my radeon card will
On Wed, Feb 22, 2017 at 4:34 PM, Lyude wrote:
> Aux transfers always fail with non-zero status flags when there's
> nothing connected on the port, so we don't usually need to see all of
> the debugging information from it. Also, we try reprobing a -lot-, so
> without ratelimiting most of the kerne
On Wed, Jan 4, 2017 at 7:15 PM, Stuart Norman wrote:
> Here is a quote from an AMD tech support person from 9/29/16:
>
> The A10 8700P uses R6 graphics and currently APU graphics are not supported by
> the AMDGPU-PRO driver. At this time we cannot comment on when or if support
> will be added. I w
Here is a quote from an AMD tech support person from 9/29/16:
The A10 8700P uses R6 graphics and currently APU graphics are not supported by
the AMDGPU-PRO driver. At this time we cannot comment on when or if support
will be added. I would recommend reverting to Xorg 1.17 and to use Crimson
15
How would I go about doing that exactly though? I cant seem to find anything
about it...
- Paul
From: Alex Deucher
Sent: 05 January 2017 03:42
To: Paul Hancock
Cc: xorg-driver-ati@lists.x.org
Subject: Re: RADEON(0): [drm] failed to set drm interface version
On Wed, Jan 4, 2017 at 2:48 AM, Paul Hancock
wrote:
>
> I've got a mostly fresh kubuntu install that cant start xserver correctly, it
> hits the line in the email subject and aborts immediately (error 1). Oddly
> enough however calling startx while in the recovery CLI allows xserver to
> start
On Tue, Jan 3, 2017 at 1:28 PM, Stuart Norman wrote:
> I use pclinuxos. When X 1.18 was released the catalyst driver was removed and
> replaced by amdgpu which does not work with my chipset. AMD isn't supporting
> catalyst past X 1.17. The chipset is an integrated APU/GPU A10 8700p which is
> R6 V
On 05/12/16 05:19 PM, Alexander Konotop wrote:
> В Mon, 5 Dec 2016 16:39:31 +0900
> Michel Dänzer пишет:
>
>> On 03/12/16 12:24 AM, Alexander Konotop wrote:
>>> Here it is.
>>> I think it might be xserver-xorg-video-radeon:amd64 (at line 360).
>>
>> In the November 25-27 window you mentioned, x
В Mon, 5 Dec 2016 16:39:31 +0900
Michel Dänzer пишет:
> On 03/12/16 12:24 AM, Alexander Konotop wrote:
> > Here it is.
> > I think it might be xserver-xorg-video-radeon:amd64 (at line 360).
>
> In the November 25-27 window you mentioned, xserver-xorg-video-radeon
> was upgraded from 1:7.8.0-1
On 03/12/16 12:24 AM, Alexander Konotop wrote:
> Here it is.
> I think it might be xserver-xorg-video-radeon:amd64 (at line 360).
In the November 25-27 window you mentioned, xserver-xorg-video-radeon
was upgraded from 1:7.8.0-1 to 1:7.8.0-1+b1. That's a binary-only NMU,
i.e. the same package versi
On 04/12/16 01:16 AM, Clemens Eisserer wrote:
>
> Looking at the profile again, I wonder how r600_get_name can consume 5%
> of all CPU cycles:
>
> SELF CUMULATIVEFUNCTION
> [ 0,18%] [ 5,37%] ioctl
> [ 0,00%] [ 4,68%] r600_get_name
> [ 2,37%] [ 2,40%] surf_drm_to
Here it is.
I think it might be xserver-xorg-video-radeon:amd64 (at line 360).
В Fri, 2 Dec 2016 17:56:17 +0900
Michel Dänzer пишет:
> On 02/12/16 05:05 PM, Alexander Konotop wrote:
> > I've attached the log.
> > I tried looking at the Xorg.0.log using "tail -f" while starting a browser
> > an
Hi,
Looking at the profile again, I wonder how r600_get_name can consume 5% of
all CPU cycles:
SELF CUMULATIVEFUNCTION
[ 0,18%] [ 5,37%] ioctl
[ 0,00%] [ 4,68%] r600_get_name
[ 2,37%] [ 2,40%] surf_drm_to_winsys
A simple switch with predictable branches?
Regar
On 02/12/16 05:05 PM, Alexander Konotop wrote:
> I've attached the log.
> I tried looking at the Xorg.0.log using "tail -f" while starting a browser
> and waiting for it to
> freeze. Nothing happened, no new messages in Xorg.0.log. As well as in syslog
> and dmesg.
Let's try to narrow down which
I've attached the log.
I tried looking at the Xorg.0.log using "tail -f" while starting a browser and
waiting for it to
freeze. Nothing happened, no new messages in Xorg.0.log. As well as in syslog
and dmesg.
В Fri, 2 Dec 2016 10:35:15 +0900
Michel Dänzer пишет:
> On 02/12/16 05:18 AM, Alexan
On 02/12/16 05:18 AM, Alexander Konotop wrote:
> Hello! It looks like I've found a radeon driver bug.
>
> Distro:
> Debian Sid(Unstable).
>
> Hardware:
> * SUMO (integrated in AMD A4 APU)
> * CAICOS (external)
>
> Problem:
> All webkit browsers freeze in few moments after startup while loading/o
On 07/11/16 01:04 AM, Clemens Eisserer wrote:
> Hello,
>
> Java performs antialiased rendering by rasterizing coverage masks (<=
> 64x64 pixels in size, PictStandardA8) on the client instead of sending
> trapezoid-lists to the XServer. The masks are uploaded using XPutImage
> and are later used fo
Am 02.11.2016 um 04:28 schrieb Michel Dänzer:
On 02/11/16 02:39 AM, Jochen Rollwagen wrote:
So as far as i’m concerned the last version of the patch i sent is the
final one (i’m attaching it).
Please re-send the patch you want to be applied generated by git
format-patch, ideally with your
On 02/11/16 02:39 AM, Jochen Rollwagen wrote:
>
> So as far as i’m concerned the last version of the patch i sent is the
> final one (i’m attaching it).
Please re-send the patch you want to be applied generated by git
format-patch, ideally with your Signed-off-by tag.
> On my
Am 31.10.2016 um 19:30 schrieb Matt Turner:
On Mon, Oct 31, 2016 at 11:16 AM, Jochen Rollwagen
wrote:
Am 31.10.2016 um 07:01 schrieb Matt Turner:
On Fri, Oct 28, 2016 at 1:28 AM, Jochen Rollwagen
wrote:
Hi there,
gcc seems to create some sub-optimal code for the following code sequence
in
r
Am 31.10.2016 um 07:01 schrieb Matt Turner:
On Fri, Oct 28, 2016 at 1:28 AM, Jochen Rollwagen wrote:
Hi there,
gcc seems to create some sub-optimal code for the following code sequence in
radeon_accel.c:
for (; nwords > 0; --nwords, ++d, ++s)
*d = ((*s & 0x) << 16) | ((*s >
On Mon, Oct 31, 2016 at 11:16 AM, Jochen Rollwagen
wrote:
> Am 31.10.2016 um 07:01 schrieb Matt Turner:
>>
>> On Fri, Oct 28, 2016 at 1:28 AM, Jochen Rollwagen
>> wrote:
>>>
>>> Hi there,
>>>
>>> gcc seems to create some sub-optimal code for the following code sequence
>>> in
>>> radeon_accel.c:
On Fri, Oct 28, 2016 at 1:28 AM, Jochen Rollwagen wrote:
> Hi there,
>
> gcc seems to create some sub-optimal code for the following code sequence in
> radeon_accel.c:
>
> for (; nwords > 0; --nwords, ++d, ++s)
> *d = ((*s & 0x) << 16) | ((*s >> 16) & 0x);
>
> the body of the
Hi,
Juniper doesn't support GL_ARB_gpu_shader_fp64. If somebody were to
implement emulation code for that extension, the driver could enable
GL 4.1. There was GSoC that should have implemented it, but I don't
know what happened to it.
If apps don't use the extension, you can force GL 4.1 by setti
On Sat, Aug 27, 2016 at 10:43 AM, Clemens Eisserer wrote:
> Hi Marek,
>
> Thanks a lot for the detailed explanation. I asked it here, because I
> was not sure whether the details I asked are driver specific.
>
>> All GPU operations are asynchronous and don't
>> cause any stalls on the CPU side.
>
Hi Marek,
Thanks a lot for the detailed explanation. I asked it here, because I
was not sure whether the details I asked are driver specific.
> All GPU operations are asynchronous and don't
> cause any stalls on the CPU side.
And what about GPU stalls? From what I read it seems currently DMA can
On Fri, Aug 26, 2016 at 2:21 AM, Connor Behan wrote:
> On 25/08/16 11:40 PM, Kevin Brace wrote:
>> Hi Connor,
>>
>> I do not mean to harass you regarding this patch or my response to your
>> feedback, but it will be nice if you can reply to my response I sent to the
>> mailing list regarding wha
On 25/08/16 11:40 PM, Kevin Brace wrote:
> Hi Connor,
>
> I do not mean to harass you regarding this patch or my response to your
> feedback, but it will be nice if you can reply to my response I sent to the
> mailing list regarding what to do with the Render code.
> I did modify the original pro
Hi Connor,
> What's wrong with keeping the two separate files? FWIW, I got the idea
> to do this from the mach64 driver.
I was trying to get rid of "#include "r128_exa.render.c" statement from
r128_exa.c.
Personally, I do not think it is desirable to include large number of lines of
code in the
On 19/08/16 04:20 AM, Kevin Brace wrote:
> Signed-off-by: Kevin Brace
> ---
What's wrong with keeping the two separate files? FWIW, I got the idea
to do this from the mach64 driver.
> src/Makefile.am | 1 -
> src/r128_exa.c| 675 ++-
> s
Hi,
OpenGL discussions should take place on mesa-dev.
The following only applies to r600 & radeonsi:
- glUnmapBuffer usually doesn't unmap buffers from the CPU address
space. This is an optimization, because mapping is a very slow
operation and we want to the next glMapBuffer call to be free.
- g
On Mon, Aug 08, 2016 at 01:30:37PM -0400, Alex Deucher wrote:
> On Fri, Aug 5, 2016 at 8:30 PM, Lyude wrote:
> > While I was investigating an unrelated bug on the radeon driver, I noticed
> > that
> > it's become rather difficult to actually read through dmesg with drm.debug
> > turned on, on acc
Am 06.08.2016 um 02:30 schrieb Lyude:
While I was investigating an unrelated bug on the radeon driver, I noticed that
it's become rather difficult to actually read through dmesg with drm.debug
turned on, on account of the huge number of messages we end up printing from
failed DP aux transactions
On Fri, 2016-08-05 at 20:30 -0400, Lyude wrote:
> There's a couple of places where this would be useful for drivers (such
> as reporting DP aux transaction timeouts).
Maybe a single static _rs or one for each type would
be better than an individual _rs per callsite.
__
rds,
Qiang
From: Ryan Ross
Sent: Friday, July 22, 2016 2:25:46 PM
To: Yu, Qiang
Cc: xorg-driver-ati@lists.x.org
Subject: Re: Making the discrete AMD GPU the default GPU in a Mux-less setup
with an integrated Intel GPU in Mint 18 (Xenial)
Ah, and your configuration works? I'll have
if you build the patched whole
Xserver to generate modesetting_drv.so. I think the RenderXXX option
is the point to find why your modesetting_drv.so can't work.
Regards,
Qiang
From: Ryan Ross
Sent: Friday, July 22, 2016 4:31:05 PM
To: Yu, Qiang
Cc: xorg
on
is the point to find why your modesetting_drv.so can't work.
Regards,
Qiang
From: Ryan Ross
Sent: Friday, July 22, 2016 4:31:05 PM
To: Yu, Qiang
Cc: xorg-driver-ati@lists.x.org
Subject: Re: Making the discrete AMD GPU the default GPU in a Mux-
From: Ryan Ross
Sent: Friday, July 22, 2016 2:25:46 PM
To: Yu, Qiang
Cc: xorg-driver-ati@lists.x.org
Subject: Re: Making the discrete AMD GPU the default GPU in a Mux-less setup
with an integrated Intel GPU in Mint 18 (Xenial)
Ah, and your configuration works? I'll have to look closer
-ati@lists.x.org
Subject: Re: Making the discrete AMD GPU the default GPU in a Mux-less setup
with an integrated Intel GPU in Mint 18 (Xenial)
Greetings Qiang,
What version of X are you using? I've built my own with what Mint
currently is offering, which is apparently 1.18.3, but it seems
Ryan Ross
Sent: Friday, July 22, 2016 1:43:01 PM
To: Yu, Qiang; xorg-driver-ati@lists.x.org
Subject: Re: Making the discrete AMD GPU the default GPU in a Mux-less setup
with an integrated Intel GPU in Mint 18 (Xenial)
Greetings Qiang,
What version of X are you using? I've built my own with
Hi Ryan,
That's interesting. I also want to do this but in another way:
one modesetting DDX display on iGPU and render on dGPU
Attach the prototype patch and the xorg.conf should be
Section "ServerFlags"
Option "AutoAddGPU" "off"
EndSection
Section "Device"
Identifier "Intel"
Sorry, I was wrong. After more time testing, everything I have tested
has the same issue.
I upgraded to linux 4.6.3-1 the 02 jul 2016 to follow your advice:
[~]$ uname -a
Linux 4.6.3-1-ARCH #1 SMP PREEMPT Fri Jun 24 21:19:13 CEST
I was thinking that solved the issue, but yesterday I had the
On 28.06.2016 02:12, Lyude Paul wrote:
> I'm up for this. Better then having to send the same patches for both radeon
> and
> amdgpu to seperate mailing lists :)
I agree, so let's move the xf86-video-ati patch review to amd-gfx as well.
--
Earthling Michel Dänzer |
I'm up for this. Better then having to send the same patches for both radeon and
amdgpu to seperate mailing lists :)
Cheers,
Lyude
On Wed, 2016-06-22 at 17:57 +0900, Michel Dänzer wrote:
> This is a heads up that we'll be using the amd-...@lists.freedesktop.org
> mailing list for xf86-vid
On Sun, Jun 26, 2016 at 10:19 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Fixes crash with Xinerama enabled, which disables RandR.
>
> Fixes: https://bugs.debian.org/827984
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
> ---
> src/drmmode_display.c | 2 +-
> src/radeon_kms
Whoops, very sorry about this! I ran git send-email, and it looks like
I had forgotten to remove some other patches in my patches/ folder.
Going to resend this to avoid confusing anyone trying to review this.
On Fri, 2016-06-24 at 17:45 -0400, Lyude wrote:
> DRM_CONNECTOR_POLL_CONNECT only enables
On Wed, Jun 15, 2016 at 6:00 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Fixes memory leak when destroying pixmaps with priv->bo == NULL.
>
> Reported-by: Qiang Yu
> Signed-off-by: Michel Dänzer
For the series:
Reviewed-by: Alex Deucher
> ---
> src/amdgpu_pixmap.h | 6 +++---
> 1 fil
On Mon, Jun 13, 2016 at 6:01 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> So it can be used outside of the DRI2 code.
>
> v2: Keep pixmap refcnt increment in amdgpu_dri2_create_buffer2 (Qiang Yu)
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
> ---
> src/amdgpu_dri2.c | 54
On 12.06.2016 18:57, Yu, Qiang wrote:
> *From:* Michel Dänzer
>
>> + /* And redirect the pixmap to the new bo (for 3D). */
>> + glamor_egl_exchange_buffers(old, pixmap);
>> + amdgpu_set_pixmap_private(old, priv);
>
> this set the old pixmap with new priv, but the old priv is no
Yes, no other problem, you can add my tested-by.
Also thank you for solving this.
Regards,
Qiang
From: Michel Dänzer
Sent: Monday, June 13, 2016 9:10:36 AM
To: Yu, Qiang
Cc: xorg-driver-ati@lists.x.org
Subject: Re: [PATCH xf86-video-amdgpu 6/6] glamor
On 12.06.2016 19:13, Yu, Qiang wrote:
> Hi Michel,
>
>
> I've tested your patches. There's one problem:
>
> 1. sudo service lightdm start
>
> 2. DRI_PRIME=1 glxgears
>
> The glxgears window is shown black. But after resize or tap a 'Alt' key to
>
> show the command bar, the gears come out.
h
_get_tiling_info(pixmap);
+ if (AMDGPU_TILING_GET(tiling_info, ARRAY_MODE) != 0) {
+ PixmapPtr linear;
+
+ /* We don't want to re-allocate the screen pixmap as
+* linear, to avoid trouble with page flipping
+*/
+ if (sc
Hi Michel,
Grep [yuq].
Regards,
Qiang
From: Michel Dänzer
Sent: Wednesday, June 8, 2016 4:45 PM
To: xorg-driver-ati@lists.x.org
Cc: Yu, Qiang
Subject: [PATCH xf86-video-amdgpu 5/6] Move DRI2's local fixup_glamor helper to
amdgpu_glamor_set_pixmap_bo
From:
om: Michel Dänzer
Sent: Wednesday, June 8, 2016 10:43
To: StDenis, Tom
Cc: xorg-driver-ati@lists.x.org; Yu, Qiang
Subject: Re: [PATCH xf86-video-amdgpu 3/6] Add amdgpu_pixmap_get_tiling_info
On 08.06.2016 22:57, StDenis, Tom wrote:
> From: Michel Dänzer
>
>> +uint64_t amdgpu_pixmap_get
On 08.06.2016 22:59, StDenis, Tom wrote:
> From: Michel Dänzer
>
>> + tiling_info = amdgpu_pixmap_get_tiling_info(pixmap);
>> + if (AMDGPU_TILING_GET(tiling_info, ARRAY_MODE) != 0) {
>> + PixmapPtr linear;
>> +
>> +
On 08.06.2016 22:57, StDenis, Tom wrote:
> From: Michel Dänzer
>
>> +uint64_t amdgpu_pixmap_get_tiling_info(PixmapPtr pixmap)
>> +{
>> + struct amdgpu_pixmap *priv = amdgpu_get_pixmap_private(pixmap);
>> + uint32_t handle;
>> +
>> + if (!priv || !priv->handle_valid) {
>> +
een;
+ uint64_t tiling_info;
CARD16 stride;
CARD32 size;
int fd;
+ tiling_info = amdgpu_pixmap_get_tiling_info(pixmap);
+ if (AMDGPU_TILING_GET(tiling_info, ARRAY_MODE) != 0) {
+ PixmapPtr linear;
+
+ /* We don't want to re-allo
grep for TSTD below...
From: xorg-driver-ati on behalf of Michel
Dänzer
Sent: Wednesday, June 8, 2016 04:45
To: xorg-driver-ati@lists.x.org
Cc: Yu, Qiang
Subject: [PATCH xf86-video-amdgpu 3/6] Add amdgpu_pixmap_get_tiling_info
From: Michel Dänzer
Retrieves t
int fd;
>
> + tiling_info = amdgpu_pixmap_get_tiling_info(pixmap);
> + if (AMDGPU_TILING_GET(tiling_info, ARRAY_MODE) != 0) {
> + PixmapPtr linear;
> +
> + /* We don't want to re-allocate the screen pixmap as
> +
Michel Dänzer wrote on 2016-05-31 14:25:42:
>
> >> On 17.05.2016 19:17, tan...@zte.com.cn wrote:
> >>>
> >>> r6xx still be used on some machine,
> >>
> >> Doesn't glamor work well on those machines with a current version of
> >> xserver? If not, what specific issues are there?
> >
> > Glamor wo
Michel Dänzer wrote on 2016-05-31 17:01:59:
> > + R600SetSolidConsts(pScrn, &ps_alu_consts[0], pSrcPicture->format,
> > + pSrcPicture->pSourcePict->solidFill.color, 0);
> [...]
> > + R600SetSolidConsts(pScrn, &ps_alu_consts[4], pMaskPicture->format,
> > + pMaskPicture->pSourcePict->
1 - 100 of 2959 matches
Mail list logo
