OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 4:28 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Slow framebuffer access on a real PC
PostPosted: Sun Dec 22, 2019 1:06 pm 
Offline
User avatar

Joined: Sun Dec 22, 2019 12:52 pm
Posts: 19
Location: Kazan, Russia
Hello everyone!
I'm writing a small hobby OS with a GUI in C. My GUI system uses double buffering. I render everything on the second buffer, which is located in RAM, and the transfer it to the graphics card's framebuffer. I determine the address of the last one by parsing VBE structures. To transfer pixel information I've been using my memcpy() implementation which used REP MOVSB, REP MOVSW and REP MOVSD instructions to transfer data. It worked perfectly well both in VirtualBox and Bochs, but had terrible performance on a real PC. In the last couple of days I've been in the process of switching from legacy BIOS and IA-32 to UEFI and x86-64. The very first thing I did was to extend memcpy() to use REP MOVSQ as well, as we're in the long mode now, but it didn't seem to improve the performance much. So next I tried implementing GOP block transfers and that did improve the performance, but I stil wouldn't consider it sufficient. My PC has two graphics cards, the first one is integrated (Intel HD 4000) and the second one is discrete (nVidia GeForce GT 650M) and I'm not really sure to which one my OS is "talking".
I would be very pleased with any kind of reply, thank you!

_________________
GitHub | Neutron


Top
 Profile  
 
 Post subject: Re: Slow framebuffer access on a real PC
PostPosted: Mon Dec 23, 2019 4:04 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
Hi,

portasynthinca3 wrote:
Hello everyone!
I'm writing a small hobby OS with a GUI in C. My GUI system uses double buffering. I render everything on the second buffer, which is located in RAM, and the transfer it to the graphics card's framebuffer. I determine the address of the last one by parsing VBE structures. To transfer pixel information I've been using my memcpy() implementation which used REP MOVSB, REP MOVSW and REP MOVSD instructions to transfer data.
I'm not sure why you do this. On a framebuffer the smallest amount of memory worth copying is a pixel, which (assuming you're not using ancient video modes) is a packed color on 32 bit. Using 24 bits does not worth it, use 32 bits only to make the copy pixel and wordsize aligned all the time.
portasynthinca3 wrote:
It worked perfectly well both in VirtualBox and Bochs, but had terrible performance on a real PC. In the last couple of days I've been in the process of switching from legacy BIOS and IA-32 to UEFI and x86-64. The very first thing I did was to extend memcpy() to use REP MOVSQ as well, as we're in the long mode now
For really good performance you should enable SSE too, and use prefetch and as many and as big registers as you can access on the given hardware. I've a highly optimized fast SSE copy implementation, let me know if you're interested. (All long mode processors must implement SSE2 at least, no need to check for availability.)
portasynthinca3 wrote:
but it didn't seem to improve the performance much. So next I tried implementing GOP block transfers and that did improve the performance, but I stil wouldn't consider it sufficient. My PC has two graphics cards, the first one is integrated (Intel HD 4000) and the second one is discrete (nVidia GeForce GT 650M) and I'm not really sure to which one my OS is "talking".
I would be very pleased with any kind of reply, thank you!
This could be for so many reasons. How is your framebuffer mapped? Do you use cache or write-through? Are you using aligned pixels (32 bit only)?

Also note that on modern Intel CPUs (not on AMD), REP MOVSB is not actually a simple byte transfer any more. Instead it is a special instruction to access a highly optimized memory transfer routine (check out ERMSB). This means if you only use 16 bytes aligned addresses for REP MOVSB, then that will be much faster than REP MOVSD or MOVSQ on unaligned addresses. Note that this only applies to specific Intel CPUs, but it could be that your real hardware happens to be one of them. Your video card doesn't really matter, because REP MOVSx is executed on the CPU, and the MMU (which does the memory cache) is also part of the CPU not the GPU.

Cheers,
bzt


Top
 Profile  
 
 Post subject: Re: Slow framebuffer access on a real PC
