<?xml version='1.0' encoding='utf-8' ?>
<!--  If you are running a bot please visit this policy page outlining rules you must respect. http://www.livejournal.com/bots/  -->
<rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/' xmlns:media='http://search.yahoo.com/mrss/' xmlns:atom10='http://www.w3.org/2005/Atom'>
<channel>
  <title>skeggsb</title>
  <link>http://skeggsb.livejournal.com/</link>
  <description>skeggsb - LiveJournal.com</description>
  <lastBuildDate>Sat, 10 Oct 2009 06:46:06 GMT</lastBuildDate>
  <generator>LiveJournal / LiveJournal.com</generator>
  <lj:journal>skeggsb</lj:journal>
  <lj:journalid>17556232</lj:journalid>
  <lj:journaltype>personal</lj:journaltype>
  <atom10:link rel='hub' href='http://pubsubhubbub.appspot.com/' />
<item>
  <guid isPermaLink='true'>http://skeggsb.livejournal.com/568.html</guid>
  <pubDate>Sat, 10 Oct 2009 06:46:06 GMT</pubDate>
  <title>Debunking bad reporting: What&apos;s changed in Nouveau since F11..</title>
  <link>http://skeggsb.livejournal.com/568.html</link>
  <description>Recently, Phoronix posted an article (&lt;a href=&quot;http://www.phoronix.com/scan.php?page=news_item&amp;amp;px=NzU5NA&quot; rel=&quot;nofollow&quot;&gt;http://www.phoronix.com/scan.php?page=news_item&amp;amp;px=NzU5NA&lt;/a&gt;) claiming that the development of both the RadeonHD and Nouveau drivers is essentially dead-in-the-water.&amp;nbsp; I can&apos;t speak for RadeonHD at all as I don&apos;t follow it, but their claims about Nouveau are, quite bluntly, wrong.&lt;br /&gt;&lt;br /&gt;So, this has prompted me to get out of vim and into firefox to post my very first blog article on just what has been going on in Nouveau since Fedora 11&apos;s release.&lt;br /&gt;&lt;br /&gt;&lt;span style=&quot;font-size: larger;&quot;&gt;&lt;strong&gt;Kernel Modesetting (KMS)&lt;/strong&gt;&lt;/span&gt;&lt;br /&gt;In Fedora 11, KMS was provided as an experimental option that owners of GeForce 8 and higher hardware could switch on an try.&amp;nbsp; This has changed in Fedora 12.&amp;nbsp; One of the first new features pushed into Nouveau was a port of the userspace RandR 1.2 (yes, despite what the above-mentioned article claims, we have supported this for quite a long time now, on all chipsets) for *all* the earlier chipsets to the DRM&amp;nbsp;in order to provide KMS&amp;nbsp;support.&lt;br /&gt;&lt;br /&gt;As a result of this, and additional improvements to the pre-existing G80 KMS&amp;nbsp;support (see below), KMS is now the default in Fedora 12.&lt;br /&gt;&lt;br /&gt;&lt;span style=&quot;font-size: larger;&quot;&gt;&lt;strong&gt;G80 Modesetting&lt;/strong&gt;&lt;/span&gt;&lt;br /&gt;Previously, the modesetting code for GeForce 8 and higher chipsets did essentially the exact same thing as the NVIDIA-supported xf86-video-nv driver.&amp;nbsp; While this is sufficient for a large number of configurations, quite a lot of work had to be done to reverse-engineer and implement support for a number of features we were aiming for in F12.&lt;br /&gt;&lt;br /&gt;&lt;u&gt;VBIOS&amp;nbsp;output configuration scripts&lt;/u&gt;&lt;br /&gt;In a vaguely similar fashion to ATOMBIOS on ATI&amp;nbsp;GPUs, the video BIOS&amp;nbsp;on NVIDIA&amp;nbsp;chipsets provide a number of tables and &amp;quot;scripts&amp;quot; that are extremely useful to the driver when initialising the display.&amp;nbsp; Since Nouveau gained RandR 1.2 support for GeForce 7 and earlier chipsets, we&apos;ve been using quite a lot of this information to program the outputs on the graphics card, resulting in far, far more stable modesetting capabilities.&amp;nbsp; Beginning with GeForce 8, a great deal of the functionality we depend on for the early chipsets moved, thus we were stuck with the semi-capable hardcoded initialisation from xf86-video-nv.&lt;br /&gt;&lt;br /&gt;A while back, I stuck my head into various VBIOS&amp;nbsp;images and traces of the NVIDIA binary driver and started slowly connecting the dots between various tables and eventually discovered where to find, and how to use the new tables present on G80.&amp;nbsp; As a result of this, we are no longer dependant on the VBIOS&amp;nbsp;POST&amp;nbsp;routine assisting with the output configuration (also very important for suspend/resume!), and are able to configure a lot of output combinations that previously would&apos;ve caused the GPU&apos;s display engine to hang in disgust.&lt;br /&gt;&lt;br /&gt;&lt;u&gt;Display Push Buffer&lt;/u&gt;&lt;br /&gt;The usual method for output configuration is to bash on a whole bunch of card registers, and that&apos;s (almost) precisely what we were doing in&amp;nbsp;F11.&amp;nbsp; GeForce 8&apos;s display architecture is a little different however, and bears a lot more resemblance to how you would usually program the graphics (2D/3D) engine of a GPU.&lt;br /&gt;&lt;br /&gt;In F11, we submitted commands to the display engine with a hackish method we inherited from nv.&amp;nbsp; Unfortunately, while this method was enough to be able to program a mode, it bypasses some of the hardware that&apos;s required to implement things such as tiled scanout.&lt;br /&gt;&lt;br /&gt;F12 now submits commands to the display engine the same way the NVIDIA&amp;nbsp;binary driver does; by filling a DMA&amp;nbsp;buffer with commands and telling the GPU&amp;nbsp;to fetch them itself, rather than having the CPU&amp;nbsp;poke registers directly.&lt;br /&gt;&lt;br /&gt;&lt;u&gt;Tiled scanout&lt;/u&gt;&lt;br /&gt;The 3D engine on&amp;nbsp;GeForce 8 chipsets refuses to render to a linear framebuffer.&amp;nbsp; This can be a *huge*&amp;nbsp;performance hit in a number of scenarios, as we&apos;d have to stall the entire graphics pipeline and render in software.&amp;nbsp; In F11, we didn&apos;t know how to make the display engine scan out from a non-linear framebuffer and had some rather elaborate workarounds that kept a shadow tiled version of the front-buffer and periodically blitted (with the 2D engine)&amp;nbsp;it to the scanout buffer.&lt;br /&gt;&lt;br /&gt;In Fedora 12 this has changed, the method to program the display engine for tiled scanout was reverse-engineered and implemented in the driver.&amp;nbsp; Allowing us to remove the ugly workarounds from the driver, and gain back some GPU&amp;nbsp;power that was used for the additional copies between the shadow and scanout buffers.&lt;br /&gt;&lt;br /&gt;&lt;strong&gt;&lt;span style=&quot;font-size: larger;&quot;&gt;Suspend/Resume&lt;/span&gt;&lt;/strong&gt;&lt;br /&gt;Yes, that&apos;s right, Nouveau finally supports suspend/resume.&amp;nbsp; In theory the support is there for all chipsets.&amp;nbsp; In the very least, every chipset I own (at least one from each family, and 5 G80-class cards)&amp;nbsp; can suspend/resume reliably except for a TNT2 that has other issues..&amp;nbsp; This support is only available when kernel modesetting is switched on, so that&apos;s even more reason to use it!&lt;br /&gt;&lt;br /&gt;&lt;strong&gt;&lt;span style=&quot;font-size: larger;&quot;&gt;Other Stuff&amp;nbsp;&lt;br /&gt;&lt;/span&gt;&lt;/strong&gt;&lt;span style=&quot;font-size: larger;&quot;&gt;&lt;span style=&quot;font-size: smaller;&quot;&gt;The above is the major user-visible improvements between Fedora 11 and Fedora 12, but there&apos;s more work going on.&amp;nbsp; On the 3D front Christoph Bumiller has done a lot of excellent work on the G80 3D driver, it&apos;s becoming more capable every week.&amp;nbsp; Francisco Jerez did a massive, much needed cleanup of the NV04-G70 modesetting code, and implemented initial support for TV-out on those chipsets.&amp;nbsp; There&apos;s work going on to implement DisplayPort support, ongoing work on 3D supoort, and likely more things that escape my mind right now.&lt;br /&gt;&lt;br /&gt;In conclusion, Nouveau development is progressing quite nicely, and is far from dead!&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;</description>
  <comments>http://skeggsb.livejournal.com/568.html</comments>
  <lj:security>public</lj:security>
  <lj:reply-count>18</lj:reply-count>
</item>
</channel>
</rss>

