I'm trying to get reflection information for a compute shader compiled by my program by calling D3DCompile() or D3DCompile2().
Compilation is OK, confimed by code executing correctly.
Then I call D3DReflect to get a reflector against the compiled code.
Once I have the reflector, I call reflector->GetDesc(&ShaderDesc);
This works perfectly: ShaderDesc structure reports ConstantBuffers equal to 1 which is correct.
Then I call reflector->GetConstantBufferByIndex(0) which always returns the null pointer.
What is wrong ?
My environment: Windows 10 fully up-to-date, DirectX11 on NVidia Quadro K4200 with driver 24.21.14.1240 dated 21/07/2019, D3DCompiler_47.dll dated 19/03/2019.
Edit:
In the shader, the constant buffer is defined like this:
cbuffer TImageParams : register(b0)
{
int2 RawImageSize; // Actual image size in RawImage
// More items....
};
Kind regards
Related
I'm getting this on the console in a QML app:
QFont::setPointSizeF: Point size <= 0 (0.000000), must be greater than 0
The app is not crashing so I can't use the debugger to get a backtrace for the exception. How do I see where the error originates from?
If you know the function the warning occurs in (in this case, QFont::setPointSizeF()), you can put a breakpoint there. Following the stack trace will lead you to the code that calls that function.
If the warning doesn't include the name of the function and you have the source code available, use git grep with part of the warning to get an idea of where it comes from. This approach can be a bit of trial and error, as the code may span more than one line, etc, and so you might have to try different parts of the string.
If the warning doesn't include the name of the function, you don't have the source code available and/or you don't like the previous approach, use the QT_MESSAGE_PATTERN environment variable:
QT_MESSAGE_PATTERN="%{function}: %{message}"
For the full list of variables at your disposal, see the qSetMessagePattern() docs:
%{appname} - QCoreApplication::applicationName()
%{category} - Logging category
%{file} - Path to source file
%{function} - Function
%{line} - Line in source file
%{message} - The actual message
%{pid} - QCoreApplication::applicationPid()
%{threadid} - The system-wide ID of current thread (if it can be obtained)
%{qthreadptr} - A pointer to the current QThread (result of QThread::currentThread())
%{type} - "debug", "warning", "critical" or "fatal"
%{time process} - time of the message, in seconds since the process started (the token "process" is literal)
%{time boot} - the time of the message, in seconds since the system boot if that can be determined (the token "boot" is literal). If the time since boot could not be obtained, the output is indeterminate (see QElapsedTimer::msecsSinceReference()).
%{time [format]} - system time when the message occurred, formatted by passing the format to QDateTime::toString(). If the format is not specified, the format of Qt::ISODate is used.
%{backtrace [depth=N] [separator="..."]} - A backtrace with the number of frames specified by the optional depth parameter (defaults to 5), and separated by the optional separator parameter (defaults to "|"). This expansion is available only on some platforms (currently only platfoms using glibc). Names are only known for exported functions. If you want to see the name of every function in your application, use QMAKE_LFLAGS += -rdynamic. When reading backtraces, take into account that frames might be missing due to inlining or tail call optimization.
On an unrelated note, the %{time [format]} placeholder is quite useful to quickly "profile" code by qDebug()ing before and after it.
I think you can use qInstallMessageHandler (Qt5) or qInstallMsgHandler (Qt4) to specify a callback which will intercept all qDebug() / qInfo() / etc. messages (example code is in the link). Then you can just add a breakpoint in this callback function and get a nice callstack.
Aside from the obvious, searching your code for calls to setPointSize[F], you can try the following depending on your environment (which you didn't disclose):
If you have the debugging symbols of the Qt libs installed and are using a decent debugger, you can set a conditional breakpoint on the first line in QFont::setPointSizeF() with the condition set to pointSize <= 0. Even if conditional breakpoints don't work you should still be able to set one and step through every call until you've found the culprit.
On Linux there's the tool ltrace which displays all calls of a binary into shared libs, and I suppose there's something similar in the M$ VS toolbox. You can grep the output for calls to setPointSize directly, but of course this won't work for calls within the lib itself (which I guess could be the case when it handles the QML internally).
I have legacy code for an embedded 8051 core (in a cypress FX2) that used to compile with other versions of SDCC. However, current SDCC doesn't know the _naked qualifier:
delay.c:27: syntax error: token -> '_naked' ; column 21
as triggered by
static void
udelay1 (void) _naked
{
_asm ; lcall that got us here took 4 bus cycles
ret ; 4 bus cycles
_endasm;
}
and other occurrences.
As _naked practically is supposed to tell the C compiler to "nah, ignore the fact that you're a C compiler and understand that you'd need to save frame context", I don't feel like I should just #define it away.
Is there any solution to this? Should I just go ahead and manually inline the assembler wherever a _naked function is used? I feel like I'd betraying the compiler on a CALL there, and that would change the timing.
_naked was replaced by __naked in newer versions of SDCC. Same applies to asm/__asm, at/__at, interrupt,bit,xdata/__….
So, this turned out to be an exercise in regex replacements.
I'm still having linker/ranlib/mostly ar problems, and CMake ignores what I instruct it to use as compilers, but oh well.
I'm trying to get started with OpenCL but came across weird behavior of the OpenCL compiler with respect to white-space and can't seem to find any documentation about that.
C-style single-line comments (// foo) immediately cause a meaningless build error: At end of source: error: expected a "}". Multi-line comments (/* bar */) seem to work fine.
Line breaks seem to get stripped without adding whitespace which can cause errors. This example will not compile because of that:
__kernel
void TestKernel() {}
line 1: error: identifier "__kernelvoid" is undefined
This may totally depend on my machine and/or configuration but can somebody confirm that these things should not be this way?
I am using OpenCL via Cloo from .net/C#. The driver is from AMD OpenCL 2.0 AMD-APP (1642.5)
I think I figured it out. I was doing this:
var program = new ComputeProgram(context, File.ReadAllLines(filename));
File.ReadAllLines() returns an array of strings without the line-break characters which is the root of the errors I was getting.
Using File.ReadAllTest() instead fixed all the problems:
var program = new ComputeProgram(context, File.ReadAllText(filename));
But in my opinion some of the blame goes to either Cloo or the OpenCL API for accepting a string array but just concatenating it together..
i got a problem with simple cobol call - returning test program.
I am using micro focus cobol.
here are my 2 codes.
***************** CALLING PROGRAM
IDENTIFICATION DIVISION.
PROGRAM-ID. callreturning.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 VA PIC S9(8) USAGE DISPLAY.
01 VB PIC S9(8) USAGE DISPLAY.
01 VC PIC 9(4) USAGE DISPLAY value 0.
PROCEDURE DIVISION.
MOVE 1 TO VA.
MOVE 2 TO VB.
move 3 to VC.
CALL "add_two" USING VA VB returning VC.
* DISPLAY VA VB VC.
EXIT PROGRAM.
END PROGRAM callreturning.
*********CALLED PROGRAM
IDENTIFICATION DIVISION.
PROGRAM-ID. add_two.
ENVIRONMENT DIVISION.
DATA DIVISION.
LINKAGE SECTION.
01 PARM_A PIC S9(8) USAGE DISPLAY.
01 PARM_B PIC S9(8) USAGE DISPLAY.
01 PARM_C PIC 9(4) USAGE DISPLAY value 0.
PROCEDURE DIVISION USING PARM_A PARM_B returning PARM_C.
move 3 to PARM_C.
* ADD PARM_A TO PARM_B GIVING PARM_C.
goback.
END PROGRAM add_two.
CALLING program simply calls the second program with using returing value.
But when i compile both program and run, error happens.
error code: 114, pc=0, call=1, seg=0
114 Attempt to access item beyond bounds of memory (Signal 11)
Did i make a wrong code? or other problem? please help me :)
I am testing 'RETURNING' phrase
Your program compiles and works just fine if you get rid of the returning statement.
Background
01 levels defined in the linkage section are more like pointers in a C program. For normal parameters they are set by the calling program. But returning parameters will be unassigned.
The error is probably caused by trying to use an unallocated pointer.
Solution
Do not use returning as it is for working with languages like java.
Allocate storage to the return-value before using it.
See:
Microfocus Manual, Look at the returning example
IBM Manual Look at the Returning Phrase Section
Finally, returning is for working with java. Anything "type" defined on returning should be java compatible (i.e. binary-long and not 9(4)). I strongly suggest not using Returning in Cobol unless you are calling other languages.
Old Question, so i try a short Answer:
First, there is nothing wrong with using returning in MF-COBOL.
So, this is native COBOL (NetExpress as IDE, i assume). To correct ist just change the second Program:
Move PARM_C from the linkage to the working-storage section
The Procedure Division doesn't get the returning Phrase in its opening declaration. Move it instead to the goback phrase:
PROCEDURE DIVISION USING PARM_A PARM_B.
*>...
goback returning PARM_C.
I've been browsing the Qt source code trying to find the actual system calls but it seems Qt doesn't use the Windows API documented on MSDN. For example grepping the source for "GetClipboardData" returns results in two files:
qclipboard_win.cpp:
#if defined(Q_OS_WINCE)
...
HANDLE clipData = GetClipboardData(CF_TEXT)
qaxserverbase.cpp:
STDMETHOD(GetClipboardData)(DWORD dwReserved, IDataObject** ppDataObject);
...
HRESULT WINAPI QAxServerBase::GetClipboardData(DWORD, IDataObject**)
{
return E_NOTIMPL;
}
and "SetClipboardData":
qclipboard_win.cpp:
#if defined(Q_OS_WINCE)
...
result = SetClipboardData(CF_UNICODETEXT, wcsdup(reinterpret_cast<const wchar_t *> (data->text().utf16()))) != NULL;
Neither of which seems useful, since they're being declared for Win CE/Mobile.
My Qt (4.8.1) uses OleSetClipboard and OleGetClipboard. The lines you got to are never reached in regular windows, as only in case of #if defined(Q_OS_WINCE) Qt uses #define OleSetClipboard QtCeSetClipboard and #define OleGetClipboard QtCeGetClipboard, and otherwise uses system-provided versions of those functions.
It was a little dificult to see this #if defined though, so you are excused ;)
It is so at least on my Qt version. If you are talking about qt, and especially about it's internals, you should menstion the version, right?