PostPosted: Mon Dec 23, 2019 10:45 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
portasynthinca3 wrote:
I'm writing a small hobby OS with a GUI in C. My GUI system uses double buffering. I render everything on the second buffer, which is located in RAM, and the transfer it to the graphics card's framebuffer.


Do you have your code in a hosted public repository, and if you do, could you please provide a link so we can look over your existing code?

portasynthinca3 wrote:
My PC has two graphics cards, the first one is integrated (Intel HD 4000) and the second one is discrete (nVidia GeForce GT 650M) and I'm not really sure to which one my OS is "talking".


On a desktop system, this usually would be easy to determine: is the monitor attached to the port on the motherboard, or the port on the adapter? AFAIK, the hardware cannot route output signals to a port other than the one it is directly connected to, and even if it could, it would require you to set it up deliberately. Can anyone confirm this?

However, given that the GT 650M is a mobile ('M') GPU, I assume that this is a laptop/notebook, and that you are using the built-in display rather than an external monitor. In that case, I would expect that it defaults to the dedicated GPU (probably with dedicated video memory, but that depends on the computer), though it may be selectable in the firmware.

What sort of GPU drivers have you written, and for which of those two? What virtualization setup did you use on the emulators, and which hardware did it emulate? Does your video driver system assume 'standard' SVGA (which never really was all that standard), or does it try to apply any of the of the functions and features of some specific hardware (whether virtual or real)?

I am not sure what other common denominator there would be which both Bochs and Virtualbox supports, if any (apparently there was some discussion about adding Cirrus support to VB as a user-implemented feature several years ago, but AFAICT nothing came of it). Even if there were any, you would have needed to implement a driver for that specific emulated hardware, which certainly wouldn't run on bare metal for either Intel's or nVidia's GPUs. Either way, I assume that your OS defaults to plain-vanilla VGA if it doesn't have a specific hardware driver for a given video system.

With regards to video pass-through allowing you to virtualize the hardware directly, this previous discussion may be relevant, though that was regarding QEMU rather than either Bochs or Virtualbox. Using VFIO would require you to connect a second monitor, and configure it to use a different GPU from the one used by the host system, with the guest getting dedicated access to the GPU it uses. I have no idea if this would even be possible on your particular notebook.

Now, the HD 4000 predates the introduction of Intel Graphics Virtualization Technology , so whichever emulated hardware you are using in Virtualbox is not going to match the physical hardware. Even if you were running on newer hardware, I don't know if Virtualbox supports GVT (Bochs presumably doesn't, being strictly a software emulator rather than a virtualizer). Either way, my understanding is that it could only be applied to the iGPU (since the Wikipedia article describes GVT as a feature of the Iris series of iGPUs specifically). Also, I'm pretty sure that GVT-d would require you to use a separate physical monitor and dedicate a GPU specifically for driving it, which for a laptop or notebook presents the same issues as with VFIO. I don't know enough about GVT-g or GVT-s to say of they will allow a virtualized GPU to be shared between the host and guest systems (my impression is that they are intended to, but that GVT-g would take a performance hit as the GPU is timesliced between the host and the guest, while GVT-s involves hardware-level emulation rather than hardware sharing).

The point being that unless you are sticking to SVGA and VBE, then you would need to write a driver for the specific GPU (most likely the GeForce). This is no small task, especially regarding the GeForce hardware, as unlike Intel, nVidia have always been tight-lipped about the internals of their hardware; while there will be a lot more information available on the older Kepler GPUs like the GT 650M than for more recent ones, it will still require a bit of digging and maybe going through the source code of some open-source drivers (e.g., Nouveau) for some of the details.

However, jumping right into driver development may be premature, until you know what the cause of the problem is.

Depending on how your GUI works, the video hardware may not be the only relevant factor. If you are booting and running off of a USB drive of some sort (especially USB 2.0 or older), then anything that requires fetching data from the drive is likely to be very, very slow, including any page faults that trigger swapping (OK, the latter isn't likely given the size of modern memories vs. the likely memory footprint of a new OS with no significant legacy cruft, but it's worth noting). There are a number of other possible issues too, I suppose, but I'd need to know more about the OS, the dev host, and the testing host (including if they are the same system or two different ones) to say.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Slow framebuffer access on a real PC
PostPosted: Mon Dec 23, 2019 12:10 pm 
Offline
User avatar

