<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - GPU hang with libva (gstreamer)" href="https://bugs.freedesktop.org/show_bug.cgi?id=97872#c24">Comment # 24</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - GPU hang with libva (gstreamer)" href="https://bugs.freedesktop.org/show_bug.cgi?id=97872">bug 97872</a> from <a class="email" href="mailto:seanvk@posteo.de" title="Sean V Kelley <seanvk@posteo.de>"> Sean V Kelley</a> <pre>(In reply to haihao from <a href="show_bug.cgi?id=97872#c20">comment #20</a>) > > Yes, that is the whole point of the patch submitted to the i915, but it is > > still a hack. I’m well aware of how this works. And that means every time > > we use a new codec that is not balanced between the VDBoxen we add the hack > > flag. Again, we need to do better. > > > > The batchbuffer for a new codec (MPEG2/JPEG/VC1/AVC/VP8) is still balanced > between all VCS/VDBOX rings. The flag in the following function call is only > available to the current batch buffer. > > intel_batchbuffer_start_atomic_bcs_override(batch, 0x1000, BSD_RING0); Yes, I'm aware of that my point is that it is not "balanced" at all from a performance stand point. And that is the kernel work I'm describing. Regardless, that will not impact the immediate fix on this bug. But I need you to test with KBL GT3+ for HCP based codecs. Once we have VDENC AVC in place that too will need to be tested.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>