[HN Gopher] Nvidia RTX Remix Runtime Open Source Available Now
___________________________________________________________________
Nvidia RTX Remix Runtime Open Source Available Now
Author : cbg0
Score : 279 points
Date : 2023-04-13 08:00 UTC (15 hours ago)
(HTM) web link (www.nvidia.com)
(TXT) w3m dump (www.nvidia.com)
| paulmd wrote:
| It's too bad this is a no-go for online/competitive games, which
| tbh are a decent number of the DX9 games still worth playing. I'd
| love to use this on Team Fortress 2 but I don't want to risk it
| on my account with all my items without some kind of explicit
| approval, since this hooking/injection probably looks just like a
| hack to VAC.
|
| But path-traced TF2 would own lol.
| smoldesu wrote:
| It might be fine. If it's just messing with the way DXVK is
| being presented, it's not very different from the "hacking"
| people use to get DirectX games working on Linux. AFAIK, games
| aren't really picky about graphics API calls as long as
| everything behaves as-expected.
| Bjartr wrote:
| Aren't there non-VAC servers you could play on?
| amelius wrote:
| Perhaps a stupid question, but with all the recent advances in
| computer graphics, why do I still see polygons everywhere in
| computer games? Is it really that hard to round those corners?
|
| I think we are optimizing the wrong thing. I think I'm not alone
| in wanting round objects more than perfectly ray-traced but
| polygonal objects.
| drakythe wrote:
| Short answer? It depends, but "yes" is more generally going to
| be true than not.
|
| The smoother the edges the more polygons there are. The more
| polygons there are the more work the processor has to do to
| render them. In a very basic sense.
|
| Now, it is absolutely possible to round the corners without
| incurring heavy processing cost but then you're probably not
| going to get good collision, instead you'll get incredibly
| obvious clipping (when one seemingly solid object passes
| through another without triggering collision).
|
| So game developers have to make a choice: look good in still
| photos or look good in gameplay? (Clipping is a jarring
| experience while playing). Bonus benefit: if you do it right
| the lower polygon count and less fancy graphic stuff means your
| game runs on a wider variety of hardware (smartphones, switch,
| Xbox/PlayStation, PC, specialty stuff).
|
| And that's all not even getting into the cost of paying an
| artist to round those corners. Do you balloon your art payroll
| and have dozens of artists working on a few hundred "perfect"
| assets or would you rather they work on thousands of assets
| that are styled consistently and damn the real world
| verisimilitude? Games are a passion for many but capitalism
| invokes a cost when making them.
| amelius wrote:
| Ok so instead of paying an artist to round those corners why
| not pay them to make round assets, then let the computer
| approximate them with polygons when and where appropriate?
| midnightclubbed wrote:
| There have been attempts to go that route from both the
| hardware (eg Nvidia NV1, 1995) and software side (eg Quake
| 3 Area, 1999) and many attempts to render curved surfaces
| since. Generally triangles have remained dominant because
| they are easier to model, easier to manipulate and are
| rendered extremely optimally on hardware.
|
| The approximation to polygons when rendering is a non
| trivial task. Individual curved patches can be easily
| approximated to triangles but once you connect those
| patches together you have to ensure that the tessellated
| triangle edges match between neighboring patches. For the
| most part it is just easier and more performant to model
| with triangles and brute-force render them. One day curved
| surfaces may be a better choice but currently triangles are
| dominant.
| ElectricalUnion wrote:
| > pay them to make round assets
|
| Those require NURBS, Non-uniform rational basis spline, and
| (almost) no one does NURBS assets, because it is most of
| the time it is a unnecessary pain to use and manipulate
| them directly.
| zokier wrote:
| NURBS is just one way of representing curved surfaces.
| Implict surfaces are another promising way of doing
| curves, and there are probably others too
| ohgodplsno wrote:
| A few reasons:
|
| - "Infinite" detail, like models that would be described by
| curves and others are mathematically absurdly expensive. And
| when you need your entire frame to be out in 16ms, there really
| isn't much space to keep both the advancements _and_ new very
| expensive math. It's done for some things like font rendering
| (see Slug), but it would be horrible for everything to be done
| that way.
|
| - All of the tooling is still made around triangles and
| exporting meshes made out of triangles, because that's how
| everyone works.
|
| - It's how everyone works because your GPU is good at one
| thing: triangles. It has dedicated units for that single goal:
| take triangles, and rasterize them to the screen. So, even if
| you made a brand new GPU with a Bezier Engine :tm: in there to
| make it efficient... well you still have to support all of the
| GPUs that only know how to do triangles, and you're back to
| doing math to transform these into triangles.
|
| - Even if you do that, surprise, your screens don't do curves
| either, nor do your framebuffers! They're a bunch of pixels, so
| you just transferred your aliasing problems from "triangles
| along a grid don't look good" to "you need to match your curve
| to your grid", and if your detail becomes small enough, you now
| also have aliasing there.
|
| - There's nothing that we have in this world that is round and
| we can't do a convincing job of with triangles. Sure, maybe
| something that has absurd scale, like a planet you can both see
| from outer space and up close: that'd be a lot of triangles to
| make it look smooth at all angles. It would be kind of
| performance wasting, but you can do it. And techniques like
| Nanite would actually even fix the problem a little bit.
| zokier wrote:
| Its not that absurdly expensive. Something like this renders
| at interactive rates on webgl:
| https://www.shadertoy.com/view/4tByz3
| TechSquidTV wrote:
| Pretty much Eunreal Engine 5 is going to completelyt fix this,
| but it's pretty new. Other engine's will pick up the same
| techniques. In 5ish years, this problem will be long gone.
| artificial wrote:
| Nanite forest biome, simply gorgeous! You can pull in Houdini
| to procedurally generate a host of things inside UE.
| https://www.unrealengine.com/marketplace/en-
| US/product/redwo...
| jayd16 wrote:
| There really hasn't been great automatic mesh detail scaling
| techniques outside of tesselation shaders and they're not super
| easy for an artist to work with.
|
| Unreal 5's Nanite system is a big step up but it's brand new
| and unique. Not many games are out yet and no other big engines
| have a competitor technology.
| brylie wrote:
| In short, it's about the trade-off between quality and
| performance. Also, not all corners need to be round.
|
| The following article provides an in-depth exploration of how
| polygon count affects performance.
|
| https://www.linkedin.com/pulse/polycount-understanding-model...
| [deleted]
| outworlder wrote:
| > Is it really that hard to round those corners?
|
| Yes.
|
| They are unlikely to ever be 'round'. Perhaps when the entire
| scene, and not just reflections is rendered by raytracers. That
| way one can represent mathematically correct curves. At that
| point we'll basically be throwing away all advancements in GPU
| tech.
|
| Besides, it's utterly unnecessary when we can fake roundness by
| increasing the number of polygons and by clever illumination.
| [deleted]
| epolanski wrote:
| Remix has been available from quite some time.
|
| Anything interesting has been released with it? Any mod.
|
| I haven't heard/seen anything.
| erk__ wrote:
| The most well known example is probably the Portal mod
|
| https://www.youtube.com/watch?v=AZHBl5yWqJk
| hbn wrote:
| I'm pretty sure that's the only example because it's made by
| Nvidia themselves as a showcase for this tech because they
| were the only ones with access to it until today.
|
| i.e. it hasn't been available until today.
| jjbinx007 wrote:
| I found it to be very impressive, although eventually it
| caused a few performance stutters on my laptop after extended
| playing.
|
| What a shame it can only be used on older DX 7 and 8 games.
| christkv wrote:
| I think it's DX8 and 9 not sure about 7.
| scandinavian wrote:
| It has not been available, it was just released, hence the news
| being submitted here. Before this the only way to use it was to
| just take the dll from Portal RTX and try to throw it at old
| games hoping it would work.
| robertkrahn01 wrote:
| From the workflow shown in the video it might even make sense to
| build a low-res game now with DirectX 9 and "mod it up"? The
| texture upscaling and material inference as well as the direct
| modification capabilities look amazing!
| jayd16 wrote:
| I don't think I'd go that far, haha. Building a good looking
| low res texture is probably harder than getting a nice modern
| one.
| aceazzameen wrote:
| This is amazing! Is it also possible to add animation or effects
| to objects/characters that didn't previously exist? Or update
| existing ones?
| rasz wrote:
| >Because Remix is build on Nvidia OnlyVerse
|
| hehe
|
| Someone at Nvidia of all places uploads YT video with gameplay
| footage at 1080 30fps with bad frame pacing and stuttering.
|
| Cool technology. Dont know what game publishers are going to say
| about it, Rockstar sued for less.
| amrb wrote:
| I could see Nvidia licensing the tech to game publishers but
| they didn't get much uptake, so open source it is.
| christkv wrote:
| Seems like it would have to work on AMD and Intel as well for
| it to be a viable path.
| amrb wrote:
| We have seen hair works as a Nvidia only tech.. Compatibly
| could be why the licence theory was rejected.
| petermcneeley wrote:
| What was the previous suit by rockstar. I have seen suits where
| people were selling mods that circumvented DRM.
| [deleted]
| sintax wrote:
| Looks like it's based on DXVK from
| https://github.com/doitsujin/dxvk
| cube2222 wrote:
| How does something like this work?
|
| Don't most of these games have custom code for rendering and
| lighting? How is this able to fit into that custom code
| automatically?
|
| Or is the automation here very limited and you just have to
| reverse engineer these and find the right hookpoints, while this
| project just provides the code that you can hook into the games?
| [deleted]
| dev_snd wrote:
| This is the reason it only works with directx 8 or 9: they have
| a pretty rigid render path with a clearly separated vertex and
| pixel shader pipeline.
|
| For directx 8, you would for example specify light sources as
| part of special draw calls to the directx API, which makes it
| easier to translate them to a ray traced scene graph.
|
| Shader tools like reshare also use heuristics to detect which
| of the framebuffers contains a depth map to add effects like
| SSAO to older games.
|
| I imagine that rtx remix can to similar things to detect where
| in a shader the light coordinates are stored: after all most
| shaders look pretty similar when it comes to implementing a
| Phong shader etc.
| qikInNdOutReply wrote:
| For everything over it, nvidia would have to expose the
| byzantine monstrosity that is the drivers they wrote, that
| detect games and hotswap the buggy developer shadercode out
| for working nvidia shader code. And they could do that for
| older titles. It just wouldnt be neat.
| l33tman wrote:
| It hooks into the DirectX fixed-function pipeline used back in
| the day (i.e. where you set up model/view/projection matrices
| and lightsource coordinates and surface materials and sent to
| OpenGL/Direct3D), so it knows what the programmer wanted to do,
| and from there it's "easy" to replace everything.
|
| Excerpt: "Scene manager, which uses information coming through
| the D3D9 fixed function API to create a representation of the
| original scene, track game objects frame to frame, and set up
| the scene to be path traced."
| prettyStandard wrote:
| So we should expect some builds for Steam & Proton?
| ptato wrote:
| For Morrowind it didn't just upgrade the rendering, it completely
| changed the aesthetic of the scene. Is that on purpose? At that
| point you can't call the results better, only different.
| bee_rider wrote:
| It is true that it changes the aesthetic a bit, and it is a
| change rather than a straight upgrade.
|
| But the old rendering pipeline still exists I guess, and the
| new one look wicked cool.
| Arrath wrote:
| It seems you'd certainly be able to go in and just tweak the
| lighting without doing all the AI touchups, texture upscaling,
| and model swaps as they did in the video. Pretty wild stuff,
| either way.
| mordae wrote:
| It ended up looking similar to Oblivion. So I'd wager a guess
| that it was the intended aesthetic, only limited by the older
| technology.
|
| The only authority here would be the original designers.
| jandrese wrote:
| It seems like the big change is that the light sources now
| actually emit light so the scene becomes a lot brighter. Maybe
| part of the process should be turning down global illumination?
| That might make dark corners even more dark however, and
| "hidden" clues that were supposed to be difficult to see may
| become outright invisible.
| FloatArtifact wrote:
| It's a shame that this isn't GPU agnostic.
| jsheard wrote:
| It is technically GPU agnostic, the injected renderer should
| run on any hardware that supports Vulkan raytracing. The design
| of the renderer certainly plays to the strengths of Nvidia's
| architectures though, so performance is quite bad on AMD cards.
| wing-_-nuts wrote:
| performance is terrible on just about everything. even a 4090
| doesn't get above 30 fps on rtx portal without dlss helping
| out at 4k. A 4090!
|
| Honestly, this seems to be nvidia's way of making everything
| look _slightly_ better while requiring _massively_ stronger
| hardware. It feels like this was purposely done to
| disadvantage amd and intel
| sigstoat wrote:
| > even a 4090 doesn't get above 30 fps on rtx portal
| without dlss helping out at 4k. A 4090!
|
| hmm, yeah, i just tried turning off DLSS on a 3080. that
| went very poorly.
|
| > It feels like this was purposely done to disadvantage amd
| and intel
|
| they're competitors? "have some free stuff, p.s. we only
| spent time optimizing it for things we sell" seems pretty
| ok to me.
| nix0n wrote:
| > "have some free stuff, p.s. we only spent time
| optimizing it for things we sell"
|
| The funny part is, that's exactly what Intel did with
| their C++ compiler.
|
| https://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler
| ChoGGi wrote:
| What better way to sell expensive hardware?
| nanidin wrote:
| Support cryptocurrency developers that commit to GPU only
| proof of work schemes for X years. Pump the price of said
| cryptocurrency.
| danudey wrote:
| For only $1500 USD you can have the prettiest version of
| Portal at framerates we haven't seen in fifteen years!
| shados wrote:
| > at framerates we haven't seen in fifteen years
|
| Now now, lets not forget consoles exist.
| wing-_-nuts wrote:
| The PS5 runs most games at 4k 60. Granted, it's scaled on
| some games, but that _really_ doesn 't matter when it's
| being outputted to a TV sitting 10 feet or more away from
| the viewer.
|
| I get _why_ they did what they did, because most TVs now
| days are 4k, but if you know enough about the limits of
| human vision, it 's pretty clear that 4k is a waste for
| console gaming. It makes much more sense on PC, but even
| there the biggest noticeable difference is reading text,
| not playing games.
| hbn wrote:
| It was only this latest generation of consoles that
| started giving a shit about framerates again because they
| basically hit diminishing returns on pumping more
| triangles into every mole of every NPC, and resolutions
| were good enough at 4k, so framerates were suddenly
| something important enough to care about.
|
| But the PS4/Xbone/Switch and prior 3D consoles certainly
| treated 30fps (sometimes less) as a standard in most
| cases. There's a reason people want to get Bloodborne
| ported somewhere else, because currently the only way to
| play it (PS4) is locked at 30fps.
| taf2 wrote:
| It's opened now so perhaps another graphics company will invest
| the time to make that happen?
| prettyStandard wrote:
| Is Nvidia making good on its promise to Open Source it's drivers
| a d stuff? They may not give us everything but this must be the
| third or fourth announcement from Nvidia on some open source they
| are providing I have seen in the past year or so.
| kkielhofner wrote:
| Nvidia really hurt themselves with their long-standing closed
| source driver position. In many circles (like HN) they burned a
| lot of goodwill and mindshare because of their driver stance
| and effect it has had on Linux desktop users. It is an
| extremely tiny population (in terms of numbers) BUT those users
| (like the HN users) have an outsized impact due to the tendency
| for them to be in technical and decision making positions.
|
| However, Nvidia (other than the driver) has a TON of open
| source work. In addition to contributions all over the place in
| the relevant open source ecosystems/projects they have 349
| repos on Github[0]. They also have a variety of different
| organizations on Github (for some reason) like Triton Inference
| Server that has another 30 repos[1]. If you start wandering
| through these repos these aren't small efforts either - it's
| clear Nvidia puts a TON of resources and investment in open
| source.
|
| At the risk of making this another Nvidia vs AMD thread, AMD
| (the open source desktop darling) by comparison has 39 repos on
| Github[2]. Their entire project for ML has a total of another
| 39 repos[3].
|
| If it weren't for the proprietary closed-source desktop driver
| souring people it would be clear and obvious how much of a
| supporter of open source Nvidia is.
|
| [0] - https://github.com/NVIDIA
|
| [1] - https://github.com/triton-inference-server
|
| [2] - https://github.com/amd
|
| [3] - https://github.com/RadeonOpenCompute
| nazgulsenpai wrote:
| NVIDIA open sourcing lots of non-graphic driver codebases
| doesn't excuse them from open-sourcing their graphic drivers.
| It's simple really.
| the8472 wrote:
| They did[0], for GPU models where they moved all the
| proprietary parts into the firmware.
|
| [0] https://github.com/NVIDIA/open-gpu-kernel-modules#user-
| conte...
| kkielhofner wrote:
| I'm not saying it does.
|
| Your comment is exactly what I'm talking about "Nvidia has
| millions of lines of open source" "Yeah but their driver
| though - they hate open source and I hate them". It's not
| that simple.
| nazgulsenpai wrote:
| I never said they hate open source or that I hate them. I
| just don't care how much open source they do if the the
| driver for only product that matters to me isn't open
| source. Their competitors' drivers are so it makes my
| decision easy.
|
| I'm not sure why it would bother anyone else that I find
| their lack of open source graphic drivers problematic.
| paulmd wrote:
| AMDGPU-pro is closed and there's a lot of features like
| raytracing that don't work on the open version at all.
| HDMI 2.1 doesn't work on either open or closed versions
| afaik (there is a long-running ticket complaining about
| it). And they also still have blobs too despite all that.
|
| https://gitlab.freedesktop.org/drm/amd/-/issues/1417
|
| https://git.kernel.org/pub/scm/linux/kernel/git/firmware/
| lin...
|
| Nobody's drivers are totally open, if you use HDMI then
| you aren't allowed to be fully open because HDMI Forum
| won't let you, that's the brightline. You have to have
| some blobs to deal with them and similar ultimatums from
| other vendors.
|
| If you are ok with _something_ working, as long as it 's
| open, and major features being broken doesn't bother
| you... might I suggest nouveau? AFAIK NVIDIA has even
| started addressing the reclocking issue on the newer
| gens.
| nazgulsenpai wrote:
| I'm not entirely sure what point you're trying to make
| here. I didn't suggest the entire stack has to be open
| source, nor am I looking for a reason to use NVIDIA on
| Linux. I just think it would be great if NVIDIA open
| sourced whatever portions of their graphics driver to
| make the Mesa implementation competitive.
| kimixa wrote:
| Counting github repos is too dependent on how projects or
| organized to be anywhere near a useful metric - especially as
| one of the major advantages of open source is integration to
| the corresponding open source projects, like the linux kernel
| and mesa, which aren't under AMD's github.
|
| And even then that count misses a large number of projects,
| like things under OpenGPU (https://github.com/GPUOpen-Drivers
| and https://github.com/GPUOpen-LibrariesAndSDKs) for example.
|
| It is in NVidia's best interest to foster the ecosystem
| around their closed system after all, so long as it's all
| built upon a foundation they control (Their closed source
| driver, and proprietary interfaces like CUDA). Nobody thought
| '90s microsoft was an open source beacon, yet they "gave
| away" a large amount of code - mainly win32 examples and the
| like.
|
| For someone who claims to be trying to avoid some "Which
| corporation that doesn't know you exist is the best" fight
| you have chosen a rather specific unbalanced comparison.
| bsder wrote:
| > Counting github repos is too dependent on how projects or
| organized to be anywhere near a useful metric
|
| Agreed. Nvidia have a lot of _abandoned_ Github repos where
| they dumped code and ran away. This lets them obey the
| letter of the law and release code without anybody being
| able to make use of it.
| kkielhofner wrote:
| Not sure why or how this is a "fight" other than (as stated
| in my first comment) it's one of the more ridiculous
| religious wars that seems to erupt on HN for reasons I'll
| never understand.
|
| I'm not going to do a full LoC analysis for an HN comment
| or analyze recent commits. It was a sixty second way to say
| "Nvidia has a lot of open source and the reductive HN
| take/experience from Linux desktop users solely based on
| their experience with drivers is a tiny piece of the
| picture".
|
| That said I would bet a dinner that a full analysis of
| Nvidia open source vs anyone else in the field would favor
| Nvidia handily.
| kimixa wrote:
| > That said I would bet a dinner that a full analysis of
| Nvidia open source vs anyone else in the field would
| favor Nvidia handily.
|
| It feels a bit weird to agree that any attempt at
| comparing is silly, and even agreeing on how to compare
| impossible to define, immediately followed by "But I bet
| I'd win anyway".
| pjmlp wrote:
| It is doing just fine in Hollywood, CAD folks and GPGPU.
|
| Many companies would dream to hurt themselves that bad.
| royjacobs wrote:
| This is such a good way to make these old games look really
| spectacular. 2d graphics of the era haven't aged particularly
| badly but old 3d games usually look pretty janky (imo!). Being
| able to literally see them in a new light is wonderful.
| zokier wrote:
| There is increasing newfound appreciation for that early 3d
| visual look though. You can see that in new games being clearly
| inspired by that look, for example Dusk (with "overwhelmingly
| positive" rating):
| https://store.steampowered.com/app/519860/DUSK/
| Arrath wrote:
| Maybe I spent far too much time playing Morrowind, but that
| place just feels homey. Low poly models and muddy textures and
| all.
| officeplant wrote:
| I love it, but projects like OpenMorrowind and Daggerfall
| Unity have given me new appreciation for the older games I
| struggled with as a kid.
| hbn wrote:
| I also feel like cranking up the quality of scenes like this
| is just gonna make it more jarring when you talk to an NPC,
| the world freezes, and their cold, dead eyes stare into your
| soul as their mouth awkwardly wiggles around and corny voice
| acting is played at you.
| anthk wrote:
| This would work great on the first Max Payne. Now if Havok was
| under a libre license... (or a Max Payne engine reimplementation
| a la re3/openrw).
| amrb wrote:
| feel more likely to rip game assets and build in a supported
| engine like Unreal.
| v7n wrote:
| MP 1 & 2 remakes are in the works by Remedy
|
| https://www.remedygames.com/games/max-payne-remake/
| henriquecm8 wrote:
| I played Max Payne recently, and didn't find a way to fix the
| audio problems, other than that it runs great.
| anthk wrote:
| https://www.pcgamingwiki.com/wiki/Max_Payne#Missing_audio
| panki27 wrote:
| According to the user guide [0], it's as simple as dragging the
| provided DLL into the game folder. I'm going to try this out with
| one of my old favorites today, I doubt it'll be quite this easy.
|
| [0] https://github.com/NVIDIAGameWorks/rtx-remix/wiki/runtime-
| us...
| amrb wrote:
| The of the widescreen fixes for the Unreal games was the
| addition of a dll file in the game folder.
| moron4hire wrote:
| I believe the DLL alone only makes the game moddable.
| Thereafter, there's still a lot of work to do to swap out low
| resolution and poly-count assets for more detailed ones.
| capableweb wrote:
| The video seems to hint that some of the process of upgrading
| models can be done automatically with AI-assisted tooling.
| moron4hire wrote:
| Yeah, but not live at runtime. It's still a pre-process
| that needs to be applied per game. Maybe just dropping the
| DLL into the game folder will upgrade the lighting
| automatically, in the rare cases these older games used
| real-time lighting. But real-time lighting, as far as I
| remember, was a pretty rare technique, opting instead to
| bake lighting into textures during asset compilation.
| jsheard wrote:
| The graphical tool shown for swapping out assets also isn't
| available yet, though it's supposed to be coming "soon".
| boywitharupee wrote:
| Would this work for counterstrike 1.6 or halflife?
| panki27 wrote:
| I loaded up HL2 with this, it's the only game I've tested so
| far that actually loads the DLL correctly. I can toogle the
| overlay menu and I've gotten one of the menu screens to look
| somewhat OK. After loading into Route Canal or Sandtraps,
| it's pitch black, aside from the weapon and the buggy. Spent
| like half an hour messing with the settings but I couldn't
| get it to work well.
|
| NFS:U2 and GTA:SA do not start at all with the DLL present.
| danielrpa wrote:
| There we go pay for Skyrim again...
| andrewstuart wrote:
| You too?
| MikusR wrote:
| Doesn't work for Skyrim. Only old games
| flangola7 wrote:
| Skyrim is super old
| MikusR wrote:
| Not old enough
| ohgodplsno wrote:
| Special Edition will not work, but release Skyrim is a DX9
| game, it will work.
| MikusR wrote:
| Skyrim is shader based so rtx remix won't work.
| PufPufPuf wrote:
| 2011 was 12 years ago
| zokier wrote:
| Remix seems to be targeting roughly 2000-2005 era games, so
| decade older than Skyrim. Even Oblivion might be too modern
| for it.
| [deleted]
| ralmidani wrote:
| Will it run on Crysis?
| willis936 wrote:
| Crysis has a DX9 mode, so maybe.
| callesgg wrote:
| The crysis dx9 mode does most likely not use the dx9 fixed
| pipeline.
___________________________________________________________________
(page generated 2023-04-13 23:00 UTC)