Anders Melander

Yes, interesting; Probably the place where it goes wrong. Unfortunately, I have no idea about what "Invariant" refers to. So assuming the problem lies in the MSF format (which is just a container format - a mini internal file system), I can't see anything in the MSF format that could be referred to as variant/invariant. I have reviewed the code and as far as I can tell I'm completely blocksize agnostic; Nowhere do I assume a blocksize of 4096. I have tried changing the blocksize to 8192 but that just makes the old VTune choke on the file and the new one still can't read it. I will now try to see if the new VTune can work with the PDB files that ship with the old VTune (they have a block size of 4096). If it can then the problem is with map2pdb (i.e. I'm doing something wrong). If it can't then the PDB format has changed and I'm f*cked because there's no way to know what changed. The first time around I reverse-engineered some of the format by examining the files in a hex editor and I'm not doing that again.

Ah, I see. So the 'wt' is a command you give to the debugger and it traces all calls made in the call tree? I thought the trace was something that msdia140.dll produced on its own.

With a list of TEdits? Not likely. I would go for an encapsulated TList<T>: type TSetOfStuff<T> = class private FList: TList<T>; public function Contains(const Value: T): boolean; function Add(const Value: T): integer; procedure Remove(const Value: T); function GetEnumarator: TEnumerator<T>; end; function TSetOfStuff<T>.Contains(const Value: T): boolean; begin var Index: integer; Result := FList.BinarySearch(Value, Index); end; function TSetOfStuff<T>.Add(const Value: T): integer; begin if (not FList.BinarySearch(Value, Result)) then FList.Insert(Result, Value); end; procedure TSetOfStuff<T>.Remove(const Value: T); begin var Index: integer; if (FList.BinarySearch(Value, Index)) then FList.Delete(Index); end; function TSetOfStuff<T>.GetEnumarator: TEnumerator<T>; begin Result := FList.GetEnumerator; end; etc...

...and no errors from the compiler if the asm is wrong.

I guess that's one way to remove the dependencies. I hadn't thought of that. But I would still have to clean up the remaining source and rewrite parts of it, so again: A fork. If I go that way I would probably prefer to simply start from the original, pre-JEDI, version of the source instead of trying to polish the turd it has become.

Ew! It looks like they have done a complete rewrite. No wonder it's broken. So I guess this is an example of the main problem with the PDB format: Microsoft considers it their own internal format to do with what they like. They have their own (undocumented) writer, their own reader, and no documentation.

Excellent! A few quick observations: First of all, it's strange that the error isn't logged. That would StrmTbl::internalSerializeBigMsf Lots of calls to this. I'm guessing it's reading MSF blocks and deblocking them into linear memory streams. This is probably the new code that supports the 8192-byte "big" MSF block size. MSF_HB::load Probably the code that loads the PDB tables from the memory streams. StrmTbl::~StrmTbl Lots of calls to this. Probably clean up after the load has been aborted. PortablePDB::PortablePDB Something wrong here. "Portable PDB" is the .NET PDB format. It's a completely different file format. I'm guessing it's falling back to that format after failing to validate the file as PDB.

