When I ran a paper's open source code, such a problem occurred.
333333333: Event_61: system.cpu progress event, total committed:0, progress insts committed: 0, IPC: 00000000
666666666: Event_61: system.cpu progress event, total committed:0, progress insts committed: 0, IPC: 00000000
999999999: Event_61: system.cpu progress event, total committed:0, progress insts committed: 0, IPC: 00000000
1333333332: Event_61: system.cpu progress event, total committed:0, progress insts committed: 0, IPC: 00000000
1666666665: Event_61: system.cpu progress event, total committed:0, progress insts committed: 0, IPC: 00000000
1999999998: Event_61: system.cpu progress event, total committed:0, progress insts committed: 0, IPC: 00000000
2333333331: Event_61: system.cpu progress event, total committed:0, progress insts committed: 0, IPC: 00000000
it seems enter an endless loop. I saw the corresponding DPRINTF in src/cpu/base.cc. under what circumstance will such a problem occur? Do anyone know the reason ? or can you provide some suggestions on how to find the problem ?I've been stuck in this problem for two weeks.Thanks
Related
I'm trying to use gmsh 4.7.1 to create a mesh within a 3D volume, that is a sphere with a concentric spherical hole (in other words, I have a spherical shell). In order to do so, I wrote the following .geo file:
// Gmsh project created on Wed Feb 17 15:22:45 2021
SetFactory("OpenCASCADE");
//+
Sphere(1) = {0, 0, 0, 0.1, -Pi/2, Pi/2, 2*Pi};
//+
Sphere(2) = {0, 0, 0, 1, -Pi/2, Pi/2, 2*Pi};
//+
Surface Loop(3) = {2};
//+
Surface Loop(4) = {1};
//+
Volume(3) = {3, 4};
//+
Physical Surface(1) = {1};
//+
Physical Surface(2) = {2};
//+
Physical Volume(3) = {3};
But, as soon as I create a 3D mesh by using the 3D command in the gmsh gui, my inner hole gets meshed too, while I'd like to have no elements of the mesh within the hole.
What am I doing wrong? How can I obtain the desired result? Thank you.
There are several issues at play here:
Sphere command, already creates a volume, not surfaces as you expect.
due to the point above, the command Surface Loop(3) = {2}; is assumed to create a surface loop from a volume, which is 1) not a supported operation. 2) will try to use the surface with the tag 2. It is unclear, what it will do in reality (as a surface with the tag 2 probably still exists).
Thus, the Volume command gets some weird things as an input
and it is all connected with the fact that the characteristic length is not setup, thus the mesh density is quite arbitrary.
If you insist on using the OpenCASCADE kernel, you probably want to use boolean operations.
Here is the code I have with an arbitrarily chosen characteristic length of 0.05 for all the points defining the solid spherical shell:
SetFactory("OpenCASCADE");
Sphere(1) = {0, 0, 0, 0.1, -Pi/2, Pi/2, 2*Pi};
Sphere(2) = {0, 0, 0, 1, -Pi/2, Pi/2, 2*Pi};
BooleanDifference(3) = { Volume{2}; Delete; }{ Volume{1}; Delete; };
Characteristic Length{ PointsOf{ Volume{3}; } } = 0.05;
Visualization from Paraview of the produced mesh with clipping:
I have an app written with RXSwift which processes 500+ days of HealthKit data to draw a chart for the user.
The chart image is drawn incrementally using the code below. Starting with a black screen, previous image is drawn in the graphics context, then a new segment is drawn over this image with certain offset. The combined image is saved and the process repeats around 70+ times. Each time the image is saved, so the user sees the update. The result is a single chart image which the user can export from the app.
Even with autorelease pool, I see spikes of memory usage up to 1Gb, which prevents me from doing other resource intensive processing.
How can I optimize incremental drawing of very large (1440 × 5000 pixels) image?
When image is displayed or saved at 3x scale, it is actually 4320 × 15360.
Is there a better way than trying to draw over an image?
autoreleasepool {
//activeEnergyCanvas is custom data processing class
let newActiveEnergySegment = activeEnergyCanvas.draw(in: CGRect(x: 0, y: 0, width: 1440, height: days * 10), with: energyPalette)
let size = CGSize(width: 1440, height: height)
UIGraphicsBeginImageContextWithOptions(size, false, 0.0)
//draw existing image
self.activeEnergyImage.draw(in: CGRect(origin: CGPoint(x: 0, y: 0),
size: size))
//calculate where to draw smaller image over larger one
let offsetRect = CGRect(origin: CGPoint(x: 0, y: offset * 10),
size: newActiveEnergySegment.size)
newActiveEnergySegment.draw(in: offsetRect)
//get the combined image
let newImage = UIGraphicsGetImageFromCurrentImageContext()
UIGraphicsEndImageContext()
//assign combined image to be displayed
if let unwrappedImage = newImage {
self.activeEnergyImage = unwrappedImage
}
}
Turns out my mistake was in passing invalid drawing scale (0.0) when creating graphics context, which defaulted to drawing at the device's native screen scale.
In case of iPhone 8 it was 3.0 The result is needing extreme amounts of memory to draw, zoom and export these images. Even if all debug logging prints that image is 1440 pixels wide, the actual canvas ends up being 1440 * 3.0 = 4320.
Passing 1.0 as the drawing scale makes the image more fuzzy, but reduces memory usage to less than 200mb.
// UIGraphicsBeginImageContext() <- also uses #3x scale, even when all display size printouts show
let drawingScale: CGFloat = 1.0
UIGraphicsBeginImageContextWithOptions(size, true, drawingScale)
I'm just starting to learn opengl so I may not know all things. Using OpenTK with VB.net.
I have this code:
Dim pm As Matrix4 = Matrix4.CreatePerspectiveFieldOfView(1.57, 16 / 9, 0.1, 100)
GL.MatrixMode(MatrixMode.Projection)
GL.LoadMatrix(pm)
GL.Begin(PrimitiveType.Triangles)
GL.Vertex3(0, 0, -1) : GL.Color4(1.0!, 0!, 0!, 1.0!)
GL.Vertex3(1, 0, -1) : GL.Color4(0.0!, 1.0!, 0!, 1.0!)
GL.Vertex3(0, 1, -1) : GL.Color4(0.0!, 0.0!, 1.0!, 1.0!)
GL.End()
This correctly draws the triangle.
But when I change the z co-ordinate to +ve, they disappear. Like when GL.Vertex3(0, 0, +1), that vertex disappears. When all 3 vertices' z coords are +ve then nothing is visible.
I thought that this was because of some matrix stuff so I added a translation to the 'pm' matrix defined above:
Matrix4.CreateTranslation(0, 0, +1.0!, pm)
Still nothing happens.
But when all are -ve then all is good:
GL.Vertex3(0, 0, -10) : GL.Color4(1.0!, 0!, 0!, 1.0!)
GL.Vertex3(1, 0, -10) : GL.Color4(0.0!, 1.0!, 0!, 1.0!)
GL.Vertex3(0, 1, -10) : GL.Color4(0.0!, 0.0!, 1.0!, 1.0!)
Note: I've followed this guide. His code seems to have the same problem though no one addressed it. His code
Can someone explain this stuff to me? Thanks in advance.
In OpenGL one usually assumes that the camera is looking in -z direction (it's a convention, not a limit). Due to this, projection matrices are usually constructed in a way that they map the interval between [-nearPlane, -farPlane] to the visible depth region.
If you want to look in positive z, then you have to add a additional viewing matrix that rotates the camera by 180° around the y-axis (Or one that simply mirrors the z-axis but then the winding order changes).
I'm using the Gaussian blur algorithm found in Apple's UIImageEffects example:
CGFloat inputRadius = blurRadius * inputImageScale;
if (inputRadius - 2. < __FLT_EPSILON__)
inputRadius = 2.;
uint32_t radius = floor((inputRadius * 3. * sqrt(2 * M_PI) / 4 + 0.5) / 2);
radius |= 1; // force radius to be odd so that the three box-blur methodology works.
NSInteger tempBufferSize = vImageBoxConvolve_ARGB8888(inputBuffer, outputBuffer, NULL, 0, 0, radius, radius, NULL, kvImageGetTempBufferSize | kvImageEdgeExtend);
void *tempBuffer = malloc(tempBufferSize);
vImageBoxConvolve_ARGB8888(inputBuffer, outputBuffer, tempBuffer, 0, 0, radius, radius, NULL, kvImageEdgeExtend);
vImageBoxConvolve_ARGB8888(outputBuffer, inputBuffer, tempBuffer, 0, 0, radius, radius, NULL, kvImageEdgeExtend);
vImageBoxConvolve_ARGB8888(inputBuffer, outputBuffer, tempBuffer, 0, 0, radius, radius, NULL, kvImageEdgeExtend);
free(tempBuffer);
vImage_Buffer *temp = inputBuffer;
inputBuffer = outputBuffer;
outputBuffer = temp;
I'm also working with some fairly large images. Unfortunately, when the radius gets over 280, the blurred image suddenly becomes almost completely blank, regardless of the resolution. What's going on here? Does vImageBoxConvolve_ARGB8888 have an undocumented kernel width/height limit? Or does it have to do with the way the box kernel width is computed from the radius?
EDIT:
Found a similar question here: vImageBoxConvolve: errors when kernel size > 255. A Gaussian radius of 280 roughly translates to a 260 size kernel, so that part matches up.
The box and tent convolves can run into a problem where the value modulo overflows the 31-bit accumulator. However 255 seems a bit narrow for that. There should be another 7 bits of headroom at least for 255x255. Certainly, check the error code returned by the function. If it says everything is fine, then this seems bug worthy. Attach some sample code to help Apple reproduce the problem to help ensure it is fixed.
I'm trying to figure out how to turn "TrueColor" on for a Microsoft LifeCam. I have a couple big USB logs from USBSniffer, and some sequences which consistently show up when I click the checkbox in Microsoft's software. Here's a request from the beginning of the enable sequence, and the device response (please correct me if I'm misinterpreting this data btw):
[156918643 ms] UsbSnoop - FilterDispatchAny(ac56afd2) : IRP_MJ_INTERNAL_DEVICE_CONTROL
[156918643 ms] UsbSnoop - FdoHookDispatchInternalIoctl(ac56b1ea) : fdo=88b25448, Irp=889911d8, IRQL=0
[156918643 ms] >>> URB 1482 going down >>>
-- URB_FUNCTION_CLASS_INTERFACE:
TransferFlags = 00000001 (USBD_TRANSFER_DIRECTION_IN, ~USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000002
TransferBuffer = abb04b86
TransferBufferMDL = 00000000
UrbLink = 00000000
RequestTypeReservedBits = 00000000
Request = 00000085
Value = 00001600
Index = 00000500
[156918644 ms] UsbSnoop - MyInternalIOCTLCompletion(ac56b126) : fido=00000000, Irp=889911d8, Context=894d6c98, IRQL=2
[156918644 ms] <<< URB 1482 coming back <<<
-- URB_FUNCTION_CONTROL_TRANSFER:
PipeHandle = 885639a0
TransferFlags = 0000000b (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000002
TransferBuffer = abb04b86
TransferBufferMDL = 8837fee0
00000000: 40 00
UrbLink = 00000000
SetupPacket =
00000000: a1 85 00 16 00 05 02 00
Now, I'd like to send the sequence of requests I've seen via PyUSB, but when I send that first one, I get:
>>> ret = dev.ctrl_transfer(0x80, 0x85, 0x1600, 0x0500, 8)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "c:\Python24\Lib\site-packages\usb\core.py", line 702, in ctrl_transfer
self.__get_timeout(timeout)
File "c:\Python24\Lib\site-packages\usb\backend\libusb0.py", line 539, in ctrl_transfer
timeout
File "c:\Python24\Lib\site-packages\usb\backend\libusb0.py", line 387, in _check
raise USBError(errmsg, ret)
usb.core.USBError: (None, 'usb_control_msg: invalid request 0x85')
For what it's worth, a simple GET_STATUS seems to work:
>>> ret = dev.ctrl_transfer(0x80, 0, 0, 0, 8)
>>> print ret
array('B', [0, 0])
Why would a request which gets answered in one case be invalid in another? Syntax? Device state?
From the very helpful USB Made Simple, the request type's highest 3 bits are formatted like so:
D7 Data direction
0 - Host-to-device
1 - Device-to-host
D6:5 Type
0 = Standard
1 = Class
2 = Vendor
3 = Reserved
The log says I'm using USB's Class interface (cf. "URB_FUNCTION_CLASS_INTERFACE"), so the RequestType is specific to the device class (audio, physical... in this case video). The GET_STATUS command works because it is of the Standard type.
So a more correct command is
ret = dev.ctrl_transfer(0xa0, 0x85, 0x1600, 0x0500, 8)
I say more correct because the command returns data, but it's still not the data I expect!
EDIT: for complete verisimilitude, I needed to specify the recipient as the interface, according to the rest of the request type table from USB Made Simple:
D4:0 Recipient
0 = Device
1 = Interface
2 = Endpoint
3 = Other
4-31 = Reserved
...and also set the length to be the same as the sniffed request, so the true version of the command is:
ret = dev.ctrl_transfer(0xa1, 0x85, 0x1600, 0x0500, 2)