No needs to be nervous. Just wrote my opinion and thoughts. Piranha/Barracuda aren't 3dfx products. They have own drivers, will not work with regular ones from 3dfx. You can't use them with games and so on. They use external controller and multiplex to address 3dfx chips, because of limits of address space for 3dfx. It's just design. There is not possible to direct attach 3x4MB devices to 8MB window without additional multiplex/banking. And this requires additional signal and extra cache to speedup transfers. You know electronics, you know how things work. No offense and good luck. I'll be wait for final product.

The text I posted is from the Primary Image Barracuda GLIDE driver.
You CANNOT use those GLIDE drivers through the MIPS CPU. When you're using glide drivers the 3dfx part is connected to the host CPU (as in the PC the card is plugged in). In that case, in essence, it's the same exact thing as the 4444SX, since the MIPS subsystem is completely unused.
And the same glide driver says that, which I'll post again:
"The additional TMU provides 12MBytes of texture memory.It also facilitates multi-texturing with one of the textures tri-linear filtered in a single pass."
"Alternatively, you can use single texturing and simply use the additional TMU to provide an extra 4MBytes of texture memory."

If this isn't clear, read fully the texts on the previous page, not just selectively.

I think we speak about the same thing but from 2 points of view. I speak from strictly 3dfx architecture and you from primary image. And we both can have right. Me: you can't jump out of the address space window, no mather what. You: primary image did 12MB. Then I wrote they use hacky way with copy of mem 2nd to 3rd tmu and also they have to use multiplex/banking because of limitation of address space. Then you wrote again same thing about primary image glide which in fact differs from 3dfx glide. Your previous quote "You should also link in the Glide2x3.lib file instead of the normal Glide2x.lib. This will cause the Glide2x3.dll to be used at run time." Seems this conversation goes nowhere, because both of us have right. Just different PoVs.

I'm not speaking of Primary Image architecture when talking about glide, since at that point it's just a V2 with an extra TMU. It's not using the MIPS CPU, it's not using the TEMPEST API. It's using a custom glide2x library for the extra TMU. So what's so special about this that you're not calling it 3dfx architecture? It's 3x TMUs connected to 1 FBI, connected to PCI. That's it.

"Then I wrote they use hacky way with copy of mem 2nd to 3rd tmu and also they have to use multiplex/banking because of limitation of address space"
What's the hacky part exactly? It works exactly as intended. There is no multiplexing or banking going on there. And again you're ignoring this part: Alternatively, you can use single texturing and simply use the additional TMU to provide an extra 4MBytes of texture memory.

I'm not going to talk about the 8MB window again, since you ignored what I previously posted.

"I'm not speaking of Primary Image architecture when talking about glide, since at that point it's just a V2 with an extra TMU. It's not using the MIPS CPU, it's not using the TEMPEST API. It's using a custom glide2x library for the extra TMU. So what's so special about this that you're not calling it 3dfx architecture? It's 3x TMUs connected to 1 FBI, connected to PCI. That's it."
They have different glide driver, it needs to be recompiled. Wrote about that.

"Then I wrote they use hacky way with copy of mem 2nd to 3rd tmu and also they have to use multiplex/banking because of limitation of address space"
What's the hacky part exactly? It works exactly as intended. There is no multiplexing or banking going on there. And again you're ignoring this part: Alternatively, you can use single texturing and simply use the additional TMU to provide an extra 4MBytes of texture memory.
Wrote about that. Copying 2nd tmu mem to 3rd. Or PI's own solution to use multiplex to handle 3rd tmu. It needs custom drivers.

"I'm not going to talk about the 8MB window again, since you ignored what I previously posted."
You may not, but it exists and you have to agree with this. If you wanna full access to 3rd tmu, you have access to it by window in address space. But you can't use 3x4MB in 8MB window directly, without extra signal and multiplex/buffers/cache/etc. You still ignore it.