If the block size being 4096 is the only problem (I somehow doubt that I'm that lucky) then this is the line that needs to be changed to write 8192-byte blocks: https://bitbucket.org/anders_melander/map2pdb/src/2341200827af24f7dd75cb695a668dfa9564bcf5/Source/debug.info.writer.pdb.pas#lines-225 constructor TDebugInfoPdbWriter.Create; begin Create(4096); end;

Neat. If you can spot where it gives up on the pdb file and returns an error that would be suuuuper nice. Does it produce any debug output while loading?

Yeah... Not too keen on that as a first approach. The last time I tried using the llvm pdb support as a reference I wasted a lot of time before I found out that it was very incomplete to the point of being unusable by VTune. It has probably improved but since then it's hard to tell what state it's in. https://github.com/llvm/llvm-project/issues/37279 https://github.com/llvm/llvm-project/issues/28528 I will try to see if I can reproduce and spot the problem in the source before I go down that road. Thanks anyway.

Looks like it. Ooooh, interesting. Maybe they've accidentally broken support for the older format and not noticed it because they're only testing the new format now. The article Stefan linked to makes me think that even though the PDB format supported large PDB files, the PDB reader (msdia140.dll) didn't. Otherwise, they would only have had to update their PDB writer to support large PDB files.

Doesn't really matter:

That means the bug is most likely in map2pdb because that DLL is Microsoft's API for reading PDB files.

I think that is a generic error message meaning "Something went wrong and our error handling sucks". As far as I remember you get a message like that regardless of what problem VTune encounters when resolving through the PDB file.

I meant what do you mean by this ^ Do you mean 32- vs 64-bit addresses? AFAIR there's no choice or ambiguities in the PDB format with regard to the size of an address value, relative or absolute, but I would have to take a look at the source to make sure.

Maybe at least reformat it into two distinct columns {$IFDEF DELPHIAVX}vpshufb ymm1, ymm0, [r9 + TAVXEncodeConst.Lut0];{$ELSE}db $C4,$C2,$7D,$00,$49,$20;{$ENDIF} {$IFDEF DELPHIAVX}vpand ymm2, ymm1, [r9 + TAVXEncodeConst.Mask0];{$ELSE}db $C4,$C1,$75,$DB,$51,$60;{$ENDIF} {$IFDEF DELPHIAVX}vpand ymm1, ymm1, [r9 + TAVXEncodeConst.Mask2];{$ELSE}db $C4,$C1,$75,$DB,$89,$A0,$00,$00,$00;{$ENDIF} {$IFDEF DELPHIAVX}vpmulhuw ymm2, ymm2, [r9 + TAVXEncodeConst.Mask1];{$ELSE}db $C4,$C1,$6D,$E4,$91,$80,$00,$00,$00;{$ENDIF} {$IFDEF DELPHIAVX}vpmullw ymm1, ymm1, [r9 + TAVXEncodeConst.Mask3];{$ELSE}db $C4,$C1,$75,$D5,$89,$C0,$00,$00,$00;{$ENDIF} {$IFDEF DELPHIAVX}vpor ymm1, ymm1, ymm2;{$ELSE}db $C5,$F5,$EB,$CA;{$ENDIF} Like this: {$IFDEF DELPHIAVX} vpshufb ymm1, ymm0, [r9 + TAVXEncodeConst.Lut0]; {$ELSE}db $C4,$C2,$7D,$00,$49,$20;{$ENDIF} {$IFDEF DELPHIAVX} vpand ymm2, ymm1, [r9 + TAVXEncodeConst.Mask0]; {$ELSE}db $C4,$C1,$75,$DB,$51,$60;{$ENDIF} {$IFDEF DELPHIAVX} vpand ymm1, ymm1, [r9 + TAVXEncodeConst.Mask2]; {$ELSE}db $C4,$C1,$75,$DB,$89,$A0,$00,$00,$00;{$ENDIF} {$IFDEF DELPHIAVX} vpmulhuw ymm2, ymm2, [r9 + TAVXEncodeConst.Mask1]; {$ELSE}db $C4,$C1,$6D,$E4,$91,$80,$00,$00,$00;{$ENDIF} {$IFDEF DELPHIAVX} vpmullw ymm1, ymm1, [r9 + TAVXEncodeConst.Mask3]; {$ELSE}db $C4,$C1,$75,$D5,$89,$C0,$00,$00,$00;{$ENDIF} {$IFDEF DELPHIAVX} vpor ymm1, ymm1, ymm2; {$ELSE}db $C5,$F5,$EB,$CA;{$ENDIF} or even better: {$IFDEF DELPHIAVX} vpshufb ymm1, ymm0, [r9 + TAVXEncodeConst.Lut0]; {$ELSE}db $C4,$C2,$7D,$00,$49,$20;{$ENDIF} {$IFDEF DELPHIAVX} vpand ymm2, ymm1, [r9 + TAVXEncodeConst.Mask0]; {$ELSE}db $C4,$C1,$75,$DB,$51,$60;{$ENDIF} {$IFDEF DELPHIAVX} vpand ymm1, ymm1, [r9 + TAVXEncodeConst.Mask2]; {$ELSE}db $C4,$C1,$75,$DB,$89,$A0,$00,$00,$00;{$ENDIF} {$IFDEF DELPHIAVX} vpmulhuw ymm2, ymm2, [r9 + TAVXEncodeConst.Mask1]; {$ELSE}db $C4,$C1,$6D,$E4,$91,$80,$00,$00,$00;{$ENDIF} {$IFDEF DELPHIAVX} vpmullw ymm1, ymm1, [r9 + TAVXEncodeConst.Mask3]; {$ELSE}db $C4,$C1,$75,$D5,$89,$C0,$00,$00,$00;{$ENDIF} {$IFDEF DELPHIAVX} vpor ymm1, ymm1, ymm2; {$ELSE}db $C5,$F5,$EB,$CA;{$ENDIF} Unreadable code is unmaintainable.

Please elaborate

This might help: https://www.intel.com/content/www/us/en/developer/articles/troubleshooting/older-version-product.html Please create an issue at the repository: https://bitbucket.org/anders_melander/map2pdb/issues/new The problem is most likely caused by msdia140.dll; The library VTune uses to read pdb files. You can try replacing the one that VTune installs with an older version. See:

There are many ways. What have you tried so far?

It doesn't matter. You are still not blending anything. Look, please forget about the alpha and just set it to 255. Even if alpha was somehow involved in what you are doing you are really not ready to deal with that part yet. Yes, but the code you posted does nothing in itself. It may very well be that you removed some parts that actually do something before you posted it, but I'm not a psychic and I can't guess what it originally did. Anyhow, moving on... Yes, it does. You are using the TImage32 control from the Graphics32 library to display the bitmaps. One approach would be to keep a copy of the bitmap you are fading from or to and then construct the bitmap to be displayed from that. However, I think we have by now established that you can't figure out how to do that. So I suggest you simply do this instead: // Set these values somewhere. // For example the place where you create the TImage32. // Make the background black fScreenImg.Color := clBlack; // Have the bitmap blend with the background color fScreenImg.Bitmap.DrawMode := dmBlend; ... // Fade out for var i := 255 downto 0 do begin fScreenImg.Bitmap.MasterAlpha := i; fScreenImg.Update; Sleep(50); end; // Load the new bitmap here fScreenImg.Bitmap.LoadFromFile(...); // or whatever... // Fade in for var i := 0 to 255 do begin fScreenImg.Bitmap.MasterAlpha := i; fScreenImg.Update; Sleep(50); end;

You don't need the alpha channel. The alpha is only needed when you later have to blend stuff together and that is not what you are doing. You are just "removing color" until only black is left. You haven't shown how exactly you draw stuff onto the screen so that is hard to answer. Generally, I would say that you need a temporary bitmap since it's dead slow to draw individual pixels one at a time. I don't know what this is supposed to illustrate since it doesn't do anything but once again: TColor32 is a DWORD (4 bytes) which is meant to contain the R, G, B and A channels simultaneously. You seem to think it represents a single channel.

Btw, I don't know if the following is relevant to what you're doing: https://blog.grijjy.com/2021/01/14/shader-programming/

GDI+ is generally not a fast library... Okay. I guess I'll take your word on that since you've actually tried it and I'm only speculating, but I would really expect a significantly higher FPS (on a "reasonably" sized screen) to be possible without hardware assist. I mean, what did we do before we got access to the GPU? Again, I'm not arguing that the GPU isn't the faster solution. I'm just surprised that it's necessary. Can you remember what bitmap size and resampler type you used when you tried this with Graphics32 (if that was what you used)? Now that I think of it, that was a brain fart on my part; It's OR-ing. I was thinking that since it's dropping black pixels it must be AND-ing but of course, since black isn't a color but rather the absence of color, it's the other way round. It's OR-ing so white $xxFFFFFF is replacing black $xx000000.

A, R, G and B are bytes. TColor32 is a dword (i.e. 4 bytes). It can be cast to a TColor32Entry, which is a record containing the 4 ARGB bytes. Value needs to be a "floating point" type. E.g. Single or Double. And the you cannot use Inc() on it. If you want to iterate using an integer value then you need to do a division somewhere so you get a value between 0 and 1 that you can multiply the RGB values with. Like I did here: This doesn't do anything. What did you expect it to do?

That's the ColorModulate function; It "fades" from any color to any color. In your case, you would fade each pixel from black to the color of your new image. Or if you absolutely must have a FadeFromBlack function: // Value = 0: Black // Value = 1: Color function FadeFromBlack(Color: TColor32Entry; Value: Single): TColor32Entry; begin Result.A := Color.A; // Probably 255 Result.R := Round(Color.R * Value); Result.G := Round(Color.G * Value); Result.B := Round(Color.B * Value); end; Apply this to each pixel of your "to" bitmap and draw the resulting bitmap on top of whatever you have on the screen.