xf86-video-i128 Version 1.4 released

Here is the announcement post.  I do understand that the hardware itself is about 20 years old, but at least I want the code itself to compile without compilation warnings, so I decided to release a new version.  The code can be compiled without compilation warnings even with the -Wall option added to the compilation script.

To be honest, I did not really test the code with the real hardware prior to the release.  I did purchase one PCI and one AGP version of Number Nine Imagine 128 from now defunct WeirdStuff Warehouse, but I do not have immediate access to it.  It is probably in one of my boxes full of graphics cards.  After all, there is a reason why this blog is called Brace Computer Laboratory blog.

Off topic, but considering what Google did to WeirdStuff Warehouse, I honestly will never, ever want to work for Google.  Not that that will ever happen since it is very, very hard to get interviews from them unless one graduated from a top tier university. (I have applied to several of their FPGA design related positions last year, but never got even a phone interview.)  Some of the area large tech corporations are becoming ever more predatory when it comes to gobbling up office space around the South Bay Area.  I am not against large corporations expanding, but please do so without disrupting long term tenants like WeirdStuff Warehouse.  I really hate seeing South Bay Area institution getting put out of business like this.

xf86-video-i740 Version 1.4 released

Here is the announcement post.  I cross posted it over at Intel-gfx mailing list.  I do not mean to bother Intel people, but hey, it is your company’s old chip, hence, the announcement post had to be cross posted there.

For those who do not know what Intel740 is (was), as of now (end of Year 2018), it is the only Intel discrete graphics chip to officially ship ever since Intel got deeply involved in the x86 PC system business with the likes of PCI bus and USB.  And yes, that was almost 21 years ago.  Intel is getting ready to get “back” into the discrete graphics business (again), possibly as a way to fill their expensive fab with silicon wafers.  As an amateur hardware industry watcher, I guess they must have sensed that they are not very good as a corporation at producing low cost and power products (i.e., smartphone SoC produced at TSMC), so they might as well concentrate on high power and margin discrete graphics products.  In general, it is understood in the industry that Intel is good at developing products on their own process technology using very high speed transistor. (although the transistors tend to be leakier compared to TSMC as a trade off)  Hence, its process technology emphasis matches the general direction the GPU industry is headed (i.e., use of GPU as a computation accelerator) where high performance is appreciated and high cost and power can be tolerated as long as the performance is outstanding.  These characteristics match Intel’s business model very well (i.e., x86 processor business), although they will have to be competitive overall against NVIDIA if they wanted to not lose money in it.

When I was an undergraduate student in EE (Electrical Engineering) some years ago, there was one lecturer who mainly taught graduate section of the department at this university.  I got to know this person because I took one graduate class with him. (a digital IC design class)  I was probably one of the five “American” (some “American” students were naturalized citizens who immigrated from another country) students out of 130 or so students who took the class. (Note: The class was had 2 sections with total of about 130 or so students. The second section with 30 people were added due to popular demand.  I was in the 100 or so first section.)  I did get an A- grade for the class, but it really did not help me get a full time job after graduation.  I would imagine all the non-American students got jobs.  Some years ago, it was almost a sure thing for foreign graduate students in EE or CS to get jobs, unlike us American students.  This really is not true anymore, especially since Year 2014 or so.  There are simply too many foreign graduate students in the EE or CS, and there are not enough jobs to go around even for them.  I have seen two new college graduate MSEEs each toiling in a municipality mandated minimum wage (i.e., higher local minimum wage) job at $13.00 / hour with Optional Practical Training (OPT; it essentially acts like a shadow H-1B visa program for up to 3 years for foreign master’s and Ph.D. NCGs.) after graduation.  They were working on a computational accelerator card that contains an Intel Stratix 10 FPGA with the business owner who did not have any hardware industry experience before getting into hardware business . . .  It appeared that they (all of them; the business owner and two inexperienced MSEEs) were struggling due to lack of experience and very low staffing.  On the other hand, a friend of mine who also took this class together and did the class project together is still stuck in an unending “contract” employment loop reserved for some unlucky American citizens in the computer / electronics industry.

Going back to the main story, the funny thing was that this lecturer was far, far more accomplished than pretty much all tenured and tenure track professors combined who taught at the university’s EE department. (Note: I did not go to a name brand top tier university for that matter, hence, strange thing like this happens if you get someone accomplished from the industry willing to work for mere 1/3 of the pay of the tenured professors as a hobby / quasi retirement job.)  This person actually worked on the Intel740 project as a senior manager of the project, and he has told me that C&T (Chips & Technologies) developed VGA compatibility circuitry went into Intel740 and subsequent Intel integrated graphics starting with Intel 810 chipset.  Please note that he was not really involved in the 3D portion, and his specialization was in the VGA / 2D portion. (note the C&T reference)  Anyway, even though PC industry historians (Is there such a thing?) considered Intel740 to be something of a failure (I personally do not agree with this view, but that’s what some people say.), it is the original roots of pretty much all Intel integrated graphics a lot of people use today.

