trx40 [Discussion] - TRX40 Bare Metal - Vanilla Patches

[Driftwood]

VIDEO ENCODING BigSur Tests

35000 bitrate HEVC 10-bit Encode from 10-bit Apple Pro Res Raw 4444

 

Just been going thru all the available video encoding on Big Sur and it appears that Adobe Media Encoder is the fastest encoder of them all - encoding twice the speed of frame rate. Apple's Compressor for some reason is not making use of Metal and CPU only but it was very slow and I need to look into that as Im sure it should work. Handbrake only uses CPU for HEVC 265 10-bit and processed footage in slightly above realtime fps.

 

@fabiosun Ill do some new bench tests for your question.

 

Edited September 5, 2020 by Driftwood

[fabiosun]

3 minutes ago, iGPU said:

 

Yes, what I presented above is BS ß6 (public release 2), released this past week. I've seen no difference from BS ß2 thru ß6.

Sorry igpu I mean a comparative benchmark in Big Sur bare metal and proxmox

i see you did in Mojave’s for proxmox but I am on my mobile and I could be wrong 

if so sorry tomorrow I will check again

[Driftwood]

I can't seem to get CB15 working still in BS. Only 20 works for me unless someone has a reliable CB15 link which works for them?

[fabiosun]

I have pu here a working dmg

see in this thread

https://we.tl/t-7kAdUC6NBC
@Driftwood try this

[Driftwood]

Okayish... This is Big Sur beta 6 (Prox to come)

Im running on standard BIOS RAM setups not Performance if that matters...!? Plus I had a few apps running inc safari 🙂

 

Edited September 5, 2020 by Driftwood

[iGPU]

Just now, fabiosun said:

Sorry igpu I mean a comparative benchmark I Big Sur bare metal and proxmox

i see you did in Mojave’s for proxmox but I am on my mobile and I could be wrong 

if so sorry tomorrow I will check again

 

You are correct on this point: C15 VM test was in Mojave, not BS. But with tests other than C15 (which I often do not run), I've seen no difference amongst Mojave, Catalina or Big Sur.

 

The small variations I've seen on-line, I believe, are simply statistical variations due to uncontrolled testing situations. Example: on my computers, 've seen variations in test results with how long the computer has been turned on, what background apps were running, and if the computer was left un-touched during tests. This says nothing of BIOS settings, DDR4 speeds, mobo variations, etc. So unless a standardized approach is taken (which is not practical) most results are probably not significantly different even in a range of ±5%.

[ckrueger99]

I'm specking out a  TR-39070X build on the Zenith II Extreme Alpha, as described in my signature below. Will be used mainly for video editing/rendering, using FCPX and After Effects. I notice that, out of 14 commenters on this thread, only one, Asus fanboy @valmeida, uses this motherboard. Aside from the ASMedia SATA controller, which I probably won't be using, are there reasons related to Hackintoshing that I should be dissuaded from using this board?

[fabiosun]

@ckrueger99in my opinion your is the best available motherboard 

I like it as I like gigabyte designare ex..

for ASMedia I think you can try some kext 

but not tested by me

[Driftwood]

3 hours ago, fabiosun said:

my opinion your is the best available motherboard 

Hum.... The cheapo Asrock's alright! Does the job 😉

[meina222]

@fabiosun,

 

Here's my OpenGL CB 15 on BS bare metal + stock reference 5700XT

 

[meina222]

On 8/12/2020 at 3:25 PM, iGPU said:

 

When you try the SSDT files, I would create an EFI on a USB card, placing your bootable EFI folder on it. Then add the new SSDT's and boot from it. That way, if there is a problem, you can more easily isolate and have an alternative way of getting into Catalina bare metal.

 

***

 

fabiosun,

 

please try this TB-SSDT to see if it helps USB functionality.

 

 

 

@iGPU - could you please help me with the TB SSDT. I tried to attach UPSB to _SB.SOD2.D2A2, but after I reboot nothing seem to change in my IOReg. I posted both SSDT I tried (with customized ROM) and IOReg in @fabiosun's TB thread. I tried to look back yours for reference to this post, but I no longer see the file.

 

Thank you!

[fabiosun]

3 hours ago, meina222 said:

@fabiosun,

 

Here's my OpenGL CB 15 on BS bare metal + stock reference 5700XT

 

 

interesting would be a comparison with your VM result if you have

thank

goal of this request is to compare

GPU in Bare metal with all patches

GPU in bare metal with a minimal set of patches (not advised by algrey)

GPU in a VM environment (ie Proxmox)

 

 

[meina222]

