Acc. Sdl? Silly Question

[MSweeney]

?

Ok a silly question maybe, but can someone explain exactly what is 'accelerated' in the GP2x SDL libs as compared to generic SDL? Is there actually functionality in the GP2X video processor for drawing accelerated lines for example? Or does this just simply change the way the Frame Buffer is accessed (ie: using mmap over opening the standard fb streams). I had intended to access the FB directly via ME anyway after my crappy little library works ok with SDL, so that may not be much useful to me.

I am starting work on a very basic 3d engine, and am working on some simple integer line drawing routines etc. However, if there is functionality to draw lines, sprites, pixels or even fill triangles in hardware I would obviously want to use those instead (Im sure there is no 3d accel. of any kind - but even 2d sprite accel. would be very helpful to me).

Again sorry for the silly questions, but people here are so helpful and straight to the point without flames and I am only interested in moving forward!

Matt Sweeney

 

[Dzz]

?

Ok a silly question maybe, but can someone explain exactly what is 'accelerated' in the GP2x SDL libs as compared to generic SDL? Is there actually functionality in the GP2X video processor for drawing accelerated lines for example? Or does this just simply change the way the Frame Buffer is accessed (ie: using mmap over opening the standard fb streams). I had intended to access the FB directly via ME anyway after my crappy little library works ok with SDL, so that may not be much useful to me.

I am starting work on a very basic 3d engine, and am working on some simple integer line drawing routines etc. However, if there is functionality to draw lines, sprites, pixels or even fill triangles in hardware I would obviously want to use those instead (Im sure there is no 3d accel. of any kind - but even 2d sprite accel. would be very helpful to me).

Again sorry for the silly questions, but people here are so helpful and straight to the point without flames and I am only interested in moving forward!

Matt Sweeney

Lines are not accelerated, but "blits" (block transfers) between hardware surfaces are accelerated with the 2D accelerator.

I don't think it would be very helpful for a 3D engine, but it might be a fast way to clear the screen prior to rendering.

 

[god_at_hell]

The GP2X has a 2D hardware acceleration which can speed up several operations. It´s not only blit. I just took a look at the handbook:

1. ROPs:
- BitBLT
- Area Fill
- Pattern Fill
- Memory-to-Screen Transfer

2. Transperancy (a simple "cut color X"-funktion ... no alpha-blending)

3. monochrome to color expansion

4. Fraction control


additionally to this you could use the VideoPostProcessor for rotation, scaling, alpha blending, color key, mirroring and several other features (eg. dithering)

 

[Radek]

The GP2X has a 2D hardware acceleration which can speed up several operations. It´s not only blit. I just took a look at the handbook:

1. ROPs:
- BitBLT
- Area Fill
- Pattern Fill
- Memory-to-Screen Transfer

2. Transperancy (a simple "cut color X"-funktion ... no alpha-blending)

You can somewhat fake color addition using OR function in 16BPP. It will not look "correct" as there will not be carry between bits but it's still interesting.

3. monochrome to color expansion

4. Fraction control

That should be called a bit shifting because it's really what it is.

additionally to this you could use the VideoPostProcessor for rotation, scaling, alpha blending, color key, mirroring and several other features (eg. dithering)

Rotation is only for 90 degress, scaling is flexible for the rest I haven't yet seen anyone using them.

 

[MSweeney]

Hey thanks for the replies, so it does seem the hardware is useful for a powerful sprite engine at least - or for a window manager UI. Where exactly do you find the info on the hardware? Is it the MagicEyes documentation or is there some other manual I am possibly missing? )

Matt

 

[Dzz]

Hey thanks for the replies, so it does seem the hardware is useful for a powerful sprite engine at least - or for a window manager UI. Where exactly do you find the info on the hardware? Is it the MagicEyes documentation or is there some other manual I am possibly missing? )

Matt

There are a few conversations on this board from ancient history (way back in 2005, heh) where the smart tech guys puzzled out the basic blitter operations. I'm not sure that ANYBODY has for sure worked out how to use the other stuff like alpha blending (I mean with working code).

 

[god_at_hell]

http://mudiweb.com/gp2x/MP2520F_Manual_Eng_V1.0.pdf
take a look at page 407ff

you could take a look at Robsters SDK too: http://www.cobbleware.com/files/sdk2x_191205d.tar.gz

 

[MSweeney]

http://mudiweb.com/gp2x/MP2520F_Manual_Eng_V1.0.pdf
take a look at page 407ff

you could take a look at Robsters SDK too: http://www.cobbleware.com/files/sdk2x_191205d.tar.gz

:wub:

Cheers, much thanks for the info.

 

[scorpio]