Considering that I personally know someone who worked on Intel740 project, it feels odd for me to get involved in releasing xf86-video-i740 DDX for X.Org X Server.  I did not really write any code for that matter (only one small patch to suppress a compilation warning), but I did test the pre-release version of the code on Shuttle AV40 mainboard.  This mainboard supports Intel Pentium 4 and has a universal AGP slot, (i.e., an AGP slot with 1.5 V and 3.3 V signaling support) and for Intel740, you need an AGP 3.3 V or universal slot.  By the way, Shuttle AV40 has VIA Technologies P4X266 chipset and that’s the reason why I was able to test Intel740 with Intel Pentium 4.  (Note: Intel chipsets since Intel 850 chipset do not support AGP 3.3 V signaling.)

Actually, Real 3D (a joint venture between the notorious money wasting defense contractor called Lockheed Martin and Intel) had a graphics card called Starfighter PCI that used a PCI to AGP bridge and one or two SDRAM devices to act as texture storage, but it is a pretty rare graphics card, so I did not test the code on it since I do not own a copy of it.  I did test the code on Real 3D Starfighter AGP and an unknown Taiwanese vendor Intel740 AGP graphics card. (same one pictured)  Both of them worked fine.

Speaking of “an unknown Taiwanese vendor,” the same Intel740 senior project manager told me that around Year 1999, Intel dumped their unsold (i.e., unwanted) inventory of Intel740 in Asia (i.e., Taiwan, Hong Kong, and China, but not Japan or South Korea) for something around $5 / chip, hence there were so many variants of Intel740 graphics card coming out of Asia at that time.  Before integrated graphics became the norm of the PC industry, there used to be something called $40 graphics card business (some of them even sold for $30), and Intel740 was eventually relegated to that bargain basement bin of the mom and pop computer dealers along with unpopular models from S3 (ViRGE and Trio3D), SiS (6326 and 305), and Trident Microsystems (3DImáge9750, 3DImáge9850, and Blade3D).  Integrated graphics pretty much killed off this category in the PC component business for all practical purpose. (The category still exists, but the volume is very small today.)

Getting back to my blog post, because one of my focus on my Linux based OS development is getting standby resume to work properly (Perhaps, my only significant contribution to OpenChrome Project.), I did test xf86-video-i740 DDX to see if it can handle resuming from ACPI S3 State.  Interestingly, Shuttle AV40 mainboard supports ACPI S3 State (Suspend to RAM or STR), and when I tested standby resume on NVIDIA GeForce 2 MX (running Nouveau DDX and DRM), it resumed flawlessly, so I was confident that ACPI S3 State resume handling code inside the BIOS will work fine.

The verdict for xf86-video-i740 DDX standby resume handling is that it does not lock up the system, but some registers are not being restored by the DDX mode setting code, hence, the display becomes disrupted.  I have seen something like that with OpenChrome DDX, and I was able to fix the issue eventually.  Perhaps, if I am willing to spend the time on it, I may be able to fix it, however, I do not really have the hardware register documentation for it.  If someone has it, please e-mail it to me.

In practice, xf86-video-i740 DDX is not practically usable even if you wanted to use it.  Honestly, I do not really think anybody still uses it today on Linux / BSD.  This is comment is coming from someone who gets ridiculed regularly for working on old graphics device drivers. (i.e., Phoronix articles written about me over the years and some of its visitor comments)  The device is not practically usable because 2D acceleration has been turned off ever since XAA has been removed from X Server, and without acceleration, the rendering speed is shockingly slow.  You will notice this if you try to move a window on Xfce window manager. (i.e., Xubuntu)

Anyway, I decided to release a new version because I am little by little cleaning up compilation warnings from various old DDXs, and xf86-video-i740 DDX was in better shape than other DDXs, as far as compilation warnings are concerned.

I may work on fixing the standby resume issue eventually, but I do not know when that will be.

Two new fixes went into OpenChrome DDX

While the OpenChrome DDX code has not received much attention lately, I put in two fixes into the upstream repository.

The first fix changes the way the VGA registers are saved.  Now the VGA registers are saved during DDX initialization rather than when DDX enters GUI mode.  This change appears to improve the display condition when the user switches to VT (Virtual Terminal) screen after going through one or more standby resume events.  Previously, VT screen will go completely blank in most computers if the user goes through one or more standby resume events.  The only catch right now is that the code is still not perfect, and in some computers, the VT screen does not get restored correctly.

