Would the latest Intel integrated graphics be backwards compatible with older, Intel HD Graphics? Also, what is the most efficient way to detect CPU, in order to decide whether to initialize Intel or AMD integrated graphics? CPUID?
Thanks
Integrated Graphics Backwards Compatibility & Detection
- PavelChekov
- Member
- Posts: 113
- Joined: Mon Sep 21, 2020 9:51 am
- Location: Aboard the Enterprise
Integrated Graphics Backwards Compatibility & Detection
USS Enterprise NCC-1701,
The Final Frontier,
Space,
The Universe
Live Long And Prosper
Slava Ukraini!
Слава Україні!
The Final Frontier,
Space,
The Universe
Live Long And Prosper
Slava Ukraini!
Слава Україні!
-
- Member
- Posts: 5565
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Integrated Graphics Backwards Compatibility & Detection
I don't think they're backwards compatible at the register level, but they do have some similarities, so parts of the drivers can be the same between different generations. For example, take a look at the Linux i915 driver.PavelCheckov wrote:Would the latest Intel integrated graphics be backwards compatible with older, Intel HD Graphics?
Enumerate PCI. The integrated graphics will appear as a PCI device.PavelCheckov wrote:Also, what is the most efficient way to detect CPU, in order to decide whether to initialize Intel or AMD integrated graphics? CPUID?
- PavelChekov
- Member
- Posts: 113
- Joined: Mon Sep 21, 2020 9:51 am
- Location: Aboard the Enterprise
Re: Integrated Graphics Backwards Compatibility & Detection
So, to support most modern computers, which version of integrated graphics should I write a driver for? I would use the framebuffer, but my understanding is that is not the ideal method.
USS Enterprise NCC-1701,
The Final Frontier,
Space,
The Universe
Live Long And Prosper
Slava Ukraini!
Слава Україні!
The Final Frontier,
Space,
The Universe
Live Long And Prosper
Slava Ukraini!
Слава Україні!
Re: Integrated Graphics Backwards Compatibility & Detection
Well if you want the most compatibility, i would say vesa is the most compatible.
There is no real hardware acceleration as standard, but you might still get some form of hardware blitting with it ( not sure how good is the support through bios interface though).
There are technics that can be workable to use bios interupt from protected mode.
Working directly on the hardware is going to be complicated and not very compatible.
Chipset become incredibly complex and varied.
For the 2d part you might have some chance to work it up with limited amount of drivers. From what i last looked in linux ddx drivers, it seems roughly compatible but still many switch for potential internal format / frequencies or other things.
There is no real hardware acceleration as standard, but you might still get some form of hardware blitting with it ( not sure how good is the support through bios interface though).
There are technics that can be workable to use bios interupt from protected mode.
Working directly on the hardware is going to be complicated and not very compatible.
Chipset become incredibly complex and varied.
For the 2d part you might have some chance to work it up with limited amount of drivers. From what i last looked in linux ddx drivers, it seems roughly compatible but still many switch for potential internal format / frequencies or other things.
-
- Member
- Posts: 5565
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Integrated Graphics Backwards Compatibility & Detection
If you're only using a framebuffer, you don't need to write a driver. Your bootloader can ask the firmware (VBE or GOP) to set up a framebuffer.PavelCheckov wrote:I would use the framebuffer, but my understanding is that is not the ideal method.
Re: Integrated Graphics Backwards Compatibility & Detection
I think you're getting way ahead of yourself. Start with the framebuffer provided by firmware/bootloader/whatever. That will be far easier than trying to write any specific driver, and is the most compatible option. Then get the rest of your OS working. Then, finally, you can worry about making the graphics more efficient.PavelCheckov wrote:So, to support most modern computers, which version of integrated graphics should I write a driver for? I would use the framebuffer, but my understanding is that is not the ideal method.
If you try to go about writing a chip-specific graphics driver before you have anything much else, I can almost guarantee you'll get bogged down and never really get anywhere.
Re: Integrated Graphics Backwards Compatibility & Detection
I agree with the last post, unless your goal is really focused on accelerated graphics, its not neccesarily the first thing you should get into.
Already handle all the infrastructures to load/unload drivers ( you probably will have to do this a couple times x)
Some tools to debug/test/monitor etc
Eventually start working some basic rendering primitives, drawing pixels, lines, polygons, fonts, image blitting etc using the framebuffer with a good testing already for the basics.
Then Eventually you can start recoding that with real accelerated manually programmed graphic drivers.
Well thats my 2 cents anyway
Already handle all the infrastructures to load/unload drivers ( you probably will have to do this a couple times x)
Some tools to debug/test/monitor etc
Eventually start working some basic rendering primitives, drawing pixels, lines, polygons, fonts, image blitting etc using the framebuffer with a good testing already for the basics.
Then Eventually you can start recoding that with real accelerated manually programmed graphic drivers.
Well thats my 2 cents anyway
- PavelChekov
- Member
- Posts: 113
- Joined: Mon Sep 21, 2020 9:51 am
- Location: Aboard the Enterprise
Re: Integrated Graphics Backwards Compatibility & Detection
Thanks, everyone!
USS Enterprise NCC-1701,
The Final Frontier,
Space,
The Universe
Live Long And Prosper
Slava Ukraini!
Слава Україні!
The Final Frontier,
Space,
The Universe
Live Long And Prosper
Slava Ukraini!
Слава Україні!