[MG_IntegrationTest] (P7): the unarmed-expected file stops misquoting tier 3s count

- the first class said its 22 names were "the same 13 entries per backend that tier 3 measured as reds", which is wrong twice: 13 was the whole count, not a per-backend one, and those 13 (AdvertisedLimitsScenario x8, SpirvShaderBinaryScenario x4, ProgramPipelineScenario's reserved name) are spread across this class and the next
- the sentence now says what tier 3 actually measured and why it is the same property seen from the other side
This commit is contained in:
2026-09-22 21:36:08 -04:00
parent 16b1d031a9
commit 0bc59ab239
@@ -37,9 +37,11 @@
# CAPS, LIMITS AND EXTENSION ADVERTISEMENT - answered from the client's CapsMirror, no verb (22)
# These call glGetIntegerv / glGetString / glGetInternalformativ and compare the answer
# against a floor or against the other width of the same query. Nothing in them reaches a fill
# point, so the arming line - latched at the process's FIRST fill - is honestly absent. They are
# the same 13 entries per backend that tier 3 measured as reds under MGITEST_SPLIT_LANE=1, for
# the same reason (a query answered without moving the encoder's record ordinal).
# point, so the arming line - latched at the process's FIRST fill - is honestly absent. This is
# the same property tier 3 measured from the other side: its 13 reds under MGITEST_SPLIT_LANE=1
# (AdvertisedLimitsScenario x8, SpirvShaderBinaryScenario x4, ProgramPipelineScenario's reserved
# name) were all queries answered without moving the encoder's record ordinal, and they are
# spread across this class and the next one - which is why this lane sets no such marker.
# --------------------------------------------------------------------------------------------
DirectGLES.VerifySplit.AdvertisedLimitsScenario.ComputeLocalSizeComesFromTheLinkedProgram
DirectGLES.VerifySplit.AdvertisedLimitsScenario.ComputeUniformBlocksIsAnAmountAnApplicationCouldActuallyAllocate