Ok,
Here are some of my findings in a testscene where it works on both cpu and opencl (previous errors and crashes I posted happen on a big scene)
First test is luxcore with different settings for visibility map against cycles with and without portals
I set halt conditions for luxcore to 1 minute which results in ~500 samples and cycles is set to 1024 samples which is ~ 57 seconds
Both running in cpu+gpu mode on ryzen2700+rtx2070
scene is identical with small exception that I didn't match exactly the tile size on checker and exposure might be a little off too, but it still illustrates my points so it is close enough.
So, this is cycles without portals:
and luxcore with visibility map set to NONE:
and luxcore with default visibility map setting, SINGLE MAP
It already looks pretty bad for luxcore when it comes to direct light performance
Also note that default single map is near useless in this testscene. I build the scene this way intentionally cause I've experienced this in few production scenes already (many obstruction objects between camera and openings in interior - map won't cover complex scene). It only works in very basic setup(single opening in scene and direct exposure from that opening on objects)
This is luxcore's new cache:
and cycles with portals:
Again, not only portals are without performance penalty (luxcore's visibility cache can easily take around 1 minute to build! in semi-complex scene)
Portals also don't give artifacts (those won't go away in luxcore even after 2000 samples and they throw off intel's denoiser so the resulting render will either have noisy patches or smudgy patches in it)
And it also seems that (at least in cycles's case) portals still give cleaner results than cache even in areas where cache works!
Also, on the topic of visibility map as a whole.
this is default setting (visibility map set to SINGLE MAP)
and this is visibility map set to NONE:
Again, intentional setup of the scene, I've seen this happen again and again in product viz scenes (just hdri+object).
Visibility map cannot handle these open scenes just as it cannot handle interiors with many openings and obstructions.
What's worse it is ON by default and in blender it is away in scene environment setting (nobody would think it damages performance, I found out by accident)
So I don't know how work in progress this cache is and what can be done about it's performance and those artifacts.
But I'm gonna assume it won't get much faster and those artifacts will always show up somewhere, so in that case:
[warning: just my personal opinion, no need for pitchforks]
I would say, this visibility map while in many cases can help a bit. It needs user to do some testing to figure if it works in his case! So not so automatic in the end(in fact it's less automatic than portals at this moment).
What's worse, If I figure that in my productviz scene it is worse having it on I can turn it off. But in my complex scene I will not have a solution for bad direct light illumination at all! Half working cache is not a solution cause it's unreliable with those "patches"
So while I would prefer a fully automatic setting without caring about portals, there is no such thing in luxcore.
I would rather spend a while setting up portals in openings knowing what result to expect, than having to test in every single scene:
If the vis.map works better on or off, what mode works better, if those patches appear and do they all go away, if they go away how long it takes and is it not better to just use single map...
I'm sorry if I speak too soon and you have some solutions in the works! I'll happily re-test anything any time there's an update to this, since luxcore really needs some boost for direct lighting. (it's the last piece of the "puzzle" to make luxcore fucking fast!)