https://bugs.freedesktop.org/show_bug.cgi?id=69341
darkbasic <darkbasic(a)linuxsystems.it> changed:
What |Removed |Added
----------------------------------------------------------------------------
Product|DRI |Mesa
Version|DRI CVS |git
Component|DRM/Radeon |Drivers/Gallium/radeonsi
--- Comment #11 from darkbasic <darkbasic(a)linuxsystems.it> ---
The …
[View More]root of the problem *isn't* glamor: I just tried Glamor with Intel HD4000
and it works flawlessly. The issue is with mesa.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
When userspace removes the active framebuffer using DRM_IOCTL_MODE_RMFB,
or explicitly disables the CRTC (by calling drmModeSetCrtc(..., NULL)
for example), a NULL framebuffer will be passed to the .set_config()
implementation of a CRTC. The drm_crtc_helper_set_config() helper will
decide to disable a CRTC when that happens.
To do so, it calls drm_crtc_helper_disable(), which in turn will iterate
over all encoders and decouple them from their connectors and finally
call …
[View More]drm_helper_disable_unused_functions() to clean up and call the
.disable() or .dpms() implementation for each encoder. However, at no
point during this sequence does it track the DPMS mode of a connector,
so it will usually remain on after this.
When a connector is enabled again, drm_helper_connector_dpms() will not
notice that the DPMS mode actually changed and won't do anything, which
causes the connector to stay disabled indefinitely.
To prevent this from happening, explicitly set the connector's DPMS mode
to off when the CRTC is disabled. That way it reflects the correct state
and can be enabled again.
This solves an issue observed when terminating an X server running on
the xf86-video-modesetting driver. Without this patch, the connector
would not be enabled properly and the screen would stay dark.
Signed-off-by: Thierry Reding <treding(a)nvidia.com>
---
drivers/gpu/drm/drm_crtc_helper.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
index 4280e37..7964948 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -563,6 +563,14 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
continue;
connector->encoder = NULL;
+
+ /*
+ * drm_helper_disable_unused_functions() ought to be
+ * doing this, but since we've decoupled the encoder
+ * from the connector above, the required connection
+ * between them is henceforth no longer available.
+ */
+ connector->dpms = DRM_MODE_DPMS_OFF;
}
}
--
1.8.4
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=70009
--- Comment #4 from Pavel Ondračka <pavel.ondracka(a)email.cz> ---
(In reply to comment #3)
> (In reply to comment #2)
> > So is seems, that when I record a trace using r300g driver (RV530) and
> > replay it using either llvmpipe or i965, it works fine. Probably this is
> > just some issue in the r300g driver, uncovered by core mesa changes...
> > EVE online apitrace uploaded here: http://pavel.ondracka.cz/EVE.…
[View More]trace
>
> llvmpipe and i965 support more temps than r300 class hw so they don't cross
> the limit.
Yeah, thats why they show no errors and promblems when launching EVE directly,
because wine detects this and generate valid shaders...
However the main problem is a little bit different. Citing one sample shader
from bug 42514:
The shader declares the array VC to have 245 elements:
uniform vec4 VC[245];
then it tries to access the 246th element of the array:
R0.xyz = (VC[245].xyz);
Also citing from wine bug 29146:
Yeah, we should be better about this. The reason we don't already do this is
that a shader like this may still work if it doesn't actually use the constants
near the end that we remove. We should probably print a message mentioning
something along those lines when such a shader fails to compile or link.
So when i generate the apitrace with r300g in already contains the invalid
shaders, however llvmpipe and softpipe still handle things correctly (e.g.
display majority of stuff) and also r300g did so before the mentioned bad
commit.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=70009
--- Comment #3 from Alex Deucher <agd5f(a)yahoo.com> ---
(In reply to comment #2)
> So is seems, that when I record a trace using r300g driver (RV530) and
> replay it using either llvmpipe or i965, it works fine. Probably this is
> just some issue in the r300g driver, uncovered by core mesa changes...
> EVE online apitrace uploaded here: http://pavel.ondracka.cz/EVE.trace
llvmpipe and i965 support more temps than r300 class …
[View More]hw so they don't cross the
limit.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
Hi
With the upcoming 3.12 merge-window, I thought people might find themselves with
nothing to do, so here's a new SimpleDRM series. Comments welcome!
This depends on the tip/x86/fb series in the x86-tip tree:
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=x86/fb
Which, as far as I understood, will be pushed into 3.12 by the x86 people.
Patches #1 and #2 implement the SimpleDRM driver which can replace vesafb,
efifb, simplefb, vgafb and more. Just enable the …
[View More]CONFIG_X86_SYSFB option and
you're good to go.
Patches #3 to #6 implement drm_kick_out_firmware() to make x86 drivers kick out
firmware-DRM drivers instead of only fbdev via
remove_conflicting_framebuffers().
I tested this based on drm-next plus the x86/fb series merged with i915 and
nouveau and it worked just fine.
Regards
David
David Herrmann (6):
drm: add SimpleDRM driver
drm: simpledrm: add fbdev fallback support
drm: add helpers to kick out firmware drivers
drm: nouveau: kick out firmware drivers during probe
drm/i915: use new drm_kick_out_firmware()
drm/radeon: use new drm_kick_out_firmware()
MAINTAINERS | 8 +
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_pci.c | 1 +
drivers/gpu/drm/drm_platform.c | 1 +
drivers/gpu/drm/drm_stub.c | 118 +++++++++
drivers/gpu/drm/drm_usb.c | 1 +
drivers/gpu/drm/i915/i915_dma.c | 6 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 29 ++-
drivers/gpu/drm/radeon/radeon_drv.c | 28 ---
drivers/gpu/drm/radeon/radeon_kms.c | 30 +++
drivers/gpu/drm/simpledrm/Kconfig | 29 +++
drivers/gpu/drm/simpledrm/Makefile | 4 +
drivers/gpu/drm/simpledrm/simpledrm.h | 112 +++++++++
drivers/gpu/drm/simpledrm/simpledrm_drv.c | 226 +++++++++++++++++
drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 153 ++++++++++++
drivers/gpu/drm/simpledrm/simpledrm_main.c | 363 ++++++++++++++++++++++++++++
drivers/gpu/drm/simpledrm/simpledrm_mem.c | 242 +++++++++++++++++++
include/drm/drmP.h | 26 ++
19 files changed, 1342 insertions(+), 38 deletions(-)
create mode 100644 drivers/gpu/drm/simpledrm/Kconfig
create mode 100644 drivers/gpu/drm/simpledrm/Makefile
create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h
create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_drv.c
create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_main.c
create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_mem.c
--
1.8.4
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=70009
Pavel Ondračka <pavel.ondracka(a)email.cz> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|mesa-dev(a)lists.freedesktop. |dri-devel(a)lists.freedesktop
|org |.org
Summary|[bisected] some wine apps |[r300g, bisected] some wine
|renders black …
[View More] |apps renders black
Component|Mesa core |Drivers/Gallium/r300
--- Comment #2 from Pavel Ondračka <pavel.ondracka(a)email.cz> ---
So is seems, that when I record a trace using r300g driver (RV530) and replay
it using either llvmpipe or i965, it works fine. Probably this is just some
issue in the r300g driver, uncovered by core mesa changes...
EVE online apitrace uploaded here: http://pavel.ondracka.cz/EVE.trace
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
NAK, after recovering from a lockup the first thing we do is signalling all remaining fences with an IB test.
If we don't recover we indeed signal all fences manually.
Signalling all fences regardless of the outcome of the reset creates problems with both types of partial resets.
Christian.
Marek Olšák <maraeo(a)gmail.com> schrieb:
>From: Marek Olšák <marek.olsak(a)amd.com>
>
>After a lockup, fences are not signalled sometimes, causing
>the GEM_WAIT_IDLE ioctl to …
[View More]never return, which sometimes results
>in an X server freeze.
>
>This fixes only one of many deadlocks which can occur during a lockup.
>
>Signed-off-by: Marek Olšák <marek.olsak(a)amd.com>
>---
> drivers/gpu/drm/radeon/radeon_device.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
>diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
>index 841d0e0..7b97baa 100644
>--- a/drivers/gpu/drm/radeon/radeon_device.c
>+++ b/drivers/gpu/drm/radeon/radeon_device.c
>@@ -1552,6 +1552,11 @@ int radeon_gpu_reset(struct radeon_device *rdev)
> radeon_save_bios_scratch_regs(rdev);
> /* block TTM */
> resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev);
>+
>+ mutex_lock(&rdev->ring_lock);
>+ radeon_fence_driver_force_completion(rdev);
>+ mutex_unlock(&rdev->ring_lock);
>+
> radeon_pm_suspend(rdev);
> radeon_suspend(rdev);
>
>--
>1.8.1.2
>
>_______________________________________________
>dri-devel mailing list
>dri-devel(a)lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/dri-devel
[View Less]