mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-04-25 06:06:03 +03:00
[GH-ISSUE #3607] Unexpected prim type: 7 (PRIM_CONTINUE unsupported) #1494
Labels
No labels
Atrac3+
Audio
CPU emulation
D3D11
D3D9 (removed)
Depth / Z
Feature Request
Font Atlas
GE emulation
Guardband / Range Culling
HLE/Kernel
I/O
Input/Controller
MP3
Multithreading
Needs hardware testing
Networking/adhoc/infrastructure
No Feedback / Outdated?
OpenGL
PGF / sceFont
PSMF / MPEG
Platform-specific (Android)
Platform-specific (Windows)
Platform-specific (iOS)
PowerVR GPU
SDL2
Saving issue
User Interface
Vulkan
arm64jit
armjit
armv6
x86jit
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ppsspp#1494
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @unknownbrackets on GitHub (Sep 4, 2013).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/3607
http://report.ppsspp.org/logs/kind/311
Versions prior to v0.9.1-433-g2bc373e may be affected by "Read Framebuffers to Memory", but later are not.
NASCAR® at least is using this prim type.According to JPCSP it means to continue the previous one.
Recent games reporting this feature:
-[Unknown]
@unknownbrackets commented on GitHub (Nov 18, 2013):
So, it looks like the behavior of this is to continue the previous vertices. "And also." Consider the following:
The behavior of the above is identical to using this:
And omitting the second call.
The logical use case for this is when you need more than 65,535 prims I guess, or also when you want to use strip/fan prims and your buffers are disjointed (namely if you're using a ringbuffer, I guess?)
I have not tested 3D (because I'm still not sure how to make it draw on screen, heh), but I assume it works the same as 2D / throughmode.
I don't think our current implementation actually continues strips, instead starting a brand new draw. I didn't test what happens if an incomplete triangle is specified in a prim, and then "continued" in another prim, but I wouldn't be surprised if it worked.
Also, there was a game that was sending a weird number of vertices and causing crashes. It probably wasn't, but if it was using this, that might explain it.
-[Unknown]
@unknownbrackets commented on GitHub (Nov 18, 2013):
Okay, I did test and my theory is right: a GE_PRIM_LINES call with one vertex, and then a GE_PRIM_CONTINUE (as I'm going to call it) with one vertex draws a line.
Also, prim types 8 and 9 are indeed treated like 0 and 1 as expected.
-[Unknown]
@hrydgard commented on GitHub (Nov 18, 2013):
Ah! Good find. This is gonna take a bit of fiddly logic to get right though, especially if there has been a flush since the last draw I guess.
Doesn't seem to be very common though according to that reporting page...
@unknownbrackets commented on GitHub (Jun 19, 2014):
Medal of Honor Heroes is definitely affected:
http://report.ppsspp.org/logs/game/ULUS10141_1.00
Screenshot from the forum:
http://forums.ppsspp.org/attachment.php?aid=11723
-[Unknown]
@ppmeis commented on GitHub (Feb 1, 2015):
Tested with latest build. Same status.
@ppmeis commented on GitHub (Jul 25, 2015):
Tested with latest build. Same status:
@hrydgard commented on GitHub (Jul 25, 2015):
Yeah, haven't done any work in this area so that's expected. Should get around to it someday .. It's gonna be a little tricky.
@unknownbrackets commented on GitHub (May 23, 2016):
Another feature I've recently tested is what I'm going to call "immediate mode vertices" or FIFO vertices, maybe. As suspected, there are a collection of registers you can write vertex data to, and it will draw.
The only really useful way to use that is in combination with this prim type. I doubt any games are doing it, but I filtered this list from reporting of potentials:
For this register, the syntax is
(prim << 8) | alpha, I think. Writing to this register kicks off a vertex (based on the preceding register values, such as position and color.)Primitive 7 (continue) and primitive 6 (sprites) look most feasible above. The others are points, and it's hard to imagine they would draw only with one odd alpha value, although I suppose anything is possible.
Most likely, all of them are garbage.
But if we wanted to be accurate to hardware, continue's interaction with this feature would definitely be tricky / important. For example, you could issue a starting vertex directly, and then upload the rest as prim data using continue. Or the opposite.
Importantly: it doesn't seem like these registers establish "default" vertex values (e.g. if color omitted), from my tests so far. Reading from them also doesn't seem to return the most recent vertex data either (although they do retain their values when you write to them directly.)
-[Unknown]
@livisor commented on GitHub (Feb 14, 2017):
some errors from debug log on medal of honor 2(latest github build)
11:56:035 user_main W[G3D]: Common\FramebufferCommon.cpp:918 Memcpy fbo upload 04400000 -> 04000000
11:56:038 user_main W[G3D]: Common\TextureCacheCommon.cpp:377 Render to texture with incompatible formats 3 != 0 at 00000000
11:56:241 user_main E[IO]: HLE\sceIo.cpp:1873 UNIMPL sceIoChangeAsyncPriority(4, 107)
11:56:496 user_main W[KERNEL]: HLE\sceKernelSemaphore.cpp:236 sceKernelCreateSema(SNDMUTEX) unsupported options parameter, size = 167768800
11:56:499 user_main E[AUDIO]: HLE\sceAudio.cpp:263 sceAudioSetChannelDataLen(00000000, 00000200) - channel not reserved
11:56:665 user_main W[ME]: HLE\sceMpeg.cpp:1671 Audio end reach. pts: 105968 dts: 735735
12:01:572 user_main W[KERNEL]: 266e7aa46db16f98\Core/HLE/sceKernel.h:457 Kernel: Bad object handle 304 (00000130)
@hrydgard commented on GitHub (Feb 14, 2017):
None of those have anything to do with the Medal of Honor issue, it has to be some bug with how we handle some edge case in primitive drawing (DrawEngine). Also, I no longer believe that the primtype 7 is the cause of the split geometry here, though I still don't really have a good idea of the cause.
@LunaMoo commented on GitHub (Nov 1, 2017):
I just investigated MOH game(actually using 2nd one) a bit as noted in my forum post here and the issue of this game became much clearer by looking at crosshair which is also affected by same problem as geometry of the terrain, but much easier to see - it's made from 4 different draws in this sequence:
And the lower right corner was missing. When I nopped TRIANGLE_STRIP draw completely it started showing up properly, so I'm guessing TRIANGLE_STRIP continues or in some other bad way interacts with RECTANGLES prim breaking it? (edit: and yeah all "buggy" terrain uses TRIANGLE_STRIP's as well)
BTW about this issue as a whole - by title and half of it it's about PRIM type 7, but concentrates on MOH games which problems in the end doesn't seem to be related:], maybe we should just rename it or separate those two as it's a bit confusing now.:]
Edit: Managed to fix the crosshair by commenting out
github.com/hrydgard/ppsspp@2c8fb0fbd1/GPU/GPUCommon.h (L252)changing it to gstate_c.Dirty(DIRTY_RASTER_STATE); also works.
No idea why this is breaking RECTANGLE prim following TRIANGLE_STRIP prim, other glitches has only TRIANGLE_STRIP prims following other TRIANGLE_STRIP prims and wasn't affected since that code wouldn't run for them anyway, but maybe somewhere else DIRTY_VERTEXSHADER_STATE is breaking stuff:].
@unknownbrackets commented on GitHub (Nov 2, 2017):
Most of the comments on this issue are about reporting indicating games (not just Medal of Honor) using a feature that we don't support. We still don't support it (except in softgpu), and those games are still likely affected - even if only in a single scene or a certain menu.
Medal of Honor was seen to report this message (indicating it uses PRIM_CONTINUE somewhere, unless we have a bug causing it to be reported when not used.) However, this could just be in one place, and unrelated to separately experienced graphics issues - which sounds correct.
I don't know that Medal of Honor 2 was ever seen reporting this message, by the way. Have not checked.
Therefore it's a separate issue - a different underlying cause, and not related to this issue, which has been about PRIM_CONTINUE from day one.
Maybe the strip shouldn't be drawn because some vertex is meant to be outside bounds (as seen in that Romance of Kingdoms or whatever it was game.) If something is fixed by NOT dirtying state, it's a bad sign. I think we should move this to a separate issue, and it may help to validate if the softgpu experiences any issues (NOTE: softgpu supports PRIM_CONTINUE and is the only backend not affected by this, #3607.)
-[Unknown]
@LunaMoo commented on GitHub (Nov 2, 2017):
Both MOH games look about same with hardware and software rendering, actually hard to tell if anything actually differs after that new prim type was added due to general glitchiness as pretty much every other triangle in the map graphics is missing or misslocated and it is actually affected by player movement making everything a confusing mess.
I'll just reopen the oldest MOH issue referencing this to separate the issues.
@hrydgard commented on GitHub (Nov 17, 2017):
MOH has been fixed now (unrelated issue #6554 ), and the RECT/TRISTRIP switch thing is also fixed, so I'm not sure what other games might be affected by this? prim type 7 doesn't seem to be very popular.
Of course, always nice to have correct behaviour, though.
@unknownbrackets commented on GitHub (Nov 18, 2017):
Just a note: the reporting log says it uses it at some point. The assumption that it uses it commonly or in most drawing was a mistake, but it may be that it does use it SOMEWHERE.
I think that sometimes multithreading causes this to be reported incorrectly (garbage in GE lists), or something. So it will be good to see what games are reported using this in 1.5.0. There are several now that haven't since 1.2.x.
I'll note though that in v1.4.2-815-g875f70b06, Medal of Honor Heroes™ was reported as using this feature again. So it can't be that hard to find, a simple breakpoint would probably find the scene that uses it.
I'll update the issue with games believed to experience this issue (based on reporting, since I don't have any of them.)
-[Unknown]
@LunaMoo commented on GitHub (Nov 18, 2017):
Using breakpoint in d3d11 I found a few:
In MOHH1 main menu, together with some other valid draws running with texture disabled and doing absolutely nothing, I don't see any visual difference from real PSP there.
Edit: See https://gist.github.com/LunaMoo/ee1467b491a561188aeb457041065365 for a bit longer log with code around those prims.
~ Also this doesn't seem to trigger anywhere in-game, only main menu and mission map trigger it, looks same in both places and does nothing, it looks too clean to be trash data, vertices it points to only have X and Y with the latter being negative everywhere, maybe together with those other texture-less draws this is just a leftover from some experimental effect that didn't make it into final game version but wasn't completely removed from the final build.
@unknownbrackets commented on GitHub (Nov 18, 2017):
We theoretically support this in softgpu, at least validated by tests. It's possible it uses those verts for an animation, that ends up with negative Y at rest state. But you're probably right, it may just be some old feature never completely removed...
-[Unknown]
@unknownbrackets commented on GitHub (Sep 4, 2022):
We handle GE_PRIM_KEEP_PREVIOUS correctly in the software renderer, at least I think. There's also some support for immediate drawing and general hardware drawing, but both are likely fairly inaccurate.
I don't think we know of any cases caused by handling this wrong, so I'm going to go ahead and close. It's difficult to handle this properly in hardware rendering and it's not an often used feature, but we'll be able to tell from software.
-[Unknown]