You wrote: "On the Piranha the 3dfx part can't be directly accessed by the host PC via the PCI bus, everything goes through the MIPS CPU. Regardless, the TMUs are still connected to the FBI, and the FBI is still connected through the PCI bus to the MIPS CPU."
That's why they can use 3rd tmu, they use own drivers, they can multiplex data for 3rd tmu. This is hacky way. Don't you see this?

According above, I'm sure your 3rd tmu will never work with direct config 3x4MB and existing 3dfx drivers/tools. And because of this, your tmus are fake 12MB, because in reality they are only 8MB. Until you discover how to map it to the address space and get full control of all of them.

I've finish. I wish you great day. And again, no offense and good luck. Just make a proof you can do it, because now you just did v2 in sli + hdmi out in fancy and expensive form.

The level of selective reading you're doing is truly something.
"
That's why they can use 3rd tmu, they use own drivers, they can multiplex data for 3rd tmu. This is hacky way. Don't you see this?"
What about the Voodoo 2 based Barracuda? Where it doesn't go through the MIPS???
What about the other thing I already posted 3 times that you're still ignoring?
If your intention is to just shitpost, please do it elsewhere.

Ok. As you wish.

"The level of selective reading you're doing is truly something."
You didn't refer to my questions/conclusions too, you map your selective readings to me, however you do the same thing.

"That's why they can use 3rd tmu, they use own drivers, they can multiplex data for 3rd tmu. This is hacky way. Don't you see this?"
It's out of context, it's related to PI architecture which is different to native 3dfx. And it's true because of limit "you know where it is", which I already explained/answered.

"What about the Voodoo 2 based Barracuda? Where it doesn't go through the MIPS???"
Already answered, IP uses own drivers and 3dfx chips are internally managed, this is visible on block diagram. Beside, what is the question? Why IP card works with own drivers? Why they can use 3rd tmu? I answered it already.

"What about the other thing I already posted 3 times that you're still ignoring?"
Which questions? I think I answered them all. Even added more questions/suggestions/conclusions to you which you ignored them and never answered.

"If your intention is to just shitpost, please do it elsewhere."
Nope, it's not my intention. Just I'm curious of things what you're doing and you just can't answer.

Ok, here we go again.
While you're doing Glide on the Voodoo 2 Barracuda (not TEMPEST via the MIPS CPU) the card looks like this:

The TMUs are connected to the FBI, the FBI to the host via the PCI bus. The MIPS CPU isn't multiplexing, bank switching or doing anything regarding the 3dfx ICs. It's not even connected to the TMUs, just the FBI, via the muxed PCI bus.
And in the same driver it says this:

1.The additional TMU provides 12MBytes of texture memory. It also facilitates multi-texturing with one of the textures tri-linear filtered in a single pass.
2.This allows you to set up single pass multi-texturing with the primary texture TriLinear filtered in TMU's 1 and 2, and the secondary texture in TMU0
3. Alternatively, you can use single texturing and simply use the additional TMU to provide an extra 4MBytes of texture memory.

So the third TMU can be used , and, from what the guys at Primary Image say, 12MB texture memory is actually a thing, with a custom driver, that actually exists.

While your first post in this thread says "The excuse that new drivers are necessary aren't explain it"

So what exactly do you want?

I told you that the same document that states the 8MB window has really really major contradictions inside, and that I haven't checked the driver sources to see if the 8MB window stated there is actually 8MB. If you did this, please share.
Also, I said that I'm not sure if having an 8MB address window will actually matter in the case of the V2 architecture. I am really not convinced that having 3 TMUs with 4MB would actually require a 12MB window instead of 4MB. The FBI has a unidirectional data bus that goes to all 3 TMUs at once. There are also 2 address bits and the TMUs have a hardcoded address ID via hardware straps. You're never addressing the whole 12MB all at once through the FBI, so why would a 12MB window be required instead of 4MB?
Again, if you checked the source code, and can prove it's one way or the other, please share, I will actually highly appreciate it.

I don't mind having a constructive discussion about this, but your previous posts just state the same thing again and again (and your last post on the previous page has a really smug tone), without any proof or actual information, beside a forum post on 3dfx.pl that you linked, which doesn't actually provide any of that.