Joined: Sun Dec 22, 2019 12:52 pm
Posts: 19
Location: Kazan, Russia
Hi!

Thank you for your replies. I have tried using SSE2 as @bzt suggested with the PREFETCHNTA instruction, but didn't seem to get much of it. It's most likely a problem with my implementation.
Yes, my PC is a laptop and I use the internal screen. If memory serves me right, when I was on Windows, nVidia control panel was saying that the LCD is connected to the HD 4000, not to the GT650M.
I did stick to VBE for quite some time with a hardcoded resolution of 640x480x8bpp, but now I use the best 32bpp resolution available through UEFI GOP.
I have a GitHub repository as well. Most notably, the memcpy() function is in src/stdlib.c at line 212.

_________________
GitHub | Neutron


Top
 Profile  
 
 Post subject: Re: Slow framebuffer access on a real PC
PostPosted: Mon Dec 23, 2019 2:26 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
portasynthinca3 wrote:
Yes, my PC is a laptop and I use the internal screen. If memory serves me right, when I was on Windows, nVidia control panel was saying that the LCD is connected to the HD 4000, not to the GT650M.


Hmmn, interesting. Have you gone into the BIOS or UEFI menu to see if it says how it is current set, and does it allow you to switch between them? Presumably you could switch between them, if it has the dedicated GPU in the first place but wasn't set to use it exclusively. Also, do you have the version of nVidia Control Panel for Linux (or whatever OS you are using as your host), and does it say anything about which is being used? If not, does your OS/distro have any other hardware utilities which might say which it is using (e.g., hwinfo, inxi)?

Would you mind sharing which laptop this is (brand and model, and which CPU model it uses, if there are more than one sub-model using different CPUs)? Some other things such as the RAM (and VRAM, if there is any dedicated memory for the GPU), the development host OS (I am assuming that it is either Linux of *BSD given that comment, but Linux distros vary enough that the specifics may matter), how you are booting it when running on bare metal (e.g., separate drive partition, external flash drive, netbooting, or whatever other approach you might be using), and so on might help as well.

Do you have access to any other systems you might cross-test on (presuming you can live-boot your OS on it) to see if the problem occurs on other hardware?

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Last edited by Schol-R-LEA on Mon Dec 23, 2019 3:08 pm, edited 3 times in total.

Top
 Profile  
 
 Post subject: Re: Slow framebuffer access on a real PC
PostPosted: Mon Dec 23, 2019 3:01 pm 
Offline
User avatar

Joined: Sun Dec 22, 2019 12:52 pm
Posts: 19
Location: Kazan, Russia
Schol-R-LEA wrote:
Have you gone into the BIOS or UEFI menu to see if it says how it is current set, and does it allow you to switch between them?

No, unfortunately not. My setup menu is kind of limited to something like "Select what device do you want to boot from and in CSM or UEFI mode"
Schol-R-LEA wrote:
Also, do you have the version of nVidia Control Panel for Linux (or whatever OS you are using as your host), and does it say anything about which is being used?

I didn't find it.
Schol-R-LEA wrote:
If not, does your OS/distro have any other hardware utilities which might say which it is using (e.g., hwinfo, inxi)?

Here's a chunk hwinfo output that I think is related:
Code:
18: PCI 100.0: 0300 VGA compatible controller (VGA)
  [Created at pci.386]
  Unique ID: VCu0.+cPUzaJEOZ0
  Parent ID: vSkL.8tEhRfnWuN4
  SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:00.0
  SysFS BusID: 0000:01:00.0
  Hardware Class: graphics card
  Model: "nVidia GK107M [GeForce GT 650M]"
  Vendor: pci 0x10de "nVidia Corporation"
  Device: pci 0x0fd1 "GK107M [GeForce GT 650M]"
  SubVendor: pci 0x1025 "Acer Incorporated [ALI]"
  SubDevice: pci 0x0686
  Revision: 0xa1
  Driver: "nouveau"
  Driver Modules: "nouveau"
  Memory Range: 0xd2000000-0xd2ffffff (rw,non-prefetchable)
  Memory Range: 0xa0000000-0xafffffff (ro,non-prefetchable)
  Memory Range: 0xb0000000-0xb1ffffff (ro,non-prefetchable)
  I/O Ports: 0x4000-0x407f (rw)
  Memory Range: 0xb2000000-0xb207ffff (ro,non-prefetchable,disabled)
  IRQ: 33 (156 events)
  Module Alias: "pci:v000010DEd00000FD1sv00001025sd00000686bc03sc00i00"
  Driver Info #0:
    Driver Status: nvidiafb is not active
    Driver Activation Cmd: "modprobe nvidiafb"
  Driver Info #1:
    Driver Status: nouveau is active
    Driver Activation Cmd: "modprobe nouveau"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #15 (PCI bridge)