The second fix is meant for standby resume to work correctly on VIA Embedded EPIA-M830 mainboard.  The code fix for OpenChrome DRM happened back in July, but due to my own lack of interest, I did not develop the fix until recently.

It will be nice if I can fix this bug soon, but I do not have the exact equipment for testing purposes.  The person who reported the bug has not responded so far.

xf86-video-r128 Version 6.12 released

I was supposed to post this message back in October 2018, but I forgot to do it.  Anyway, I released xf86-video-r128 Version 6.12 to fix two urgent build failures reported by users.  Here is the official announcement.


I did not state in the official announcement, but there is practically no change in the functionality of the DDX device driver.  All the rendering issues present with the current r128 DDX EXA code (i.e., occasional artifacts and sluggish 2D rendering performance) are still there.  The only thing I noticed about the artifact bug is that if I allocate excess amount of storage dedicated to EXA off screen memory, the artifact bug does not seem to happen.

I have not experimented with it for almost 2 months, but I still have not found the registers I need to restore when resuming from standby in order to prevent system lockup.  I am assuming that AGP related PLL not getting restored correctly is causing the system lockup, but so far, that has not really fixed the issue.

Regarding the rewrite of GEM / TTM memory allocator

Some of you who have been monitoring the development of OpenChrome graphics stack may have noticed the slow down in the development over the past few months.  To be honest, there were some personal reasons for this, but I will not want to go into details.  The other reason why the development pace has slowed down is due to myself forcing to work solely on the new GEM / TTM memory allocator as discussed in this blog post.  I am working on this matter slowly since I am trying to understand what the code will be doing before I write the code.

OpenChrome DRM drm-next-4.20 branch is working again

Last month, I posted 2 posts (here and here) on this blog regarding the state of OpenChrome DRM drm-next-4.20 branch.  Although I initially suspected I2C bus helper service to be the suspect, after some testing, I started to suspect something within the DRM core was causing the issue.  Unfortunately, I was not able to track down the suspect commit of DRM core even though I did try several times.

I tried Linux 4.19 rc2 from DRM subsystem repository several weeks ago, but that did not resolve the issue.  I just tried Linux 4.19 rc5 from DRM subsystem repository now, and this time around, OpenChrome DRM is working again!  Basically, I had to live with the bleeding edge of OpenChrome DRM not working for about 2 1/2 months.  It was really frustrating when someone else causes a problem that I have little control over it, but I am happy I am now out of this long tunnel.


Update on the broken OpenChrome DRM drm-next-4.20 branch

I still have not figured out why the OpenChrome DRM drm-next-4.20 branch is not working.  Looked at I2C bus subsystem related code commit, but could not really find a commit that will cause a crash like what I observed.  As an experiment, played around with Linux 4.18 rc6 to see how it will perform.  The good news is that this version is working, and in fact, I am writing this post from the computer I used to compile the code (VIA Embedded EPIA-M830 with VIA Nano 1 GHz).  I will test Linux 4.18 rc7 shortly.  Since I went back to performing full compilation, it might take a few hours to compile the code and test it.

OpenChrome DRM drm-next-4.20 branch is currently broken

I moved the OpenChrome DRM development into drm-next-4.20 branch more than a week ago, but I discovered that when OpenChrome DRM is being used, it can no longer boot the OS.

The reason for this is due to a strange bug introduced by I2C bus subsystem device driver between Linux 4.18 rc4 and rc7.  The matter was not resolved by upgrading to Linux 4.19 rc1.  I have tried to find the offending commit of I2C bus subsystem, but I am not able to find the bad commit so far.  I contacted the I2C bus subsystem maintainer, but he denied that “core” I2C bus subsystem device driver has changed recently.  Generally speaking, the I2C bus subsystem maintainer did not show much interest in the issue when I reported the issue to him directly via e-mail.  I guess I will have to go bisect the issue myself.

Status of legacy graphics stack development project (June / July 2018)

Similar to what I usually do with OpenChrome Project, I will start giving end of the month summary of what happened with what I will call, “legacy graphics stack development project.”  For now, this will mainly mean ATI Technologies RAGE 128, but it will likely expand into other devices down the road.

In June, I decided to start working on ATI Technologies RAGE 128.  This was due to RAGE 128 having good technical documentation and the device driver has limited device support scope.  Some time in early July, I was able to commit code myself.  At the present time, I am focused on code refactoring (mainly initialization code) and fixing standby resume.  I am starting to learn how the EXA code works in order to figure out why the EXA code renders some junk on the screen sometimes.

In addition to that, I went ahead and released xf86-video-r128 Version 6.11.  It fixes a bug that causes some RAGE 128 Pro models to output out of range signal to the monitor.  At this rate, I think it will take several months before I can fix one significant bug of RAGE 128 DDX.