DataBloom

A team of scientists have created a new AI-based tool to help lock up greenhouse gases like CO2 in porous rock formations faster and more precisely than ever before. Carbon capture technology, also referred to as carbon sequestration, is a climate change mitigation method that redirects CO2 emitted from power plants back underground. While doing Read article >

The post Rock On: Scientists Use AI to Improve Sequestering Carbon Underground appeared first on NVIDIA Blog.

This post describes different ways to compile an application using various development environments for the BlueField DPU.

Step-A 

Step-B 

Go get a cup of coffee… 

Step-C 

How often have you seen “Go get a coffee” in the instructions? As a developer, I found early on that this pesky quip is the bane of my life. Context switches, no matter the duration, are a high cost to pay in the application development cycle. Of all the steps that require you to step away, waiting for an application to compile is the hardest to shake off. 

As we all enter the new world of NVIDIA Bluefield DPU application development, it is important to set up the build-step efficiently, to allow you to {code => compile => unit-test} seamlessly. In this post, I go over different ways to compile an application for the DPU. 

Free range routing with the DOCA dataplane plugin 

In the DPU application development series, I talked about creating a DOCA dataplane plugin in FRR for offloading policies. FRR’s code count is close to a million lines (789,678 SLOC), which makes it a great candidate for measuring build times.  

Developing directly on the Bluefield DPU 

The DPU has an Arm64 architecture and one quick way to get started on DPU applications is to develop directly on the DPU. This test is with an NVIDIA BlueField2 with 8G RAM and 8xCortex-A72 CPUs. 

I installed the Bluefield boot file (BFB), which provides the Ubuntu 20.04.3 OS image for the DPU. It also includes the libraries for DOCA-1.2 and DPDK-20.11.3. To build an application with the DOCA libraries, I add the DPDK pkgconfig location to the PKG_CONFIG path.

root@dpu-arm:~# export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/mellanox/dpdk/lib/aarch64-linux-gnu/pkgconfig 

Next, I set up my code workspace on the DPU by cloning FRR and switching to the DOCA dataplane plugin branch.

root@dpu-arm:~/code# git clone https://github.com/AnuradhaKaruppiah/frr.git 
root@dpu-arm:~/code# cd frr 
root@dpu-arm:~/code/frr# git checkout dp-doca 

FRR requires a list of constantly evolving prerequisites that are enumerated in the FRR community docs. With those dependencies installed, I configured FRR to include the DPDK and DOCA dataplane plugins.

root@dpu-arm:~/code/frr# ./bootstrap.sh 

root@dpu-arm:~/code/frr# ./configure --build=aarch64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=${prefix}/lib/aarch64-linux-gnu --libexecdir=${prefix}/lib/aarch64-linux-gnu --disable-maintainer-mode --disable-dependency-tracking --enable-exampledir=/usr/share/doc/frr/examples/ --localstatedir=/var/run/frr --sbindir=/usr/lib/frr --sysconfdir=/etc/frr --with-vtysh-pager=/usr/bin/pager --libdir=/usr/lib/aarch64-linux-gnu/frr --with-moduledir=/usr/lib/aarch64-linux-gnu/frr/modules "LIBTOOLFLAGS=-rpath /usr/lib/aarch64-linux-gnu/frr" --disable-dependency-tracking --disable-dev-build --enable-systemd=yes --enable-rpki --with-libpam --enable-doc --enable-doc-html --enable-snmp --enable-fpm --disable-zeromq --enable-ospfapi --disable-bgp-vnc --enable-multipath=128 --enable-user=root --enable-group=root --enable-vty-group=root --enable-configfile-mask=0640 --enable-logfile-mask=0640 --disable-address-sanitizer --enable-cumulus=yes --enable-datacenter=yes --enable-bfdd=no --enable-sharpd=yes --enable-dp-doca=yes --enable-dp-dpdk=yes 

As I used the DPU as my development environment, I built and installed the FRR binaries in place:

root@dpu-arm:~/code# make –j12 all; make install 

Here’s how the build times fared. I measured that multiple ways:

• Time to build and install the binaries using make -j12 all and make install
• Time to build the same binaries but also assemble them into a Debian package using dpkg-buildpackage –j12 –uc –us 

The first method is used for coding and unit testing. The second method of generating debs is needed to compare with build times on other external development environments.

