intel/xess

xess's Issues

Running on Linux via Wine/Proton/vkd3d?

Currently, running XeSS-enabled games on Arc graphics on Linux via compatibility tools like Wine/Proton and VKD3D seems to require the Mesa/ANV Vulkan driver to report a fake vendor ID, so that XeSS does not detect Intel graphics. Otherwise, the game crashes.

I'm not sure why this is the case, I'm guessing it is either related to the XeSS dispatcher trying to find the driver (which is not installed in Wine since everything is running on the Linux drivers) for a new version, or the XMX code perhaps getting lost in translation.

I think it would be nice if this could be investigated and fixed, so that the Mesa driver does not need to implement any further workarounds to get XeSS-enabled games working, and to ensure that gamers on Linux also get the full benefit of the advanced XMX model for the best image quality and performance.

See for example:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23271
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25965

I don't work on any of these drivers myself, but making sure XeSS is properly supported on Wine seems like a good step to me.

Detail information for igxess.dll, libxess.dll, WinPixEventRuntime.dll, XeFX.dll, XeFX_Load.dll

Any introduction for igxess.dll, libxess.dll, WinPixEventRuntime.dll, XeFX.dll, XeFX_Load.dll? If we want to know what's feature, architecture and work flow...

Open Source XeSS

Edit: I get it now XeSS wasn't meant to be open sourced right?

Integration into Nvidia Streamline SDK?

