GSdx 1.0

[Serial Hacker]

If i see you asking for that again I'm going to start dishing out warnings. Stop pushing for it.

it was a joke sorry

[iMineLink]

Why people do always think that competition is better than cooperation. The issue of Intel is the mathematics not the lack of competition. Efficiently is between 0% and 100%, when you are close to 0 you  can easily get a factor 2 as improvement. When you're above 50%, it is impossible to have a factor 2 anymore (otherwise you will be above 100% ). It is the same for AMD, that why Zen will be in the same ball park as HW cpu.


When you dispatch the draw command, the command isn't executed. It is pushed in a queue. Much later when the GPU finishes its previous job, it will process it.

Normal rendering.

Code:

upload texture 1
dispatch draw 1
upload texture 2
dispatch draw 2

In reality you can upload the 2nd texture before the first draw.

Code:

upload texture 1 / upload texture 2
execute draw 1
execute draw 2

Zo2 rendering

Code:

upload texture 1
dispatch draw 1
upload texture 1
dispatch draw 2

In reality you need to wait

Code:

upload texture 1
dispatch draw 1
... wait ...
execute draw 1
... wait ...
upload texture 1
dispatch draw 2

In short, the texture cache doesn't work well with palette (at least for openGL). Some numbers from you testcase
170 frame
250K upload of palette 16 texels
250K upload of palette 256 texels
=> 250K*4*(16+256) ~~ 282MB of data. It is fairly low even for the slow PCI express port.

Instead to always reupload new palette data to the same textures, I need to creates several textures and ping-pong between them.

Could palette change be done via fragment shader?

[gregory]

Could palette change be done via fragment shader?

Well. How do you know the value to set in the palette? You still need to upload the frame from the MEM to the VRAM. There are 2 solutions
1/ Create a pool of palette texture. 1024 palette textures only consume 1MB of vram. This way upload will basically be
palette[n]
n = (n + 1) % 1024

Potentially we can create a 2nd pool for small palette (16 texels) to reduce the size of the pool.

2/ Or create a single texture buffer of size 1MB but only map a small portion to the shader. This way it might be possible to upload data n when n - 1 is used.

I don't know which solution is better neither how the driver will react. Both solution requires some massive upgrades of GSdx.

[hellbringer616]

Would this reduce the bandwidth thats needed for Snowblind games? Or is that a separate issue all together?

I just hit the water world (the pit) and let me tell you, it's SLLLLLOOOOOOOWWWWWWWWW i can get a capture if you'd like but last i knew you were aware of the issue.

Also sometimes the textures get extremely low res and the game slows to a crawl when they do. I mentioned this before but never got a GS dump (didn't know how at the time) would you like one or are you aware of it?

finally (god i type too much..) what revision fixed the snowblind games? I was planning on updating the wiki stating the issue has been resolved.

[gregory]

each games have its own issue.

Snowblind games behavior just break the hypothesis of the cache architecture. Maybe we can improve the situation with potential speed hack but it is currently a low priority.

Currently priority is
1/ stabilize my blending code.
2/ take a break and some vacations
3/ redo texturing in the shader (I'm afraid that it will cost 10% on the GPU).
4/ fork the opengl renderer into gl3 and gl4
5/ Find a way to bypass the texture cache for post processing effect
6/ optimize uniform and palette update
7/ Improve texture cache and why not think about mipmap.
....

Edit: for the commit search on github. However the fix spawn on multiple commt.

[iMineLink]

each games have its own issue.

Snowblind games behavior just break the hypothesis of the cache architecture. Maybe we can improve the situation with potential speed hack but it is currently a low priority.

Currently priority is
1/ stabilize my blending code.
2/ take a break and some vacations
3/ redo texturing in the shader (I'm afraid that it will cost 10% on the GPU).
4/ fork the opengl renderer into gl3 and gl4
5/ Find a way to bypass the texture cache for post processing effect
6/ optimize uniform and palette update
7/ Improve texture cache and why not think about mipmap.
....

Edit: for the commit search on github. However the fix spawn on multiple commt.

After eating dinner and drinking coffee I maybe get the palette issue.
Correct me if I'm wrong: the PS2 support palette switch just as NES / SNES and old GPU, so that changing color applied to a texture happens in a blink.
Now, the pcsx2 emulation does treat palette textures as 2D textures of 16 and 256 texels (in zoe2 at least).
That, mixed with the usage of OGL which does not directly has a "set palette" functionality but requires higher level operation to achieve the "color swapping" thing, makes you treating palette textures as any other 2D texture.
Now, this behavior breaks in some way the texture caching architecture (as you already said in previous post), which does not work well with constant changing (no cache benefits) of the buffer contents.
Is there a way to easily know whether a 2D texture is actually a "palette texture" from emulation calls, such as the game code asks to load some data into a different GS register?
If the answer is yes, wouldn't have it been easier if the plugin in the first time treated differently the palette from normal textures?
Pardon my ignorance on PS2 architecture but it's damn complicated...

EDIT: And I'm a bit using you as a teacher, so thanks in advance LOL

[tsunami2311]

Why people do always think that competition is better than cooperation.

Poor choice of words I guess what I really meant someone needs reason to  WANT to improve DX and in theory Improving OPENGL to the point  that DX  far behind should be enough reason to improve it cause some people are stuck having to us DX still, and I think OPENGL has already done that. But there is also nothing wrong with friendly competition/challenge on who can improve what faster either. DX just needs some love like Opengl is getting.

Any way I did some more test with FF12  the few scenes (Cutscense) I reported like prison when vann first wakes up on the floor and when Van and balither are in cell fight  and when we first see basch in cell scene no longer seem to have BLACK textures where there should be actual textures.

[dabore]

palettes

i talk gas? texture and palette are meant to be combined to be a static 32bit texture and remain in the cache. that's the quickest. caching of all 32bit permutations of the index and palettes would do the trick but potentially explode the cache for all dynamic palettes. it might work for textures that don't change. this is something to figure out. if i guess the gs memory cache is in full flux you barely see the correct memory 'windows'/offsets for textures and palettes combos to validate. if you remove the combination you have a index texture and the palette. you can cache that index texture effectively. but...

if the palettes change alot to deliver the permutations or an effect you gotta reupload them all the time. or cache them. in which way? that is some sort of way to figure. for the rendering it's a question of what type of resource to use. the bug is the constant upload of it. while a texture is used for rendering it can't be updated to assign a new palette. just a shader plug. but it doesn't want to as gregory said. if you use a bigger palette textures i dunno if you can update lines when the palette is locked.

what's the effect in zoe2 btw. optimized with lots of small textures. and the veins ... neh? a scrolling palette?

all that nice eyecandy. gotta get my fingers on it (again?).

[jonaand]

nothing about flashlight in silent hill origins yet in HW?

[refraction]

nothing about flashlight in silent hill origins yet in HW?

Did you not read the progress report on the main page or try a recent Git build?