DPU-ARM build Times	Real	User	Sys
DPU Arm   (Complete make)	2min 40.529 sec	16min 29.855 sec	2min 1.534 sec
DPU Arm   (Debian package)	5min 23.067 sec	20min 33.614 sec	2min 49.628sec

The difference in times is expected. Generating a package involves several additional steps. 

There are some clear advantages to using the DPU as your development environment.

• You can code, build and install, and then unit-test without leaving your workspace.
• You can optimize the build for incremental code changes.

The last option is usually a massive reduction in build time compared to a complete build. For example, I modified the DOCA dataplane code in FRR and rebuilt with these results:

root@dpu-arm:~/code/frr# time make –j12 

>>>>>>>>>>>>> snipped make output >>>>>>>>>>>> 

real    0m3.119s 

user   0m2.794s 

sys     0m0.479s 

While that may make things easier, it requires reserving a DPU indefinitely for every developer for the sole purpose of application development or maintenance. Your development environment may also require more memory and horsepower, making this a less viable option long-term. 

Developing on an x86 server 

My Bluefield2 DPU was hosted by an x86-64 Ubuntu 20.04 server, and I used this server for my development environment.

root@server1-x86:~# lscpu |grep "CPU(s):|Model name" 

CPU(s):               32 

Model name:    Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz 

root@server1-x86:~# grep MemTotal /proc/meminfo 

MemTotal:       131906300 kB 

In this case, the build-machine is x86 and the host-machine where the app is going to run is DPU-Arm64. There are several ways to do this:

• Use an Arm emulation on the x86 build-machine. A DOCA development container is available as a part of the DOCA packages.
• Use a cross-compilation toolchain. 

In this test, I used the first option as it was the easiest. The second option can give you a different performance but creating that toolchain has its challenges. 

I downloaded and loaded the bfb_builder_doca_ubuntu_20.04 container on my x86 server and fired it up.

root@server1-x86:~# sudo docker load -i bfb_builder_doca_ubuntu_20.04-mlnx-5.4.tar 
root@server1-x86:~# docker run -v ~/code:/code --privileged -it -e container=dock 
er doca_v1.11_bluefield_os_ubuntu_20.04-mlnx-5.4:latest 

The DOCA and DPDK libraries come preinstalled in this container, and I just had to add them to the PKG_CONFIG path.

root@86b87b0ab0c2:/code # export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/mellanox/dpdk/lib/aarch64-linux-gnu/pkgconfig 

I set up the workspace and FRR prerequisites within the container, same as with the previous option.

root@86b87b0ab0c2:/code # git clone https://github.com/AnuradhaKaruppiah/frr.git 
root@86b87b0ab0c2:/code # cd frr 
root@86b87b0ab0c2:/code/frr # git checkout dp-doca 

I could build my application within this DOCA container, but I couldn’t test it in place. So, the FRR binaries had to be built and packaged into debs, which are then copied over to the Bluefield DPU for testing. I set up the FRR Debian rules to match the FRR build configuration used in the previous option and generated the package:

root@86b87b0ab0c2:/code/frr # dpkg-buildpackage –j12 –uc -us 

Table 2 shows how the build time compares with previous methods.

DPU-Arm & X86 Build Times	Real	User	Sys
DPU Arm  (Complete make)	2min 40.529sec	16min 29.855sec	2min 1.534sec
DPU Arm  (Debian package)	5min 23.067sec	20min 33.614sec	2min 49.628sec
X86 + DOCA dev container  (Debian package)	24min 19.051sec	139min 39.286s	3min 58.081sec

The giant jump in build time surprised me because I have an amply stocked x86 server and no Docker limits. So, it seems throwing CPUs and RAM at a problem doesn’t always help! This performance degradation is because of the cross architecture, as you can see with the next option. 

Developing in an AWS Graviton instance 

Next, I tried building my app natively on Arm but this time on an external server with more horsepower. I used an Amazon EC2 Graviton instance for this purpose with specs comparable to my x86 server. 

• Arm64 arch, Ubuntu 20.04 OS
• 128G RAM 
• 32 vCPUs 

root@ip-172-31-28-243:~#  lscpu |grep "CPU(s):|Model name" 
CPU(s):              32 
Model name:   Neoverse-N1 
root@ip-172-31-28-243:~# grep MemTotal /proc/meminfo 
MemTotal:       129051172 kB 