Hi,
any progress so far?
last year (https://www.tomshardware.com/news/nvidia-streamline-aims-to-simplify-developer-support-for-upscaling-algorithms), some sites cited support from other IHVs like Intel..
Intel showed at the time interest on integrating XeSS support into StreamLine..
Asked also on Nv streamline github site: NVIDIAGameWorks/Streamline#12
Maybe there is a branch somewhere on github by Intel devs with XeSS StreamLine support?
Thanks..

Output color range problem

Hello,

I think there is a problem on output color calculations when color texture has wide (like 0.0f-64000.0f) range . Input color texture have correct details but output texture comes out crushed and with missing details.

For example this is input color texture:

This is the output texture from xess:

Input color texture have a color value range of 0-64000 but output texture only have 0-380 (and this 380 is like a limit on XeSS?)

I am attaching dump of this frame too.
XessDump.zip

One final thing, dump is taken with AutoExposure but i am getting same results with using ExposureTexture too.

xessD3D12BuildPipelines() returns XESS_RESULT_ERROR_NOT_IMPLEMENTED on Arc A380

I believe Kaplanyan has already addressed this on Twitter, but it's probably worth repeating it here to be notified when the problem is solved and for other developers who might run into the issue and search about it.

The following call returned the correct result in my system with an NVIDIA GeForce RTX 3090, but a user with an A380 reported that XESS_RESULT_ERROR_NOT_IMPLEMENTED was returned instead as indicated on my process' log. It's worth mentioning that XeSS ran correctly for this user upon deleting the xessD3D12BuildPipelines call and letting xessD3D12Init do the work instead, at the expense of a longer startup time. Their drivers were also confirmed to be up to date and the XeSS demos ran as intended.

xessD3D12BuildPipelines(xessContext, nullptr, false, 
  XESS_INIT_FLAG_RESPONSIVE_PIXEL_MASK | XESS_INIT_FLAG_LDR_INPUT_COLOR);

I ran into this because the manual itself mentions the possibility of using the pipeline caching:

But upon reading the included samples, XeSSRuntime::InitializePipeline is the only function to call xessD3D12BuildPipelines, but it's unused because InitializePipeline is never called by the demo application. BasicSample does not currently make use of the function either. Judging by its omission from the code in both samples, I figure the team is already aware of the problem.

Thanks for opening up the issue tracker!

libxess.dll spends more than 24MB of its binary initializing stack objects

There are three functions inside of libxess.dll which are more than 8MB apiece initializing stack objects using single byte move instructions.

This consumes more than 24MB in the library, which with v1.3.0's binary being 71MB, that's 33.8% of the binary size. As far as I can tell, these also cause initialization time of the library to take multiple seconds once these get executed as well.

From libxess.dll v1.3.0 these functions live at offsets 0x2b3c0, 0x29c550, and 0x50dfc0. Since we don't have function symbol names for these, it's unknown what these functions are called. Looks like they are generating some dll file on stacks or something though.

Ideally these binaries could just live in an array structure in the dll and they get memcpy'd in to the stack (or whatever it is doing). This has the potential to shave off the majority of this 24MB of code and improving initialization time.

Video attached scrolling through the binary a small portion. The code layout on the right having three large contiguous blocks of blue, showcasing each individual block of ~8MB of code.

Oopsies-2024-04-04_18.07.18.mp4

Network Models

Hello,

I checked a lot of places but can't find and info about explanation of network models and their purposes in XeSS? At least could you briefly explain models and purposes?

XESS_NETWORK_MODEL_KPSS
XESS_NETWORK_MODEL_SPLAT
XESS_NETWORK_MODEL_3
XESS_NETWORK_MODEL_4
XESS_NETWORK_MODEL_5
XESS_NETWORK_MODEL_6

Test

Frame Generation

When there is going to be a frame generation feature if it's ever going to be?

[Feature Request] XESS driver for linux

XESS is not supported in linux, because not exist a driver.
Is obvious that intel not have interesting in bring XESS API for Mesa3D and have no plans
for a new Open Source Gaming ML based upscaling API standard from community.

Solution:
Bring a XESS proprietary driver for linux if are possible, and is not necessary a Vulkan Support, is just necessary
a bridge between Wine and System libs in the same way the DLSS works in linux using the DXVK-NVAPI +
Proprietary implementation, this can be possible without open the source code of XESS.
A Vulkan support can be good

Documentation Issue

Hello,

In documentation there is only one parameter for heap and it's pTempStorageHeap but actually we have two seperate parameters, pTempBufferHeap and pTempTextureHeap but current documentation still using old(?) parameter and structure.

Also adding xessGetProperties to example code for getting heap sizes and necessary heap descriptions would be really helpful.
I found this info in samples.

Linux support planned?

Hi,
Hope it is..
Would be nice as both nv dlss and amd fsr support Linux..
This of course is dependent on first supporting Vulkan API.. #6
Thanks..

Vulkan Support

Can you provice us support for native Vulkan games?

Intel Lied. And Now it's Harming Linux Users.

Intel, On their Intel Arc GPU Announcement live stream, briefly mentioned how Xe Super Sampling™ is going to be a "Open Platform".

We also got official confirmation in Intel's own announcement article which is sadly lost to time mentioning:

• "Intel® Xe Super Sampling (XeSS) is open source. It is implemented using open standards to ensure wide availability on many games and across a broad set of shipping hardware, from both Intel® and other GPU vendors" - Alternate source

Unfortunately, it seems like this was all fabricated inside a phony GitHub repository and Intel has yet to comment on how uploading binary blobs to a GitHub repository is not considered "Open Source Software".

Not only that, Anton Kaplanyan, Intel's VP of Graphics Research, In a now deleted tweet mentioned how XeSS will be "cross platform". Other Sources. We've yet to see any "cross platform" implementations other than Windows.

Unfortunately, as a result of this, pull requests like this are being made to at least get XeSS working on an un-accelerated state on Linux.

Call of duty season 2, Intel GPUs and complete letdown

While I could play Call of Duty, Modern Warfare 3 (MW3), after season 2 it crashes right after launch with the culprit being in libxess.dll (version 1.2 being used here):

I tried to manually replace version 1.2 with 1.1 but COD them finding out the files are not right.

The issue started with season 1 reloaded where it would give this warning before launching (but it would carry on to the game OK):

Well and I did go the website - my graphics are (MacBook Pro using BootCamp)

With this processor: Processor Intel(R) Core(TM) i7-8559U CPU @ 2.70GHz, 2601 Mhz, 4 Core(s), 8 Logical Processor(s)

But Intel website tells me I have the most up-to-date driver which is only 2127:

And whenever I try to install 4955 or 5252 (downloading the drivers myself and running them), it gives me this error:

So after spending £70, and while I could play season 1, I can no longer play season 2 since Intel drivers refuse to upgrade to the latest version. Having played 1 season, I am in a situation where I can no longer play.

So can you please either explain or direct me to where I can ask for newer versions to be extended to Iris graphics?

XeSS 1.1?

Seems talked at gdc..

What's different with ESRGAN for upscaling and anti-analiasing?

What's different with ESRGAN for upscaling and anti-analiasing?