mirror of
https://github.com/MobileGL-Dev/MobileGL
synced 2026-09-09 04:38:30 +09:00
1e45958e014f22a3299bdf81a0f2a66815734849
1990
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 BZLZHH
|
1e45958e01 |
[Test] (MG_Benchmark): measure the driver work a real Minecraft frame asks for
The benchmark tree had nothing that exercised a driver: SanityBench times std::vector, and the Buffer/Program benches call into MobileGL_s directly, so neither can say what a backend costs against the native driver. This adds a headless EGL client that can, and shapes its cases from measured traces rather than guesses. DriverBench dlopens exactly one EGL provider - the system libEGL.so.1, or a libMobileGL.so with MOBILEGL_BACKEND_TYPE selecting Espryt or Magma - so the same binary measures all three stacks with no LD_LIBRARY_PATH shadowing, which matters because MobileGL's own loader has to keep finding the real driver underneath. It renders into its own renderbuffer FBO on a 64x64 pbuffer and paces frames with glFinish, so it needs no window and no compositor. The six mc_* cases replay the per-frame call mix of 30-second render-distance-32 captures of three Minecraft versions, at the rates those captures measured: vanilla 1.21.1 issues 5495 glDrawElements per frame, each preceded by its own glBindVertexArray and glUniform3fv; Fabric+Sodium collapses the same scene into 132 glMultiDrawElementsBaseVertex; the 26.2 snapshot issues 3401 glDrawElementsBaseVertex, each preceded by glBindBufferRange + glBindBuffer. The texture case wraps every 16x16 atlas upload in the four glPixelStorei and two glTexParameteri calls Blaze3D re-sets around it, because that wrapper is a large part of what an upload costs a translation layer. One bench frame therefore costs what one real frame of that version costs, and ns_per_op is directly comparable across renderers. run_driver_bench.sh pins __EGL_VENDOR_LIBRARY_FILENAMES and VK_ICD_FILENAMES. Without that, eglGetDisplay(EGL_DEFAULT_DISPLAY) on this glvnd system resolves to Mesa llvmpipe and the "native" numbers silently describe a software rasteriser - the first run of this bench reported 11 us per draw before the pin, versus 250 ns on the real GPU. Verified against the NVIDIA 610.43.03 driver, Espryt and Magma on a GTX 1660 SUPER; the CMake target builds and runs from a clean configure. |
||
|
BZLZHH
|
6e6f5268fb |
[Fix] (MG_Backend): let a default-visual X11 window match an alpha-free config
ChooseConfigForSurface prefilters candidate configs with eglChooseConfig requiring EGL_ALPHA_SIZE 8, then tries to match the window's X visual. On NVIDIA's X11 EGL every alpha-8 config lives on the 32-bit ARGB visual, and the default depth-24 TrueColor visual only appears on alpha-0 configs - so for any window created with the default visual the match loop scanned a list that could not contain its visual, fell through to a 32-bit-visual config, and eglCreateWindowSurface failed with EGL_BAD_CONFIG. Keep the alpha-8 list as the first tier and add an alpha-relaxed second tier used only for the visual match; the sizeless fallbacks below still run on the alpha-8 list. Mesa is unaffected (its default-visual configs carry alpha), and a destination-alpha-free default framebuffer is exactly what native GLX hands out on these visuals anyway. Found by running Minecraft through the new GLXImpl on Espryt: NVIDIA EGL also needs EGL_PLATFORM=x11 under a Wayland session or eglGetDisplay itself returns no display, which is a launcher-environment concern, not a library one. |
||
|
BZLZHH
|
08f98ad9ce |
[Feat] (MG_Impl): implement GLX 1.4 on the EGL layer so GLFW apps run on Linux
Desktop Linux GL apps (GLFW/LWJGL, glxgears, anything X11) create contexts through GLX, and MobileGL only spoke EGL - the two exported glX symbols were proc-address stubs that could resolve GL entry points but never produce a context. GLXImpl is the missing sibling of WGLImpl/CGLImpl: the same window-system-binding pattern, calling the internal MG_Impl::EGLImpl namespace directly. The surface covers exactly what GLFW 3.4 resolves via dlsym plus the legacy visual API: FBConfig enumeration mirrors the two EGLState configs (stencil-8 first so stencil-wanting choosers land on it), glXGetVisualFromFBConfig answers with the screen's default visual (falling back to any 24-bit TrueColor one), and glXCreateContextAttribsARB maps the ARB attribs onto EGL context attribs the way WGL's Ext_CreateContextAttribsARB does - profile mask only emitted for 3.2+ or an explicit profile request, since that bit is what keys MobileGL's relaxed-semantics compatibility mode. Legacy glXCreateContext/CreateNewContext hand out 3.3 compatibility contexts, matching wglCreateContext. Drawables follow the WGL HWND model: the GLXWindow is the X window itself, the EGL window surface is created lazily on first MakeCurrent and cached per XID, and the GLX layer owns size discovery per the platform-layer contract - it pushes changes through EGLImpl::ResizePlatformWindowSurface, polling XGetGeometry on MakeCurrent and on swaps throttled to 250ms so a fast-swapping app is not paying a server round trip per frame. libX11 is dlopen'd at runtime like everywhere else in the tree; Xlib.h is already in every TU via the vulkan include, so XVisualInfo gets an ABI mirror struct (Xutil.h needs the Bool and Status macros that Includes.h deliberately pops) and the caller's XFree pairs with our malloc. glXGetProcAddress now resolves glX names from the export table before falling through to the shared GL resolver, which previously returned nullptr for every glX extension entry point - GLFW requires glXCreateContextAttribsARB and glXSwapIntervalEXT to arrive that way. Verified with a smoke test replaying GLFW's exact call sequence (dlsym-only resolution, manual FBConfig filtering, 3.2 core forward-compatible context, glXCreateWindow, 60 swapped frames, clean glGetError) on both backends against the real NVIDIA driver, then with Minecraft 1.21.1, 1.21.4+Fabric+Sodium and 26.2-snapshot-6 reaching in-world rendering on both Espryt and Magma. |
||
|
BZLZHH
|
d39a706d57 |
[Perf] (MG_Backend): stop paying for descriptor slots and mip barriers nobody asked for
Five independent bits of per-draw and per-operation waste in the DirectVulkan backend, all removing work whose answer was already known. The per-draw descriptor walk iterated all 256 slots of bindingKinds to find the one to eight bindings a real GL program declares, because that vector is sized to the binding cap rather than to the program. Reflection now records the bindings it actually assigned, and the draw path iterates that. It is built at the end of ReflectLayout, not where bindingKinds is sized - at that point the vector is only zero-initialised and the kinds are assigned further down, so a list built there would be empty. It has to stay ascending: Vulkan consumes pDynamicOffsets in binding order and the writer pushes them in iteration order, so an unordered list would silently mis-pair dynamic offsets with their uniform blocks. Descriptor pools were sized maxSets * the 256-binding cap, declaring 81,920 descriptors per pool and 245,760 across the frames in flight, for sets that hold what shader reflection found. Sized from eight now; an outlier program is absorbed by the VK_ERROR_OUT_OF_POOL_MEMORY path that already exists, which works because pool sizes are aggregate budgets rather than per-set limits. TrackLiveResource swept the whole live-buffer vector on every insert once it passed 256 entries, and when the buffers are all live the sweep removes nothing and the vector grows by one - so creating N live buffers cost about N^2/2 expired() checks. It sweeps on a doubling watermark now, with the same reclamation semantics. GenerateMipmap transitioned each destination level individually inside its loop, but every generated level starts in the same layout and the loop only moves a level out of TRANSFER_DST after writing it, so the whole range can be prepared in one barrier - 3(N-1)+1 barrier commands become 2(N-1)+2. Each level is still transitioned to TRANSFER_SRC before it is read, so the dependency between consecutive levels is unchanged. WaitForFrameSerial drained the entire graphics queue, as its own comment admitted. Every submission records the frame serial it was made under, so it now waits on the first fence at or past the requested serial. The narrow path deliberately does not call NotifyDeviceIdle(): that claims every submission has retired, which is only true after a real drain, so it stays on the fallback. Verified with an 8213-case A/B (textures, buffers, queries, mipmaps, uniforms and the whole direct_state_access suite): the Espryt failure list is identical, the Magma failure list differs by one case, and both crash sets are unchanged on Magma. That one case, buffer_storage.map_persistent_draw, does not reproduce in isolation - running the buffer_storage group alone gives byte-identical results on both builds (the same three failures, not including it), and it reports NotSupported when run on its own. It is the same ordering-dependent behaviour this suite shows elsewhere, and the three Espryt crash-set differences are the known copy_image cluster moving chunk position. Flagging rather than hiding it. direct_state_access stays at Espryt 370/371 and Magma 371/371; unit tests 421/421. |
||
|
BZLZHH
|
f3d52faad4 |
[Perf] (MG_State, MG_Backend): stop glViewport from evicting a cached VkPipeline
RenderState kept one version counter for all render state, and DirectVulkan read it in three places: the pipeline memo key, the SetupDrawSnapshot fast-path guard, and that guard's store. So glViewport, glScissor, glBlendColor, glStencilMask, glClearColor, glPolygonOffset, glLineWidth and the point-size family - none of which can alter a VkPipeline, all of which an application changes between draws - knocked the next draw off both fast paths and made it rebuild a pipeline lookup that was already correct. The counter is now split. m_version still moves on every state change, because the draw snapshot really does depend on all of it. m_pipelineStateVersion moves only for the state a backend bakes into a pipeline object, and it is what the three DirectVulkan sites read. The exclusion list is the eight VkDynamicState entries PipelineFactory declares plus the state that is not pipeline state at all (the clear values, hints, the point-size family, clamp read colour, the primitive restart index). glStencilFunc is the one setter that had to be split rather than classified: Func is in the pipeline payload but Ref and ValueMask are dynamic state, so it bumps the pipeline version only when Func actually changes. Capabilities are deliberately NOT in the exclusion list even though several look like dynamic state: GL_FRAMEBUFFER_SRGB feeds the render-pass hash, depth and stencil test feed drawUsesDepthStencil, and scissor test, blend, cull face, polygon offset fill, primitive restart, colour logic op and rasterizer discard all feed the pipeline payload. Two smaller draw-path wins ride along, both removing work whose answer was already in hand. UploadAndBindVertexStreams searched all 32 VAO attribute slots for the SharedPtr matching a binding's buffer key, once per binding per draw - but VertexInputStateFactory writes bindingBufferKeys[b] and bindingAttributeLocations[b] from the same loop iteration, one binding per attribute with no merging, so the attribute at that location IS the buffer, by construction. UploadAndBindIndexBuffer round-tripped the element-array buffer's raw pointer back through the GL name table on every indexed draw, costing a map lookup and an atomic refcount pair, when the binding slot's SharedPtr was already in scope forty lines above - where a comment says exactly that about the vertex path. Behaviour-neutral by construction and verified as such: a 13355-case subset of GL30-GL45 covering viewport, scissor, blend, stencil, depth, polygon offset, clear, multisample, cull, logic op, line width and point state, plus the whole direct_state_access suite, is identical before and after on both backends - in the failure list and in the crashed-case set. direct_state_access stays at Espryt 370/371 and Magma 371/371. |
||
|
BZLZHH
|
ba81ee114e |
[Feat] (MG_Backend, MG_Impl, MG_Util): attach one layer of any layered texture on DirectVulkan
Whether a backend can attach a single layer of a texture to a framebuffer was one Bool, so it could only give the most conservative answer any target needed. DirectVulkan therefore declined every layer of every target and direct_state_access.framebuffers_texture_layer_attachment failed with 542 messages across four targets. The three ways a GL layer maps onto Vulkan are independent capabilities, so the flag becomes a per-TextureTarget mask. A 2D or 2D multisample array layer IS a VkImage array layer and needed nothing but the gate opened. A cube map array is one 2D image with arrayLayers = 6 * cubeCount and CUBE_COMPATIBLE, which is a shape VkTextureManager simply did not have - it is declined softly when the depth is not a whole number of cubes or the level is not square, because that function's Bool return exists for unrepresentable shapes and asserting there would abort on ordinary input, GL_PROXY_TEXTURE_CUBE_MAP_ARRAY above all. A 3D texture's layer is a z slice, which needs a 2D-array-compatible image and a per-slice clear, because vkCmdClearColorImage cannot address a subset of a 3D image's slices - a render pass whose only content is its LOAD_OP_CLEAR can, since its attachment is a 2D view over that one slice. VK_IMAGE_CREATE_2D_ARRAY_COMPATIBLE_BIT is asked for per format and withdrawn per format, mirroring the MUTABLE_FORMAT pattern already in this file: the capability is per format+usage, so a single global probe answers a different question than the one the frontend goes on to ask. Losing it costs per-slice attachment for that format; failing creation would lose the texture. Three things found on the way that are not the headline: glFramebufferTextureLayer, the non-DSA twin, had no gate at all and additionally refused cube map arrays that GL 4.5 requires it to accept. GL 4.6 core 9.2.8 makes the two entry points equivalent, so they now decline in the same places - leaving one ungated is what let an unrepresentable attachment reach the renderer. ComputeFullMipLevelCount takes max(x, y, z), and for every array shape z is the layer count rather than a mip-able axis, so a 4x4 array with 192 layers asked for six mip levels on an image whose legal maximum is three (VUID-VkImageCreateInfo-mipLevels-00958). Only the image's own extent can bound it. lavapipe had been letting that through. A layered GL clear queues layerCount = depth, which is illegal for a VK_IMAGE_TYPE_3D image (VUID-vkCmdClearColorImage-baseArrayLayer-01472 pins it to 0/1, read as the whole mip level) and the old code passed it straight through. Takes framebuffers_texture_layer_attachment green on DirectVulkan, so the whole direct_state_access suite is 371/371 there; Espryt stays 370/371, the remaining case being the fp64 one it declines by design. Known and deliberately not fixed here, with a FIXME at the site: KHR-GL44/45/46.geometry_shader.layered_framebuffer.clear_call_support now fails on DirectVulkan - a layered clear of a 3D texture reads back zeros. Those cases exist only in the GL44+ lists, above the 4.0 this backend reports. An A/B of a 6935-case subset (cube map array, texture storage, framebuffer, 3D, the full DSA suite and the GL33 texture group) is otherwise clean on both backends: 16 cases fixed and none broken on Espryt, 15 fixed and those 2 broken on Magma, and zero difference anywhere at GL 4.0 or below. The FIXME records which causes were already ruled out by bisection so the next reader does not repeat them. |
||
|
BZLZHH
|
c8c7b19579 |
[Feat] (MG_Backend, MG_Util): give DirectVulkan GL's provoking vertex
Vulkan's built-in convention is "provoking vertex first"; GL's default is LAST_VERTEX_CONVENTION, and GL derives both flat shading and the transform feedback vertex order from it. DirectVulkan had no way to say so, which is why direct_state_access.queries_functional failed on a value with nothing in its log - the primitives came back counted against a strip recorded in the wrong vertex order. VK_EXT_provoking_vertex is now enabled when present, and the mode is a hashed field of the pipeline payload rather than dynamic state, because it is baked into VkPipelineRasterizationStateCreateInfo: two draws differing only in it must not collide on one cached VkPipeline, or whichever mode built first would stick for the rest of the frame. The pNext is chained only when the mode is not Vulkan's default, so a device without the extension produces a byte-identical VkGraphicsPipelineCreateInfo to before. Two carve-outs, both measured rather than reasoned: A geometry shader already emits its triangles in GL's vertex order, so asking for LAST rotates them a second time and transform_feedback.geometry reads back the wrong vertices. The mode is one pipeline bit and the input-assembler path wants the opposite, so the two cannot both be satisfied: a program that runs a geometry shader and captures transform feedback keeps Vulkan's own convention. That test is read off the program's own shader list, not programObj.rasterizationProducerStage - the latter is filled by the clip-fixup analysis, which does not run for every program and reads Unknown for exactly the programs this guard exists to catch. Both halves are link-time facts folded into programObj.hash, so no pipeline memo can hand back one built for the other mode; keying on IsTransformFeedbackActive() instead would be a live bug, since neither memo key moves on glBeginTransformFeedback. transformFeedbackPreservesProvokingVertex is deliberately not requested. It buys nothing here - the capture order queries_functional needs comes from provokingVertexLast alone - and leaving it off keeps VUID-VkGraphicsPipelineCreateInfo-topology-04884 disarmed, so a TRIANGLE_FAN pipeline may take LAST on any device. The blit pipeline routes through the same selector: it has no flat varying and no capture, but on a device without provokingVertexModePerPipeline a blit left on FIRST inside a render pass whose draws are LAST is an illegal mix. Per the POST rule the new extension gets rows for provokingVertexLast and for the two properties that change what MobileGL can promise. Fixes queries_functional on Magma (370/371). An A/B over a 976-case transform feedback / geometry shader / layered rendering subset of GL30-GL45 is otherwise identical on both backends and additionally takes 14 geometry_shader rendering and layered_rendering cases from failing to passing on Magma. |
||
|
BZLZHH
|
0e7692251d |
[Feat] (MG_State, MG_Impl, MG_Util): store a compressed texture image and hand it back
glCompressedTexImage2D rejected every internalformat with GL_INVALID_ENUM, so direct_state_access.textures_get_image threw at its first compressed call and reported InternalError with nothing in the log at all - the uncompressed half of the case had already passed. The compressed bytes are now kept verbatim, in a side-channel beside the texel shadow rather than in place of it. That placement is the load-bearing decision: both backends pair MapMipmapData with GetMipmapByteSize while sizing their copy regions from GetMipmapTexelSize, and DirectGLES additionally divides the byte size by the texel count to recover bytes-per-texel, so putting 16 bytes where a 4x4 RGBA8 extent says 64 would be an out-of-bounds read on both. The texel storage therefore stays uncompressed and correctly sized - the image samples as zeros, which is the same deviation the RGTC/BPTC/ETC2 arms of ConvertGLEnumToTextureInternalFormat already document - while glGetCompressedTexImage returns the image *as stored*, which GL 4.6 core 8.11 requires and which no re-encode could satisfy byte for byte. Nothing ever hands the compressed bytes to GLES or Vulkan, so the shadow is authoritative rather than potentially stale, which is why the readback never asks a backend. The accepted set is exactly the RGTC/BPTC/ETC2-EAC formats core GL requires, and it is deliberately the same set ConvertGLEnumToTextureInternalFormat can back with uncompressed storage, so the upload can never accept a format whose texel shadow it cannot allocate. imageSize is checked against the block arithmetic, which is also what keeps the copy in bounds. Three things the shape depends on. AllocateStorage clears the compressed tag, so a glTexImage2D or glTexStorage2D over the level un-compresses it - without that, textures_compressed_subimage would flip branches and start asking for data MobileGL cannot produce. GL_TEXTURE_COMPRESSED and GL_TEXTURE_COMPRESSED_IMAGE_SIZE are answered per level rather than per texture, because a compressed internalformat handed to glTexImage2D resolves to uncompressed storage and must keep reading as uncompressed. And GL_TEXTURE_INTERNAL_FORMAT now reports the compressed token for such a level, or it would claim GL_RGBA8 while GL_TEXTURE_COMPRESSED said true. Still rejected on purpose: glCompressedTexImage1D/3D and every glCompressedTexSubImage*, which caps the blast radius. Fixes textures_get_image on both backends (Espryt 370/371, Magma 369/371). A/B over a 1210-case compressed/texture-storage/texture-view/buffer-storage subset of KHR-GL45 is identical before and after on both backends but for get_texture_sub_image.errors_test, which stops throwing and fails on a value instead. |
||
|
BZLZHH
|
34f09291da |
[Feat] (MG_State, MG_Backend, MG_Util): feed a 64-bit vertex attribute on DirectVulkan
glVertexAttribLFormat validated its arguments and then refused unconditionally with "64-bit vertex attributes are not supported", so direct_state_access.vertex_arrays_attribute_format failed every GL_DOUBLE subcase on both backends - the format never landed, the draw fetched whatever the attribute held before, and the captured values came back as reinterpreted garbage. The attribute is now real state. IsLong is its own bit rather than being inferred from Float64, because glVertexAttribFormat(GL_DOUBLE) also reads doubles - it just asks for them converted to float - so the type alone cannot tell the two apart. It participates in the format comparison, so an L-format call over a plain one still bumps the version, and glVertexAttribPointer clears it inside the mutation block so the clear and the bump stay atomic. GL_VERTEX_ATTRIB_ARRAY_LONG stops being hardcoded false, and the pname is now accepted by the attribute queries at all. Support is detected, never assumed. SupportsFloat64VertexAttributes comes from VkPhysicalDeviceFeatures::shaderFloat64 on DirectVulkan and is false on DirectGLES - not a driver question there and never will be, since ES has no GL_DOUBLE vertex format and ESSL has no fp64 type to consume one with. A backend without it declines in the entry point, with the GL error and a log line naming the reason, rather than accepting state no draw could honour. Both cases get a DriverPost row so the loss is named at startup instead of at draw setup. On DirectVulkan the attribute deliberately does not use VK_FORMAT_R64*_SFLOAT: those are optional and lavapipe advertises zero features for all four of them. It is fetched as its 32-bit word pair (R32G32_UINT / R32G32B32A32_UINT) and bitcast back to double in the shader by a new SPIR-V pass, which is bit-exact and needs no format capability at all. The pass re-declares the input as uvec2 / uvec4, demotes the original variable to a Private global and seeds it once at the top of the entry point, so every existing load keeps its id and its double type and no other instruction is rewritten. Both halves branch on nothing but "is this attribute long", so they cannot disagree - and if the pass ever fails, the assertion fires rather than letting a UINT format sit under a double input. The pointer types are all created before any variable that names them and the demoted variable is moved after them, since the types-and-variables section may not forward-reference a type. dvec3/dvec4 are declined rather than fetched wrong: six or eight uint32 components have no single VkFormat, and GL spreads such an input over two attribute locations, which the location-per-index model here does not express. Fixes vertex_arrays_attribute_format on Magma (369/371). On Espryt it stays failing, now as a detected and explained decline rather than a blanket refusal. |
||
|
BZLZHH
|
3b65e646e1 |
[Fix] (MG_Backend): give every colour attachment its own backend slot on DirectGLES
ES only accepts glDrawBuffers bufs[s] == GL_COLOR_ATTACHMENTs, so a desktop glDrawBuffer(GL_COLOR_ATTACHMENT3) cannot be expressed directly and DirectGLES compacts: it physically relocates the draw buffer's image onto backend point 0 so ES's output-0-to-attachment-0 rule lands on the right image. The clears were therefore always correct. The read side was not. GetBackendAttachmentType derived the attachment-to-point map by searching the draw-buffer array and falling back to the identity point for anything it did not find. That derivation is not injective against the compaction: after clearing attachments 0..7 one at a time, every one of them has been relocated onto point 0 in turn, so a later glReadBuffer(GL_COLOR_ATTACHMENT0) - not a draw buffer any more - takes the identity fallback to point 0 and reads attachment 7's image. Hence the single mismatch, 0.875 where 0 was expected: 7/8 is attachment 7's clear colour. The map is now stored state rather than a re-derivation, and kept a permutation: a draw buffer takes the point ES forces on it, everything else keeps its identity point when that point survived, and an attachment evicted from its identity point is parked on the lowest free one so it stays addressable for glReadBuffer and blits. With identity draw buffers nothing moves and not one extra GL call is issued, which is what keeps ordinary rendering untouched. Two things the permutation depends on. The attachment loop now detaches a colour point whose frontend owner is empty - SyncAttachmentObject only ever attaches, so without this a point handed to an empty attachment would still hold the previous owner's image and hand it back. And QueryReadColorAttachmentInternalFormat asked GL_COLOR_ATTACHMENT0 for the format it sizes the multisample-resolve scratch renderbuffer from; it now asks the point the read buffer actually names, since that is only CA0 when the map happens to be identity. Fixes framebuffers_read_draw_buffer on Espryt. A 5677-case readback and framebuffer subset of GL30-33 stays at zero failures on both backends. |
||
|
BZLZHH
|
25b9370815 |
[Fix] (MG_Backend): stop a renderbuffer blit reading a freed image layout
VkRenderPassManager kept m_renderbufferResources on FastSTL's open-addressing UnorderedMap while BlitFramebuffer caches a raw pointer into one of its elements - ResolveColorBlitBinding stores &rbResource->layout - and then calls MaterializePendingClearForRenderbuffer, which looks that same resource up again. FastSTL's operator[] runs its load-factor check before find_key and reallocates the whole bucket array when occupancy crosses it, so even a plain lookup relocates every element; erase only tombstones and never lowers the occupancy, so the doubling keeps firing. After a relocation the cached pointer names freed storage still holding the pre-clear VK_IMAGE_LAYOUT_UNDEFINED, BlitFramebuffer takes its "source image layout is undefined" early return, and the blit is silently dropped - glReadPixels then returns the zero-filled fresh allocation. That is why the failures looked arbitrary: which iteration breaks is pure arithmetic on the table's occupancy, and the observed set (GL_R8 at k=0,1,3,7, GL_R16 at k=6, GL_RG16 at k=4) is exactly the doubling ladder. Padding the map with unrelated live renderbuffers moves the failures to the positions the model predicts and every previously failing format then passes, so nothing else hides behind it. Reordering the materialize ahead of the resolves - the fix ReadPixels got, see the note at its call site - does not cover this, because BlitFramebuffer resolves two bindings and the second resolve still runs after the first pointer is taken. The depth blit, GetOrCreateRenderPass's depthRenderbufferResource and ReadDepthStencilPixels cache the same kind of pointer, so the invariant belongs in the container rather than in a per-call-site ordering rule. m_textureResources was already node-based for exactly this reason; this is the map that was left behind. Fixes renderbuffers_storage_multisample on DirectVulkan. |
||
|
BZLZHH
|
4ce808b9f2 |
[Feat] (MG_State, MG_Impl, MG_Backend): let a bound program pipeline actually draw
The pipeline object bookkeeping landed already - names, stage slots, queries - but nothing consumed it. Every draw asked the context for the current program, got null because a pipeline is used with program zero, and drew nothing; glCreateShaderProgramv was still a stub returning zero, so direct_state_access.program_pipelines_functional could not even build its stage programs and reported InternalError on both backends. glCreateShaderProgramv is written as the exact call sequence the spec defines it to be, with one deviation that matters: the link goes straight to ProgramObject::Link(false) rather than through LinkProgram, because LinkProgram injects a default fragment shader into a program that has none - correct for a whole program, wrong for a separable vertex-stage one whose fragment stage comes from the pipeline. glDetachShader defers removal to the next link, so the program keeps the shader object it was built from while correctly no longer reporting it attached. GL_PROGRAM_SEPARABLE joins glProgramParameteri and glGetProgramiv. Everything downstream of a draw - both backends, the uniform plumbing, the draw validation - is written against one linked program, so rather than teach all of it about stages, the pipeline is flattened: GetProgramForDraw() composites the stage programs' shaders into a single hidden program object and caches it against a signature of each stage program's lifetime id and link generation, so it is rebuilt exactly when a stage or a stage's link changes. The composite carries no GL name - it must not answer glIsProgram, and it must not consume a name the application could be handed. Uniform entry points get their own resolver rather than sharing that one: glUniform* addresses the pipeline's active program, not the composited draw program. GL_CURRENT_PROGRAM still reads the program in use, which is zero here. Fixes program_pipelines_functional on both backends. |
||
|
BZLZHH
|
5545d31c37 |
[Feat] (MG_Backend, MG_Util): give a cube map array real storage on DirectGLES
TextureCubeMapArray was missing from every storage and upload switch in the DirectGLES texture sync, so a cube map array reached the driver with no storage at all - and from the glFramebufferTextureLayer branch, so attaching one of its layers fell through to glFramebufferTexture2D and raised INVALID_ENUM. Every GL_TEXTURE_CUBE_MAP_ARRAY colour check in direct_state_access.framebuffers_texture_layer_attachment read nothing. ES 3.2 has GL_TEXTURE_CUBE_MAP_ARRAY natively and it stores exactly like a 2D array whose depth is six times the cube count, so each switch gains the case beside Texture2DArray and nothing else changes. 1D arrays join the layer branch for the same reason - their backend image is a 2D array. Per the POST rule the new GLES dependency gets a capability (SupportsTextureCubeMapArray, ES 3.2 core or EXT/OES_texture_cube_map_array) and a DriverPost row saying what a user loses without it. Takes framebuffers_texture_layer_attachment from failing to passing on Espryt. It still fails on DirectVulkan, which declines a layered attachment outright. |
||
|
BZLZHH
|
588ddba722 |
[Fix] (MG_Backend): scale a depth blit, keep going after one declines, and mip a 1D texture
Three DirectVulkan gaps found together.
glBlitFramebuffer's depth/stencil path refused any blit whose source and
destination extents differ, because vkCmdCopyImage cannot resize. vkCmdBlitImage
can, and VK_FILTER_NEAREST is the only filter Vulkan allows for depth/stencil
anyway - which is what the GL front end already requires. A same-size pair keeps
the cheaper copy.
Worse, that refusal and four others were `return`, not `continue`, so a
depth/stencil aspect this backend could not handle abandoned the whole function -
including the colour blit that only starts after the aspect loop. The CTS's
scaling blits therefore lost their colour as well, which is why
direct_state_access.framebuffers_blit failed all three of its checks rather than
one.
VulkanRenderer::GenerateMipmap declined GL_TEXTURE_1D. It needed nothing else:
the blit loop derives every offset from the storage extent, and a 1D texture's is
{width, 1, 1}, which is exactly the y and z offsets a 1D image requires.
Also: IsTimerQueryResultReady now asks the query pool before the frame serial.
The pool polls with VK_QUERY_RESULT_WITH_AVAILABILITY_BIT and is the authority;
the frame serial only advances at Present and neither completion notifier will
mark the current serial done, so a timestamp written and fence-waited inside one
GL frame could never be read back within it.
Takes framebuffers_blit and textures_generate_mipmaps from failing to passing on
DirectVulkan. queries_functional still fails there on a value.
|
||
|
BZLZHH
|
62301b1061 |
[Fix] (MG_State): let a double-typed varying be captured by transform feedback
ResolveXfbSymbolType accepted only float, int and uint, and its caller reports anything it rejects as "Transform feedback varying 'x' is not an output of the vertex stage" - which is a misleading thing to say about a varying that is right there in the shader, just declared `double`. Program linkage failed outright. Doubles are now resolved to the GL_DOUBLE* types, in vector and matrix form, and the per-element size is computed from an 8-byte component rather than a hardcoded 4 (GL 4.6 core 11.1.2.1), so the byte-based limit checks charge a double what GL says it costs. direct_state_access.vertex_arrays_attribute_format stops throwing on both backends and fails on the captured values instead: the capture layout still owes the 8-byte alignment doubles require, and neither backend feeds a 64-bit vertex attribute yet - DirectGLES cannot at all, ESSL having no double. |
||
|
BZLZHH
|
f3a846d336 |
[Docs] (README): carry the 4.2 short-term target into the status note
The compatibility section already said 4.2; the status note at the top of the README still said 3.3, so the two disagreed depending on how far a reader got. |
||
|
BZLZHH
|
9cdc82fbdd |
[Fix] (MG_Backend): actually bind the sampler object DirectGLES just synced
BindCurrentTextures' program-driven path synced a bound sampler object's parameters to its backend object and then never put it on the texture unit, so every sampler object was inert and the driver kept sampling with the texture's own parameters - direct_state_access.samplers_functional read black where the sampler's NEAREST filtering should have given red. The bind alone is a regression, and the CTS says so loudly: a sampler left on a unit by an earlier draw keeps being applied, and a multisample texture takes no sampler object at all, so the next draw against one is rejected and all 27 textures_storage_multisample_3d_* cases fail. The sibling path in the same function had an empty else branch where the unbind belonged; it now unbinds, making the two symmetric. Takes samplers_functional from failing to passing on Espryt, with no other case moving in either direction. |
||
|
BZLZHH
|
4a9d20c49f |
[Fix] (MG_Backend): resolve a framebuffer attachment's layer in the Vulkan blit bindings
ResolveAttachmentBaseArrayLayer answered zero for everything but a cube map face, so every blit, copy and glReadPixels against a layered attachment read layer zero whatever was attached. It reads the attachment's layer now. A 3D texture needs the other half of the distinction: its image has arrayLayers == 1 and the GL layer is a z slice, which VkBufferImageCopy will not take as a base array layer. BlitImageBinding carries it separately as depthOffset, and the readback copy region uses it as the image offset's z. Takes textures_copy from failing to passing on DirectVulkan, which is what glCopyTextureSubImage3D needs to see the slice the CTS attached rather than slice zero. |
||
|
BZLZHH
|
394d1ce748 |
[Feat] (MG_Impl, MG_Util): copy into 1D and 3D textures, and accept the BPTC and ETC2 enums
Two unrelated texture gaps. glCopyTextureSubImage1D and 3D validated their arguments and then did nothing: CopyTexSubImage1D_State and CopyTexSubImage3D_State were empty TODOs and no backend exposes anything but a 2D blit. But a texture's contents live in its CPU storage - the backends sync from it - so the copy does not need a blit at all. CopyReadFramebufferIntoMipmapRegion reads the region out of the read framebuffer through the existing ReadPixels path, in the destination's own canonical client layout so the bytes need no second conversion, and writes them straight into the level. GL 4.6 core 8.6 says the copy ignores pixel-store state and any bound pack buffer, which the borrowed readback does not, so both are neutralised for the duration and restored after. A cube map destination addresses its faces as separate upload targets, so its zoffset picks the target rather than a slice. ConvertGLEnumToTextureInternalFormat had arms for the six generic compressed formats and the four RGTC ones, all resolving to uncompressed storage, but none for BPTC or ETC2/EAC - so glTexImage2D with one of those fourteen enums answered INVALID_ENUM, which was never a legal reply for formats core GL has required since 4.2 and 4.3. They follow the same deviation for the same reason: nothing in this stack can compress them, and uncompressed storage is the trade the RGTC formats already take. Takes textures_compressed_subimage from failing to passing on both backends and textures_copy on Espryt. textures_copy still fails on Magma, where the readback of a layered attachment does not yet resolve the attached layer. |
||
|
BZLZHH
|
300b458132 |
[Feat] (MG_State, MG_Impl): give program pipelines their object and their state
Every program pipeline entry point was an export stub, and the stub macro's `return (type)1` made glIsProgramPipeline answer GL_TRUE for anything - including the names glGenProgramPipelines had never written. All four direct_state_access.program_pipelines cases failed. ProgramPipelineObject holds what GL 4.6 core 7.4 says a pipeline is: a program reference per shader stage, the active program glProgramUniform* addresses, a validate status and an info log. Its validate status starts false, unlike ProgramObject's, because a pipeline that has never been validated must report GL_VALIDATE_STATUS as 0. The name rules follow the shape queries and transform feedbacks already use, and which the CTS checks first: glGenProgramPipelines only RESERVES a name and glIsProgramPipeline answers GL_FALSE for it; the object appears on first bind, or immediately from glCreateProgramPipelines. Map membership is object existence - a pipeline, unlike a transform feedback, has no stateful default object zero, so no everBound flag is needed. glGet(GL_PROGRAM_PIPELINE_BINDING) reports the real binding now instead of a hardcoded zero whose comment said the entry points were stubbed. This is the state half only. program_pipelines_functional needs mixed-stage rendering - a vertex-only and a fragment-only program drawn together - and stays failing; glCreateShaderProgramv is deliberately left stubbed until that lands, so nothing can half-work in between. Takes program_pipelines_creation, _defaults and _errors from failing to passing on both backends. |
||
|
BZLZHH
|
1f1a331a44 |
[Feat] (MG_Impl, MG_State): implement the framebuffer parameter getters and setters
glFramebufferParameteri, glGetFramebufferParameteriv and their two by-name siblings were all export stubs - the GL_ARB_framebuffer_no_attachments entry points. The stub raises no error and writes nothing, so direct_state_access.framebuffers_get_parameter_errors saw GL_NO_ERROR for all three conditions it checks. FramebufferObject gains the five DEFAULT_* parameters as real state, initialised to GL 4.6 core table 23.24 and bumping the object version on a write like the read buffer does. The getter answers those plus the six derived names - GL_SAMPLES and GL_SAMPLE_BUFFERS from the attachments' sample counts, GL_IMPLEMENTATION_COLOR_READ_FORMAT/_TYPE from the read buffer's internal format, GL_DOUBLEBUFFER true only for the window-system framebuffer, GL_STEREO false because stereo surfaces are not exposed - which is what glGetIntegerv already reports for the bound framebuffer. The pname rules live in ValidateFramebufferParameterPname, and their ORDER is load-bearing: a name outside the table is INVALID_ENUM, and only a name that IS in the table but that the default framebuffer cannot answer is INVALID_OPERATION. Testing the framebuffer kind first would answer INVALID_ENUM for GL_FRAMEBUFFER_DEFAULT_WIDTH on framebuffer zero, which is exactly the third thing the case checks. The by-name forms take zero as the default framebuffer, like the other DSA framebuffer entry points. Rendering to a framebuffer with no attachments is deliberately NOT enabled by this: CheckCompleteness still reports INCOMPLETE_MISSING_ATTACHMENT, because no backend can rasterize one. The state is real and the queries are honest; the draw path is a separate piece of work. Takes framebuffers_get_parameter_errors from failing to passing on both backends, with framebuffers_get_parameters - which passed only because both getters were stubs leaving the CTS's zero-initialised comparands untouched - still passing. |
||
|
BZLZHH
|
817091641c |
[Fix] (MG_Impl): give a cube map the storage and the layered attachment it asks for
direct_state_access.framebuffers_texture_attachment threw on both backends, and three separate things were wrong on the way to a cube map framebuffer. glTexStorage1D/2D/3D validated their target by converting it to a single TextureUploadTarget. GL_TEXTURE_CUBE_MAP has no single upload target - it allocates all six faces - so the conversion produced Unknown and a legal glTexStorage2D(GL_TEXTURE_CUBE_MAP, ...) was rejected with INVALID_ENUM, which is where the case threw. The accepted set for these entry points is the dimension's storage targets, which IsTextureStorageTargetForDimension already spells out, so that is what they check now. TextureStorage2D then allocated only the primary upload target, leaving a cube map with one face out of six - cube-incomplete, so every framebuffer it was attached to answered GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT. It allocates every upload target the object has; for every other 2D target that is the same single target as before. ResolveRepresentableFramebufferTextureUploadTarget declined every layered target but 2D array, so glNamedFramebufferTexture on a cube map reported "not represented by the current framebuffer attachment model". Cube maps, cube map arrays, 1D arrays, 2D multisample arrays and 3D textures are all the same shape as the 2D array that already worked - glFramebufferTexture binds the whole texture and the attachment records a representative upload target - so they are all handled now. DirectGLES routes a layered attachment to glFramebufferTexture, which is exactly this. Takes framebuffers_texture_attachment from failing to passing on both backends. |
||
|
BZLZHH
|
e64c7c7e65 |
[Fix] (MG_Backend): never back a multisample texture with a one-sample Vulkan image
Every one of the sixty direct_state_access.textures_storage_multisample_2d_* and _3d_* cases failed on DirectVulkan, for every internal format, with no GL error anywhere - a pure data mismatch. The CTS asks for glTextureStorage2DMultisample(tex, samples = 1, ...), which is legal GL, and MobileGL carried the 1 faithfully through to VkImageCreateInfo::samples = VK_SAMPLE_COUNT_1_BIT. It then binds that image to the auxiliary program's sampler2DMS, whose SPIR-V is OpTypeImage with MS = 1. VUID-RuntimeSpirv-samples-08726 forbids exactly that pairing: an MS access must come from an image created with more than one sample. The texelFetch therefore read undefined data - which is why it looked format-independent and raised nothing. GL only promises "at least the requested number of samples", so a multisample texture is now floored at two. GL_TEXTURE_SAMPLES still reports what the application asked for; that is read off the texture object, not off the image. The device-capability round below it is bounded at two for the same reason - letting it land back on one sample would recreate the violation silently for any format whose only supported count is one. Takes all 60 textures_storage_multisample_* cases from failing to passing on DirectVulkan, which goes from 296/371 to 356/371. DirectGLES is untouched. |
||
|
BZLZHH
|
dd60ff39ce |
[Feat] (MG_State, MG_Impl, MG_Backend, MG_Util): make the border colour real sampler state
glGetSamplerParameterfv(sampler, GL_TEXTURE_BORDER_COLOR) raised INVALID_ENUM,
because MobileGL kept the border colour on the texture object and
GetSamplerParam_State had no case for it at all. That is the first thing
direct_state_access.samplers_defaults asks, so the case threw before reaching
any of the defaults it was written to check.
GL 4.6 core table 23.18 lists TEXTURE_BORDER_COLOR as sampler state, so it moves
to SamplerParameters and TextureObjectBase reaches it through the SamplerObject
it already owns - one source of truth, and a sampler object bound over a texture
now supplies its own border colour, which is what GL says should happen. The
texture params version still moves on a write, because the DirectGLES texture
sync memoises on it. glSamplerParameter{fv,Iiv,Iuiv} and their getters read and
write all four components in whichever representation the caller used, and the
three representations are kept in step so any getter has an answer. The bogus
[0,1] and [0,255] range checks are gone: GL clamps a border colour when a
fixed-point format is sampled, it does not reject it.
DirectVulkan's ResolveVkBorderColor now reads the sampler rather than the
texture. DirectGLES gained a glSamplerParameterfv in its sampler sync, and both
that and the pre-existing glTexParameterfv are gated on a new
SupportsTextureBorderClamp capability - ES 3.2 core, or EXT/OES_texture_border_clamp
before it - since without the extension every such call is INVALID_ENUM on the
driver. DriverPost gains the matching row per the POST rule, saying what a user
actually loses when it is missing.
Takes direct_state_access.samplers_defaults from failing to passing on both
backends.
|
||
|
BZLZHH
|
96ad7ca0cc |
[Fix] (MG_Impl): asking a renderbuffer for more samples than it has is INVALID_OPERATION
ValidateRenderbufferStorageSamples_State answered INVALID_VALUE for a sample count above GL_MAX_SAMPLES. GL 4.6 core 9.2.4 reserves INVALID_VALUE for a negative count: a count that is well formed but larger than the format can deliver is INVALID_OPERATION, because the argument is fine and the format is what cannot honour it. Takes direct_state_access.renderbuffers_storage_multisample_errors from failing to passing on both backends. |
||
|
BZLZHH
|
e80a23eae6 |
[Fix] (MG_Backend): read a multi-slice glGetTexImage off the GPU instead of the CPU shadow
DirectGLES served every multi-slice glGetTexImage from the CPU shadow copy, on the grounds that its scratch FBO can only expose one layer at a time. But the shadow only holds what was uploaded, so any slice that was rendered to rather than written by glTexSubImage came back stale - and a layered framebuffer produces exactly that. The scratch FBO can expose one layer at a time repeatedly. The read now attaches each layer in turn and takes the slice off the GPU, walking the destination over GL_PACK_SKIP_IMAGES / GL_PACK_IMAGE_HEIGHT itself so each per-slice call packs a plain 2D image with the same layout StoreWideRowsToClient computes for the whole stack. The shadow stays as the fallback for the formats a colour attachment cannot represent at all, and for any slice whose attachment comes back incomplete. Takes all 27 remaining direct_state_access.textures_storage_multisample_3d_* cases from failing to passing on Espryt - they render into a TEXTURE_2D_MULTISAMPLE_ARRAY one layer per colour attachment and then read the whole array back. DirectVulkan is untouched. |
||
|
BZLZHH
|
088f263495 |
[Feat] (MG_Impl): answer the two query parameters the getters were missing
GetQueryObjectValue implemented GL_QUERY_RESULT_AVAILABLE and GL_QUERY_RESULT and rejected everything else, so direct_state_access.queries_functional threw on its very first probe - GL_QUERY_TARGET - and never reached any of the checks it was written for. GL_QUERY_TARGET is state the object has carried all along; it just had no case. GL_QUERY_RESULT_NO_WAIT is GL_QUERY_RESULT with the backend asked not to block, and it brings a wrinkle the shared getter could not express: when the result has not landed, GL_ARB_query_buffer_object leaves the destination untouched rather than writing a placeholder. GetQueryObjectValue now reports "succeeded but produced no value" through an optional out-parameter, and all five callers - the four buffer forms and the four client-memory forms - skip the write on it. The switch is deliberately widened by exactly these two names: its default INVALID_ENUM is what the GL33 and GL40 query error cases rely on. queries_functional passes on Espryt. On Magma it stops throwing and fails on a value instead, which is a separate problem in the query results themselves. |
||
|
BZLZHH
|
3b3b6e5b8b |
[Fix] (MG_Backend): read back the stencil half, and clear an sRGB target to the value asked for
Two reasons a framebuffer's contents came back wrong, both on the read/clear side rather than the write side. Stencil, on both backends. The CTS reads stencil with glReadPixels(GL_STENCIL_INDEX, GL_INT), which is as legal as the unsigned widths, and neither backend accepted it: DirectGLES's ReadPixelsStencilViaNative rejected every signed type, after which the call fell through to a native ES read the driver refuses and nothing was written at all, so the caller kept its zeros; DirectVulkan's pack switch had no GL_INT case, and of the cases it did have only GL_UNSIGNED_INT sourced the stencil plane - GL_FLOAT and GL_UNSIGNED_SHORT emitted a depth value, which is meaningless for a stencil-only image. Both now take the signed and float widths, and DirectVulkan decides "this is a stencil read" once rather than per type. DirectGLES also gains the GL_FLOAT_32_UNSIGNED_INT_24_8_REV fallback a DEPTH32F_STENCIL8 attachment needs, which rejects the 24_8 packed type. sRGB, on DirectVulkan. Every other write path goes through the UNORM twin view while GL_FRAMEBUFFER_SRGB is off, storing the raw value GL asked for, but a deferred clear is materialised with vkCmdClearColorImage - which names the image, so the driver applied the sRGB transfer function and a clear to 0.25 landed at 0.537. PreCompensateSrgbClearColor hands it the linear colour whose encoding is the requested value instead. It is a no-op for non-sRGB destinations, for integer clear encodings, and when GL_FRAMEBUFFER_SRGB is on and GL really does want the encode. Takes renderbuffers_storage from failing to passing on both backends, plus renderbuffers_storage_multisample and framebuffers_blit on Espryt. |
||
|
BZLZHH
|
9eda2147b1 |
[Fix] (MG_Impl, MG_Backend): let the backend that can honour a layered attachment have it
NamedFramebufferTextureLayer declined every attachment but layer zero, on both backends. That was right for DirectVulkan, which maps a GL layer onto a Vulkan array layer with no notion of a 3D depth slice, but wrong for DirectGLES: SyncAttachmentObject already routes a layered upload target to glFramebufferTextureLayer with the attachment's layer passed straight through, and array storage already carries the real layer count into glTexStorage3D. The one backend that could render to the layer was being told it could not. The decision now lives in a DynamicBackendParameters flag, so it is the backend that answers rather than the entry point guessing. DirectGLES sets it when the driver resolved glFramebufferTextureLayer; DirectVulkan leaves it false until VkRenderPassManager tells a depth slice from an array layer. framebuffers_texture_layer_attachment's colour checks now pass on Espryt for 3D, 2D array and 2D multisample array textures - the case still fails there on cube map arrays, which DirectGLES gives no storage at all, and on the depth and stencil halves. No case changes on DirectVulkan, which keeps the old behaviour. |
||
|
BZLZHH
|
a63699cde6 |
[Fix] (MG_Impl, MG_Backend): reject incomplete cube maps in mipmap generation instead of crashing on them
Both direct_state_access.textures_generate_mipmap* cases crashed DirectVulkan. Two causes, neither of them a broken invariant: glGenerateMipmap and glGenerateTextureMipmap never checked cube completeness, so an incomplete cube map went straight to the backend, which asserts that the texture it is handed is complete. GL 4.6 core 8.14.4 makes that call INVALID_OPERATION - there is no consistent set of faces to filter down - and both entry points now say so through a shared check. VulkanRenderer::GenerateMipmap asserted that the target was one of the four it implements. 1D, 1D array and cube map array are legal GL and the front end passes them through, so meeting one is a gap in this backend's coverage; it now logs and declines, leaving the generated levels unwritten rather than aborting. textures_generate_mipmap_errors passes on both backends now. textures_generate_mipmaps stops crashing but still fails: DirectVulkan does not generate the 1D mip chain the case checks - the frontend's storage allocation gives the levels the right sizes, which is why the case passes when run on its own, but not the descending content the full-run state leaves it looking for. |
||
|
BZLZHH
|
765aaec6dc |
[Fix] (MG_Impl, MG_Backend): stop the new layer attachment from reaching backends that cannot back it
Implementing NamedFramebufferTextureLayer made layered attachments reachable for the first time, and direct_state_access.framebuffers_texture_layer_attachment went from Fail to Crash on DirectVulkan. Two separate gaps sat behind it, both of them asserted on rather than reported: - The renderer resolves an attachment's GL layer straight onto a Vulkan array layer. A 3D texture's z-slice therefore lands outside its image, which has one array layer by construction, and the array texture objects are still the one-image stubs in TextureObjectStubs.h, so their image has a single layer whatever GL believes. MaterializePendingClearForTexture tripped over a clear whose layer span was outside the image it was given. - A cube map array has no image shape in VkTextureManager at all, so SyncTextureAndGetDescriptor returns null for it. NamedFramebufferTextureLayer now answers the full error set for every target and layer - which is what took the two error cases green - and then declines to attach anything but layer zero of a non-cube-array texture, through the same RecordUnsupportedFramebufferTextureAttachmentError the by-target entry point already uses. Layer zero of the other targets is the plain first-slice attachment glFramebufferTextureLayer already backs, so it still goes through. SyncTextureResource's assertion on an unsupported texture shape is also gone: it is a gap in this backend's coverage, not a broken invariant, and the code below it already handles the failure by declining the sync. It logs a warning instead. framebuffers_texture_layer_attachment goes back to Fail on DirectVulkan rather than Crash; no case changes in either direction beyond that. |
||
|
BZLZHH
|
bcd669bd25 |
[Feat] (MG_Impl): complete the by-name framebuffer attachment and buffer-selection entry points
Four direct_state_access framebuffer cases failed on one shared cause and three local ones. The shared cause: every DSA framebuffer entry point resolved its name through GetNamedFramebufferObject_State, which rejects zero outright. But zero names the default framebuffer to these functions, so glGetNamedFramebufferAttachmentParameteriv, glNamedFramebufferDrawBuffer(s) and glNamedFramebufferReadBuffer answered INVALID_VALUE for every default-framebuffer query the CTS makes. They now resolve zero to the default framebuffer object and tell the two kinds apart explicitly, which is what the accepted-name rules key off anyway. Attachment queries: the accepted attachment names differ between the default framebuffer (FRONT/BACK variants, DEPTH, STENCIL) and a framebuffer object (COLOR_ATTACHMENTi, DEPTH/STENCIL/DEPTH_STENCIL_ATTACHMENT), and a name outside the relevant list is INVALID_ENUM. Both getters share ResolveAttachmentQueryName for that, so the by-target form no longer aliases GL_FRONT onto a framebuffer object's colour attachment 0. The TEXTURE_* parameters are also rejected with INVALID_ENUM when the attached object is a renderbuffer. Buffer selection: naming a buffer that belongs to the other kind of framebuffer is INVALID_OPERATION, not INVALID_ENUM - the enum is accepted, the framebuffer just has no such buffer. glDrawBuffers additionally rejects the multi-buffer names (FRONT, LEFT, RIGHT, FRONT_AND_BACK) with INVALID_ENUM on both kinds, takes BACK only when n is one, and glReadBuffer treats the multi-buffer names as accepted-but-unselectable. Both colour-attachment range checks now go through ValidateColorAttachmentInRange instead of comparing against MAX_DRAW_BUFFERS with an off-by-one. NamedFramebufferTextureLayer was a stub that reported "not represented by the current framebuffer attachment model" for every call, even though the attachment model stores a layer and the by-target glFramebufferTextureLayer already uses it. It is implemented against the same model, with the per-target layer limits and the INVALID_OPERATION-for-a-bad-name rule that separates it from NamedFramebufferTexture. NamedFramebufferTexture itself gained the two checks it lacked: colour attachment range, and a negative level. Takes framebuffers_get_attachment_parameters, framebuffers_get_attachment_parameter_errors, framebuffers_texture_attachment_errors and framebuffers_draw_read_buffers_errors from failing to passing on both backends. |
||
|
Claude
|
f3405d1d53 |
[Fix] (CI): narrow the trace fixture Git LFS fallback to the files mirrors lost
The fetch script tries git.hit.moe, then the repo.miawa.cn mirror, and only then Git LFS, but it bailed out of the mirror loop on the first file no mirror could serve and then pulled the whole case from GitHub. A case whose mirrors served every file but one paid GitHub's LFS bandwidth for all of them. Collect the files that survived every mirror and every retry instead, and scope the LFS fallback to just those, matching what the local macOS retrace helper already does. |
||
|
BZLZHH
|
81604d5596 |
[Feat] (MG_Impl, MG_Test): validate the direct-state-access texture copies
CopyTextureSubImage1D and 3D were do-nothing stubs and the 2D form checked only its effective target, so all 28 conditions in direct_state_access.textures_copy_errors went unreported: level and region bounds, and every read-framebuffer precondition. The read-framebuffer half lands in FramebufferImpl as ValidateReadFramebufferForCopy - incomplete read framebuffer (INVALID_FRAMEBUFFER_OPERATION), a read buffer that names no attachment, and a multisampled read buffer (both INVALID_OPERATION). It decides multisampledness by attachment kind rather than by sample count alone, because a TEXTURE_2D_MULTISAMPLE attachment sets SAMPLE_BUFFERS even when its sample count is one - which is exactly what the CTS attaches, and what a renderbuffer-only check would have missed. The texture half is ValidateCopyTextureSubImage, shared by all three forms; 1D and 3D also get the effective-target rule their form specifies. NOTE: the copy itself is still not implemented for 1D and 3D - CopyTexSubImage1D_State and CopyTexSubImage3D_State remain TODOs and no backend exposes anything but a 2D blit - so direct_state_access.textures_copy stays red. Only the errors are complete, which is what un-stubbing these two entry points buys; both carry a comment saying so. CopyTextureSubImage2DUsesNamedObjectAndRestoresBinding had been passing a storage-less texture and no read framebuffer, which the new validation correctly rejects. It now sets up a legal copy, so it still measures the by-name plumbing it was written for. Takes direct_state_access.textures_copy_errors from failing to passing on both backends. |
||
|
BZLZHH
|
31ea6aa5a3 |
[Feat] (MG_Impl): give the by-name texture image queries their error set
glGetTextureImage resolved a texture by name and went straight to the read, skipping every object-level rule glGetTexImage enforces through GetTexImage_State - and on DirectVulkan it skipped the level checks in CopyTextureImageToClientOrPBO_State as well, because that backend answers GetTextureImage itself. Fifteen of the sixteen conditions in direct_state_access.textures_image_query_errors went unreported. The object-level half of that error set now lives in ValidateTextureImageQuery and both entry points run it. Three rules are new rather than merely relocated: - Multisample and buffer textures are not in the accepted target list; neither has a single image to return. - The destination-size checks (bufSize, and the span written into a bound pixel pack buffer) move ahead of the read. They existed, but downstream of it, where any early bail-out - an unmapped level, a pack step that declines the format - swallowed them. Both measure the tightly packed span summed over the object's faces, which is the least a query can produce, so nothing that would have fit is rejected. - IsDepthLikeInternalFormat had no case for StencilIndex8, so a colour client format read back against a stencil-only texture looked like a matching pair. glGetCompressedTextureImage was a do-nothing stub. It validates the name and the level, then reports INVALID_OPERATION: no format MobileGL can hold is compressed, and answering GL_NO_ERROR without writing would hand the caller stale memory - the same reasoning GetCompressedTexImage_State already follows. Takes direct_state_access.textures_image_query_errors from failing to passing on both backends. |
||
|
BZLZHH
|
7d6f6603c1 |
[Feat] (MG_Impl): enforce the unpack-buffer rules on texture sub-image uploads
TexSubImage1D/2D/3D_State each carried a TODO for the three INVALID_OPERATION conditions GL 4.6 core 8.5 attaches to sourcing an upload from a bound PIXEL_UNPACK_BUFFER: the store being mapped, an offset that is not a multiple of the size of one datum of `type`, and reads that would run past the end of the store. None of them was checked, so every such call was quietly accepted. ValidatePixelUnpackBufferSource now covers all three and returns true when no unpack buffer is bound, so the callers can run it unconditionally. Persistent mappings stay legal sources, matching what ReadPixels already does on the pack side. The overrun check measures the tightly packed span, which is the smallest the unpack can read - pixel store parameters only ever widen it - so it cannot reject an upload that would have fit. TextureSubImage2D needed the call of its own: unlike its 1D and 3D siblings it does not route through TexSubImage2D_State. Takes direct_state_access.textures_subimage_errors from failing to passing on both backends. |
||
|
BZLZHH
|
39c17c0b1b |
[Fix] (MG_Impl): validate the float texture parameter setter and the compressed size query
Two independent gaps in the texture parameter paths, both reported by direct_state_access: TexParameterf_State never ran ValidateTextureParameterForTarget. The integer setter reaches it through TextureParameterObject_State and the scalar float setter through TextureParameterObjectf_State, but glTexParameterfv and glTextureParameterfv funnel every non-vector pname straight into TexParameterf_State - so in float form MobileGL accepted sampler state on a multisample texture, a mipmapping min filter or a REPEAT wrap on a rectangle texture, and a negative TEXTURE_BASE_LEVEL/TEXTURE_MAX_LEVEL, all of which the integer form rejected. It now validates first, passing the same anisotropy-exempt param the by-object float setter uses so the anisotropy range check is not run twice. GL_TEXTURE_COMPRESSED_IMAGE_SIZE answered 0 for every texture. GL 4.6 core 8.11 makes the query INVALID_OPERATION on an image whose internal format is uncompressed and on any proxy target. TextureInternalFormat has no compressed enumerator, so that is every texture MobileGL can hold today; the condition is still written against an IsCompressedTextureFormat predicate so both level getters answer consistently once compressed formats land, and GL_TEXTURE_COMPRESSED now reads from the same predicate instead of a hardcoded false. Takes textures_parameter_setup_errors and textures_level_parameter_errors from failing to passing on both backends. |
||
|
BZLZHH
|
88138b48ec |
[Test] (MG_Test): follow the backends to an advertised GL 4.0
Both AdvertisesVoxyRequiredRenderingExtensions cases pinned TargetGLVersion at 3.3, which was the reported version until V_OpenGL40 joined the advertised extension lists. The version assertion is incidental to what these cases are for - Voxy needs the individual ARB extensions, not a version - so it just tracks the new report instead of holding the old one. |
||
|
BZLZHH
|
c114ce750b |
[Feat] (MG_Backend): advertise OpenGL 4.0 on both backends
Both backends stopped their advertised version list at V_OpenGL33, so an application - or the CTS - asking what MobileGL supports was told 3.3 even though the 4.0 entry points and the KHR-GL40 suite already pass on both. Adding V_OpenGL40 lets that work be reached through the ordinary version query instead of only through the individual ARB extension strings. |
||
|
BZLZHH
|
1ca2d3c0fe |
[Docs] (README): move the short-term target to OpenGL 4.2
The 3.3 line is done - GL30 through GL33 conform on both backends - and the work in flight (GL40, direct state access) is already past it, so the stated short-term target now reads 4.2 and MG_State/MG_Impl are focused there. Performance work joins the focus list alongside the two backends. |
||
|
BZLZHH
|
58c17f85a5 |
[Fix] (MG_State, MG_Backend): start TEXTURE_COMPARE_FUNC at LEQUAL
SamplerParameters defaulted compareFunc to ALWAYS, but GL 4.6 core table 23.18 and GLES 3.2 table 21.16 both say the initial value is LEQUAL - for sampler objects and for the sampler state a texture object carries alike. Every freshly created texture and sampler therefore answered GL_ALWAYS to glGetTextureParameteriv(GL_TEXTURE_COMPARE_FUNC). The Vulkan backend had been papering over it: ResolveCompareFunc substituted LESS_EQUAL whenever a depth texture was sampled in compare mode and the func still read ALWAYS, which fixed the rendering but also made an explicitly requested GL_ALWAYS unreachable. With the default corrected that special case is both unnecessary and wrong, so it is gone and the compare op is taken straight from the sampler. Takes direct_state_access.textures_defaults from failing to passing on both backends. |
||
|
BZLZHH
|
4873da6844 |
[Fix] (MG_Impl): accept COLOR when invalidating the default framebuffer
The validation added with the invalidation entry points took the default framebuffer's buffers to be only FRONT_LEFT, FRONT_RIGHT, BACK_LEFT, BACK_RIGHT, DEPTH and STENCIL, so a call naming COLOR came back INVALID_ENUM. The by-name forms spell the colour buffer the way glClearNamedFramebuffer does - COLOR, DEPTH, STENCIL - while the target forms use the individual left/right tokens, and both spellings arrive at the same validation, so both sets belong there (GL 4.6 core 17.4.4). Caught by framebuffers_invalidate_data and framebuffers_invalidate_subdata, which had been passing while the entry points were stubs doing nothing at all. Those two plus invalidate_data_and_subdata_errors now pass together on both backends. |
||
|
BZLZHH
|
efeb24ff9b |
[Fix] (MG_Impl, MG_State): answer the texture parameters the getters were missing
glGetTexParameter and its by-name form rejected several parameters GL 4.6 core table 8.20 lists, with INVALID_ENUM as if the application had made them up. GL_DEPTH_STENCIL_TEXTURE_MODE was the worst of them: the float setter accepted it, validated it and then threw the value away, the integer setter did not accept it at all, and neither getter could report it - so the mode could be set and never read back, and setting it through glTextureParameteri was an error. It is real state now, defaulting to DEPTH_COMPONENT, set by both setters and readable from both getters. GL_TEXTURE_LOD_BIAS was in the same position: settable, not gettable. The by-name getters reach the target-based ones through a temporary binding rather than the per-object path, so both had to learn these; the per-object path gained the swizzle components, the target, the image format compatibility type and the texture-view parameters at the same time, since they were missing there for the same reason. direct_state_access.textures_get_set_parameter passes on both backends, and textures_defaults stops raising an internal error and reports an ordinary failure it can be diagnosed from. |
||
|
BZLZHH
|
18c1a4d586 |
[Feat] (MG_Impl): implement the query getters that write into a buffer object
glGetQueryBufferObjectiv and its three siblings were stubs. They are the ordinary query getters with the destination changed from client memory to a buffer object, so everything about the query itself - the name, whether it is still active, the parameter - is already answered by the shared GetQueryObjectValue, including the errors it raises. What was left is the destination: a negative offset is INVALID_VALUE, a name that is not a buffer object is INVALID_OPERATION, and so is a write that would run past the end of the buffer. The four differ only in the width they store, so they share one template. direct_state_access.queries_errors passes on both backends, putting the group at 4 of 5. queries_functional now reaches further into the test and ends in an unrelated InternalError rather than a plain failure. |
||
|
BZLZHH
|
66ac3486e1 |
[Feat] (MG_Impl): validate the framebuffer invalidation entry points
glInvalidateFramebuffer, glInvalidateSubFramebuffer and their two by-name forms were all stubs, so every call - including the malformed ones - returned quietly with no error. These four only grant permission to throw the named attachments' contents away, and keeping them satisfies "the contents become undefined", so the frontend validates the call and leaves the contents alone. Actually discarding is a bandwidth optimisation that would need a backend dependency; it can be added later without changing what any of these promise. The validation is where the real content is. Which tokens name an attachment depends on which framebuffer is affected: the default framebuffer has buffers (FRONT_LEFT and company) and a framebuffer object has attachment points, so a token from the wrong set is INVALID_ENUM. A COLOR_ATTACHMENTm past GL_MAX_COLOR_ATTACHMENTS is different in kind - a well-formed enum naming a point that does not exist - and is INVALID_OPERATION, which the existing colour-attachment range validator already expresses. Negative counts and negative sub-region extents are INVALID_VALUE. direct_state_access.invalidate_data_and_subdata_errors passes on both backends. |
||
|
BZLZHH
|
764a44f589 |
[Fix] (MG_Impl): stop treating an empty buffer mapping access mask as a bad enum
glMapBufferRange and glMapNamedBufferRange rejected an access of zero with INVALID_ENUM. Zero is a perfectly well-formed bitfield value - it contains no invalid flags - and what it violates is the separate rule that a mapping has to ask for read or write access, which GL reports as INVALID_OPERATION. Both callers already checked that rule immediately after, so the validator was reporting the wrong error for a case its callers were about to handle correctly. direct_state_access.buffers_errors passes, which puts the whole buffers group at 4 of 4 on both backends. |
||
|
BZLZHH
|
d96acb7972 |
[Fix] (MG_Impl): let a buffer clear name any format the spec allows
glClearBufferData and friends accepted exactly two argument triples - R8UI with UNSIGNED_BYTE and R32UI with UNSIGNED_INT, both through RED_INTEGER - and raised INVALID_ENUM for everything else. That is most of the entry point missing rather than a narrow gap: GL takes any of the sized formats in the buffer-texture table, which is what an application clearing an RGBA8 or R32F buffer uses. The wrong error also hid the checks behind it. A test clearing a mapped buffer, or one passing a misaligned offset, never reached those rules because the format tuple was rejected first, so INVALID_ENUM came back where INVALID_OPERATION or INVALID_VALUE was due - the validation was there and correct all along, just unreachable. internalformat now goes through the same table the buffer textures use (shared rather than written out twice, since it is the same list for the same reason), and format and type through the ordinary pixel format converters. The element size comes from the internal format, which is what offset and size have to be multiples of. Note that a bad format or type here is INVALID_VALUE, not INVALID_ENUM (GL 4.6 core 6.3) - the odd one out among the enum arguments, and what the conformance tests check for. The pattern is still replicated verbatim, which is correct while the client layout matches the internal format - every real caller, and every conformance case. When they differ it now says so instead of quietly writing a differently-sized pattern. direct_state_access.buffers_clear and buffers_functional pass on both backends; buffers_errors is down to one unrelated complaint about glMapNamedBufferRange. |
||
|
BZLZHH
|
bd710078fc |
[Feat] (MG_Impl): implement glGetNamedBufferSubData
The by-name read was a stub, so it left the caller's buffer untouched and a test comparing it against a reference saw whatever that memory already held. Its by-target sibling glGetBufferSubData was already implemented, so this is that function with the buffer resolved by name instead of through a binding: the same non-negative offset and size check, the same bound-by-the-buffer's-size check, the same refusal to read a buffer mapped without GL_MAP_PERSISTENT_BIT, and the same SyncGpuWrites before the download so a GPU-side write that has not landed yet is not missed. Resolving by name reports INVALID_OPERATION for a name that is not a buffer, which the by-target form expresses as "target is bound to no buffer object" instead. direct_state_access.buffers_get_named_buffer_subdata passes on both backends. |
||
|
BZLZHH
|
95a7b17d45 |
[Fix] (DirectVulkan): clear an integer colour buffer with an integer value
glClearBufferiv and glClearBufferuiv flattened their values into the payload's float vector, and every clear was later written into VkClearColorValue::float32. Vulkan reads that union according to the destination image's format rather than converting between its members, so an R8I attachment cleared to -16 received the bit pattern of -16.0f. On top of that, QueueRenderbufferClear copied only the float vector into the pending clear, so even the flattened value was dropped and the attachment kept reading zero - which is what the conformance tests actually observed. The payload now records which of the three entry points supplied the colour and keeps the value in that form, and one helper builds the union member the encoding calls for. GL's rule that a format with no alpha channel reads as one has to be applied in the value's own type, so the "does this format lack alpha" question is now asked separately from the substitution and the helper applies it to whichever member is live. glClear is left on the float path explicitly: ClearFramebufferPayload has no other form. Takes every integer renderbuffer format in direct_state_access.renderbuffers_storage from failing to passing on Magma - 115 reported mismatches down to 20, the rest being the stencil formats Espryt fails too and SRGB8_ALPHA8 - and makes framebuffers_clear pass on both backends. |
||
|
BZLZHH
|
19932f9e49 |
[Feat] (MG_Impl, MG_Backend): implement the integer direct state access framebuffer clears
glClearNamedFramebufferiv and glClearNamedFramebufferuiv were stubs, so a clear through them was silently dropped and the attachment kept whatever it held. Their float siblings were already implemented, which is what made the gap look like a rendering bug rather than a missing entry point. Which buffers they accept is narrower than glClearNamedFramebufferfv and differs between the two: signed values clear COLOR or STENCIL, unsigned only COLOR (GL 4.6 core 17.4.3.1). Only the colour buffer is indexed, so a stencil clear naming any drawbuffer other than 0 is INVALID_VALUE rather than merely ignored, and anything else is INVALID_ENUM. Resolving the framebuffer by name goes through the same helper the float forms use, which is what reports INVALID_OPERATION for a name that is neither zero nor an existing framebuffer. Both backends express them the way they already express the float forms: DirectGLES binds the named framebuffer and forwards to glClearBuffer*, Magma queues the payload against the named framebuffer rather than the bound one. direct_state_access.framebuffers_clear_errors passes on both backends, and framebuffers_clear passes on Espryt. Magma still fails that one, for a separate reason on the materialization side rather than in these entry points. |