To set up the DOCA and DPDK libraries in this instance, I installed the DOCA SDK repo meta package.

root@ip-172-31-28-243:~#  dpkg -i doca-repo-aarch64-ubuntu2004-local_1.1.1-1.5.4.2.4.1.3.bf.3.7.1.11866_arm64.deb 
root@ip-172-31-28-243:~#  apt update 
root@ip-172-31-28-243:~# apt install doca-sdk 

The remaining steps for cloning and building the FRR Debian package are the same as the previous option.  

Table 3 shows how the build fared on the AWS Arm instance.

DPU-Arm, X86 & AWS-Arm Build Times	Real	User	Sys
DPU Arm  (Complete make)	2min 40.529sec	16min 29.855sec	2min 1.534sec
DPU Arm  (Debian package)	5min 23.067sec	20min 33.614sec	2min 49.628sec
X86 + DOCA dev container  (Generate Debian package)	24min 19.051sec	139min 39.286sec	3min 58.081sec
AWS-Arm   (Generate Debian package)	1min 30.480sec	6min 6.056sec	0min 35.921sec

 This is a clear winner, no coffee needed.

Figure 1 shows the compile times in these environments.

Summary 

In this post, I discussed several development environments for DPU applications:

• Bluefield DPU 
• DOCA dev container on an x86 server
• AWS Graviton compute instance 

You can prototype your app directly on the DPU, experiment with developing in the x86 DOCA development container, and grab an AWS Graviton instance with DOCA to punch it into hyperspeed! 

For more information, see the following resources:

• NVIDIA Introduces BlueField DPU as a platform for Zero Trust Security with DOCA 1.2
• Building a Foundation for Zero Trust Security with NVIDIA DOCA 1.2
• Introduction to NVIDIA DOCA for BlueField DPUs DLI course
• DPU-Based Hardware Acceleration: A Software Perspective

submitted by /u/redska_
[visit reddit] [comments]

We present a new generation of neural operators, named U-FNO, that empowers a novel technology for solving multiphase flow problems with superior accuracy, speed, and data efficiency.

Climate change mitigation is about reducing greenhouse gas (GHG) emissions. The worldwide goal is to reach net zero, which means balancing the amount of GHG emissions produced and the amount removed from the atmosphere.

On the one hand, this implies reducing emissions by using low-carbon technologies and energy efficiency. On the other hand, it implies deploying negative emission technologies such as carbon storage, which is the subject of this post.

Carbon capture and storage (CCS) refers to a group of technologies that contribute to directly reducing emissions at their source in key power sectors such as coal and gas power plants and industrial plants. For emissions that cannot be reduced directly either because they are technically difficult or prohibitively expensive to eliminate, CCS underpins an important net-negative technological approach for removing carbon from the atmosphere.

If not being used on site, CO₂ can be compressed and transported by pipeline, ship, rail, or truck. It can be used in a range of applications or injected into deep geological formations (including depleted oil and gas reservoirs or saline formations) that trap the CO₂ for permanent storage. This unique dual ability of CCS makes it an essential solution among the energy transition technologies that mitigate climate change.

In addition to the role CCS plays in the energy transition, it is a solution for challenging emissions in heavy industries and addresses deep emissions reductions from hard-to-abate sectors like steel, fertilizer, and cement production. It can also support a cost-effective pathway for low-carbon blue hydrogen production. 

In numbers, CCS facilities currently in operation can capture and permanently store around 40 Mt of CO₂ every year. According to the International Energy Agency (IEA), to achieve a climate outcome consistent with the Paris Agreement, 1150 MtCO₂ must be stored before 2030. So, there is a factor of 30 to achieve in storage capacity by 2030 to reduce the emissions of power and industrial sectors.

Global macro-trends such as the rise of environment social governance (ESG) criteria are stimulating the implementation of the broadest portfolio of technologies, including CCS to achieve net-zero emissions at the lowest possible risk and cost. Investment incentives are therefore building unprecedented momentum behind CCS with plans for more than 100 new facilities already announced in 2021.

CO₂ injection problem

Carbon must be stored somewhere. It is most often stored underground in a process called geological sequestration. A geological formation is only selected as a storage site under certain conditions to make sure there’s no significant risk of leakage and no significant environmental or health risk.

