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
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.
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.
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.
I sent patches to mesa-dev now.
Cooper, if you want to re-test these patches, they are
in this branch:
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:
Should be fixed with:
i965: Increase max texture to 16k for gen7+
Except, Jason raised some concerns:
the mesa part is now fixed, but the modesetting driver in xserver needs to be fixed too:
xf86CrtcSetSizeRange(pScrn, 320, 200, mode_res->max_width,
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.
The mesa component was reported fixed, since this is a mesa issue tracker, closing as fixed.