High memory usage

desgen

Use monitoring tools like Process Hacker and see process properties (go to Process tab and press Enter in to process string) Performance tab, Memory graph and check Memory tab for find whats modules used too much memory and write bug-report to AMD - this is error in to here software, which I have not been surprised for so many blunders in the drivers of ATI/AMD are present since the release of first video card ATI Mach8 and often do not correct for decades.

ATI / AMD has always had a good video card circuitry copied from the IBM 8514 / A, but at the same time for desktop boards are traditionally equipped with hastily written drivers with a lot of errors, and well-written and carefully debugged drivers for professional boards that are usually built on the same microchips as their desktop analogs have numerous built-in checks to prevent them from running on "foreign" cards.

ATI / AMD is the only device that uses such an extravagant way to prevent competition between its mass and professional products. All other manufacturers use either specially developed for the professional and mass market segments of the family of chips (for example, 3DLabs GLint - Z-buffer 32 bits, frame buffer and texture memory up to 40 MB VRAM for 3D professional solutions, and 3DLabs Permedia - Z-buffer 16 bits, frame buffer and memory textures up to 8 MB DRAM for AutoCAD and entry-level systems) or use the microarchitecture chipset (NVIDIA GeForce / QUADRO / Tesla) programmable by a set of control signals.
 
VictorVG said:
desgen

Use monitoring tools like Process Hacker and see process properties (go to Process tab and press Enter in to process string) Performance tab, Memory graph and check Memory tab for find whats modules used too much memory and write bug-report to AMD - this is error in to here software, which I have not been surprised for so many blunders in the drivers of ATI/AMD are present since the release of first video card ATI Mach8 and often do not correct for decades.  

ATI / AMD has always had a good video card circuitry copied from the IBM 8514 / A, but at the same time for desktop boards are traditionally equipped with hastily written drivers with a lot of errors, and well-written and carefully debugged drivers for professional boards that are usually built on the same microchips as their desktop analogs have numerous built-in checks to prevent them from running on "foreign" cards.

ATI / AMD is the only device that uses such an extravagant way to prevent competition between its mass and professional products. All other manufacturers use either specially developed for the professional and mass market segments of the family of chips (for example, 3DLabs GLint - Z-buffer 32 bits, frame buffer and texture memory up to 40 MB VRAM for 3D professional solutions, and 3DLabs Permedia - Z-buffer 16 bits, frame buffer and memory textures up to 8 MB DRAM for AutoCAD and entry-level systems) or use the microarchitecture chipset (NVIDIA GeForce / QUADRO / Tesla) programmable by a set of control signals.

I installed Process Hacker but when I switch to process tab, it stops working...
 
VictorVG said:
desgen

Use monitoring tools like Process Hacker and see process properties (go to Process tab and press Enter in to process string) Performance tab, Memory graph and check Memory tab for find whats modules used too much memory and write bug-report to AMD - this is error in to here software, which I have not been surprised for so many blunders in the drivers of ATI/AMD are present since the release of first video card ATI Mach8 and often do not correct for decades.  

ATI / AMD has always had a good video card circuitry copied from the IBM 8514 / A, but at the same time for desktop boards are traditionally equipped with hastily written drivers with a lot of errors, and well-written and carefully debugged drivers for professional boards that are usually built on the same microchips as their desktop analogs have numerous built-in checks to prevent them from running on "foreign" cards.

ATI / AMD is the only device that uses such an extravagant way to prevent competition between its mass and professional products. All other manufacturers use either specially developed for the professional and mass market segments of the family of chips (for example, 3DLabs GLint - Z-buffer 32 bits, frame buffer and texture memory up to 40 MB VRAM for 3D professional solutions, and 3DLabs Permedia - Z-buffer 16 bits, frame buffer and memory textures up to 8 MB DRAM for AutoCAD and entry-level systems) or use the microarchitecture chipset (NVIDIA GeForce / QUADRO / Tesla) programmable by a set of control signals.
I installed Process Hacker that you provided, but some problem happened so i'm using old version now.

I'm just a high school student that has a little interest in computer.
I don't know much about these things, but i found something suspicious.

When I enable sensors "GPU [#1]: AMD Radeon 390X:", "GPU [#1]: AMD Radeon R9 390X: CHiL/IR PMBus - GPU Core" and "GPU [#1]: AMD Radeon R9 390X: CHiL/IR PMBus - GPU Aux"(all of these are second GPU sensors),HWiNFO will start growing memory. (hwinfo6.png)