This involves injecting carbon dioxide into underground rock formations. It is stored as a supercritical fluid, meaning that it has properties between those of a gas and a liquid.

When CO₂ is injected at depth into a reservoir, it remains in this supercritical condition as long as it stays in excess of 31.1° C and at a pressure in excess of 73.86 bar. This is true whether the reservoir is a saline formation or depleted oil and gas fields.

CO₂ must be sealed under a capillary barrier so that carbon remains stored for hundreds of years or even indefinitely in a safe way. Otherwise, if CO₂ leaks out in large quantities, it could potentially contaminate a nearby aquifer. If it leaks to ground surface, it can cause safety hazards to nearby humans or animals.

The overall performance of such storage can be predicted numerically by solving a multiphase flow problem. However, this requires solving highly nonlinear PDEs due to multiscale heterogeneities and complex thermodynamics.

The numerical simulation methodology to achieve this usually consists in several steps:

1. Collecting data and information about the subsurface geology and properties.
2. Building a geological model of the storage formation and its surroundings.
3. Building a dynamic model of the reservoir, which is used to simulate CO₂ injection and CO₂ evolution inside the reservoir. These dynamic simulations are used to evaluate and optimize key performance indicators related to reservoir conditions.

Traditional simulators can accurately simulate this complex problem but are expensive at sufficiently refined grid resolution. Machine learning models trained with numerical simulation data can provide a faster alternative to traditional simulators.

In this post, we highlight the results using the newly developed U-FNO machine learning model and show its superiority for CO₂-water multiphase flow problems required for understanding and scaling CCS applications.

Simulation setup

We consider modeling gas saturation and pressure over 30 years in deep saline formation at a constant rate ranging from 0.2 to 2 Mt/year. The x-axis and y-axis are the reservoir thickness and reservoir radius in meters, respectively.

The setup is a realistic reservoir located at least 800 m below ground surface (Figure 2). The setup enables reservoir simulation at various realistic depths, temperature, formation thickness, injection pattern, rock properties, and formation geology.

The numerical simulator Schlumberger ECLIPSE (e300) is used to develop the multiphase flow dataset for CO₂ geological storage. Super-critical CO₂ can be injected through a vertical injection, well with various perforation interval designs into a radially symmetrical system x (r, z).

A novel Fourier neural operator

In a recent paper published in Advances in Water Resources, four types of machine learning model architectures are studied:

• The Fourier neural operator (FNO) proposed in Fourier Neural Operator for Parametric Partial Differential Equations
• A newly proposed U-FNO
• A conv-FNO that uses conv3d instead of U-Net
• The state-of-the-art benchmark CNN used in U-FNO–An enhanced Fourier neural operator-based deep-learning model for multiphase flow

The goal of a neural operator is to learn an infinite-dimensional-space mapping from a finite collection of input-output observations. In contrast to the original Fourier layer in FNO, the U-FNO architecture proposed here appends a U-Net path in each U-Fourier layer. The U-Net processes local convolution to enrich the representation power of the U-FNO in higher frequencies information.

The newly proposed U-FNO model architecture uses both Fourier and U-Fourier layers (Figure 3).

In the Fourier and U-Fourier layers (a):

• is the input.
• and are fully connected neural networks.
• is the output.

Inside the Fourier layer (b):

• denotes the Fourier transform.
• is the parameterization in Fourier space.
• $latex F⁻¹$ is the inverse Fourier transform.
• is a linear bias term.
• is the activation function.

Inside the U-FNO layer (c):

• denotes a two-step U-Net.
• The other notations have identical meaning as in the Fourier layer.
• The number of Fourier and U-Fourier layers, and , are hyperparameters, optimized for the specific problem.

Comparisons with the original FNO architecture and a state-of-the-art CNN benchmark shows that the newly proposed U-FNO architecture provides the best performance for both gas saturation and pressure buildup predictions.

The results of CO₂ storage predictions using NVIDIA GPUs show the following:

• U-FNO predictions are accurate, with only 1.6% plume error on gas saturation and 0.68% relative error on pressure buildup.
• U-FNO has superior performance on both training and testing sets compared to CNNs and the original FNO.
• Gas saturation and pressure buildup prediction using U-FNO is 46% and 24% more accurate than state-of-the-art CNNs.
• U-FNO requires only 33% of the training data to achieve the equivalent accuracy as CNNs.
• Running a 30-year case on GPUs using U-FNO takes 0.01 s compared to 600 s using traditional finite-difference methods (FDM).
• U-FNO is 6 x 10⁴x faster than the “ground truth” conventional FDM solver; FNO is 10⁵ x faster.

