Taronites

...nice one, thankfully I ain't no crybaby!

hope somebody could post the results, meanwhile what people think about this?
https://wccftech.com/geforce-rtx-2080ti ... 070-chips/

Not sure, but I imagine that NVidia wouldn't let something like this slide for long. They have no benefit from such a failure, especially with such an expensive card.
I don't know what people were saying about my GTX 970, but it was fairly cheap and still rocks my world and I'm super happy! Anyway...I'm a bit skeptical when it comes to such devastating reviews, since it's an ugly world out there, you know.

RX Vega 64 LC here.

So at 3840x2160 (4k, 16-9 aspect ratio)

I am able to get 3 fully fluid layers saved and opened, but on the fourth I get an error upon trying to open it. "EXCEPTION_ACCESS_VIOLATION"

EDIT: Interesting HBCC results, at first since I didn't see a noticeable difference I thought HBCC made no difference but I have found one. Using HBCC allows me to load the file with 4 full liquid+Blend etc layers, without HBCC it will only do 3. However HBCC does NOT allow me to go to 5-6 or more, It seems to allow 4 but not more. GPU usage with 4 layers is only showing 2.5gb Vram Usage when the file is Open.
in theory HBCC should essentially let the program use 24gb worth of what it would consider to be Vram on my system 8GB+16GB, but I think the error it throws has to have a bottleneck somewhere else, although it would appear that simple dedicated GPU memory makes a clear difference, but then again you have the 1080/1080 ti claims.

Without HBCC at 5k 5120x2880 the Program is black after loading a file with just 1 layers, and gives the violation error when attempting to save a second layer.
Same Results with HBCC at 5k

1 Layer

---

4000x4000-Doesn't save

3500x3500-Saves but loads up Black

3200x3200-Saves and loads just fine

---

2 Layers

3200x3200-Saves but loads up Black

3000x3000-Saves and loads just fine

-

3 Layers

3000x3000-Saves but loads up Black

2800x2800- Saves and loads just fine

-

4 Layers

2800x2800- Saves and loads just fine
---
^HBCC made no difference in these tests

PS: I did these tests because someone asked me to on the AMD forums, I'm loving the program and posted a image of what I made with it on the first doodles thread.

HA! This is VERY interesting! I could imagine what the problem is....and it's a dumb one. I'd have to free CPU memory along the way, because Verve is currently still on 32bit, having a 2.5Gb memory limit. OMG, I didn't even think of that being a problem during loading, but, yeah... it might very well be and would explain a lot.
Those are some excellent tests, Patriot, thanks a heck of a lot, fantastic!

UH, gotta jump on the gallery thread right away! WELCOME TO THE FORUM, I'm very happy you came over!!!

uhrm uhrm
I did some research Taron xD all good be done for Verve xD
Good to see you joined the forum "patriot", I was about to reply once more to your reply and invite you here but the AMD admin had to check my post before it was uploaded.
https://community.amd.com/thread/233561
anyway, many thanks for the great AMD Vega 8gb info, and a huge welcome to the forum.

Taron I wonder if there would be a bottle neck with the NVIDIA 2080 and 2080ti due to Verve being a 32bit software.
on the other hand if Verve could manage to handle all that 24gb of AMD vram, it would take Verve to new boundaries.

PD: "patriot" it's me from the AMD forum question, my name is Eduardo Bedoya.

32bit only refers to CPU memory usage, not GPU. So, only what has to go through RAM will be a concern, but ordinarily almost all memory matters regarding Verve are GPU related. It's about saving and loading, that's all. I will have to carefully deal with memory blocks, that's all.

nvidia 1080 test
4 Layer 4000x4000 loade and save ok

temperature of cpu 45
temperature of gpu 82
the test lasted a moment, because why would I want to scorch the components



I'm working at 3888x3888, usually on one layer
if there are more of them for a moment
and I merge them down

thx for the update Pud, was its speed workable at that resolution?
btw
In the AMD forum people were very kind to support my post...
https://community.amd.com/thread/233561
but today I was very surprised to see the respond I got from the the NVIDIA forum D: ...
https://forums.geforce.com/default/topi ... 20-series/

Some people just aren't cut out for public exchange. Don't let that reflect badly on NVidia. I'm pretty sure the problem is, that NVidia users think it has less to proof. ...pity you had to run into the "bad boy" over there right away.
ANYWAY, those AMD forum users are very nice, though. And thank you very much for posting this there!
I've had my revelation already, though, regarding the saving and loading. It has much less to do with the card than with the RAM and my management of it. I'll have to figure out a way to break things down into smaller chunks during loading, because of the 32bit restriction of BlitzMax. If I figure out how to write a tablet mod for 64bit, I could use BlitzMax NG to compile for 64bit right away. ...no luck, yet, though.

As for SLI, I still can't tell, if SLI requires the software to do something specific. There are different modes for it, but I would assume that the workload sharing has some automation that doesn't require the software to even know about it. SO...unless you have tested it yourself, you probably shouldn't talk about SLI at all or make claims regarding it. You may very well be right, but unless you know for sure, it's a bold thing to do.
Read this:
https://en.wikipedia.org/wiki/Scalable_Link_Interface