Quoting: mylkayou cant buy non TI
why the F do they make a TI then?

For 3070, good question.
For 3080 TI, according to LTT, it seems the supply of rtx 3090s is currently bound by the DDR6X supply, so instead of having 24GB, you get 12GB on a GPU which is essentially the same otherwise. It then allows you to do twice as many with as many dies. The 2% shave off is probably to support using GPU with low defect rate too.
The 3080ti is a 3090 with less ram, not a boosted 3080.

View this comment - View article - View full comments

Quoting: kfpenguinWell, I wish NVidia would fix their drivers and do better QA. Their new drivers crashes on boot if your montior is connected with DP and/or resoution greater than 1080p.

https://forums.developer.nvidia.com/t/465-24-02-page-fault/175782 [External Link]

To be fair, it seems confined to some models, which might explain why they missed it. No issue here with 2k freesync MSI monitor, and seems many of us have no issue. Likely some specific incompatibilities.
But overall, I wish vendors would do more QA yes ... Cheaping out on QA will only cause issues for yourself down the road.

View this comment - View article - View full comments

Quoting: x_wing

Quoting: 3zekielSo yeah, AMD's behavior does bother me. Actually, compared to what I hear from many persons, AMD support is in many way not that great. You often have to wait for months before new GPUs are supported (as in booting)...

Sorry, but that's BS. All AMD release in the last 3 or 4 years had a proprietary driver release on Linux the same day they hardware was released. And if your point is that kernel and Mesa version releases doesn't sync with the hardware release, I can tell you that this issue is not isolated to AMD.

I indeed ignored the closed source driver, as it seems to have its support limited to a few distro. And it is not the target for games and so on.
Also, there is still no full support in the "normal" driver for quite a few features, see Joshua Ashton's closing words in his blog about RTX and about supporting a driver no one cares about. I did rephrase it, but this is not me saying it in the first place. Joshua Ashton [External Link]

AMDVLK and AMDGPU-Pro are pretty much worthless as targets for developers. Waiting between 3-months and half a year for a release with new fixes/features is a complete joke for anyone wanting to ship a game or really anything.

As for the Mesa/Kernel issue not being only for AMD, it might be, but the only competitor in x86 space making use of open source driver for their (i)GPUs actually has a much better track record (except for one obscure dGPU that no one really cares about and was more of a warm up). So I don't really get your point. Supporting your products so as to release code and merge it sufficiently ahead of release is quite possible, and again, AMD has the manpower/money/ressources/smart enough people to do just that. It is just not their priority / not worth enough for them. So is life.

View this comment - View article - View full comments

Quoting: mphuZ

Quoting: CatKillerNvidia had day 1 Linux support, albeit in their beta driver.

Quoting: CatKillerIntel managed to get Linux support for Vulkan ray tracing before AMD, and they don't even have any ray tracing hardware.

What is the point of this, if there were no and almost no games with RT on Linux?
What's the point of chasing a niche (at the moment) technology?

Well, the issue is this kind of behavior will discourage devs from porting RT games to Linux. If you don't have RT support on Linux for your game, then how do you port it ?
And even ignoring native games, this could also reduce the drive of proton/steam play since it artificially disables feature parity with the OS whose name we do not speak.
And overall, this reinforce the impression of potential newcomers that Linux support is sub par.

Comparatively, Nvidia did try to push Nvapi/DLSS sooner in fact with previous code drops, and seeing that it was not enough, instead of just saying "oh well, who cares" they pushed an implementation by themselves.

So yeah, AMD's behavior does bother me. Actually, compared to what I hear from many persons, AMD support is in many way not that great. You often have to wait for months before new GPUs are supported (as in booting), and even more before they are properly supported (All features enabled). Also, most of the effort is actually not done by them but by valve paid people. Yes, their driver is open source, and yes they might not disable features like VFIO for fun like Nvidia used to do - which they did correct, as well as finally marching to wayland albeit quite late -, but if you can't fully use your GPU (or even not at all if you buy at the beginning) then it only has moderate worth.
And they are perfectly able to do it, they also completely have the means, now that they make shitloads of money from Ryzen and sell all their GPU like hot cakes thanks to the massive shortage.

View this comment - View article - View full comments

Quoting: slapinWill DLSS work fine for native games/applications?

DLSS 2.0 is already supported in the driver, but the Linux is SDK has not been properly released it seems ... But will all open sourcing work on NVAPI and co, I guess this will come soon.