The training and testing times are both evaluated on an NVIDIA A100-SXM GPU and compared to Schlumberger ECLIPSE simulations on an Intel Xeon Processor E5-2670 CPU.

For the CO₂-water multiphase flow application described here, the goal was to optimize for the accuracy of gas saturation and pressure fields, for which the U-FNO provides the highest performance. The trained U-FNO model can therefore serve as an alternative to traditional numerical simulators in probabilistic assessment, inversion, and CCS site selection.

Web application

The trained U-FNO models are hosted on an openly accessible web application, CCSNet: a deep learning modeling suite for CO2 storage. The web application provides real-time predictions and lowers the technical barriers for governments, companies, and researchers to obtain reliable simulation results for CO₂ storage projects.

Scaling FNO to 3D problem sizes using NVIDIA Tensor Core GPUs

Due to the high dimensionality of input data in CO₂ storage problems, machine learning application has been limited to two-dimensional or small to medium-scale three-dimensional sized problems.

To overcome this limitation, a recent study proposed a model-parallel version of FNOs based on domain-decomposition of both the input data and network weights. For more information, see Towards Large-Scale Learned Solvers for Parametric PDEs with Model-Parallel Fourier Neural Operators.

Performing domain decomposition methods with minimum communication amount for parallelization of multidimensional fast Fourier transforms (FFT)s has been extensively looked at in literature, for many applications.

It is well-known that you can efficiently compute a multidimensional FFT with a sequence of lower-dimensional FFTs. The main idea is to use an iterative repartition pattern. The full mathematical derivation of the required components of distributed FNOs and its implementation is provided in the previously mentioned paper.

The following figure shows this concept, showing the distributed FFT using pencil decompositions acting on an input initially distributed over a 2×2 partition. Repartition operators are used to ensure that each worker has the full data it needs for calculating the sequential FFT in each dimension.

The authors demonstrated that this implementation offers a different set of features when solving the 3D time-varying two-phase flow equations. In this case, the model-parallel FNO can predict time-varying PDE solutions of over 3.2 billion variables using up to 768 GPUs (128 nodes) on Summit.

Looking ahead towards next steps, we can train larger 3D models following the Grady approach based on domain-decomposition, and drastically increase our capability on data size. With this technique, it is possible for us to scale up FNO type models to solve 3D basin/reservoir CO₂ storage problems.

Summary

Simulations are required to optimize the CO₂ injection location and verify that CO₂ does not leak from the storage site. We have shown that U-FNO, an enhanced deep Fourier neural operator, is 2x more accurate, 3x more data efficient than state-of-the-art CNN, and four orders of magnitude faster than a numerical simulator.

Using NVIDIA GPUs, the trained U-FNO models generate gas saturation and pressure buildup predictions 6 × 10⁴x faster than a traditional numerical solver. Distributed operator learning and the ability to scale FNOs with domain decomposition to large problem sizes opens up new possibilities to scale our studies to realistically sized data.

To avoid the worst outcomes from climate change, Working Group III published the 2022 mitigation pathways in its contribution to the sixth assessment report (AR6) of the Intergovernmental Panel on Climate Change (IPCC).  Experts highlighted the need for and potential of carbon capture and storage (CCS) to limit global warming to 1.5° C or 2° C.

Admittedly, there are current limitations to this set of technologies, especially related to economic and sociocultural barriers. But its deployment to counterbalance hard-to-abate residual emissions is considered unavoidable if net zero CO₂ or greenhouse gas emissions are to be achieved. 

We believe that building powerful AI tools for climate action and resilience can curb emissions at scale. In this work, we deployed novel artificial intelligence techniques to accelerate the CO₂ flow in porous media, which play an important role for CCS applications and the path forward towards mitigating climate change.

The recent DOCA Hackathon in Europe revealed streamlined innovation in video processing, storage solutions, and switching protocols using the BlueField DPU and DOCA SDK.