I am starting work on a very basic 3d engine, and am working on some simple integer line drawing routines etc. However, if there is functionality to draw lines, sprites, pixels or even fill triangles in hardware I would obviously want to use those instead (Im sure there is no 3d accel. of any kind - but even 2d sprite accel. would be very helpful to me).

I'm in the middle of tidying up some code as part of a small tutorial on using the blitter for sprites, and I hope to have something finished for the weekend, so that might help a little bit. The blitter can be used for drawing horizontal and vertical lines, so you will probably find it useful as part of a triangle rasteriser, but it would only be good for flat coloured polys. For shaded or textured polygons, I don't think it will be any use at all, but I could be proved wrong if somebody out there has some clever code. For drawing pixels, it would probably be quicker to use the CPU...

 

[Radek]

I am starting work on a very basic 3d engine, and am working on some simple integer line drawing routines etc. However, if there is functionality to draw lines, sprites, pixels or even fill triangles in hardware I would obviously want to use those instead (Im sure there is no 3d accel. of any kind - but even 2d sprite accel. would be very helpful to me).

I'm in the middle of tidying up some code as part of a small tutorial on using the blitter for sprites, and I hope to have something finished for the weekend, so that might help a little bit. The blitter can be used for drawing horizontal and vertical lines, so you will probably find it useful as part of a triangle rasteriser, but it would only be good for flat coloured polys. For shaded or textured polygons, I don't think it will be any use at all, but I could be proved wrong if somebody out there has some clever code. For drawing pixels, it would probably be quicker to use the CPU...

The problem (and advantage) of blitter is that it's really direct access memory device. I was thinking about using its shifting capability to fill cache row and then further process pixels by cpu. But as it's doing DMA it can not be done. It's pity really because it'd save some cpu cycles as I have to shift in cpu to have pixel accurate horizontal scrolling.

Fortunately the 920T has some other tricks what weren't tapped yet.

 

[scorpio]

Fortunately the 920T has some other tricks what weren't tapped yet.

Sounds like you have something up your sleeve for the demo competition!

Can the blitter render data into the 940's address space, perhaps that might be another option?

 

[paeryn]

Can the blitter render data into the 940's address space, perhaps that might be another option?

Yes, that's the only place it can at the moment. You can't blit into the lower 32MB (well, actually you can) because that is managed by the 920's MMU and so there's no reasonable way to tell what areas are free from one moment to the next.
All the other hardware bits (blitter, display, audio, 940 etc) have certain area of the upper memory allocated to them

 

[scorpio]

Can the blitter render data into the 940's address space, perhaps that might be another option?

Yes, that's the only place it can at the moment. You can't blit into the lower 32MB (well, actually you can) because that is managed by the 920's MMU and so there's no reasonable way to tell what areas are free from one moment to the next.
All the other hardware bits (blitter, display, audio, 940 etc) have certain area of the upper memory allocated to them

As I might have mentioned in another thread, I'm toying with the idea of writing a kernel module that will provide memory amd IRQ management routines for the upper 32MB, and I think something that would be good to add would be an interface which can return the physical location of normally-allocated memory.

Have you tried blitting into the lower 32MB, though? I haven't tried it myself (yet), but seeing as how getting the blitter to work involves enabling the FASTIO clock, and only the upper memory is designated as FASTIO, would it not hang if you tried to use it to access the lower 32MB?

I should state that my original comment there was geared more towards implying that you could use the blitter to perform its raster ops for a line into the 940's address space, while the 940 processes the previous line and kind of double-buffers the line processing through the 940's limited address space.

 

[paeryn]

As I might have mentioned in another thread, I'm toying with the idea of writing a kernel module that will provide memory amd IRQ management routines for the upper 32MB, and I think something that would be good to add would be an interface which can return the physical location of normally-allocated memory.

Nope, due to the way virtual memory works there's no gaurantee that the virtual memory block you allocated is really one contiguous block of physical memory, it could be split up all over the place. And only the 920's MMU can do the translating. That's why the memory's split into 32MB for the 920 and 32MB for everything else.

Have you tried blitting into the lower 32MB, though? I haven't tried it myself (yet), but seeing as how getting the blitter to work involves enabling the FASTIO clock, and only the upper memory is designated as FASTIO, would it not hang if you tried to use it to access the lower 32MB?

FASTIO is a reserved part of the memoryspace where the blitter registers are located, nothing to do with physical memory. If you started writing to the lower 32MB there's no telling what you're overwriting, and a good chance it'll be part of the OS code!

I should state that my original comment there was geared more towards implying that you could use the blitter to perform its raster ops for a line into the 940's address space, while the 940 processes the previous line and kind of double-buffers the line processing through the 940's limited address space.

Due to the setup time needed for the blitter registers (all relevent registers have to be written every time,) and the fact that the blitter works asynchronously, I think you'd be able to do it quicker not involving the blitter.

 

[scorpio]

