Hello again, this time around the PLLs on skylake are programmed, over here I can use all the gfx card outputs, and have two screens running at the same time even.
Since on a laptop it was shown that at least the native mode displays correctly on it’s internal panel, I have now enabled all known skylake desktop and mobile graphicscards in git, see: hrev55667
If you have such a system don’t hesitate to let me know how it holds up with this. It might be that on some systems (for instance) the intel GART driver is not recognized yet, so if you see errors about that in the syslog also let me know: if all is right we simply have to add it’s ID to that driver (hostbridge ram interface).
This would be the same on Intel and for instance nVidia.
I just read this (DRI wiki): GART
Which would describe it, you call it GTT in your posts if I am not mistaken.
On the Intel driver it’s apparantly needed (I assumed before, but maybe that’s nonsense come to think of it now) to give the CPU access to gfx memory for the framebuffer. I did not look into the details, I just know it’s there and it must be enabled to make the intel_exreme driver work. My focus upto now lies explicitly inside the intel_extreme driver, the graphics cards register docs, along with pieces of the drm driver.
Might well be (would be much more likely) it’s only needed for the acceleration part which is nolonger in use by the app_server though. That would make more sense as the goal of GART would be to make seperate bits and pieces spreaded in system memory appear as one contiguous piece of memory to the GPU so the GPU can burst DMA with it (scatter/gather accesses).
In my 3D addon driver textures were/are uploaded to the graphics memory by the CPU, that would be interesting to let do by the GPU. Also, when I worked on this, graphics memory was at most 256Mb, where it’s much more these days. I read that the aperture where accesses are done is still only 256Mb so a lot of ‘fiddling’ has to be done to get things done between main system and graphics card to let it fit into that ‘narrow channel’.
I think you’re much more into the details these days, so correct me if/where I’m wrong
For the nVidia driver I never bothered to look at this, though I did program AGP modes (I initially wrote the AGP busmanager without the GART part). The CPU can much faster access graphics memory there when the AGP-FW feature is enabled when compared to PCI (so non-AGP) mode.
I did setup DMA access for the GPU to/from system main memory though as I have the circular command buffer in main memory. For nVidia this piece could be done by just programming the card itself.
Hello Rudoff, great work!
How to test the driver for you?
What programs to use?
Only at start it started in the wrong resulution and the deskbar is out of reach. Now with hrev:55667 it starts always in wrong resolution.with hrev 55648 it was working to switch to different resolution.
This is generation 9.5 Coffee Lake, from 2018. So unfortunately no, won’t work, this cardtype is still to new.
The updates I am currently doing are only for:
Skylake (2015, gen 9).
Broadwell (2014/2015, gen 8),
And for Haswell (2013, late gen 7)
Skylake is nearing completion, but PLL programming is still missing for Broadwell and Haswell. I have no cards to test with for these two, but I’ll add PLL programming ‘blindly’ hoping someone will test for me and report back (via a ticket would be handy).
I am doing this because it looks a lot like Skylake I expect, while generally speaking I don’t like to add code I cannot test at all. In other words, chances are support for newer cards than Skylake will not yet come (by me), though I will probably have a second look at my Microsoft Surface 3. Since that system is still very flaky with Haiku I’d say don’t hold your breath though.
Hi Brunobastardi, do we have a ticket for this system’s graphics? Maybe it’s handy to post a screenshot or two there, with a description, and syslogs from both revs? I’d like to get as much info as is possible.
Also, I uploaded a patch to git: hrev55668
For laptops with Haswell, Broadwell and Skylake this is important for the internal panel: It enables the driver to program it so modes can be set, at least that is what I expect.
Could be that the code still has to be finetuned a bit, depending on what I see on various syslogs from users though
With these changes my CoffeeLake desktop GPU successfully sets the display to 4K. (+ change iGPU memory in EFI to 64MB)
Big thank you for working on enabling SKL, this is such a great timing for me. I’ve just upgraded my displays that no longer have DVI port and as a result I was no longer able to set any reasonable resolution using HDMI (with Nvidia card) on my bare metal install. Now I can use it again
Nice! Thanks for jumping in, super
I’m looking at your patches, I’ll report back here asap.
Looking at the intel wiki list, combined with your remarks:
Coffee lake and Kaby lake are gen 9.5. You’re saying gen 9.5 works the same as gen 9. That’s very nice and I did not expect that since there are so much changes to previous gens, and also LP variants seem to work rather differently. I did not check the docs for the later cards yet, so I’m pleasantly surprised
Comet lake is unknown on the intel list, where would you place this? Do they have a different name there for those? Or are these simply missed on that list? Any thoughts?
OTOH the Intel list mentions Kaby Lake, which you don’t mention. Any thoughts about this?
Can you share a syslog from the driver working on your system? Would love to see that. Is your screen recognized by the driver (EDID)? Does your card still have a analog VGA type connector and if so, does it work?
What are you trying to say about the nvidia driver btw? It doesn’t work correctly? or were you using VESA mode there? Which type do you have?
The intel_extreme driver supports a lot of integrated graphics from second gen graphics upto/including gen 9.5, except for the LP versions. At least it seems we are are getting there reasonably well now…
I couldn’t find specific core2duo remarks on the intel wiki page though?
Looking closer I found full manuals for KabyLake (on the sidebar) which would point to it being different, and they do mention Gen9p5. However, searching through them and public Intel repositories doesn’t yield many results - in fact in many places Gen9.5 is treated like Gen9. I believe there is no practical difference.
The list is incomplete. SkyLake - ix-6xxx, KabyLake - ix-7xxx, CoffeeLake - ix-8xxx and ix-9xxx, CometLake - ix-10xxx. On the desktop the GPU in all of them is Gen9. (Mobile is a bit more varied - ix-10xxGx is Ice Lake.)
Yes.
You mean motherboard? Yes, it does, but I didn’t check.
There is no driver for my card - GTX 750 Ti. Previously it was working fine with DVI connection - EFI correctly set native display resolution (and framebuffer driver inherited that). After switching to HDMI, only 800x600 and 1024x768 is available (and the latter is used by EFI).
Thanks for the reply. I myself find the intel way of doing/naming things rather complex which makes searching in a lot of places all nessesary indeed.
Anyhow, all in all looking good! So we can add a lot more ID’s to the driver then. I hope that gets done (by others than me) then
I am currently compiling the mods you did to test them quickly on my systems.
There is just one thing I am wondering about: you added in the kerneldriver:
" info.class_sub != PCI_display_other"
Did you actually encounter a problem for which you needed to add this? What would make for an “other” VGA display in general or at least concerning Intel? Can you elaborate a bit on this?
About the VGA connector on your system, I am curious about how this is implemented:
Your system is a desktop system, no?
the VGA connector is actually a connection to a digital output, using DP mode, if all is right on the eDP connection (which in the driver is portE currently for DDI).
I would like to establish this is the case on your system, and I would like to know if it works. Probably your screen won’t get detected yet via EDID there, but hopefully you -can- set modes there…
Yes, it seems for newer GPUs subtype has changed to PCI_display_other. This is also reflected in lspci output, where it says “Display controller” for Intel GPU, and “VGA compatible controller” for Nvidia card (which would be PCI_vga).
filtered syslog: http://0x0.st/-7Dk.txt (EDID: http://0x0.st/-7DF.txt)
It seems stolen memory detection is broken (it should be 64 MB, not 1) but it doesn’t affect anything apparently (I’ve seen similar issue on IVB, where it now works with the patch).
@Kapix,
So all seems OK, I took the liberty of doing +2 for your patches. I hope that’s OK. If I shouldn’t have done that, please inform me so I’ll learn from it
I have the impression that +2 will get it applied. If not, then hopefully someone can arrange for that. I am signing of for the coming hours now…
1MB for IvyBridge and SkyLake is always wrong. Anyway, it should be fixed now, for SkyLake too. Though this being broken and everything working fine would indicate that GART change was not necessary.
For your entertainment
Syslog VGA: http://0x0.st/-7kb.txt (works fine though it didn’t start with native res, setting manually does the trick)
Syslog DVI: http://0x0.st/-7kA.txt