After looking to Memory tab, I found amdocl64.dll is keep growing Total WS but this also grows when i don't enable second GPU sensors. (hwinfo7.png, hwinfo8.png)
Also Heap segment (ID1) is growing but it will stop at Size 16,192kB and Total WS 15,608kB, then make a new Heap segment (ID1) and continue grow. (hwinfo9.png)

hwinfo10.png shows the inside of Heap segment (ID1).
 

Attachments

  • hwinfo6.png
    hwinfo6.png
    198.7 KB · Views: 10
  • hwinfo7.png
    hwinfo7.png
    247.8 KB · Views: 7
  • hwinfo8.png
    hwinfo8.png
    219.9 KB · Views: 6
  • hwinfo9.png
    hwinfo9.png
    203 KB · Views: 5
  • hwinfo10.png
    hwinfo10.png
    195.1 KB · Views: 3
Thanks for the results. amdocl64.dll is the AMD OpenCL library and if that is leaking this clearly points to a problem there. But I don't understand why this library should be involved in monitoring, probably AMD ADL (atiadlxx.dll) uses it...
 
Please try one more test - disable the "Wake disabled GPUs" option in HWiNFO to see if that changes something.
 
Martin said:
Please try one more test - disable the "Wake disabled GPUs" option in HWiNFO to see if that changes something.

I disabled it.
Now I can't find amdocl64.dll and any growing thing in list but Heap segment is keep growing.
:huh:

After I enabled wake disabled GPU again, amdocl64.dll showed up and growing again.
 

Attachments

  • hwinfo11.png
    hwinfo11.png
    112.7 KB · Views: 8
Today, I checked MSI After burner using Process Hacker but I can only find atiadlxx.dll that seems have relevance to driver.
Only Heap segment 32-bit (ID1) is growing and stops when reaching Size 16,192kB and Total WS 15,608kB, then make another Heap segment 32-bit (ID1) like HWiNFO does.
 
This is when I disable CrossFire with second GPU monitoring enabled.

Heap segment (ID1) looks normal.
 

Attachments

  • hwinfo12.png
    hwinfo12.png
    93.1 KB · Views: 5
Can you somehow dump and send me the content of Heap segment (ID1) when memory usage is growing ?
 
Martin said:
Can you somehow dump and send me the content of Heap segment (ID1) when memory usage is growing ?

Hello, I noticed in his screenshots he has a fair bit of OSD, Graphics card, and other potentially conflicting softwares that may play part in the leakage.

MSI Gaming app, AMD Relive software, Rainmeter, Relive, etc....

I'm wondering if the fault has purely been other drivers and software installed rather than an issue purely with HWiNFO/AMD's drivers. Maybe if he experiments (optimally just fresh installing the OS) with clean booting or disabling specific applications from running on startup or just uninstalling them outright to see if the memory issue disappears.

I'm wondering if he installs the AMD minimal driver rather than the bundle (control panel/Relive). Might help future tracking down the actual cause of this.
 
desgen said:
Martin said:
Can you somehow dump and send me the content of Heap segment (ID1) when memory usage is growing ?

Hello, I noticed in his screenshots he has a fair bit of OSD, Graphics card, and other potentially conflicting softwares that may play part in the leakage.

MSI Gaming app, AMD Relive software, Rainmeter, Relive, etc....

I'm wondering if the fault has purely been other drivers and software installed rather than an issue purely with HWiNFO/AMD's drivers. Maybe if he experiments (optimally just fresh installing the OS) with clean booting or disabling specific applications from running on startup or just uninstalling them outright to see if the memory issue disappears.

I'm wondering if he installs the AMD minimal driver rather than the bundle (control panel/Relive). Might help future tracking down the actual cause of this.

I even tried reinstall windows, only install device driver and HWiNFO, it still leaks memory...
 
Thanks. Unfortunately that dump doesn't provide further clues where exactly that heap might belong to :(
 
AMD reduced second GPU sensors in 18.1.1. But still leaks...

Now there are only GPU FAN (OD5), Utilization, GPU FAN Speed (OD5), PCIe Link Speed.
 

Attachments

  • HWiNFO64.DBG
    1.8 MB · Views: 1
kenichiA380 said:
AMD reduced second GPU sensors in 18.1.1. But still leaks...

Now there are only GPU FAN (OD5), Utilization, GPU FAN Speed (OD5), PCIe Link Speed.

HWiNFO shows disappeared sensors again now... :huh:
 
Back
Top