Schol-R-LEA wrote:
Would you mind sharing which laptop this is (brand and model, and which CPU model it uses, if there are more than one sub-model using different CPUs)?

It's Acer Aspire V3-771G with an Intel Core i5-3230M.
Schol-R-LEA wrote:
Some other things such as the RAM (and VRAM, if there is any dedicated memory for the GPU)

I have 6 GB of RAM: one 4 GB stick from Samsung and a 2 GB stick from a manufacturer which name I forgot :cry:
Schol-R-LEA wrote:
the development host OS (I am assuming that it is either Linux of *BSD given that comment, but Linux distros vary enough that the specifics may matter)

I use Ubuntu Linux version 19.10.
Schol-R-LEA wrote:
how you are booting it when running on bare metal (e.g., separate drive partition, external flash drive, netbooting, or whatever other approach you might be using)

I create a FAT32 partition on a flash drive and drop the bootable EFI file into the efi/boot directory on the flash drive.
Schol-R-LEA wrote:
Do you have access to any other systems you might cross-test on (presuming you can live-boot your OS on it) to see if the problem occurs on other hardware?

I have tried booting the system on two of my friends' PCs and the OS failed to even find the GOP on them. I only remember that the manufacturer of the first motherboard was ASUS, and the manufacturer of the second one was American Megatrends. They both didn't have any dedicated graphics cards and CPU manufacturer was Intel.

_________________
GitHub | Neutron


Top
 Profile  
 
 Post subject: Re: Slow framebuffer access on a real PC
PostPosted: Mon Dec 23, 2019 3:08 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
Oh, I should add that AFAICT (after looking up HD 4000 and Ivy Bridge on Wicked-pedo and ark.intel.com), all of the CPUs which include HD 4000 have SSE 4.1/4.2 and AVX, as well as the earlier MMX/SSE extensions. I don't know off-hand if any SSE 3, SSSE 3, SSE 4.1/4.2, or AVX instructions would be applicable for this purpose or not.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Slow framebuffer access on a real PC
PostPosted: Mon Dec 23, 2019 3:57 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
portasynthinca3 wrote:
Schol-R-LEA wrote:
Have you gone into the BIOS or UEFI menu to see if it says how it is current set, and does it allow you to switch between them?

No, unfortunately not. My setup menu is kind of limited to something like "Select what device do you want to boot from and in CSM or UEFI mode"
Schol-R-LEA wrote:
Would you mind sharing which laptop this is (brand and model, and which CPU model it uses, if there are more than one sub-model using different CPUs)?

It's Acer Aspire V3-771G with an Intel Core i5-3230M.

OK, then. According to the Aspire V3-731 manual (assuming that this web page is in fact what it claims to be), the hotkey to get into the BIOS setup at boot time is F2. Hopefully, that would get you into the UEFI setup, though as it happens, the hwinfo dump you posted (below) has the answer to the most pressing particular question that would have related to, anyway.

portasynthinca3 wrote:
Schol-R-LEA wrote:
If not, does your OS/distro have any other hardware utilities which might say which it is using (e.g., hwinfo, inxi)?

Here's a chunk hwinfo output that I think is related:
Code:
18: PCI 100.0: 0300 VGA compatible controller (VGA)
[...]
  Hardware Class: graphics card
  Model: "nVidia GK107M [GeForce GT 650M]"