The third in a series of global NVIDIA DOCA Hackathons took place on March 21, during NVIDIA 2022 GTC. Competing in the event were 10 teams from a variety of universities, enterprises, and technology partners from across Europe and the Middle East. As part of GTC, NVIDIA CEO, Jensen Huang, gave a powerful keynote highlighting efforts in AI to supercharge industries including DPU and switching.

The recent Hackathon in Europe focused on BlueField DPU innovations that leverage the DOCA software framework to streamline the development process. Participants continue to find new ways to utilize the DPU for offloading, accelerating, and isolating a broad range of services. With DOCA, NVIDIA brings together APIs, drivers, libraries, sample code, documentation, services, and prepackaged containers for developers to speed up application development and deployment. 

“The NVIDIA Hackathon series enables participants to take a giant leap forward in their DPU application development. With direct access to DOCA training, mentors, preconfigured setups, documentation, and access to a working environment. These Hackathons help to accelerate application development that would have otherwise taken months for many organizations and play a significant role in establishing a strong DOCA developer community,” said Dror Goldenberg, SVP of Software Architecture at NVIDIA. “We continue to be very impressed with the creativity and ingenuity of all of our hackathon contestants and this competition was no exception!”

First Place

Team Thales from Theresis
Utilization of DPU for Storage Security

The Team Thales solution successfully used the BlueField DPU to create cyberdefense for files transmitted over the network. They used a combination of networking and storage security rules that delivered an overall performance improvement. The goal was to build upon the DPI acceleration to enable Yara rules, which are used for inspection of files downloaded from the network to identify malware and potential threats. To implement this, Team Thales used a Yara Parser to transform public Yara rules into DPI rules in a Suricata community-based format supported by the DOCA DPI lib. This solution leveraged DOCA DPI functionality to scan the files on the fly as the packets flow through the device.  

Second Place

Team RARE/FreeRTR from GÉANT
Router for Academia Research and Education Hardware accelerated MPLS 

FreeRTR Router is a Swiss army knife meant to be used as a primary router but can also be used as a specific appliance. The team evaluated accelerated DPDK and DOCA FLOW and enabled the routing functionality with multiple routing protocols on the DPU leveraging the large and programmable flow tables. As part of their planned innovation, the team also evaluated added services by linking DOCA libraries to provide additional functionality including Firewall, RegEx scanning, MACsec encryption, and DPI engine at line rate. This allowed Team Rare to create one control plane to rule all dataplanes.

Third Place

Team DOCA Seville from the University of Seville
Video processing at the edge

Team DOCA Seville used the BlueField DPU to filter out voided frames of CCTV streams, reducing the load on a CPU/GPU and improving physical security by providing detection of firearms. The intention is to prevent mass shootings by detecting the weapon. Removing images with no people significantly improves the overall system performance. Team DOCA Seville leveraged the DPU to offload the image processing and used DOCA gRPC infrastructure to stream filtered data for further analysis. 

Congratulations to the winners and thanks to all of the teams that participated, making this round of NVIDIA DOCA Hackathon such a wonderful success!

NVIDIA is building a broad community of DOCA developers to create innovative applications and services on top of BlueField DPUs to secure and accelerate modern, efficient data centers. To learn more about joining the community, visit the DOCA developer web page or register to download DOCA today.

Up next is the NVIDIA DPU Hackathon in China. Check out our corporate calendar to stay informed of future events, and take part in our journey to reshape the data center of tomorrow. 

More resources

• Take the Introduction to NVIDIA DOCA for BlueField DPUs DLI course
• Developing Applications with NVIDIA BlueField DPU and NVIDIA DOCA Libraries
• Build a foundation for zero trust security with DOCA 1.2
• Start a discussion on forums
• Read about DPU-Based hardware acceleration
• Get access to cutting edge technology through NVIDIA Inception for startups

submitted by /u/stephanr21
[visit reddit] [comments]

GeForce NOW is about bringing new experiences to gamers. This GFN Thursday introduces game demos to GeForce NOW. Members can now try out some of the hit games streaming on the service before purchasing the full PC version — including some finalists from the 2021 Epic MegaJam. Plus, look for six games ready to stream Read article >

The post Try This Out: GFN Thursday Delivers Instant-Play Game Demos on GeForce NOW appeared first on NVIDIA Blog.

submitted by /u/hobopwnzor
[visit reddit] [comments]