There's a lot of attention at the moment focused toward Linux and the
future of gaming support on the platform. And it got me thinking, is
there any particular improvements that are planned to improve the kernel
from better support for gaming?
Regards
--
Chris Jones @ [email protected]
also on [email protected] and [email protected]
Ubuntu 12.04 (PC)|Android (Smartphone)|Windows 7 (Laptop)|Windows XP (Gaming)
Linux kernel developer|Solaris kernel developer|BSD kernel developer|Lead Developer of SDL|Lead Developer of Nest Linux|Gamer and Emulator nut|Web Services|Digital Imaging Services
Controllers: Rapier V2 Gaming mouse|Logitech Precision|PS3 controller|XB360 controller|Logitech Attack 3 j/stick
Emulators: Fusion|Gens|ZSNES|Project64|PCSX-R|Stella|WinVICE|WinUAE|DOSBox
Sorry, had to send this again so it could go to the mailing list. I
accidentally replied to you personally :\
On 04/08/12 08:12, Chris Jones wrote:
> There's a lot of attention at the moment focused toward Linux and the
> future of gaming support on the platform. And it got me thinking, is
> there any particular improvements that are planned to improve the
> kernel from better support for gaming?
>
>
> Regards
>
Hi Chris,
The biggest problem I can see at the moment is supporting dual-GPU
setups in unusual ways.
For example, NVIDIA Optimus uses an Intel Core i* processor and
integrated Intel 3/4000 graphics,
but also has a NVIDIA GeForge GT *M graphics card. However, this card
cannot be accessed
directly, and all instructions effectively pass through the Intel
graphics system.
I'm not entirely sure how that works, but it's what I've managed to
gather from some tinkering.
It's being worked on at the moment (RandR 1.(5? 6? 7?) and DMA-BUF
PRIME) - Which is good,
since the majority of laptops that I have seen being sold in my area
either use NVIDIA
Optimus or some other similar system if they cost under $1000 or so.
Until these are implemented, there is no way for the kernel to access
the dedicated graphics
card on these systems. There is, however, a project (Bumblebee) that
seems to be doing
a good job performance-wise, but doesn't support automatic switching to
the dedicated
graphics card.
On another note, not kernel based, Wine has actually managed to run
Grand Theft Auto: San Andreas faster on Ubuntu 12.04 than the default
Windows 7
installation on this laptop. Valve has also committed to developing
games on Linux
(starting with Ubuntu) with frame rates that, so far, have been higher
than on Windows.
I guess we'll just have to wait and see what happens. There are a couple
of things (some
of which are major, but thankfully not impossible)
On 04/08/12 08:44, Cruz Julian Bishop wrote:
> On 04/08/12 08:12, Chris Jones wrote:
>> There's a lot of attention at the moment focused toward Linux and the
>> future of gaming support on the platform. And it got me thinking, is
>> there any particular improvements that are planned to improve the
>> kernel from better support for gaming?
>>
>>
>> Regards
>>
> Hi Chris,
>
> The biggest problem I can see at the moment is supporting dual-GPU
> setups in unusual ways.
>
> For example, NVIDIA Optimus uses an Intel Core i* processor and
> integrated Intel 3/4000 graphics,
> but also has a NVIDIA GeForge GT *M graphics card. However, this card
> cannot be accessed
> directly, and all instructions effectively pass through the Intel
> graphics system.
>
> I'm not entirely sure how that works, but it's what I've managed to
> gather from some tinkering.
> It's being worked on at the moment (RandR 1.(5? 6? 7?) and DMA-BUF
> PRIME) - Which is good,
> since the majority of laptops that I have seen being sold in my area
> either use NVIDIA
> Optimus or some other similar system if they cost under $1000 or so.
>
> Until these are implemented, there is no way for the kernel to access
> the dedicated graphics
> card on these systems. There is, however, a project (Bumblebee) that
> seems to be doing
> a good job performance-wise, but doesn't support automatic switching
> to the dedicated
> graphics card.
>
>
>
> On another note, not kernel based, Wine has actually managed to run
> Grand Theft Auto: San Andreas faster on Ubuntu 12.04 than the default
> Windows 7
> installation on this laptop. Valve has also committed to developing
> games on Linux
> (starting with Ubuntu) with frame rates that, so far, have been higher
> than on Windows.
>
> I guess we'll just have to wait and see what happens. There are a
> couple of things (some
> of which are major, but thankfully not impossible)
It just seems to me that Valve is pressing ahead with games for Linux
and no doubt there will be another influx of games and companies to
follow not far behind if Valve make it a running success. And good luck
to them. But on the other hand, it seems that kernel development is not
quite up to scratch yet when it comes to full support for hardware
graphics. And bring drivers in to the mix. Albeit, I do understand that
graphics drivers should be handled and worked on by AMD and NVIDIA etc.
It's hard to describe what I mean. Basically, to the outside world via
media, it is presented as "Valve is taking gaming to Linux. Wow, Linux
is now capable of gaming!" That's all fine and everything. But we need
to ensure that the kernel and all other aspects of code under our
control is up to the task of handling a massive dump of games for Linux.
Otherwise, it's going to backfire on us and Linux overall. It's moving
very quickly.
Regards
--
Chris Jones @ [email protected]
also on [email protected] and [email protected]
Ubuntu 12.04 (PC)|Android (Smartphone)|Windows 7 (Laptop)|Windows XP (Gaming)
Linux kernel developer|Solaris kernel developer|BSD kernel developer|Lead Developer of SDL|Lead Developer of Nest Linux|Gamer and Emulator nut|Web Services|Digital Imaging Services
Controllers: Rapier V2 Gaming mouse|Logitech Precision|PS3 controller|XB360 controller|Logitech Attack 3 j/stick
Emulators: Fusion|Gens|ZSNES|Project64|PCSX-R|Stella|WinVICE|WinUAE|DOSBox
On Sat, 4 Aug 2012, Chris Jones wrote:
> On 04/08/12 08:44, Cruz Julian Bishop wrote:
>> On 04/08/12 08:12, Chris Jones wrote:
>>> There's a lot of attention at the moment focused toward Linux and the
>>> future of gaming support on the platform. And it got me thinking, is there
>>> any particular improvements that are planned to improve the kernel from
>>> better support for gaming?
>
> It's hard to describe what I mean. Basically, to the outside world via media,
> it is presented as "Valve is taking gaming to Linux. Wow, Linux is now
> capable of gaming!" That's all fine and everything. But we need to ensure
> that the kernel and all other aspects of code under our control is up to the
> task of handling a massive dump of games for Linux. Otherwise, it's going to
> backfire on us and Linux overall. It's moving very quickly.
Other than drivers, what problems do you think that the Linux kernel has
in supporting games?
Drivers are bad due to the video card vendors opting to not provide the
information needed for them to be good, so while I wish they were better,
I don't really see anything for the "Linux kernel community" to do.
David Lang
On 04/08/12 10:32, [email protected] wrote:
> On Sat, 4 Aug 2012, Chris Jones wrote:
>
>> On 04/08/12 08:44, Cruz Julian Bishop wrote:
>>> On 04/08/12 08:12, Chris Jones wrote:
>>>> There's a lot of attention at the moment focused toward Linux and
>>>> the future of gaming support on the platform. And it got me
>>>> thinking, is there any particular improvements that are planned to
>>>> improve the kernel from better support for gaming?
>>
>> It's hard to describe what I mean. Basically, to the outside world
>> via media, it is presented as "Valve is taking gaming to Linux. Wow,
>> Linux is now capable of gaming!" That's all fine and everything. But
>> we need to ensure that the kernel and all other aspects of code under
>> our control is up to the task of handling a massive dump of games for
>> Linux. Otherwise, it's going to backfire on us and Linux overall.
>> It's moving very quickly.
>
> Other than drivers, what problems do you think that the Linux kernel
> has in supporting games?
>
> Drivers are bad due to the video card vendors opting to not provide
> the information needed for them to be good, so while I wish they were
> better, I don't really see anything for the "Linux kernel community"
> to do.
>
> David Lang
Well you are right I guess. There really is nothing technically wrong
with the kernel in its current state. And there probably isn't really an
essential to-do list, so to speak. But I guess I know that we know this
because we're all developers. However, if new gamers move to Linux and
find they're experience is not the same as their experience was when
gaming under Windows, then the eventual blame-game will fall back on us.
The kernel developers. Even though the responsibility lies with video
card and hardware developers.
I guess I am just a little concerned that it might not be a smooth and
happy introduction as Valve is making out. However, if Valve handle this
correctly and provide the gamer community with enough information and
documentation, hopefully things will work out. And this might actually
be the kick in the rear-end that AMD and NVIDIA need to get into gear
and start developer some useful and Windows equivalent hardware drivers
for ALL their cards for Linux.
Regards
--
Chris Jones @ [email protected]
also on [email protected] and [email protected]
Ubuntu 12.04 (PC)|Android (Smartphone)|Windows 7 (Laptop)|Windows XP (Gaming)
Linux kernel developer|Solaris kernel developer|BSD kernel developer|Lead Developer of SDL|Lead Developer of Nest Linux|Gamer and Emulator nut|Web Services|Digital Imaging Services
Controllers: Rapier V2 Gaming mouse|Logitech Precision|PS3 controller|XB360 controller|Logitech Attack 3 j/stick
Emulators: Fusion|Gens|ZSNES|Project64|PCSX-R|Stella|WinVICE|WinUAE|DOSBox
On Sat, 04 Aug 2012 10:51:49 +1000, Chris Jones said:
> documentation, hopefully things will work out. And this might actually
> be the kick in the rear-end that AMD and NVIDIA need to get into gear
> and start developer some useful and Windows equivalent hardware drivers
> for ALL their cards for Linux.
The truly ironic part is that the current NVidia binary blob driver that
everybody dislikes so much *IS* the "Windows equivalent" driver (in
fact, it's the same driver, with a Linux shim layer wrapped around it).
You can flame them for having a non-GPL binary blob, but you can't flame
NVidia for not having equivalent drivers...
On Sat, 2012-08-04 at 00:12 -0400, [email protected] wrote:
> On Sat, 04 Aug 2012 10:51:49 +1000, Chris Jones said:
>
> > documentation, hopefully things will work out. And this might actually
> > be the kick in the rear-end that AMD and NVIDIA need to get into gear
> > and start developer some useful and Windows equivalent hardware drivers
> > for ALL their cards for Linux.
>
> The truly ironic part is that the current NVidia binary blob driver that
> everybody dislikes so much *IS* the "Windows equivalent" driver (in
> fact, it's the same driver, with a Linux shim layer wrapped around it).
Hm.. so windows can be kept in kernel for a full second of IPI blasting
all cores too. That driver seems to work very nicely once things are
running, but whatever the heck it does when you first fire up rendering
is.. something to keep far far away from realtime tasks :)
-Mike
On Sat, 2012-08-04 at 06:49 +0200, Mike Galbraith wrote:
> On Sat, 2012-08-04 at 00:12 -0400, [email protected] wrote:
> > On Sat, 04 Aug 2012 10:51:49 +1000, Chris Jones said:
> >
> > > documentation, hopefully things will work out. And this might actually
> > > be the kick in the rear-end that AMD and NVIDIA need to get into gear
> > > and start developer some useful and Windows equivalent hardware drivers
> > > for ALL their cards for Linux.
> >
> > The truly ironic part is that the current NVidia binary blob driver that
> > everybody dislikes so much *IS* the "Windows equivalent" driver (in
> > fact, it's the same driver, with a Linux shim layer wrapped around it).
>
> Hm.. so windows can be kept in kernel for a full second of IPI blasting
> all cores too. That driver seems to work very nicely once things are
> running, but whatever the heck it does when you first fire up rendering
> is.. something to keep far far away from realtime tasks :)
That seems to have gotten about a ton better. Worst just measured with
295.53 under 3.0-rt58 was 7.7ms, with typical being < 1ms.
-Mike