[...]
  Driver: "nouveau"
  Driver Modules: "nouveau"
  Memory Range: 0xd2000000-0xd2ffffff (rw,non-prefetchable)
  Memory Range: 0xa0000000-0xafffffff (ro,non-prefetchable)
  Memory Range: 0xb0000000-0xb1ffffff (ro,non-prefetchable)
  I/O Ports: 0x4000-0x407f (rw)
  Memory Range: 0xb2000000-0xb207ffff (ro,non-prefetchable,disabled)
  IRQ: 33 (156 events)
  Module Alias: "pci:v000010DEd00000FD1sv00001025sd00000686bc03sc00i00"
[...]
  Driver Info #1:
    Driver Status: nouveau is active

It looks as if the GT 650M is the active GPU. I couldn't see anything in the manual about switching between the two, and while it may simply not have mentioned that, it's more likely that it only uses the GeForce in normal operation.

portasynthinca3 wrote:
Schol-R-LEA wrote:
Some other things such as the RAM (and VRAM, if there is any dedicated memory for the GPU)

I have 6 GB of RAM: one 4 GB stick from Samsung and a 2 GB stick from a manufacturer which name I forgot :cry:

OK. In the manual I found, it does say that the on-board GT 650M has 1GiB of dedicated DDR3 (not GDDR3) video memory, which may be relevant here. My understanding is that transferring between system RAM and video RAM - or even just clearing video RAM from the CPU - may perform quite differently from similar reads/writes to (or between different parts of) system memory. Perhaps someone more versed in this subject can comment on this.

portasynthinca3 wrote:
Schol-R-LEA wrote:
how you are booting it when running on bare metal (e.g., separate drive partition, external flash drive, netbooting, or whatever other approach you might be using)

I create a FAT32 partition on a flash drive and drop the bootable EFI file into the efi/boot directory on the flash drive.
Schol-R-LEA wrote:
Do you have access to any other systems you might cross-test on (presuming you can live-boot your OS on it) to see if the problem occurs on other hardware?

I have tried booting the system on two of my friends' PCs and the OS failed to even find the GOP on them. I only remember that the manufacturer of the first motherboard was ASUS, and the manufacturer of the second one was American Megatrends. They both didn't have any dedicated graphics cards and CPU manufacturer was Intel.

Hmmmn, could either of them have been Legacy BIOS systems, rather than UEFI systems, by any chance? As a rule, non-Apple systems made before 2010 are going to be Legacy BIOS, while ones made after 2011 are almost always going to be UEFI, with 2010-11 being a transitional period where you would have seen both in roughly equal numbers.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Slow framebuffer access on a real PC
PostPosted: Mon Dec 23, 2019 4:02 pm 
Offline
User avatar

Joined: Sun Dec 22, 2019 12:52 pm
Posts: 19
Location: Kazan, Russia
Schol-R-LEA wrote:
According to the Aspire V3-731 manual (assuming that this web page is in fact what it claims to be), the hotkey to get into the BIOS setup at boot time is F2. Hopefully, that would get you into the UEFI setup

That's how I've been entering it :)
Schol-R-LEA wrote:
In the manual I found, it does say that the on-board GT 650M has 1GiB of dedicated DDR3 (not GDDR3) video memory

Hmm. I remember it reporting 2 GiB of VRAM.
Schol-R-LEA wrote:
Hmmmn, could either of them have been Legacy BIOS systems, rather than UEFI systems, by any chance

No, I'm 100% sure they're both UEFI class 2.

_________________
GitHub | Neutron


Top
 Profile  
 
 Post subject: Re: Slow framebuffer access on a real PC
PostPosted: Mon Dec 23, 2019 4:12 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
portasynthinca3 wrote:
It worked perfectly well both in VirtualBox and Bochs, but had terrible performance on a real PC.

The frame buffer is probably configured as uncached (UC) when it should be configured as write-combining (WC). Check the MTRRs and page tables.

I'm not sure if you need to call ExitBootServices() before you can change the MTRRs.

portasynthinca3 wrote:
So next I tried implementing GOP block transfers and that did improve the performance, but I stil wouldn't consider it sufficient.

