[PATCH v2 05/26] clk: sunxi: Add display and TCON0 clocks driver
Hi,
On Thu, Jan 14, 2016 at 11:24 PM, Maxime Ripard
wrote:
> The A10 SoCs and its relatives has a special clock controller to drive the
> display engines (both frontend and backend), that have a lot in common with
> the clock to drive the first TCON channel.
>
> Add a driver to support both.
>
> Signed-off-by: Maxime Ripard
> ---
> Documentation/devicetree/bindings/clock/sunxi.txt | 2 +
> drivers/clk/sunxi/Makefile| 1 +
> drivers/clk/sunxi/clk-sun4i-display.c | 241
> ++
> 3 files changed, 244 insertions(+)
> create mode 100644 drivers/clk/sunxi/clk-sun4i-display.c
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
> b/Documentation/devicetree/bindings/clock/sunxi.txt
> index 8a47b77abfca..5360554a7d3f 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -55,6 +55,7 @@ Required properties:
> "allwinner,sun9i-a80-apb1-gates-clk" - for the APB1 gates on A80
> "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
> "allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
> + "allwinner,sun4i-a10-display-clk" - for the display clocks on the A10
> "allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
> "allwinner,sun4i-a10-mmc-clk" - for the MMC clock
> "allwinner,sun9i-a80-mmc-clk" - for mmc module clocks on A80
> @@ -64,6 +65,7 @@ Required properties:
> "allwinner,sun8i-a23-mbus-clk" - for the MBUS clock on A23
> "allwinner,sun7i-a20-out-clk" - for the external output clocks
> "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
> + "allwinner,sun4i-a10-tcon-ch0-clk" - for the TCON channel 0 clock on
> the A10
> "allwinner,sun4i-a10-usb-clk" - for usb gates + resets on A10 / A20
> "allwinner,sun5i-a13-usb-clk" - for usb gates + resets on A13
> "allwinner,sun6i-a31-usb-clk" - for usb gates + resets on A31
> diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> index cb4c299214ce..a991cd8ca509 100644
> --- a/drivers/clk/sunxi/Makefile
> +++ b/drivers/clk/sunxi/Makefile
> @@ -10,6 +10,7 @@ obj-y += clk-a10-pll2.o
> obj-y += clk-a20-gmac.o
> obj-y += clk-mod0.o
> obj-y += clk-simple-gates.o
> +obj-y += clk-sun4i-display.o
> obj-y += clk-sun8i-mbus.o
> obj-y += clk-sun9i-core.o
> obj-y += clk-sun9i-mmc.o
> diff --git a/drivers/clk/sunxi/clk-sun4i-display.c
> b/drivers/clk/sunxi/clk-sun4i-display.c
> new file mode 100644
> index ..9dc6894f0934
> --- /dev/null
> +++ b/drivers/clk/sunxi/clk-sun4i-display.c
> @@ -0,0 +1,241 @@
> +/*
> + * Copyright 2015 Maxime Ripard
> + *
> + * Maxime Ripard
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct sun4i_a10_display_clk_data {
> + boolhas_div;
> + boolhas_rst;
> + u8 parents;
> +
> + u8 offset_en;
> + u8 offset_div;
> + u8 offset_mux;
> + u8 offset_rst;
> +
> + u8 width_div;
> + u8 width_mux;
> +};
> +
> +struct reset_data {
> + void __iomem*reg;
> + spinlock_t *lock;
> + struct reset_controller_dev rcdev;
> + u8 offset;
> +};
> +
> +static DEFINE_SPINLOCK(sun4i_a10_display_lock);
> +
> +static inline struct reset_data *rcdev_to_reset_data(struct
> reset_controller_dev *rcdev)
> +{
> + return container_of(rcdev, struct reset_data, rcdev);
> +};
> +
> +static int sun4i_a10_display_assert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct reset_data *data = rcdev_to_reset_data(rcdev);
> + unsigned long flags;
> + u32 reg;
> +
> + spin_lock_irqsave(data->lock, flags);
> +
> + reg = readl(data->reg);
> + writel(reg & ~BIT(data->offset), data->reg);
> +
> + spin_unlock_irqrestore(data->lock, flags);
> +
> + return 0;
> +}
> +
> +static int sun4i_a10_display_deassert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct reset_data *data = rcdev_to_reset_data(rcdev);
> + unsigned long flags;
> + u32 reg;
> +
> + spin_lock_irqsave(data->lock, flags);
> +
> + reg =
[Bug 93516] "Gods Will Be Watching" hangs at chapter load
https://bugs.freedesktop.org/show_bug.cgi?id=93516 --- Comment #1 from andreaskem at web.de --- With kernel 4.4 and mesa 11.1.1, the game continues for another 2 seconds after the black screen fades out and then hangs again. Strace is pretty much identical to the one attached to the original report. Race condition? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/c42b1b20/attachment.html>
[Bug 93740] weston client egl corruption above certain window size.
https://bugs.freedesktop.org/show_bug.cgi?id=93740 Bug ID: 93740 Summary: weston client egl corruption above certain window size. Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: adf.lists at gmail.com QA Contact: dri-devel at lists.freedesktop.org Apologies if this isn't a radeonsi issue. Before today I've never tested weston so have no knowledge of past behavior. R9285. Issue happens with weston alone or started from within X. Weston its self renders OK. If I start weston-simple-egl it renders OK, but if I enlarge its window the output becomes corrupted, not totally, I can see the triangle is enlarged, but there is lots of random looking memory rendered as well. If shrink it back down it renders OK once it hits original size and is OK smaller. Output from kodi/mpv is also 90% junk. In the case of mpv I can reduce the vid window down in size, and when it hits the small size that simple-egl starts at it also starts to render OK. All the wayland/weston code is release. Mesa/llvm gits. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/2bbf0259/attachment.html>
[PATCH] drm/i2c: tda998x: Choose between atomic or non atomic dpms helper
Choose between atomic or non atomic connector dpms helper. If tda998x
is connected to a drm driver that does not support atomic modeset
calling drm_atomic_helper_connector_dpms() causes a crash when the
connectors atomic state is not initialized. The patch implements a
driver specific connector dpms helper that calls
drm_atomic_helper_connector_dpms() if driver supports DRIVER_ATOMIC
and otherwise it calls the legacy drm_helper_connector_dpms().
Fixes commit 9736e988d328 ("drm/i2c: tda998x: Add support for atomic
modesetting").
Signed-off-by: Jyri Sarha
---
Ok, so this is the second approach to solve this issue. The first
attempt can be found here [1] with the follow from Liviu Dudau that
suggested this approach.
It just makes me wonder if drm_atomic_helper_connector_dpms() should
call the legacy callback automatically if DRIVER_ATOMIC is not set or
at least bail out gracefully with an error message. Then again it may
be overkill if the tda998x is the only driver that need to support
both situations.
Best regards,
Jyri
[1] http://www.spinics.net/lists/dri-devel/msg98514.html
drivers/gpu/drm/i2c/tda998x_drv.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 012d36d..bb7d507 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1382,8 +1382,16 @@ static void tda998x_connector_destroy(struct
drm_connector *connector)
drm_connector_cleanup(connector);
}
+static int tda998x_connector_dpms(struct drm_connector *connector, int mode)
+{
+ if (drm_core_check_feature(connector->dev, DRIVER_ATOMIC))
+ return drm_atomic_helper_connector_dpms(connector, mode);
+ else
+ return drm_helper_connector_dpms(connector, mode);
+}
+
static const struct drm_connector_funcs tda998x_connector_funcs = {
- .dpms = drm_atomic_helper_connector_dpms,
+ .dpms = tda998x_connector_dpms,
.reset = drm_atomic_helper_connector_reset,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = tda998x_connector_detect,
--
1.9.1
[Bug 93737] egl segfault since gallium/radeon: implement PIPE_CAP_INVALIDATE_BUFFER
https://bugs.freedesktop.org/show_bug.cgi?id=93737 --- Comment #3 from Andy Furniss --- Thanks, they do fix it for me. I'll close when they are in. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/0c721c63/attachment.html>
[PATCH RFC] drm/i2c: tda998x: Only set atomic funcs if bound to atomic drm driver
On 01/15/16 16:09, Liviu.Dudau at arm.com wrote:
> On Fri, Jan 15, 2016 at 02:55:26PM +0200, Jyri Sarha wrote:
>> I am not sure if this is the best way to fix the issue, but after
>> 9736e988d328 Beaglebone-Black HDMI is totally broken and this fixes
>> the issue. I am currently working on atomic modesetting for tilcdc,
>> but there is no way it makes it to 4.5 release.
>
> Yes, I'm not a big fan of the change either. I would've thought that
> you only need to update the .dpms pointer, all other hooks added are
> specific to atomic operations (right?). Would it not be simpler to have
> a tda998x_connector_dpms() function that calls the appropriate .dpms
> function based on the feature check?
>
Oh yes, that sound like a better idea, but si and appears to work too.
I'll send another patch soon. Thanks.
Best regards,
Jyri
> Best regards,
> Liviu
>
>>
>> Best regards,
>> Jyri
>>
>> drivers/gpu/drm/i2c/tda998x_drv.c | 17 +++--
>> 1 file changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
>> b/drivers/gpu/drm/i2c/tda998x_drv.c
>> index 012d36d..67d1408 100644
>> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
>> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
>> @@ -1382,7 +1382,7 @@ static void tda998x_connector_destroy(struct
>> drm_connector *connector)
>> drm_connector_cleanup(connector);
>> }
>>
>> -static const struct drm_connector_funcs tda998x_connector_funcs = {
>> +static const struct drm_connector_funcs tda998x_connector_atomic_funcs = {
>> .dpms = drm_atomic_helper_connector_dpms,
>> .reset = drm_atomic_helper_connector_reset,
>> .fill_modes = drm_helper_probe_single_connector_modes,
>> @@ -1392,15 +1392,28 @@ static const struct drm_connector_funcs
>> tda998x_connector_funcs = {
>> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>> };
>>
>> +static const struct drm_connector_funcs tda998x_connector_funcs = {
>> +.dpms = drm_helper_connector_dpms,
>> +.fill_modes = drm_helper_probe_single_connector_modes,
>> +.detect = tda998x_connector_detect,
>> +.destroy = tda998x_connector_destroy,make[4]: *** [drivers/g
>> +};
>> +
>> static int tda998x_bind(struct device *dev, struct device *master, void
>> *data)
>> {
>> struct tda998x_encoder_params *params = dev->platform_data;
>> struct i2c_client *client = to_i2c_client(dev);
>> struct drm_device *drm = data;
>> struct tda998x_priv *priv;
>> +const struct drm_connector_funcs *connector_funcs;
>> u32 crtcs = 0;
>> int ret;
>> make[4]: *** [drivers/g
>> +if (drm_core_check_feature(drm, DRIVER_ATOMIC))
>> +connector_funcs = _connector_atomic_funcs;
>> +else
>> +connector_funcs = _connector_funcs;
>> +
>> priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>> if (!priv)
>> return -ENOMEM;
>> @@ -1437,7 +1450,7 @@ static int tda998x_bind(struct device *dev, struct
>> device *master, void *data)
>> drm_connector_helper_add(>connector,
>> _connector_helper_funcs);
>> ret = drm_connector_init(drm, >connector,
>> - _connector_funcs,
>> + connector_funcs,
>> DRM_MODE_CONNECTOR_HDMIA);
>> if (ret)
>> goto err_connector;
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[Bug 92270] Radeon R7 M260/M265 - *ERROR* amdgpu: ring 0 test failed (scratch(0xC040)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=92270 --- Comment #8 from Chris --- I'm also experiencing this bug with a Radeon 6850 and GNOME 3 desktop, on following systems: Ubuntu 14.04 with 3.19 kernel and fglrx drivers. openSUSE Leap 42.1 with open source drivers. It happens when I resume from suspend. System hangs and switching to tty1 displays all the errors such as "ring 0 test failed", etc. From there, I have to shutdown the system if I want to use it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/7fd4b576/attachment.html>
[PATCH] configure.ac: disable annoying warning -Wmissing-field-initializers
Hi
On Fri, Jan 15, 2016 at 4:24 PM, Marek Olšák wrote:
> On Fri, Jan 15, 2016 at 12:12 PM, Emil Velikov
> wrote:
>> On 12 January 2016 at 23:14, Marek Olšák wrote:
>>> From: Marek Olšák
>>>
>>> It warns for all "{}" initializers. Well, I want us to use {}.
>>> ---
>>> configure.ac | 3 ++-
>>> intel/intel_decode.c | 2 --
>> The whole of libdrm, minus the intel_decode can get away without using
>> such constructs. And yes that includes radeon and amdgpu.
>>
>> NACK on this one - please be consistent with existing code base.
>
> Consistent with what? {} is the same as memset on each structure
> member. The warning says that a structure member is initialized to
> zero because of {}, which is why {} is used in the first place. It's
> the same as using memset and getting a warning "memset initializes the
> memory to zero". How useful is that?
The only use of this warning is to prevent people from learning that
{} initializes any non-specified field to 0.
Reviewed-by: David Herrmann
Thanks
David
[Bug 93737] egl segfault since gallium/radeon: implement PIPE_CAP_INVALIDATE_BUFFER
https://bugs.freedesktop.org/show_bug.cgi?id=93737 --- Comment #2 from Nicolai Hähnle --- You may also need this one: https://patchwork.freedesktop.org/patch/70593/ -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/d9e18e71/attachment.html>
[Bug 93737] egl segfault since gallium/radeon: implement PIPE_CAP_INVALIDATE_BUFFER
https://bugs.freedesktop.org/show_bug.cgi?id=93737 --- Comment #1 from Nicolai Hähnle --- Sorry for the regression. I believe Michel already has a fix for this, see https://patchwork.freedesktop.org/patch/70592/ -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/6843a3e2/attachment.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #28 from Maxim Sheviakov --- > and I believe unrelated to the one discussed here Actually, it is. All the logs and fixes comply with my problem (not only mine, heh). I think that the problem lies deeper than we think - here's why it is so: My rig is equipped with Radeon R7 370 Armor 2X from MSI. It's a GCN1.0 GPU based off Cape Verde/Curacao PRO chip from R9 270X. It doesn't matter that the memory clock is lower than it should at 800MHz (if quad-pumped, or 200MHz if you like), another thing does: people with GCN1.1+ GPUs can run the game flawlessly without issues like mine/Jurgen's - it just works. However, many GCN1.0-cards owners claim they have the same issue. Maybe we should look into RadeonSI driver's source if there are any acting differences between GCN1.0 and 1.1+ GPUs' code? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/db35a72e/attachment.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #27 from Maxim Sheviakov --- It actually is there, sorry: > glsl: assign varying locations to tess shaders when doing SSO But that doesn't make anything work. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/5aabd0eb/attachment.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #26 from Maxim Sheviakov --- (In reply to Ilia Mirkin from comment #25) > (In reply to Maxim Sheviakov from comment #24) > > So, the fix isn't present in 11.1.1 ver, for which it was planned (as far as > > I'm concerned). What's wrong and when will it be avalible for stable users? > > http://cgit.freedesktop.org/mesa/mesa/commit/?h=11. > 1=66e0a26b56d80921e886195e4be550b8d033d7e9 > > My fix is in 11.1.1. There can, of course, be additional issues. That said, > outside of the fact that the game plays like a slideshow on my super-slow > GF108 GPU, it was mostly fine. (There's an additional issue which is that > the game does GL calls from different threads, in a perfectly legal manner, > which totally breaks nouveau sometimes. That's a larger issue and I believe > unrelated to the one discussed here.) Weird thing, then... It's strange. I'm on Archlinux here. I've got mesa-11.1.1 and lib32-mesa-11.1.1 compiled by myself. And after removing that tempfix (additional launch settings) I get the same issue as if I was at mesa-11.1, for example - freeze of the game at the logo. However, with those parameters it's okay. I can't also see the fix in the release notes at cgit. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/a8b84eff/attachment.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #25 from Ilia Mirkin --- (In reply to Maxim Sheviakov from comment #24) > So, the fix isn't present in 11.1.1 ver, for which it was planned (as far as > I'm concerned). What's wrong and when will it be avalible for stable users? http://cgit.freedesktop.org/mesa/mesa/commit/?h=11.1=66e0a26b56d80921e886195e4be550b8d033d7e9 My fix is in 11.1.1. There can, of course, be additional issues. That said, outside of the fact that the game plays like a slideshow on my super-slow GF108 GPU, it was mostly fine. (There's an additional issue which is that the game does GL calls from different threads, in a perfectly legal manner, which totally breaks nouveau sometimes. That's a larger issue and I believe unrelated to the one discussed here.) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/925827e4/attachment.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 Maxim Sheviakov changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #24 from Maxim Sheviakov --- So, the fix isn't present in 11.1.1 ver, for which it was planned (as far as I'm concerned). What's wrong and when will it be avalible for stable users? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/c22138ee/attachment.html>
[Bug 93292] "Thea: The Awakening" world map textures not rendered (blue background)
https://bugs.freedesktop.org/show_bug.cgi?id=93292 --- Comment #4 from Jan-Marek Glogowski --- I uploaded a new apitrace with low details settings and disabled intro video, which makes it much smaller (170 MB xz). https://docs.google.com/uc?id=0Bwde9zQo1PeCVVdZU2ZSM3hKcXc=download While I was at it I played a bit with qapitrace, comparing the r600 and swrast output. And I found the origin of the bug. The "breaking" call is "1247216" in the new trace: glDrawElements(mode = GL_TRIANGLES, count = 600, type = GL_UNSIGNED_SHORT, indices = NULL) The call "destroys" the depth map, filling it with a constant value, so nothing is rendered. Actually I suspect the glUseProgram(87) in call 1247202 to be the origin of the problem, as it installs a shader program (AFAIK OpenGL) and because I'm able to play Thea using the llvm r600 backend via "R600_DEBUG=llvm" and if I disable "ambient occlusion", which is also broken. My current mesa build is based on commit 6303231a1ddf646b05c43c6bbc7fa71314ebb3fc -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/c5ff8c30/attachment-0001.html>
[linux-sunxi] [PATCH v2 16/26] drm: Add Allwinner A10 Display Engine support
On Thu, 2016-01-14 at 16:24 +0100, Maxime Ripard wrote: > The Allwinner A10 and subsequent SoCs share the same display pipeline, with > variations in the number of controllers (1 or 2), or the presence or not of > some output (HDMI, TV, VGA) or not. >Â > Add a driver with a limited set of features for now, and we will hopefully > support all of them eventually >Â [..] > diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h > b/drivers/gpu/drm/sun4i/sun4i_backend.h > new file mode 100644 > index ..60f6a200fa73 > --- /dev/null > +++ b/drivers/gpu/drm/sun4i/sun4i_backend.h > @@ -0,0 +1,160 @@ > +/* > + * Copyright (C) 2015 Free Electrons > + * Copyright (C) 2015 NextThing Co > + * > + * Maxime Ripard > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of > + * the License, or (at your option) any later version. > + */ > + > +#ifndef _SUN4I_BACKEND_H_ > +#define _SUN4I_BACKEND_H_ > + > +#include > +#include > + > +#define SUN4I_BACKEND_MODCTL_REG 0x800 > +#define SUN4I_BACKEND_MODCTL_LINE_SELBIT(29) > +#define SUN4I_BACKEND_MODCTL_ITLMOD_EN BIT(28 > ) > +#define SUN4I_BACKEND_MODCTL_OUT_SEL GENMASK( > 22, 20) > +#define SUN4I_BACKEND_MODCTL_OUT_LCD > (0 << 20) > +#define SUN4I_BACKEND_MODCTL_OUT_FE0 > (6 << 20) > +#define SUN4I_BACKEND_MODCTL_OUT_FE1 > (7 << 20) > +#define SUN4I_BACKEND_MODCTL_HWC_EN BIT(16) > +#define SUN4I_BACKEND_MODCTL_LAY_EN(l) BIT(8 > + l) > +#define SUN4I_BACKEND_MODCTL_OCSC_EN BIT(5) > +#define SUN4I_BACKEND_MODCTL_DFLK_EN BIT(4) > +#define SUN4I_BACKEND_MODCTL_DLP_START_CTL BIT(2) > +#define SUN4I_BACKEND_MODCTL_START_CTL BIT(1) > +#define SUN4I_BACKEND_MODCTL_DEBE_EN BIT(0) > + > +#define SUN4I_BACKEND_BACKCOLOR_REG 0x804 > +#define SUN4I_BACKEND_BACKCOLOR(r, g, b) (((r) << 16) > | ((g) << 8) | (b)) > + > +#define SUN4I_BACKEND_DISSIZE_REG0x808 > +#define SUN4I_BACKEND_DISSIZE(w, h) (h) - > 1) & 0x) << 16) | \ > + Â (((w) - 1) > & 0x)) > + > +#define SUN4I_BACKEND_LAYSIZE_REG(l) (0x810 + (0x4 * > (l))) > +#define SUN4I_BACKEND_LAYSIZE(w, h) (h) - > 1) & 0x1fff) << 16) | \ > + Â (((w) - 1) > & 0x1fff)) > + > +#define SUN4I_BACKEND_LAYCOOR_REG(l) (0x820 + (0x4 * > (l))) > +#define SUN4I_BACKEND_LAYCOOR(x, y) u32)( > y) & 0x) << 16) | \ > + Â ((u32)(x) & > 0x)) > + > +#define SUN4I_BACKEND_LAYLINEWIDTH_REG(l)(0x840 + (0x4 * > (l))) > + > +#define SUN4I_BACKEND_LAYFB_L32ADD_REG(l)(0x850 + (0x4 * > (l))) > + > +#define SUN4I_BACKEND_LAYFB_H4ADD_REG0x860 > +#define SUN4I_BACKEND_LAYFB_H4ADD_MSK(l) GENMASK(3 + > ((l) * 8), 0) > +#define SUN4I_BACKEND_LAYFB_H4ADD(l, val)((v > al) << ((l) * 8)) > + > +#define SUN4I_BACKEND_REGBUFFCTL_REG 0x870 > +#define SUN4I_BACKEND_REGBUFFCTL_AUTOLOAD_DISBIT(1) > +#define SUN4I_BACKEND_REGBUFFCTL_LOADCTL BIT(0) > + > +#define SUN4I_BACKEND_CKMAX_REG 0x880 > +#define SUN4I_BACKEND_CKMIN_REG 0x884 > +#define SUN4I_BACKEND_CKCFG_REG 0x888 > +#define SUN4I_BACKEND_ATTCTL_REG0(l) (0x890 + (0x4 * > (l))) > +#define SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL_MASK BIT(15) > +#define SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL(x) ((x) > << 15) > +#define SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL_MASKGENMASK(11, > 10) > +#define SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL(x) > ((x) << 10) > + > +#define SUN4I_BACKEND_ATTCTL_REG1(l) (0x8a0 + (0x4 * > (l))) > +#define SUN4I_BACKEND_ATTCTL_REG1_LAY_HSCAFCTGENMASK > (15, 14) > +#define SUN4I_BACKEND_ATTCTL_REG1_LAY_WSCAFCTGENMASK > (13, 12) > +#define SUN4I_BACKEND_ATTCTL_REG1_LAY_FBFMT GENMASK(1 > 1, 8) > +#define SUN4I_BACKEND_LAY_FBFMT_1BPP > (0 << 8) > +#define SUN4I_BACKEND_LAY_FBFMT_2BPP > (1 << 8) > +#define SUN4I_BACKEND_LAY_FBFMT_4BPP > (2 << 8) > +#define SUN4I_BACKEND_LAY_FBFMT_8BPP > (3 << 8) > +#define SUN4I_BACKEND_LAY_FBFMT_RGB655 > (4 << 8) > +#define SUN4I_BACKEND_LAY_FBFMT_RGB565 > (5 << 8) > +#define SUN4I_BACKEND_LAY_FBFMT_RGB556 > (6 << 8) > +#define
[Bug 93614] Tonga general protection fault in libdrm_amdgpu at di.fm
https://bugs.freedesktop.org/show_bug.cgi?id=93614 Brian Paterni changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Brian Paterni --- Not sure exactly which package provided the fix, but now I'm no longer seeing the fault, and also the stream on di.fm launches more consistently now. Recently updated packages and versions: libdrm: 2.4.66-2 mesa: 11.1.1-2 Thanks to all working on this! :) Closing this bug -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/5c262d57/attachment.html>
[Bug 92858] AMD Radeon GPU Acceleration Disabled Under Kernels 4.2.x and later versions
https://bugs.freedesktop.org/show_bug.cgi?id=92858 --- Comment #19 from Darren --- (In reply to Michel Dänzer from comment #18) > Darren, why did you resolve this report as invalid? I didn't see you response earlier. My email I used to make the account expired so I had to make a new one and log back in. Anyhow, I thus far have still been unable to locate the commit that broke acceleration due to unbootable kernels. It's time consuming and got to be frustrating. At this point, I'll buy a replacement video card or switch to the built-in and sell the discrete card instead. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/e3bf9dad/attachment.html>
[linux-sunxi] [PATCH v2 05/26] clk: sunxi: Add display and TCON0 clocks driver
On Thu, 2016-01-14 at 16:24 +0100, Maxime Ripard wrote:
> The A10 SoCs and its relatives has a special clock controller to drive the
> display engines (both frontend and backend), that have a lot in common with
> the clock to drive the first TCON channel.
>
> Add a driver to support both.
...
> +static void __init sun4i_a10_display_init(struct device_node *node,
> + Â Â struct sun4i_a10_display_clk_data
> *data)
> +{
> + const char *parents[data->parents];
> + const char *clk_name = node->name;
> + struct reset_data *reset_data;
> + struct clk_divider *div = NULL;
> + struct clk_gate *gate;
> + struct clk_mux *mux;
> + void __iomem *reg;
> + struct clk *clk;
> + int i;
warning: unused variable 'i'
> +
> + of_property_read_string(node, "clock-output-names", _name);
> +
> + reg = of_io_request_and_map(node, 0, of_node_full_name(node));
> + if (IS_ERR(reg)) {
> + pr_err("%s: Could not map the clock registers\n", clk_name);
> + return;
> + }
...
Thanks for working on this feature ;)
Päikest,
Priit Laes
[Bug 93737] egl segfault since gallium/radeon: implement PIPE_CAP_INVALIDATE_BUFFER
https://bugs.freedesktop.org/show_bug.cgi?id=93737 Bug ID: 93737 Summary: egl segfault since gallium/radeon: implement PIPE_CAP_INVALIDATE_BUFFER Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: adf.lists at gmail.com QA Contact: dri-devel at lists.freedesktop.org R9285 first noticed trying to set up wayland/weston, bisected with eglgears_x11. Since - commit 321140d563730b210e6390c5b73c09fdcf9649af Author: Nicolai Hähnle Date: Thu Jan 14 09:41:04 2016 -0500 gallium/radeon: implement PIPE_CAP_INVALIDATE_BUFFER I get segfaults trying to run egl. bt from gears Program received signal SIGSEGV, Segmentation fault. 0x7239fb23 in r600_do_invalidate_resource (rctx=0x692b30, rbuffer=0x0) at r600_buffer_common.c:219 219 if (rctx->ws->buffer_is_user_ptr(rbuffer->buf)) (gdb) bt #0 0x7239fb23 in r600_do_invalidate_resource (rctx=0x692b30, rbuffer=0x0) at r600_buffer_common.c:219 #1 0x72210dd2 in dri_flush (cPriv=, dPriv=, flags=5, reason=) at dri_drawable.c:496 #2 0x7645ddb8 in dri2_x11_swap_buffers_msc (msc=0, divisor=0, remainder=0, drv=, draw=0x6f9160, disp=) at drivers/dri2/platform_x11.c:837 #3 dri2_x11_swap_buffers (drv=, disp=, draw=0x6f9160) at drivers/dri2/platform_x11.c:873 #4 0x76453d76 in eglSwapBuffers (dpy=0x62af30, surface=) at main/eglapi.c:1010 #5 0x00403a71 in _eglutNativeEventLoop () at eglut_x11.c:249 #6 0x0040328b in eglutMainLoop () at eglut.c:272 #7 0x00401d16 in main (argc=1, argv=0x7fffe108) at eglgears.c:298 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/ed18ec48/attachment.html>
[PATCH] configure.ac: disable annoying warning -Wmissing-field-initializers
Reviewed-by: Ilia Mirkin
On Tue, Jan 12, 2016 at 4:14 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> It warns for all "{}" initializers. Well, I want us to use {}.
> ---
> configure.ac | 3 ++-
> intel/intel_decode.c | 2 --
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index c8c4ace..057a846 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -174,7 +174,8 @@ MAYBE_WARN="-Wall -Wextra \
> -Wstrict-aliasing=2 -Winit-self \
> -Wdeclaration-after-statement -Wold-style-definition \
> -Wno-unused-parameter \
> --Wno-attributes -Wno-long-long -Winline -Wshadow"
> +-Wno-attributes -Wno-long-long -Winline -Wshadow \
> +-Wno-missing-field-initializers"
>
> # invalidate cached value if MAYBE_WARN has changed
> if test "x$libdrm_cv_warn_maybe" != "x$MAYBE_WARN"; then
> diff --git a/intel/intel_decode.c b/intel/intel_decode.c
> index e7aef74..287c342 100644
> --- a/intel/intel_decode.c
> +++ b/intel/intel_decode.c
> @@ -38,8 +38,6 @@
> #include "intel_chipset.h"
> #include "intel_bufmgr.h"
>
> -/* The compiler throws ~90 warnings. Do not spam the build, until we fix
> them. */
> -#pragma GCC diagnostic ignored "-Wmissing-field-initializers"
>
> /* Struct for tracking drm_intel_decode state. */
> struct drm_intel_decode {
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
Porting GCN pre-1.2 parts from radeon to amdgpu kernel driver
Hello to both of you, I've been following the development mostly of the radeon driver for some time (with some small commits here and there as you may know). I was waiting to hear some news about the coming support of Vulkan API. And I have been wondering for sometime now if it would be a good think to have all GCN parts moved from the radeon driver to the amdgpu kernel driver (I had figured out it would be possible, but would it be of any use was still unanswered). I was also curious to know if the new Crimson software would support the radeon driver at some point. Now, I may have had a clear answer: I just read from Phoronix' editor Michael Larabel (http://www.phoronix.com/scan.php?page=news_item=Help-Bring-Older-GCN-To-AMDGPU) that Vulkan would come to the amdgpu driver only, that the blob (which should eventually be opened) would support all GCN parts and that the only missing part to support GCN pre-1.2 parts with both Vulkan and Crimson would be to have them ported from the radeon driver to the amdgpu driver. Am I understanding correctly? I'd be interested to know a bit more about the task and I may try to start the work or join someone who would already be interested in doing so. Any comments on the matter? Any missunderstood thing? Cheers! -- Alexandre Demers
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #58 from Julian --- In case anyone is interested, I've hacked together a GNOME extension that adds a status icon showing the current DPM setting and a popup menu to easily switch: https://github.com/JuBan1/radeon-dpm-control.git It only handles three combinations of settings: low/battery, auto/balanced, high/performance. I don't think the others are particularly useful. It makes use of Thomas DEBESSE's dpm-query script a few comments earlier. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/c0ee0630/attachment.html>
[Bug 89155] Dual monitor setup does not initialize
https://bugs.freedesktop.org/show_bug.cgi?id=89155 --- Comment #6 from Adam Reichold --- Maybe of interest w.r.t this: Running kernel 4.3.3. by now, I found a seemingly reliable workaround, i.e. if the VGA-connected monitor does not initialize after boot, it will always properly initialize when I put the system into suspend-to-memory and wake it up again immediately after that. (But the VGA-connected monitor will sometimes go dark for a few seconds some time after it initialized for the first time.) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/aecf9a08/attachment.html>
[Bug 93648] Random lines being rendered when playing Dolphin (geometry shaders related, w/ apitrace)
https://bugs.freedesktop.org/show_bug.cgi?id=93648 --- Comment #4 from Timothy Arceri --- (In reply to Ilia Mirkin from comment #3) > I tested on a SNB and couldn't reproduce any artifacts on the apitrace > (after forcing ARB_conservative_depth on). Even if I could, it'd be very > surprising if the issues were related. Unless you have concrete evidence to > the contrary, I'd keep it to one bug per issue that you see. Issues can be > combined later on, but are difficult to break apart. Switching this one back > to radeonsi. > > Any issues you see on other hardware should include an apitrace taken on > that hw. I think Pierre was referring to bug #93418 it already has an apitrace for SNB I tried it a while ago on my Ivy Bridge and it also worked fine there. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/ebe29531/attachment.html>
[Bug 93648] Random lines being rendered when playing Dolphin (geometry shaders related, w/ apitrace)
https://bugs.freedesktop.org/show_bug.cgi?id=93648 Ilia Mirkin changed: What|Removed |Added Component|Mesa core |Drivers/Gallium/radeonsi Assignee|mesa-dev at lists.freedesktop. |dri-devel at lists.freedesktop |org |.org QA Contact|mesa-dev at lists.freedesktop. |dri-devel at lists.freedesktop |org |.org --- Comment #3 from Ilia Mirkin --- I tested on a SNB and couldn't reproduce any artifacts on the apitrace (after forcing ARB_conservative_depth on). Even if I could, it'd be very surprising if the issues were related. Unless you have concrete evidence to the contrary, I'd keep it to one bug per issue that you see. Issues can be combined later on, but are difficult to break apart. Switching this one back to radeonsi. Any issues you see on other hardware should include an apitrace taken on that hw. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/96b4d120/attachment-0001.html>
[Bug 93648] Random lines being rendered when playing Dolphin on radeonsi (w/ apitrace)
https://bugs.freedesktop.org/show_bug.cgi?id=93648 Pierre Bourdon changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|Mesa core Assignee|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org QA Contact|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org --- Comment #2 from Pierre Bourdon --- I haven't been able to test that myself, but other Dolphin users have reported the same symptoms on Intel Sandybridge IGPs. Our automated tests on Broadwell don't seem see that issue however, and my own laptop on Haswell doesn't see that issue either. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160116/0afec115/attachment.html>
r600/shader: emit tessellation factors to GDS at end of TCS.
On 15 January 2016 at 12:25, Dieter Nützel wrote: > Hello Dave, > > first all the best for your newborn and your whole family! Thanks, > > Second: > What could be differend between r6xx/r7xx and EG+ (NI, here) that the below > fixes the 'gsraytrace' GPU hang on the later but NOT on the former? > > Any ideas, hints where I could start? > r6xx/r7xx do not have any TESS support as we now. > So where to start? > Disabling some lines of your commit and try? This commit just fixed things by luck on EG I suppose, it must be the NOP at the end of the shader, and I think on r600/700 that could should still happen, I'd probably need to spend some time staring at fglrx dumps to work out why we crash, does R600_DEBUG=nosb help at all? Dave.
linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon
On 01/15/2016 01:26 PM, Ville Syrjälä wrote: > On Fri, Jan 15, 2016 at 11:34:08AM +0100, Vlastimil Babka wrote: >> Hi, >> >> since kernel 4.4 I'm unable to login to kde5 desktop (on openSUSE >> Tumbleweed). There's a screen with progressbar showing the startup, >> which normally fades away after reaching 100%. But with kernel 4.4, the >> progress gets stuck somewhere between 1/2 and 3/4 (not always the same). >> Top shows that kwin is using few % of CPU's but mostly sleeps in poll(). >> When I kill it from another console, I see that everything has actually >> started up, just the progressbar screen was obscuring it. The windows >> obviously don't have decorations etc. Starting kwin manually again shows >> me again the progressbar screen at the same position. > Depressing. I was stress-testing those patches with Linux 4.4 for days on 2 AMD gpu's (HD-4000 RV 730 and HD-5770) under KDE 5 Plasma 5.4.2 (KUbuntu 15.10, XOrg 1.17) and just retested Linux 4.4 on nouveau/radeon/intel also with XOrg 1.18 and XOrg master) with Linux 4.4 a few days ago and never encountered such a hang or other vblank related problem on KDE-5 or GNOME-3. I'm currently running... while xinit /usr/bin/ksplashqml --test -- :1 ; do echo yay; done ... in an endless loop on Linux 4.4 SMP PREEMPT on HD-5770 and so far i can't trigger a hang after hundreds of runs. Does this also hang for you? > Hmm. Sounds like it could then be waiting for a vblank in the distant > future. There's that 1<<23 limit in the code though, but even with that > we end up with a max wait of ~38 hours assuming a 60Hz refresh rate. > xtrace suggests that ksplashqml seems to use classic OpenGL + glXSwapBuffers under DRI2. So no clever swap scheduling based on vblank counter values. > Stuff to try might include enabling drm.debug=0x2f, though that'll > generate a lot of stuff. Another option would be to use the drm vblank > tracepoints to try and catch what seq number it's waiting for and > where we're at currently. Or I suppose you could just hack > up drm_wait_vblank() to print an error message or something if the > requested seq number is in the future by, say, more than a few seconds, > and if that's the case then we could try to figure out why that happens. > >> >> I have suspected that kwin is waiting for some event, but nevertheless >> tried bisecting the kernel between 4.3 and 4.4, which lead to: >> >> # first bad commit: [4dfd64862ff852df7b1198d667dda778715ee88f] drm: Use >> vblank timestamps to guesstimate how many vblanks were missed >> >> I can confirm that 4.4 works if I revert the following commits: >> 63154ff230fc9255cc507af6277cd181943c50a1 "drm/amdgpu: Fixup hw vblank >> counter/ts for new drm_update_vblank_count() (v3)" >> >> d1145ad1e41b6c33758a856163198cb53bb96a50 "drm/radeon: Fixup hw vblank >> counter/ts for new drm_update_vblank_count() (v2)" > > The sha1s don't seem to match what I have, so not sure which kernel tree > you have, but looking at the radeon commit at least one thing > immediately caught my attention; > > + /* Bump counter if we are at >= leading edge of > vblank, > +* but before vsync where vpos would turn negative and > +* the hw counter really increments. > +*/ > + if (vpos >= 0) > + count++; > > It's rather hard to see what it's really doing since the custom flags to > the get_scanout_position now cause it return non-standard things. But if > I'm reading things correctly it should really say something like: > > if (vpos >= 0 && vpos < (vsync_start - vblank_start)) > count++; > > Hmm. Actually even that might not be correct since it could be using the > "fake" vblank start here, so might be it'd need to be something like: > > if (vpos >= 0 && vpos < (vsync_start - vblank_start + lb_vblank_lead_lines) > count++; > The current code should be correct. vpos here returns the distance of hw vertical scanout position to the start of vblank. According to Alex and Harry Wentland of AMD's display team, and my testing of my two cards the hw vertical scanout position resets to zero at start line of vsync, therefore the "vpos" in that code becomes negative at start of vsync. At the same time the hw frame counter increments by one, making that "count++" to bump the returned count by +1 no longer neccessary. If the reset of hw vertical scanout pos to zero and the increment of hw frame counter wouldn't happen at exactly the same time at start of vsync i could see how that could cause two successive queries of driver->get_vblank_counter() could report a count of N+1 and then N if the timing of both calls would be just perfectly right. That would cause the DRM code to falsely detect counter wraparound and jump the vblank counter forward by 2^24. My tested gpu's had DCE-3 or DCE-4 display engines, Caicos has DCE-5, so could this be some hw quirk for
r600/shader: emit tessellation factors to GDS at end of TCS.
Am 15.01.2016 21:04, schrieb Dave Airlie: > On 15 January 2016 at 12:25, Dieter Nützel > wrote: >> Hello Dave, >> Second: >> What could be differend between r6xx/r7xx and EG+ (NI, here) that the >> below >> fixes the 'gsraytrace' GPU hang on the later but NOT on the former? >> >> Any ideas, hints where I could start? >> r6xx/r7xx do not have any TESS support as we now. >> So where to start? >> Disabling some lines of your commit and try? > > This commit just fixed things by luck on EG I suppose, I called it by 'accident' ;-) Look, here: Bug 91865 - [r600g] GPU hang in 'gsraytrace' - NI/Turks (6670) https://bugs.freedesktop.org/show_bug.cgi?id=91865#c10 > it must be the NOP > at the end of the shader, and I think on r600/700 that could should > still happen, > > I'd probably need to spend some time staring at fglrx dumps to work out > why > we crash, does R600_DEBUG=nosb help at all? Not at all, for me on EG and RV730. With the commit it crash on RV730 for 'gsraytrace': Bug 83319 - [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) - RV730 https://bugs.freedesktop.org/show_bug.cgi?id=83319#c15 For all other cases with R600_DEBUG=nosb vsraytrace and fsraytrace on RV730, vsraytrace, fsraytrace and gsraytrace on EG it show the damages like below (see attachments): Bug 93715 - [r600g] rendering issues with R600_DEBUG=nosb for all three 'raytrace' variants BTW gsraytrace on EG is now better than with fglrx (15.11?) Let me know when I should test sth on RV730. Thanks for looking at it. -Dieter
