Intel Linux Graphics Driver Preparing NN Integer Mode Scaling

[DavidC1]

Their current GPU design is based on architecture that is about a decade old and it was never intended for long-term use or gaming, as it was designed for media consumption and Internet use. It will (apparently) be discarded with the soon to be released GPU that was developed with the engineers that Intel poached from AMD and Nvidia in the past six years, which is more in line with current GPUs from those respective companies.

What? It's not a decade old. Gen 9 introduced with Skylake in late 2015.

Xe doesn't "discard" it either. It'll be much more efficient and faster but fundamentals will stay. Xe is also known as Gen 12. The engineers Intel poached will certainly help, but will show in low-levels details most people can't understand. High-level is essentially the same. Tigerlake, is revealed to have 96 EUs.

[Venemo]

Why is it late for this to get into 5.4? Even 5.3 isn't released yet.

[Michael]

Why is it late for this to get into 5.4? Even 5.3 isn't released yet.

The soft feature cut-off for getting new code into DRM-Next for 5.4 was last week.

[Venemo]

The soft feature cut-off for getting new code into DRM-Next for 5.4 was last week.

Why does it make sense to cut-off the deadline for 5.4 while 5.3 is not even out yet?

[Michael]

Why does it make sense to cut-off the deadline for 5.4 while 5.3 is not even out yet?

Linus Torvalds got tired of new DRM feature code being merged at (or just around) the days before the N+1 kernel feature merge window due to bugs/fallout. So this soft deadline for DRM (and generally most other subsystems not merging new code right before a new merge window) has been in place for a while, it's nothing new, it allows for better testing to ensure at least semi-decent quality code entering at the merge window.

[Venemo]

Linus Torvalds got tired of new DRM feature code being merged at (or just around) the days before the N+1 kernel feature merge window due to bugs/fallout. So this soft deadline for DRM (and generally most other subsystems not merging new code right before a new merge window) has been in place for a while, it's nothing new, it allows for better testing to ensure at least semi-decent quality code entering at the merge window.

Ahhh, okay.
Sadly it also means that we have to wait several months for stuff like this.

[bearoso]

No, not emulators. I'm talking about hardware scaling.

Older consoles didn't work this way. The CRT controllers worked like this: The TV will scan the electron gun back and forth almost horizontally, lighting up the 3 colors of phosphors on the display producing a fixed number of lines. This gets you an almost arbitrary vertical resolution. However, some CRTs had the various colors laid out in a triangle, rather than vertical stripes, so you can't get solidly defined pixels, which would make this aspect kind of hazy. Horizontally, the gun could be instructed to change power of each of the 3 color components, which theoretically creates an infinite horizontal resolution. However, on any CRT the number of columns or dot triads is limited so this isn't exact either. Keep in mind this is an analog signal controlled by a chip with limited clock speed, and the CRTC in these old consoles can't just instantly change the signal, it changes slowly, producing a gradient. So you get a bit more blur.

So you've got the expensive aperture grille TVs that CAN product pixel perfect vertical resolution, but not the horizontal. Normal shadow mask TVs are blurred in both dimensions. The phosphor's radiant glow might have helped trick the eyes into thinking it was sharper than it was, but it wasn't the pixel perfect experience people think it was.

[tildearrow]

Older consoles didn't work this way. The CRT controllers worked like this: The TV will scan the electron gun back and forth almost horizontally, lighting up the 3 colors of phosphors on the display producing a fixed number of lines. This gets you an almost arbitrary vertical resolution. However, some CRTs had the various colors laid out in a triangle, rather than vertical stripes, so you can't get solidly defined pixels, which would make this aspect kind of hazy. Horizontally, the gun could be instructed to change power of each of the 3 color components, which theoretically creates an infinite horizontal resolution. However, on any CRT the number of columns or dot triads is limited so this isn't exact either. Keep in mind this is an analog signal controlled by a chip with limited clock speed, and the CRTC in these old consoles can't just instantly change the signal, it changes slowly, producing a gradient. So you get a bit more blur.

So you've got the expensive aperture grille TVs that CAN product pixel perfect vertical resolution, but not the horizontal. Normal shadow mask TVs are blurred in both dimensions. The phosphor's radiant glow might have helped trick the eyes into thinking it was sharper than it was, but it wasn't the pixel perfect experience people think it was.

Yes, I know, but what I meant is that the SNES is capable of scaling the background and sprites arbitrarily using nearest-neighbor (see Mode 7).

[bridgman]

Why does it make sense to cut-off the deadline for 5.4 while 5.3 is not even out yet?

It gives a couple of weeks to test the collected drm changes so that when 5.4 is opened up the code is generally solid. Once the merge window opens drm is just one of many subsystems all coming together at the same time, and if they aren't all reasonably well tested you get chaos.

I don't remember when Dave put the "rc5" rule in but my recollection is that it was quite a few years ago. The only recent change IIRC was enforcing it more tightly after some last minute (post-rc5) changes caused breakage in the merge window.

[timofonic]

It gives a couple of weeks to test the collected drm changes so that when 5.4 is opened up the code is generally solid. Once the merge window opens drm is just one of many subsystems all coming together at the same time, and if they aren't all reasonably well tested you get chaos.

I don't remember when Dave put the "rc5" rule in but my recollection is that it was quite a few years ago. The only recent change IIRC was enforcing it more tightly after some last minute (post-rc5) changes caused breakage in the merge window.

Any plans to add advanced hardware scaling to AMD hardware? I want it for retro system emulators and ScummVM.