Recent

Author Topic: BGRABitmap and 64bit  (Read 10462 times)

Michl

  • Full Member
  • ***
  • Posts: 226
BGRABitmap and 64bit
« on: May 30, 2016, 08:50:07 am »
Hi,

I tried to compile the Trunk BGRABitmap (revision 1246) package BGLControls for a 64bit Windows and 64bit Debian, both with no success (32bit work just fine). The compilation stops at the unit BGRAFilters: bgrafilters.pas(1148,40) Error: Can't determine which overloaded function to call

The problem is the typecast of NativeUInt and abs():
Code: Pascal  [Select][+][-]
  1. {$ifdef CPU64}
  2.   PtrUInt = QWord;
  3. {$endif CPU64}
  4. ...
  5.   NativeUint = PtrUint;    
  6. ...
  7. function FilterEmboss(bmp: TBGRACustomBitmap; angle: single; ABounds: TRect; AStrength: integer; AOptions: TEmbossOptions): TBGRACustomBitmap;
  8. var
  9.   redDiff: NativeUInt;
  10. ...          
  11.   tempPixel.alpha := min(255,abs(redDiff-128)+abs(greenDiff-128)+abs(blueDiff-128)); // <-- abs can't handle a QWord

And it seems to be a feature: http://bugs.freepascal.org/view.php?id=16177

So my questions are:
Is BGRABitmap only supported for the usage in 32bit systems?
Is there a workaraound to compile it for 64bit?
Is there a mistake from my side?
Code: [Select]
type
  TLiveSelection = (lsMoney, lsChilds, lsTime);
  TLive = Array[0..1] of TLiveSelection;

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: BGRABitmap and 64bit
« Reply #1 on: May 30, 2016, 10:36:29 am »
NativeUINT and PtrUINT are already defined for cpu64 platforms. No need to do that by hand. If these slightly differ then that might be the cause. (e.g. type  xxx = type yyy; differs from type xxx = yyy;) And that can make a big difference for the compiler to determine overloads.
Specialize a type, not a var.

Michl

  • Full Member
  • ***
  • Posts: 226
Re: BGRABitmap and 64bit
« Reply #2 on: May 30, 2016, 10:46:56 am »
Sorry for misleading (my native language isn't english).

NativeUINT isn't redefined by BGRABitmap. It uses the FPC typecasts. I only want to show, where the problem is (I simply copied the typecasts, to show that for 64bit a NativeUINT is a QWord).

For 32bit, there is no problem, cause Abs(SomeNativeUINT - SomeInteger) is the same as Abs(SomeDWord - SomeInteger) and it is imho interpreted as Abs(SomeInt64). See posted bugreport link.
« Last Edit: May 30, 2016, 10:53:28 am by Michl »
Code: [Select]
type
  TLiveSelection = (lsMoney, lsChilds, lsTime);
  TLive = Array[0..1] of TLiveSelection;

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: BGRABitmap and 64bit
« Reply #3 on: May 30, 2016, 11:44:13 am »
[Edit] It was me adding the paraphrased code and correcting the error..[/edit]
Code: Pascal  [Select][+][-]
  1. function FilterEmboss(bmp: TBGRACustomBitmap; angle: single; ABounds: TRect; AStrength: integer; AOptions: TEmbossOptions): TBGRACustomBitmap;
  2. var
  3.   redDiff: DWORD;// or longword or even cardinal. Don't use a Native type when you mean a 32bit type.
  4. ...          
  5.   tempPixel.alpha := min(255,abs(redDiff-128)+abs(greenDiff-128)+abs(blueDiff-128)); // A QWord is wasting space here and should be a 32bit unsigned type

Yes, but even on a 64bit processor it is debatable if it simply should not be declared as longword,  or cardinal, instead of the Native width of the processor. After all: it is just a 32bit calculation, also on a 64bit OS. I think it is wrong in this place to try to use a qword for the operation that is intended: it is a dword, longword or even cardinal type.

Furthermore, when using a 64bit type you are also hampering the compiler with its optimizations: it is prevented from using packed dwords and instead needs to allocate a full qword. Since a 64bit compiler optimizes/can optimize for SSE(x) you ask for sub-optimal code generation. Not a very smart thing to do ...;) O:-) And especially not with graphics... >:D Under MMX/SSE code you also miss out on saturation.

To the BGRAbitmap maintainer(if this code really stems from BGRA code..) : Why? It is silly...
« Last Edit: May 30, 2016, 06:41:40 pm by Thaddy »
Specialize a type, not a var.

tetrastes

  • Sr. Member
  • ****
  • Posts: 473