You also can't use it after calling ExitBootServices().

portasynthinca3 wrote:
My PC has two graphics cards, the first one is integrated (Intel HD 4000) and the second one is discrete (nVidia GeForce GT 650M) and I'm not really sure to which one my OS is "talking".

For memory-mapped framebuffer access, you shouldn't see any significant difference between the two.


Top
 Profile  
 
 Post subject: Re: Slow framebuffer access on a real PC
PostPosted: Mon Dec 23, 2019 6:34 pm 
Offline
Member
Member

Joined: Wed Mar 30, 2011 12:31 am
Posts: 676
Octocontrabass wrote:
portasynthinca3 wrote:
It worked perfectly well both in VirtualBox and Bochs, but had terrible performance on a real PC.
The frame buffer is probably configured as uncached (UC) when it should be configured as write-combining (WC). Check the MTRRs and page tables.
+1 for this.

_________________
toaruos on github | toaruos.org | gitlab | twitter | bim - a text editor


Top
 Profile  
 
 Post subject: Re: Slow framebuffer access on a real PC
PostPosted: Mon Dec 23, 2019 10:29 pm 
Offline
User avatar

Joined: Sun Dec 22, 2019 12:52 pm
Posts: 19
Location: Kazan, Russia
Octocontrabass wrote:
The frame buffer is probably configured as uncached (UC) when it should be configured as write-combining (WC). Check the MTRRs and page tables.

Thank you for the idea! I will try it out.

_________________
GitHub | Neutron


Top
 Profile  
 
 Post subject: Re: Slow framebuffer access on a real PC
PostPosted: Tue Dec 24, 2019 12:57 pm 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 812
Location: Hyperspace
Schol-R-LEA wrote:
My understanding is that transferring between system RAM and video RAM - or even just clearing video RAM from the CPU - may perform quite differently from similar reads/writes to (or between different parts of) system memory. Perhaps someone more versed in this subject can comment on this.

I don't have any deeper understanding, but I do know 9front's graphics performance varies a lot between machines. Some machines are fine, others slow. If I remember right, it was tracked down to the BIOS of the poor-performing machines disabling caching for writes to the framebuffer.

EDIT: Oh sorry, I see it's a known problem. :)

_________________
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie


Top
 Profile  
 
 Post subject: Re: Slow framebuffer access on a real PC
PostPosted: Tue Dec 24, 2019 1:45 pm 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3191
I've tried this on many different machines, and it is my impression that it is Intel machines that have lousy frame-buffer performance while most AMD based machines work fine. It probably relates to Intel assuming that everybody use their GPU software, and so they use some kind of emulation for framebuffer.


Top
 Profile  
 
 Post subject: Re: Slow framebuffer access on a real PC
PostPosted: Tue Dec 24, 2019 1:47 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
eekee wrote:
Schol-R-LEA wrote:
My understanding is that transferring between system RAM and video RAM - or even just clearing video RAM from the CPU - may perform quite differently from similar reads/writes to (or between different parts of) system memory. Perhaps someone more versed in this subject can comment on this.

I don't have any deeper understanding, but I do know 9front's graphics performance varies a lot between machines. Some machines are fine, others slow. If I remember right, it was tracked down to the BIOS of the poor-performing machines disabling caching for writes to the framebuffer.

EDIT: Oh sorry, I see it's a known problem. :)


I had been thinking in terms of the difference between accessing memory through the system memory bus versus through the PCI bus (IIUC, most laptops with discrete graphics and separate VRAM - including the one mentioned - place the GPU and video memory on the internal PCI bus, even though they are integrated into the motherboard), which would be a consideration even when the VRAM is mapped into the virtual memory space (again, I'm not an expert at this, but IIUC only part of it - the framebuffer and some code space, I think - is mapped to the CPU's address space at any given time, with the rest visible only to the GPU, even though - again, IIUC, and I would welcome corrections or clarifications on any of these points - any given part can be system-memory mapped as needed).

However, I'd say that the problem and solution which Octocontrabass described seems much more likely to be the culprit here.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 65 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group