dri-devel October 2018

dri-devel@lists.freedesktop.org

277 participants
1898 discussions

[PATCH] drm/etnaviv: fix bogus fence complete check in timeout handler
by Lucas Stach 04 Oct '18

04 Oct '18

The GPU hardware fences and the job out-fences are on different timelines so it's wrong to compare them. Fix this by only looking at the out-fence. Fixes: 2c83a726d6fb (drm/etnaviv: bring back progress check in job timeout handler) Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> --- drivers/gpu/drm/etnaviv/etnaviv_sched.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c b/drivers/gpu/drm/etnaviv/etnaviv_sched.c index 69e9b431bf1f..e5a9fae31ab7 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c @@ -93,7 +93,7 @@ static void etnaviv_sched_timedout_job(struct drm_sched_job *sched_job) * If the GPU managed to complete this jobs fence, the timout is * spurious. Bail out. */ - if (fence_completed(gpu, submit->out_fence->seqno)) + if (dma_fence_is_signaled(submit->out_fence)) return; /* -- 2.19.0

1 0

[PULL] drm-intel-next-fixes
by Joonas Lahtinen 04 Oct '18

04 Oct '18

Hi Dave, Here comes -fixes for drm-next. One compiler warning fix and adding back a removed max stride check, nothing end user visible. Regards, Joonas PS. Travelling next week, so I'll skip PR unless there's something big. --- drm-intel-next-fixes-2018-10-04: Compiler warning fix and adding back a removed max stride check for sprite planes. The following changes since commit 87c2ee740c07f1edae9eec8bc45cb9b32a68f323: Merge branch 'drm-next-4.20' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-09-28 09:48:40 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2018-10-04 for you to fetch changes up to 98a9bce38b3d93082353fda561abb73a4d7b8d94: drm/i915: Avoid compiler warning for maybe unused gu_misc_iir (2018-10-01 11:58:17 +0300) ---------------------------------------------------------------- Compiler warning fix and adding back a removed max stride check for sprite planes. ---------------------------------------------------------------- Chris Wilson (1): drm/i915: Avoid compiler warning for maybe unused gu_misc_iir Ville Syrjälä (1): drm/i915: Check fb stride against plane max stride drivers/gpu/drm/i915/i915_irq.c | 33 ++++++++++++--------------------- drivers/gpu/drm/i915/intel_display.c | 14 ++++++++++++++ drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_sprite.c | 22 ++++++++++++++++++++++ 4 files changed, 49 insertions(+), 21 deletions(-)

1 0

[PATCH 1/6] drm/bridge: use bus flags in bridge timings
by Stefan Agner 04 Oct '18

04 Oct '18