Re: BGRABitmap and 64bit
« Reply #4 on: May 30, 2016, 02:30:54 pm »
I successfully compiled and used BGRAbitmap 7.9.3 and 8.7 with some source editing under Debian 7 64 bit and now 8.8.4 under Debian 8 64 bit.
So I downloaded 8.9 and 8.9.1. Though this error and later issue with DoExecuteNormal in the bgrafilters.pas are easily corrected, in bgrascenetypes.pas I've got

630 procedure TCustomRenderer3D.SetProjection(const AValue: TProjection3D);
631 begin

bgrascenetypes.pas(631,1) Error: Internal error 2012090607 

632  FProjection := AValue;
633  FProjectionDefined := true;
634 end;

And I don't know what to do with that.
So I remained with old good 8.8.4.
I don't know what are new features in 8.9, but may be your program will work with 8.8.4.

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: BGRABitmap and 64bit
« Reply #5 on: May 30, 2016, 02:57:25 pm »
I successfully compiled and used BGRAbitmap 7.9.3 and 8.7 with some source editing under Debian 7 64 bit and now 8.8.4 under Debian 8 64 bit.
So I downloaded 8.9 and 8.9.1. Though this error and later issue with DoExecuteNormal in the bgrafilters.pas are easily corrected, in bgrascenetypes.pas I've got

630 procedure TCustomRenderer3D.SetProjection(const AValue: TProjection3D);
631 begin

bgrascenetypes.pas(631,1) Error: Internal error 2012090607 

632  FProjection := AValue;
633  FProjectionDefined := true;
634 end;

And I don't know what to do with that.
So I remained with old good 8.8.4.
I don't know what are new features in 8.9, but may be your program will work with 8.8.4.

What editting? Provide that plz? This is distraction for the issue at hand: a wrong declaration of a type fundamental to the librarry's performance.
Unless you edited that type, that is ;) I explained in detail what the issue boils down to.
« Last Edit: May 30, 2016, 02:59:31 pm by Thaddy »
Specialize a type, not a var.

tetrastes

  • Sr. Member
  • ****
  • Posts: 473
Re: BGRABitmap and 64bit
« Reply #6 on: May 30, 2016, 03:09:41 pm »
If you mean editing in 8.9 version, then

function FilterEmboss(bmp: TBGRACustomBitmap; angle: single; ABounds: TRect; AStrength: integer; AOptions: TEmbossOptions): TBGRACustomBitmap;
var
  redDiff, ...: DWord;

as you explained :).
I don't see any troubles doing so.
In previous versions there was other code for this function and no issue.
I forgot to mention that I used stable releases of Lazarus 1.4.x FPC 2.6.4 and now 1.6.0 FPC 3.0.0 (amd64 Debian packages)
« Last Edit: May 30, 2016, 03:16:49 pm by tetrastes »

Michl

  • Full Member
  • ***
  • Posts: 226
Re: BGRABitmap and 64bit
« Reply #7 on: May 30, 2016, 03:46:09 pm »
Provide that plz
To get it start isn't a big deal (patch added - works for me on 32 and 64bit) but the maintainer should have a look at it, if it is correct.

I was just a little bit confused, cause I thought, that trunk package is used often, so it was tested on 64bit before?!
« Last Edit: May 30, 2016, 03:59:29 pm by Michl »
Code: [Select]
type
  TLiveSelection = (lsMoney, lsChilds, lsTime);
  TLive = Array[0..1] of TLiveSelection;

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: BGRABitmap and 64bit
« Reply #8 on: May 30, 2016, 06:03:19 pm »
You do not need to add a patch as this was clearly an oversight by the developer. Feel free to submit it though. Then it won't be ignored. And this is the wrong place. Try bugs.freepascal.org.
I just read the code, didn't even have to compile it to find this bug.
What's needed is 32 bit, not native resolution. So, indeed, like the last two posts and my example, it needs to be a dword, longword or maybe for backwards Delphi a cardinal.
Specialize a type, not a var.

lainz

  • Hero Member
  • *****
  • Posts: 4460
    • https://lainz.github.io/
Re: BGRABitmap and 64bit
« Reply #9 on: May 30, 2016, 06:10:55 pm »
This is the correct place for the bug, is the forum of the package (Thread was moved by a forum moderator / admin).

Bugs.freepascal.org is for lazarus fpc and packages included in lazarus, is not the case.

Just wait circular or PM him to solve this. Seems easy to solve, also I can access the repository to write the files but better he solves it as he want.

BGRABitmap is supposed to work in 64 bit systems, maybe just this is the only thing that doesn't work now, but also LazPaint is published at 32 and 64 bits.

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: BGRABitmap and 64bit
« Reply #10 on: May 30, 2016, 06:20:33 pm »
Well, Circular has a very very good reputation in the speed in which he solves bugs and resolves issues!
So I am sure he reads this and picks it up. I thought it was mainstream already ;) (I am Hardcore FPC only ;) )
@Circular: can you read reply #3, plz? Because I am not sure YOU made that mistake.
« Last Edit: May 30, 2016, 06:38:34 pm by Thaddy »
Specialize a type, not a var.