Nope, due to the way virtual memory works there's no gaurantee that the virtual memory block you allocated is really one contiguous block of physical memory, it could be split up all over the place.

Yes, I was thinking of that before, and I thought that it might be best that the function returns not a pointer to the memory block, but a pointer to a list of of all the pages allocated for the block. There is a minimum page size, right? So, if you're not using large blocks of memory (.e.g sprite storage) it should be possible to use this and not have the granularity impinge on your code too much. Alternatively, I think this is a parameter that can be tuned in real-time, so it might be possible to make the system allocate you a contiguous block. It's been a couple of weeks now, so I'll have to read up on it again, but I think there is some control there, although it might have been specific to a particular version of the kernel.

If you started writing to the lower 32MB there's no telling what you're overwriting, and a good chance it'll be part of the OS code!

Right, thanks for clearing up the FASTIO thing, I should really have checked the docs before writing that (I have them printed out too, so I've no excuse!) As regards the other point, if you're accessing memory and you have a mechanism to find out where your memory really is, then you would at least be able to know what areas were "safe". So, while the functionality may not be massively useful in a lot of cases, it would provide an option that we wouldn't have had before, and could come in really handy when you needed it.

Due to the setup time needed for the blitter registers (all relevent registers have to be written every time,) and the fact that the blitter works asynchronously, I think you'd be able to do it quicker not involving the blitter.

I was wondering about something when I first started on programming the blitter, and you might be the person with the experience to clear it up. As far as I know the blitter registers are double-buffered. So, when you start a blitter run, does the previous register set swap back in? That is to say, could you double-buffer your blitter usage as well, minimising the setup time? That way, you would only need to set the registers that you know need to be changed.

At the moment I'm talking about the blitter in relation to use in hand-optimised demo code rather than a general-purpose C function, so the code would be pretty tightly coupled to what's going on in the 920 as well.

 

[paeryn]

Yes, I was thinking of that before, and I thought that it might be best that the function returns not a pointer to the memory block, but a pointer to a list of of all the pages allocated for the block. There is a minimum page size, right? So, if you're not using large blocks of memory (.e.g sprite storage) it should be possible to use this and not have the granularity impinge on your code too much. Alternatively, I think this is a parameter that can be tuned in real-time, so it might be possible to make the system allocate you a contiguous block. It's been a couple of weeks now, so I'll have to read up on it again, but I think there is some control there, although it might have been specific to a particular version of the kernel.

Right up until the kernel allocates some memory for itself bang in the middle of what you're using.
You'll need a way of allocating a specific block of memory - I've not looked into how Linux manages is memory. Plus, don't forget the possibilty of cache discontinuity. Any writes by the blitter wont be shadowed in the 920's cache.

Due to the setup time needed for the blitter registers (all relevent registers have to be written every time,) and the fact that the blitter works asynchronously, I think you'd be able to do it quicker not involving the blitter.

I was wondering about something when I first started on programming the blitter, and you might be the person with the experience to clear it up. As far as I know the blitter registers are double-buffered. So, when you start a blitter run, does the previous register set swap back in? That is to say, could you double-buffer your blitter usage as well, minimising the setup time? That way, you would only need to set the registers that you know need to be changed.

When I was playing around with it I seem to remember that the register set you get back to write to is zeroed, unless it's just that you can't read the registers. I'll have a look later and see.

 

[scorpio]

Right up until the kernel allocates some memory for itself bang in the middle of what you're using.
You'll need a way of allocating a specific block of memory - I've not looked into how Linux manages is memory.

Well I was thinking that the module would allocate the memory as normal, so the kernel would be aware of it, but because the module will be part of the kernel, it will be able to tell the user-level application where the memory physically is. I'm not talking about bypassing the kernel's memory allocation routines for the lower 32MB, but taking advantage of them, and perhaps extending them to the upper 32MB. I have a few memory management functions written myself for the upper 32MB, but of course when they're used, only my program knows what's going on. Putting it into a kernel module would mean that other applications could access this information and not step on each others' toes.

Plus, don't forget the possibilty of cache discontinuity. Any writes by the blitter wont be shadowed in the 920's cache.

Ah, good point. I hadn't considered that, as my focus was more on using the RAM for read storage. I guess a 'flush cache' could be another function in the module.

As speculation, perhaps an MMU trap could be added when blocks are allocated, so that writes to blocks allocated in this way (in the lower 32MB, of course) would result in a flush. I don't know if this is possible with the MMSP2's setup though, as I have no idea how the MMU works yet.

Due to the setup time needed for the When I was playing around with it I seem to remember that the register set you get back to write to is zeroed, unless it's just that you can't read the registers. I'll have a look later and see.

Don't worry about it, I'm cleaning up some sprite code this weekend, so I'll experiment with it and see what happens...