The DRM bus flags convey additional information on pixel data on the bus. All current available bus flags might be of interest for a bridge. Remove the sampling_edge field and use bus_flags. In the case at hand a dumb VGA bridge needs a specific data enable polarity (DRM_BUS_FLAG_DE_LOW). Signed-off-by: Stefan Agner <stefan(a)agner.ch> --- drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 +++--- include/drm/drm_bridge.h | 11 +++++------ 2 files changed, 8 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c index 9b706789a341..7a5c24967115 100644 --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c @@ -234,7 +234,7 @@ static int dumb_vga_remove(struct platform_device *pdev) */ static const struct drm_bridge_timings default_dac_timings = { /* Timing specifications, datasheet page 7 */ - .sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE, + .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE, .setup_time_ps = 500, .hold_time_ps = 1500, }; @@ -245,7 +245,7 @@ static const struct drm_bridge_timings default_dac_timings = { */ static const struct drm_bridge_timings ti_ths8134_dac_timings = { /* From timing diagram, datasheet page 9 */ - .sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE, + .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE, /* From datasheet, page 12 */ .setup_time_ps = 3000, /* I guess this means latched input */ @@ -258,7 +258,7 @@ static const struct drm_bridge_timings ti_ths8134_dac_timings = { */ static const struct drm_bridge_timings ti_ths8135_dac_timings = { /* From timing diagram, datasheet page 14 */ - .sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE, + .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE, /* From datasheet, page 16 */ .setup_time_ps = 2000, .hold_time_ps = 500, diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h index bd850747ce54..85d4b51eae19 100644 --- a/include/drm/drm_bridge.h +++ b/include/drm/drm_bridge.h @@ -244,14 +244,13 @@ struct drm_bridge_funcs { */ struct drm_bridge_timings { /** - * @sampling_edge: + * @bus_flags: * - * Tells whether the bridge samples the digital input signal - * from the display engine on the positive or negative edge of the - * clock, this should reuse the DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE - * bitwise flags from the DRM connector (bit 2 and 3 valid). + * Tells what additional settings for the pixel data on the bus + * this bridge requires (like pixel signal polarity). See also + * &drm_display_info->bus_flags. */ - u32 sampling_edge; + u32 bus_flags; /** * @setup_time_ps: * -- 2.18.0

2 6

[PATCH libdrm 1/5] [libdrm] sync drm.h for syncobj part
by Chunming Zhou 04 Oct '18

04 Oct '18

Signed-off-by: Chunming Zhou <david1.zhou(a)amd.com> --- include/drm/drm.h | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/include/drm/drm.h b/include/drm/drm.h index f0bd91de..d1688269 100644 --- a/include/drm/drm.h +++ b/include/drm/drm.h @@ -695,6 +695,7 @@ struct drm_prime_handle { struct drm_syncobj_create { __u32 handle; #define DRM_SYNCOBJ_CREATE_SIGNALED (1 << 0) +#define DRM_SYNCOBJ_CREATE_TYPE_TIMELINE (1 << 1) __u32 flags; }; @@ -725,12 +726,32 @@ struct drm_syncobj_wait { __u32 pad; }; +struct drm_syncobj_timeline_wait { + __u64 handles; + /* wait on specific timeline point for every handles*/ + __u64 points; + /* absolute timeout */ + __s64 timeout_nsec; + __u32 count_handles; + __u32 flags; + __u32 first_signaled; /* only valid when not waiting all */ + __u32 pad; +}; + struct drm_syncobj_array { __u64 handles; __u32 count_handles; __u32 pad; }; +struct drm_syncobj_timeline_query { + __u64 handles; + /* points are timeline syncobjs payloads returned by query ioctl */ + __u64 points; + __u32 count_handles; + __u32 pad; +}; + /* Query current scanout sequence number */ struct drm_crtc_get_sequence { __u32 crtc_id; /* requested crtc_id */ @@ -887,6 +908,9 @@ extern "C" { #define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct drm_mode_get_lease) #define DRM_IOCTL_MODE_REVOKE_LEASE DRM_IOWR(0xC9, struct drm_mode_revoke_lease) +#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT DRM_IOWR(0xCA, struct drm_syncobj_timeline_wait) +#define DRM_IOCTL_SYNCOBJ_QUERY DRM_IOWR(0xCB, struct drm_syncobj_timeline_query) + /** * Device specific ioctls should only be in their respective headers * The device specific ioctl range is from 0x40 to 0x9f. -- 2.17.1

2 5

[PATCH v2] drm: fb-helper: Reject all pixel format changing requests
by Eugeniy Paltsev 04 Oct '18

04 Oct '18

drm fbdev emulation doesn't support changing the pixel format at all, so reject all pixel format changing requests. Cc: stable(a)vger.kernel.org Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com> --- Changes v1->v2: * Reject all pixel format changing request, not just the invalid ones. drivers/gpu/drm/drm_fb_helper.c | 91 ++++++++++++----------------------------- 1 file changed, 26 insertions(+), 65 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 16ec93b75dbf..48598d7f673f 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1580,6 +1580,25 @@ int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, } EXPORT_SYMBOL(drm_fb_helper_ioctl); +static bool drm_fb_pixel_format_equal(const struct fb_var_screeninfo *var_1, + const struct fb_var_screeninfo *var_2) +{ + return var_1->bits_per_pixel == var_2->bits_per_pixel && + var_1->grayscale == var_2->grayscale && + var_1->red.offset == var_2->red.offset && + var_1->red.length == var_2->red.length && + var_1->red.msb_right == var_2->red.msb_right && + var_1->green.offset == var_2->green.offset && + var_1->green.length == var_2->green.length && + var_1->green.msb_right == var_2->green.msb_right && + var_1->blue.offset == var_2->blue.offset && + var_1->blue.length == var_2->blue.length && + var_1->blue.msb_right == var_2->blue.msb_right && + var_1->transp.offset == var_2->transp.offset && + var_1->transp.length == var_2->transp.length && + var_1->transp.msb_right == var_2->transp.msb_right; +} + /** * drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var * @var: screeninfo to check @@ -1590,7 +1609,6 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var, { struct drm_fb_helper *fb_helper = info->par; struct drm_framebuffer *fb = fb_helper->fb; - int depth; if (var->pixclock != 0 || in_dbg_master()) return -EINVAL; @@ -1610,72 +1628,15 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var, return -EINVAL; } - switch (var->bits_per_pixel) { - case 16: - depth = (var->green.length == 6) ? 16 : 15; - break; - case 32: - depth = (var->transp.length > 0) ? 32 : 24; - break; - default: - depth = var->bits_per_pixel; - break; - } - - switch (depth) { - case 8: - var->red.offset = 0; - var->green.offset = 0; - var->blue.offset = 0; - var->red.length = 8; - var->green.length = 8; - var->blue.length = 8; - var->transp.length = 0; - var->transp.offset = 0; - break; - case 15: - var->red.offset = 10; - var->green.offset = 5; - var->blue.offset = 0; - var->red.length = 5; - var->green.length = 5; - var->blue.length = 5; - var->transp.length = 1; - var->transp.offset = 15; - break; - case 16: - var->red.offset = 11; - var->green.offset = 5; - var->blue.offset = 0; - var->red.length = 5; - var->green.length = 6; - var->blue.length = 5; - var->transp.length = 0; - var->transp.offset = 0; - break; - case 24: - var->red.offset = 16; - var->green.offset = 8; - var->blue.offset = 0; - var->red.length = 8; - var->green.length = 8; - var->blue.length = 8; - var->transp.length = 0; - var->transp.offset = 0; - break; - case 32: - var->red.offset = 16; - var->green.offset = 8; - var->blue.offset = 0; - var->red.length = 8; - var->green.length = 8; - var->blue.length = 8; - var->transp.length = 8; - var->transp.offset = 24; - break; - default: + /* + * drm fbdev emulation doesn't support changing the pixel format at all, + * so reject all pixel format changing requests. + */ + if (!drm_fb_pixel_format_equal(var, &info->var)) { + DRM_DEBUG("fbdev emulation doesn't support changing the pixel format\n"); return -EINVAL; } + return 0; } EXPORT_SYMBOL(drm_fb_helper_check_var); -- 2.14.4

3 4

[PULL] drm-misc-fixes
by Maarten Lankhorst 04 Oct '18

04 Oct '18

drm-misc-fixes-2018-10-04: drm-misc-fixes for v4.19-rc7: - Fix use-after-free in drm_mode_create_lease_ioctl() - Fix crash in fbdev error path. The following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38: Linux 4.19-rc6 (2018-09-30 07:15:35 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-10-04 for you to fetch changes up to 4d4c2d89913e2d891bd6a34b12050a2576e60525: drm/cma-helper: Fix crash in fbdev error path (2018-10-02 13:03:34 +0200) ---------------------------------------------------------------- drm-misc-fixes for v4.19-rc7: - Fix use-after-free in drm_mode_create_lease_ioctl() - Fix crash in fbdev error path. ---------------------------------------------------------------- Jann Horn (1): drm: fix use-after-free read in drm_mode_create_lease_ioctl() Noralf Trønnes (1): drm/cma-helper: Fix crash in fbdev error path drivers/gpu/drm/drm_client.c | 35 ++++++++++++++++++++++++++--------- drivers/gpu/drm/drm_fb_cma_helper.c | 4 +++- drivers/gpu/drm/drm_fb_helper.c | 4 +++- drivers/gpu/drm/drm_lease.c | 6 +++--- include/drm/drm_client.h | 5 +++-- 5 files changed, 38 insertions(+), 16 deletions(-)

1 0

[PATCH v10 1/2] drm: Add connector property to limit max bpc
by Radhakrishna Sripada 04 Oct '18

04 Oct '18

At times 12bpc HDMI cannot be driven due to faulty cables, dongles level shifters etc. To workaround them we may need to drive the output at a lower bpc. Currently the user space does not have a way to limit the bpc. The default bpc to be programmed is decided by the driver and is run against connector limitations. Creating a new connector property "max bpc" in order to limit the bpc. xrandr can make use of this connector property to make sure that bpc does not exceed the configured value. This property can be used by userspace to set the bpc. V2: Initialize max_bpc to satisfy kms_properties V3: Move the property to drm_connector V4: Split drm and i915 components(Ville) V5: Make the property per connector(Ville) V6: Compare the requested bpc to connector bpc(Daniel) Move the attach_property function to core(Ville) V7: Fix checkpatch warnings V8: Simplify the connector check code(Ville) V9: Const display_info(Ville) V10: Fix CI issues. Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Kishore Kadiyala <kishore.kadiyala(a)intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Manasi Navare <manasi.d.navare(a)intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy(a)intel.com> Cc: Sunpeng Li <sunpeng.li(a)amd.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada(a)intel.com> --- drivers/gpu/drm/drm_atomic.c | 5 +++++ drivers/gpu/drm/drm_atomic_helper.c | 4 ++++ drivers/gpu/drm/drm_atomic_uapi.c | 4 ++++ drivers/gpu/drm/drm_connector.c | 33 +++++++++++++++++++++++++++++++++ include/drm/drm_connector.h | 20 ++++++++++++++++++++ 5 files changed, 66 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 2870ae205237..f328bcca84a8 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -390,6 +390,7 @@ static int drm_atomic_connector_check(struct drm_connector *connector, { struct drm_crtc_state *crtc_state; struct drm_writeback_job *writeback_job = state->writeback_job; + const struct drm_display_info *info = &connector->display_info; if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) || !writeback_job) return 0; @@ -417,6 +418,10 @@ static int drm_atomic_connector_check(struct drm_connector *connector, return -EINVAL; } + state->max_bpc = info->bpc ? info->bpc : 8; + if (connector->max_bpc_property) + state->max_bpc = min(state->max_bpc, state->max_requested_bpc); + return 0; } diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index e49b22381048..75aeca35f6d9 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -639,6 +639,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev, if (old_connector_state->link_status != new_connector_state->link_status) new_crtc_state->connectors_changed = true; + + if (old_connector_state->max_requested_bpc != + new_connector_state->max_requested_bpc) + new_crtc_state->connectors_changed = true; } if (funcs->atomic_check) diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c index d5b7f315098c..86ac33922b09 100644 --- a/drivers/gpu/drm/drm_atomic_uapi.c +++ b/drivers/gpu/drm/drm_atomic_uapi.c @@ -740,6 +740,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector, return set_out_fence_for_connector(state->state, connector, fence_ptr); + } else if (property == connector->max_bpc_property) { + state->max_requested_bpc = val; } else if (connector->funcs->atomic_set_property) { return connector->funcs->atomic_set_property(connector, state, property, val); @@ -804,6 +806,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector, *val = 0; } else if (property == config->writeback_out_fence_ptr_property) { *val = 0; + } else if (property == connector->max_bpc_property) { + *val = state->max_requested_bpc; } else if (connector->funcs->atomic_get_property) { return connector->funcs->atomic_get_property(connector, state, property, val); diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 1e40e5decbe9..65e22c1b37a5 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -1583,6 +1583,39 @@ void drm_connector_set_link_status_property(struct drm_connector *connector, EXPORT_SYMBOL(drm_connector_set_link_status_property); /** + * drm_connector_attach_max_bpc_property - attach "max bpc" property + * @connector: connector to attach max bpc property on. + * @min: The minimum bit depth supported by the connector. + * @max: The maximum bit depth supported by the connector. + * + * This is used to add support for limiting the bit depth on a connector. + * + * Returns: + * Zero on success, negative errno on failure. + */ +int drm_connector_attach_max_bpc_property(struct drm_connector *connector, + int min, int max) +{ + struct drm_device *dev = connector->dev; + struct drm_property *prop; + + prop = connector->max_bpc_property; + if (!prop) { + prop = drm_property_create_range(dev, 0, "max bpc", min, max); + if (!prop) + return -ENOMEM; + + connector->max_bpc_property = prop; + } + + drm_object_attach_property(&connector->base, prop, max); + connector->state->max_requested_bpc = max; + + return 0; +} +EXPORT_SYMBOL(drm_connector_attach_max_bpc_property); + +/** * drm_connector_init_panel_orientation_property - * initialize the connecters panel_orientation property * @connector: connector for which to init the panel-orientation property. diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index 91a877fa00cb..bfc3e698cda6 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -461,6 +461,18 @@ struct drm_connector_state { * drm_writeback_signal_completion() */ struct drm_writeback_job *writeback_job; + + /** + * @max_requested_bpc: Connector property to limit the maximum bit + * depth of the pixels. + */ + u8 max_requested_bpc; + + /** + * @max_bpc: Connector max_bpc based on the requested max_bpc property + * and the connector bpc limitations obtained from edid. + */ + u8 max_bpc; }; /** @@ -924,6 +936,12 @@ struct drm_connector { */ struct drm_property_blob *path_blob_ptr; + /** + * @max_bpc_property: Default connector property for the max bpc to be + * driven out of the connector. + */ + struct drm_property *max_bpc_property; + #define DRM_CONNECTOR_POLL_HPD (1 << 0) #define DRM_CONNECTOR_POLL_CONNECT (1 << 1) #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2) @@ -1201,6 +1219,8 @@ void drm_connector_set_link_status_property(struct drm_connector *connector, uint64_t link_status); int drm_connector_init_panel_orientation_property( struct drm_connector *connector, int width, int height); +int drm_connector_attach_max_bpc_property(struct drm_connector *connector, + int min, int max); /** * struct drm_tile_group - Tile group metadata -- 2.9.3

3 7

[PATCH v4 0/2] drm/blend: Add per-plane pixel blend mode property
by Lowry Li 04 Oct '18

04 Oct '18

Hi, This serie aims at adding the support for pixel blend modes represent the alpha blending equation selection in the driver. It also introduces to use it in the malidp driver. Let me know what you think, Lowry Changes for v4: - Refines drm_plane_create_blend_mode_property(). drm_property_add_enum() can calculate the index itself just fine, so no point in having the caller pass it in. - Since the current DRM assumption is that alpha is premultiplied as default, define DRM_MODE_BLEND_PREMULTI as 0 will be better. - Refines some comments. - Updates on drm/malidp, hardware limitation check only when the format has alpha pixel. - Rebases on drm-misc-next and fixed the confilcts Changes for v3: - Refines the comments of drm_plane_create_blend_mode_property: 1) Puts the descriptions (after the ":") on a new line 2) Adds explaining why @supported_modes need PREMUL as default - Refines the comments of drm/mali-dp patchset - Rebased on drm-misc-next and fixed the confilcts with plane alpha patch Changes for v2: - Moves the blending equation into the DOC comment - Refines the comments of drm_plane_create_blend_mode_property to not enumerate the #defines, but instead the string values - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha - Introduces to use it in the malidp driver, which depends on the plane alpha patch Changes from v1: - v1 is just the core changes to request for commments - Adds a pixel_blend_mode to drm_plane_state and a blend_mode_property to drm_plane, and related support functions - Defines three blend modes in drm_blend.h - Rebased on current drm-next Lowry Li (2): drm: Add per-plane pixel blend mode property drm/mali-dp: Implement plane alpha and pixel blend on malidp drivers/gpu/drm/arm/malidp_planes.c | 74 ++++++++++++--------- drivers/gpu/drm/drm_atomic.c | 4 ++ drivers/gpu/drm/drm_atomic_helper.c | 1 + drivers/gpu/drm/drm_blend.c | 126 ++++++++++++++++++++++++++++++++++++ include/drm/drm_blend.h | 6 ++ include/drm/drm_plane.h | 2 + 6 files changed, 182 insertions(+), 31 deletions(-) -- 1.9.1

6 13

[Bug 106671] Frequent lock ups for AMD RX 550 graphics card
by bugzilla-daemon＠freedesktop.org 04 Oct '18

04 Oct '18

https://bugs.freedesktop.org/show_bug.cgi?id=106671 --- Comment #23 from Alan W. Irwin <Alan.W.Irwin1234(a)gmail.com> --- Created attachment 141872 --> https://bugs.freedesktop.org/attachment.cgi?id=141872&action=edit tarball containing daemon.log, messages, kern.log, syslog, and dmesg output The previously described uptime test lasted (until the lockup this morning) for 9+ days, but the log files included nothing that seemed relevant. The next uptime test that started this morning for exactly the same graphics stack and kernel parameters lasted only 7 hours until a lockup, and this time the (attached) log files caught substantial error messages before the crash. @Michel Dänzer: Could you please take a look at this one to see whether there is some clue in the kernel error messages concerning the source of this instability? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly
by bugzilla-daemon＠freedesktop.org 04 Oct '18

04 Oct '18

https://bugs.freedesktop.org/show_bug.cgi?id=101739 Bug ID: 101739 Summary: An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: krystian.galaj(a)vpltd.com QA Contact: dri-devel(a)lists.freedesktop.org The game is sometimes rendering trees. It has multiple tree mesh models, and when the tree gets close, the game is switching between different LODs/models by rendering both models overlapping on a grid of pixels, as if checkerboard, pixels of old LOD in black fields of it, new one in white. As long as it’s doing that using single-sampled buffers as render targets, all is fine. However in higher quality modes, the game switches to multisampled buffers. When using multisampled buffers, if ATOC is turned on in settings, the game is using alpha-to-coverage technique without polygon sorting to make sure that the grass is rendered correctly. At the same time it’s using depth test and depth write to fill up the depth buffer. In the same execution of fragment shader it sets the output color and alpha value, and the depth buffer value, and it expects the alpha value to cause the color value to end up only in some samples of multisampled texture, and - the important bit - the depth value to end up only in the corresponding samples of the depth buffer. This technique works on DX11 on Windows, on all drivers on Mac OS X, and on NVidia drivers on Linux, but on Mesa Radeonsi drivers on Linux it makes the rendering go bad, rendering most of the tree pixels white until the LOD transition ends. The white is visible on the screen because it is the initial color of the multisampled render target, and for some reason this color is allowed to leak through, which means that in some cases the depth buffer value is set, when the corresponding color buffer value isn’t. Both depth and color buffer have the same number of samples (8), and were created with fixedSamples = true in OpenGL call. It looks as if the depth buffer values in case of Mesa Radeonsi driver were: - correctly not written when the depth test fails for the fragment shader, - correctly written to all samples of the depth buffer when alpha coverage directs the draw to fill them all, but - INCORRECTLY assigned not only to those samples to which alpha coverage directed the fragment output color, but either to all the samples in depth buffer, or to samples in depth buffer that don’t correspond to the samples in color attachment buffer. We encountered the same issue in 2015 in fglrx drivers, contacted AMD team about it, and received confirmation that it is a bug, and that it was fixed. Unfortunately, shortly after that fglrx drivers went out of use. The issue can be easily reproduced in Arma 3 by: - launching Arma 3 game, - switching to High quality or higher to turn on multisampled buffers, - enabling ATOC (alpha to coverage) in Video settings, or making sure it's enabled, - launching first level of Drawdown 2035 campaign, ie. starting a new campaign, bypassing optional tutorial, and observing as the main character walks into the base, the bushes flicker white from time to time as they get closer. The issue is present in Mesa 17.2.0-devel from padoka PPA, on at least Radeon R7 260X/360. -- You are receiving this mail because: You are the assignee for the bug.

1 18

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2018