lainz

  • Hero Member
  • *****
  • Posts: 4460
    • https://lainz.github.io/
Re: BGRABitmap and 64bit
« Reply #11 on: May 30, 2016, 06:46:57 pm »
Well, Circular has a very very good reputation in the speed in which he solves bugs and resolves issues!
So I am sure he reads this and picks it up. I thought it was mainstream already ;) (I am Hardcore FPC only ;) )
@Circular: can you read reply #3, plz? Because I am not sure YOU made that mistake.

Well he is the only one that edit bgrabitmap sources, I contributed maybe only one procedure long time ago (TextShadow) and a class that was rewritten almost at all by circular (the class that do the slice scaling).

And what's the problem about making mistakes, is just normal and maybe it was not tested under 64 bits (I've reported to circular other bugs in lazpaint that appeared only under 64 bits, so it's not the first time) but I don't see the problem, is reported then fixed and that's all  :)

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: BGRABitmap and 64bit
« Reply #12 on: May 30, 2016, 07:08:15 pm »
@lainz:
I never said anything about a problem with mistakes. I have a problem with them in the sense that I hate people who "forget"  to put me right when I make a mistake. (To the extend that if this happened more than once, often, I fired them. True story. Over MY mistakes. That nobody told me about... And cost a lot of man hours and money to correct)

I am sure this will be resolved in no-time. That's all  ::) 8-)
« Last Edit: May 30, 2016, 07:12:18 pm by Thaddy »
Specialize a type, not a var.

lainz

  • Hero Member
  • *****
  • Posts: 4460
    • https://lainz.github.io/
Re: BGRABitmap and 64bit
« Reply #13 on: May 30, 2016, 07:45:01 pm »
@lainz:
I never said anything about a problem with mistakes. I have a problem with them in the sense that I hate people who "forget"  to put me right when I make a mistake. (To the extend that if this happened more than once, often, I fired them. True story. Over MY mistakes. That nobody told me about... And cost a lot of man hours and money to correct)

I am sure this will be resolved in no-time. That's all  ::) 8-)

Well I always try to tell the problems, of course there is no money here, or maybe yes if used in commercial applications, but of course the time of people is valuable too.

Indeed I get it :)

circular

  • Hero Member
  • *****
  • Posts: 4195
    • Personal webpage
Re: BGRABitmap and 64bit
« Reply #14 on: May 30, 2016, 11:43:16 pm »
Hello people!

Thanks for pointing out the problem.

Quote from: Thaddy
To the BGRAbitmap maintainer(if this code really stems from BGRA code..) : Why? It is silly...
Please avoid calling it silly though. I am not comfortable with that.

I have just installed Lazarus 1.6 64bit. I am positively surprised that it handles nicely the fact that I have another version of Lazarus.

As Michl has said, the problem is that Abs cannot handle QWord.

To be more precise, I think that after subtracting a value to the QWord, it could be either a QWord or an Int64. The compiler considers it then to be an integer of undefined size and as Abs can take either 32-bit or 64-bit values, the compiler does not know what to use.

In all cases, it is easy to prevent this by adding an explicit type cast to NativeInt. Just did that on the repositories.

Quote from: Thaddy
on a 64bit processor it is debatable if it simply should not be declared as longword,  or cardinal, instead of the Native width of the processor. After all: it is just a 32bit calculation, also on a 64bit OS. I think it is wrong in this place to try to use a qword for the operation that is intended

So you say that because the calculation fits in a smaller size, you would follow the principle of storing it in a smaller variable?

I am following the principle that the computation is made using a 64-bit register, so I store the value with this precision to avoid conversions.

I am not sure what is faster here.

Quote from: Thaddy
@Circular: can you read reply #3, plz? Because I am not sure YOU made that mistake.
Which mistake are you talking about?

Quote from: tetrastes
Though this error and later issue with DoExecuteNormal in the bgrafilters.pas are easily corrected
Yes, I made a mistake regarding branching with 64-bit. I have fixed it on the repositories.

Quote from: tetrastes
bgrascenetypes.pas(631,1) Error: Internal error 2012090607
Ah, that's a compiler error. I will try a fix that worked for somewhere else, to add {$OPTIMIZATION OFF} around it.

Please try using version from SVN or from Git and tell me if it works.

Regards
« Last Edit: May 30, 2016, 11:44:49 pm by circular »
Conscience is the debugger of the mind

 

TinyPortal © 2005-2018