xserver issueshttps://gitlab.freedesktop.org/xorg/xserver/-/issues2023-05-03T17:55:26Zhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1544glamor poorly accelerates the geometry requests2023-05-03T17:55:26ZAdam Jacksonajax@nwnk.netglamor poorly accelerates the geometry requestsBy "geometry" here I mean lines arcs and polygons. There are a few cutouts for axis-aligned zero-width lines and the like, but the general cases all fall down to `mi`'s span path, which is like "eh" efficient for lines and polys but brut...By "geometry" here I mean lines arcs and polygons. There are a few cutouts for axis-aligned zero-width lines and the like, but the general cases all fall down to `mi`'s span path, which is like "eh" efficient for lines and polys but brutally slow for arcs.
You'd like to move that math to the GPU side, and ideally keep within the GLES2 target feature set. One thing GLES2 does have is `discard`. Think about a wide line: draw a tri fan that covers the line with a ~1 pixel border, hit test inside the fragment shader and `discard` if the X primitive shouldn't touch that pixel, otherwise fill as usual. You waste a few fragment shader invocations but those are cheap and CPU time is not. Arcs are the hard case, hit testing isn't trivial and you'd like to emit a somewhat-optimal tri fan covering the arc rather than just resort to axis-aligned rectangle and a _lot_ of `discard`s.
The other hard part of this is join and cap styles and self-intersection and all that other fluff. Ideally the `mi` code would have a clean separation between decomposing those style rules into other truly primitive geometry requests, and decomposing primitives into spans. But it probably doesn't (I no longer remember and am not about to look), and refactoring all of `mi` is a much larger task, so complicated GC state will likely still hit the span code; oh well.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1428RFE: XGE generic event channels2023-02-02T17:39:01ZAdam Jacksonajax@nwnk.netRFE: XGE generic event channelsThe Present extension makes the notable improvement that events are selected and delivered relative to an `EVENTID` type - "event channel" might be a better name. This allows for multiple subsystems within a process to receive a copy of ...The Present extension makes the notable improvement that events are selected and delivered relative to an `EVENTID` type - "event channel" might be a better name. This allows for multiple subsystems within a process to receive a copy of any given event, without affecting other subsystems or needing to rely on a client-side convention for event queue interest. (Well. Kinda. It bakes that convention into libxcb as "special events". Whatever.)
Unfortunately it stops there, and it doesn't really belong there. Event channels ought to be an XGE extension concept, and they should be able to encapsulate arbitrary core or extension events. This could massively improve life on the client side. A few examples off the top of my head:
- Multiple readers could listen for `ConfigureNotify` on the root window, or corresponding RANDR events, and all would get notified
- llvmpipe would be able to use the `send_event=True` version of `ShmPutImage` to increase parallelism
- libX11 could potentially internally redirect event selection to its own private channel, which might finally solve the "who owns the event queue" problem when mixing xcb and xlib in one processhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/998Fix glamor's Render implementation2020-09-04T14:24:18ZAdam Jacksonajax@nwnk.netFix glamor's Render implementationSee the [old wiki](https://www.x.org/wiki/Development/Documentation/GlamorPerformance/#render) for details.See the [old wiki](https://www.x.org/wiki/Development/Documentation/GlamorPerformance/#render) for details.https://gitlab.freedesktop.org/xorg/xserver/-/issues/997Indirect GLX needn't be terrible2020-03-12T18:43:39ZAdam Jacksonajax@nwnk.netIndirect GLX needn't be terribleIndirect GLX has its flaws but many of those flaws are just accidents of implementation, and it's also genuinely useful. The glorious future might involve any or all of:
* Porting the dispatch code generation to either the XCB or Khrono...Indirect GLX has its flaws but many of those flaws are just accidents of implementation, and it's also genuinely useful. The glorious future might involve any or all of:
* Porting the dispatch code generation to either the XCB or Khronos protocol definitions
* Extending support through [OpenGL 3.0](https://github.com/KhronosGroup/OpenGL-Registry/blob/master/xml/glxproto.reserved.txt)
* Interop with [NVIDIA's unofficial protocol](http://us.download.nvidia.com/XFree86/Linux-x86_64/384.59/README/glxsupport.html) if any of that differs from 3.0 above
* Defining support for OpenGL post 3.0
* Improving DMX's GLX support, possibly starting by porting it to the same GLX code as the other servershttps://gitlab.freedesktop.org/xorg/xserver/-/issues/975Move server-internals docs into doxygen2020-05-19T05:09:30ZAdam Jacksonajax@nwnk.netMove server-internals docs into doxygenSome of the [server](doc/Xserver-spec.xml) [internals](hw/xfree86/doc/ddxDesign.xml) documentation is... bad. Though much of it is still quite valid, there's much that is out-of-date, and keeping it separate from the code hasn't helped. ...Some of the [server](doc/Xserver-spec.xml) [internals](hw/xfree86/doc/ddxDesign.xml) documentation is... bad. Though much of it is still quite valid, there's much that is out-of-date, and keeping it separate from the code hasn't helped. It would probably be a good idea (though quite a lot of editorial work) to move the documentation into doxygen-style comments in the code.https://gitlab.freedesktop.org/xorg/xserver/-/issues/896glamor: Accelerate alpha maps2019-09-24T17:56:24ZAdam Jacksonajax@nwnk.netglamor: Accelerate alpha mapsAlpha maps allow the alpha channel for blend operations to be in a different picture than the color channels. This is useful for (for example) blending among x2r10g10b10 surfaces with an external a8 alpha map for increased precision. The...Alpha maps allow the alpha channel for blend operations to be in a different picture than the color channels. This is useful for (for example) blending among x2r10g10b10 surfaces with an external a8 alpha map for increased precision. The implementation in pixman is fairly straightforward to understand; adding it to GL shouldn't be _that_ hard if you have multiple render targets.https://gitlab.freedesktop.org/xorg/xserver/-/issues/863glamor, but for vulkan2019-07-26T09:40:24ZAdam Jacksonajax@nwnk.netglamor, but for vulkanGL's awesome, but a bit heavyweight. It would be cool to have a Vulkan-based acceleration backend instead. Ideally the GLSL would be shared between the two as far as possible.GL's awesome, but a bit heavyweight. It would be cool to have a Vulkan-based acceleration backend instead. Ideally the GLSL would be shared between the two as far as possible.https://gitlab.freedesktop.org/xorg/xserver/-/issues/628glamor's gradient code could probably be better2020-09-03T17:05:05ZAdam Jacksonajax@nwnk.netglamor's gradient code could probably be betterIf memory serves, the gradient shaders are the ones most likely to push us over the instruction limit on i915 and similarly sad devices, probably due to the massive if/else chain.
Since gradient stops are defined as 16.16 fixed point va...If memory serves, the gradient shaders are the ones most likely to push us over the instruction limit on i915 and similarly sad devices, probably due to the massive if/else chain.
Since gradient stops are defined as 16.16 fixed point values in the range [0,1], there are a maximum of 65537 stops. It might be worthwhile to pre-render the gradient as a 1D texture and sample from that in the shader. For extra credit you could pre-render the gradient with the GPU too. This does use a bit more memory - 256k or so per gradient - but could easily be more performant as well as needing fewer shader instructions.https://gitlab.freedesktop.org/xorg/xserver/-/issues/918Pseudocolor visual emulation with Composite2019-10-16T19:12:20ZAdam Jacksonajax@nwnk.netPseudocolor visual emulation with CompositeEasy enough to add the synthetic visual. Tricky bit is setting up unlimited colormaps so each window can have its own, and also implementing accelerated c8->rgba32 expansion in Render.Easy enough to add the synthetic visual. Tricky bit is setting up unlimited colormaps so each window can have its own, and also implementing accelerated c8->rgba32 expansion in Render.https://gitlab.freedesktop.org/xorg/xserver/-/issues/386The server needs 32 bit regions2020-04-03T16:25:17ZBugzilla Migration UserThe server needs 32 bit regions## Submitted by David Ronis
Assigned to **Adam Jackson `@ajax`**
**[Link to original bug (#25270)](https://bugs.freedesktop.org/show_bug.cgi?id=25270)**
## Description
I've been following the git master of Xorg. I tried viewing ...## Submitted by David Ronis
Assigned to **Adam Jackson `@ajax`**
**[Link to original bug (#25270)](https://bugs.freedesktop.org/show_bug.cgi?id=25270)**
## Description
I've been following the git master of Xorg. I tried viewing a magicpoint presentation today and X aborted. The first slide displays properly (it's basically text). The second is also simple text, displays as it should, but then X crashes. I captured the message from startx shown in the summary on a remote screen. I very vaguely recall having a similar problem with pixman several months ago.
This happens only on one of the machines I tried it on. This uses the radeon ati driver.
Version: githttps://gitlab.freedesktop.org/xorg/xserver/-/issues/136Expose low-depth visuals through Composite2019-05-10T17:31:27ZBugzilla Migration UserExpose low-depth visuals through Composite## Submitted by Adam Jackson `@ajax`
Assigned to **Adam Jackson `@ajax`**
**[Link to original bug (#4770)](https://bugs.freedesktop.org/show_bug.cgi?id=4770)**
## Description
Only four drivers actually use the overlay cores: glint...## Submitted by Adam Jackson `@ajax`
Assigned to **Adam Jackson `@ajax`**
**[Link to original bug (#4770)](https://bugs.freedesktop.org/show_bug.cgi?id=4770)**
## Description
Only four drivers actually use the overlay cores: glint, sunffb, chips, and mga.
They're based on cfb, and as a result they don't support Render and have known
correctness and stability bugs.
The solution is to add additional visuals when Composite is active, and force
windows created on those visuals to always be composited even when no compmgr is
active. This would provide a sort of overlay emulation for every driver using
fb, and would allow the removal of the overlay cores.
Version: git