Very good news since first images of Fidelity FX look fairly blury ... Seems it is just a slightly softened upscaling and nothing more in the end. Plus, considering AMD did not deem necessary to proprely support VK ray tracing on Linux, no reason to think any kind of linux support will come for Fidelity FX anytime soon either.

Wayland support is coming too, which seems like a very good news. That, plus the noise of a big open source driver coming ... who knows, we may yet see the light.
Nvidia also properly enabled virtual gpu support on linux for those who have passtru, seems they are really coming along on properly supporting us. If the Valve handheld uses Nvidia in the end, it would be very fun in fact.

View this comment - View article - View full comments

Finally, this one is perfect.
Thanks Tuxedo, I know where next month's salary is going now.

Quoting: iiari

Quoting: AppelsinNow we're talking! ...Have anyone tried these (or other laptops from Tuxedo) and can comment on how the keyboard and touchpad are to use?

I was going to ask the same thing regarding the touchpad. The other item of slight concern for me is the non-replaceable/swappable 53 Wh battery, which I think is the bare minimum I would accept and I'd be a bit concerned about achieving all-day work battery life with that.

For me, it might be this vs the Framework laptop (3:2 screen, replaceable 55 Wh battery). Nice to have choices.

It's true the framework is enticing, but it seems US only for now.

View this comment - View article - View full comments

Hi Hi,
Would love to have a free copy of the game :)

View this comment - View article - View full comments

Quoting: Mohandevir

Quoting: DorritGood news.
And, personally, I couldn't care less about ray tracing.

I'm probably some weird exception, but I still don't see what RTX brings to the table... I look at screenshots of games RTX on/off and it doesn't impress me that much... "More realistic lighting systems"... Ok, I understand the point... So? You could pass me an RTX off image for an RTX ON one and I wouldn't second guess it; the games are looking fabulous even with RTX off. Will I pay a premium for RTX? Will I pay a premium to see my fps drop from 80fps to 40fps because of RTX? Nope!

I probably have modest requirements. :grin:

In games that truly use it you can see fairly dramatic differences. On games which only use it as a gimmick on the other hand....
Also, using a full path traced pipeline instead of raster can dramatically simplify the life for the programmer, which in turn will tend to mean higher quality games for you.

View this comment - View article - View full comments

Quoting: rustybroomhandleHmmm, with or without ray tracing support?

Yes, that is the number one question. Does it come with ray tracing and DLSS ?
Otherwise, I almost gave up waiting, resisted buying it until now. Finally, here it comes !

View this comment - View article - View full comments

Quoting: wvstolzing

Quoting: 3zekielA secondary issue is that it is the supreme bloat since you really pack a whole lot of things in your app, and its corrolary: you can't update any part yourself - is it monolithic -, whereas for flatpak, you could force a newer runtime for the basics at least, or overload an installed flatpak with new features/libs if you want.

As you say, it is not a complete blocker either, and it does have some cases where it can be useful for distribution by stores like gog as an example. RPCS3 which does have a flatpak is not the best example though :)

I might be misunderstanding your point here, but AppImage currently does allow incremental updates: https://docs.appimage.org/packaging-guide/optional/updates.html [External Link]

I've been using the zsync method to update the neovim nightly appimage from github; it works just fine — that is the developer (without going through any intermediary) incrementally updates the nightly image on github every day, and the delta is all I have to download.

So for the first point, I was talking about what you can do without the developer, which is override the runtime, or add elements yourself (in flatpak you do that by declaring your own flatpak as prev_flatpak.my_extension). Incremental update is a delta on bin image I guess as implem. Having the update source directly in Appimage is good though.
Also, in term of bloat, two Appimage do not share anything, whereas two flatpaks most likely share their runtime, and probably some "base apps", meaning it will lead to less disk usage overhead.

Second, when I talk about downloading off the internet, I mean as a general habit. The fact that it comes straight from the dev is not necessarily good. And not just for AppImage, the perfect example is: https://www.omgubuntu.co.uk/2018/05/ubuntu-snap-malware [External Link] where the snap this time came from the dev, but was not carefully checked by intermediary and contained some malware ... If the app had been packaged and tested by a packager, and not just blob submitted and checked only for stuff like sandbox violation, this could have been avoided. But with AppImage, no one even checks whether the program does strange stuff, hence my remark about it being the same as good old .exe days. You can have dishonest devs that get away more easily, or you can have dubious sources for those who are less careful, or if you end up on a repo that looks like that of the original dev as an example. It is much easier to impersonate (imperfectly) a single dev than to take over your distro's repository, or Flathub.

Now, I can see some cases where Appimage has its place, but I don't think it can be THE inter distro platform.

View this comment - View article - View full comments