I am a novice user of DirectX technologies.
How can I scroll a contents of ID3D10Texture2D? using bitblt. Something like BitBlt on GDI device context where src and dst hdc are the same.
I have ID3D10Texture2D from IDXGISurface which scrolling is my real goal, but could not find anything in the dxgi api.
Scrolling is fairly easy. To draw an entire texture you texture from 0, 0 to 1,1. Now instead add 0.5 to each x coordinate so you get the following:
0.5, 0.0----------------1.5, 0.0
| |
| |
| |
| |
| |
0.5, 1.0----------------1.5, 1.0
You will now find the texture has srolled by half its width to the right.
Hope that helps!
Edit: If you can't do the above then you may be slightly stuck as you can't read and write from the same texture (well on some drivers you can but its undefined behaviour). So you have 2 options.
1) Create a render-target texture and then render (as above) the original texture to the new render target with your offset. Then texture with the render target texture.
2) Lock (Map) the texture and copy individual bytes around to the new positions (This will be very slow due to the PCIe bus copy).
So ideally you'd do as I suggest in 1. For best performance however you'd set up a "scrolling texture vertex shader" where you set the scroll amount as a constant and then offset the texture coords per-vertex as originally described. This would be by far the most performant method.
Related
I dont understand the rendering of an opengl window. So lets say i want my graphics card to draw a scene onto the screen. My opengl window is at location, lets say 50, 50, 100, 100 (x, y , width, height). The GPU knows to draw the scene at this location. This is called the viewport and the GPU gets this viewport information in form of a matrix.
What happens when i move my opengl window from location 50, 50, 100, 100 to location 150, 150, 100, 100. How does the GPU gets this new viewport information while still rendering the scene (maybe it is now in the fragmentshader stage). It will paint the wrong pixels at location 50, 50, 100, 100. Please explain.
My opengl window is at location, lets say 50, 50, 100, 100 (x, y , width, height). The GPU knows to draw the scene at this location.
Does it? You are making assumptions about the specific nature of what the internals of the rendering system, OS, and GPU are doing.
In many composition-based rendering systems, the rendering operation you generate when you perform OpenGL commands renders to a piece of memory, some image data. When you do a swap-buffers call, that image gets copied into the actual screen area that you see. So when you move the window around, all that happens is that the image you render to gets copied into a different location. While the copy is indeed performed by the GPU, the rendering operations you directly caused aren't aware of what location their results will ultimately end up in.
Even in rendering systems where you directly render to display memory, whose to say that what you can set as your "viewport" is not manipulated by the internal OpenGL driver? When you move the window from one location to another, the driver can simply offset your viewport settings, and you will be none the wiser.
Basically, there are many ways for it to happen, and which way gets selected depends entirely on how the OpenGL implementation (and attendant OS/rendering system) chooses to handle screen locations.
I don't know the entire internals of the graphics stack, but when you request a viewport, you are getting a pixel buffer from a display server like X server or wayland. The GPU does computations to fill a frame buffer with colors. The display server then throws the frame buffer to the window. This is oversimplifying, and I have some details wrong. On linux, there is a complex pipeline of events that occur from the exiting user space, getting into the kernel to finally seeing your frame buffer on the screen.
Many of the embedded/mobile GPUs are providing access to performance registers called Pixel Write Speed and Texel Write speed. Could you explain how those terms can be interpreted and defined from the actual GPU hardware point of view?
I would assume the difference between pixel and texel is pretty clear for you. Anyway, just to make this answer a little bit more "universal":
A pixel is the fundamental unit of screen space.
A texel, or texture element (also texture pixel) is the fundamental unit of texture space.
Textures are represented by arrays of texels, just as pictures are
represented by arrays of pixels. When texturing a 3D surface (a
process known as texture mapping) the renderer maps texels to
appropriate pixels in the output picture.
BTW, it is more common to use fill rate instead of write speed and you can easily find all required information, since this terminology is quite old and widely-used.
Answering your question
All fill-rate numbers (whatever definition is used) are expressed in
Mpixels/sec or Mtexels/sec.
Well the original idea behind fill-rate was the number of finished
pixels written to the frame buffer. This fits with the definition of
Theoretical Peak fill-rate. So in the good old days it made sense to
express that number in Mpixels.
However with the second generation of 3D accelerators a new feature
was added. This feature allows you to render to an off screen surface
and to use that as a texture in the next frame. So the values written
to the buffer are not necessarily on screen pixels anymore, they might
be texels of a texture. This process allows several cool special
effects, imagine rendering a room, now you store this picture of a
room as a texture. Now you don't show this picture of the room but you
use the picture as a texture for a mirror or even a reflection map.
Another reason to use MTexels is that games are starting to use
several layers of multi-texture effects, this means that a on-screen
pixel is constructed from various sub-pixels that end up being blended
together to form the final pixel. So it makes more sense to express
the fill-rate in terms of these sub-results, and you could refer to
them as texels.
Read the whole article - Fill Rate Explained
Additional details can be found here - Texture Fill Rate
Update
Texture Fill Rate = (# of TMU - texture mapping unit) x (Core Clock)
The number of textured pixels the card can render to the
screen every second.
It is obvious that the card with more TMUs will be faster at processing texture information.
The performance registers/counters Pixel Write Speed and Texel Write speed maintain stats / count operations about pixel and texel processed/written. I will explain the peak (maximum possible) fill rates.
Pixel Rate
A picture element is a physical point in a raster image, smallest
element of display device screen.
Pixel rate is the maximum amount of pixels the GPU could possibly write to the local memory in one second, measured in millions of pixels per second. The actual pixel output rate also depends on quite a few other factors, most notably the memory bandwidth - the lower the memory bandwidth is, the lower the ability to get to the maximum fill rate.
The pixel rate is calculated by multiplying the number of ROPs (Raster Operations Pipelines - aka Render Output Units) by the the core clock speed.
Render Output Units : The pixel pipelines take pixel and texel information and process it, via specific matrix and vector operations, into a final pixel or depth value. The ROPs perform the transactions between the relevant buffers in the local memory.
Importance : Higher the pixel rate, higher is the screen resolution of the GPU.
Texel Rate
A texture element is the fundamental unit of texture space (a tile of
3D object surface).
Texel rate is the maximum number of texture map elements (texels) that can be processed per second. It is measured in millions of texels in one second
This is calculated by multiplying the total number of texture units by the core speed of the chip.
Texture Mapping Units : Textures need to be addressed and filtered. This job is done by TMUs that work in conjunction with pixel and vertex shader units. It is the TMU's job to apply texture operations to pixels.
Importance : Higher the texel rate, faster the game renders displays demanding games fluently.
Example : Not a nVidia fan but here are specs for GTX 680, (could not find much for embedded GPU)
Model Geforce GTX 680
Memory 2048 MB
Core Speed 1006 MHz
Shader Speed 1006 MHz
Memory Speed 1502 MHz (6008 MHz effective)
Unified Shaders 1536
Texture Mapping Units 128
Render Output Units 32
Bandwidth 192256 MB/sec
Texel Rate 128768 Mtexels/sec
Pixel Rate 32192 Mpixels/sec
I have an OpenGL texture that I generate through a couple of render passes in my FBO.
Now I want to use the texture as vertex data in a VBO and render stuff with it.
Since all data is GPU-sided, is there an efficient way to transfer (or re-interpret) texture data as vertex data in OpenGL?
Or do I have to go all the way through the CPU with
// ... generate texture on GPU.
glReadBuffer(..where the texture is..);
glReadPixels(..., mainMemoryBuffer);
glBufferSubData(GL_ARRAY_BUFFER, ..., mainMemoryBuffer);
? Or is there another way to achieve what I want?
Ok. After some more research it seems that PBOs (Pixel Buffer Objects) are the OpenGL feature which enable this:
glBindBuffer(GL_PIXEL_PACK_BUFFER, myVbo);
glReadPixels(..., 0);
Unfortunately it seems they are unavailable on OpenGL ES (see this thread on GameDevelopment).
I'm getting a fishy error when using glDrawElements(). I'm trying to render simple primitives (mainly rectangles) to speed up drawing of text and so forth, but when I call glDrawElements() the WHOLE screen blinks black (not just my window area) for one frame or so. The next frame it turns back to the same "Windows colors" as before. And so it flickers for a couple of seconds, ending up in a message box saying
The NVIDIA OpenGL Driver encountered an unrecoverable error
and must close this application.
Error 12
Is there any setting for GL which I need to reset before calling glDrawElements()? I know it's not some dangling glEnableClientState(), I checked it (I used to have one of those, but then glDrawElements() crashed instead).
Come to think of it, it almost looks like some back buffer error... Any ideas on what to try?
Obviously you are mixing VBO mode and VA mode. This is perfectly possible but must be use with care.
When you call:
glBindBuffer(GL_ARRAY_BUFFER, 0);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0);
This means that next time you render something with glDrawElements(..., ..., ..., x), it will use x as a pointer on the indices data, and the last call to glVertexPointer points on the vertices data.
If you don't unbind the current VBO and IBO (with the above two glBindBuffer calls), this means that when rendering with the same glDrawElements, x will be use as an offset on the indices data in the IBO, and the last call to glVertexPointer as an offset on the vertices data in the VBO.
Depending values of x and glVertexPointer you can make the driver crash because the offsets go out of bounds and/or the underlying data is of the wrong type (NaN).
So for answering your question, after drawing with VBO mode and then drawing with VA mode:
unbind the current VBO
unbind the current IBO
specify the right vertices address with glVertexPointer
specify the right indices address with glDrawElements
and then it will be fine.
Bah! Found it. When I did
glBindBuffer(GL_ARRAY_BUFFER, 0);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0);
before rendering the flickering+crashing stopped. Is this the expected behavior? Sorry for wasting time and space.
I'v got a bitmap 24bits, I am writing application in c++, MFC,
I am using libjpeg for encoding the bitmap into jpeg file 24bits.
When this bitmap's width is M, and height is N.
How to estimate jpeg file size before saving it with certain quality factor N (0-100).
Is it possible to do this?
For example.
I want to implement a slide bar, which represent save a current bitmap with certain quality factor N.
A label is beside it. shows the approximate file size when decode the bitmap with this quality factor.
When user move the slide bar. He can have a approximate preview of the filesize of the tobe saved jpeg file.
In libjpeg, you can write a custom destination manager that doesn't actually call fwrite, but just counts the number of bytes written.
Start with the stdio destination manager in jdatadst.c, and have a look at the documentation in libjpeg.doc.
Your init_destination and term_destination methods will be very minimal (just alloc/dealloc), and your empty_output_buffer method will do the actual counting. Once you have completed the JPEG writing, you'll have to read the count value out of your custom structure. Make sure you do this before term_destination is called.
It also depends on the compression you are using and to be more specific how many bits per color pixel are you using.
The quality factor wont help you here as a quality factor of 100 can range (in most cases) from 6 bits per color pixel to ~10 bits per color pixel, maybe even more (Not sure).
so once you know that its really straight forward from there..
If you know the Sub Sampling Factor this can be estimated. That information comes from the start of frame marker.
In the same marker right before the width and height so is the bit depth.
If you let
int subSampleFactorH = 2, subSampleFactorV = 1;
Then
int totalImageBytes = (Image.Width / subSampleFactorH) * (Image.Height / subSampleFactorV);
Then you can also optionally add more bytes to account for container data also.
int totalBytes = totalImageBytes + someConstantOverhead;