The i965 driver has a limitation of 8kx8k for texture size, and this causes issues trying to configure compiz to use, say, three 4k monitors in one row with recent hardware.
Customer escalated this issue since it's blocking issue. Thanks,
(In reply to Cooper Chiou from comment #1) > Customer escalated this issue since it's blocking issue. Thanks, Please talk to management (Kaveh) for any escalations and priority discussions. Updating priority fields in bugzilla isn't likely to help get more/less attention. (In reply to Timo Aaltonen from comment #0) > The i965 driver has a limitation of 8kx8k for texture size, and this causes > issues trying to configure compiz to use, say, three 4k monitors in one row > with recent hardware. We should be able to handle 16kx16k on Ivybridge and later. If you want to try this, you can edit brw_context.c:526-527 (change 8192 -> 16384 and 14 -> 15). The downside is that we can currently only blit 8k wide stencil buffers, so those blits would break (probably assert fail). Large depth/stencil MSAA surfaces may break as well. Jordan is working on a real solution for this. Jordan, how's your blorp-splitting code going?
Considering this has technically been supported in hardware since Haswell, I can't fathom how we can call this a critical bug now.
Bumping those values fixed this issue, but what would be the test case to find regressions?
nevermind, apparently running Xonotic was enough to crash the session
Hi Kenneth, Shall modify ctx->Const.MaxCubeTextureLevels = 15; (current is 14 /*8192*/) in this case?
Created attachment 127559 [details] mesa crash log when enabled 16Kx16K render buffer #7 0x00005635fdb835d8 in ProcDRI2GetBuffersWithFormat (client=0x5635ffe7a220) at ../../../../hw/xfree86/dri2/dri2ext.c:317 buffers = <optimized out> status = <optimized out> count = 153 stuff = 0x5635ffea0440 pDrawable = 0x5635ffb84190 width = -35332736 height = -1596896 attachments = 0x5635ffea044c
(In reply to Cooper Chiou from comment #7) > Created attachment 127559 [details] > mesa crash log when enabled 16Kx16K render buffer > > #7 0x00005635fdb835d8 in ProcDRI2GetBuffersWithFormat > (client=0x5635ffe7a220) at ../../../../hw/xfree86/dri2/dri2ext.c:317 > buffers = <optimized out> > status = <optimized out> > count = 153 > stuff = 0x5635ffea0440 > pDrawable = 0x5635ffb84190 > width = -35332736 > height = -1596896 > attachments = 0x5635ffea044c Ken wasn't suggesting this as a permanent solution. It was just something to demonstrate that the platform can do it, and that the kernel is mostly working. Please stop using that experiment and let Jordan finish his work. Thanks.
Cooper tested an early branch of mine related to this, and reported that it appeared to allow him to use 3 4k monitors configured side-by-side.
Created attachment 127888 [details] 3x4K output on Dell Upload 3x4K resolution output on Dell device as attached.
Jordan, Do we think the issue is fixed now? Are there next steps? Thanks!
(In reply to Annie from comment #11) > Do we think the issue is fixed now? Are there next steps? Thanks! The current status is that I'm working on getting my patches upstream to Mesa master. I've sent out some patches for code review, but not all of them.
Thank you.
I sent patches to mesa-dev now. Cooper, if you want to re-test these patches, they are in this branch: git://people.freedesktop.org/~jljusten/mesa split-blorp-blit-v1
Thank you Jordan!
It was brought to my attention that this still will not work with the modesetting driver. We might want to start a new bug for that. I've asked Martin Peres to add this to his list of modesetting driver work to be done.
Ben-It looks like he's updated that Jira with the new bug.
v2 incorporating suggestions from Jason: git://people.freedesktop.org/~jljusten/mesa split-blorp-blit-v2 https://patchwork.freedesktop.org/series/15786/
Should be fixed with: commit e9133dd90ec498cfb6a23fa22504e06488352c51 i965: Increase max texture to 16k for gen7+ Except, Jason raised some concerns: https://lists.freedesktop.org/archives/mesa-dev/2016-December/137620.html
the mesa part is now fixed, but the modesetting driver in xserver needs to be fixed too: hw/xfree86/drivers/modesetting/drmmode_display.c: xf86CrtcSetSizeRange(pScrn, 320, 200, mode_res->max_width, vs. src/sna/sna_display.c: xf86CrtcSetSizeRange(sna->scrn, 8, 8, INT16_MAX, INT16_MAX); currently with xserver 1.19.3 it's not possible to configure 3x4k row of monitors unless the -intel ddx is used.
Filed a new bug for modesetting driver. https://bugs.freedesktop.org/show_bug.cgi?id=102508
The mesa component was reported fixed, since this is a mesa issue tracker, closing as fixed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.