Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
In atari_py/ale_c_wrapper.h:62 it writes 4 bytes per pixel, but was allocating 3 bytes here. Gym wasn’t affected, because it pre-allocates a buffer
- Loading branch information
a802482
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Several people (and me too) struck into this previously. This could be simply fixed, but requires simultaneous fix to
gym
. I can prepare a PR if you are interested.a802482
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what you have in mind. Is there still a bug?
a802482
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, function name is
getScreenRGB
, but it returnsBGRX
(reverted order + extra byte), so technically speaking yeah, there is still a bug.a802482
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renaming the function will break things, so I'll just document it clearly.
a802482
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you think it is better to leave this behavior and a workaround gym? I do not understand...
a802482
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
a802482
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On my system those byte swaps consume about the half of forward pass time. So it is nice way to spend cpu time.
a802482
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where are they being swapped? They don't get swapped in Gym or for most Gym agents I know about. OpenCV actually requires BGR order, and most Gym agents start by resizing the image.
a802482
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/openai/gym/blob/c4321c27913e71c0b343163e40e70789600b9341/gym/envs/atari/atari_env.py#L88
a802482
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right: there was an extra swap going on (although not where you point out: numpy can do that operation without touching the data by changing strides.) Anyway, these 2 commits (now in master) give a significant performance improvement:
openai/gym@3bc4692
5f2a362