I will try VM in a few hours as I'm about to sign off. Here's the reduced set of Kernel patches in BS metal (matching @Driftwood's config). For some reason, I see big jump.

 

[fabiosun]

Thank you meina222 for now using a minimal set of patches is not advised by people who discover / maintain them

so our bleeding edge hardware is also more in a deeper bleeding edge

on the other hand, if we hadn't tried everything we wouldn't be here talking about it .. or not? 🙂

If with Proxmox you have the same results it is another important step and now only to understand if it is stable or not

 

5700xt seems to have a better support for now than radeon VII with old application in Big Sur (also your all 64 cores whiteout HT could be a key)..and this too can be a key to understanding

[fabiosun]

10 hours ago, Driftwood said:

Hum.... The cheapo Asrock's alright! Does the job 😉

yep but VRM and others quality hardware on it could be the difference

however not for our task

 

When I have set my system in Italy was available only MSI trx40 Pro 10 g with next delivery day option..It was on 4 December 2019....

My first choice was on Gigabyte designare ex (not available in that period)

Happy for my choice 🙂

 

[Driftwood]

The only problem with going virtualized is the clock and timings. This is critical for audio and video apps. 

This is why I still run both, and BM is of course best for timing. 

For Penryn compatability and using all intel_memset.A compiled stuff, Proxmox is best. 

The patches (or rather layer removers) for Photoshop and Davinci in BM are okay but not so ideal a workaround. 

Personally, I would like lilu to be improved more with patches to do intel compiled spoofing to use intel_memset.V etc...

 

this is what u pay for either side

 

🙂

Edited September 6, 2020 by Driftwood

[Driftwood]

@fabiosun and anyone else who wants to see or use my working EFI folders together with config.plists. If you try, simply edit the Platforminfo UUIDs as usual.

Also please check if you receive relinked errors either way (ie your Library/Extensions folder has matching kexts or older kexts in these EFIs match L/E - as  you may have to update your kextcache kernel cache properly to get these working.

For Proxmox you will need to sort out your MMIO, vm.conf, vfio.conf and bl'cklists.

 

Here's the EFI folders:-

 

Proxmox Catalina

Driftwood Proxmox - Catalina EFI FOlder.zip

 

 

Proxmox Big Sur (last used on beta 2)

Driftwood Proxmox - Big Sur EFI Folder.zip

 

 

Bare Metal Catalina

Driftwood Catalina Bare Metal EFI Folder.zip

 

 

Bare Metal Big Sur (works on beta 6)

Driftwood Big Sur Bare Metal EFI Folder.zip

Edited September 6, 2020 by Driftwood

[meina222]

Here is the VM score. VM EFI booting into the bare metal NVMe installation. Consistent with previous marks, except for the outlier scored in the Bare Metal with "reduced" patches (dark orange vs bright orange). The 144 fps score seems anomalous. What is the story with the set of reduced patches and why are they "not recommended"?

 

[Pavo]

15 minutes ago, meina222 said:

Here is the VM score. VM EFI booting into the bare metal NVMe installation. Consistent with previous marks, except for the outlier scored in the Bare Metal with "reduced" patches (dark orange vs bright orange). The 144 fps score seems anomalous. What is the story with the set of reduced patches and why are they "not recommended"?

The story is from me, I decided to try and reduce the amount of kernel patches applied for AMD system and simply did a test of disabling one patch at a time and seeing if I could boot and checking my WoW game performance. Once I got to the point of my WoW game performance was like it should have been from the beginning I stopped reducing the patches. The reason they are not recommended is because it is not consistent across all AMD systems on what patches can be removed and provide the GPU gaming performance increase.

[Driftwood]

Latest OC061 Commits Config manuals and differences pdfs. Release version should be tomorrow (Pavo).

 

 

OC061 Latest Commits manual and Differences.zip

[iGPU]

FYI.

 

I have worked for hours trying to sort out why I could not get Shutdown to properly work. I won't even list all of the things I investigated (but they involved BIOS, ACPI, kexts, DevProp, MMIO and other OC settings). Shutdown would work perhaps 1/10 times; just enough to tease and lead me in one direction and then another.

 

I finally found the source of the problem. It was my keyboard (here). It was triggering the panic reboots. Once the keyboard was removed, Shutdown began working well (Sleep is also working).

 

Bottom line: remember to check hardware issues when things aren't working as expected.

 

[fabiosun]

@all

I would clarify a thing...we have done this experiences also in Proxmox if you see my boost increase performances when I was touching TSC stuff related..

so deleting some TSC stuff could give benchmark increments..some time big improvement

 

Pro application do not benefit for this

My personal opinion is it is placebo medicine for our desire to improve performance, but I can't see real benefit in application I use

however I am happy people try also this way, maybe it could help to improve patches creation

 

My "not advised" message sense is:

no all people are skilled as some of you

Some times when I have talked about mmio, people with other system or also platform took mine..thinking it was the same for all

Also Dortania guide write to use two MMIO like all of us (trx40 owner) have that MMIO (NOT TRUE)

 

So touching patches without knowing the meaning of them could be risky

And for this people involved in patches development  does not recommend to use in a different way

 

only my two cents about it

😉

 

[Pavo]

@fabiosun I would agree with you but the kernel patches they provided are based off what they added back in the day to compile a kernel for AMD specifically when they were using Clover. It is always good to validate what patches are needed or not needed in my opinion. I have had tons of discussions this with algrey and Shaneee before to get a better understanding of exactly what each individual kernel patch is doing. There are quite a few patches that are applied simply to avoid a kernel panic on certain function calls that was being produced back in 10.12 era. They simply apply the same methodology on every update instead of going through each new kernel to get the bare minimum kernel patches needed.

[fabiosun]

@Pavo you are a pretty skilled user

 

not all have your skill

from December I was talking with algrey and testing stuff he Kindly proposed

the word I said before are a his thought and he could confirm to you if you are in touch

 

Agree we have to test, if I didn't test we all stay here to wait a new telenovelas video of the "queen of hackintosh"..and we would know zero about how to do..

 

but TSC stuff is complex..

then..seen only min/max on patches description is possible to understand where there patches are useful or not

 

for others:

17 mean high sierra

18 means mojave

19 means catalina

20 means big sur

 

so min 17

max 20.xx

means used if set to yes from high Sierra to Catalina 

min 17

max 18

used on high Sierra and Mojave

and so on!

 

 

[Pavo]

12 minutes ago, fabiosun said:

for others:

17 mean high sierra

18 means mojave

19 means catalina

20 means big sur

This is correct. 

13 minutes ago, fabiosun said:

so min 17

max 20.xx

means used if set to yes from high Sierra to Catalina 

This is incorrect Min 17.x.x with a Max of 20.x.x means used if set to enabled (yes) from High Sierra to BigSur. Not Catalina