For the record, I created a ticket, but it has not much info yet:
https://dev.haiku-os.org/ticket/17264
Hope this will help getting it solved at some point 
3 Likes
I also have problem that app_server start freeze and load CPU after running accelerant test. Maybe retrace semaphore problem.
Accelerant cloning unfortunately not working. It returns error when attempting to clone. Cloning accelerant should perform better and cause less conflicts when app_server is running.
2 Likes
Also is it hard to implement hardware alpha blitting support? Software alpha blitting is slow because it use slow video memory reading.
2 Likes
Sorry, don’t know. I never looked at intel’s acceleration engine yet.
I am testing BWindowScreen atm on the intel driver and it seems to fail, so I’ll fix that if possible. Cloning I did not test yet (normally I am testing with a video consumer node which does that and displays video on a secondary graphics card: don’t even know if I can activate a second card alongside intel atm, and besides I don’t know if video overlay is supported on the intel driver, which the node needs (or scaled_filtered_blit)
I can imagine that the retrace semaphore isn’t working on your card since a lot does not work there yet (setting modes).
1 Like
It works for Intel graphics. At least GLTeapot shows 60 FPS. I also made BDirectWindow tearing tests with retrace semaphore.
2 Likes
ah ok, then there’s another problem there. Maybe the DPMS thing again?
Matrix channel user reported screen with artifacts. Any Ideas why this can happen?
Assuming the colorspace is set in app_server the same as in the hardware (so setmode is working) it can be RAM access trouble. Try lower resolution or colordepth to see if it improves. if so, that points towards RAM access. If intel uses shared (main) memory as GPU memory, a faster type of memory might improve the situation as well.
Of course the real solution is that some programming needs to be added to the driver that is apparantly missing, i.e. caching and priority for this RAM access. RAM access can be checked of course by writing a pattern to the screen memory and reading it back for comparing… The Nvidia driver has this function and uses it for prio stuff IIRC.
EDIT:
There are -two- types of access occuring where it could go wrong:
- main CPU <> GPU (shared) RAM: this can be tested with writing - reading a pattern.
- GPU reading the RAM. this can practically only be ‘tested’ by visually confirming it is OK or not…
The priority that needs to be programmed if RAM is rather slow is the priority between these two types. Accessing with larger (or smaller) chunks ‘at a time’ (RAM path width, line-cache, stuff like that) arranges the caching part.
All in all it’s always a good thing to have as fast as possible main RAM in the system if this is shared for use with a GPU. I’ve seen a lot of shit so to speak trying to optimize this stuff…
Oh yeah: and there is clocking of course… It might be that the cardBIOS sets slow clocks as it knows what VESA mode (or so) it is setting during boot. If the driver is set for a much higher mode, and it does not know how to program the clocks, it is not going to work very well.
So there can be a lot that’s not OK 
Sorry, last edit: for Intel even more can go wrong: we have this link between CPU and southbridge: if that’s in use with too low capacity (can also be for the display-link in theory) again that -could- look like this…
6 Likes
It might be a defect graphic card as well. I have such a laptop…
Try another OS to make sure the Latop itself works!
2 Likes
This is a bit off the topic of the Intel gfx driver, but I figured I’d ask anyway… @rudolfc was it you who wrote that old Nvidia chipset driver for Haiku? I was wondering how feasible it would be to rewrite that driver while adding support for newer Nvidia chipsets (in this case, I mean up to about 2010 or so). Maybe it’s something I can try to look into, after I learn the basics of C/C++… 
Hi, Yes indeed, along with VIA, Matrox, Neomagic, and the nividia 3D hardware acceleration ‘add-on’…
Originally I wanted to have a seperate driver for newer nvidia cards. Seeing nouveau, that driver would be much different when based on that. So, as an intermediate solution, indeed I was also thinking of expanding the current driver a bit more, as long as it ‘fits’ more or less in there.
I did some preliminary tests with a 8400 and a 9200. There are currently problems accessing most of the hardware registers. Mapping is OK since I can work with the general / basic control registers, so some thing probably needs to be added to enable access to the rest. This could be an indication things work quite differently indeed later on, don’t know for sure yet.
I did get DDC/EDID going on the 9200 for HDMI and external VGA (this is a laptop). For displayport it’s quite a different story, as with intel, but that is logical as this interface nolonger has explicit I2C wires (it’s embedded in the higher level serial protocol these days).
Something that I also don’t know yet is how dependant support for newer cards is going to be on the card BIOS: nouveau gets a lot of info from there i.e. which DDC port connects to what connector? Upto ‘now’ I could make some assumptions about that, but that might nolonger be true (tests could be done to get a clearer picture on that, but that requires a lot of different cards of course, find the ‘common denominator’ and see if it’s large enough).
It would be very nice if we would have a completely new driver based on nouveau, as that adds a lot of functionality I only implemented partly (had to ‘invent’ it all myself back then, while now you can ‘just copy’ that from the nouveau driver )
Hope this answers your question ( a bit)…
8 Likes
Very true indeed. I assumed that this was already done
Laptop user (it is not my photo) also posted photo with ReactOS that works fine. Windows probably works fine too.
1 Like
Yes, you are indeed right, there’s a problem with cloning: the shared info is apparantly not ‘copied over’. BWindowScreen also clones the accelerant, and I see in move_display that the virtual size is zero by zero.
This needs fixing (missing flag in kerneldriver?). Along with that a modeflag that’s essential is missing. This is due to multiple errors:
Since creating the modelist is offloaded to ‘common’ the driver has ‘less influence’ on it than if it’s internal. At least, officially this list needs to be iterated again by the driver to set the flags correctly, instead of relying to the defaults done by the external code: which does not know about the card’s hardware restrictions.
A second problem is that setmode in the driver foregoes calling proposemode. Proposemode would also validate for instance these flags. Proposemode is missing that as well…
If you are testing with cloning currently, can you have a peek at the shared info cloning in the kerneldriver? later on today I hope to update the driver with a few patches for the rest.
4 Likes
Thanks for the reply @rudolfc, and despite my limited knowledge, I’d agree that a port of nouveau, or simply a new Haiku driver containing some code based on nouveau, might be the way to go. I’ve been considering learning either C or C++ for the purpose of contributing something to the Haiku project; porting a whole new driver might be difficult, but might still be something I could look into, after I’ve got the language’s basics down… though it would be a part-time effort at best
For a bit of context, I’ve got a laptop that uses an Nvidia Quadro FX 3700M GPU (G92 series), and the only thing that’s currently preventing me from using Haiku as its primary OS is the lack of an accelerated graphics driver.
@X512 Ah Ok, got it: the current mode is not shared. It has nothing to do with failed sharing info. I’ll patch it.
1 Like
Ah, I understand why you’d want a nvidia driver update Still, while the driver (for the cards currently supported) would support acceleration, it is not in use by app_server. So you’ll gain no acceleration at all. You do gain modesetting, second screen, and pageflipping like things, and probably at some point a hard cursor.
Just committed hrev55454. This fixes:
- Cloned accelerants,
- (Smooth) panning and scrolling with virtualscreens (i.e. BWindowsScreen use).
- Should work on all generations now, upto/including Haswell.
So for instance games that use panning and scrolling through a scene larger than your desktop resolution should now work. 
15 Likes
Are there any updates to the supported cards for intel coming?
That’s a good point… maybe eventually I’ll be able to take a look at the app_server source to see how difficult it would be to add acceleration support, if someone else doesn’t get to it sooner 