similar to: [Bug 94832] New: Reverse Prime corruption with nouveau using radeon outputs

2016-01-03 20:11 GMT+01:00 Ilia Mirkin <imirkin at alum.mit.edu>: > On Sun, Jan 3, 2016 at 1:52 PM, Csányi Pál <csanyipal at gmail.com> wrote: >> So there is an AMD card too: >> VGA ASUS AMD Radeon R7 240, R7240-2GD3-L, 2GB DDR3, 128bit, >> 730/1800MHz, HDMI, DVI-D, D-sub >> >> What would be the best choice here: >> GEFORCE GT 730 >> or

> Regardless of the fence implementation, why would it be a good idea to do a full lockup recovery when some other driver is > calling your wait function? That doesn't seem to be a nice thing to do, so I think a timeout is the best error you could return here, > other drivers have to deal with that anyway. The problem is that we need to guarantee that the lockup will be resolved

Am 23.07.2014 10:07, schrieb Daniel Vetter: > On Wed, Jul 23, 2014 at 9:58 AM, Christian K?nig > <deathsimple at vodafone.de> wrote: >> Just imagine an application using prime is locking up Radeon and because of >> that gets killed by the user. Nothing else in the system would use the >> Radeon hardware any more and so radeon gets only called by another driver

OK, so I've got two PCs with Radeon 7000. One has PCI version of the card, and the other has AGP version of the card. Before update to 4.2, I had DRI enabled on both of them, and it worked stable for me (lucky me). After update to 4.2, the PC with AGP version of the card does not load radeon kernel module anymore, and it seems DRI related options from xorg.conf file are ignored. On the

op 23-07-14 15:16, Maarten Lankhorst schreef: > op 23-07-14 14:36, Christian K?nig schreef: >> Am 23.07.2014 12:52, schrieb Daniel Vetter: >>> On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig >>> <christian.koenig at amd.com> wrote: >>>>> And the dma-buf would still have fences belonging to both drivers, and it >>>>> would still call

Hello, I saw in the CentOS 6.6 release notes that the Xorg ABI has changed but that "This should not concern anyone who uses the default drivers shipped with CentOS." I'm using the ATI drivers in Base but X still fails when I boot a CentOS 6.6 kernel. I was hoping this is a known problem that would get fixed with a kernel update but I'm still having problems with the

Fall back to retrieving the EDID via the ACPI _DDC method, when present for notebook internal panels, when retrieving BIOS-embedded EDIDs. Signed-off-by: Daniel Dadap <ddadap at nvidia.com> --- drivers/gpu/drm/radeon/radeon_combios.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_combios.c b/drivers/gpu/drm/radeon/radeon_combios.c

--- drivers/gpu/drm/radeon/atombios_encoders.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c index 01b20e1..1603751 100644 --- a/drivers/gpu/drm/radeon/atombios_encoders.c +++ b/drivers/gpu/drm/radeon/atombios_encoders.c @@ -2623,16 +2623,8 @@ radeon_atom_ext_dpms(struct drm_encoder *encoder, int

--- drivers/gpu/drm/radeon/atombios_encoders.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c index 01b20e1..1603751 100644 --- a/drivers/gpu/drm/radeon/atombios_encoders.c +++ b/drivers/gpu/drm/radeon/atombios_encoders.c @@ -2623,16 +2623,8 @@ radeon_atom_ext_dpms(struct drm_encoder *encoder, int

Am 23.07.2014 12:52, schrieb Daniel Vetter: > On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig > <christian.koenig at amd.com> wrote: >>> And the dma-buf would still have fences belonging to both drivers, and it >>> would still call from outside the driver. >> >> Calling from outside the driver is fine as long as the driver can do >> everything

Hi, since 2.0.4 didn''t work with my notebook (see ''[Xen-devel] "general protection faults" in dom0 when loading intel-agp module'') I tried xen-testing. Now I''m on xen-unstable but I still get the following problem. X loads but doesn''t display anything more than the X cursor. The rootwindow looks kind of strange. Please see

Sam, Danny, J., all I am working with the radeon and radeonhd drivers seeing if I can get them to work with compiz 0.8.2.1 on my radeon x1200 laptop. My xorg .conf is: Section "Device" BoardName "RV350 NP" # Driver "radeon" Driver "radeonhd" Identifier "Device[0]" VendorName "ATI" EndSection I have tried

Am 23.07.2014 09:31, schrieb Daniel Vetter: > On Wed, Jul 23, 2014 at 9:26 AM, Christian K?nig > <deathsimple at vodafone.de> wrote: >> It's not a locking problem I'm talking about here. Radeons lockup handling >> kicks in when anything calls into the driver from the outside, if you have a >> fence wait function that's called from the outside but

I've posted this on the ubuntu forums as well with some additional postage there: http://ubuntuforums.org/showthread.php?t=1749918 I am having a graphics problem that is prohibiting me from playing portal 2 (serious business). I just recently installed Wine. I tried to play portal 2 and my graphics start flickering rapidly, mostly black. tried on ubuntu 10.10 64 bit wine version 1.3 ati

Boris Samorodov wrote: > The most convenient way to freeze the OS is to finish gnome session. > When gdm is reloading the whole mashine freezes at gnome greeter. > The mouse cursor freezes while being a clock-buzzer. Ctrl-alt-del > doesn't help, only reset does. > > > Does disabling DRI in xorg.conf fixes the problem ? > > Didn't try, but may do if it may help.

Am 22.07.2014 06:05, schrieb Dave Airlie: > On 9 July 2014 22:29, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: >> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> >> --- >> drivers/gpu/drm/radeon/radeon.h | 15 +- >> drivers/gpu/drm/radeon/radeon_device.c | 60 ++++++++- >>

On Wed, May 20, 2020 at 10:43 AM Christian K?nig <ckoenig.leichtzumerken at gmail.com> wrote: > > Am 13.05.20 um 13:03 schrieb Christian K?nig: > > Unfortunately AGP is still to widely used as we could just drop support for using its GART. > > > > Not using the AGP GART also doesn't mean a loss in functionality since drivers will just fallback to the driver

GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in radeon. v2: * move object-function instance to radeon_gem.c (Christian) * set callbacks in radeon_gem_object_create() (Christian) Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> ---

Am 23.07.2014 11:55, schrieb Maarten Lankhorst: > op 23-07-14 11:47, Christian K?nig schreef: >> Am 23.07.2014 11:44, schrieb Daniel Vetter: >>> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter <daniel.vetter at ffwll.ch> wrote: >>>> The scheduler needs to keep track of a lot of fences, so I think we'll >>>> have to register callbacks, not a

I am using Wine 1.2 which I compiled on Debian testing/wheezy. It works with fglrx but not with the radeon driver. I am using the AMD/ATI HD4850 video card. The following terminal output shows the wine error and that the radeon driver has OpenGL 2.1 support which to my understanding is at least the equivalent of Direct3D 9 (which is all I need). Also, there is a wine popup for every attempt to run